핀커Forward Deployed Engineer
3.5 (49)핀커스코리아
경력근거: Knowledge Graph, Ontology, Text2SQL 등을 활용한 AI·검색 데이터 파이프라인 구축
60일 전 확인채용 공고 보기
※ 실제 산출물이 아닌 AI 예측 시안입니다.
공고가 주요업무에 'Knowledge Graph, Ontology, Text2SQL 등을 활용한 AI·검색 데이터 파이프라인 구축' 과 '고객사 현장 배포, QA, 안정화 및 서비스 성능 모니터링·운영 지원' 을 나란히 적었습니다. 현장에서 답이 틀리는 원인은 대개 모델이 아니라 근거로 들어간 문단이고, 이 포트폴리오는 그 채택 판단을 규칙표로 옮깁니다. 'LLM·RAG·NLP 기반 AI 솔루션 설계' 도 답을 만들기 전에 무엇을 근거로 쓸지 정하는 같은 자리를 가리킵니다. 이 포트폴리오가 보여주는 것은 채택 기준을 데이터로 두고 검색 결과와 맞춰 근거 여부를 가르는 기술이며, 지식그래프 설계나 고객사 도메인 전문성은 주장하지 않습니다. 모르는 깊이는 면접에서 모른다고 말하는 편이 낫습니다.
'고객사 비즈니스 요구사항 분석 및 LLM·RAG·NLP 기반 AI 솔루션 설계'. 답이 아니라 근거를 먼저 다룹니다.
'Knowledge Graph, Ontology, Text2SQL 등을 활용한 AI·검색 데이터 파이프라인 구축'. 검색 결과를 거르는 층이 그 파이프라인의 끝입니다.
'고객사 현장 배포, QA, 안정화 및 서비스 성능 모니터링·운영 지원'. 안정화 단계에서 근거 품질이 문제로 올라옵니다.
검색된 문단이 답변 근거로 쓸 만한지 가릅니다. 문서 유형별 채택 규칙에 최소 점수와 유효 개월, 절 이름 필요 여부를 두고 검색 결과와 맞춰, 기준을 넘으면 근거로 채택하고 그렇지 않으면 점수 미달·문서 만료·절 이름 없음 중 어느 쪽인지 사유로 남깁니다. 본문이 빈 문단은 점수가 높아도 인용할 문장이 없다고 표시하고, 규칙에 없는 문서 유형은 미등록으로 남겨 기준을 먼저 정하게 합니다. 검색 결과는 실 고객사 색인 대신 지원자가 공개 문서로 색인을 만들어 직접 질의한 것을 가정합니다.
고객사에 RAG 검색을 붙이고 답이 틀리는 이유를 찾는 자리에 앉는 FDE 입니다. 답이 이상하면 모델을 손보기 전에 어떤 문단이 근거로 들어갔는지를 매번 로그를 펼쳐 눈으로 훑던 사람입니다.
문서 유형마다 최소 점수와 유효 기간, 절 이름 필요 여부를 규칙으로 두고 검색 결과와 맞추면, 근거로 쓸 문단과 버릴 문단이 규칙으로 갈리고 버린 이유가 근거로 남는다는 가정입니다. 규칙에 없는 문서 유형은 미등록으로 빠지므로 기준이 아직 없는 원천이 그대로 드러납니다.
검색 결과와 채택 규칙표를 받아 문단마다 채택·버림을 판정하고, 버렸으면 점수 미달·문서 만료·절 이름 없음·본문 없음·미등록 중 어느 쪽인지 붙여 질의별로 묶은 판정 리포트를 터미널과 Markdown 파일로 내는 CLI 가 도는 완결품입니다.
공개 문서로 만든 색인에 질의 200건을 돌려 나온 문단에 손으로 붙인 정답 채택 여부와 대조해 일치율을 내고, 미등록이 몰리는 문서 유형을 모아 기준이 없는 원천을 목록으로 냅니다.
채택된 문단만 모아 인용을 붙인 답변 초안을 조립하고, 같은 질의에 서로 어긋나는 문단이 남으면 사람 확인으로 갈라 내는 단계입니다.
FDE 가 검색 결과와 채택 규칙표를 넣으면 문단마다 채택 여부와 버린 사유가 질의별로 묶여 나오는 과정을 시연합니다.
공개 문서 색인에 질의 200건을 돌려 나온 문단과 손으로 붙인 정답 채택을 대조해 일치율을 냅니다. 단, 정답과 색인을 모두 작성자가 만든 합성 기준이라 성능 검증이 아니라 데모 조건 동작입니다.
본문이 비었거나 유형 표기가 흔들리거나 규칙에 없는 유형이 섞인 입력 30종을 넣어도 출력 형식이 안 깨지고 사유별로 빠지는 비율을 보여줍니다.
임계와 유효 기간을 바꿨을 때 옛 판정이 어떻게 뒤집히는지 회귀로 확인합니다.
진짜 성능 검증은 여기서 멈춥니다. 위 수치는 작성자가 만든 색인의 자가채점이며, 실제 근거 품질은 핀커스코리아 고객사의 실 문서와 실 질의가 있어야 측정됩니다. 이 포트폴리오는 그 검증을 바로 돌릴 수 있는 상태까지 만듭니다.
수치는 합성 데이터 자가채점이라 성능 증명이 아니므로, 면접에서는 데모 동작과 실검증 준비 상태로 솔직히 설명합니다.
정답을 작성자가 붙였으니 잘 맞는 게 당연하므로, 만료 문서와 본문 결측, 규칙에 없는 유형을 일부러 섞어 쉬운 문단만 푸는 함정을 피합니다.
이 포트폴리오가 보여주는 것은 채택 기준을 데이터로 두고 검색 결과와 맞춰 근거 여부를 가르는 기술이며, 지식그래프 설계나 고객사 도메인 전문성은 주장하지 않습니다. 판정은 점수와 날짜 비교가 하고 LLM 은 담당자가 읽을 사유 문장만 맡습니다.
점수가 높다고 그 문단이 질문에 답한다는 뜻은 아니어서, 판정에 본문을 함께 실어 담당자가 한 번 더 읽게 둡니다.
실제 도입 때는 고객사마다 문서 유형과 갱신 주기가 다르므로, 규칙표를 새로 채우는 일을 도입 단계 과제로 둡니다.
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
질의마다 검색기가 돌려준 문단입니다. 문단 번호와 질의 번호, 문서 이름, 문서 유형 표기, 점수, 본문, 발행일, 절 이름을 한 행에 둡니다. 유형 표기는 색인마다 손으로 적어 'tech note'와 'technote'처럼 흔들립니다. 본문이 빈 행, 절 이름이 없는 행, 규칙표에 없는 유형을 일부러 섞어 두어 사유가 갈리게 둡니다.
| chunk_no | query_no | doc_raw | doc_type_raw | score | text | published_on | section_name |
|---|---|---|---|---|---|---|---|
| CK-1001 | Q-201 | 운영매뉴얼_v3 | manual | 0.88 | 설비 정지 시 담당자는 즉시 라인장에게 보고합니다. | 2026-03-01 | 2.1 정지 대응 |
| CK-1002 | Q-201 | 운영매뉴얼_v3 | manual | 0.61 | 라인장은 보고를 받은 뒤 조치 이력을 남깁니다. | 2026-03-01 | 2.2 이력 |
| CK-1003 | Q-202 | 사내규정_2023 | policy | 0.91 | 연차는 회계연도 기준으로 부여합니다. | 2023-01-10 | 제4조 |
| CK-1004 | Q-202 | 사내규정_2026 | policy | 0.86 | 연차는 입사일 기준으로 부여합니다. | 2026-01-05 | 제4조 |
| CK-1005 | Q-203 | 기술노트_임베딩 | tech note | 0.72 | 임베딩 차원은 1024 로 맞춥니다. | 2026-06-11 | — |
아래 JSON Schema 를 그대로 만족하는 검색 문단 행을 400개 더 만들어 주세요. 질의 하나에 문단 서넛을 붙이고 문서 유형을 여섯 종쯤 섞습니다. 유형 표기는 몇 행에서 'technote'처럼 띄어쓰기를 지워 흔들리게 두고, 2할은 본문이나 절 이름을 비우며, 몇 행은 발행일이 2~3년 지난 문서로 둡니다. 규칙표에 없는 유형도 몇 행 넣으세요. 채택 여부나 사유는 넣지 마세요.
{"type": "object", "properties": {"chunk_no": {"type": "string"}, "query_no": {"type": "string"}, "doc_raw": {"type": "string"}, "doc_type_raw": {"type": "string"}, "score": {"type": "number"}, "text": {"type": ["string", "null"]}, "published_on": {"type": ["string", "null"]}, "section_name": {"type": ["string", "null"]}}, "required": ["chunk_no", "query_no", "doc_raw", "doc_type_raw", "score", "text"]}{"type": "object", "properties": {"chunk_no": {"type": "string"}, "query_no": {"type": "string"}, "doc_raw": {"type": "string"}, "doc_type_raw": {"type": "string"}, "score": {"type": "number"}, "text": {"type": ["string", "null"]}, "published_on": {"type": ["string", "null"]}, "section_name": {"type": ["string", "null"]}}, "required": ["chunk_no", "query_no", "doc_raw", "doc_type_raw", "score", "text"]}문서 유형별 채택 규칙표입니다. 유형 표기와 최소 점수, 유효 개월, 절 이름 필요 여부, 담당을 한 행에 둡니다. 유형마다 기준이 달라 같은 점수도 어떤 문서에서는 채택되고 어떤 문서에서는 버려집니다. 검색 결과에 나오는 유형 중 일부는 일부러 넣지 않아 미등록이 도출되게 둡니다.
| rule_no | doc_type_raw | min_score | valid_months | require_section | owner_name |
|---|---|---|---|---|---|
| GR-1001 | manual | 0.7 | 24 | true | 운영팀 |
| GR-1002 | policy | 0.8 | 12 | true | 경영지원 |
| GR-1003 | tech note | 0.65 | 18 | false | 플랫폼 |
| GR-1004 | proposal | 0.75 | 12 | true | 영업 |
| GR-1005 | wiki | 0.7 | 12 | true | 플랫폼 |
아래 JSON Schema 를 그대로 만족하는 채택 규칙 행을 30개 더 만들어 주세요. 문서 유형마다 최소 점수와 유효 개월을 성격에 맞게 다르게 두고 절 이름 필요 여부를 참·거짓으로 섞습니다. 검색 결과에 나오는 유형 중 일부는 일부러 넣지 마세요 — 미등록이 있어야 규칙표의 구멍이 드러납니다. 판정 결과는 넣지 마세요.
{"type": "object", "properties": {"rule_no": {"type": "string"}, "doc_type_raw": {"type": "string"}, "min_score": {"type": "number"}, "valid_months": {"type": ["integer", "null"]}, "require_section": {"type": "boolean"}, "owner_name": {"type": "string"}}, "required": ["rule_no", "doc_type_raw", "min_score", "require_section", "owner_name"]}{"type": "object", "properties": {"rule_no": {"type": "string"}, "doc_type_raw": {"type": "string"}, "min_score": {"type": "number"}, "valid_months": {"type": ["integer", "null"]}, "require_section": {"type": "boolean"}, "owner_name": {"type": "string"}}, "required": ["rule_no", "doc_type_raw", "min_score", "require_section", "owner_name"]}| Python | 검색 결과와 채택 규칙을 맞춰 점수와 경과 개월을 견주는 판정기를 맡습니다. |
| Elasticsearch | 공개 문서 색인과 질의 실행에 씁니다. 채택 판정은 색인 엔진에 기대지 않습니다. |
| TypeScript | 판정 결과를 팀이 볼 수 있게 내보내는 리포트 변환기를 맡습니다. |
| Markdown | 질의별로 묶은 판정 리포트를 파일로 냅니다. |
✗ fail → 미등록이 절반을 넘으면 규칙표를 먼저 채웁니다.
✓ pass → 2주차 정답 대조로 넘어갑니다.
✗ fail → 어긋난 유형을 모아 임계와 유효 기간을 다시 봅니다.
✓ pass → 3주차 답변 초안으로 넘어갑니다.
문단 하나와 채택 규칙이 만나는 자리마다 답변 근거로 쓸지 정합니다. 버리면 점수 미달·문서 만료·절 이름 없음·본문 없음·미등록 중 어느 쪽인지 싣습니다. 화면과 리포트는 이 사유 코드로 묶습니다.
{"type": "object", "properties": {"verdict_no": {"type": "string"}, "chunk_no": {"type": "string"}, "query_no": {"type": "string"}, "doc_type_raw": {"type": "string"}, "rule_no": {"type": ["string", "null"]}, "ground_code": {"type": "string", "enum": ["usable", "score_low", "doc_expired", "section_missing", "text_missing", "doc_type_unmapped"]}, "age_months": {"type": ["integer", "null"], "description": "published_on 에서 오늘까지의 개월 수입니다. 발행일이 없으면 비웁니다."}, "min_score": {"type": ["number", "null"]}, "owner_name": {"type": ["string", "null"]}, "evidence": {"type": "array", "items": {"type": "object", "properties": {"field": {"type": "string"}, "agg": {"type": ["string", "null"]}, "value": {}}, "required": ["field", "value"]}}, "summary": {"type": "string"}, "hedge": {"type": ["string", "null"]}}, "required": ["verdict_no", "chunk_no", "query_no", "doc_type_raw", "ground_code", "evidence", "summary"]}[
{
"verdict_no": "GV-001",
"chunk_no": "CK-1001",
"query_no": "Q-201",
"doc_type_raw": "manual",
"rule_no": "GR-1001",
"ground_code": "usable",
"age_months": 5,
"min_score": 0.7,
"owner_name": "운영팀",
"evidence": [
{
"field": "score",
"agg": null,
"value": 0.88
},
{
"field": "min_score",
"agg": null,
"value": 0.7
}
],
"summary": "점수가 기준을 넘고 절 이름도 붙어 있어 답변 근거로 씁니다.",
"hedge": null
},
{
"verdict_no": "GV-002",
"chunk_no": "CK-1009",
"query_no": "Q-205",
"doc_type_raw": "wiki",
"rule_no": "GR-1005",
"ground_code": "usable",
"age_months": 1,
"min_score": 0.7,
"owner_name": "플랫폼",
"evidence": [
{
"field": "score",
"agg": null,
"value": 0.9
},
{
"field": "section_name",
"agg": null,
"value": "배포 창"
}
],
"summary": "발행이 최근이고 절 이름이 있어 배포 규칙의 근거로 씁니다.",
"hedge": "같은 질의의 채팅 덤프와 내용이 어긋나 사람이 한 번 봅니다."
},
{
"verdict_no": "GV-003",
"chunk_no": "CK-1011",
"query_no": "Q-206",
"doc_type_raw": "manual",
"rule_no": "GR-1001",
"ground_code": "score_low",
"age_months": 5,
"min_score": 0.7,
"owner_name": "운영팀",
"evidence": [
{
"field": "score",
"agg": null,
"value": 0.47
},
{
"field": "min_score",
"agg": null,
"value": 0.7
}
],
"summary": "점수 0.47 이 기준 0.70 에 못 미쳐 근거로 쓰지 않습니다.",
"hedge": null
},
{
"verdict_no": "GV-004",
"chunk_no": "CK-1003",
"query_no": "Q-202",
"doc_type_raw": "policy",
"rule_no": "GR-1002",
"ground_code": "doc_expired",
"age_months": 43,
"min_score": 0.8,
"owner_name": "경영지원",
"evidence": [
{
"field": "published_on",
"agg": null,
"value": "2023-01-10"
},
{
"field": "valid_months",
"agg": null,
"value": 12
}
],
"summary": "2023년 규정이라 유효 12개월을 한참 넘겨 최신 규정과 답이 갈립니다.",
"hedge": null
},
{
"verdict_no": "GV-005",
"chunk_no": "CK-1005",
"query_no": "Q-203",
"doc_type_raw": "tech note",
"rule_no": "GR-1003",
"ground_code": "usable",
"age_months": 2,
"min_score": 0.65,
"owner_name": "플랫폼",
"evidence": [
{
"field": "score",
"agg": null,
"value": 0.72
},
{
"field": "require_section",
"agg": null,
"value": false
}
],
"summary": "기술노트는 절 이름을 요구하지 않아 점수만으로 근거가 됩니다.",
"hedge": "'technote' 표기 행과 같은 문서라 접어서 한 규칙으로 봤습니다."
},
{
"verdict_no": "GV-006",
"chunk_no": "CK-1007",
"query_no": "Q-204",
"doc_type_raw": "meeting",
"rule_no": "GR-1006",
"ground_code": "text_missing",
"age_months": 0,
"min_score": 0.75,
"owner_name": "운영팀",
"evidence": [
{
"field": "text",
"agg": null,
"value": null
},
{
"field": "score",
"agg": null,
"value": 0.79
}
],
"summary": "점수는 높은데 본문이 비어 인용할 문장이 없습니다.",
"hedge": null
},
{
"verdict_no": "GV-007",
"chunk_no": "CK-1010",
"query_no": "Q-205",
"doc_type_raw": "chat",
"rule_no": null,
"ground_code": "doc_type_unmapped",
"age_months": 0,
"min_score": null,
"owner_name": null,
"evidence": [
{
"field": "doc_type_raw",
"agg": null,
"value": "chat"
},
{
"field": "rule_no",
"agg": "count",
"value": 12
}
],
"summary": "채택 규칙 열두 행에 채팅 유형이 없어 근거로 쓸지 정하지 못합니다.",
"hedge": null
}
][자동 검증 · 코드가 판정합니다] 1. ground_code 가 enum 여섯 값 중 하나인지 확인합니다. 2. verdict_no·chunk_no·query_no·doc_type_raw·ground_code·evidence·summary 가 모두 채워졌는지 확인합니다. 3. chunk_no 가 검색 결과에 실재하는 번호인지 대조합니다. 4. rule_no 가 있으면 규칙표에 실재하는 행 번호인지 대조합니다. 5. rule_no 가 있으면 min_score·owner_name 이 그 규칙 행의 값과 같은지 대조합니다. 6. doc_type_raw 를 공백을 지워 접은 뒤 규칙표의 유형과 맞고, 맞는 행이 없으면 ground_code 가 doc_type_unmapped 인지 확인합니다. 7. age_months 를 published_on 에서 오늘까지의 개월 수로 다시 계산합니다. 8. ground_code 가 usable 이면 score 가 min_score 이상이고 age_months 가 valid_months 이하인지 다시 확인합니다. 9. ground_code 가 score_low 이면 score 가 min_score 에 못 미치는지 다시 확인합니다. 10. ground_code 가 doc_expired 이면 age_months 가 valid_months 를 넘는지 다시 계산합니다. 11. require_section 이 참인데 section_name 이 비어 있으면 ground_code 가 section_missing 인지 확인합니다. 12. text 가 비어 있으면 ground_code 가 text_missing 인지 확인합니다. 13. evidence 의 field 이름이 검색 결과와 규칙표에 실재하는 컬럼인지 대조합니다. 14. agg 가 없는 evidence 의 value 가 그 컬럼에 수록된 행 값과 같은지 확인합니다. 15. summary 가 존댓말로 끝나는지 확인합니다. [평가 러너 · 2주차] 공개 문서 색인에 질의 200건을 돌려 나온 문단에 손으로 붙인 정답 채택과 대조해 일치율과 사유 코드별 분포를 내고, 미등록이 몰리는 문서 유형을 모아 기준이 없는 원천을 목록으로 냅니다. [수동 검증 · 사람이 봅니다] 1. 유형별 최소 점수를 어디로 정할지 담당 조직이 정합니다. 2. 같은 질의에 서로 어긋나는 문단이 남으면 어느 쪽을 쓸지 담당자가 정합니다.