RAG 품질 문제는 모델보다 검색 단계에서 먼저 확인한다

사내 문서, 매뉴얼, 규정집을 LLM에 연결한 RAG 서비스에서 답변이 부정확할 때 모델을 바꾸는 것부터 시작하기 쉽습니다. 그러나 실제 장애의 상당수는 검색 대상 문서가 잘못 잘렸거나, 현재 질문과 무관한 문서가 상위에 노출되거나, 오래된 문서가 최신 정책보다 먼저 선택되는 데서 발생합니다. 생성 모델은 전달받은 근거 안에서 답을 만들기 때문에 검색 품질이 불안정하면 프롬프트를 길게 써도 결과가 흔들립니다.

운영 가능한 RAG는 문서 수집, 청킹, 임베딩, 후보 검색, 재정렬, 답변 생성, 근거 기록을 분리해서 설계합니다. 각 단계의 입력과 결과를 남기면 특정 답변이 왜 나왔는지 추적할 수 있고, 문서가 바뀌었을 때 어느 인덱스를 다시 만들어야 하는지도 명확해집니다.

청킹은 문단 길이보다 의미 경계를 우선한다

문서를 일정 글자 수로만 자르면 제목과 본문, 표의 설명과 항목, 예외 조건과 기본 규칙이 서로 떨어질 수 있습니다. 먼저 HTML이나 Markdown의 제목, 문단, 목록, 표 같은 구조를 읽고, 같은 소제목 아래의 내용을 하나의 후보 범위로 묶는 방식이 안전합니다. 그 뒤 범위가 너무 길면 문장 단위로 나누고 일부를 겹치게 합니다.

  • 일반 안내 문서: 400~800 토큰을 시작점으로 사용하고, 다음 청크와 10~20% 정도 겹치게 합니다.
  • 규정·계약·운영 절차: 조항 번호와 예외 조건이 함께 남도록 더 작은 단위로 분리합니다.
  • API 문서: 엔드포인트 설명, 요청 예제, 응답 예제를 같은 청크 또는 연결 가능한 청크로 유지합니다.
  • 표가 많은 문서: 표 제목과 열 이름을 각 행의 텍스트 표현에 반복해 검색어와의 연결을 보존합니다.

청크에는 본문만 저장하지 말고 원문 제목, 상위 제목 경로, 문서 식별자, 문서 버전, 수정 시각을 함께 저장해야 합니다. 질문이 ‘휴가 승인 기준’처럼 짧을 때에도 제목 경로가 임베딩과 키워드 검색에 중요한 힌트를 제공합니다.

메타데이터 필터를 검색 조건으로 사용한다

RAG에 부서별 매뉴얼과 과거 공지까지 섞여 있으면 유사도만으로는 권한과 최신성을 보장할 수 없습니다. 사용자 조직, 문서 공개 범위, 문서 상태, 적용 시작일을 메타데이터로 두고 검색 전에 필터링합니다. 특히 폐기된 문서는 삭제하지 못하더라도 검색 대상에서 제외해야 합니다. 날짜를 문자열로 비교하면 형식 문제로 잘못 정렬될 수 있으므로 ISO 날짜 또는 데이터베이스의 날짜 타입으로 관리합니다.

SELECT chunk_id, content, source_title, updated_at FROM rag_chunks WHERE tenant_id = :tenantId AND access_level <= :userAccessLevel AND document_status = 'published' AND effective_from <= CURRENT_DATE AND (effective_to IS NULL OR effective_to >= CURRENT_DATE) ORDER BY embedding <=> :queryEmbedding LIMIT 30;

위 예시는 PostgreSQL과 pgvector에서 후보를 가져오는 기본 형태입니다. 실제 서비스에서는 사용자 ID 자체를 모든 청크에 복제하기보다 조직, 역할, 프로젝트 같은 접근 범위를 정규화하고, 검색 요청의 권한 값을 서버에서 계산합니다. 클라이언트가 전달한 역할 값을 그대로 SQL 필터에 넣으면 권한 우회 위험이 생깁니다.

벡터 검색만 쓰지 말고 키워드 검색을 결합한다

벡터 검색은 표현이 달라도 의미가 비슷한 내용을 찾는 데 강하지만, 오류 코드, 제품명, 계약 번호, 정확한 함수명처럼 희소한 고유어에는 약할 수 있습니다. 반대로 전문 검색은 정확한 단어를 잘 찾지만 동의어나 문장형 질문을 놓칠 수 있습니다. 두 검색 결과를 합쳐 순위를 계산하는 하이브리드 검색을 기본값으로 두면 실무 질문의 편차를 줄일 수 있습니다.

결합 방법으로는 각 검색 결과의 순위만 이용하는 RRF가 구현과 운영이 단순합니다. 점수 범위가 다른 두 엔진의 원점수는 바로 더하지 않고, 각각의 순위에 가중치를 적용합니다. 아래 함수는 벡터 결과와 키워드 결과를 합쳐 재정렬하는 예시입니다.

function rrfMerge(vectorHits, keywordHits, k = 60) { const scores = new Map(); for (const [weight, hits] of [[1.0, vectorHits], [0.8, keywordHits]]) { hits.forEach((hit, index) => { const score = weight / (k + index + 1); scores.set(hit.chunkId, (scores.get(hit.chunkId) ?? 0) + score); }); } return [...scores.entries()].sort((a, b) => b[1] - a[1]).map(([chunkId, score]) => ({ chunkId, score })); }

후보를 20~50개 정도 모은 뒤 상위 5~8개만 재정렬 모델 또는 LLM 기반 판별기로 좁힐 수 있습니다. 다만 재정렬은 비용과 지연 시간을 늘리므로 모든 질문에 무조건 적용하지 말고, 검색 점수가 낮거나 답변 영향도가 높은 업무 화면부터 적용하는 것이 좋습니다. 최종 컨텍스트에는 중복 청크를 제거하고, 같은 문서에서 너무 많은 청크가 선택되지 않도록 문서별 상한도 둡니다.

답변에는 근거와 응답 보류 규칙을 함께 둔다

검색 결과가 부족한데도 답변을 강제하면 그럴듯한 추측이 나옵니다. 프롬프트에 ‘제공된 근거에 없는 내용은 단정하지 않는다’는 규칙을 넣고, 검색 임계값 미달 또는 서로 충돌하는 최신 문서가 발견되면 담당 부서 확인이 필요하다고 응답하게 합니다. 이때 사용자가 확인할 수 있도록 문서 제목, 문서 버전, 원문 링크 또는 내부 문서 식별자를 답변에 함께 표시합니다.

인용은 단순한 화면 장식이 아닙니다. 문의자가 원문을 검토할 수 있게 하고, 운영자는 잘못 선택된 청크를 빠르게 찾게 합니다. 답변 로그에는 질문 원문, 권한 필터 결과, 검색 후보 ID와 순위, 최종 인용 ID, 모델·프롬프트 버전, 응답 시간만 저장합니다. 개인정보나 인증 정보가 질문에 들어올 수 있으므로 원문 로그는 마스킹 정책과 보존 기간을 별도로 적용해야 합니다.

운영 전 점검 체크리스트

  • 문서 제목과 상위 제목 경로가 청크 텍스트 및 메타데이터에 포함되어 있는가
  • 문서 상태, 적용일, 조직·역할 권한을 검색 전에 필터링하는가
  • 고유 코드와 제품명을 위한 키워드 검색을 벡터 검색과 결합했는가
  • 최종 답변이 인용 문서와 청크 식별자를 남기며, 근거 부족 시 응답을 보류하는가
  • 정답·오답뿐 아니라 검색 누락, 오래된 문서 선택, 권한 위반 가능성을 분리해 점검하는가

RAG 개선은 모델 교체보다 검색 흐름을 관측 가능한 상태로 만드는 데서 시작합니다. 청크 구조, 메타데이터 필터, 하이브리드 검색, 인용 로그를 차례로 갖추면 문서가 늘어나도 품질 저하 원인을 재현하고 수정할 수 있습니다.