#다중 홉 질문은 왜 절반만 답해오나 — 리콜 불완전 3층 방어

← 전체 목차 · 이전: 분산된 문서 증거를 어떻게 조립하는가 · 다음: 신구 제도가 동시에 존재하면 어떻게 처리하는가

제품 상담 RAG에게 "엔터프라이즈판과 플래그십판은 데이터 보안에서 어떤 차이가 있고, 어느 쪽이 프라이빗 배포를 지원하나요?"라고 물었다. 답변은 엔터프라이즈판 보안 특성만 설명하고 플래그십판은 언급조차 하지 않았으며, 심지어 "두 버전 모두 프라이빗 배포를 지원하지 않는다"고 잘못 단언했다. 사용자는 경쟁사 스크린샷을 들고 항의했다.

사후 조사: 벡터 DB에는 엔터프라이즈판·플래그십판 문서가 모두 저장되어 있었고, 모델도 정상이었다. 문제는 검색이 "찾을 수 있는데 못 찾은" 것이 아니라 — 여러 주체를 비교해야 하는 질문에서 한쪽 주체의 리콜 자리를 다른 쪽이 독차지했다.

#"유령 함정" — 에러 없이 조용히 실패하는 결함

이 결함에 별명을 붙이자면 유령 함정이다. 왜냐하면:

• 벡터 DB는 정상적으로 조회된다.
• 모델은 정상적으로 매끄럽게 생성한다.
• 로그에도 에러가 없다.
• 다만 사실의 절반이 조용히 빠졌을 뿐이다.

에러가 나는 답보다 유창한 반쪽짜리 답이 훨씬 위험하다. 사용자는 의심하지 못하고 그대로 행동에 옮긴다.

#원인: 단일 홉과 다중 홉은 다른 문제다

다중 홉 문제는 "더 어려운 단일 홉 문제"가 아니라 다른 종류의 문제다. TopK를 늘리는 방식으로는 해결되지 않는다 — 자리를 늘려도 여전히 같은 주체가 상위를 채운다.

#3층 방어

사용자 Query
   │
   ├─[1층] 입구 분급 ─ 검색 전에 처리
   │      단일 홉 간단 질문  → 표준 벡터 검색 TopK
   │      다중 홉 복합 질문  → Query 분해
   │        원 질문을 하위 질문으로 쪼갠 뒤 각각 독립 검색 → 다경로 결과 합병·중복 제거
   │        예: "A·B 보안 차이, C 지원 여부"
   │            → 서브쿼리1: A 보안 특성
   │            → 서브쿼리2: B 보안 특성
   │            → 서브쿼리3: C 지원 버전
   │      고위험 시나리오(가격·법규·권익 약속) → 벡터+키워드 강제 혼합 소환
   │
   ├─[2층] 리콜 품질 검증과 보완 ─ 검색 직후
   │      상관성 재정렬 → 임계값 미만 조각은 버림 + 동시에 이차 검색 촉발(동의어·업계 용어 보충 후 재검색)
   │      인용 출처 강제 → 결론마다 출처 조각을 명시, 출처 없는 내용은 생성 금지 ("생성단에서 리콜 품질을 거꾸로 강제")
   │      답변 완전성 검증 → 비교형·열거형 질문에 한해, 출력 전 질문 속 모든 주체를 나열해 답변과 대조. 빠진 주체가 있으면 그 주체만 재검색
   │
   └─[3층] 아키텍처 레벨 ─ 인덱스 자체를 손본다
          의미 단위 청킹 → 고정 길이 대신 제목 계층·단락 의미로 분할, 각 조각에 소속 문서·상위 제목 정보를 유지(상하문 단절·신원 상실 방지)
          이중층 인덱스 → 문서 요약층 + 전문 조각층. 먼저 요약에서 관련 문서를 특정한 뒤 그 문서 내부에서 세밀 검색(교차 문서 간섭 차단)
          지식베이스 증분 갱신 → 문서 갱신 시 벡터·요약 인덱스를 함께 갱신하고 버전 표기, 검색 시 최신 버전 우선 반환

2층의 "답변 완전성 검증"이 사고 현장에 정확히 대응한다: 엔터프라이즈판 조각의 상관성 점수는 높았을 것이다(그래서 리콜됐다). 하지만 질문 속 주체 목록("엔터프라이즈판", "플래그십판")과 답변에 등장한 주체를 대조하면 플래그십판 누락이 즉시 드러난다. 상관성 점수는 커버리지를 보장하지 않는다.

#핵심 통찰

1. "리콜 불완전"은 모델이 못 찾은 게 아니라 여러 주체가 같은 자리를 두고 경쟁한 결과다 — 벡터 공간에서 "엔터프라이즈판"과 "플래그십판"은 의미적으로 매우 가깝기 때문에, 단일 Query의 TopK는 둘 중 하나로 채워지기 쉽다. Query를 하나 던지는 것 자체가 구조적 편향을 만든다.
2. 다중 홉 문제의 해법은 K를 늘리는 것이 아니라 검색 통로를 나누는 것이다 — Query 분해로 각 주체가 독립된 검색 통로를 갖게 되면, 더 이상 같은 이름값의 자리를 두고 다투지 않는다.
3. 의미 유사 ≠ 업무 핵심 — 가격·법규·권익 약속처럼 정확한 문자(버전명, 조항 번호)로 구별되는 내용은 순수 벡터 검색이 가장 쉽게 놓친다. 벡터가 "뜻이 가깝다"를 맡고 키워드가 "글자가 맞다"를 맡아야 서로의 사각지대를 메운다.
4. 생성단 제약이 검색단 결함을 가장 값싸게 드러낸다 — "결론마다 출처 조각을 명시하고, 없으면 생성하지 않는다"는 규칙을 생성 쪽에 걸어두면, "두 버전 모두 지원하지 않는다"처럼 근거 없는 단언이 이 관문에서 저절로 걸러진다.
5. 비교·열거형 질문은 상관성 점수가 못 보는 차원이 있다 — 답변에 인용된 조각 하나하나의 점수는 전부 높을 수 있다. 그런데도 답이 반쪽인 이유는 "점수가 높다"와 "질문의 모든 주체를 커버했다"가 서로 다른 조건이기 때문이다. 질문에서 주체 목록을 뽑아 답변과 대조하는 것은 점수 체계 밖의 별도 검증이 필요하다.
6. "지식베이스를 전부 모델에 던진다"는 이 문제의 표준 오답이다 — 긴 컨텍스트 시대의 가장 유혹적인 게으른 해법이지만, 비용·지연·노이즈 세 겹의 대가를 치른다. 3층 방어의 목적은 정확도를 컨텍스트 길이로 사는 대신 분급·검증·아키텍처로 사는 것이다.
7. 청킹 전략이 리콜율의 상한을 정하고, 뒤의 두 층은 그 상한 안에서 구제할 뿐이다 — 고정 길이 청킹은 상하문을 자르고 조각의 신원 정보를 함께 지워버린다. 소속 문서·상위 제목을 유지하는 의미 단위 청킹이 있어야 "문서를 먼저 특정하고 문서 내부를 세밀 검색"하는 이중층 인덱스가 성립한다.
8. 이 결함은 보고되지 않기 때문에 관측 가능한 신호로 만들어야 한다 — 조각 대량 폐기율, 출처 없는 결론 발생률, 주체 미커버율처럼 2층에서 나오는 신호를 모니터링에 얹지 않으면, "리콜 불완전"은 사용자 항의가 접수되기 전까지 시스템 어디에도 나타나지 않는다.

#엔지니어링 실전 Tips

• 먼저 사고를 복기해 병소를 특정할 것: 관련 문서가 지식베이스에 있는지, 정답 조각을 손으로 Prompt에 끼워 넣으면 모델이 맞히는지 두 가지를 확인해야 "리콜 불완전"인지 "모델·Prompt 문제"인지 갈린다.
• 버림과 보충은 항상 짝으로 움직일 것: 임계값 미만 조각을 버리는 것은 뺄셈이고, 동의어·업계 용어를 보충해 재검색하는 것은 덧셈이다. 뺄셈만 하면 리콜율이 자기 임계값에 의해 더 깎인다.
• 완전성 검증은 비교·열거형에만 걸 것: 질문에서 주체 목록을 직접 뽑을 수 있는 이 두 유형에만 적용해야 비용 대비 효과가 맞는다. 개방형 질문에 무리하게 적용하면 오탐이 많아진다.
• 조각에는 반드시 소속 문서·상위 제목 정보를 실을 것: 사소한 메타데이터처럼 보이지만, 이중층 인덱스가 성립하는 전제 조건이자 답이 엉뚱한 버전에 뒤섞이는 것을 막는 열쇠다.
• 인덱스 갱신은 벡터·요약을 동시에 이중 쓰기하고 버전을 붙일 것: 둘 중 하나만 갱신되면 "요약은 최신 문서를 가리키는데 조각은 옛 버전"인 어긋남이 생긴다.
• 고위험 시나리오 목록을 미리 정의할 것: 가격·법규·권익 약속 같은 단어를 트리거로 등록해 자동으로 혼합 소환으로 승급시키고, 사용자의 표현이 우연히 이 단어를 쓰기를 기대하지 말 것.
• 더 파고들 방향: 입구 분급기 자체의 정확도 담보(단일 홉/다중 홉/고위험 오분류 시 뒤의 3층이 통째로 틀어짐), Query 분해의 하위 질문 수 상한과 지연 예산, 다경로 합병 시 중복 제거 알고리즘, 이 문서와 RAG12 Top K 결정·RAG16 분산 증거 조립의 결합 — 셋 모두 "여러 조각을 어떻게 온전히 모을 것인가"를 다루지만 이 문서는 서로 다른 비교 대상 사이의 자리 경쟁을 다룬다는 점에서 구별된다.