로컬 RAG 답변이 틀릴 때: 검색·청크·모델 진단 순서

‘입사 6개월 차 직원도 여름휴가를 쓸 수 있나요?’라는 질문을 예로 들겠습니다. 답변 화면만 보고는 원인을 알 수 없으니, 먼저 검색기가 모델에 넘긴 조각을 같은 화면이나 로그에서 확인합니다. ‘입사 후 1년’이라는 조건을 담은 문장이 상위 결과에 없으면 생성 모델을 바꾸지 마세요. 답변 모델은 검색되지 않은 규정을 복원할 수 없습니다.

검색 결과가 비었거나 다른 휴가 제도를 가리킨다면 PDF 추출본부터 원문 페이지와 대조합니다. 제목과 표의 행이 섞이지 않았는지, ‘6개월 이상’ 같은 조건이 텍스트에 남았는지 확인하세요. 추출본에는 조건이 있는데 검색에서 빠지면 청크 경계, 임베딩, 문서 필터를 한 항목씩 살펴봅니다. 검색된 조각에 조건이 분명히 있는데 답이 틀렸다면 그때 모델에 전달한 프롬프트와 답변을 비교합니다.

휴가 규정이 표나 두 단으로 편집된 PDF라면, 페이지 한 장을 골라 눈에 보이는 문장과 추출된 텍스트를 나란히 놓으세요. ‘입사 후 6개월 이상’이 빠졌거나 표의 자격과 예외가 뒤섞였다면, 검색기는 틀린 원문을 정확히 찾고 있을 수 있습니다. PDF 추출 도구나 OCR 설정을 바꾼 다음 해당 페이지를 다시 추출해 빠진 문장이 복구됐는지 확인합니다.

문서 전체를 다시 색인하기 전에 문제 페이지의 텍스트가 고쳐졌는지 먼저 확인하세요. 수정 뒤에도 예전 결과가 나온다면 이전 추출본이나 색인을 읽는 것인지 점검합니다. 원문과 추출본이 같은 뜻을 담고 있는 것이 확인된 다음 청크와 검색 설정으로 넘어가면 됩니다.

청크가 너무 짧으면 ‘입사 6개월 이상’이라는 조건과 휴가 사용 가능 여부가 서로 다른 조각으로 갈릴 수 있습니다. 너무 길면 여러 휴가 규정이 한 조각에 섞여 질문과 관계없는 문장까지 모델에 전달됩니다. 먼저 정답 근거가 들어 있어야 하는 문장을 표시해 두고, 같은 질문을 실행해 상위 검색 결과 몇 개 안에 그 문장이 들어오는지 기록하세요.

근거가 빠진다면 청크 크기만 조정하고 같은 질문을 다시 실행합니다. 그다음에도 빠지면 겹침, 임베딩, 메타데이터 필터, 재정렬기 순서로 각각 한 가지씩 바꾸세요. 한 번에 여러 설정을 바꾸면 검색 결과가 달라져도 무엇이 고쳤는지 알 수 없습니다. 검색 순위가 좋아졌다는 사실과 최종 답변이 정확해졌다는 사실도 따로 적습니다.

규정 PDF를 고쳤는데 예전 답이 계속 나온다면 파일 이름만 보지 말고 파일 해시, 색인 생성 시각, 색인 버전과 캐시 키를 확인하세요. 파일명은 그대로 둔 채 본문만 바뀌었을 수 있습니다. 새 문서가 실제 추출 텍스트에 들어왔는지, 새 색인 검색 결과에 수정한 조항이 나오는지도 질문으로 점검합니다.

운영 중인 색인을 먼저 지우고 새로 만들면 검증이 끝날 때까지 검색을 제공하지 못할 수 있습니다. 새 버전을 별도로 만들고 대표 질문으로 확인한 다음 전환하면, 새 버전에서 오류가 발견될 때 이전 색인으로 돌아갈 수 있습니다. 확인 항목은 문서 해시, 색인 버전, 대표 질문의 검색 조각과 답변입니다.

검색 조각에 ‘입사 후 6개월 이상이면 여름휴가를 신청할 수 있다’는 문장이 있는데 모델이 ‘1년 이상이어야 한다’고 답했다고 해 보겠습니다. 이 경우 먼저 실제 프롬프트에 그 조각이 그대로 들어갔는지 확인합니다. 들어갔다면 모델에게 근거 문장 안에서만 답하고, 조건이 없으면 모른다고 말하도록 지시합니다. 같은 근거를 넣고 재실행해도 틀리면 모델이나 양자화¹를 바꿔 비교할 시점입니다.

답이 늦을 때도 구간을 나눕니다. 질문을 보낸 시각부터 검색 결과가 나올 때까지, 검색이 끝난 뒤 첫 토큰²이 나올 때까지, 첫 토큰 뒤 답변이 끝날 때까지 각각 시간을 기록하세요. 앞 구간이 길면 색인·필터를, 가운데가 길면 근거 길이와 프리필³을, 마지막이 길면 토큰 생성 속도를 확인합니다. 사용자 수가 늘 때만 느려진다면 같은 질문을 한 명과 네 명이 보냈을 때의 대기열과 메모리 사용량도 비교합니다.