RAG가 대충 맞는 것 같아도 운영이 흔들린다면, 평가 대시보드부터 먼저 만들어야 합니다

RAG를 붙인 서비스가 데모에서는 괜찮아 보이는데, 운영에 들어가면 자주 흔들립니다. 어떤 날은 답이 잘 나오고, 어떤 날은 엉뚱한 문서를 가져오고, 업데이트한 문서가 바로 반영되지 않기도 합니다. 이때 많은 팀이 프롬프트부터 다시 만집니다. 그런데 실제로는 평가 체계가 없어서 문제를 못 보고 있는 경우가 더 많습니다. RAG 운영에서 먼저 만들어야 할 것은 새로운 프롬프트가 아니라 평가 대시보드입니다. retrieval quality, answer grounding, freshness, failure pattern을 계속 볼 수 있어야 합니다. 이 글은 RAG를 실서비스로 운영하는 팀이 왜 평가 대시보드를 먼저 가져야 하는지, 어떤 지표를 최소 구성으로 봐야 하는지 설명합니다.

왜 프롬프트보다 대시보드가 먼저인가

RAG 실패는 종류가 다릅니다.

검색 자체가 틀린 경우
검색은 맞았는데 답변 조합이 틀린 경우
최신 문서가 반영되지 않은 경우
문서는 맞지만 사용자 질문 의도를 잘못 해석한 경우

이걸 구분하지 않으면 모든 문제를 '모델이 이상함'으로 뭉개게 됩니다. 그러면 개선도 느립니다. 평가 대시보드가 필요한 이유는 실패를 분해하기 위해서입니다. 어느 단계에서 흔들리는지 알아야 정확히 고칠 수 있습니다.

최소한 봐야 하는 지표 6개

1) Retrieval hit rate

정답 근거가 상위 k개 문서 안에 들어왔는지 보는 지표입니다. 이 값이 낮으면 임베딩, chunking, metadata filter, query rewrite 쪽 문제일 가능성이 큽니다.

2) Grounded answer rate

최종 답변이 실제 검색된 문서 근거 안에서만 말하고 있는지 봐야 합니다. 문서를 가져왔어도 모델이 바깥 상식을 섞으면 위험합니다. 특히 정책, 가격, 규정, 법무 문서에서는 치명적입니다.

3) Freshness lag

문서가 갱신된 시점과 검색 인덱스에 반영된 시점의 차이를 측정해야 합니다. 사내 위키나 제품 문서는 하루만 늦어도 잘못된 답이 됩니다.

4) No-answer precision

답을 모를 때 '모른다'고 말하는 정확도입니다. 많은 팀이 이것을 안 재는데, 운영에서는 매우 중요합니다. 틀린 답변보다 안전한 거절이 나은 경우가 많기 때문입니다.

5) Citation usefulness

출처 링크를 붙였는지가 아니라, 실제로 사용자가 검증 가능한 출처였는지를 봐야 합니다. 제목만 비슷한 문서를 붙이는 경우가 꽤 많습니다.

6) Query failure clusters

어떤 질문 유형에서 반복적으로 깨지는지 묶어 봐야 합니다. 예를 들면 숫자 비교, 최신 정책, 다국어 문서, 표 기반 질의, 복수 문서 종합형 질문처럼 패턴이 생깁니다.

대시보드 설계는 어떻게 시작하나

가장 단순한 구조는 요청 로그를 네 구간으로 나누는 겁니다.

user query
retrieval result
answer output
human feedback or offline label

이 네 구간만 저장해도 많은 게 보입니다. 여기에 아래 메타데이터를 추가하면 훨씬 좋아집니다.

인덱스 버전
임베딩 모델 버전
chunk size
필터 조건
top-k 값
응답 시간
사용자 클릭한 출처

이 정도면 '어느 설정에서 실패가 늘었는지'를 추적할 수 있습니다.

자주 놓치는 운영 포인트

1) 오프라인 평가셋이 없다

실제 사용 로그만 보면 편향이 생깁니다. 자주 묻는 질문만 계속 최적화하게 됩니다. 대표 질문셋 100~300개 정도는 별도로 고정해 두고, 배포 전후 점검에 써야 합니다.

2) retrieval과 generation을 따로 안 본다

검색이 틀렸는지, 답변이 틀렸는지 분리해야 합니다. retrieval hit rate는 높은데 grounded answer rate가 낮다면 생성 단계 문제입니다. 반대로 grounded answer는 괜찮은데 정답 문서를 못 가져오면 검색 단계 문제입니다.

3) 문서 신선도를 무시한다

운영 문서는 계속 바뀝니다. 그런데 인덱싱 파이프라인 지연을 안 보면, 사용자는 최신 문서를 봤다고 믿지만 시스템은 옛 문서를 들고 옵니다. 특히 가격, 약관, 공지, 내부 정책 문서는 freshness 모니터링이 중요합니다.

4) 사람 검수 비용을 계산 안 한다

평가 대시보드를 만들면 초기에 라벨링 비용이 듭니다. 이걸 아까워하면 개선 속도가 더 느려집니다. 최소한 치명도 높은 도메인만이라도 주간 샘플 검수를 돌려야 합니다.

개발팀 관점의 현실적인 결론

RAG는 '지식이 연결된 챗봇'이 아니라 검색 시스템과 생성 시스템의 합성체입니다. 그래서 운영도 두 시스템을 분리해서 봐야 합니다. 문제는 대개 성능 부족보다 관측 부족에서 시작됩니다.

평가 대시보드를 먼저 만들면 팀 대화 방식도 달라집니다. '요즘 답이 별로다'가 아니라 '최신 정책 질의에서 retrieval hit rate가 62%로 떨어졌다'처럼 말할 수 있습니다. 이렇게 되면 개선 속도가 빨라집니다.

바로 실행할 체크리스트

대표 질문셋 100개 이상을 만든다
retrieval 결과와 final answer를 분리 저장한다
hit rate, grounded rate, freshness lag를 기본 KPI로 둔다
no-answer precision을 따로 측정한다
실패 질문을 유형별로 태깅한다
인덱스 버전과 임베딩 버전을 로그에 남긴다
배포 전후를 같은 평가셋으로 반드시 비교한다