#검색 결과가 많을수록 답이 나빠진다면 — 윈도우 오버플로우가 아니라 상하문 오염이다

← 전체 목차 · 이전: 대량 제로 리콜은 어떻게 트러블슈팅하는가 · 다음: RAG 시스템의 프롬프트 인젝션은 어떻게 막나

"모델 윈도우가 부족하다, 대화 기록을 좀 지우면 된다" — 짧은 문답에서는 잘 맞던 시스템이 다중 턴·다문서로 넘어가면 답이 뒤죽박죽된다. 이 증상을 이 한 문장으로 설명하면 절반은 틀린다. 대다수 RAG 사고는 "자료를 못 찾아서"가 아니라 "답에 들어가서는 안 될 자료를 너무 많이 찾아서" 일어난다.

#두 개의 다른 병: 윈도우 오버플로우 vs 상하문 오염

오버플로우 = 용량 부족 → 내용 유실
오염     = 노이즈 과다 → 논리 왜곡

둘을 혼동하면 "일단 더 큰 윈도우 모델로 바꾼다"는 값비싼 오진에 빠진다 — 창을 키우면 담을 수 있는 쓰레기의 양만 늘어난다.

#오염의 네 근원

노이즈는 중립적이지 않다. 컨텍스트에 들어간 조각은 단지 자리를 차지하는 게 아니라 추론에 능동적으로 참여한다 — 참고자료를 컨텍스트에 넣는 행위 자체가 그 내용에 신뢰도를 부여하는 것과 같다. 그래서 "해로워 보이지 않는" 참고자료를 더 넣었는데 답이 더 이상해지는 역설이 생긴다.

#4층 정화 파이프라인

1층 · 검색층 감소     TopK 결과 → 유사도 임계값 필터 → Rerank 재정렬
                     → 고관련 핵심 조각만 통과
                     원칙: 첫 칼은 모델 답변이 아니라 열등 검색 결과를 겨눈다

2층 · 상하문 동적 절삭  전량 이력 반입 금지
                     → 현재 질문 의미로 관련 이력 턴만 동적 선별
                     → 만료/무관/무효 대화 자동 폐기
                     원칙: 완전할수록 좋은 게 아니라 관련 있고, 신선하고, 절제될수록 좋다

3층 · 중복 제거 + 권위 우선  유사도 중복 제거로 중복 단락 정리
                          문서 가중치 + 버전 우선순위 → 신 문서가 구 문서를 덮는다
                          권위 문서를 우선 상하문에 편입
                          원칙: 다문서는 단순 접합이 아니라 먼저 중복·충돌·권위를 해결해야 한다

4층 · 상하문 압축 제련   텍스트 압축·요약 제련 기술
                      무효 화술·중복 서두·무효 공백 제거
                      핵심 데이터·규칙·결론만 보존
                      원칙: 압축의 목표는 "짧게"가 아니라 "토큰당 증거 밀도"다

#제로 리콜(19번)과의 경계

제로 리콜은 **"검색 결과가 아예 없다"**는 상류 장애다. 상하문 오염은 정반대 축이다 — 검색은 충분히, 심지어 과하게 되는데, 그 결과가 답의 논리를 흐린다. 하나는 리콜량이 부족해서 생기고, 다른 하나는 리콜량을 무분별하게 늘려서 생긴다. 두 문제를 같은 처방(TopK를 늘린다)으로 다루면 오염 쪽 증상은 오히려 악화된다.

#다중턴 붕괴 문서와의 경계

다중턴 대화에서만 발생하는 검색 전략 실효(원 질문의 지시 대상 해소, 대화 상태에 적응하는 동적 검색 로직 설계)는 **별도 문서(다중턴 RAG 붕괴 — 4대 검색단 병목)**가 다룬다. 이 문서는 그보다 상위의 진단 틀이다 — 단일 질의든 다중 턴이든, 검색이 "충분히" 혹은 "과하게" 됐을 때 그 결과물의 순도를 어떻게 관리할 것인가를 다룬다. 두 문서는 겹치는 지점(이력 희석)이 있지만 전자는 "무엇을 검색할 것인가"를, 이 문서는 "검색된 것 중 무엇을 남길 것인가"를 묻는다는 점에서 갈린다.

#핵심 통찰

1. RAG의 병목은 "리콜률"에서 "정보 순도"로 이동했다 — 단문 단답 단계에서는 많이 리콜할수록 안전했지만, 다중 턴·다문서로 가면 무효 조각의 한계 피해가 유효 조각의 한계 수익을 넘어선다. 시스템 성숙도는 얼마나 많이 담을 수 있는가가 아니라 얼마나 과감히 버릴 수 있는가로 판단한다.
2. 오버플로우와 오염은 서로 다른 병이며 오진하면 엉뚱한 약을 쓴다 — 오버플로우는 용량병(증상: 잘림), 오염은 순도병(증상: 논리 붕괴·전후 모순). 오염을 오버플로우로 오진해 창을 키우면, 창은 늘어난 만큼의 쓰레기를 더 담을 뿐 병은 낫지 않는다.
3. 컨텍스트에 들어간 노이즈는 중립적이지 않고 추론에 능동 개입한다 — 무해해 보이는 참고자료를 넣는 행위 자체가 모델에게 "이것도 신뢰할 근거"라는 신호를 준다. 그래서 참고자료를 늘렸는데 답이 더 이상해지는 현상이 설명된다.
4. 다중 턴 이력은 "망각할 줄 알아야" 한다 — 전량 이력 반입은 가장 손쉽지만 가장 위험한 구현이다. 만료 요구가 지속 누적되어 옛 정보가 새 의도를 덮고, 모델이 몇 턴 전 질문에 답하기 시작한다. 완전성보다 관련성과 신선도가 우선한다.
5. 다문서 상황의 1순위 문제는 접합 순서가 아니라 권위다 — 서로 다른 버전·규범이 충돌하는데 시스템이 우선순위를 주지 않으면, 모델은 편을 들지 않는다 — 절충한다. 양쪽에 걸치고 어느 쪽도 맞지 않는 답을 낸다. 충돌은 반드시 컨텍스트 진입 전에 해소해야 한다.
6. 중복은 증거 강화가 아니라 주의력 소모다 — 같은 문장이 세 조각에서 중복 적중되면 교차 검증처럼 보이지만 실제로는 창과 주의력 예산을 태워, 정작 중요한 규칙을 가장자리로 밀어낸다.
7. 상하문 압축의 목표는 길이가 아니라 밀도다 — "짧아지는 것"은 부산물일 뿐, 진짜 지표는 토큰 하나가 담는 유효 증거량이다. 화술·서두·공백을 제거하는 수익이 더 큰 윈도우 모델로 바꾸는 것보다 클 때가 많다.
8. 이 문제가 몸값을 가르는 이유는 컴포넌트 지식이 아니라 관리 능력을 묻기 때문이다 — 벡터DB를 호출할 줄 알고 프롬프트를 쓸 줄 아는 것은 컴포넌트 지식이다. 오염이 어느 네 개의 문으로 들어오는지 알고 매 층마다 관문을 설계하는 것이 프로덕션 구현 능력이다.

#엔지니어링 실전 Tips

• 먼저 병명을 정할 것: 답이 끊기거나 미완성이면 오버플로우, 답이 앞뒤가 안 맞거나 무관한 정보에 끌려가면 오염이다. 오진하면 "무조건 큰 윈도우 모델로 바꾼다"는 무효 동작에 예산을 태운다.
• TopK는 조정 항목이지 수익 항목이 아니다: TopK를 늘리면 저관련·중복·만료·충돌 네 종류 내용이 함께 늘어 유효 정보 비중이 지속 하락한다. K를 올리기 전에 임계값 필터와 Rerank가 이미 켜져 있는지 먼저 볼 것.
• "신 버전이 구 버전을 덮는다"는 검색 파이프라인에 심을 것, 프롬프트에 당부하지 말 것: 문서 가중치·버전 우선순위는 데이터 계층 정책이다. 프롬프트에 "최신 기준으로 답하라"고 써 봐야 모델은 애초에 최신·권위 출처를 자동으로 가려내지 못한다.
• 중복 제거는 청킹 단계에서 할 것: 중복 단락은 서로 다른 조각이 같은 내용을 중복 적중해서 생긴다. 최종 접합 시점에만 눈으로 훑어서는 잘 드러나지 않으므로 유사도 기반 중복 제거를 명시적으로 넣을 것.
• 상하문 상태 점검 지표는 "유효 정보 비중"으로 잡을 것: 이 값을 관측 가능한 지표로 만들면 리콜 적중률만 보는 것보다 답변 품질을 훨씬 잘 예측한다.
• 제련 대상에는 포맷 쓰레기도 포함된다: 무효 공백·중복 서두는 의미에 영향을 주지 않으면서도 실질적으로 토큰을 잡아먹는다. 투입 대비 산출이 가장 좋은 최적화 한 가지다.
• 대화 축수·검색 건수 제한은 지혈일 뿐 치리가 아니다: 작은 트래픽에서는 버티지만 사용자·문서가 늘면 다시 붕괴하고 환각이 폭증한다. 임시 조치로만 취급하고 정식 방안으로 보고하지 말 것.
• 더 파고들 방향: 4층 정화 파이프라인을 계측 가능한 지표로 만들기(임계값 필터 전후 조각 수, Rerank 후 유효 정보 비중, 중복 제거율, 압축 후 토큰당 정보 보존율), 다중 턴 이력의 망각 전략 세부 설계(망각 윈도우 길이, 의도 전환 탐지), 이 치리 구조를 Agent의 도구 반환값·중간 스텝 기록에 그대로 옮기기(같은 네 근원과 네 층이 구조적으로 재사용 가능).