RAG 평가는 검색과 답변을 따로 봐야 한다

RAG는 질문, 검색, 컨텍스트 조립, 답변 생성의 연쇄 시스템이다. 정답이 틀렸다는 결과만 기록하면 어느 단계가 고장 났는지 알 수 없다. 검색 결과에 정답 문서가 없었다면 생성 모델을 바꿔도 해결되지 않는다. 반대로 정답 문서가 들어왔는데 답변이 근거를 벗어났다면 검색 튜닝보다 프롬프트·모델·출력 검증을 손봐야 한다.

테스트셋은 정답보다 실패 조건부터 설계한다

처음부터 수천 건을 만들 필요는 없다. 도입 초기는 핵심 업무 질문 50~100건으로 시작하되 질문 유형을 의도적으로 나누는 편이 실용적이다. 단순 사실 조회만 넣으면 실제 서비스의 긴 질문, 모호한 표현, 문서에 답이 없는 질문을 놓친다. 이후 운영 로그에서 실패 사례를 골라 테스트셋을 늘린다.

1. 정답이 한 문서에 있는 질문: 기본 검색 성능을 확인한다.
2. 여러 문서를 조합해야 하는 질문: 다중 근거 회수와 합성을 확인한다.
3. 문서에 답이 없는 질문: 근거 없는 생성 대신 모른다고 답하는지 본다.
4. 날짜·버전이 충돌하는 질문: 최신 문서 우선순위와 메타데이터 필터를 본다.
5. 오탈자·약어·한국어와 영어가 섞인 질문: 실제 입력 변형에 견디는지 본다.
6. 권한 밖 문서를 묻는 질문: 검색 단계에서 접근 제어가 지켜지는지 본다.

각 행에는 질문, 기대 답변, 관련 문서 ID, 반드시 포함할 사실, 허용 가능한 변형, 중요도, 실패 유형을 저장한다. 정답 문서 라벨이 없으면 검색 Recall을 계산할 수 없으므로 최소한 핵심 질문에는 관련 문서 ID를 사람이 붙이는 것이 좋다.

{
  "question": "환불 요청 가능 기간은?",
  "reference_answer": "수령 후 7일 이내",
  "relevant_doc_ids": ["policy-2026-08"],
  "must_include": ["7일"],
  "risk": "high",
  "expected_behavior": "answer_with_citation"
}

검색 품질은 Recall@K 하나로 끝나지 않는다

검색 평가는 관련 문서 라벨이 있을 때 가장 명확하다. Pinecone의 정보검색 평가 설명처럼 Recall@K는 관련 문서를 얼마나 놓치지 않았는지, MRR은 첫 관련 결과가 얼마나 위에 있는지, nDCG는 여러 결과의 관련도와 순서를 함께 본다. 서비스 목적에 따라 우선순위가 달라진다.

실무에서는 Recall@K를 먼저 확보한 뒤 Precision과 지연·토큰 비용을 함께 줄이는 순서가 안전하다. 정답 문서를 못 가져오는 상태에서 컨텍스트를 짧게 만드는 것은 품질 개선이 아니라 근거 삭제가 될 수 있다. 검색 구조 자체를 설계하는 단계라면 GraphRAG와 벡터 검색의 차이도 함께 확인할 수 있다.

답변 평가는 근거성·관련성·정확성을 분리한다

LangSmith 공식 RAG 평가 튜토리얼은 답변과 정답의 정확성, 답변과 질문의 관련성, 답변과 검색 문서의 근거성, 검색 문서와 질문의 관련성을 서로 다른 비교로 정의한다. 이 분리가 중요하다. 근거에는 충실하지만 질문에 답하지 않는 문장도 있고, 그럴듯하고 유용하지만 문서에 없는 사실을 덧붙인 답변도 있기 때문이다.

평가 항목	비교 대상	판정 질문
정확성	생성 답변 기준 답변	필수 사실이 맞고 충돌하는 내용이 없는가
답변 관련성	생성 답변 사용자 질문	질문을 직접 해결하며 불필요하게 벗어나지 않는가
근거성	생성 답변 검색 문서	답변의 주장마다 검색 문서에서 근거를 찾을 수 있는가
검색 관련성	검색 문서 사용자 질문	가져온 문서가 질문 해결에 실제로 필요한가
거절 품질	답변 문서 부재·정책	근거가 없거나 권한이 없을 때 안전하게 중단하는가

Ragas도 Context Precision·Context Recall·Response Relevancy·Faithfulness 같은 RAG 전용 지표를 제공한다. 다만 도구가 내놓은 0~1 점수를 절대적인 품질로 해석하면 안 된다. OpenAI 평가 가이드도 자동 지표를 사람 판단으로 보정하고, 실제 분포를 반영한 과업별 평가를 만들며, 변경 때마다 지속 평가할 것을 권한다.

최소 운영 절차는 7단계면 충분하다

1. 성공 기준을 먼저 쓴다. 예를 들어 핵심 정책 질문은 관련 문서가 상위 5개 안에 있어야 하고, 답변은 문서에 없는 숫자를 만들면 실패로 정의한다.
2. 실제 질문을 유형별로 모은다. 정상·경계·적대·답 없음 질문을 섞는다.
3. 관련 문서와 기준 답변을 라벨링한다. 위험도가 높은 질문부터 사람이 검수한다.
4. 검색기를 단독 실행한다. 답변 모델을 호출하기 전에 Recall@K·MRR·지연을 저장한다.
5. 생성기를 고정된 검색 결과로 평가한다. 검색 변동과 답변 변동을 분리한다.
6. 자동 심사와 사람 판정을 맞춘다. 불일치 사례를 보고 루브릭과 예시를 보완한다.
7. 모든 변경에서 회귀 테스트한다. 임베딩, 청킹, 프롬프트, 모델, 재랭커 변경 전후를 같은 데이터셋으로 비교한다.

평가 결과를 실행 단위 trace와 연결하면 원인 분석이 빨라진다. 검색 결과, 프롬프트 버전, 모델, 토큰, 지연, 평가 점수를 함께 남기는 방법은 AI 에이전트 관측 도구 비교와 AI 에이전트 비용 추적 가이드에서 이어서 볼 수 있다.

점수 조합으로 실패 원인을 좁힌다

비용과 보안도 평가 설계에 포함한다

LLM 심사기를 모든 운영 요청에 붙이면 품질 점검 비용과 지연이 커진다. 배포 전에는 전체 회귀 세트를 돌리고, 운영 중에는 위험도 기반 표본 추출과 실패 감지 후 재평가를 섞는 방식이 현실적이다. 규칙으로 판정 가능한 인용 유무·JSON 스키마·금칙어·문서 ID 일치 여부는 코드 평가기로 처리하고, 의미 판단이 필요한 항목만 LLM 심사기에 맡긴다.

외부 평가 서비스나 심사 모델로 질문·검색 문서·답변을 보내면 개인정보와 사내 문서가 함께 반출될 수 있다. 운영 전 데이터 보존 정책, 학습 사용 여부, 리전, 암호화, 접근 제어를 확인해야 한다. 테스트셋에는 고객 식별자를 가명 처리하고, 권한 필터가 적용된 문서만 평가 파이프라인에 전달한다.

FAQ

정답 데이터가 없어도 RAG 평가를 시작할 수 있나?

가능하다. 질문과 답변의 관련성, 답변과 검색 문서의 근거성, 질문과 검색 문서의 관련성은 기준 답변 없이도 LLM 심사나 사람 검토로 볼 수 있다. 다만 검색 Recall과 최종 정확성을 신뢰성 있게 측정하려면 핵심 질문부터 관련 문서와 기준 답변을 붙여야 한다.

Ragas와 LangSmith 중 무엇을 써야 하나?

Ragas는 코드 중심으로 RAG 지표를 조합하고 자체 파이프라인에 넣을 때 편하다. LangSmith는 데이터셋, 실험 비교, trace와 평가를 관리형 워크플로로 묶고 싶을 때 유리하다. 도구보다 먼저 평가 데이터 스키마와 합격 기준을 정해야 나중에 교체하기 쉽다.

RAG 품질의 합격 점수는 몇 점으로 잡아야 하나?

모든 서비스에 통하는 단일 점수는 없다. 현재 시스템의 기준선을 같은 테스트셋에서 측정하고, 핵심 질문의 실패 허용치와 안전 관련 실패 0건 같은 운영 기준을 먼저 둔다. 평균점수 상승보다 기존 정상 사례를 깨뜨리지 않았는지와 고위험 질문 실패가 줄었는지를 우선한다.

참고자료

• Ragas 공식 문서: RAG 평가 지표 목록
• Ragas 공식 문서: Context Precision
• Ragas 공식 문서: Faithfulness
• LangSmith 공식 문서: Evaluate a RAG application
• OpenAI 공식 문서: Evaluation best practices
• Pinecone: Evaluation Measures in Information Retrieval

자료와 문서 경로는 2026년 8월 19일 확인했다.

The post RAG 평가 실무 가이드: 검색 품질과 답변 품질을 분리하는 법 appeared first on .

왜 AI 기능은 감으로 평가하면 안 되나

일반 소프트웨어는 함수 입력과 출력이 비교적 명확하다. 테스트가 통과하면 같은 입력에 같은 결과를 기대할 수 있다. 반면 LLM 기능은 모델 버전, 프롬프트, 컨텍스트, 검색 결과, temperature, 도구 호출 상태에 따라 답변이 달라진다. 한두 번 직접 질문해 보고 “괜찮다”고 판단하면 배포 후 다른 질문에서 깨질 가능성이 크다.

특히 RAG나 AI 에이전트는 실패 지점이 많다. 검색이 틀릴 수도 있고, 문서를 맞게 찾았지만 요약을 잘못할 수도 있고, 도구 호출 인자를 잘못 만들 수도 있고, 안전 정책을 우회할 수도 있다. 그래서 평가도 답변 문장 하나가 아니라 전체 실행 흐름을 봐야 한다.

AI Evals의 기본 구성

Golden dataset부터 만든다

AI Evals의 출발점은 golden dataset이다. 이것은 “우리 서비스가 반드시 잘 답해야 하는 대표 질문 모음”이다. 처음부터 수천 개를 만들 필요는 없다. 실제 사용자 질문, 고객 지원 이력, 운영 실패 사례, 개발자가 만든 엣지 케이스에서 20~50개를 골라 시작하면 된다.

• 자주 들어오는 대표 질문
• 비즈니스상 틀리면 안 되는 질문
• 검색 문서가 여러 개 필요한 질문
• 과거에 hallucination이 발생한 질문
• 정책상 답하면 안 되는 질문
• 모델이 헷갈리기 쉬운 동음이의어와 경계 조건

평가 방식 3가지: 규칙, 사람, LLM-as-judge

실무에서는 세 방식을 섞는 편이 좋다. 예를 들어 JSON 출력 형식은 rule-based로 확인하고, 답변 품질은 LLM-as-judge로 1차 평가하고, 실패 샘플은 사람이 검수한다. 중요한 고위험 항목은 자동 평가 점수가 높아도 사람 검수를 통과해야 한다.

RAG 평가에서 봐야 할 항목

RAG 평가는 일반 챗봇 평가와 다르다. 최종 답변만 맞아 보인다고 좋은 RAG가 아니다. 검색된 문서가 적절했는지, 답변이 문서 근거에 충실한지, 없는 내용을 만들지 않았는지까지 확인해야 한다.

AI 에이전트 평가는 도구 실행까지 본다

AI 에이전트는 답변만 생성하지 않는다. 파일을 읽고, 코드를 수정하고, 터미널을 실행하고, 브라우저나 외부 API를 조작한다. 따라서 에이전트 eval은 최종 답변보다 실행 과정이 중요하다. 잘못된 도구를 호출했는지, 실패 후 복구했는지, 사용자 승인이 필요한 작업을 멋대로 실행하지 않았는지 확인해야 한다.

• 올바른 도구를 선택했는가
• 도구 인자를 안전하게 만들었는가
• 실패 로그를 보고 다른 전략으로 복구했는가
• 테스트를 실제로 실행했는가
• 권한이 필요한 작업에서 승인 절차를 지켰는가
• 최종 산출물이 요구사항을 만족하는가

작은 팀용 AI Evals 시작 순서

1. 실제 사용자 질문과 실패 사례를 20~50개 모은다.
2. 각 질문마다 반드시 포함할 내용과 금지할 내용을 적는다.
3. 정확성, 근거성, 완전성, 안전성을 1~5점 rubric으로 만든다.
4. rule-based 체크와 LLM-as-judge 평가를 섞어 자동화한다.
5. 배포 전 같은 eval을 실행해 이전 버전과 비교한다.
6. 운영 중 나온 실패 사례를 다시 dataset에 추가한다.

평가 결과는 평균 점수만 보면 안 된다

평균 점수는 위험하다. 100개 중 95개가 좋아도, 나머지 5개가 결제, 의료, 법률, 보안, 개인정보 같은 고위험 질문이면 배포하면 안 된다. eval 결과는 전체 평균, 카테고리별 점수, 고위험 테스트 통과율, 실패 유형을 따로 봐야 한다.

AI Evals 체크리스트

• 대표 질문 세트가 실제 사용자 질문을 반영하는가
• 정답 기준과 금지 기준이 문서화돼 있는가
• RAG 검색 품질과 최종 답변 품질을 분리해 평가하는가
• LLM-as-judge 결과를 사람 샘플 검수로 보정하는가
• 모델, 프롬프트, 인덱스 변경 전후를 비교하는가
• 고위험 질문은 별도 차단 기준을 두는가
• 실패 사례를 dataset에 계속 되돌리는가

FAQ

AI Evals는 무엇인가?

AI Evals는 LLM 애플리케이션의 답변 품질, 안정성, 근거성, 안전성을 테스트셋과 채점 기준으로 반복 측정하는 평가 체계다. 일반 소프트웨어 테스트처럼 AI 기능에도 회귀 테스트와 품질 기준을 두는 접근이다.

LLM-as-judge는 믿을 수 있는가?

LLM-as-judge는 빠르고 유연하지만 절대 기준은 아니다. 명확한 rubric, 샘플 검수, 사람 평가와의 일치도 확인, 모델 변경 시 재검증이 필요하다.

RAG 평가와 일반 챗봇 평가는 무엇이 다른가?

RAG 평가는 답변만 보지 않는다. 검색된 문서가 적절한지, 답변이 근거 문서에 충실한지, 인용이 맞는지, 없는 내용을 만들지 않았는지까지 함께 평가한다.

작은 팀도 AI Evals가 필요한가?

필요하다. 처음에는 20~50개의 대표 질문과 간단한 pass/fail 기준만 있어도 충분하다. 중요한 것은 배포 전 같은 질문을 반복 실행해 품질이 나빠졌는지 확인하는 습관이다.

AI Evals는 한 번 만들면 끝인가?

아니다. 사용자 질문, 실패 사례, 정책 변경, 모델 변경에 따라 계속 업데이트해야 한다. 실제 운영 로그에서 실패 사례를 골든 데이터셋으로 되돌리는 루프가 중요하다.

참고 자료

• OpenAI Evals guide
• LangSmith Evaluation documentation
• Google Cloud Gen AI evaluation service overview
• Microsoft Foundry generative AI evaluation approach
• DeepLearning.AI Evaluating and Debugging Generative AI

The post AI Evals 실무 가이드: LLM 답변 품질을 감으로 평가하지 않는 방법 appeared first on .