프로젝트 01 — 프로덕션
호롱 · KEIAdminSuperv
사내 규정을 위한 온프레미스 RAG — 근거를 대거나, 아니면 답하지 않습니다.
행정·회계·감사에서는 틀린 답이 곧 사고입니다. 그래서 목표를 “그럴듯한 답”이 아니라 틀리지 않는 것으로 잡았습니다. 599개 문서를 조문 단위로 자르고, KURE-v1으로 임베딩해 밀집 검색 top-20을 뽑은 뒤, 온프레미스 리랭커로 top-5까지 좁히고, 생성 전에 신뢰 게이트를 통과시킵니다. 근거가 없으면 지어내지 않고 “규정에서 확인되지 않습니다”로 거부합니다.
FastAPI · Ollama (Qwen3.5-9B GGUF) · Chroma · KURE-v1 · bge-reranker-v2-m3 · Next.js 14 · MLflow · Cloudflare Zero Trust
82.9%
리랭커를 넣은 뒤의 엄격 Hit@1. 60.0%에서 올랐습니다.
100%
모든 답변 끝에 면책 고지가 붙습니다. 모델이 19% 확률로 빠뜨리던 것을 코드가 보장하게 바꿨습니다.
6,044
599개 문서에서 나온 청크. 상위법령 4,116청크는 물리적으로 분리해 둡니다.
[규정, 조문] 출처가 붙고, 근거 카드는 그 자리에서 펼쳐 볼 수 있습니다
부하를 걸어 재고, 그 결과를 설명했습니다.
추측이 아니라 dev 인스턴스에 동시성 스윕을 직접 돌린 결과입니다. 처리량은 동시 요청 2개에서 이미 포화되고, 그 위로는 전부 큐잉으로 밀립니다. 생성 속도가 부하와 상관없이 14~15 tok/s로 일정하다는 것 — 이걸 보고 병목을 GPU 성능이 아니라 배칭 없는 직렬 생성으로 좁혔습니다.
| 동시성 | p50 | p95 | 처리량 | 생성 속도 |
|---|---|---|---|---|
| 1 | ~15초 | 18.0초 | 3.9 req/min | 13.9 tok/s |
| 2 | 28.3초 | 30.3초 | 4.3 req/min | 14.4 tok/s |
| 4 | 50.0초 | 55.2초 | 4.3 req/min | 15.0 tok/s |
| 8 | 74.9초 | 111.2초 | 3.8 req/min | 15.0 tok/s |
지금 쓰는 사내 수십 명 규모에는 충분합니다. 더 키워야 한다면 순서는 분명합니다 — continuous batching을 지원하는 서버로 옮기고, Vulkan에 묶어 두는 드라이버 제약을 풀고, 그다음이 replica입니다. 토큰 수치는 엔드포인트가 usage를 돌려주지 않아 문자 수 기반 근사입니다.
선의가 아니라 결정론으로.
금액·비율·기간이 근거에 없으면 코드가 경고를 붙입니다. 모델 재량이 아닙니다. HWP 변환에서 깨진 표는 수치 인용 자체를 금지하고, 삭제·폐지된 조문은 근거에서 강등합니다.
매일 스스로 채점합니다.
평일 200문항, 주말 500문항×3회차를 자동으로 출제·답변·채점·게시하고 결과를 MLflow에 기록합니다.
기각도 결과입니다.
BM25 하이브리드 검색은 실측에서 이득이 없어 기본 off로 내렸습니다. 같은 근거로 치른 모델 A/B에서 57.3% 대 40.8%가 갈렸고, 이 숫자가 지금 돌아가는 모델을 정했습니다.
사고 기록 — 버그는 지표 쪽에 있었습니다. 하루아침에 정답률이 90에서 68로 떨어졌습니다. 서비스가 나빠진 게 아니었습니다. 출제 표본이 매일 85%씩 갈리고 있어서, 합산 정답률로는 애초에 개선을 증명할 수 없는 구조였던 겁니다. 재시험 문항과 신규 문항 코호트를 갈라 보니 같은 문항의 오답이 7건에서 1건으로 줄어 있었고, 급락이 표본 탓이라는 걸 30분 만에 짚어냈습니다. 이후로도 측정기가 틀린 사고가 이어졌습니다 — 거부 판정 정규식이 정답을 거부로 세고, 채점기가 사흘간 정답을 ‘부분 정답’으로 깎고, 거부 원인 56건 중 9건이 엉뚱하게 ‘검색실패’로 분류되고 있었습니다. 다섯 건을 한 번에 묶어 고친 뒤 25회차 4,800여 문항을 다시 집계해 156건이 이동하는 것을 확인했습니다.
