RAG를 붙인 서비스가 데모에서는 괜찮아 보이는데, 운영에 들어가면 자주 흔들립니다. 어떤 날은 답이 잘 나오고, 어떤 날은 엉뚱한 문서를 가져오고, 업데이트한 문서가 바로 반영되지 않기도 합니다. 이때 많은 팀이 프롬프트부터 다시 만집니다. 그런데 실제로는 평가 체계가 없어서 문제를 못 보고 있는 경우가 더 많습니다. RAG 운영에서 먼저 만들어야 할 것은 새로운 프롬프트가 아니라 평가 대시보드입니다. retrieval quality, answer grounding, freshness, failure pattern을 계속 볼 수 있어야 합니다. 이 글은 RAG를 실서비스로 운영하는 팀이 왜 평가 대시보드를 먼저 가져야 하는지, 어떤 지표를 최소 구성으로 봐야 하는지 설명합니다.
RAG 실패는 종류가 다릅니다.
이걸 구분하지 않으면 모든 문제를 '모델이 이상함'으로 뭉개게 됩니다. 그러면 개선도 느립니다. 평가 대시보드가 필요한 이유는 실패를 분해하기 위해서입니다. 어느 단계에서 흔들리는지 알아야 정확히 고칠 수 있습니다.
정답 근거가 상위 k개 문서 안에 들어왔는지 보는 지표입니다. 이 값이 낮으면 임베딩, chunking, metadata filter, query rewrite 쪽 문제일 가능성이 큽니다.
최종 답변이 실제 검색된 문서 근거 안에서만 말하고 있는지 봐야 합니다. 문서를 가져왔어도 모델이 바깥 상식을 섞으면 위험합니다. 특히 정책, 가격, 규정, 법무 문서에서는 치명적입니다.
문서가 갱신된 시점과 검색 인덱스에 반영된 시점의 차이를 측정해야 합니다. 사내 위키나 제품 문서는 하루만 늦어도 잘못된 답이 됩니다.
답을 모를 때 '모른다'고 말하는 정확도입니다. 많은 팀이 이것을 안 재는데, 운영에서는 매우 중요합니다. 틀린 답변보다 안전한 거절이 나은 경우가 많기 때문입니다.
출처 링크를 붙였는지가 아니라, 실제로 사용자가 검증 가능한 출처였는지를 봐야 합니다. 제목만 비슷한 문서를 붙이는 경우가 꽤 많습니다.
어떤 질문 유형에서 반복적으로 깨지는지 묶어 봐야 합니다. 예를 들면 숫자 비교, 최신 정책, 다국어 문서, 표 기반 질의, 복수 문서 종합형 질문처럼 패턴이 생깁니다.
가장 단순한 구조는 요청 로그를 네 구간으로 나누는 겁니다.
이 네 구간만 저장해도 많은 게 보입니다. 여기에 아래 메타데이터를 추가하면 훨씬 좋아집니다.
이 정도면 '어느 설정에서 실패가 늘었는지'를 추적할 수 있습니다.
실제 사용 로그만 보면 편향이 생깁니다. 자주 묻는 질문만 계속 최적화하게 됩니다. 대표 질문셋 100~300개 정도는 별도로 고정해 두고, 배포 전후 점검에 써야 합니다.
검색이 틀렸는지, 답변이 틀렸는지 분리해야 합니다. retrieval hit rate는 높은데 grounded answer rate가 낮다면 생성 단계 문제입니다. 반대로 grounded answer는 괜찮은데 정답 문서를 못 가져오면 검색 단계 문제입니다.
운영 문서는 계속 바뀝니다. 그런데 인덱싱 파이프라인 지연을 안 보면, 사용자는 최신 문서를 봤다고 믿지만 시스템은 옛 문서를 들고 옵니다. 특히 가격, 약관, 공지, 내부 정책 문서는 freshness 모니터링이 중요합니다.
평가 대시보드를 만들면 초기에 라벨링 비용이 듭니다. 이걸 아까워하면 개선 속도가 더 느려집니다. 최소한 치명도 높은 도메인만이라도 주간 샘플 검수를 돌려야 합니다.
실무에서는 아래 순서가 가장 안전합니다.
이 순서를 지키면 감으로 튜닝하는 시간을 크게 줄일 수 있습니다.
RAG는 '지식이 연결된 챗봇'이 아니라 검색 시스템과 생성 시스템의 합성체입니다. 그래서 운영도 두 시스템을 분리해서 봐야 합니다. 문제는 대개 성능 부족보다 관측 부족에서 시작됩니다.
평가 대시보드를 먼저 만들면 팀 대화 방식도 달라집니다. '요즘 답이 별로다'가 아니라 '최신 정책 질의에서 retrieval hit rate가 62%로 떨어졌다'처럼 말할 수 있습니다. 이렇게 되면 개선 속도가 빨라집니다.
