서치AI/ML 개발자 3년 이상 (FDE)
0.0서치독
경력근거: 글로벌 검색 수준의 Retrieval·Indexing 파이프라인을 설계·구축합니다
41일 전 확인채용 공고 보기
※ 실제 산출물이 아닌 AI 예측 시안입니다.
서치독 FDE는 고객사 현장에서 직접 부딪치며 건축 2D 도면·3D BIM·제조 3D 모델 문제를 정의하고, 글로벌 검색 수준의 Retrieval·Indexing 파이프라인과 생성형 AI Multi-Agent 서비스로 그 도메인 문제를 푸는 역할입니다. 규격 조항이 문서마다 흩어져 있고 같은 부재를 다른 이름으로 부르는 건축·제조 문서 특성상, 어휘 검색과 의미 검색을 함께 걸어 맞는 조항을 근거로 끌어오고 없는 근거는 막는 검색 파이프라인이 이 회사 업무의 핵심입니다. 이 포트폴리오는 그 Retrieval·Indexing과 근거 기반 생성 기술을 정면으로 보여줍니다. 다만 보여주는 것은 검색·생성형 AI 서비스를 만드는 FDE 기술이지 건축 구조·제조 공차 같은 규격 도메인 자체의 전문성이 아닙니다. 그 도메인 깊이는 포트폴리오로 증명되지 않으므로 주장하지 않고, 모르는 규격은 면접에서 모른다고 말하는 편이 낫습니다. 검색 적중과 근거 정합은 정답 조항 아이디 대조 같은 결정론 규칙으로만 판정합니다.
고객사 현장에서 직접 부딪치며 건축 2D 도면·3D BIM·제조 3D 모델 문제를 정의하고 가설·데이터셋·평가로 반복 실험합니다. 규격 검색 어시스턴트가 그 현장 문제 해결 흐름과 정렬됩니다.
글로벌 검색 수준의 Retrieval·Indexing 파이프라인을 설계·구축하고 Semantic/Vector와 BM25/Lexical 검색을 이해합니다. 문서 인덱싱과 하이브리드 검색 골조가 정면으로 정렬됩니다.
Dataset·Evaluation Set을 설계하고 생성형 AI로 도메인 문제 해결형 Multi-Agent 서비스를 개발·운영합니다. 검색 평가셋과 질의 분해 에이전트가 정렬됩니다.
건축·제조 규격 조항 문서를 검색 인덱스에 올리고, 현장 담당자의 질문을 받아 BM25 어휘 검색과 벡터 의미 검색으로 관련 조항을 찾아 근거 인용으로 답하는 규격 검색 어시스턴트입니다. 답이 맞았는지는 질문마다 미리 정한 정답 조항 아이디(gold_clause_id)에 검색 결과가 들어왔는지, 생성한 답이 검색된 조항만 인용했는지 같은 결정론 규칙으로 판정하고, 정답 조항이 없는 질문은 지어내지 않고 '근거 없음'으로 막습니다. LLM은 찾은 조항을 근거로 답을 요약하는 역할이며 검색 적중 판정 자체는 규칙이 합니다. 검색·생성형 AI 서비스를 만드는 FDE 기술을 보여주는 것이지 건축·제조 규격 자체의 전문성을 주장하지 않습니다.
서치독 FDE. 고객사 현장에서 건축 도면·BIM·제조 3D 규격 문제를 풀 때 '이 부재의 기준 조항이 어느 문서 어디에 있는가'를 흩어진 규격 문서에서 매번 손으로 뒤지던 일을, 한 검색창에서 질문을 넣으면 관련 조항을 근거 인용으로 받고 싶은 사람입니다.
규격 문서를 조항 단위로 쪼개 어휘 검색과 의미 검색을 함께 인덱싱하면, (a) 질문에 맞는 조항을 상위 검색 결과 안에 넣어 근거 인용으로 답하고, (b) 검색 결과에 없는 내용은 지어내지 않고 '근거 없음'으로 막으며, (c) 어휘가 다른 동의어 질문과 여러 조항을 조합해야 하는 질문을 검색 방식별로 나눠 강약을 드러냅니다.
건축·제조 규격 조항 문서를 BM25와 벡터 검색으로 인덱싱하고, 질문을 넣으면 관련 조항 상위 결과를 근거 인용으로 답하는 동작하는 검색 화면입니다. 문서는 공개 규격 요약과 작성자가 만든 더미 조항으로 채우고, 정답 조항이 없는 질문은 '근거 없음'으로 막는 것까지 완결합니다.
같은 평가셋을 BM25 단독·벡터 단독·하이브리드로 돌려 검색 적중과 근거 정합을 비교하고, 동의어 질문과 여러 조항 조합 질문에서 어느 방식이 강한지와 검토자 일치도를 리포트로 남기는 화면입니다.
복합 질문을 하위 질의로 분해하고 조항을 각각 검색해 근거를 조립하는 Multi-Agent 흐름을 붙이고, 어느 하위 질의도 근거를 못 찾으면 지어내지 않고 '근거 없음'으로 표시하는 화면입니다.
건축·제조 규격 질문을 넣으면 관련 조항이 상위 검색 결과로 나오고 답변에 근거 인용이 붙는 걸 몇 초 안에 시연합니다
일부러 만든 악성·결측 질문 30종(정답 조항 없는 질문·동의어만 다른 질문·미등록 조항 참조·본문 결측 조항)을 넣어도 답변 형식이 한 번도 안 깨지고, 근거 없는 질문은 지어내지 않고 no_evidence 로 분류됩니다
더미 평가셋에 심은 정답 조항 50건 중 상위 3개 검색 결과에 정답이 들어온 게 44건(약 88%)이고 생성 답의 인용 조항이 모두 검색 결과 안에 있었습니다. 단, 질문과 정답 조항을 모두 작성자가 만든 합성 기준이라 '성능 검증'이 아니라 '데모 조건에서의 동작'임을 명시합니다
진짜 성능 검증은 여기서 멈춥니다. 위 수치는 전부 작성자가 만든 더미 규격 문서·자작 평가셋 자가채점이며, 실제 검색 적중률과 답변 신뢰도는 서치독 고객사의 실 규격 문서와 실 현장 담당자 검수가 있어야 측정 가능합니다. 이 파이프라인은 그 검증을 바로 돌릴 수 있는 상태로 만듭니다
이건 고객·실 규격 문서 없이 혼자 만든 포트폴리오입니다. 모든 수치는 합성 문서·자작 평가셋 자가채점이라 성능 증명이 아닙니다. 면접에서는 실제 검색 동작과 실검증 준비 상태로 솔직히 설명합니다
질문과 정답 조항을 작성자가 만들었으니 잘 맞는 게 당연합니다. 어휘가 완전히 다른 동의어 질문·여러 조항을 조합해야 답이 되는 질문·정답 조항이 없는 질문·미등록 조항을 참조하는 질문 같은 경계 케이스를 평가셋에 일부러 섞어, 쉬운 검색만 통과시키는 게 아님을 보여줍니다
이 포트폴리오가 보여주는 것은 Retrieval·Indexing과 근거 기반 생성이라는 검색·생성형 AI FDE 기술입니다. 건축 구조·제조 공차 같은 규격 도메인 전문성은 포트폴리오로 증명되지 않으므로 주장하지 않으며, 그 깊이는 면접에서 모르면 모른다고 말하는 편이 낫습니다. 검색 적중과 근거 정합은 정답 조항 아이디 대조 같은 결정론 규칙으로만 판정합니다
더미 규격 문서는 실제 고객 도면·BIM 문서와 어휘 분포·표기 흔들림이 다릅니다. 실제 도입 시에는 고객 실 규격 문서로 인덱스와 평가셋을 다시 맞추고 검색 방식 가중치를 재조정해야 하며, 이 차이는 도입 단계 과제로 분리해 명시합니다
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
건축·제조 규격 조항 문서. 검색 인덱스가 올리는 원본 테이블입니다. 조항 본문·출처·표기 별칭을 담고, 본문 결측·미매핑 출처·같은 부재의 별칭 표기·category 경계 조항을 일부러 섞어 검색과 정규화가 쉽지 않게 만듭니다.
| clause_id | category | doc_source_raw | doc_source_id | title | body | aliases | keywords |
|---|---|---|---|---|---|---|---|
| cl_001 | arch_2d | 건축도면 표기 기준 | src_arch | 벽체 두께 표기 규칙 | 외벽 벽체는 도면에 공칭 두께를 밀리미터 단위로 표기하고 마감 두께는… | ["벽 두께","wall thickness"] | ["벽체","두께","표기","외벽"] |
| cl_002 | arch_2d | 건축도면 표기 기준 | src_arch | 치수선 최소 간격 | 치수선은 부재 외곽선에서 최소 8밀리미터 이상 떨어뜨려 배치하며 중복… | ["dimension line"] | ["치수선","간격","배치"] |
| cl_003 | bim_3d | BIM 부재 속성 가이드 | src_bim | 부재 분류 코드 부여 | 모든 BIM 부재는 분류 체계 코드를 속성으로 가지며 코드가 비면 미… | ["classification code","부재 코드"] | ["부재","분류","코드","속성"] |
| cl_004 | bim_3d | BIM 부재 속성 가이드 | src_bim | 간섭 검토 허용 오차 | — | ["clash detection","간섭체크"] | ["간섭","검토","허용오차"] |
| cl_005 | mfg_3d | 제조 3D 모델 규격 | src_mfg | 치수 공차 기본값 | 일반 치수 공차는 별도 지정이 없으면 정밀 등급을 따르고 도면에 등급… | ["tolerance","공차"] | ["공차","치수","등급"] |
아래 JSON Schema 에 맞는 건축·제조 규격 조항 문서 80행을 JSON 배열로 생성합니다. category(arch_2d·bim_3d·mfg_3d) 분포를 고루 섞고 각 category 안에서 서로 다른 표기·치수·속성 주제를 다양하게 만듭니다.
{"type":"object","properties":{"clause_id":{"type":"string"},"category":{"enum":["arch_2d","bim_3d","mfg_3d"]},"doc_source_raw":{"type":"string"},"doc_source_id":{"type":["string","null"]},"title":{"type":"string"},"body":{"type":["string","null"]},"aliases":{"type":"array","items":{"type":"string"}},"keywords":{"type":"array","items":{"type":"string"}}},"required":["clause_id","category","doc_source_raw","title","keywords"]}
쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라(쉬운 검색만 통과시키는 함정 회피): (1) 결측 body=null 인 조항 3건 이상(제목·키워드만 있어 본문 검색이 안 되는 조항), (2) 미매핑 doc_source_id=null 인 미등록 출처 3건, (3) 표기 흔들림 같은 출처의 별칭('건축도면 표기 기준'·'건축 도면 표기기준'·'건축도면 표기기준'처럼 정규화 필요) 여러 건과 조항의 aliases 에 한글·영문 동의어 병기, (4) 같은 주제를 category 경계에서 다루는 유사 조항 2건(검색 혼동 유발). clause_id 는 cl_ 접두로 유일하게. JSON 배열만.{"type":"object","properties":{"clause_id":{"type":"string"},"category":{"enum":["arch_2d","bim_3d","mfg_3d"]},"doc_source_raw":{"type":"string"},"doc_source_id":{"type":["string","null"]},"title":{"type":"string"},"body":{"type":["string","null"]},"aliases":{"type":"array","items":{"type":"string"}},"keywords":{"type":"array","items":{"type":"string"}}},"required":["clause_id","category","doc_source_raw","title","keywords"]}검색 평가셋. 질문마다 정답 조항 아이디를 심어 검색 적중과 근거 정합을 자가채점하는 테이블입니다. 정답 없는 질문·동의어만 다른 질문·미등록 조항 참조·조합 질문을 섞어 쉬운 검색만 통과하지 못하게 합니다.
| query_id | query_text | query_type | gold_clause_ids | expected_verdict | note |
|---|---|---|---|---|---|
| q_001 | 외벽 벽체 두께는 도면에 어떻게 표기하나요 | lexical | ["cl_001"] | answered | — |
| q_002 | 벽 두께 적는 규칙 알려줘 | semantic | ["cl_001"] | answered | 동의어 질문, 어휘 불일치 |
| q_003 | 치수선은 부재에서 얼마나 떨어뜨리나요 | lexical | ["cl_002"] | answered | — |
| q_004 | BIM 부재에 분류 코드가 없으면 어떻게 표시하나요 | lexical | ["cl_003"] | answered | — |
| q_005 | 간섭 검토 허용 오차 수치가 얼마인가요 | unanswerable | [] | no_evidence | cl_004 본문 결측이라 근거 없음 |
아래 JSON Schema 에 맞는 검색 평가 질문 80행을 JSON 배열로 생성합니다. query_type 분포를 lexical·semantic·multi_hop·unanswerable 로 고루 섞고 gold_clause_ids 는 spec_clauses 의 clause_id 를 참조합니다.
{"type":"object","properties":{"query_id":{"type":"string"},"query_text":{"type":"string"},"query_type":{"enum":["lexical","semantic","multi_hop","unanswerable"]},"gold_clause_ids":{"type":"array","items":{"type":"string"}},"expected_verdict":{"enum":["answered","no_evidence"]},"note":{"type":["string","null"]}},"required":["query_id","query_text","query_type","gold_clause_ids","expected_verdict"]}
expected_verdict 규칙: gold_clause_ids 가 비어 있으면 no_evidence, 하나 이상이면 answered. 쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라(쉬운 검색만 통과시키는 함정 회피): (1) 정답 없는 unanswerable 질문 8건 이상(gold 빈 배열, 지어내면 안 되는 함정), (2) 어휘가 완전히 다른 semantic 동의어 질문 다수(질문에 조항 본문 단어를 쓰지 않기), (3) 여러 조항을 조합해야 하는 multi_hop 6건 이상(gold 2개 이상), (4) 미등록 조항 아이디(예: cl_999)나 본문 결측 조항을 참조해 근거를 못 대는 질문 3건. note 에 함정 성격을 적어라. JSON 배열만.{"type":"object","properties":{"query_id":{"type":"string"},"query_text":{"type":"string"},"query_type":{"enum":["lexical","semantic","multi_hop","unanswerable"]},"gold_clause_ids":{"type":"array","items":{"type":"string"}},"expected_verdict":{"enum":["answered","no_evidence"]},"note":{"type":["string","null"]}},"required":["query_id","query_text","query_type","gold_clause_ids","expected_verdict"]}| Python | 문서 파싱·조항 분할·인덱싱·검색·평가 러너를 잇는 주 구현 언어입니다 |
| RAG | 검색으로 끌어온 규격 조항만 근거로 답을 생성하고, 검색 밖 내용은 답에 못 쓰게 막는 근거 기반 생성 골조입니다 |
| NLP | 조항 본문을 문장·키워드로 정규화하고 동의어·별칭 표기를 맞춰 어휘 검색 품질을 올립니다 |
| LLM | 검색된 조항을 근거로 질문에 답을 요약하고 인용 조항 아이디를 붙이는 생성 역할이며, 검색 적중 판정은 하지 않습니다 |
| Docker | 인덱스·검색 API·평가 러너를 컨테이너로 묶어 고객 현장과 같은 환경에서 재현 가능하게 만듭니다 |
| Linux | 컨테이너 베이스와 배포·평가 셸 스크립트가 도는 서버 환경입니다 |
| CI/CD | 평가셋을 커밋마다 자동 실행해 검색 적중·근거 정합이 회귀하면 잡아내는 파이프라인입니다 |
| BM25 | 조항 본문의 어휘 일치로 후보를 뽑는 렉시컬 검색 축입니다 |
| Vector 검색 | 질문과 조항을 임베딩해 어휘가 달라도 의미가 가까운 조항을 찾는 시맨틱 검색 축입니다 |
| Evaluation Set | 질문마다 정답 조항 아이디를 심어 검색 적중과 근거 정합을 자가채점하는 평가셋입니다 |
✓ pass → 그대로 멈춰도 완결입니다. 더 키우려면 2주차(어휘 검색과 의미 검색 비교)로 진행합니다.
✓ pass → 여기서 멈춰도 완결입니다. 더 키우면 3주차(질의 분해 Multi-Agent 확장)로 진행합니다.
질문 1건에 대한 검색·답변 결과. 검색된 조항과 점수, 답과 인용 조항 아이디, 근거 여부와 판정을 한 스키마로 담아 화면 카드에 씁니다. 근거를 못 찾으면 지어내지 않고 no_evidence 로 남기고, 인용 조항은 검색 결과 안에 있는 것만 허용합니다.
{"type":"object","properties":{"query_id":{"type":"string"},"retrieved":{"type":"array","items":{"type":"object","properties":{"clause_id":{"type":"string"},"score":{"type":"number"},"method":{"enum":["bm25","vector","hybrid"]}},"required":["clause_id","score","method"]}},"answer":{"type":["string","null"]},"citations":{"type":"array","items":{"type":"string"}},"grounded":{"type":"boolean"},"verdict":{"enum":["answered","no_evidence","ambiguous"]},"hedge":{"type":["string","null"]}},"required":["query_id","retrieved","citations","grounded","verdict"]}[
{
"input_ref": "q_002 (벽 두께 동의어 질문, gold cl_001)",
"output": {
"query_id": "q_002",
"retrieved": [
{
"clause_id": "cl_001",
"score": 0.81,
"method": "vector"
},
{
"clause_id": "cl_010",
"score": 0.42,
"method": "vector"
}
],
"answer": "외벽 벽체는 도면에 공칭 두께를 밀리미터로 표기하고 마감 두께는 괄호로 병기합니다.",
"citations": [
"cl_001"
],
"grounded": true,
"verdict": "answered",
"hedge": "더미 규격 문서 기준이며 실 고객 규격에서 재확인이 필요합니다"
}
},
{
"input_ref": "q_005 (간섭 허용 오차, cl_004 본문 결측)",
"output": {
"query_id": "q_005",
"retrieved": [
{
"clause_id": "cl_004",
"score": 0.55,
"method": "bm25"
}
],
"answer": null,
"citations": [],
"grounded": false,
"verdict": "no_evidence",
"hedge": "관련 조항 제목은 검색됐지만 본문 근거가 없어 수치를 지어내지 않고 근거 없음으로 답합니다"
}
},
{
"input_ref": "q_009 (벽체 두께 + 치수선 조합, gold cl_001·cl_002)",
"output": {
"query_id": "q_009",
"retrieved": [
{
"clause_id": "cl_001",
"score": 0.78,
"method": "hybrid"
},
{
"clause_id": "cl_002",
"score": 0.71,
"method": "hybrid"
}
],
"answer": "벽체 두께는 공칭 두께를 밀리미터로 표기하고 마감을 괄호로 병기하며, 치수선은 부재 외곽선에서 최소 8밀리미터 이상 떨어뜨려 배치합니다.",
"citations": [
"cl_001",
"cl_002"
],
"grounded": true,
"verdict": "answered",
"hedge": null
}
}
][자동 검증] 1. 출력이 스키마(필드·enum)를 통과하는지 확인합니다. 2. citations 가 모두 retrieved 의 clause_id 안에 있는지 봅니다(검색 밖 조항을 인용하면 근거 위반으로 grounded=false 처리). 3. verdict 를 결정론 규칙과 대조합니다. gold_clause_ids 가 상위 검색 결과에 들어오고 인용이 근거 안이면 answered, gold 가 비었는데 answer 를 냈으면 실패(지어냄), gold 가 비고 no_evidence 면 정답. 4. 심은 정답 expected_verdict·gold_clause_ids 와 비교해 상위 3개 검색 적중률과 근거 정합률을 계산하고, answer(LLM 생성) 문장은 판정에 넣지 않고 참고 텍스트로만 취급합니다. [수동 검증] 1. 검토자 2명이 비동기로 근거 정합(인용 조항이 질문에 실제로 답이 되는지)을 라벨링해 일치율과 bootstrap Cohen's κ(두 사람 일치가 우연 이상인 정도, 0~1) 하한 0.6 이상을 봅니다. 2. 전체 질문의 5% 를 사람이 직접 검색 결과와 대조해 인용 조항이 답을 실제로 뒷받침하는지 확인합니다.