RAG 검색 정확도가 낮을 때 확인할 5단계

RAG 검색 정확도가 낮다면 모델을 바꾸기 전에 정답 근거가 어느 단계에서 빠지는지 확인해야 합니다. 원문은 있는데 추출되지 않았는지, 검색 후보에서 빠졌는지, 후보에는 있지만 최종 문맥에서 제외됐는지, 올바른 근거를 받은 뒤 답변이 틀렸는지를 나눠 보세요.

같은 오답이라도 원인은 다릅니다. 표가 깨진 문서는 임베딩 모델을 바꿔도 복구되지 않고, 잘못된 개정본을 근거로 쓰는 문제는 답변을 더 길게 생성한다고 해결되지 않습니다. 수집·추출, 청킹, 검색, 순위 조정, 답변의 다섯 단계를 차례로 확인하면 수정할 범위를 좁힐 수 있습니다.

먼저 오답과 정답 근거를 한 쌍으로 남기세요

조사할 질문에는 원문 파일과 정확한 근거 위치를 붙입니다. 파일명, 문서 버전, 실행 계정, 질문, 실행 시각과 답변을 함께 남기세요. 설정이나 문서 상태가 달라지면 같은 질문도 다른 결과가 나올 수 있으므로 재현 조건이 중요합니다.

“정확도가 낮다”는 표현 대신 관찰한 실패를 적으면 담당자가 달라도 원인을 이어서 확인하기 쉽습니다. 다음 표는 첫 조사 위치를 정하는 데 사용할 수 있습니다.

관찰한 결과	먼저 열어볼 기록	첫 점검 대상
파일은 보이지만 본문 문장을 못 찾음	추출 텍스트와 처리 상태	수집·문서 추출
본문은 있는데 조건·각주가 빠짐	검색되는 문서 조각	청킹과 문맥 보존
품목 코드 대신 비슷한 제품이 나옴	검색어와 후보 문서	정확한 문자열·검색 방식
정답이 후보 아래쪽에만 있음	순위 조정 전후 목록	리랭킹과 결과 선택
올바른 문맥을 받았는데 답이 틀림	모델에 전달한 근거와 답변	생성·인용·답변 보류

Microsoft의 RAG 설계·평가 가이드도 검색 방식과 각 처리 단계의 평가를 구분합니다. 시스템을 직접 개발하지 않는 조직도 공급사에 같은 구분으로 진단 결과를 요청할 수 있습니다.

1단계. 정답이 추출 텍스트와 색인에 있는지 확인하세요

원본에서 답을 찾은 다음, 검색 시스템이 실제로 읽은 내용과 비교합니다. 문서가 등록됐다는 표시만으로 전체 본문이 검색 대상에 들어갔다고 판단하지 마세요. 일부 페이지만 처리됐거나, 표·이미지·암호 문서가 제외됐을 수 있습니다.

질문이 참조하는 문장과 표의 값, 단위, 예외 조건이 추출 결과에 있는지 봅니다. 스캔 PDF라면 원문의 숫자와 OCR 결과가 일치하는지, 다단 문서라면 문장을 읽는 순서가 맞는지 확인합니다. 이런 문제는 OCR·PDF 색인 검수 단계에서 먼저 고쳐야 합니다.

추출은 됐지만 검색되지 않으면 색인 상태, 대상 컬렉션, 갱신 시점과 필터 조건을 확인합니다. 사용자의 권한 때문에 제외된 결과는 검색 품질 오류와 다릅니다. 진단을 위해 운영 환경의 권한을 풀기보다, 해당 문서를 읽을 수 있는 승인된 시험 계정으로 확인하세요.

이 단계에서 남길 결과는 “파일 처리 성공” 한 줄보다 구체적이어야 합니다. 원본의 근거 구절, 추출된 구절, 색인된 문서 ID, 처리 시각을 연결해 두면 다시 처리한 뒤 개선 여부를 비교할 수 있습니다.

2단계. 청킹이 질문에 필요한 조건을 나누지 않았는지 보세요

청킹은 긴 문서를 검색하기 좋은 조각으로 나누는 과정입니다. 너무 작은 조각은 앞뒤 조건을 놓칠 수 있고, 서로 다른 내용이 한 조각에 섞이면 필요한 내용을 찾기 어려울 수 있습니다. 적절한 크기는 문서 구조와 질문에 따라 달라집니다.

Microsoft의 문서 청킹 안내는 고정 길이, 문서 구조, 의미 단위와 혼합 방식을 설명합니다. 따라서 모든 문서를 동일한 길이로 자르는 설정 하나를 정답으로 삼기보다, 실제 실패 문서에서 필요한 맥락이 남는지 비교하세요.

예를 들어 적용 대상을 설명한 절 제목, 비용 기준표, 승인 예외를 적은 각주가 서로 떨어져 있다면 표의 숫자만 검색될 수 있습니다. 조각에 제목·문서 정보를 함께 남기거나 필요한 인접 내용을 함께 가져오는 방법을 시험할 수 있습니다. 단, 내용을 늘린 만큼 무관한 문장도 섞일 수 있으므로 결과를 다시 확인해야 합니다.

문서 구조	확인할 문맥	조정 후 재시험할 질문
규정과 예외 조항	본문 규칙과 예외의 연결	“이 경우에도 같은 기준이 적용되나요?”
여러 페이지의 표	열 제목·행·단위의 연결	“해당 항목의 값과 단위는 무엇인가요?”
긴 매뉴얼	장·절 제목과 대상 장비	“이 절차는 어느 모델에 적용되나요?”
부록을 참조하는 본문	참조 문구와 부록의 대응	“본문에서 언급한 세부 조건은 무엇인가요?”

청킹을 바꿀 때는 해당 조각의 색인도 다시 만들어야 결과를 비교할 수 있습니다. 다른 설정까지 동시에 바꾸면 무엇이 개선에 영향을 줬는지 알기 어려우므로, 우선 같은 문서와 질문에서 한 가지 변경을 확인하세요.

3단계. 정확한 문자열과 의미 검색을 따로 시험하세요

사내 질문에는 문서 번호, 설비 코드, 고객사 약칭처럼 정확히 일치해야 하는 표현이 많습니다. 반면 사용자가 “설비가 자꾸 멈춰요”라고 물었는데 문서에는 “반복 정지 현상”이라고 적혀 있다면 표현 차이를 다룰 수 있어야 합니다. 두 유형을 같은 질문 묶음으로만 평가하면 한쪽의 약점을 놓치기 쉽습니다.

키워드 검색은 코드·고유명사 등 정확한 표현을 찾는 데 도움이 되고, 벡터 검색은 표현이 달라도 의미가 가까운 내용을 찾는 데 사용할 수 있습니다. 두 결과를 결합하는 하이브리드 검색은 이런 차이를 함께 다루는 방법입니다. Azure AI Search의 하이브리드 검색 설명도 전문 용어·코드와 의미 유사성을 구분합니다.

다만 하이브리드 검색을 켰다는 사실만으로 더 정확해졌다고 판단하지 마세요. 아래와 같은 가상 시험 질문을 업무 용어로 바꿔 비교할 수 있습니다.

• 정확한 식별자: “설비 코드 EQ-17의 점검 주기는?”
• 표현 차이: “장비가 반복해서 멈출 때 확인할 항목은?”
• 조건 결합: “EQ-17의 고온 운전 중 점검 항목은?”
• 근거 없음: “문서에 없는 새 모델 EQ-99의 점검 주기는?”

같은 자료로 키워드, 벡터, 결합 결과를 비교하고 정답 문서가 검색 후보에 들어오는지 기록합니다. 코드의 하이픈·숫자·약칭이 어떻게 처리되는지, 질문을 바꿔 쓸 때 식별자와 조건이 유지되는지도 확인하세요. 일치 검색과 의미 검색은 서로 다른 질문에서 도움이 될 수 있습니다.

4단계. 후보와 최종 근거 사이에서 빠지는 문서를 찾으세요

정답 문서가 초기 후보에는 있지만 모델이 받은 근거에는 없다면 후보를 고르는 단계가 문제일 수 있습니다. 검색 후보 수, 중복 문서, 순위 조정, 문맥 길이 제한을 차례로 확인하세요. 검색 결과 전체와 모델에 전달된 결과를 같은 목록이라고 가정하면 이 차이를 놓칩니다.

리랭킹은 검색한 후보를 질문과 다시 비교해 순서를 조정하는 방식입니다. Microsoft의 semantic ranking 설명에서도 초기 검색 결과를 받은 뒤 추가 순위를 매기는 단계로 설명합니다. 따라서 후보에 들어오지 않은 근거를 순위 조정만으로 되살릴 수는 없습니다.

후보를 더 가져오면 정답을 포함할 기회가 늘 수 있지만, 처리 시간과 비용이 달라지고 불필요한 자료가 함께 들어올 수 있습니다. 같은 질문에서 후보 수와 최종 근거 수를 구분해 기록하고, 검색 결과의 앞부분에 중복 사본만 몰리는지도 확인합니다.

권한과 문서 버전 조건은 순위 점수와 별도로 유지해야 합니다. 관련성이 높은 이전 규정이라도 현재 기준을 묻는 질문의 정답이 아닐 수 있습니다. 승인 상태와 시행일을 어떤 기준으로 반영할지 정하고, 개정·삭제 후에는 문서 갱신 점검을 반복하세요.

5단계. 올바른 근거를 받은 뒤에도 답이 틀리는지 확인하세요

모델에 필요한 근거가 전달됐는데 답변이 틀렸다면 검색 이후를 점검합니다. 숫자·단위를 잘못 읽었는지, 예외를 생략했는지, 서로 다른 문서의 조건을 합쳤는지, 근거에 없는 설명을 덧붙였는지 구분하세요. 이때부터 답변 지시, 모델 선택, 문맥 구성의 변경을 비교할 이유가 생깁니다.

답변 형식은 업무에 맞춰 정할 수 있습니다. 예를 들어 핵심 결론, 적용 조건, 근거 문서와 위치, 확인이 필요한 사항을 구분하면 검토가 쉬워집니다. 단, 형식이 정돈됐다고 내용이 맞는 것은 아니므로 각 주장과 원문을 대조해야 합니다.

문서에 답이 없는 질문도 포함하세요. 관련 자료가 있더라도 결론에 필요한 정보가 없다면 그 부족함을 설명하는지 봅니다. 출처 링크가 붙어 있어도 실제 구절이 답변을 뒷받침하지 않으면 통과로 처리하지 않습니다.

권한 밖 정보가 답변·제목·인용에 나타나는 문제는 평균 정답률에 섞지 않고 별도로 처리해야 합니다. 해당 정보를 모델에 전달하기 전에 접근 조건을 적용하는지와 회수 후 동작을 사내 AI 보안 검토에 포함하세요.

개선 여부는 같은 기준으로 비교합니다

변경 전후에는 질문, 문서 버전, 실행 계정과 통과 기준을 유지합니다. 고친 실패만 반복하지 말고 이전에 맞던 질문도 함께 확인하세요. 문제를 수정하는 데 사용하지 않은 질문을 따로 남겨 두면 특정 예시에만 맞춰진 변경인지 확인하는 데 도움이 됩니다.

평가표에는 근거 발견 여부, 순위, 최종 문맥 포함 여부, 답변의 조건·수치, 인용 일치, 응답 시간을 나눠 적습니다. 소수의 질문이 좋아졌다는 결과를 전체 정확도 개선으로 확대하지 말고, 시험한 문서 유형과 질문 범위를 함께 기록하세요.

자주 묻는 질문

임베딩 모델을 바꾸면 검색 정확도가 바로 좋아지나요?

모델이 원인일 때 도움이 될 수 있지만 추출 누락, 잘못된 청킹, 과도한 필터, 갱신 실패는 별도로 해결해야 합니다. 모델을 바꿀 때는 기존 색인과 질의의 임베딩 호환성, 다시 색인할 범위도 확인하고 같은 질문으로 비교하세요.

검색 결과를 많이 넣으면 더 정확한가요?

항상 그렇지는 않습니다. 필요한 근거가 추가될 수도 있지만 중복·무관한 문서와 상충하는 버전이 섞일 수도 있습니다. 검색 후보 수와 모델에 넣는 근거 수를 따로 조정하고 정확도·응답 시간·처리 비용을 함께 평가해야 합니다.

솔루션을 도입하면 이런 점검이 필요 없나요?

문서 구조, 업무 용어와 권한은 조직마다 다르므로 실제 파일로 확인해야 합니다. 내부 설정을 직접 바꾸기 어려워도 실패 질문과 기대 근거를 전달해 어느 단계에서 문제가 생겼는지 설명을 요청할 수 있습니다.

Wissly를 검토할 때 준비할 자료

Wissly는 연결된 사내 문서를 검색하고 답변의 원문 근거를 확인하는 흐름을 제공합니다. 특정 검색 기법의 이름보다 조직의 문서와 질문에서 필요한 내용을 찾는지 확인하세요. 검색·문서 처리·연동 구성은 도입 환경에 맞춰 검토합니다.

Wissly 도입 상담에 실패 질문, 기대하는 원문 위치, 파일 형식, 저장소와 보안 조건을 준비하면 검토 범위를 구체적으로 정할 수 있습니다. 검색이 놓친 근거를 찾는 일과 근거를 잘못 해석한 답변을 고치는 일을 나눠 평가하는 것이 출발점입니다.