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 .

RAG가 먼저 해결한 문제

RAG는 Retrieval-Augmented Generation의 약자다. LLM이 내부 파라미터에만 의존하지 않고, 외부 문서에서 관련 내용을 검색한 뒤 그 근거를 바탕으로 답변하게 만드는 방식이다. 회사 문서, 정책 자료, 기술 문서, 고객 지원 문서처럼 모델 학습 시점 이후의 지식이나 비공개 지식을 다룰 때 유용하다.

가장 흔한 구현은 문서를 작은 청크로 나누고 embedding을 만든 뒤 벡터 DB에 저장하는 방식이다. 사용자가 질문하면 질문도 embedding으로 바꾸고, 벡터 공간에서 가까운 청크를 찾아 LLM에 넣는다. 이 방식은 간단하고 강력하지만 모든 질문에 충분하지는 않다.

벡터 검색만으로 부족한 순간

벡터 검색은 의미적으로 비슷한 문장을 찾는 데 강하다. 그러나 질문이 여러 문서에 흩어진 관계를 묻거나, 특정 엔티티가 전체 데이터 안에서 어떤 역할을 하는지 묻거나, 여러 사건을 묶어 상위 패턴을 요약해야 할 때는 한계가 드러난다.

GraphRAG의 기본 구조

GraphRAG는 문서를 단순히 청크로만 저장하지 않는다. 문서에서 사람, 조직, 장소, 제품, 개념, 사건 같은 엔티티를 추출하고, 엔티티 사이의 관계를 edge로 연결한다. 이후 이 그래프를 요약하거나 커뮤니티로 나누고, 질문에 맞는 노드와 관계를 찾아 LLM에 제공한다.

Local search와 Global search

Microsoft Research의 GraphRAG 연구는 query-focused summarization 문제에서 local search와 global search 관점을 제시한다. local search는 특정 엔티티나 좁은 주제 주변의 근거를 찾는 데 유리하다. global search는 전체 데이터셋에서 넓은 패턴이나 주제를 요약할 때 유리하다.

GraphRAG가 유리한 데이터

• 조직, 팀, 서비스, 고객, 계약처럼 엔티티 관계가 중요한 업무 문서
• 사건, 원인, 영향, 대응이 여러 문서에 흩어진 장애 보고서
• 논문, 특허, 기술 리포트처럼 개념 간 연결이 중요한 지식 데이터
• 뉴스, 정책, 법령처럼 사람과 기관, 시점, 사건의 관계가 중요한 문서
• 고객 지원 기록처럼 같은 문제가 다른 표현으로 반복되는 데이터

GraphRAG가 과한 경우

GraphRAG는 만능이 아니다. 단순한 FAQ, 짧은 제품 문서, 키워드 검색으로 충분한 데이터, 실시간성이 강해 그래프를 자주 다시 만들어야 하는 데이터에는 비용 대비 효과가 낮을 수 있다. 그래프 구축에는 LLM 호출 비용, 엔티티 정제, 관계 품질 검증, 인덱싱 시간이 들어간다.

따라서 처음부터 GraphRAG를 도입하기보다 일반 RAG로 시작하고, 실패 사례를 모아야 한다. “관련 문서는 찾았지만 관계를 설명하지 못한다”, “전체 문서 컬렉션의 패턴을 요약하지 못한다”, “동일 엔티티가 여러 이름으로 흩어진다” 같은 문제가 반복될 때 GraphRAG를 검토하는 편이 현실적이다.

일반 RAG, GraphRAG, Knowledge Graph의 관계

작게 시작하는 GraphRAG 설계

작은 팀이 GraphRAG를 실험한다면 전체 시스템을 한 번에 바꾸지 않는 편이 좋다. 먼저 기존 RAG에서 실패한 질문 20~50개를 모은다. 그다음 해당 질문이 엔티티 관계 문제인지, 전체 요약 문제인지, 검색 품질 문제인지 분류한다. GraphRAG는 이 중 관계와 전체 요약 문제가 반복될 때 도입 가치가 커진다.

1. 기존 RAG 실패 질문을 수집한다.
2. 반복적으로 등장하는 엔티티 유형을 정의한다.
3. 문서 일부로 작은 지식 그래프를 만든다.
4. local search와 global summary 질문을 따로 평가한다.
5. 일반 RAG 답변과 GraphRAG 답변을 같은 질문 세트로 비교한다.
6. 정확도뿐 아니라 비용, 지연 시간, 운영 복잡도도 함께 본다.

GraphRAG 체크리스트

• 질문이 단순 문서 검색인지 관계 분석인지 구분했는가
• 추출할 엔티티 유형과 관계 유형을 정의했는가
• 그래프 생성에 드는 LLM 비용을 계산했는가
• 그래프 업데이트 주기와 재인덱싱 비용을 정했는가
• 일반 RAG와 비교할 평가 질문 세트를 만들었는가
• 답변 근거를 사용자에게 어떻게 보여줄지 정했는가
• 잘못 추출된 엔티티와 관계를 수정하는 절차가 있는가

FAQ

GraphRAG는 무엇인가?

GraphRAG는 문서에서 엔티티와 관계를 추출해 지식 그래프를 만들고, 이 그래프를 RAG 검색과 답변 생성에 활용하는 구조다. 벡터 검색만으로 찾기 어려운 관계형 질문이나 전체 요약 질문에 강하다.

GraphRAG와 일반 RAG의 차이는 무엇인가?

일반 RAG는 질문과 비슷한 문서 청크를 벡터 검색으로 찾는 방식이 많다. GraphRAG는 문서 안의 사람, 조직, 개념, 사건, 관계를 그래프로 연결한 뒤 그 구조를 검색과 요약에 함께 사용한다.

GraphRAG를 쓰면 벡터 DB가 필요 없는가?

그렇지 않다. 실제 구현에서는 벡터 검색과 그래프 검색을 함께 쓰는 경우가 많다. 벡터 검색은 의미적으로 가까운 문서를 찾는 데 강하고, 그래프는 엔티티 간 관계와 커뮤니티 구조를 따라가는 데 강하다.

GraphRAG는 언제 과한 선택인가?

문서 수가 적고 질문이 단순 사실 검색 중심이라면 일반 RAG로도 충분하다. GraphRAG는 그래프 구축, 엔티티 정제, 커뮤니티 탐지, 인덱싱 비용이 들기 때문에 관계 분석이 필요한 데이터에서 더 가치가 크다.

Microsoft GraphRAG만이 GraphRAG인가?

아니다. Microsoft GraphRAG는 대표적인 오픈소스 구현과 연구 사례 중 하나다. GraphRAG라는 이름은 더 넓게 그래프 기반 검색 증강 생성 패턴을 가리킬 때도 쓰인다.

참고 자료

• Microsoft Research Project GraphRAG
• Microsoft GraphRAG Documentation
• microsoft/graphrag GitHub repository
• From Local to Global: A Graph RAG Approach to Query-Focused Summarization
• GraphRAG: Unlocking LLM discovery on narrative private data

The post GraphRAG란 무엇인가: 벡터 검색만으로 부족할 때 쓰는 RAG 구조 appeared first on .