面试题 · Agent
搜索「Prompt工程」匹配到口述回答，相关段落已展开。查看匹配内容 ↓
在构建智能对话系统时，如何防止大模型将用户闲聊意图误判为功能调用意图，从而避免不必要的工具调用？请从模型设计、提示工程、后处理策略等角度阐述解决方案。
本质是意图边界模糊问题，需在"能调"和"该调"之间建立多层过滤。
1. 显式意图分类器
chat/tool_call/三档学习内容与项目面试，在同一条路上。
uncertain2. 双模型架构
3. 联合训练策略
tool_calls为空1. 边界定义清晰化
只有当用户明确请求执行某项任务时，才调用工具。
以下情况不调用：泛泛而谈、情绪表达、假设性讨论、已完成的任务。2. Few-shot示例
3. 强制反思（Chain-of-Verification）
先判断：用户是否在请求我执行操作？是/否
再输出：...| 策略 | 实现方式 |
|---|---|
| 置信度阈值 | 工具选择概率<0.7时降级为闲聊回复 |
| 参数完整性校验 | 必填参数缺失时，先询问而非强行调用 |
| 上下文一致性检查 | 连续3轮闲聊后突现工具调用，触发确认话术"您是想查...吗？" |
| 用户反馈闭环 | 提供"这不是我要的"按钮，实时修正路由策略 |
场景切入
我看你做过智能客服。假设用户说“今天天气真差”,系统却调了天气查询工具,这显然不对。你在实际中怎么避免这种把闲聊当功能调用的误判?
层层追问
你平时怎么区分用户是想闲聊还是要调用功能?……如果提示工程调了还有误判怎么办?……那从模型设计或者后处理上,还有没有其他手段兜底?
直球架构
请从模型设计、提示工程、后处理三个角度,说说如何防止大模型将闲聊意图误判为功能调用,避免不必要的工具触发。
这道题其实问的是，怎么在对话系统里把闲聊和功能调用分清楚，避免模型动不动就瞎调工具。我理解核心就一句话：意图边界模糊，需要在能调工具和该调工具之间，建好几道过滤。
先说模型设计层。一个直接的做法是加一个显式的意图分类器，在触发 [[Function Calling]] 之前先分一下，输出 chat、tool_call 或者 uncertain 三档。这个分类器可以用轻量模型，比如 BERT 级别，或者用 [[LoRA]] 微调一下，负担不大。另一个思路是双模型架构，一个路由模型专门判断该不该走工具分支，另一个执行模型专心做工具调用，这样两个模型各管一摊，闲聊数据不会干扰工具模型。训练的时候，我会在 [[SFT]] 阶段刻意加一些负例，就是那些明显是闲聊的样本，明确标出来 tool_calls 为空。[[RLHF]] 阶段也可以引入惩罚，用户说“我没让你查这个”就是一个很强的负向信号。
再一个就是提示工程。我会在 [[System Prompt]] 里把边界定义写清楚，比如“只有用户明确请求执行任务时才调用工具，泛泛而谈、情绪表达、假设性讨论都不调”。然后加几个 [[Few-shot]] 示例，正例是“查北京明天天气”调天气工具，负例是“今天天气真差”就回一句“是啊，适合宅家”。还可以加一步强制反思，用 [[Chain-of-Verification]] 的思路，让模型先自问“用户是在请求我执行操作吗？”，再决定要不要调工具。
后处理策略这块也很关键。我会设一个置信度阈值，比如工具选择概率低于 0.7 就降级成闲聊回复。再一个是参数完整性校验，如果必填参数缺失，先问清楚而不是强行调用。上下文一致性检查也很有用，比如用户连续聊了三轮闲话，突然蹦出一个工具调用，那就触发一个确认话术“您是想查……吗？”。用户反馈闭环也得有，提供一个“这不是我要的”按钮，实时修正路由策略。
这里有个重要的取舍：宁可漏调，不可错调。闲聊误调工具的伤害，远大于功能没识别出来，没识别可以追问澄清，误调会让用户觉得系统很蠢。所以我会把后处理做得保守一些，高模糊场景用“您是指……吗？”过渡，不直接执行。
还有一个点值得注意，就是多轮对话里的意图漂移。用户可能前几轮在闲聊，突然切到功能请求，这时候模型容易受上下文干扰。我倾向于引入一个轻量的状态机，维护一个“当前意图状态”，结合[[滑动窗口]]判断意图是否发生了切换，而不是单纯依赖单轮分类。
所以说，我会把整件事看成一条流水线，从模型到提示到后处理，每层都做一点过滤，最终目标是让工具调用既准又稳。