마키나락스 FDE(LLM)는 제조·산업 데이터에 LLM/VLM·RAG·Fine-tuning·Agent 를 적용하고, LLM 시스템의 성능 모니터링·평가 지표 설계·품질 개선 사이클을 운영하며 실적용 성공 사례를 늘립니다. RAG 답변을 근거·평가 지표로 채점해 개선 큐로 돌리는 이 게이트는 그 핵심(평가 지표 설계·품질 개선 사이클·RAG 근거 검증) 기술을 정면으로 입증합니다. 제조·설비 도메인 전문성은 포트폴리오로 증명되지 않으므로 일반 문서로 기술만 보이고 그 깊이는 면접에서 솔직히 다룹니다. 답변 신호를 채점 규칙·개선 루프로 잇는 사슬은 단순 RAG 호출 맥락으로는 그대로 만들 수 없습니다.
제조·산업 데이터(설비 로그·이미지·문서)를 기반으로 LLM/VLM 지능형 분석·자동화 시스템을 개발합니다. RAG 답변 평가가 직접 정렬됩니다.
LLM 기반 시스템의 성능 모니터링·평가 지표 설계·품질 개선 사이클을 운영합니다. 개선 큐가 환경과 정렬됩니다.
LLM/VLM 으로 실제 사용 가능한 제품을 개발·배포·운영합니다. 평가 파이프라인이 실적용과 정렬됩니다.
산업 문서 RAG 답변(질문·답·인용 근거·평가 점수)을 받아, 규칙(원문 미근거·형식 위반·저평가·결측)으로 통과할지 개선 큐로 보낼지 반려할지 정합니다. 정답 여부는 원문 근거 인용과 평가 지표 임계로 결정하고, LLM 은 답변 생성·채점 보조만 맡습니다. 답변의 의미적 완벽함 판정이 아니라 품질 게이트·개선 라우팅입니다.
마키나락스 FDE(LLM). RAG 답변을 일일이 원문과 대조해 쓸지 고칠지 판단하고 저품질을 골라 개선하던 일을, 한 게이트에서 답·근거·평가 점수를 함께 보고 개선 큐로 돌리고 싶은 사람입니다.
RAG 답변을 한 스키마로 묶고 평가 지표를 붙이면, (a) 원문 미근거·형식 위반·저평가를 규칙으로 거르고, (b) 채점 근거를 원문 인용으로 풀며, (c) 여러 문서 도메인의 답변을 끊김 없이 채점하고 개선 큐로 돌립니다.
RAG 답변을 받아 원문 근거·형식·평가 점수를 검사해 통과·개선·반려를 정하고 저품질을 개선 큐로 보내는 동작하는 게이트입니다. 문서·답변은 일반 문서 더미로 시작합니다.
채점 판정을 심은 정답·검토자 2명 라벨과 비교해 정밀도·재현율과 일치도를 보여주는 화면입니다.
문서 도메인별 답변 품질과 반려 사유 분포를 누적 집계해 약한 도메인을 보여주는 화면입니다.
채점 시나리오 12종(정상·미근거·형식 위반)을 넣으면, 답변·근거·평가 결과가 몇 초 안에 나오는 걸 시연합니다
일부러 만든 악성·결측 입력 30종(평가 점수 null·미등록 도메인·문서 표기 흔들림)을 넣어도 출력 형식(스키마)이 한 번도 안 깨집니다
더미에 심은 정답 40건 중 통과/반려 판정이 일치한 게 35건(약 88%)입니다. 단, 정답·데이터를 모두 작성자가 만든 합성 기준이라 '성능 검증'이 아니라 '데모 조건에서의 동작'임을 명시합니다
진짜 성능 검증은 여기서 멈춥니다. 위 수치는 전부 작성자가 만든 더미데이터 자가채점이며, 실제 정밀도·재현율은 마키나락스의 실 산업 문서와 실 검토자가 있어야 측정 가능합니다. 이 게이트는 그 검증을 바로 돌릴 수 있는 상태까지 만듭니다
이건 고객·실데이터 없이 혼자 만든 포트폴리오입니다. 모든 수치는 합성 데이터 자가채점이라 성능 증명이 아닙니다. 면접에서는 데모 동작과 실검증 준비 상태로 솔직히 설명하는 게 오히려 신뢰를 줍니다
이 포트폴리오가 입증하는 것은 RAG 답변 채점 규칙 + 근거 검증 + 품질 개선 큐 기술입니다. 제조·설비 같은 산업 도메인 전문성은 포트폴리오로 증명되지 않으므로 주장하지 않고 일반 문서로 기술만 보이며, 그 깊이는 면접에서 모르면 모른다고 말하는 편이 낫습니다
정답을 작성자가 만들었으니 잘 맞는 게 당연합니다. 그래서 평가 점수 결측·미등록 도메인·문서 표기 흔들림 같은 경계 케이스를 더미에 일부러 섞어, 쉬운 채점만 통과시키는 게 아님을 보여줍니다
LLM 답변은 그럴듯해도 원문에 없을 수 있습니다. 답변마다 원문 인용을 달게 하고, 근거가 없으면 '미근거'로 반려해 통과시키지 않습니다
문서·도메인 표기가 제각각입니다. 정규화로 같은 도메인으로 묶고, 못 묶은 건 추측하지 말고 '미매핑'으로 알립니다. 실제 도입 시 평가 지표·임계가 더미와 다르므로 규칙을 다시 맞춰야 합니다(도입 단계 과제로 분리)
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
산업 문서 RAG 답변 채점 로그. 채점 규칙이 가장 먼저 질의하는 테이블입니다. 평가 점수 결측·미등록 도메인·문서 표기 흔들림을 일부러 섞고, label 로 정답을 심어 자가채점합니다.
| ans_id | domain_raw | domain_id | grounded | schema_ok | eval_score | label | ts |
|---|---|---|---|---|---|---|---|
| ra_001 | 설비매뉴얼 | manual | true | true | 0.91 | pass | 2026-03-04T09:00 |
| ra_002 | 설비매뉴얼 | manual | false | true | 0.5 | reject | 2026-03-04T10:00 |
| ra_003 | 품질리포트 | quality | true | false | 0.7 | reject | 2026-03-04T11:00 |
| ra_004 | 품 질리포트 | quality | true | true | 0.55 | improve | 2026-03-04T12:00 |
| ra_005 | 신규문서X | — | true | true | 0.85 | improve | 2026-03-04T13:00 |
아래 Zod 스키마에 맞는 RAG 답변 채점 60행 JSON 배열로 생성합니다. 문서 도메인 2~3개, 정상 위주에 개선·반려를 섞습니다. label 규칙: grounded=false 또는 schema_ok=false → reject, eval_score<0.7(단, >=0.5) 또는 domain_id=null 또는 eval_score=null → improve, 그 외(근거·형식 정상 & eval>=0.7... 단 0.85 미만 미등록도메인은 improve) → pass.
z.object({ ans_id: z.string(), domain_raw: z.string(), domain_id: z.string().nullable(), grounded: z.boolean(), schema_ok: z.boolean(), eval_score: z.number().nullable(), label: z.enum(["pass","improve","reject"]), ts: z.string() })
쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라(쉬운 채점만 통과시키는 함정 회피): (1) 같은 도메인의 표기 별칭('설비매뉴얼'/'설 비매뉴얼', '품질리포트'/'품 질리포트'처럼 domain_master 로 정규화돼야 함) 3건 이상, (2) 미등록 도메인(domain_id=null) 2건, (3) 결측: eval_score 가 null 인 행 1~2건, (4) 경계값 — 원문 미근거(grounded=false)·형식 위반(schema_ok=false) 각 2건, (5) 중간 평가(eval_score 0.5~0.6) 개선 케이스 2~3건. label 은 위 규칙대로 정직하게. JSON 배열만.z.object({ ans_id: z.string(), domain_raw: z.string(), domain_id: z.string().nullable(), grounded: z.boolean(), schema_ok: z.boolean(), eval_score: z.number().nullable(), label: z.enum(["pass","improve","reject"]), ts: z.string() })| LLM | 산업 문서 질문에 답하고 근거를 인용하는 RAG 답변 엔진입니다 |
| RAG | 문서 청크를 검색해 답변 근거로 인용하는 핵심 구조입니다 |
| VLM | 이미지·도면 문서가 섞일 때 답변 근거 추출을 가정한 보조입니다 |
| Python | 답변 파서·채점 규칙·평가 지표 계산의 구현 언어입니다 |
| MLOps | 개선 큐·평가 로그 적재를 운영 파이프라인으로 가정합니다 |
| Claude | 답변 생성·채점 보조 LLM(판정은 규칙)입니다 |
✓ pass → 그대로 멈춰도 완결입니다. 더 키우려면 2주차(채점이 맞았는지 확인)로 진행합니다.
✓ pass → 여기서 멈춰도 완결입니다. 더 키우면 3주차(문서 도메인별 품질 추이)로 진행합니다.
RAG 답변 1건의 채점 카드. 결정·요인·근거를 한 스키마로 담아 화면 카드에 씁니다. 의미적 완벽함이 아니라 품질 게이트·개선 라우팅입니다.
z.object({ ans_id: z.string(), domain_id: z.string().nullable(), decision: z.enum(["pass","improve","reject"]), factors: z.array(z.enum(["ungrounded","schema_violation","low_eval","unmapped_domain","missing_metric"])), reason: z.string().min(20), evidence: z.string().min(8), hedge: z.string().nullable() })[
{
"input_ref": "ra_002 (원문 미근거)",
"output": {
"ans_id": "ra_002",
"domain_id": "manual",
"decision": "reject",
"factors": [
"ungrounded",
"low_eval"
],
"reason": "답변이 원문 매뉴얼에 근거가 없고 평가 점수도 0.5 로 낮습니다. 실적용에 내보내면 안 되는 답이라 반려합니다.",
"evidence": "grounded=false, eval_score=0.5",
"hedge": "원문 근거가 없어 반려합니다"
}
},
{
"input_ref": "ra_004 (중간 평가)",
"output": {
"ans_id": "ra_004",
"domain_id": "quality",
"decision": "improve",
"factors": [
"low_eval"
],
"reason": "근거·형식은 정상이나 평가 점수가 0.55 로 통과 임계에 못 미칩니다. 반려까지는 아니라 품질 개선 큐로 보냅니다.",
"evidence": "eval_score=0.55, grounded=true",
"hedge": "평가가 낮아 개선이 필요합니다"
}
},
{
"input_ref": "ra_005 (미등록 도메인)",
"output": {
"ans_id": "ra_005",
"domain_id": null,
"decision": "improve",
"factors": [
"unmapped_domain"
],
"reason": "문서 도메인이 마스터에 없어 통과를 단정하지 않습니다. 근거·평가는 정상이라 도메인 등록·지표 보정을 위해 개선 큐로 둡니다.",
"evidence": "domain_id=null, eval_score=0.85",
"hedge": "미등록 도메인이라 지표 보정 후 통과가 필요합니다"
}
}
][자동 검증] 1. Zod parse 로 출력 형식(필드·enum)이 스키마를 통과하는지 확인합니다. 2. decision 이 채점 규칙(미근거/형식위반→reject·저평가/미등록/결측→improve·통과→pass)과 일치하는지 봅니다. 3. evidence 가 입력의 실제 값 인용인지 토큰 매칭으로 확인하고, grounded=false 면 pass 가 되지 않게 강제합니다. 4. decision 을 심은 정답 label 과 비교해 정밀도·재현율을 계산합니다. [수동 검증] 1. 검토자 2명이 비동기로 채점을 라벨링해 정밀도·재현율과 bootstrap Cohen's κ(두 사람 일치가 우연 이상인 정도, 0~1) 하한 0.6 이상을 봅니다. 2. 전체의 5% 를 사람이 직접 점검합니다.