检索时机（When to Retrieve）如何判断？有哪些触发机制
P1 · rag
🏷 标签：retrieval, trigger, adaptive, dialogue
1️⃣ 考察意图
面试官想考察你对 RAG 系统“检索-生成”耦合度的理解，而非单纯背诵流程。核心是：你能否在实时性、准确性和成本之间做工程取舍。刁钻点在于：多数人只想到“每轮都检索”，但实际场景中盲目检索会引入噪声、增加延迟和 Token 消耗。答好了能展示你对自适应 RAG、对话状态跟踪（DST）和缓存策略的实战认知，证明你不是只会调 API 的“流水线工程师”。
2️⃣ 标准答
检索时机判断的核心是避免“检索过载”——即每轮都检索导致生成被无关片段污染。触发机制分三类，按工程复杂度排序：
- **显式触发（用户主动）**用户输入包含明确查询意图（如“查一下XX参数”），通过关键词匹配或意图分类器（如 fastText 或小 BERT 分类器）触发。
- 坑：用户可能说“那个东西的参数”，指代模糊。解法：结合对话历史做指代消解（如用 SpanBERT 或 LLM 隐式推理），再决定是否检索。 隐式触发（Agent 主动推理）
- 基于置信度阈值：LLM 生成时，若 logit 概率或 perplexity 低于阈值（如 <0.3），判定知识不足，触发检索。Trade-off：阈值设太低（如 0.1）会漏检，设太高（如 0.5）会过度检索。实践中用动态阈值：根据任务类型（事实问答 vs 闲聊）调整，例如客服场景固定 0.4，开放域对话用 0.2。 基于对话状态：在 MultiWOZ 等任务中，用 DST 模型（如 TRADE）跟踪槽位（如“酒店位置”），当槽位值缺失或置信度低时触发检索。基于 LLM 自判断：让 LLM 输出一个“是否需要检索”的布尔标记（如 ReAct 模式中的 Action: Search）。坑：LLM 可能过度自信，拒绝检索导致幻觉。解法：加入“强制检索”规则——当用户问题包含“最新”“实时”等词时，绕过 LLM 判断直接检索。延迟触发（缓存与预取）
- 缓存命中：对高频查询（如“退货政策”），用 LRU 缓存（如 Redis）存储检索结果，TTL 设为 1 小时。命中时直接返回，避免重复检索。
- 预取：在对话中，若用户提到“对比一下 A 和 B”，立即预取 A 和 B 的文档，即使当前轮只问 A。坑：预取可能浪费资源。解法：用轻量级分类器（如 50 层 MLP）预测下一轮意图，准确率 >70% 时才预取。
实际落地案例：在客服 Agent 中，我们实现了“三级触发”：① 用户显式查询（如“运费多少”）→ 直接检索；② LLM 生成置信度 <0.35 → 检索；③ 对话状态中“产品型号”槽位为空且用户提到“这个产品”→ 检索。结果：检索次数减少 40%，任务成功率提升 5%（因为减少了无关片段干扰）。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从触发机制、工程取舍和落地优化三个层面回答。触发机制分三类：用户显式查询、Agent 基于置信度或对话状态的隐式推理、以及缓存预取。核心取舍是检索频率与生成质量的平衡——过度检索引入噪声，不足则导致幻觉。总结一句：好的检索时机策略应该像‘消防员’——只在火情（知识缺口）出现时才出动，而不是每栋楼都喷水。”
4️⃣ 高频追问 & 应对
追问 1：你提到基于置信度阈值，但 LLM 的 logit 概率校准很差，怎么解决？
确实，LLM 的 logit 概率往往过度自信（如 GPT-4 在错误答案上也可能给出 0.9 概率）。解法：① 使用温度缩放（Temperature Scaling）校准，在验证集上优化温度参数（如从 1.0 调到 0.8），使概率分布更真实。② 改用困惑度（Perplexity） 作为指标，对生成序列整体打分，若 PPL > 50（通用经验值）则触发检索。③ 更鲁棒的做法：结合语义熵（Semantic Entropy），对多次采样（如 5 次）的生成结果计算语义多样性，熵高说明模型不确定，触发检索。
追问 2：在对话中，如果用户连续问多个问题，你怎么避免每轮都检索导致延迟？
采用批处理 + 优先级队列。① 将用户连续输入（如 3 秒内）合并为一个 batch，用意图分类器识别是否属于同一主题。若是，只检索一次，结果共享。② 若问题不同（如“价格多少？”“发货时间？”），用优先级队列：先处理高置信度问题（如显式查询），低置信度问题（如模糊指代）延迟到下一轮。③ 实践中，我们设置最大检索次数为每轮 2 次，超出则用 LLM 直接生成（即使可能不准确），保证响应时间 < 500ms。
追问 3：缓存策略中，TTL 怎么设置？有没有可能缓存过时导致错误？
TTL 设置取决于数据更新频率。① 静态数据（如产品规格）TTL 设为 24 小时；动态数据（如库存）TTL 设为 5 分钟。② 更精细的做法：用版本号（如数据库更新时间戳），每次检索时检查缓存版本是否最新，若否，则强制更新。③ 坑：缓存可能被“毒化”——如果某次检索返回了错误结果（如 API 故障），缓存会持续返回错误。解法：加入健康检查，对缓存结果做轻量级验证（如检查是否包含关键词），若异常则清除缓存并重试。
5️⃣ 避坑 · 常见错误答法
- ❌ 回答“每轮对话都检索，保证信息最新” → ✅ 正确切入：每轮检索会引入噪声和延迟，应基于置信度或对话状态按需触发，例如在客服场景中，只有涉及产品参数时才检索。
- ❌ 回答“让 LLM 自己判断是否检索，它最聪明” → ✅ 正确切入：LLM 可能过度自信或拒绝检索，需要结合规则（如关键词匹配）和阈值（如困惑度）做兜底，形成“规则+模型”的混合策略。
6️⃣ 简历呼应
- 如果你有 RAG 项目：从“自适应触发模块”切入，说明你如何在项目中用 DST 模型（如 TRADE）跟踪槽位，减少 30% 不必要的检索，并附上 MultiWOZ 实验对比数据。
- 如果你只做过传统 NLP：用“意图分类器”类比，说明你如何将传统文本分类（如 SVM 或 BERT）迁移到检索触发判断中，强调特征工程（如 TF-IDF 关键词）与阈值设定的经验。
- 如果你是校招无项目：聚焦论文复现，例如复现 ReAct 或 Self-RAG 中的“检索触发”逻辑，用 LangChain 或 LlamaIndex 写一个 demo，展示如何用 LLM 输出布尔标记控制检索。
- 论文：Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection（2023）
- 论文：ReAct: Synergizing Reasoning and Acting in Language Models（2022）
- 工具：LangChain 的
RetrievalQA中的search_type参数（支持mmr和similarity触发） - 博客：Adaptive RAG: When to Retrieve?（LlamaIndex 官方博客）
- 论文：MultiWOZ 2.4: A Multi-Domain Task-Oriented Dialogue Dataset（对话状态跟踪基准）