RAG 평가 전략

production 문제를 다루는 좋은 첫 단계는 관측성(observability) 시스템을 갖추는 것이다. 이번 편은 관측성 플랫폼이 추적해야 할 정보와, 평가를 설계하는 scope × evaluator type 프레임워크, 그리고 실전 지표 세트를 정리한다.

 

 

1. 무엇을 추적하나 — 성능 · 품질

관측성 플랫폼은 몇 가지 정보를 추적해야 한다. 첫째, 소프트웨어 성능 지표 — latency·throughput·memory·compute 사용량. 얼마나 많은 request를 처리하고, 얼마나 걸리고, 자원을 얼마나 쓰는지다. 둘째, 품질 지표 — 최종 응답에 대한 사용자 만족도부터 retriever의 recall까지. 빠르고 효율적으로 도는가뿐 아니라, 결과가 정한 품질 기준을 충족하는지도 알아야 한다.

그림 1. 핵심 지표 — 소프트웨어 성능(latency·throughput·memory) + 품질(만족도·recall).

 

 

 

2. 어떻게 수집·보고하나

수집·보고 방식도 중요하다. ① 집계 통계(aggregate statistics)를 시간에 따라 모아 큰 흐름을 보고 regression을 빠르게 포착한다. ② 상세 로그(detailed logs)를 기록해 개별 프롬프트가 파이프라인을 통과하는 경로를 추적한다(성능 낮은 응답의 원인 파악에 유용). ③ 실험(experimentation)을 가능하게 한다 — 새 모델·시스템 프롬프트·retriever 설정 변경을 안전한 환경의 커스텀 실험이나 A/B 테스트로 검증해, production 반영 여부를 결정한다.

그림 2. 수집·보고 — 집계 통계(추세·regression), 상세 로그(개별 추적), 실험(A/B).

 

 

 

3. 프레임워크 — Scope × Evaluator Type

지표를 정리하는 좋은 틀은 scope(범위)와 evaluator type(평가자 유형)이다. scope는 평가가 component를 대상으로 하는지 전체 시스템을 대상으로 하는지, evaluator type은 평가가 code-based인지 LLM-as-a-judge인지 human feedback인지를 묻는다. 이 두 축이 grid를 만들고, 각 eval이 한 칸에 위치한다.

그림 3. Scope(component/system) × Evaluator type(code·LLM·human)의 격자.

 

system-level eval은 전체 성능을 요약·조망하고, component-level eval은 개별 문제의 원인을 디버그한다. 예로 전체 latency가 너무 높으면, 원인이 retriever인지 LLM인지 다른 component인지 찾으려면 component-level eval이 필요하다.

 

 

 

4. Evaluator Type 세 가지

Code-based

가장 저렴·단순·직관적이다. 초당 처리 프롬프트 수 기록부터 "LLM이 valid JSON을 내는지" unit test까지. 자동 실행·결정론적·거의 무료라는 점이 핵심이다.

그림 4. Code-based — 가장 저렴하고 자동·결정론적. 코드가 놓치는 것은 못 잡는다.

 

Human feedback

스펙트럼 반대편. 흔한 예가 응답에 thumbs up/down. 상세하진 않아도 down이 늘면 문제 신호다. 텍스트 박스로 상세 피드백을 받을 수도 있다. 또 사람이 프롬프트↔검색돼야 할 문서 데이터셋을 미리 구성해 두면, 이후 precision·recall을 빠르게 계산할 수 있다(초기 구성엔 사람이 필요). 비용은 크지만 code가 놓치는 정보를 포착한다.

그림 5. Human feedback — thumbs·텍스트 피드백·사전 구성 테스트셋(precision/recall). 비싸지만 놓치는 것을 잡음.

 

LLM-as-a-judge

둘의 중간. LLM으로 성능의 여러 요소를 채점한다(예: 검색 문서가 프롬프트와 관련 있는지 판단). code보다 유연하고 human보다 저렴하다. 단, 신중히 조정해야 한다 — 자기 계열 모델 선호 편향이 있고, 명확한 rubric이 필요하며, 0~100 점수보다 relevant/irrelevant 같은 이산 기준에서 잘 작동한다.

그림 6. LLM-as-a-judge — code보다 유연·human보다 저렴. 편향·rubric 주의, 이산 기준이 유리.

 

 

 

5. 실전 지표 세트

시작으로 좋은 조합은 각 주요 component와 전체 시스템에 대해 성능·품질 지표를 모두 모으는 것이다.

 

성능 지표는 code-based라 저렴·쉽고 component·system 양쪽에서 쉽게 잡힌다. 품질 지표는 보통 human annotation이나 LLM-as-a-judge에 의존한다. 이 조합이 전체·개별의 성능·품질을 모두 보게 하고, 싼 eval과 비싼 eval의 균형을 잡아준다.

그림 7. 실전 세트 — 성능은 code-based로, 품질은 human/RAGAS로. component·system 모두 커버. 정리

 

다음 글에서는 이 관측성을 실제로 구현하는 도구 — 로깅·모니터링·관측성(observability) 플랫폼 — 을 살펴본다.