사내 AI가 틀린 답을 할 때, 검색 실패와 답변 실패를 어떻게 나눌까

먼저 정답의 근거를 업무 담당자와 정합니다

검색 증강 생성(RAG)은 업무 자료에서 가져온 문맥으로 답변을 구성합니다. 문서 자체가 모호하거나 정답이 원문에 없는 질문이라면 검색 결과가 많은 것과 올바른 답을 내는 것은 다릅니다. 고객이 평가에서 원하는 결과를 “배송 규정을 알려 줘”처럼 한 줄로만 적으면, 보통 적용되는 조항을 찾았을 때 합격시킬지 예외 조항까지 요구할지 판정이 흔들립니다. 질문 속 조건에 적용되는 문서, 시행일, 조항, 예외와 출처를 문서 담당자가 함께 검토해야 합니다. 요구사항과 확인 근거를 버전으로 연결하는 방식은 요구사항과 테스트의 추적성에 정리돼 있습니다.

질문·기대 결과·문서 버전을 한 케이스로 묶을 때 결과 유형도 정합니다. 답할 수 있는 경우, 조건을 다시 물어야 하는 경우, 근거가 부족해 보류할 경우, 자료가 충돌해 담당자에게 넘길 경우가 있습니다. “급한 건도 다음 날 배송되나요?”처럼 고객이 배송 지역과 상품 유형을 제공하지 않았다면 일반 조항과 필요한 추가 조건을 안내하는 정도가 기대 결과일 수 있습니다. 질문이 충분히 구체적인데 평가 문서를 담당자가 확정하지 못했다면 먼저 데이터나 기준의 결함을 기록합니다. 그런 사례에 거짓 정답을 만들어 넣으면 검색과 모델 둘 다 잘못된 목표를 맞추게 됩니다.

질문자의 역할이나 정책 적용일에 따라 정답이 달라진다는 점도 중요합니다. 특정 부서에 제한된 근거가 현재 사용자에게 허용되지 않는다면, 시스템의 올바른 선택은 허용 범위의 정보만 제공하거나 확인 가능한 다음 경로로 이관하는 것일 수 있습니다. 따라서 평가 기록에 역할과 당시 유효 문서 버전을 남깁니다. 과거 질의를 다시 시험하더라도 최신 정책 적용을 평가하는지 과거 주문에 당시 정책을 적용하는지 명시합니다. 서로 다른 질문에 같은 정답표를 적용하면 맞는 답도 오답으로 집계됩니다.

답변을 만든 네 단계에서 증거를 찾습니다

한 질문의 실행을 식별할 수 있는 ID를 사용합니다. 원문과 검색 후보, 실제 모델 입력, 사용자에게 표시된 답과 인용을 같은 실행으로 연결합니다. 검색 응답에 문서가 보였는지와 모델에 넘겼는지는 다른 데이터입니다. 여러 단계에서 같은 문서 ID를 쓰더라도 문단의 범위와 문서 버전이 구별돼야 합니다. 로그에 업무 문서의 원문을 계속 저장하기 어려우면 시험 환경에서 가상 자료와 식별자를 쓰거나 운영에서는 권한이 있는 사람이 확인 가능한 참조를 남기는 방식이 있습니다. 실행 경로를 연결하는 구조는 AI 에이전트 관측을 참고할 수 있습니다.

이 진단표는 가능한 첫 번째 실패를 찾는 출발점입니다. 검색이 부족한 상태에서 생성도 틀릴 수 있습니다. 처음 발견한 문제를 해결한 뒤 다른 단계의 증거도 확인합니다. 같은 케이스에 원문 누락과 잘못된 확정이 함께 있으면 문서 등록과 보류 정책을 둘 다 회귀에 추가합니다. RAG 평가에서 검색의 관련성과 생성 답변의 근거 충실성을 따로 볼 수 있다는 근거는 RAGAS 연구^[1]와 Google Cloud의 평가 지표 안내^[2]에서 확인할 수 있습니다. 여기에서 다루는 지표들은 팀의 내부 정책에 맞는 정답 여부와 별개로 적용 범위를 정합니다.

배송 안내의 같은 오답을 두 가지로 재현합니다

가상의 유통사 정책에 “일반 상품은 영업일 오후 2시 이전 주문 시 당일 출고”와 “설치가 필요한 상품은 별도 설치 일정에 따라 출고”가 있다고 가정합니다. 대상 상품은 설치형입니다. 질문은 “오늘 오전 11시에 주문한 설치 상품을 오늘 출고하나요?”입니다. 서비스는 두 실행에서 모두 “오후 2시 이전 주문이면 오늘 출고합니다”라고 답했습니다. 겉으로는 같은 오류여도 근거를 따라가면 손봐야 할 부분이 달라집니다.

첫 번째 실행에서는 일반 출고 규정만 검색됐습니다. 유효한 설치 예외 조항은 인덱스에 있었는데, 제품 유형이 붙은 검색 결과가 낮은 순위로 밀려 후보에 포함되지 않았습니다. 이 경우 승인된 예외 문장이 검색 인덱스에 실제로 있는지 확인하고 원 질문과 질의 변환이 설치라는 조건을 보존했는지 비교합니다. 질의 변환이 “오늘 출고 기준”으로 질문을 줄인 것이 관측되면, 질문의 중요한 조건에서 검색 필드나 제품 유형 필터를 지정할 수 있습니다. 이 수정 뒤에도 일반 상품은 이전과 같이 일반 출고 규정을 찾는지 확인합니다. 모델을 바꿔 잘 설명하게 했더라도 보지 못한 출고 예외가 앞으로 늘 정확하게 답변에 나타날 근거는 부족합니다.

두 번째 실행에서는 검색 상위 후보에 설치 예외가 포함됐습니다. 먼저 모델 입력에서 설치 예외가 문장 끝까지 도달했는지를 확인합니다. 구성기가 문서를 길이 제한에 맞춰 잘라 해당 문장을 뺐다면 모델은 일반 규정만 받았습니다. 문맥 구성에서 일반 규정과 적용되는 예외를 함께 넣도록 수정하고 후보가 많을 때도 예외가 유지되는지 검증합니다. 문장이 입력에 모두 존재했다면 생성 단계에서 모델이 일반 규정과 예외의 우선순위를 해석했는지 평가합니다. 채점은 ‘설치’라는 단어가 응답에 들어 있는지를 보는 대신 당일 출고를 확정하지 않고 일정 확인이 필요하다고 했는지 봅니다.

같은 케이스를 원인별로 고칠 때 작은 절제 실험을 할 수도 있습니다. 검색 결과와 생성 설정을 고정하고 운영 문맥과 승인된 완전 문맥을 각각 넣습니다. 예외를 포함한 문맥에서만 기대 답이 나온다면 근거 전달을 개선할 이유가 생깁니다. 두 입력 모두 오답이면 생성이 지시한 적용 논리와 거짓 확정 방지 기준을 확인합니다. 운영 문맥에서만 정답이 나오더라도 모델이 과거 학습이나 표현상의 단서로 우연히 맞혔을 수 있습니다. 현재 질문에 실제로 제공한 인용이 결론을 뒷받침하는지 따로 판단합니다.

근거 부족과 자료 충돌도 재현합니다

예외를 고친 뒤 정책을 일부러 하나 누락하거나 두 개를 충돌시켜 ‘모름’ 경로를 확인합니다. 설치형이라고 답변할 수 있어도 정확한 출고일이 예약 시스템에 있고 접근이 안 되면 확인할 다음 절차가 필요합니다. 유효한 문서 두 개가 서로 다른 기준을 제시한다면 시행일과 문서 권한에서 우선순위를 결정할 수 있는지 확인합니다. 기준으로 해결할 수 없으면 충돌을 요약하고 정책 소유자에게 전달합니다. 데이터 소스가 끊겨 검색을 실행하지 못한 상태도 구분합니다. 근거가 없다는 문구를 반환했더라도 그것이 올바른 보류인지, 서비스 장애를 숨기는 답인지 실행 증거로 판단합니다.

검색 점수는 질문과 분모에 연결합니다

검색 관련성으로 상위 후보가 질문에 얼마나 잘 맞는지 판단합니다. 정답 문단을 포함한 후보를 찾아야 하는 평가에서는 재현율을 쓸 수 있습니다. 여기서 문단 단위 재현율@5는 사람이나 기준 데이터가 표시한 관련 문단 중 상위 5개에 들어온 비율입니다. 관련 문단이 3개이고 상위 후보에 2개라면 이 질문의 그 지표는 2/3, 약 66.7%입니다. 문서가 반복되거나 관련 근거가 더 있을 수 있다면 분모는 자기 평가셋에서 식별한 범위로 제한됩니다. 관련 문단이 하나도 없는 보류 케이스에는 이 분모를 만들 수 없으므로 보류 성공과 별도로 봅니다.

운영 질문은 필요한 모든 근거가 들어왔는지를 더 직접적으로 요구할 수도 있습니다. 예를 들어 일반 규정과 고위험 예외가 둘 다 있어야 답할 수 있으므로, 모든 필수 근거를 포함한 질문 비율을 검색 재현율과 나란히 기록합니다. 평균 검색 점수가 높아져도 필수 예외 문단이 하나씩 빠지는 문제가 남을 수 있습니다. 또한 후보 수를 5개에서 20개로 늘리면 더 많은 문단을 찾을 수 있지만 관계없는 내용도 늘어나고, 모델 입력 제한으로 최종 문맥에서 필요한 근거가 밀릴 수 있습니다. 후보 지표와 모델 입력 지표가 별도로 필요한 이유입니다.

답변 충실성은 답변의 주장이 제공 문맥에 의해 뒷받침되는지 보고, 업무 정답성은 최신 승인된 기준에 따라 그 질문의 필수 조건을 만족했는지 봅니다. 오래된 정책을 충실하게 인용했지만 현재 규정에 어긋난 경우는 충실성과 정답성이 다르게 나옵니다. 답변이 정확해도 인용 링크가 다른 조항을 열거나 페이지에 접근할 수 없다면 인용 적합성에서 잡습니다. 수치 항목이나 실제 상태는 코드로 검산할 수 있고, 문구의 예외나 보류의 이유를 판단할 때는 문서 책임자나 검증한 평가 방식을 사용합니다. Anthropic — Demystifying evals for AI agents^[3]

검색 실패를 고치겠다고 순위 값과 모델·프롬프트를 함께 바꾸면 어떤 수정에서 효과가 생겼는지 나중에 분리하기 어렵습니다. 원인 가설과 바꿀 값을 먼저 적고, 동일 원문·질문·권한 조건으로 전후를 재실행합니다. 문맥 조정이라면 모델 입력에서 필수 절이 살아났는지 보고, 생성 조정이라면 입력을 고정한 채 업무 판정을 비교합니다. 단일 실행 결과에 변동성이 있으면 일부 고위험 케이스는 같은 설정으로 반복합니다. 대상에 따라 기대 결과가 달라졌거나 근거가 확인되지 않은 사례는 그 이유를 남겨 둡니다. 배포 전 시험과 운영의 문제 환류는 NIST AI 600-1^[4]을 참고할 수도 있습니다.