RAG의 평가와 개선

RAG는 만든 뒤부터 좋아진다

RAG 시스템은 한 번 구축하고 끝나는 기능이 아닙니다. 문서가 늘어나고, 사용자의 질문이 쌓이고, 실패 사례가 보이면서 계속 좋아지는 제품입니다. 처음부터 완벽한 청킹, 완벽한 검색식, 완벽한 프롬프트를 만들기는 어렵습니다. 중요한 것은 품질을 측정할 기준을 만들고, 실패를 기록하고, 작은 단위로 개선하는 루프를 갖추는 일입니다.

평가는 크게 두 가지로 나눌 수 있습니다. 하나는 "필요한 문서를 잘 찾았는가"를 보는 검색 평가입니다. 다른 하나는 "찾은 문서를 바탕으로 좋은 답변을 만들었는가"를 보는 답변 평가입니다. 이 둘을 분리해서 봐야 원인을 정확히 찾을 수 있습니다.

검색 품질 평가하기

검색 평가는 질문에 대해 정답이 되는 문서 조각이 검색 결과 상위에 들어오는지 확인하는 과정입니다. 예를 들어 사용자가 "환불 정책은 며칠까지 가능한가요?"라고 물었을 때, 환불 정책이 적힌 청크가 Top 5 안에 들어와야 합니다.

가장 자주 쓰는 관점은 Recall@K입니다. K개를 가져왔을 때 그 안에 정답 문서가 포함되는지를 봅니다. Recall@5가 높다는 것은 상위 5개 결과 안에 필요한 근거가 잘 들어온다는 뜻입니다. RAG에서는 답변 모델이 검색 결과 안에서만 판단하므로 Recall이 특히 중요합니다.

Precision은 가져온 결과 중 실제로 유용한 문서의 비율을 봅니다. 관련 없는 청크가 많이 섞이면 모델은 혼란스러워지고 답변도 길어지거나 흐려집니다. MRR은 정답 문서가 몇 번째에 나오는지를 보는 지표입니다. 정답이 1등에 가까울수록 좋은 검색입니다.

실무에서는 모든 질문에 복잡한 지표를 붙이기보다, 대표 질문 세트를 먼저 만듭니다. 자주 들어오는 질문, 중요한 정책 질문, 사용자가 틀리면 안 되는 질문을 모아 테스트셋으로 삼습니다. 그리고 청킹, 임베딩 모델, Hybrid Search, Reranking을 바꿀 때마다 같은 질문으로 비교합니다.

답변 품질 평가하기

검색 결과가 좋아도 답변이 항상 좋은 것은 아닙니다. 답변 평가는 세 가지 질문으로 시작하면 충분합니다.

첫째, 질문에 직접 답했는가. 사용자가 묻지 않은 배경 설명만 길게 늘어놓으면 좋은 답변이 아닙니다. 둘째, 근거 문서와 일치하는가. 문서에 없는 내용을 그럴듯하게 덧붙이면 환각입니다. 셋째, 불확실한 내용을 단정하지 않았는가. 문서에 근거가 부족하면 "제공된 문서에서는 확인할 수 없습니다"라고 말해야 합니다.

이 기준은 점수표로 만들 수 있습니다. 예를 들어 답변 정확성, 근거 일치성, 출처 적절성, 간결성을 각각 1~5점으로 평가합니다. 자동 평가를 붙일 수도 있지만, 초기에는 사람이 직접 몇십 개의 대표 질문을 읽어보는 것이 더 빠르고 정확합니다. 특히 회사 정책, 법률, 의료, 금융처럼 오답 비용이 큰 영역에서는 사람이 보는 검수 과정이 필요합니다.

환각을 줄이는 방법

환각을 줄이려면 모델에게 "아는 척하지 말라"고 말하는 것만으로는 부족합니다. 시스템 구조가 근거 중심으로 설계되어야 합니다.

프롬프트에는 답변 규칙을 명확히 넣습니다. "아래 문서에 있는 내용만 사용하라", "근거가 없으면 모른다고 답하라", "답변 끝에 사용한 출처를 표시하라"처럼 행동을 제한합니다. 검색 결과에는 청크 내용뿐 아니라 제목, 섹션, 날짜 같은 메타데이터도 함께 넣어야 합니다. 그래야 모델이 어떤 문서를 근거로 삼는지 판단하기 쉽습니다.

낮은 신뢰도 응답 처리도 중요합니다. 검색 점수가 너무 낮거나, 관련 문서가 거의 없거나, 여러 문서가 서로 충돌한다면 바로 답변을 생성하지 않는 편이 낫습니다. 이때는 "관련 문서를 찾지 못했습니다", "질문을 조금 더 구체적으로 입력해 주세요", "다음 문서 중 어느 범위를 기준으로 할까요?"처럼 안전한 응답을 제공합니다.

출처 검증 단계도 둘 수 있습니다. 답변 문장마다 어떤 청크를 근거로 했는지 연결하고, 출처 없는 핵심 주장에는 경고를 표시합니다. 사용자가 신뢰하는 RAG는 말을 잘하는 시스템이 아니라, 근거를 확인할 수 있는 시스템입니다.

실패 로그에서 개선점 찾기

좋은 RAG 운영은 로그에서 시작됩니다. 최소한 사용자의 질문, 검색된 청크, 검색 점수, 최종 답변, 클릭한 출처, 재질문 여부, 사용자 피드백을 남겨야 합니다. 이 정보가 있어야 어디서 실패했는지 알 수 있습니다.

검색 실패는 여러 형태로 나타납니다. 정답 문서가 아예 검색되지 않았다면 청킹, 임베딩, 키워드 검색, 메타데이터 필터를 점검해야 합니다. 정답 문서는 있었지만 너무 아래에 있었다면 Reranking이나 점수 결합 방식을 개선할 수 있습니다. 검색은 잘됐는데 답변이 틀렸다면 프롬프트, 컨텍스트 구성, 출처 연결 방식을 봐야 합니다.

사용자의 재질문 패턴도 중요한 신호입니다. 같은 질문을 표현만 바꿔 다시 묻는다면 첫 답변이 부족했을 가능성이 큽니다. 사용자가 특정 출처를 자주 클릭한다면 그 문서는 중요한 근거입니다. 반대로 검색 결과에는 자주 나오지만 클릭되지 않는 문서는 관련성이 낮을 수 있습니다.

지속적으로 좋아지는 지식베이스

RAG의 개선은 운영 루프로 설계해야 합니다. 새 문서가 추가되면 자동으로 전처리하고, 청킹하고, 임베딩하여 인덱스에 반영합니다. 오래된 문서는 갱신 날짜를 기준으로 다시 임베딩하거나 검색 우선순위를 낮춥니다. 삭제된 문서나 권한이 바뀐 문서는 검색 결과에 남지 않도록 동기화해야 합니다.

사용자 피드백은 개선의 연료입니다. "도움 됨", "도움 안 됨" 같은 단순한 버튼도 충분히 의미가 있습니다. 다만 피드백을 모으는 것에서 끝나면 안 됩니다. 부정 피드백이 많은 질문을 모아 원인을 분류하고, 문서 보강, 청킹 수정, 메타데이터 추가, 검색식 조정으로 연결해야 합니다.

결국 좋은 RAG는 모델 하나로 완성되지 않습니다. 문서 품질, 검색 품질, 답변 규칙, 출처 표시, 로그 분석이 함께 맞물려야 합니다. 질문과 문서가 쌓일수록 더 정확해지는 구조를 만들 때, RAG는 단순한 챗봇이 아니라 살아 있는 AI 지식베이스가 됩니다.