휴먼
2.3 (11)휴먼링크
경력근거: 고객사에 임베딩되어 현장의 모호한 비즈니스 문제를 직접 듣고, 함께 정의·구조화
수집일 없음
※ 실제 산출물이 아닌 AI 예측 시안입니다.
휴먼링크의 FDE 는 고객사에 임베딩되어 모호한 문제를 정의·구조화하고 LLM·RAG 로 제품을 환경에 맞게 구현합니다. 고객사마다 도메인이 바뀌는 FDE 특성상, 특정 도메인 전문성보다 '어떤 문서든 근거 기반으로 답하는' 도메인 무관 RAG 역량이 핵심입니다. 이 어시스턴트는 그 핵심 능력(근거 인용 RAG·근거 검증·근거 없는 답 차단)을 정면으로 다루되 한 사람이 1~3주에 만들 수 있는 적정 범위로 잡았고, 도메인 전문성은 주장하지 않습니다. 문서 신호를 인용 근거와 강등 규칙으로 잇는 사슬은 단순 검색 맥락으로는 그대로 만들 수 없습니다.
고객사에 임베딩되어 현장의 모호한 문제를 정의·구조화하고 제품을 환경에 맞게 통합하는 FDE 입니다. 도메인 무관 RAG 어시스턴트가 직접 정렬됩니다.
LLM·RAG 로 AI 시스템을 빠르게 프로토타입해 현장에 적용합니다. 근거 인용 답변 엔진이 환경과 정렬됩니다.
기술만이 아니라 비즈니스 관점에서 고객 문제를 함께 고민하고 협업합니다. RAG 어시스턴트가 비즈니스와 정렬됩니다.
고객사 문서(문서·문서군·청크·출처·갱신일)를 청크로 적재해 질문에 답하되, 답이 인용한 청크가 실제로 그 답을 뒷받침하는지 점검해 근거 없으면 답을 강등합니다. 규칙(근거 없음·인용 청크와 답 불일치·저신뢰·결측)으로 점검이 필요한 답을 잡고, 원인을 LLM 이 인용 근거를 들어 풀어줍니다. 문서군·출처 마스터를 붙여 표기를 정규화합니다. 정답은 인용 청크 일치로 결정하고 LLM 은 검색·요약을 맡습니다.
휴먼링크 FDE 가 고객사 현장에서 쓰는 어시스턴트의 사용자는 그 고객사 실무자입니다. 흩어진 문서에서 답을 찾을 때 어느 답에 근거가 있는지 매번 원문을 뒤지던 일을, 한 화면에서 답과 인용 근거·근거 없는 답을 함께 보고 싶은 사람입니다.
고객사 문서를 청크로 적재하고 문서군·출처 마스터를 붙이면, (a) 답이 인용 청크로 뒷받침되는지·근거 없는지를 규칙으로 잡고, (b) 원인을 LLM 이 인용 근거를 들어 풀며, (c) 도메인이 바뀐 새 고객사 문서에도 같은 파이프라인으로 답합니다.
고객사 문서를 청크로 적재해 질문에 인용 근거와 함께 답하고, 인용 청크가 답을 뒷받침하지 못하면 답을 강등하는 동작하는 어시스턴트입니다. 데이터는 고객사 문서를 가정한 더미로 시작합니다.
답이 인용 청크로 뒷받침되는지를 정답 출처와 비교하고, 검토자 2명이 라벨링해 정답률·근거 충실도와 일치도를 보여주는 화면입니다.
문서군·출처별 근거 충실도와 근거 없는 답 비율을 누적 집계해 약점을 보여주는 화면입니다.
질문 시나리오 12종을 넣으면, 인용 근거와 함께 답이 몇 초 안에 나오고 근거 없는 질문은 답을 막는 걸 시연합니다
일부러 만든 악성·결측 입력 30종(출처 null·미등록 문서군·문서군 표기 흔들림)을 넣어도 출력 형식(스키마)이 한 번도 안 깨집니다
내가 만든 정답 40건 중 인용 청크가 답을 뒷받침하는지 판정이 일치한 게 35건(약 88%)입니다. 단, 정답·데이터를 모두 작성자가 만든 합성 기준이라 '성능 검증'이 아니라 '데모 조건에서의 동작'임을 명시합니다
진짜 성능 검증은 여기서 멈춥니다. 위 수치는 전부 작성자가 만든 더미데이터 자가채점이며, 실제 정답률은 휴먼링크가 들어갈 실 고객사 문서와 실 검토자가 있어야 측정 가능합니다. 이 도구는 그 검증을 바로 돌릴 수 있는 상태까지 만듭니다
수치는 합성 데이터 자가채점이라 성능 증명이 아닙니다. 면접에서는 데모 동작과 실검증 준비 상태로 솔직히 설명합니다
이 포트폴리오는 근거 인용 RAG 와 근거 검증 기술을 보여줍니다. FDE 는 고객사마다 도메인이 바뀌므로 특정 도메인 전문성을 주장하지 않고, 어떤 문서든 근거 기반으로 답하는 도메인 무관 파이프라인으로 잡았습니다. 모르는 도메인 깊이는 면접에서 모른다고 말하는 편이 낫습니다
정답을 작성자가 만들었으니 잘 맞는 것이 당연합니다. 출처 누락·미등록 문서군·인용 경계 같은 결측·경계 케이스를 더미에 일부러 섞어, 쉬운 질문만 푸는 게 아님을 보여줍니다
RAG 답은 그럴듯해도 근거가 없을 수 있습니다. 답은 인용 청크 id 를 달게 하고, 그 청크가 답을 뒷받침하지 못하면 '근거 없음'으로 강등하며 단정하지 않습니다
문서군·출처 표기가 제각각입니다. 정규화로 같은 문서군으로 묶고, 못 묶은 건 추측하지 말고 '미매핑'으로 알립니다. 실제 도입 시 고객사 문서 체계·용어가 더미와 다르므로 문서군 마스터와 청킹을 다시 맞춰야 합니다(도입 단계 과제로 분리)
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
고객사 문서 청크 로그. 근거 점검·RAG 답변이 가장 먼저 질의하는 테이블입니다. 출처 결측·미등록 문서군·문서군 표기 흔들림·인용 경계를 일부러 섞어, 쉬운 질문만 푸는 게 아님을 보여줍니다.
| chunk_id | docgroup_raw | docgroup_id | source | claim | supports_topic | confidence | ts |
|---|---|---|---|---|---|---|---|
| ck_001 | 계약서 | dg_contract | 계약서_v3.pdf#p2 | 계약 해지 통보는 30일 전에 한다 | 해지통보기한 | 0.95 | 2026-03-04T09:00 |
| ck_002 | 계약 서 | dg_contract | — | 해지 관련 일반 안내 | 해지통보기한 | 0.4 | 2026-03-05T09:00 |
| ck_003 | 운영 매뉴얼 | dg_manual | 운영매뉴얼.docx#3 | 장애 1차 대응은 운영팀이 맡는다 | 장애대응주체 | 0.9 | 2026-03-04T10:00 |
| ck_004 | 운영 매뉴얼 | dg_manual | — | 장애 관련 문구 | 장애대응주체 | — | 2026-03-04T11:00 |
| ck_005 | 신규문서군X | — | 기타.txt#1 | 정산은 월말에 한다 | 정산주기 | 0.88 | 2026-03-04T12:00 |
아래 Zod 스키마에 맞는 고객사 문서 청크 60행 JSON 배열로 생성합니다. 문서군 4~6개, 토픽(supports_topic) 다수, 정상 위주에 근거 점검 필요 청크를 섞습니다. confidence 는 0~1.
{"type":"object","properties":{"chunk_id":{"type":"string"},"docgroup_raw":{"type":"string"},"docgroup_id":{"type":["string","null"]},"source":{"type":["string","null"]},"claim":{"type":"string"},"supports_topic":{"type":"string"},"confidence":{"type":["number","null"]},"ts":{"type":"string"}},"required":["chunk_id","docgroup_raw","docgroup_id","source","claim","supports_topic","confidence","ts"]}
쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라(쉬운 질문만 푸는 함정 회피): (1) 같은 문서군의 표기 별칭('계약서'/'계약 서', '운영 매뉴얼'/'운영매뉴얼'처럼 docgroup_master 로 정규화돼야 함) 3건 이상, (2) 미등록 문서군(docgroup_id=null) 2건, (3) 결측: source/confidence 가 null 인 행 각 1~2건, (4) 인용 경계 — 같은 supports_topic 인데 출처 없는 일반 문구(claim 이 토픽을 실제로 뒷받침 못함) 2건, 저신뢰(confidence 0.4~0.55) 2건, (5) 한 토픽에 뒷받침 청크와 비뒷받침 청크가 섞인 케이스 2~3건. JSON 배열만.{"type":"object","properties":{"chunk_id":{"type":"string"},"docgroup_raw":{"type":"string"},"docgroup_id":{"type":["string","null"]},"source":{"type":["string","null"]},"claim":{"type":"string"},"supports_topic":{"type":"string"},"confidence":{"type":["number","null"]},"ts":{"type":"string"}},"required":["chunk_id","docgroup_raw","docgroup_id","source","claim","supports_topic","confidence","ts"]}| RAG | 고객사 문서 청크를 검색해 답변 근거로 인용하는 핵심 엔진입니다 |
| LLM | 질문에 맞는 청크를 검색·요약해 답을 만들고 근거 없는 답을 가려냅니다 |
| TypeScript | 적재·청킹·근거 점검 규칙·출력 스키마(Zod) 구현 언어입니다 |
| Zod | 문서 입력과 LLM 출력(답·인용)의 런타임 형식 검증입니다 |
| 임베딩 검색 | 청크를 벡터로 색인해 질문과 가까운 근거를 찾습니다 |
| Claude | 근거 인용 답변·점검 원인 설명 LLM 입니다 |
✓ pass → 그대로 멈춰도 완결입니다. 더 키우려면 2주차(답이 맞았는지 확인)로 진행합니다.
✓ pass → 여기서 멈춰도 완결입니다. 더 키우면 3주차(문서군별 답변 신뢰도 추이)로 진행합니다.
질문 1건의 답변 카드. 답·인용 청크·근거 충실 여부를 한 스키마로 담아 화면에 씁니다. 정답 여부는 인용 청크 일치로 결정하고 LLM 은 검색·요약을 맡습니다.
{"type":"object","properties":{"question":{"type":"string"},"answer":{"type":"string","minLength":2},"cited_chunk":{"type":["string","null"]},"status":{"type":"string","enum":["grounded","weak","ungrounded","unanswerable"]},"factors":{"type":"array","items":{"type":"string","enum":["grounded_ok","cite_mismatch","low_confidence","unmapped_docgroup","missing_source"]}},"reason":{"type":"string","minLength":20},"evidence":{"type":"string","minLength":8},"hedge":{"type":["string","null"]}},"required":["question","answer","cited_chunk","status","factors","reason","evidence","hedge"]}[
{
"input_ref": "Q: 계약 해지 통보는 며칠 전에? (근거 충실)",
"output": {
"question": "계약 해지 통보는 며칠 전에 해야 하나요?",
"answer": "30일 전",
"cited_chunk": "ck_001",
"status": "grounded",
"factors": [
"grounded_ok"
],
"reason": "해지통보기한 토픽을 뒷받침하는 계약서 청크가 30일을 명시하고 출처도 있어 근거 충실로 답합니다.",
"evidence": "cited_chunk=ck_001, source=계약서_v3.pdf#p2",
"hedge": null
}
},
{
"input_ref": "Q: 장애 1차 대응 주체는? (인용 청크 결측·근거 부족)",
"output": {
"question": "장애 1차 대응 주체는 누구인가요?",
"answer": "운영팀(근거 확인 필요)",
"cited_chunk": "ck_004",
"status": "ungrounded",
"factors": [
"cite_mismatch",
"missing_source"
],
"reason": "검색된 청크가 출처 없는 일반 문구라 1차 대응 주체를 뒷받침하지 못합니다. 출처 있는 매뉴얼 청크 재검색이 필요합니다.",
"evidence": "cited_chunk=ck_004, source=null, supports_topic=장애대응주체",
"hedge": "인용 청크가 답을 뒷받침 못해 근거 없음으로 강등합니다"
}
},
{
"input_ref": "Q: 신규 문서군의 정산 주기는? (미등록 문서군)",
"output": {
"question": "정산 주기는 어떻게 되나요?",
"answer": "월말(미등록 문서군)",
"cited_chunk": "ck_005",
"status": "weak",
"factors": [
"unmapped_docgroup"
],
"reason": "문서군이 마스터에 없어 신뢰를 단정하지 않습니다. 문서군 등록 후 재색인·재질의가 필요합니다.",
"evidence": "cited_chunk=ck_005, docgroup_id=null",
"hedge": "미등록 문서군이라 근거 충실도를 단정하지 않습니다"
}
}
][자동 검증] 1. Zod parse 로 출력 형식(필드·enum)이 스키마를 통과하는지 확인합니다. 2. status 가 인용 청크 일치 규칙과 맞는지 봅니다(인용 청크의 supports_topic·출처·신뢰도로 결정). 3. cited_chunk 가 실제 존재하는 청크 id 인지·evidence 가 그 값 인용인지 토큰 매칭으로 확인합니다. 4. 출처 결측·미등록 문서군·인용 불일치면 ungrounded/weak 로 강등하고 단정을 막습니다. [수동 검증] 1. 검토자 2명이 비동기로 답·근거를 라벨링해 정답률·근거 충실도와 bootstrap Cohen's κ(두 사람 일치가 우연 이상인 정도, 0~1) 하한 0.6 이상을 봅니다. 2. 전체의 5% 를 사람이 직접 점검합니다.
근거: 고객사에 임베딩되어 현장의 모호한 비즈니스 문제를 직접 듣고, 함께 정의·구조화