RAG는 화면에 답이 잘 나오는지만 보면 안 됩니다. 검색이 제대로 됐는지, 어떤 문서가 근거였는지, 답변이 실제로 grounded 되었는지까지 같이 봐야 합니다.
이 글은 RAG 모니터링을 운영 관점에서 정리하고, 무엇을 메트릭으로 봐야 하는지 설명합니다.
개요 #
RAG 모니터링은 모델 모니터링과 다릅니다. 모델 자체보다 검색 계층과 문서 계층의 이상 징후를 더 빨리 포착해야 합니다.
핵심 질문은 다음과 같습니다.
- 검색이 올바른 문서를 가져오는가
- 답변이 근거를 유지하는가
- latency와 cost가 정상 범위인가
- 실패가 반복되는 query가 있는가
왜 중요한가 #
모니터링이 없으면 RAG는 점점 품질이 떨어져도 알아차리기 어렵습니다.
- retrieval 실패가 늘어나도 답변만 보면 그럴듯하다
- 특정 query에서 hallucination이 반복된다
- 최신 문서보다 예전 문서가 자주 선택된다
- 비용이 증가해도 원인을 찾기 어렵다
이런 상황은 RAG Evaluation과 Retrieval Quality Metrics를 운영에 붙이지 않으면 더 빨리 악화됩니다.
운영 포인트 #
모니터링은 네 계층으로 보는 것이 실용적입니다.
- Query layer: 질의 유형, 실패 패턴, fallback 발생률
- Retrieval layer: top-k hit rate, recall, reranking 결과
- Generation layer: groundedness, citation coverage, answer length
- System layer: latency, token cost, timeout, error rate
운영 도구는 RAG Ops 기준으로 묶고, 검색 계층은 Qdrant Cloud와 Hybrid Search 관점으로 보는 것이 좋습니다.
아키텍처 도식 #
기본 흐름은 다음과 같습니다.
- query 로그 수집
- retrieval trace 저장
- answer trace 저장
- 품질 지표 계산
- 이상 징후 알림
- 회귀 분석
trace가 남지 않으면 지표는 있어도 원인을 못 찾습니다. 그래서 모니터링은 로그보다 trace 중심으로 설계하는 편이 낫습니다.
체크리스트 #
- query, retrieval, answer trace가 연결되는가
- 실패 query가 반복적으로 식별되는가
- latency와 cost를 같은 대시보드에서 보는가
- grounding failure를 따로 알리는가
- 최신 문서 미반영 사례를 추적하는가
- 평가 데이터셋과 운영 지표가 연결되는가
결론 #
RAG 모니터링의 목적은 장애를 찾는 것만이 아닙니다. 품질이 서서히 무너지는 순간을 먼저 포착하는 데 있습니다.
검색 품질, 답변 품질, 비용, latency를 같이 보면 개선 우선순위가 명확해집니다.