중복 문서 제거의 함정과 비용, RAG 설계 노트

Q: 문서 단위로 지울까, 청크 단위로 지울까?

둘은 서로 다른 문제를 해결한다.

RAG에서 중복 문서를 지우면 검색 품질이 좋아질까?

항상 그렇지는 않다. 완전 중복(동일 바이트·동일 텍스트) 제거는 대체로 안전하지만, 준중복 제거는 임계값과 적용 단계에 따라 정답 근거 자체를 날릴 수 있다. 판단 기준은 "삭제했더니 Recall이 유지되면서 top-k의 고유 source 비율이 올라갔는가"다.

흔히 빠지는 함정은 "비슷하면 일단 지운다"는 1차원 규칙이다. 임베딩 유사도가 높다는 이유만으로 날짜나 수치가 다른 두 보고서를 하나로 합쳐버리면, 질문이 특정 분기나 특정 수치를 물을 때 근거 문서가 아예 검색되지 않는다. Databricks의 RAG 파이프라인 문서는 수집 이후 중복·준중복 탐지 → 청킹 → 임베딩 → 인덱싱 순서를 제시하는데, 준중복은 단순 문자열 일치가 아니라 MinHash와 Jaccard 유사도 기반 similarity join으로 찾는다. 즉 "완전 일치"와 "단어 집합 유사"는 처음부터 다른 문제로 분리해서 다룬다Databricks.

핵심 정리

완전 중복은 해시로, 준중복은 MinHash·Jaccard로 분리해서 처리한다.
중복 제거의 실제 목적은 저장 절약이 아니라 top-k가 같은 출처를 독점하지 않게 만드는 것이다.
문서 단위 삭제와 청크 단위 삭제는 서로 다른 부작용을 낳으므로 따로 측정해야 한다.
준중복이 많은 도메인(금융 공시 등)은 유사도 임계값 하나로 해결되지 않는다.
삭제 전후 Recall·고유 source 비율·지연시간·토큰 수를 같이 기록해야 효과를 판단할 수 있다.

문서 단위로 지울까, 청크 단위로 지울까?

둘은 서로 다른 문제를 해결한다. 문서 전체를 먼저 지우고 나서 청킹하면 같은 문서의 다른 버전, 부록, 표가 함께 사라질 위험이 있다. 반대로 청크를 먼저 만든 뒤 중복을 제거하면, 검색 시 같은 원문에서 나온 여러 청크가 top-k를 독점하는 문제를 줄일 수 있다.

2025년 HASH-RAG는 이 구분을 실험으로 다뤘다. 여러 proposition(명제 단위 조각)을 원문서로 매핑한 뒤 document ID 기준으로 중복을 제거해, 최종 top-k에는 서로 다른 문서가 반환되도록 설계했다. NQ, TriviaQA, HotpotQA에서 이 방식은 기존 검색기 대비 검색 지연을 약 90% 줄였고 문서 recall@20/100을 0.2~8.6% 높였다고 보고됐다HASH-RAG. 다만 이 수치는 해당 연구의 모델·인덱스·데이터셋 조건에서 나온 결과이지, 모든 문서 QA 파이프라인에 그대로 적용되는 일반 개선폭은 아니다.

실무에서는 두 지점을 모두 측정하는 편이 안전하다. 문서 단위 제거만 보면 저장 공간은 줄지만 청크 단위에서 여전히 같은 내용이 반복될 수 있고, 청크 단위 제거만 보면 원문 맥락이 끊겨 표·각주가 누락될 수 있다.

임베딩 전/후 어디서 걸러야 비용이 덜 들까?

제거 시점을 나누면 같은 규칙을 모든 데이터에 일괄 적용하는 실수를 줄일 수 있다. 원문이 완전히 동일한 경우는 파일 해시나 정규화한 텍스트 해시로 임베딩 전에 걸러낸다. 이 단계에서 걸러내면 임베딩 호출 자체가 줄어 비용 절감 효과가 가장 직접적이다.

문장 순서나 서식만 다른 준중복은 MinHash·LSH로 후보를 좁힌 뒤 임계값으로 판정한다. 2025년 Q2D-Web 연구는 약 1억 9천만 문서, 약 7만 검색 질의 규모에서 토큰 5-gram 집합의 Jaccard 유사도 0.975 이상인 문서를 MinHash-LSH로 클러스터링했다Q2D-Web. 이 0.975라는 값은 해당 연구의 대규모 코퍼스 설정일 뿐, 모든 문서 QA 시스템에 권장되는 보편 임계값으로 보면 안 된다.

의미가 비슷하지만 날짜나 수치가 다른 문서는 임베딩 유사도만으로 자동 삭제하지 않는 편이 안전하다. 메타데이터와 핵심 필드(보고기간, 버전, 수치)를 함께 비교해야 한다. 마지막으로 검색 결과에서 같은 source가 반복되는 문제는 색인을 건드리지 않고도 완화할 수 있다. source ID·document ID별 최대 반환 개수를 두는 후처리 방식이다.

비용 측정 항목으로는 중복 제거 전후의 임베딩 건수, 저장 벡터 수, 인덱스 크기, 재색인 시간, 질의 p50·p95 지연시간, LLM 입력 토큰 수를 함께 기록한다Databricks. 특정 클라우드나 임베딩 모델에서 실제로 얼마가 절감되는지는 데이터 규모와 요금제에 따라 달라서 별도 측정이 필요하다.

준중복이 많은 공시 문서는 뭐가 다를까?

금융 공시처럼 반복 서식이 많은 도메인은 유사도 임계값 하나로 접근하면 실패하기 쉽다. 2025년 LOFin 연구는 SEC 공시가 반복적인 boilerplate와 유사한 표 구조를 공유해, 전통적인 RAG가 near-duplicate 텍스트를 계속 검색한다고 지적했다. 이 연구의 LOFin 벤치마크는 SEC 문서 145,897건과 질문·정답 1,595개로 구성됐다LOFin.

LOFin은 문서를 통째로 지우는 대신 계층적 검색과 evidence curation(증거 선별)을 사용해 반복 문구의 영향을 줄이고, 필요하면 보완 질의를 생성해 누락된 정보를 보충했다. 공시처럼 여러 문서가 같은 서식을 공유하는 경우, 유사도 하나로 전부 삭제하기보다 회사·보고기간·문서유형·섹션 메타데이터를 함께 써야 한다는 결론이다. 이 접근은 "중복 제거"라기보다 "검색 결과 중 어떤 증거를 근거로 쓸지 선별"하는 쪽에 가깝다.

임베딩 유사도만 높으면 중복으로 봐도 될까?

아니다. 이게 이 글에서 가장 자주 발생하는 오해다. 의미가 비슷하다는 것과 내용이 같다는 것은 다르다. 같은 회사의 1분기와 2분기 보고서는 문장 구조와 용어가 거의 동일해 임베딩 유사도가 높게 나올 수 있지만, 수치와 기간이 다르면 서로 다른 근거 문서다.

이를 막기 위한 구현상의 안전장치가 있다. 검색 결과를 LLM에 전달하기 전에 source_id, document_id, version, section, published_at을 함께 제공하고, "같은 source의 반복 내용은 한 번만 근거로 사용하라", "날짜·수치가 다르면 중복으로 합치지 말라", "충돌 시 최신 문서와 원문을 우선하고 차이를 명시하라"는 규칙을 두는 방식이다. 중복 제거를 색인 단계에서 과도하게 밀어붙이는 대신, 검색·생성 단계에서 다시 통제하는 이중 장치로 볼 수 있다.

평가 세트를 만들 때도 같은 문제가 생긴다. MIRAGE는 7,560개 QA와 37,800개 문서 청크로 구성되며, 각 질문에 정답에 필요한 positive 청크와 내용은 비슷하지만 핵심 정보가 빠진 negative 청크를 함께 둔다. 이 구축 과정에서도 중복 문서 출처를 제거해 주제 다양성을 확보했는데, 별도 처리 없이 동일 출처의 여러 표현을 평가 세트에 넣으면 검색기가 실제로 다양한 문서를 찾았는지 구분하기 어렵다MIRAGE. 다만 MIRAGE의 수치는 2025년 버전 기준이며, 공개 페이지에는 2026년 업데이트 정보가 함께 표시되므로 인용할 때는 버전과 공개일을 같이 적는 편이 재현성에 도움이 된다.

중복 제거 효과를 어떻게 검증하고 기록해야 할까?

실험 설계를 고정하지 않으면 중복 제거의 효과인지 다른 변수의 효과인지 구분할 수 없다. 원본 코퍼스와 중복 제거 코퍼스를 동일한 임베딩 모델로 색인하고, chunk size·overlap·top-k·reranker·LLM을 고정한 뒤, 완전 중복 제거·MinHash 준중복 제거·검색 결과 source 제한을 각각 분리해서 실험하는 방식을 권장한다.

비교 지표는 Recall@5·Recall@20·nDCG·고유 source 수·p95 지연시간·입력 토큰 수다. 날짜·수치·표가 포함된 질문은 별도 오류율로 따로 집계해야 하는데, 이런 질문이 준중복 제거의 부작용을 가장 먼저 드러내기 때문이다. 삭제된 문서 샘플은 사람이 검수해 false positive 비율을 기록한다.

보존 우선순위도 미리 정해두는 편이 운영에 유리하다. 동일 내용이면 최신 수정일 문서를, 동일 날짜면 공식 원문이나 신뢰도 높은 출처를, 동일 출처면 언어·문서 유형 조건을 만족하는 문서를, 그리고 표·각주·부록이 더 완전한 문서를 남긴다. 삭제된 문서는 원본 ID와 삭제 사유를 로그에 남겨, 나중에 특정 질문에 답이 안 나올 때 원인을 역추적할 수 있게 한다. 2026년 기준으로 이런 로그는 벤치마크 재현성 검증에도 그대로 쓸 수 있다.

핵심 정리

완전 중복은 해시로 임베딩 전에, 준중복은 MinHash·LSH 후보 선별 뒤 메타데이터 확인을 거쳐 제거한다.
문서 단위 제거와 청크 단위 제거는 서로 다른 부작용을 가지므로 각각 측정한다.
금융 공시처럼 서식이 반복되는 도메인은 임계값 하나보다 메타데이터 기반 증거 선별이 적합할 수 있다.
임베딩 유사도만으로 날짜·수치가 다른 문서를 합치면 근거가 사라지므로, 프롬프트 단의 중복 제어 규칙을 함께 둔다.
효과 검증은 Recall·고유 source 비율·지연시간·토큰 수를 같은 조건에서 비교해야 의미가 있다.