3 为什么复杂问题常常不适合只走一条召回链路
1️⃣ 考察意图
面试官想考察你对检索系统在复杂场景下失效本质的理解，而非简单背诵“多路召回”概念。刁钻点在于：你是否能区分“复杂问题”的具体类型（多跳推理、条件约束、时序依赖等），并针对每种类型解释单条链路（如纯向量检索）为何丢失信息。答好了能展示系统设计中的trade-off意识（如召回率vs延迟）、对检索策略适用边界的认知，以及实际落地时如何平衡效果与工程成本。
2️⃣ 标准答
核心论点：复杂问题通常包含多个子意图或跨领域约束，单条召回链路（如单一向量检索）的“语义压缩”过程会丢失关键信息，导致召回碎片化或偏差。
1. 复杂问题的典型特征
- 多跳推理：如“2020年诺贝尔化学奖得主所在大学的校长是谁？”需要先定位获奖者，再查其大学，最后找校长。单条向量检索无法编码这种链式依赖。
- 条件约束：如“推荐北京适合带小孩的、有户外泳池的酒店”。向量检索可能只匹配“北京酒店”或“户外泳池”，但忽略“带小孩”的隐含条件（如安全设施）。
- 时序与因果：如“特斯拉股价下跌后，马斯克发了什么推文？”需要时间顺序和因果关联，单条检索无法区分事件先后。
2. 单条链路的三大局限
- 语义压缩损失：向量检索将整个查询压缩为单一embedding，复杂查询中的多个子意图会互相干扰。例如，查询“如何治疗感冒并预防流感”的embedding可能偏向“治疗”，导致“预防”相关文档被排到后面。
- 检索策略的偏好偏差：BM25对精确关键词敏感，但无法处理同义表达；稠密检索（如DPR）擅长语义匹配，但对罕见实体（如专有名词“CRISPR-Cas9”）召回差。单一策略必然有盲区。
- 缺乏上下文交互：单次检索无法根据已召回结果动态调整策略。例如，第一次检索只找到“感冒治疗”文档，但系统不会意识到需要补充“流感预防”的检索。
3. 实际落地的坑与解法
- 坑：多路召回后直接拼接结果，导致信息冗余或矛盾（如同时返回“感冒需多喝水”和“感冒需吃药”）。
- 解法：引入结果融合策略，如RRF（Reciprocal Rank Fusion）加权排序，或使用LLM作为reranker，对多路结果进行去重和逻辑校验。例如，对“感冒治疗与预防”查询，先让LLM分解子问题，再对每路结果做交叉验证。
4. 替代方案与trade-off
- 查询分解（Query Decomposition）：用LLM将复杂问题拆解为多个简单子问题，每个子问题走不同检索策略（如子问题1用BM25找精确实体，子问题2用稠密检索找语义相似）。代价：增加1-2次LLM调用，延迟增加200-500ms，但召回率提升15-30%（在HotpotQA上验证）。
- 迭代检索（Iterative Retrieval）：先检索一次，用结果生成新查询再检索，类似ReAct模式。代价：需要设计停止条件，否则可能陷入循环或过度检索。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从三个层面回答：第一，复杂问题的本质是多子意图或跨领域约束，单条链路（如向量检索）的语义压缩会丢失关键信息；第二，不同检索策略有偏好偏差，BM25对关键词敏感但忽略语义，稠密检索反之，单一策略必有盲区；第三，实际落地时，我会用查询分解+多路召回+RRF融合，虽然增加延迟，但能提升召回率15-30%。总结一句：复杂问题必须用多策略互补，否则召回碎片化会直接导致下游生成错误。”
4️⃣ 高频追问 & 应对
追问 1：多路召回后结果冲突怎么办？比如一路说“感冒需吃药”，另一路说“感冒需休息”。
这是常见问题。我会用两步解决：第一步，用LLM作为reranker，对多路结果进行语义去重和逻辑校验，例如让LLM判断“吃药”和“休息”是否矛盾（实际上不矛盾，可合并）。第二步，如果结果确实冲突（如“吃药”vs“不吃药”），则根据文档来源权威性（如PubMed vs 博客）加权，或返回置信度最高的结果并附上冲突说明。工程上，可以设置一个冲突检测阈值，当两篇文档的相似度>0.8但结论相反时，触发LLM裁决。
追问 2：查询分解会增加延迟，你怎么权衡？
延迟和召回率是典型trade-off。我会根据业务场景做分级：对高实时场景（如客服对话），用轻量级分解（如基于规则的实体识别+关键词拆分），延迟控制在100ms内；对离线分析或知识库问答，用LLM分解（如GPT-4），延迟可接受500ms。另外，可以用缓存优化：对常见复杂查询（如“如何退换货”），预计算分解结果，避免重复调用。
追问 3：如果用户查询是“2020年诺贝尔化学奖得主所在大学的校长是谁”，多路召回能解决吗？
这种多跳查询，多路召回本身不够，因为子问题之间有依赖关系。我会用图检索：先构建实体关系图（如从Wikipedia提取），然后对查询进行实体链接（如“诺贝尔化学奖”→“Emmanuelle Charpentier”），再沿图路径检索（“Charpentier”→“University of California, Berkeley”→“校长”）。如果图不完整，可以用LLM做链式推理，每一步检索后验证结果，类似ReAct模式。
5️⃣ 避坑 · 常见错误答法
- ❌ “复杂问题就用多路召回，把BM25、稠密检索、稀疏检索都跑一遍，结果合并就行。” → ✅ “多路召回只是手段，关键是理解复杂问题的类型（多跳/条件/时序），然后针对性地设计检索策略。例如，多跳问题需要图检索或链式推理，条件约束问题需要属性过滤+语义检索，不能无脑堆策略。”
- ❌ “单条链路不行是因为embedding不够好，换更好的模型（如text-embedding-3-large）就行。” → ✅ “embedding模型再强，也无法编码多跳依赖或时序关系。这是检索范式本身的局限，不是模型能力问题。例如，即使使用最先进的embedding，也无法区分‘A导致B’和‘B导致A’。”
6️⃣ 简历呼应
- 如果你有RAG项目：从“我在XX项目中遇到用户查询‘如何申请退款并保留会员资格’，单路检索只返回退款流程，后来用查询分解+多路召回，召回率从60%提升到85%”切入，强调实际效果和工程成本。
- 如果你只做过传统NLP：用“传统信息检索中，布尔查询和向量空间模型也有类似问题，比如‘苹果’在水果和公司语境下需要不同索引”类比，展示迁移能力。
- 如果你是校招无项目：聚焦“我在复现HotpotQA论文时，发现单路DPR的F1只有40%，而查询分解+多路召回能到65%”，展示对论文细节的理解和实验能力。
- “Query Decomposition for Multi-Hop QA” (Min et al., 2019)
- “REACT: Synergizing Reasoning and Acting in Language Models” (Yao et al., 2022)
- “RRF: Reciprocal Rank Fusion for Multi-Retrieval” (Cormack et al., 2009)
- “Dense Passage Retrieval for Open-Domain Question Answering” (Karpukhin et al., 2020)
- “ColBERT: Efficient and Effective Passage Search via Contextualized Late Interaction” (Khattab & Zaharia, 2020)