今天北京天气如何？「 → should_search: true ✓

1️⃣ 考察意图

面试官想看的不是你会不会调一个分类器，而是你对 Agent 工具调用决策 的工程化理解。这道题表面是“判断是否搜索”，实则在考察：意图识别与工具调用的边界设计、规则与模型的取舍、以及 延迟与准确率的平衡。刁钻点在于：看似简单的“天气查询”背后，藏着“模糊查询（如‘北京’）”“多轮上下文（如‘那明天呢’）”“时效性判断（如‘今天’ vs ‘历史’）”等边界。答好了，能展示你从数据标注到线上部署的整条链路工程思维，而非纸上谈兵。

2️⃣ 标准答

核心逻辑：should_search 是 Agent 的“门卫”，决定是否调用搜索工具。设计时需分三层：触发条件、决策模型、边界兜底。

1. 触发条件设计：规则优先，模型兜底

规则层：用关键词 + NER 快速命中。例如：
关键词：天气、新闻、股价、今天、明天 → 直接 true
NER：识别出 [地点: 北京] + [时间: 今天] → 触发搜索
为什么这么做：规则延迟低（<1ms），覆盖 80% 高频场景，避免模型调用浪费算力。
模型层：对规则未命中的 query，用轻量分类器（如 BERT-tiny 或 DistilBERT）做二分类。训练数据需包含：
正例：“北京限行吗？”（需实时数据）
负例：“北京是首都”（静态知识，无需搜索）
坑：负例容易过拟合。解法：加入 hard negative mining，比如 “北京天气如何” 是正例，但 “北京的气候类型” 是负例（气候是静态知识）。

2. 决策模型的工程取舍

模型选择：用 BERT-tiny（4层）而非 BERT-base（12层），因为：
延迟：BERT-tiny 推理约 5ms，BERT-base 约 20ms，在 Agent 的决策链路中，每多 10ms 都会影响用户体验。
准确率：在 should_search 任务上，BERT-tiny 可达 94%，BERT-base 约 96%，差距可接受。
Trade-off：准确率 vs 延迟。如果业务要求 99% 准确率（如金融场景），必须上 BERT-base + 规则兜底；如果追求低延迟（如对话式搜索），用规则 + 轻量模型即可。

3. 实际落地的坑与解法

坑 1：模糊查询。用户说 “北京” 而非 “北京天气”。解法：在规则层加入上下文补全，比如最近 3 轮对话中出现了 “天气”，则 “北京” 自动触发搜索。
坑 2：时效性误判。“北京的历史天气” 不应触发搜索（因为历史数据是静态的）。解法：在 NER 中加入 [时间: 历史/去年] 标签，规则层直接返回 false。
坑 3：多轮上下文。用户先问 “今天北京天气”，再问 “那明天呢”。解法：维护一个 search_context 缓存，记录上一轮搜索的实体（地点、时间），当前 query 若依赖上下文，则自动继承并触发搜索。

4. 评估与迭代

离线指标：准确率、召回率、F1。但更关键的是 误报率（不该搜却搜了）和 漏报率（该搜却没搜）。误报浪费 API 成本，漏报导致 Agent 回答错误。
线上指标：搜索工具调用率、用户满意度（通过隐式反馈，如是否继续追问）。如果调用率过高（>30%），说明模型太激进，需调高阈值或增加负例。

总结：should_search 不是简单的分类问题，而是 规则 + 模型 + 上下文 + 兜底 的系统设计。核心是：用规则覆盖高频、用模型处理模糊、用缓存解决多轮。

3️⃣ 答题模板（30 秒电梯版）

“这个问题我从三个层面回答：第一，触发条件设计，用规则（关键词 + NER）覆盖 80% 高频场景，模型（BERT-tiny）兜底模糊查询；第二，工程取舍，用轻量模型保延迟，用 hard negative mining 提准确率；第三，边界兜底，比如模糊查询靠上下文补全，多轮对话靠缓存继承。总结一句：should_search 是 Agent 的门卫，核心是规则与模型的平衡，以及边界情况的系统化处理。”

4️⃣ 高频追问 & 应对

追问 1：如果用户说“北京天气如何”，但系统误判为 false，怎么排查？

首先，检查规则层是否命中：关键词“天气”是否在词表？NER 是否识别了“北京”？如果规则未命中，看模型层输出概率。如果概率接近阈值（如 0.5），说明模型置信度低，需调整阈值或增加训练数据。其次，检查上下文缓存：如果前一轮有搜索，当前 query 是否被错误继承？最后，加日志：记录规则命中、模型输出、上下文状态，方便复现。常见解法：在规则层加入“天气”的变体（如“天儿”“气象”），并降低模型阈值到 0.3 以提升召回。

追问 2：如何设计 should_search 的训练数据？正负例比例多少？

正负例比例建议 1:3 到 1:5，因为线上负例远多于正例。正例来源：用户真实搜索日志（如“天气”“新闻”）；负例来源：静态知识 query（如“北京是首都”）、闲聊（如“你好”）。关键技巧：加入 hard negative，比如“北京的气候类型”是负例，但“北京今天气候”是正例（因为“今天”暗示时效性）。数据增强：用 LLM 生成相似 query，比如“上海明天会下雨吗”作为正例。线上持续收集误报和漏报，每周更新训练集。

追问 3：如果用户说“帮我查一下”，没有具体实体，怎么处理？

这是典型的“意图明确但实体缺失”场景。解法：规则层识别“查一下”为搜索意图，但实体为空，此时触发追问，而不是直接搜索。例如，Agent 回复“您想查什么？请提供具体信息”。如果用户在多轮中已提供实体（如之前说过“北京”），则从上下文缓存中继承。工程上，在 should_search 后加一个 entity_check 模块，如果实体缺失，返回 should_search: true, need_entity: true，引导用户补充。

5️⃣ 避坑 · 常见错误答法

❌ 说“用 GPT-4 直接判断是否搜索，准确率很高” → ✅ 正确切入：GPT-4 延迟高（秒级）、成本高（每 query 几美分），不适合线上实时决策。应该用规则 + 轻量模型，GPT-4 只做兜底或离线标注。
❌ 说“should_search 就是二分类，用 BERT 微调就行” → ✅ 正确切入：忽略了规则层的必要性和边界情况（如模糊查询、多轮上下文）。系统设计必须考虑延迟、成本、可解释性，不能只堆模型。
❌ 说“所有 query 都触发搜索，反正有 reranker 兜底” → ✅ 正确切入：这会浪费 API 成本（搜索工具调用费钱），且增加延迟。should_search 的目的是前置过滤，减少不必要的工具调用。

6️⃣ 简历呼应

如果你有 RAG 项目：从“检索触发条件”切入，对比 RAG 中“是否检索”的决策逻辑，强调 should_search 是 RAG 的“前置门卫”，并分享你如何用规则 + 模型减少无效检索。
如果你只做过传统 NLP：用“意图识别”类比，比如把 should_search 看作“查询分类”任务，强调你如何用 NER + 关键词匹配实现 95% 准确率，并处理模糊查询。
如果你是校招无项目：聚焦“BERT-tiny 微调”的 demo，展示你从数据标注（正负例 1:3）到模型部署（ONNX 推理 5ms）的全流程，并提到 hard negative mining 的优化。
《RAG vs Fine-tuning: Pipelines, Tradeoffs, and a Case Study on Agriculture》（Google 2024）
《Toolformer: Language Models Can Teach Themselves to Use Tools》（Meta 2023）
《BERT-tiny: Efficient Language Understanding for Edge Devices》（Hugging Face 2020）
《Hard Negative Mining for Intent Detection》（ACL 2021）
《Agent 工具调用决策：从规则到模型的系统设计》（知乎专栏，作者：某大厂 Agent 团队）

—— 本场面试完 ——