RAG는 모델보다 검색 품질에서 먼저 흔들린다

사내 문서, 매뉴얼, FAQ를 LLM에 연결한 RAG 서비스가 기대보다 부정확한 이유는 대개 모델 자체가 아니라 검색 단계에 있다. 질문과 무관한 문서 조각이 컨텍스트에 들어가면 모델은 그 내용을 그럴듯하게 요약하거나 빈 곳을 추정해 답한다. 이를 막으려면 문서를 잘게 나누는 청킹, 의미와 키워드를 함께 찾는 검색, 후보를 다시 정렬하는 재순위화, 답변 근거를 검사하는 흐름을 분리해 설계해야 한다.

운영 목표를 먼저 정하는 것이 좋다. 예를 들어 고객지원 문서는 상위 5개 검색 결과 중 정답 근거가 포함될 비율을, 사내 규정 문서는 인용한 문단이 실제 답변을 뒷받침하는 비율을 측정한다. 단순히 채팅 답변이 자연스러운지만 보면 검색 오류가 모델 문장력에 가려진다.

1. 문서 구조를 보존해 청킹한다

고정 글자 수로 자르면 제목과 표의 의미가 끊기기 쉽다. 먼저 제목, 소제목, 문단, 목록처럼 문서 구조를 기준으로 나누고, 너무 긴 단락만 추가 분할한다. 일반적인 업무 문서는 400~800 토큰 정도의 본문 청크와 50~120 토큰의 겹침 구간부터 시작할 수 있다. 단, 숫자 기준은 정답이 아니라 검증 출발점이다. 제품 규격이나 계약 조항처럼 한 문장이 독립적인 문서는 더 작게, 설계 배경처럼 앞뒤 맥락이 중요한 문서는 더 크게 유지한다.

각 청크에는 본문만 넣지 말고 원문 제목, 상위 제목, 문서 ID, URL, 개정일, 권한 그룹을 메타데이터로 저장한다. 검색 결과를 모델에 전달할 때도 상위 제목을 함께 주면 같은 단어가 다른 업무 영역에서 쓰이는 혼동을 줄일 수 있다. 원본 문서의 위치를 표시하면 답변 화면에서 사용자가 근거를 즉시 열 수 있다.

{
  "chunkId": "handbook-2026-014",
  "documentId": "employee-handbook-2026",
  "title": "연차 휴가 운영 기준",
  "headingPath": ["인사 규정", "휴가", "연차 휴가"],
  "text": "연차 휴가는 입사일을 기준으로 ...",
  "sourceUrl": "https://docs.example.internal/hr/leave",
  "updatedAt": "2026-08-01",
  "allowedGroups": ["employees"]
}

2. 벡터 검색과 키워드 검색을 함께 사용한다

벡터 검색은 질문과 비슷한 의미를 가진 문장을 찾는 데 강하지만, 제품 코드, 오류 번호, 법 조항, 정확한 옵션명에는 약할 수 있다. 반대로 키워드 검색은 정확한 문자열에 강하지만 표현이 달라지면 놓친다. 따라서 두 결과를 합쳐 후보군을 만들면 업무 문서에서 재현성이 높아진다. PostgreSQL을 쓴다면 전문 검색용 tsvector와 pgvector 임베딩을 같은 청크 테이블에 보관하는 방식이 관리하기 쉽다.

검색 시에는 권한 조건과 문서 상태를 가장 먼저 적용한다. 권한 없는 문서를 검색 후 제거하면 후보 수가 부족해지고, 무엇보다 모델 컨텍스트에 민감한 텍스트가 들어갈 위험이 생긴다. 최신 문서 우선 규칙도 검색 쿼리 단계에서 적용해야 한다. 폐기 문서와 현재 문서를 함께 전달한 뒤 모델에게 선택하게 하면 일관된 답을 기대하기 어렵다.

WITH candidates AS (
  SELECT id, title, body,
         1 - (embedding <=> $1::vector) AS vector_score,
         ts_rank_cd(search_text, websearch_to_tsquery('simple', $2)) AS keyword_score
  FROM rag_chunks
  WHERE $3 = ANY(allowed_groups)
    AND status = 'published'
  ORDER BY embedding <=> $1::vector
  LIMIT 40
)
SELECT *, (0.65 * vector_score + 0.35 * keyword_score) AS hybrid_score
FROM candidates
ORDER BY hybrid_score DESC
LIMIT 12;

위 가중치는 예시다. 실제 질문 세트로 벡터 단독, 키워드 단독, 하이브리드 결과를 비교해 조정한다. 키워드 결과에만 있는 문서도 후보군에 합치는 UNION 방식이 더 적합한 경우가 많으며, 특히 식별자 중심의 기술 지원 문서에서 효과가 크다.

3. 상위 후보만 재순위화한다

하이브리드 검색으로 20~50개 정도의 후보를 얻은 뒤, 질문과 청크를 한 쌍으로 비교하는 재순위화 모델 또는 LLM 평가기로 상위 3~8개만 고른다. 처음부터 모든 문서에 재순위화를 적용하면 비용과 지연 시간이 커진다. 검색 단계는 넓게 후보를 모으고, 재순위화 단계는 정밀하게 줄이는 역할로 나누는 것이 핵심이다.

재순위화 결과가 낮으면 억지로 답하지 않는 정책도 필요하다. 최고 점수가 기준에 못 미치거나 서로 상충하는 최신 문서가 있으면, 답변 대신 담당 부서나 원문 링크를 안내하도록 한다. 모델 프롬프트에는 제공된 근거 밖의 사실을 단정하지 말 것, 각 결론 뒤에 청크 ID를 인용할 것, 근거가 없으면 모른다고 답할 것을 명시한다.

4. 평가 데이터로 검색과 답변을 분리 점검한다

실제 사용자가 남긴 질문, 고객센터 티켓, 사내 반복 문의에서 30~100개를 뽑아 질문·정답 문서·허용 답변 범위를 기록한다. 새 문서가 추가되거나 임베딩 모델, 청크 크기, 프롬프트를 바꿀 때마다 같은 세트로 회귀 테스트한다. 운영 로그에는 질문 원문, 검색된 청크 ID와 점수, 최종 인용, 응답 시간, 사용자 피드백을 남긴다. 개인정보와 비밀값은 마스킹하거나 저장 제외 대상으로 처리한다.

  • 청크에 제목·문서 버전·권한·원문 URL을 저장했는가
  • 벡터와 키워드 검색을 별도로 측정하고 합쳤는가
  • 재순위화는 제한된 후보군에만 적용하는가
  • 낮은 근거 점수에서 답변 보류 또는 추가 확인 경로가 있는가
  • 대표 질문 세트로 변경 전후 검색 정확도와 인용 정확도를 비교하는가

RAG 품질은 한 번의 모델 교체로 해결되지 않는다. 문서 구조, 권한, 검색 후보, 재순위화, 평가 로그를 각각 관찰하면 부정확한 답의 원인을 좁힐 수 있다. 먼저 검색 결과와 인용 근거가 맞는지 확인하고, 그 다음에 생성 문장을 개선하는 순서로 운영한다.