2026년 10월 02일 약 3분 소요 작성자 Meydo Editorial Team

RAG 평가: 모델을 탓하기 전에 검색부터 시험하라

문서 재현율과 근거성, 관련성, 완전성을 기준으로 검색 증강 생성 시스템을 구성 요소별로 평가하는 가이드.

Documents moving through retrieval stages toward a grounded answer

검색 증강 시스템의 답이 부실할 때 모델은 가장 나중에 의심해야 할 구성 요소일 수 있다. 출처가 애초에 컨텍스트에 들어오지 않았을 가능성이 있다.

RAG 실패 사슬을 그려라

일반적인 RAG 흐름은 문서를 수집하고 청크로 나누고 메타데이터를 붙인 뒤, 표현을 인덱싱하고 후보를 검색해 모델이 답하도록 한다. 단계별 실패 모습은 다르다. 오래된 수집본, 의미를 훼손한 청킹, 부정확한 순위, 컨텍스트 잘림, 근거 없는 생성 등이 있다.

질의를 문서 버전, 검색된 청크, 점수, 필터, 최종 컨텍스트, 응답까지 연결하는 추적 기록을 남긴다. 이 사슬이 없으면 그럴듯한 답이 고장 난 검색기를 감추고, 틀린 답 때문에 쓸데없이 프롬프트를 고칠 수 있다.

정답 라벨이 있는 질문으로 검색을 측정하라

근거 문서를 알고 있는 질문을 만든다. 필요한 출처가 상위 결과에 등장하는지 측정하고, 순서가 중요하면 순위 지표도 쓴다. Microsoft의 RAG 평가 지침은 문서 검색 지표와 검색된 컨텍스트의 텍스트 품질 판단을 분리한다. 관련성 라벨이 더 정밀한 진단을 가능하게 한다는 점에서 유용한 구분이다.

필터와 권한을 핵심 동작으로 시험한다. 관련성이 있어도 권한이 없는 문서를 찾은 검색기는 답이 맞더라도 실패한 것이다. 중복 페이지, 오래된 개정판, 표, 둘 이상의 청크에서 근거를 모아야 하는 질문도 포함한다.

답변을 서로 독립된 축으로 평가하라

근거성은 주장이 제공된 컨텍스트 안에 머무는지를 본다. 관련성은 질문에 답하는지를, 완전성은 반드시 다뤄야 할 핵심 정보를 포함하는지를 본다. 세 차원은 따로 움직일 수 있다. 조심스러운 답은 근거는 있지만 불완전할 수 있고, 매끄러운 답은 관련성은 높지만 뒷받침이 없을 수 있다.

영향이 큰 용도에서는 구체적인 주장에 인용을 붙이고 각 인용이 근처의 진술을 뒷받침하는지 확인한다. 어느 구절이 어느 결론의 근거인지 알 수 없다면 글 하단의 출처 목록만으로는 충분하지 않다.

경계 조건에 부하를 가하라

코퍼스로 답할 수 없는 질문을 던지고 즉흥적인 답 대신 명시적인 한계를 요구한다. 검색 문서에 심은 프롬프트 인젝션, 충돌하는 버전, 오탈자, 바꿔 말한 질문, 시간에 민감한 질문도 추가한다. 모든 청크를 똑같이 보지 않고 권위와 날짜를 구별하는지 평가한다.

사용자는 한 언어로 묻고 코퍼스는 다른 언어인 경우 언어별 시험을 따로 실행한다. 언어 간 검색은 생성 전에 실패할 수 있으며, 유창한 답변이 그 누락을 감출 수 있다.

진단을 변경으로 연결하라

재현율이 낮으면 수집, 청크 경계, 메타데이터, 임베딩, 질의 재작성을 살핀다. 검색된 근거는 좋은데 근거성이 낮다면 생성 계약과 인용 요건을 바꾼다. 답은 근거가 있지만 불완전하다면 컨텍스트 구성과 여러 문서의 포괄 범위를 다시 본다.

변경 사항은 고정된 세트와 새 홀드아웃 세트 모두에서 비교한다. 익숙한 질문에 과적합되는 것을 막으면서 실제 일반화 가능성을 확인할 수 있다.

실전에 적용하는 방법

먼저 모델을 탓하기 전에 검색을 시험하는 RAG 평가와 관련된, 범위가 명확한 워크플로 하나를 고른다. 시스템을 바꾸기 전에 현재 완료 시간, 품질 검사, 흔한 실패 범주, 에스컬레이션 경로, 결과 담당자를 한 페이지에 정리한다. 가장 깔끔한 사례만 고르지 말고 대표 표본을 선택한다. 일반 사례와 어려운 경계 사례, 그리고 멈추거나 추가 정보를 요청하는 것이 정답인 사례를 최소 하나 포함한다.

후보 시스템이 기존 절차를 대체하도록 허용하기 전에 두 시스템을 나란히 운영한다. 오류율이 낮아져도 영향이 큰 새로운 실패를 감출 수 있으므로 성공한 출력과 실패한 출력을 모두 검토한다. 각 시험에 사용한 정확한 구성을 기록하고, 다른 검토자가 결과를 재현할 수 있는 산출물을 보관한다. 파일럿이 끝나면 가장 인상적인 시연을 보고 뒤늦게 판단하지 말고, 미리 합의한 기준에 따라 확대·수정·중단을 결정한다.

벤더나 내부 팀에 물어볼 질문

핵심 주장을 뒷받침하는 증거가 무엇인지, 그 증거를 만든 시스템과 데이터의 버전은 무엇인지, 어떤 조건이 제외됐는지 묻는다. 실제 배포에서 맞닥뜨릴 언어, 입력 유형, 위험 범주별 결과를 요청한다. 변경 사항을 어떻게 알리고 회귀를 어떻게 탐지하는지, 고객이 사고 검토에 필요한 로그를 내보낼 수 있는지도 확인한다.

확신도가 낮거나 의존성이 실패하거나 요청이 지원 범위를 벗어날 때 시스템이 어떻게 작동하는지도 묻는다. 신뢰할 수 있는 제품에는 더 매끄러운 답변만이 아니라 정의된 실패 상태가 있어야 한다. 책임 주체도 중요하다. 누가 워크플로를 멈출 수 있는지, 누가 예외를 승인하는지, 중대한 오류가 운영 환경으로 빠져나갔을 때 누가 영향받은 사용자에게 알리는지 정한다.