황혜수 연구원
AI Engineer · AIWORKX R&D센터 지능화멀티모달연구팀
RAG·LLM 기반 시스템을 연구·기획하고 직접 개발합니다. 특수 도메인 RAG의 검색 설계와 온톨로지 구축을 실무에서 풀어내는 데 집중하고 있습니다.
- 눈대중(Vibe Check)으로는 프로덕션 RAG를 평가할 수 없다 — 검색과 생성을 분리(Decoupling)한 4대 정량 지표(Context Recall, Context Precision, Faithfulness, Answer Relevance)가 출발점이다.
- 실무 최대 장벽은 정답셋(Ground Truth)의 부재 — 정답 문서에서 거꾸로 질문을 만드는 합성 데이터 생성과 LLM-as-a-Judge(LLM 심판)로 돌파한다.
- AI 심판도 100% 완벽할 수 없다 — HITL 정성 평가를 결합해 AIWORKX는 데이터 정제(1편)부터 검색(2편), 평가(3편)까지 통합 파이프라인으로 시스템화했다.
1편에서는 파서(Parser)와 VLM을 활용해 비정형 데이터의 늪을 탈출했고, 2편에서는 단순 벡터 검색이 가질 수 있는 한계를 ‘온톨로지(Ontology)’와 ‘지식 그래프(Knowledge Graph)’라는 기술을 통해 극복해냈습니다.
지금까지 우리는 비정형 데이터를 정제하고, 도메인 지식을 구조화하여 검색 아키텍처까지 구축했습니다. 이제 파이프라인은 원활하게 돌아갑니다. 사용자가 질문을 던지면 그럴싸한 답변이 잘 나옵니다.
성공적인 프로젝트 종료를 앞둔 어느 날, 경영진 혹은 고객사가 묻습니다.
“그래서, 이 RAG 시스템의 정확도는 몇 퍼센트(%)인가요? 이전 버전보다 구체적으로 얼마나 좋아졌죠?”
이 질문을 받는 순간, 대부분의 엔지니어와 PM은 말문이 막힙니다. 이번 마지막 3편에서는 도대체 RAG를 어떻게 정량적으로 평가해야 하는지, 그리고 턱없이 부족한 특수 도메인의 평가 데이터셋을 어떻게 구축해 나가는지 그 실무적인 해답을 찾아보겠습니다.
- 1편 데이터 정제(전처리): 비정형 데이터의 늪 (발행 완료)
- 2편 검색 설계: 검색의 진화와 온톨로지 (발행 완료)
- 3편 성능 평가: 지표와 도메인 특화 데이터셋 〔이번 편 · 마지막편〕
1. 눈대중(Vibe Check) 평가의 함정
기존 소프트웨어 개발에서는 예상 결과값이 명확했습니다. A를 넣으면 B가 나와야 한다는 테스트 코드(True/False)를 짤 수 있었죠. 하지만 생성형 AI의 결과물은 매번 문장 단위로 새롭게 생성되며, ‘정답의 형태’가 무한합니다.
그래서 튜토리얼이나 초기 PoC(개념 검증) 단계에서는 보통 ‘눈대중(Vibe Check)’으로 평가를 진행합니다. 개발자가 10~20개의 질문을 던져보고, 답변이 그럴듯하게 나오면 “잘 동작하네요!”라고 판단하는 식입니다.
하지만 프로덕션(실 서비스) 환경에서는 이 방식이 잘 통하지 않습니다.
- “Chunk 사이즈를 500자에서 800자로 늘려볼까?”
- “임베딩 모델을 다른 것으로 바꿔볼까?”
- “하이브리드 검색에서 BM25 가중치를 0.3에서 0.5로 올려볼까?”
파이프라인의 특정 파라미터를 변경했을 때, 시스템 전체의 성능이 ‘개선되었는지(Up)’ 아니면 ‘퇴보했는지(Down)’ 판단하려면 수천 개의 질의응답을 모두 읽어봐야 합니다. 인간의 눈으로는 불가능한 영역입니다. 우리는 직감(Vibe)이 아닌, 시스템의 건강 상태를 모니터링할 ‘정량적 지표(Metric)’가 필요합니다. 1편에서 파서 실험을 EM(Exact Match) 지표와 5개 질의로 측정하며 ‘이 수치를 어떻게 신뢰할지는 3편에서’라고 약속드렸는데, 바로 그 이야기입니다.
2. RAG 평가의 핵심: 검색과 생성을 분리하라 (Decoupling)
RAG 평가가 막막한 가장 큰 이유는 ‘검색 실패’와 ‘생성 실패’를 뭉뚱그려 생각하기 때문입니다. AI가 엉뚱한 답변을 냈을 때, LLM이 바보(환각)라서 틀린 것인지, 아니면 DB가 애초에 엉뚱한 문서를 가져와서(검색 오류) 틀린 것인지 원인을 정확히 분리해서 채점해야 합니다.
이를 위해 RAGAS나 TruLens 같은 오픈소스 기반의 RAG/LLM 평가 도구들은 평가 지표를 크게 ‘검색(Retrieval)’과 ‘생성(Generation)’ 두 축으로 나눕니다. 앞선 2편의 예시를 가져와 쉽게 풀어보겠습니다.
- 사용자 질문: “2023년 5월 기준, A질환 65세 여성의 급여 인정 여부는?”
- DB 내 정답 문서: 문서1(A질환 급여 규정), 문서2(나이 및 성별 조건)
2-A. 검색(Retrieval) 품질 지표: DB는 일을 잘했는가?
- Context Recall (검색 재현율): 질문에 답하기 위해 필요한 ‘모든 관련 지식’을 빠짐없이 가져왔는가?
- 예시: DB가 문서1은 가져왔는데 문서2를 놓쳤다면? LLM은 나이 조건을 알 수 없어 답변을 못 합니다. (Recall 점수 하락)
- Context Precision (검색 정밀도): 검색해 온 문서들 중 ‘진짜 쓸모있는 정답 문서’가 얼마나 상단(Top)에 위치해 있는가?
- 예시: 쓸모없는 과거 규정 문서 8개를 1~8등으로 가져오고, 진짜 정답인 문서1, 문서2를 9, 10등으로 가져왔다면? 노이즈가 너무 많아 LLM이 헷갈리게 됩니다. (Precision 점수 하락)
2-B. 생성(Generation) 품질 지표: LLM은 말을 잘했는가?
- Faithfulness (사실 부합성 / 환각 여부): LLM이 생성한 답변이 오직 검색된 문서(Context)에만 기반하고 있는가?
- 예시: DB가 ‘급여 불가’ 문서를 가져왔는데, LLM이 자기 맘대로 다른 분야에서 학습된 지식을 섞어 “급여가 가능합니다”라고 대답했다면? (가장 위험한 통제 불능 상태. Faithfulness 0점)
- Answer Relevance (답변 관련성): 문서의 내용을 잘 요약했더라도, 정작 사용자가 묻는 ‘질문의 의도’에 정확히 부합하는가?
- 예시: LLM이 “A질환은 이러이러한 무서운 병이며, 예방법은…”이라고 장황하게 설명했다면? 문서를 잘 요약했더라도 ‘급여 인정 여부’라는 질문 의도를 벗어났으므로 빵점입니다.
3. 실무의 거대한 장벽: 정답셋(Ground Truth)의 부재
위의 4가지 지표를 보면 고개가 끄덕여집니다. “좋아, 이제 저 지표들로 점수를 매기면 되겠군!”
그런데 여기서 실무 엔지니어를 혼돈에 빠지게 하는 장벽이 등장합니다. 저 지표들을 계산하려면, 도대체 무엇이 ‘완벽한 정답’인지 기준점이 되는 ‘정답 데이터셋(Ground Truth)’이 필요하다는 사실입니다.
‘검색 재현율’을 평가하려면 질의에 대한 “이상적인 황금 문서(Golden Context)” 리스트가 있어야 하고, ‘답변 관련성’을 평가하려면 “이상적인 모범 답안(Golden Answer)”이 있어야 합니다.
| 데이터 구분 | 특징 및 한계 |
|---|---|
| 일반 오픈소스 데이터셋 | 상식 퀴즈 위주, 인터넷에 공개된 일반 지식. 특수 도메인 성능 평가에 적용 불가 |
| 도메인 특화 데이터셋 | 의료 심사 고시, 법안, 사내 제조 매뉴얼 등. 원하는 조건에 적합한 데이터셋은 존재하기 어려움 |
결국 현업 도메인 전문가(의사, 변호사, 사내 시니어)들을 방에 가둬놓고 수십, 수백개의 예상 질문과 모범 답안, 정답 문서 번호를 엑셀로 작성하게 해야 하는데, 이는 비용과 시간 측면에서 매우 어려운 미션입니다.
4. 엔지니어링으로 돌파하기: 역발상과 지식 증류(Knowledge Distillation)
사람이 직접 정답셋을 만들 수 없다면 어떻게 해야 할까요? 엔지니어들은 이 문제를 ‘역발상(Reverse Engineering)’과 ‘LLM 심판(LLM-as-a-Judge)’이라는 기법으로 돌파합니다.
돌파구 1: 합성 데이터 자동 생성 (Synthetic Data Generation)
질문을 보고 정답 문서를 찾는 것은 어렵지만, ‘정답 문서를 미리 쥐어주고 그에 맞는 질문을 만들어내라’고 LLM에게 시키는 것은 상대적으로 쉽습니다.
1편과 2편을 거치며 우리는 고품질의 지식 데이터들을 확보해 두었습니다. 이 데이터들을 LLM에 입력한 후, 이렇게 지시합니다.
“이 규정 문서를 기반으로, 현업 실무자가 헷갈려 할 법한 복잡한 추론형 질문(Question) 3개를 생성하고, 그에 대한 완벽한 모범 답안(Answer)을 작성해 줘.”
이 자동화 파이프라인을 돌리면 단 며칠 만에 [질문 – 황금 문서 ID – 모범 답안]으로 엮인 도메인 특화 QA 데이터셋이 쏟아져 나옵니다.
돌파구 2: 심판으로서의 LLM (LLM-as-a-Judge)
정답셋이 준비되었다면, 이제 우리의 RAG 시스템이 내놓은 결과물을 채점할 차례입니다. 인간이 수만 개의 답변을 채점할 수 없으니, 똑똑한 LLM을 ‘심판(Judge)’으로 기용합니다.
심판 LLM에게 우리의 RAG 시스템이 가져온 문서(Context)와 최종 답변, 그리고 앞서 만든 모범 답안을 함께 쥐어주고, 앞서 정의한 4가지 지표에 따라 1~5점의 점수와 ‘채점 이유’를 작성하게 합니다.
돌파구 3: 실무 최적화 — 지연 시간(Latency) 통제와 지식 증류
여기서 한 단계 더 깊은 실무적 고민이 등장합니다. 대규모 CI/CD 환경(코드를 통합·배포하는 자동화 체계)이나 실시간 모니터링 시스템에서, 수만 건의 평가를 매번 무거운 거대 모델에게 맡기는 것은 막대한 API 비용과 심각한 지연 시간(Latency) 병목을 유발합니다.
따라서 현업에서는 거대 모델의 우수한 평가 논리와 추론 능력을 가벼운 소형 모델(SLM, Small Language Model)에 이식하는 지식 증류(Knowledge Distillation) 기법을 활용하기도 합니다. 가볍고 빠른 자체 평가용 라우팅 모델을 구축하여, 지연 속도를 최적화하면서도 평가의 일관성을 유지하는 것이 엔지니어링 노하우 중 하나죠.
5. 이상과 현실의 앙상블, 그리고 시스템화 (Wrap-up)
물론 AI가 합성한 데이터와 LLM 심판이 100% 완벽할 수는 없습니다. 질문이 지나치게 기계적이거나, 심판 모델 자체의 편향성이 개입될 여지가 분명 존재합니다.
결국 여기서도 2편에서 강조했던 HITL(Human-In-The-Loop)이 다시 등장합니다.
사용자는 평가된 결과의 세부 내역을 보고 실제로 해당 질의-응답 셋의 정답 유무가 올바르게 적용된 것인지 “정성적인 평가”를 거치는 과정이 필요합니다. 해당 정성적인 평가를 효과적으로 수행하기 위해 검색과 생성 각각의 단계에 있어 세부적인 검색 결과 및 평가 이유를 제공합니다. 인간은 해당 내용을 보고 정확한 평가를 위해 평가 데이터셋에 대한 수정을 진행합니다.
이 거대하고 복잡한 사이클을 끊임없이 반복하며 정량적 수치를 우상향시키는 것. 이것이 튜토리얼을 벗어나 실전 프로덕션 환경에서 RAG를 구축하는 엔지니어들의 진짜 모습입니다.
저희 AIWORKX(에이아이웍스)가 비정형 데이터 파싱(1편)부터 온톨로지 기반 검색 아키텍처(2편), 그리고 오늘 다룬 평가 프레임워크(3편)까지 이 모든 과정을 ‘통합된 시스템 파이프라인’으로 만들어낸 이유이기도 합니다. 이 힘든 인프라와 평가의 굴레를 프로젝트마다 매번 수작업으로 반복할 수는 없으니까요.
지금까지 총 3편에 걸쳐 실전 RAG 시스템을 구축하며 겪는 데이터의 민낯, 검색의 한계, 그리고 평가의 막막함까지 함께 짚어보았습니다.
생성형 AI는 단순한 마법이 아닙니다. 파운데이션 모델의 화려함 뒤에는, 결국 데이터를 닦고 조이고 구조화하며 끝없이 채점표를 수정해 나가는 엔지니어들의 땀방울과 치밀한 아키텍처가 존재한다는 사실이 잘 전달되었기를 바랍니다.
감사합니다.
자주 묻는 질문 (FAQ)
Q1. RAG 성능 평가의 핵심 지표는 무엇인가요?
검색과 생성을 분리해 4가지로 봅니다. 검색 측은 Context Recall(필요한 지식을 빠짐없이 가져왔는가)과 Context Precision(정답 문서가 상단에 있는가), 생성 측은 Faithfulness(검색된 문서에만 기반했는가)와 Answer Relevance(질문 의도에 부합하는가)입니다.
Q2. Context Recall과 Context Precision의 차이는 무엇인가요?
Recall은 필요한 관련 지식의 ‘누락 여부’, Precision은 가져온 문서 중 정답 문서의 ‘상단 배치 비율’을 봅니다. 둘 다 검색(Retrieval) 품질 지표입니다.
Q3. LLM-as-a-Judge(LLM 심판)란 무엇인가요?
사람이 수만 건의 답변을 채점할 수 없으므로, LLM에게 검색 문서·최종 답변·모범 답안을 함께 주고 지표별 1~5점 점수와 채점 이유를 작성하게 하는 자동 평가 기법입니다.
Q4. 정답셋(Ground Truth)이 없을 때는 어떻게 평가하나요?
정답 문서를 미리 주고 그에 맞는 질문과 모범 답안을 LLM이 만들게 하는 합성 데이터 생성(역발상)으로 도메인 특화 QA 데이터셋을 구축한 뒤, HITL 정성 평가로 품질을 보정합니다.
Q5. 대규모 평가의 비용과 지연 시간은 어떻게 줄이나요?
거대 모델의 평가 논리를 가벼운 소형 모델(SLM)에 이식하는 지식 증류(Knowledge Distillation)로 자체 평가용 모델을 만들어, 평가 일관성을 유지하면서 속도와 비용을 최적화합니다.