RAG 문서가 많아질수록 먼저 좁혀야 한다
논문 『When More Documents Hurt RAG: Mitigating Vector Search Dilution with Domain-Scoped, Model-Agnostic Retrieval』를 읽고
문서가 많아질수록 RAG 검색 품질이 오히려 희석될 수 있다는 연구를 바탕으로, 업무 지식관리와 검색 설계에서 먼저 좁혀야 할 기준을 정리한다.
제일 먼저 든 생각
RAG를 만들 때 가장 쉬운 유혹은 “문서를 더 넣으면 더 똑똑해지겠지”라는 생각이다. 이 논문은 그 반대편에서 출발한다. 문서가 많아질수록 검색 후보가 풍부해지는 것이 아니라, 비슷해 보이지만 맥락은 틀린 조각들이 상위 결과를 차지하면서 정확도가 떨어질 수 있다는 것이다. 저자들은 이 현상을 **벡터 검색 희석(vector search dilution)**이라고 부른다.
RAG를 업무에 붙일 때 자주 생기는 착각은 문서를 많이 넣을수록 답이 좋아진다는 믿음이다. 실제로는 검색 범위를 먼저 좁히지 않으면 중요한 근거가 후보 더미 속에 묻힐 수 있다.
이 표현이 마음에 걸렸다. 회사 지식관리에서도 같은 일이 일어난다. 회의록, 제안서, 교육자료, 규정, FAQ를 모두 넣어두면 처음에는 든든해 보인다. 그런데 실제 질문이 들어오면 “비슷한 말”은 찾지만 “지금 이 부서·업무·문서 유형에 맞는 답”을 놓치는 경우가 생긴다.
문서를 많이 넣기 전에, 어떤 범위에서 찾을지 먼저 정해야 한다는 점이 핵심이다.
더 큰 인덱스가 항상 더 좋은 검색은 아니다
논문의 사례는 와이오밍 교통부(Wyoming Department of Transportation) 문서 기반 챗봇이다. 저자들은 문서 수가 54개에서 1,128개, 청크 수 88,907개로 늘어났을 때 표준 명세 관련 질문의 정확도가 75%에서 40% 아래로 떨어졌다고 보고한다. 하이브리드 검색(dense+sparse retrieval)을 써도 문제는 남았다.
우리는 이 실패 양식을 벡터 검색 희석이라고 부른다. 54개 문서에서 1,128개 문서로 확장했을 때 정확도는 75%에서 40% 아래로 떨어졌다.
“We refer to this failure mode as vector search dilution… scaling from 54 to 1,128 documents (88,907 chunks) reduced accuracy from 75% to below 40%.”
원인은 검색기가 “가까운 벡터”를 찾지 못해서만은 아니다. 가까운 이웃을 찾았는데도, 그것이 질문의 업무 맥락에는 맞지 않는 경우가 늘어난다. 의미적으로는 비슷하지만 문서 범주, 부서, 규정 맥락이 다른 조각이 섞이는 것이다.
업무 RAG에서 이 문제는 아주 현실적이다. “휴가 승인 기준”을 물었는데 교육 운영 매뉴얼의 휴가 예시가 나오거나, “평가 결과 공개 범위”를 물었는데 전년도 프로젝트 회고 문서가 검색되는 식이다. 둘 다 단어는 비슷하지만 답으로 쓰면 위험하다.
저자들의 처방: 먼저 스코프를 정하고, 합성은 단순하게
논문은 MASDR-RAG(Multi-Agent Scoped Domain Retrieval for RAG)를 제안하지만, 결론이 무작정 “에이전트를 많이 쓰자”로 흐르지는 않는다. 오히려 실무 권고는 간명하다. 조직 메타데이터로 검색 범위를 먼저 좁히고, 가능하면 단일 합성 호출을 사용하라는 것이다.
실무 권고는 단순하다. 먼저 범위를 좁히고, 그다음 단일 합성 호출을 수행하라. 완전한 다중 에이전트 조율은 진짜 다중 도메인 코퍼스와 네이티브 도구 호출 백본이 있을 때 남겨두라.
“our practical recommendation is simple: scope first, then perform a single synthesis call, reserving full multi-agent orchestration for genuinely multi-domain corpora paired with native-tool-call backbones.”
이 대목이 좋았다. 요즘 RAG 설계에서는 라우터, 멀티에이전트, 그래프, 재랭킹 같은 장치를 계속 붙이고 싶어진다. 그런데 논문은 “복잡하게 조율하기 전에 조직이 이미 알고 있는 메타데이터를 써라”라고 말한다. 문서의 출처, 부서, 문서 유형, 적용 연도, 업무 프로세스 단계 같은 정보가 검색 성능의 핵심 설계 재료가 될 수 있다.
본문 결과에서도 도메인 스코핑(domain scoping)은 P@10을 0.77에서 0.86으로 올리는 핵심 요인으로 보고된다. 반면 다중 에이전트 조율은 구성에 따라 결과가 달라졌고, 어떤 스택에서는 정밀도와 충실도 사이의 역설(precision–faithfulness paradox)이 나타났다고 한다. 더 많이 나누고 더 많이 합친다고 항상 안전해지는 것은 아니다.
원문 첫 페이지. RAG 성능 저하를 “문서 수 증가”가 아니라 “맥락 범위가 흐려지는 문제”로 진단한다.
Deciflow식 실무 적용
이 논문을 읽고 바로 바꾸고 싶은 것은 벡터DB가 아니라 문서 수집표다. RAG 프로젝트를 시작할 때 “파일을 어디까지 모을까”보다 “질문을 받을 때 어떤 범위로 먼저 좁힐까”를 표준 항목으로 넣어야 한다.
작은 실험은 이렇게 해볼 수 있다.
- 기존 문서 폴더를 전부 넣기 전에 문서마다
부서,업무,문서유형,적용기간,권한수준메타데이터를 붙인다. - 질문 예시 30개를 만들고, 각 질문에 정답 문서 범위를 사람이 먼저 표시한다.
- 전체 검색과 메타데이터 스코프 검색을 나눠 P@5 또는 P@10을 비교한다.
- 답변 생성보다 먼저 “검색 후보가 맞는 문서군에서 왔는가”를 평가한다.
- 멀티에이전트 구조는 단일 스코프 검색의 실패 유형이 분명해진 뒤에 붙인다.
Power BI나 업무 대시보드에도 같은 원리가 있다. 모든 지표를 한 화면에 넣는다고 좋은 분석이 되지 않는다. 질문의 범위를 좁히는 필터, 기간, 조직 단위가 먼저 맞아야 해석이 안전해진다. RAG도 결국 검색형 대시보드라면, 첫 설계는 모델이 아니라 스코프일 수 있다.
오늘 남기는 질문
우리의 RAG 프로젝트에서 “더 넣을 문서” 목록만큼이나 먼저 좁혀야 할 문서 범위 목록을 관리하고 있을까. 다음 지식관리 실험에서는 문서 추가량보다, 질문이 들어왔을 때 어떤 메타데이터로 검색 영역을 잠그는지부터 설계해보고 싶다.
함께 읽을 노트
원문 정보
- 제목: When More Documents Hurt RAG: Mitigating Vector Search Dilution with Domain-Scoped, Model-Agnostic Retrieval
- 저자: Nabaraj Subedi, Ahmed Abdelaty, Shivanand Venkanna Sheshappanavar
- 소속: University of Wyoming, 논문 표기 기준
- 연도/게시일: 2026
- 게재/출처: arXiv
- arXiv: 2606.11350v1
- PDF: https://arxiv.org/pdf/2606.11350