네이버 D2가 4월 초 공개한 글이 눈에 띈다. RAG 서비스의 품질을 RAGAS 프레임워크로 정량화하고, LLM-as-a-Judge와 LLMOps 파이프라인으로 평가를 자동화했다는 내용이다.
"느낌"이 아닌 숫자
RAG 시스템을 만들어본 팀이라면 다 겪는 문제가 하나 있다. "이 RAG가 잘 되고 있는 건가?"라는 질문에 팀원 세 명이 각자 다른 답을 내놓는 상황. 검색 결과가 "괜찮아 보이는데?" 수준의 감상평으로 흘러가고, 품질 논의가 주관의 영역에 갇힌다.
네이버가 꺼낸 카드는 RAGAS다. RAG Assessment의 약자로, RAG 파이프라인 전체를 정량 평가하는 오픈소스 프레임워크. D2 팀은 여기서 세 가지 지표에 집중했다: Context Precision, Faithfulness, Answer Relevance. 각각이 RAG의 서로 다른 약점을 찌르는 구조다.
Context Precision — 리트리버가 핵심을 찔렀는가
Context Precision은 리트리버가 가져온 문서 덩어리(chunk) 중 실제로 관련 있는 것이 상위에 랭크되었는지를 본다. 10개 chunk를 가져왔는데 정작 답이 될 chunk가 8번째에 깔려 있으면 점수가 떨어진다.
이 지표가 왜 중요한지는 LLM의 특성을 생각하면 바로 와닿는다. "Lost in the middle" 현상 — 컨텍스트 윈도우의 중간에 묻힌 정보는 모델이 잘 활용하지 못한다는 연구 결과가 여러 차례 나왔다. 그래서 단순히 "관련 문서를 가져왔느냐"가 아니라 "관련 문서를 앞쪽에 배치했느냐"가 승부를 가른다. 임베딩 모델만 바꿔도 이 지표가 0.6에서 0.85로 뛸 수 있고, 리랭커(reranker) 하나 끼우면 또 달라진다. 네이버 스케일에서 리트리버 튜닝의 효과를 객관적으로 비교하려면 이런 숫자가 필수적이다.
Faithfulness — 환각을 정량화하는 법
Faithfulness는 생성된 답변이 검색된 컨텍스트에 실제로 근거하고 있는지를 측정한다. 환각(hallucination)의 정량화라고 봐도 무방하다.
평가 방식이 꽤 영리하다. 답변을 개별 claim으로 분해한 뒤, 각 claim이 제공된 컨텍스트에서 추론 가능한지를 하나씩 검증한다. "5개 claim 중 4개가 컨텍스트에 근거 → Faithfulness 0.8" 이런 식이다. 네이버 규모에서 이걸 사람이 직접 하면 비용이 감당이 안 되니, LLM-as-a-Judge를 끌어들인 것이다.
여기서 한 가지 짚어야 할 지점이 있다. LLM으로 LLM의 출력을 평가하는 순환 구조 — 이게 정말 신뢰할 만한가? 평가 모델이 같은 종류의 환각을 공유하면 오류를 놓칠 수 있다. D2 팀도 이 문제를 인지하고 있었던 것 같다. 인간 평가자 표본과의 상관관계를 먼저 검증하고, 상관이 충분히 높은 지표에 한해서만 자동 평가를 적용하는 2단계 접근을 취했다. 무작정 자동화부터 들이민 게 아니라는 점에서 실용적이다.
Answer Relevance는 왜 따로 보는가
세 번째 지표인 Answer Relevance는 답변이 원래 질문의 의도에 부합하는지를 측정한다. Faithfulness가 "출처에 충실한가"라면, 이쪽은 "사용자가 원한 답인가"에 가깝다.
실무에서 이 두 지표가 갈라지는 경우가 의외로 잦다. 컨텍스트에 충실하게 답했는데 정작 질문과 관련 없는 이야기를 하는 케이스. 검색된 문서 자체가 질문의 핵심에서 벗어났을 때 생긴다. Context Precision이 낮으면 Answer Relevance도 연쇄적으로 떨어지는 상관관계가 있다는 것이 D2 팀의 관찰이었고, 이 세 지표를 같이 봐야 "어디가 병목인지" 진단이 가능하다는 결론이다.
프로덕션에서는 대시보드가 돼야 한다
지표 세 개를 노트북에서 한 번 찍어보는 건 연구 단계에서는 충분하다. 하지만 프로덕션에서는 이야기가 다르다. 매 배포마다 자동 측정이 돌아야 하고, 성능이 기준선 아래로 떨어지면 알림이 와야 하고, 어떤 코드 변경이 퇴화를 일으켰는지 추적이 가능해야 한다.
네이버가 강조한 건 바로 이 LLMOps 파이프라인 부분이다:
배포 파이프라인에 테스트 쿼리셋을 물려서 세 지표를 자동 측정
임계값 이하일 경우 배포 자체를 블로킹
시계열 추적으로 서서히 퇴화하는 패턴을 조기 포착
MLOps에서 모델 드리프트 모니터링이 표준이 된 것처럼, RAG에도 같은 수준의 운영 체계가 필요하다는 메시지다. 토스가 Qwen 셀프호스팅에서 자체 평가 루프를 돌리고, 배민이 사내 MCP 서버에서 AI 서비스 품질 관리를 내세우는 흐름과도 맞닿아 있다.
다음으로 궁금한 것
아쉬운 건 네이버가 이 체계를 CLOVA X 소비자 서비스에 직접 적용한 사례까지는 공개하지 않았다는 점이다. D2 글은 사내 RAG — 내부 검색, 문서 Q&A — 에 초점이 맞춰져 있었다. 네이버 스케일의 소비자 대면 RAG, 예를 들면 검색 결과 요약이나 쇼핑 추천에서 RAGAS 지표가 어떻게 움직이는지가 진짜 궁금한 이야기다.
RAG가 "벡터 DB 붙이면 끝" 단계를 넘어서 "잘 만든 건지 증명할 수 있느냐"로 넘어가고 있다. 네이버의 이번 글은 그 전환점에 서 있다.