B컷전문 | 개발과 인생의 이야기

사내 고객지원 챗봇에 “배송 중인 주문을 취소할 수 있나요?”라고 물었다. 답은 단정적이고 출처 링크도 붙었다. 그런데 링크를 열어 보니 작년 정책의 일반 취소 규정이었다. 현행 문서에는 배송 중 주문은 담당자 확인이 필요하다고 적혀 있다. 모델이 문장을 매끄럽게 썼는지보다 먼저, 어떤 문서를 찾아 답의 근거로 삼았는지를 확인해야 하는 상황이다.

RAG(Retrieval-Augmented Generation)는 질문에 맞는 외부 자료를 검색해 모델의 답변 맥락으로 제공하는 방식이다. 검색이 틀리면 그럴듯한 답변도 틀릴 수 있다. 반대로 올바른 문서를 찾아도 모델이 조건을 빠뜨릴 수 있다. 따라서 검색 품질, 답변의 근거 충실도, 질문에 대한 유용성을 분리해 다뤄야 한다.

1. 검색과 답변을 한 점수로 합치지 않는다

Microsoft의 RAG 평가 문서는 검색 단계의 문서 검색·맥락 관련성과 최종 답변의 근거성·관련성·완전성을 별도 평가 대상으로 둔다. 검색 결과에 정답 문서가 없으면 생성 프롬프트를 고치는 것만으로 원인을 해결하기 어렵다. 정답 문서가 있어도 답변에서 예외 조건을 누락했다면 생성 단계의 문제다.

확인할 질문	검사 대상	실패 예시
필요한 자료가 검색됐는가?	검색 결과의 문서 ID, 버전, 상위 순위	현행 정책 대신 오래된 FAQ만 상위에 있음
답의 각 주장이 자료에 있는가?	문장별 주장과 해당 원문 구절	“즉시 취소 가능”이라는 조건 없는 단정
질문의 핵심에 답했는가?	예외·보류 조건과 사용자에게 필요한 조치	근거는 맞지만 담당자 확인 절차를 생략

여기서 근거성은 제공된 자료와의 일치를 뜻한다. 자료 자체가 오래되거나 잘못됐으면 근거성 점수가 높아도 업무상 정답은 아닐 수 있다. 문서의 효력과 최신성은 별도로 확인해야 한다.

2. 검색 평가셋에는 정답 문서와 “없음”을 함께 넣는다

대표 질문마다 기대하는 문서 또는 구절을 사람이 확인해 기록한다. 사용자 표현과 문서 용어가 다른 질문, 상품명·정책번호처럼 정확한 문자열이 중요한 질문, 여러 문서를 함께 읽어야 하는 질문을 나눠 담자. 답이 자료에 없는 질문도 넣어야 검색 결과가 없을 때 답을 꾸며 내지 않는지 볼 수 있다.

• 찾기: 필요한 문서가 상위 k개 안에 들어왔는지 사례별로 기록한다. k는 실제 모델에 전달하는 검색 결과 수에 맞춘다.
• 순위: 필요한 문서가 목록 맨 아래에 묻히지 않았는지 본다. 관련성 레이블이 있다면 NDCG 같은 순위 지표를 사용할 수 있다.
• 맥락: 검색된 조각에 적용 대상, 시행일, 예외가 함께 들어 있는지 원문과 대조한다.
• 빈 결과: 근거가 없는 질문에는 충분한 근거가 없다고 표시하는 경로를 시험한다.

Microsoft는 검색용 정답 레이블이 있을 때 문서 검색 지표를, 없을 때는 검색 맥락의 관련성을 평가하는 방법을 설명한다. Google Cloud의 RAG 평가 실습도 검색 단계의 Hit Rate와 MRR을 답변 단계의 평가와 구분한다. 숫자는 비교 도구이지 모든 질문의 안전성을 보증하는 도장은 아니다.

3. 출처 링크는 장식이 아니라 주장 단위의 검증 경로다

검색 조각에 문서 ID, 제목, 원문 URL, 버전 또는 시행일, 해당 위치를 연결해 두자. 답변을 만든 뒤에는 “배송 중 주문은 담당자 확인이 필요하다” 같은 검증 가능한 주장을 나눠 각 주장이 인용한 구절에서 실제로 뒷받침되는지 확인한다. 링크가 열리는지만 검사하면, 엉뚱한 문단을 가리키는 인용을 놓친다.

점검 순서는 간단하다. (1) 링크가 접근 가능한 원문인지, (2) 인용한 문서가 해당 질문의 제품·지역·시점에 적용되는지, (3) 인용 구절이 답변의 조건과 수치를 실제로 지지하는지, (4) 서로 충돌하는 문서가 있을 때 우선순위를 설명할 수 있는지 확인한다. 판단할 수 없으면 확답 대신 확인 필요를 표시한다. 자동 근거성 판정은 표본을 사람이 대조해 오판을 살펴야 한다.

4. 실전 예시: 취소 정책 검색을 바꾸기 전

가상의 고객지원 시스템에 현행 정책 v4와 구형 FAQ v2가 함께 색인돼 있다고 하자. 질문은 “배송 중인 주문을 취소할 수 있나요?”이고, 기대 근거는 정책 v4의 ‘배송 중 건은 담당자 확인’ 조항이다. 이 예시는 특정 회사의 실제 정책이 아니라 평가 설계를 위한 가상 사례다.

기록 항목	예시 값
질문·기대 근거	배송 중 주문 취소 가능 여부 / policy-v4 §3.2
검색 기록	상위 결과의 문서 ID·버전·순위·인용 구절
답변 판정	담당자 확인 필요를 포함하고 즉시 취소 확약은 하지 않음
실패 분류	검색 누락 / 구형 문서 우선 / 조건 누락 / 인용 불일치

검색 설정을 바꾸기 전과 후에 같은 질문 묶음을 실행한다. v4가 결과에 아예 없다면 색인·필터·질의 표현을 점검한다. v4가 상위에 있는데 답이 “즉시 취소”라고 한다면 생성 프롬프트와 맥락 전달을 점검한다. v4가 인용됐지만 링크가 다른 조항을 가리키면 인용 매핑을 고친다. 세 경우를 모두 “RAG 실패”라고만 기록하면 다음 수정이 흐려진다.

5. 흔한 문제와 개선 팁

• 정확한 정책 번호를 못 찾는다: 자연어 의미 검색만 고집하지 말고 키워드 검색과 결합한 후보를 같은 평가셋에서 비교한다. Azure AI Search 문서도 하이브리드 검색과 재순위를 관련성 조정 방법으로 소개한다.
• 조각은 검색되지만 예외가 잘린다: 청크 경계와 제목·시행일 메타데이터를 점검하고, 조건이 함께 전달되는지 사례로 확인한다. 청크 크기만 무작정 늘리지는 않는다.
• 옛 문서가 답을 오염시킨다: 최신성 메타데이터와 폐기 상태를 관리하고, 충돌 문서는 담당자가 우선순위를 정한다.
• 링크가 있어도 주장이 틀리다: 답변 전체가 아니라 주장별로 인용 구절을 대조하고, 불일치를 별도 실패로 남긴다.
• 평균 점수는 좋아졌는데 위험한 질문이 나빠진다: 정책 변경·예외·근거 없음 사례를 별도 묶음으로 보고 배포 전에 사람이 확인한다.

요약

RAG의 품질은 “문서를 붙였는가”로 결정되지 않는다. 정답 근거를 검색했는지, 적절한 버전과 조건을 전달했는지, 최종 답변의 각 주장이 그 근거에 의해 지지되는지를 따로 확인하자. 검색 기록과 인용 위치를 남기고 실패를 검색·생성·출처 매핑으로 분류하면 개선할 곳이 보인다. 근거를 찾지 못했을 때 멈추는 경로도 좋은 답변 설계의 일부다.

참고 자료

• Microsoft Learn, Retrieval-Augmented Generation (RAG) evaluators
• Microsoft Learn, Retrieval-augmented generation in Azure AI Search
• Google Cloud Codelabs, Evaluate RAG Systems with Vertex AI