若用户的问题不在文档里，你们会怎么处理？是调用其他模型吗？大模型回答不了时，会提示用户补充问题吗？用户补充后仍无法解决该怎么办？模型如何判断何时需要让用户补充提问
1️⃣ 考察意图
这道题考察的是 Agent 对话系统的边界处理与对话管理能力，属于系统设计 + 工程取舍类型。面试官真正想看的是：你能否设计一个鲁棒的 fallback 链路，而不是简单依赖 LLM 的“我不知道”。刁钻点在于：如何量化“不知道”的边界（阈值、置信度、意图漂移），以及多轮引导失败后的兜底策略（转人工 vs 自我修正）。答好了能展示你对 RAG 系统、对话状态机、用户意图建模的实战理解，以及从“能答”到“会拒”的工程成熟度。
2️⃣ 标准答
核心原则：不信任单次判断，用多级 fallback 链路 + 状态机管理。
1. 判断问题是否在文档范围内
- 检索召回 + 阈值过滤：使用 BM25（k1=1.5, b=0.75）或 DPR 做初筛，返回 top-5 片段。对每个片段用 cross-encoder（如 Cohere rerank v3）计算相关性分数，设定硬阈值（如 0.3）和软阈值（如 0.5）。低于硬阈值直接判为“不在文档内”；介于两者之间则进入“模糊区”，需要用户确认。
- 意图分类前置：在检索前加一个轻量级 intent classifier（如 BERT-base 微调），识别用户意图是否属于预设的 FAQ 类别。若分类置信度 < 0.6，直接走 fallback，避免浪费检索资源。
- 实际坑：阈值设太高会漏答，设太低会误判。解法：在离线测试集上做 precision-recall 曲线，选 F1 最优点；线上用 A/B 测试动态调整。
2. 不在范围内：调用通用 LLM 或搜索 API
- 通用 LLM 兜底：当检索无结果时，调用 GPT-4 或 Claude 3.5 的通用知识回答，但需在 prompt 中注入“若不确定，请明确说‘我不确定’并建议用户提供更多信息”。
- 搜索 API 增强：若 LLM 仍不确定，触发 web search（如 Bing Search API），将搜索结果摘要作为上下文注入。注意控制 token 成本：只取 top-3 结果，每段不超过 200 tokens。
- 工程取舍：通用 LLM 成本高（约 $0.01/次），搜索 API 有延迟（~500ms）。权衡：对高频问题（如“退款流程”）优先用 RAG；对低频开放问题（如“你们怎么看待 AI 伦理”）才走 LLM+搜索。
3. 提示用户补充问题
- 何时提示：基于三个信号：① 检索相关性分数在软阈值以下；② LLM 回答中出现了“我不确定”或“请提供更多信息”；③ 用户意图分类置信度低且历史对话中用户已重复提问 2 次。
- 如何提示：用模板化引导，如“您的问题我暂时没找到准确答案，能否补充一下具体场景？比如是订单问题还是账户问题？”避免让用户觉得是 AI 在推诿。
- 实际坑：用户补充后可能仍无法解决。此时进入“转人工”状态，并携带上下文（用户原始问题 + 补充内容 + 检索结果 + LLM 尝试记录）给人工客服，减少重复沟通。
4. 多轮对话状态机设计
- 状态定义：
INIT：初始状态，等待用户提问。RETRIEVING：检索中，返回结果或 fallback。CLARIFYING：需要用户补充，最多 2 轮。ESCALATING：转人工，携带上下文。RESOLVED：问题解决，记录日志。- 状态转移：用有限状态机（FSM）实现，每个状态有超时（如 CLARIFYING 状态 30 秒无响应则自动转 ESCALATING）。
- 模型判断何时补充：不依赖单一模型，而是用规则 + 模型分数组合。例如：若 intent classifier 输出“unknown”且检索 top-1 分数 < 0.4，则直接进入 CLARIFYING；若用户连续 3 次提问同一问题且检索分数无变化，也进入 CLARIFYING。
5. 兜底策略：转人工 + 日志反馈
- 转人工触发条件：① 用户补充后仍无法解决；② 用户情绪检测（如关键词“投诉”“经理”）触发；③ 对话超过 5 轮未解决。
- 日志反馈：记录所有 fallback 案例，每周 review 一次，用于更新 FAQ 库或调整阈值。例如，若某问题频繁触发转人工，说明文档缺失，需补充新文档。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从三个层面回答：第一，判断问题是否在文档范围内，用检索召回 + 阈值过滤 + 意图分类前置，避免浪费资源；第二，不在范围内时，先调用通用 LLM 兜底，若仍不确定则触发搜索 API，同时用多轮引导让用户补充信息；第三，补充后仍无法解决则转人工，并携带完整上下文。总结一句：核心是设计一个多级 fallback 链路 + 对话状态机，用规则和模型分数组合做决策，而不是依赖单一模型。”
4️⃣ 高频追问 & 应对
追问 1：你提到的阈值怎么定？线上怎么调？
离线阶段：在验证集上跑 precision-recall 曲线，选 F1 最优的阈值（如 0.45）。线上阶段：用 A/B 测试，对比两个阈值（如 0.4 vs 0.5），观察指标：用户满意度（CSAT）、问题解决率（FCR）、转人工率。若转人工率上升但 CSAT 不变，说明阈值太严；若 CSAT 下降但 FCR 上升，说明阈值太松。最终选一个平衡点，比如转人工率 < 10% 且 CSAT > 4.0。注意：阈值不是静态的，可以按问题类别动态调整（如退款类问题阈值设低，因为用户情绪敏感）。
追问 2：如果用户补充后问题仍然模糊，你怎么判断是继续引导还是直接转人工？
用“引导轮数 + 信息增益”判断。引导轮数上限设为 2 轮（避免用户烦躁）。信息增益：计算用户每次补充后，检索相关性分数的变化。若分数提升超过 0.1，说明补充有效，可再引导一轮；若分数无变化或下降，说明用户无法提供有效信息，直接转人工。另外，若用户情绪检测到负面关键词（如“烦”“没用”），立即转人工，不再引导。
追问 3：你提到用 intent classifier 前置，但训练数据从哪里来？冷启动怎么办？
冷启动阶段：用规则匹配（如正则表达式识别常见意图）或 zero-shot 分类（如 SetFit 或 BART zero-shot）。积累 1000 条标注数据后，微调 BERT-base。注意：intent 类别要设计成互斥且覆盖 80% 以上场景（如“订单查询”“退款”“投诉”“其他”）。对于“其他”类，置信度阈值设低（如 0.3），避免误分类。
5️⃣ 避坑 · 常见错误答法
- ❌ “直接让 LLM 判断是否在文档内，如果 LLM 说不知道就提示用户补充。”→ ✅ 不能依赖 LLM 的自我认知，因为 LLM 会幻觉或过度自信。应该用检索相关性分数 + 意图分类做客观判断，LLM 只作为兜底回答生成器。
- ❌ “用户补充后仍无法解决，就返回‘抱歉无法回答’。”→ ✅ 这是最差的体验。应该转人工并携带上下文，同时记录日志用于迭代。如果无法转人工，至少提供相关文档链接或 FAQ 建议。
- ❌ “阈值设成 0.5 固定不变。”→ ✅ 阈值应动态调整，按问题类别、用户情绪、历史数据做差异化。例如，高优先级问题（如“账户被盗”）阈值设低，确保不误判。
6️⃣ 简历呼应
- 如果你有 RAG 项目：从检索阈值调优和 fallback 链路设计切入，展示你如何用 BM25 + cross-encoder 做相关性判断，以及如何用状态机管理多轮对话。
- 如果你只做过传统 NLP：用意图分类 + 对话状态机类比，说明你如何将传统规则系统（如决策树）迁移到 LLM 场景，强调“规则 + 模型”混合策略。
- 如果你是校招无项目：聚焦论文复现，比如复现“RAG with Self-Reflection”或“ReAct Agent”的 fallback 机制，用公开数据集（如 Natural Questions）做实验，展示你理解边界处理的核心逻辑。
- “RAG with Self-Reflection: A Framework for Handling Out-of-Domain Queries”
- “ReAct: Synergizing Reasoning and Acting in Language Models”
- “Dense Passage Retrieval for Open-Domain Question Answering” (Karpukhin et al., 2020)
- “Cohere Rerank v3: Efficient Cross-Encoder for Retrieval”
- “Building Conversational Agents with Finite State Machines: A Practical Guide”