AI 지식 RAG & 검색 완전 정리

RAG가 기대만큼 안 나올 때 원인은 대개 LLM이 아니라 검색 쪽에 있습니다. 검색이 엉뚱한 문단을 물어 오면 그 뒤 단계에서 아무리 좋은 모델을 써도 답은 그 문단의 범위를 벗어나지 못합니다. 그런데 파이프라인이 문서 적재, 분할, 임베딩, 검색, 재순위, 생성으로 길게 이어져 있어서 어느 칸에서 망가졌는지 눈으로 보이지 않습니다. RAG를 잘 다룬다는 말은 사실상 이 단계별로 중간 산출물을 꺼내 확인하는 습관이 있다는 뜻입니다.

구성은 파이프라인 순서를 그대로 따릅니다. RAG(검색 증강 생성) 기초 아키텍처로 전체 흐름을 잡은 뒤 청킹(Chunking) 전략에서 문서를 어떤 단위로 자를지 정하는데, 이 결정이 뒤의 모든 단계 품질 상한을 정합니다. 하이브리드 검색 — 벡터 + 키워드는 임베딩이 약한 고유명사와 숫자 매칭을 BM25로 메우고, Re-ranking — 검색 품질 향상은 넓게 건져 온 후보를 좁혀 컨텍스트를 아낍니다. 개선이 실제로 개선인지 확인하려면 RAG 평가 지표 — RAGAS를 먼저 붙여 두는 편이 순서상 유리합니다.

청킹에서 자주 놓치는 지점은 표와 코드 블록입니다. 고정 토큰 길이로 자르면 표가 머리글과 본문으로 쪼개져 두 조각 모두 의미를 잃고, 검색에 걸려도 모델이 열 이름을 모르는 상태로 답을 지어냅니다. 헤더 경로를 각 청크 앞에 붙여 두면 이 문제가 상당히 줄어듭니다. 또 하나, 임베딩 모델을 교체하면 벡터 공간이 달라지므로 기존 인덱스는 전량 재생성해야 합니다. 같은 컬렉션에 옛 벡터와 새 벡터가 섞이면 오류 없이 조용히 검색 품질만 떨어지기 때문에, 인덱스에 모델 이름과 버전을 메타데이터로 남겨 두는 편이 안전합니다.