rag 시스템은 수백 개 문서에서는 단순한 청킹(chunking)과 벡터 검색만으로도 잘 동작한다. 문서가 수만 개를 넘어가면 같은 구현이 검색 잡음, 긴 꼬리 지연 시간(tail latency), 불필요한 컨텍스트 비용을 만든다. 대규모 RAG는 LLM 기능이 아니라 정보검색(information retrieval) 시스템 위에 LLM 추론 레이어를 얹는 문제로 다뤄야 한다.
규모가 커지면 실패하는 세 지점
| 실패 지점 | 증상 | 원인 |
|---|---|---|
| 청크 폭증 | 비슷하지만 답이 아닌 결과가 top-k에 섞인다 | 고정 길이 청킹과 중복 템플릿이 벡터 공간의 잡음을 키운다 |
| 벡터 검색 포화 | p95 응답 시간이 급격히 늘어난다 | 거대한 단일 인덱스와 런타임 임베딩 비용이 누적된다 |
| 컨텍스트 과적재 | 더 많은 문서를 넣었는데 답이 나빠진다 | 모델의 주의(attention)가 근거보다 잡음에 분산된다 |
1. 청킹보다 구조를 먼저 보존한다
문서를 일정 토큰 수로만 쪼개면 제목, 절, 표, 정책 버전 같은 의미 경계가 사라진다. 대규모 코퍼스에서는 다음 정보를 색인 단계에서 함께 보존해야 한다.
- 문서 ID, 버전, 섹션 경로, 권한 범위, 최신성
- 헤더·문단·표를 기준으로 한 의미 청크
- 푸터, 법적 고지, 템플릿처럼 반복되는 보일러플레이트 제거
문서 -> 섹션 -> 청크의 계층을 유지하면 먼저 관련 문서와 섹션을 좁힌 뒤 필요한 청크만 검색할 수 있다.
2. 검색 경로를 단계화한다
대규모 인덱스 전체에 매번 동일한 벡터 질의를 던지는 대신, 메타데이터와 검색 단계를 결합한다.
질의
-> tenant / 제품 / 날짜 / 권한 필터
-> BM25 + 벡터 하이브리드 검색
-> cross-encoder 리랭킹
-> 상위 근거만 LLM 컨텍스트로 전달파티션 인덱스(partitioned index)는 검색 공간을 줄이고, 문서 임베딩은 수집 시 미리 계산한다. 자주 반복되는 질의나 요약에는 캐시를 적용해 런타임 계산량을 통제한다.
3. 컨텍스트는 양이 아니라 밀도로 최적화한다
검색 결과 30개를 모두 프롬프트에 붙이는 방식은 검색 실패를 생성 단계로 넘길 뿐이다. 실제 운영에서는 상위 근거를 리랭킹하고, 중복 내용을 압축하며, 응답과 함께 인용을 반환해야 한다.
| 데모 구현 | 확장 가능한 구현 |
|---|---|
| 고정 토큰 청킹 | 문서 구조 기반 청킹과 중복 제거 |
| 벡터 검색만 사용 | 필터 + 하이브리드 검색 + 리랭킹 |
| 단일 거대 인덱스 | 계층형·파티션 인덱스 |
| 많은 컨텍스트 전달 | 근거 압축과 인용 가능한 소수 청크 |
적용 순서
- 검색 실패 사례와 p95 지연 시간을 먼저 측정한다.
- 청크에 문서 구조·버전·권한 메타데이터를 추가한다.
- 메타데이터 필터와 하이브리드 검색을 도입한다.
- 리랭커와 인용 기반 답변 평가를 붙인다.
- 색인 버전 교체와 캐시 무효화를 배포 절차로 관리한다.
프로덕션 운영의 인덱스 정합성, 배포, 추적 설계는 rag-tips-production과 함께 적용하는 것이 좋다.
참고 자료
- When RAG Hits the Wall: Designing Systems That Scale from 1,000 to 1 million Documents – Microsoft Developer Community Blog (2026-05-22)