TestForge Blog
← 전체 포스트
#ai #rag #operations #evaluation #llm

RAG 개발 5편 - 평가, 관측성, 운영 안정화까지 프로덕션 관점으로 보기

RAG를 운영 단계로 올리려면 답변 품질을 어떻게 평가하고 어떤 로그를 남기며 어디서 병목이 나는지 봐야 합니다. retrieval 평가, groundedness, latency, feedback loop, 운영 체크리스트까지 정리합니다.

TestForge Team ·

RAG는 데모와 운영이 다르다

처음에는 몇 개 질문에 잘 답하면 성공처럼 보입니다. 하지만 실제 서비스에서는 다음 문제가 곧 드러납니다.

  • 어떤 질문에는 매우 좋고 어떤 질문에는 급격히 약함
  • 문서가 갱신된 후 품질이 흔들림
  • 응답 지연시간이 길어짐
  • 잘못된 출처가 붙음
  • 사용자가 답변을 신뢰하지 않음

그래서 RAG는 검색과 생성만이 아니라 평가와 운영 체계를 함께 가져가야 합니다.

무엇을 평가해야 할까

최소한 세 층으로 나눠서 봐야 합니다.

1. Retrieval quality

정답 문서를 잘 가져오는가

대표 지표:

  • Recall@k
  • Precision@k
  • MRR
  • NDCG

2. Answer quality

생성된 답변이 실제 문서 근거에 맞는가

대표 지표:

  • groundedness
  • citation accuracy
  • hallucination rate
  • completeness

3. System quality

운영 가능한 수준인가

대표 지표:

  • end-to-end latency
  • retrieval latency
  • token usage
  • error rate
  • fallback rate

평가셋은 어떻게 만들까

좋은 평가셋 없이는 개선도 어렵습니다.

추천 형식:

{
  "question": "토큰 재발급 API는 어떤 경우에 호출되나요?",
  "expected_doc_ids": ["auth-guide", "auth-errors"],
  "must_include": ["refresh token", "만료", "재발급"],
  "must_not_include": ["비밀번호 재설정"],
  "answer_type": "procedural"
}

질문 유형도 다양하게 넣어야 합니다.

  • 정의형 질문
  • 절차형 질문
  • 비교형 질문
  • 장애 대응 질문
  • 모호한 질문
  • 최신성 민감 질문

retrieval 평가는 분리해서 보자

LLM 최종 답변만 보면 검색 문제가 가려집니다.

예를 들어 답변이 나쁘다고 해서 꼭 generation 문제는 아닙니다.

  • 정답 문서를 못 찾았는지
  • 찾았는데 순위가 낮았는지
  • 순위는 맞았는데 LLM이 잘못 사용했는지

이걸 분리해야 개선 포인트가 보입니다.

groundedness는 어떻게 볼까

답변이 문서 근거에 실제로 기반했는지 확인해야 합니다.

간단한 방법:

  • 답변 문장을 출처 문서와 대조
  • 출처 없는 단정 표현 탐지
  • 문서에 없는 엔티티 등장 여부 확인

질문:

토큰은 24시간 후 만료되나요?

검색 문서에 24시간 정보가 없는데 답변이 “24시간 후 만료됩니다”라고 말하면 groundedness 실패입니다.

운영 로그는 무엇을 남겨야 하나

실무에서는 아래 로그가 꼭 필요합니다.

  • 원문 질문
  • rewrite된 질문
  • 사용된 필터
  • retrieval top-k 결과
  • rerank 결과
  • 최종 선택 chunk
  • 프롬프트 크기
  • 모델명
  • 응답 시간
  • citations
  • fallback 여부

이 정보가 없으면 품질 이슈가 발생했을 때 원인을 재현하기 어렵습니다.

latency 병목은 대개 여러 군데에 있다

RAG 지연시간은 한 단계에서만 생기지 않습니다.

대표 병목:

  • query rewrite 모델 호출
  • vector DB 조회
  • reranker 호출
  • LLM 생성 시간
  • post-processing

예:

Query rewrite: 120ms
Retrieval: 80ms
Reranking: 140ms
LLM generation: 900ms
Post-process: 40ms
Total: 1280ms

이렇게 분해해서 봐야 어디를 줄일지 판단할 수 있습니다.

문서 갱신과 재색인도 운영 지표다

문서가 바뀌었는데 검색 인덱스에 반영되기까지 너무 오래 걸리면 RAG는 금방 낡아집니다.

봐야 할 지표:

  • 문서 변경 감지 지연
  • chunk 생성 지연
  • embedding 생성 실패율
  • 인덱스 반영 완료 시각

특히 운영 가이드나 정책 문서는 최신성이 매우 중요합니다.

사용자 피드백 루프 만들기

정량 지표만으로는 한계가 있습니다.

실무에서 유용한 피드백:

  • 도움이 됨 / 안 됨
  • 출처가 적절했는지
  • 답변이 장황했는지
  • 실제 문제 해결에 도움이 되었는지

피드백은 그대로 재학습 데이터로 쓰기보다, 먼저 오류 유형 분류에 활용하는 편이 좋습니다.

운영 중 자주 만나는 문제

문서 업데이트 후 품질 하락

청킹 규칙 변경이나 메타데이터 손실이 숨어 있을 수 있습니다.

특정 카테고리 질문만 약함

해당 문서군의 품질 문제이거나, query rewrite가 특정 용어를 잘 못 다루는 경우가 많습니다.

citation이 엉뚱하게 붙음

chunk 선택과 답변 문장 매핑 로직을 다시 봐야 합니다.

latency가 점점 증가

top-k 증가, reranker 추가, 더 긴 프롬프트 등이 누적 원인일 수 있습니다.

추천 대시보드

운영 초기에는 아래 정도만 보여도 충분합니다.

  • 질문 수
  • 평균 응답 시간
  • fallback 비율
  • top-k retrieval 성공률
  • citation 포함 비율
  • 사용자 피드백 점수
  • 카테고리별 실패율

여기서 이상치를 빨리 발견하는 것이 중요합니다.

프로덕션 체크리스트

  • 평가셋이 있는가
  • retrieval과 generation을 분리 측정하는가
  • 문서 변경 후 재색인 파이프라인이 있는가
  • latency breakdown을 보는가
  • 출처 정확도를 검증하는가
  • fallback 로직이 있는가
  • 사용자 피드백 루프가 있는가

마무리

RAG를 프로덕션으로 올린다는 것은 검색과 생성 기능을 만드는 것보다, 그 품질을 계속 측정하고 흔들림을 줄이는 체계를 만드는 일에 가깝습니다.

좋은 운영 체계는 아래를 반복합니다.

  • 문서가 바뀌면 다시 색인하고
  • 검색 로그를 보고 실패를 분류하고
  • 평가셋으로 비교 실험하고
  • 출처 정확도와 latency를 함께 추적합니다

이 단계까지 갖춰져야 RAG가 데모를 넘어 실제 서비스 자산이 됩니다.