1. 面试场景还原为什么“一句话”就送走了自己“面试官Agent意图识别怎么做”这个问题在最近一两年的AI应用开发、大模型工程化面试中出现的频率越来越高。它不再是一个遥远的学术概念而是直接关系到产品能否落地、用户体验是否流畅的核心技术点。我见过太多候选人包括一些经验不错的工程师在这个问题上栽了跟头。最常见的“送走”式回答往往长这样“哦意图识别啊就是让大模型比如GPT去理解用户说的话是什么意思然后分类或者提取关键信息。”或者更“技术”一点的 “我们一般用Prompt Engineering设计一个系统提示词System Prompt让模型去判断用户的意图。”如果你也这么回答那么恭喜你你已经成功进入了面试官的“待定区”甚至可能直接被Pass。为什么因为这种回答暴露了几个致命问题对Agent系统的复杂性认知不足、对生产级意图识别的工程挑战缺乏理解、以及将“提示词工程”等同于“解决方案”的肤浅认知。面试官抛出这个问题他期待的绝不是一个名词解释或者一个笼统的方案。他真正想考察的是你是否理解意图识别在Agent系统中的核心地位与挑战它不是锦上添花而是Agent的“大脑前额叶”决定了后续所有行动的合理性和效率。你是否具备将学术/理论概念转化为可落地、可维护、可评估的工程方案的能力这涉及到数据、模型、流程、评估的全链路思考。你是否踩过坑是否有超越标准文档的实战经验比如如何处理模糊意图、如何降低大模型API的调用成本和延迟、如何设计兜底策略。所以当你说出“用大模型理解”或“写Prompt”时面试官听到的潜台词是“我对这个问题的认知还停留在Demo阶段没有真正负责过一个需要稳定运行的Agent系统。” 接下来他可能会用一系列追问让你陷入困境“如果用户同时表达了多个意图怎么办”“你的意图分类如何应对新出现的、训练数据里没有的意图”“当大模型偶尔‘胡言乱语’返回一个完全错误的意图时你的系统如何容错”这篇文章我们就来彻底拆解“Agent意图识别”这个面试必问题。我会以一个经历过多次迭代的实战者视角分享从架构设计、技术选型到避坑指南的完整思路。这不是一篇教科书而是一份能让你在面试中脱颖而出的“作战地图”。2. 意图识别Agent的“决策开关”与系统工程本质在深入技术细节前我们必须建立正确的认知框架意图识别Intent Recognition在Agent系统中本质上是一个“决策开关”或“路由分发器”。它的输入是用户的自然语言指令可能伴随上下文、历史记录输出是一个结构化的、可执行的“行动指令”或“技能调用”。2.1 从“理解”到“决策”的范式转变很多人的误区在于把意图识别等同于“语义理解”或“文本分类”。这是NLP时代的遗留思维。在大模型时代尤其是Agent场景下意图识别的目标发生了根本性转变传统NLP意图识别目标是准确地将用户query分类到预设的、有限的几个类别中如“查天气”、“订机票”、“放音乐”。它更关心分类的准确率、召回率。Agent意图识别目标是确定当前应该激活哪个技能Skill、工具Tool或工作流Workflow并为其准备好正确的调用参数。它更关心决策的合理性、可执行性以及效率。举个例子用户说“帮我总结一下上周销售会议纪要的要点然后发邮件给项目组。”传统视角这可能被分类为“文档处理”或“邮件发送”。Agent视角这需要识别出两个顺序执行的意图1)skill: summarize_document参数为file: “上周销售会议纪要”2)skill: send_email参数为content: [上一步的输出],recipients: “项目组”。更重要的是它需要判断这两个意图是有关联的、需要顺序执行的。所以Agent意图识别是一个决策生成问题而不仅仅是分类问题。2.2 意图识别系统的核心工程挑战认识到它是决策系统后我们就能理解其面临的工程挑战远比一个分类模型复杂意图的开放性与动态性你无法预知用户所有可能的请求。如何设计系统使其既能处理已知意图又能一定程度上处理未知或模糊意图意图的层次性与组合性如上例意图可能是多层次的总结-发送也可能是并行的“查一下北京和上海的天气”。上下文依赖用户的意图严重依赖对话历史。比如用户先说“打开空调”然后说“调到24度”第二个“调温”意图的识别依赖于对第一个“打开”意图的上下文记忆。成本与延迟的权衡每次都调用大模型如GPT-4来做意图识别精度可能最高但成本和延迟无法承受。如何设计混合策略评估的困难性如何评估一个意图识别系统的好坏准确率但很多场景下没有唯一标准答案需要人工评估合理性这非常耗时。安全与兜底当模型无法识别或识别出危险意图如“删除所有文件”时系统必须有明确的降级和拦截机制。面对这些挑战一个成熟的意图识别系统绝不会是“一句话”能概括的。它必然是一个分层、混合、可观测的工程系统。3. 分层混合架构从规则到LLM的实战设计直接上结论单一技术方案无法解决所有问题。一个鲁棒的、生产级的Agent意图识别系统通常采用“分层过滤混合决策”的架构。下面我以一个典型的电商客服Agent为例拆解这套架构。假设我们的Agent拥有以下技能查询订单、退货申请、商品推荐、转人工客服。3.1 第一层快速规则与关键词匹配低成本过滤这一层的目标是用极低的成本和延迟拦截和处理那些明确、高频的意图。不要看不起规则它在生产环境中至关重要。实现方式正则表达式针对非常固定的模式。例如用户输入“订单号123456”可以用正则订单号\s*(\d)直接提取意图查询订单和参数order_id: 123456。关键词/短语匹配建立意图关键词库。例如“退货”、“退款”、“不想要了”映射到退货申请“有什么推荐”、“类似商品”映射到商品推荐。简单模板匹配对于稍复杂的固定句式如“我要查一下我的订单”可以设计模板。工程实践要点维护一个可配置的规则库最好用YAML或JSON文件管理方便运营人员非代码修改。例如intents: - name: query_order patterns: - regex: 订单号\s*(\d) params: [order_id] - keywords: [查订单, 订单状态, 我的订单] action: direct # 直接触发可能需要进一步询问订单号 - name: return_request keywords: [退货, 退款, 退钱, 不想要, 拒收]设置匹配优先级和冲突解决一个query可能匹配多条规则需要定义优先级如正则优先于关键词。这一层的召回率可能不高但精确率接近100%且响应在毫秒级。它能有效分担后续复杂层的压力。3.2 第二层轻量级机器学习模型处理模糊与泛化对于规则层无法捕获的、更模糊或更泛化的表达引入一个轻量级的意图分类模型。这里不推荐直接用巨型LLM。模型选型Fine-tuned BERT/类似轻量模型这是最主流的选择。从业务对话日志中标注数据微调一个像bert-base-chinese这样的模型。它的优点是比规则泛化能力强能理解“我买的东西到哪了”和“查订单”是同一个意图。比大模型GPT成本低几个数量级速度快10-100ms内可以部署在自有GPU甚至CPU上。确定性好不会出现大模型那样的“幻觉”或随机性。Embedding 聚类/分类如果标注数据少可以用Sentence-BERT等模型将用户query转化为向量然后与已知意图的标准query向量计算相似度取最相似的意图。这种方法实现简单但对语义的精细区分能力不如微调模型。实操中的关键点数据收集与标注这是最大的坑。初期可以从客服日志、搜索日志中挖掘高频query进行人工标注。要特别注意标注“负样本”即不属于任何已知意图的query用于训练模型的“拒识”能力。意图粒度设计意图不是越细越好。例如是设计一个查询订单意图还是拆成查询订单状态、查询订单物流这需要平衡业务复杂度和模型能力。通常建议从粗粒度开始必要时在技能内部再细分。模型更新与监控线上模型需要定期用新数据重新训练和更新。要监控模型的预测分布如果“其他/未知”类别的比例持续升高说明出现了新的用户需求需要review是否定义新意图。3.3 第三层大语言模型作为“裁决者”与“生成器”处理复杂与开放当前两层都无法给出高置信度的结果时或者query本身非常复杂、开放、需要深度推理时才请出“王牌”——大语言模型LLM。LLM在这一层的核心作用有两个复杂意图裁决与拆解当用户query很长、包含多个子任务或条件时LLM可以将其拆解为结构化的意图序列。例如“帮我对比一下iPhone 15和华为Mate 60的优缺点然后告诉我哪个更适合玩游戏最后总结成一份简短的报告。” LLM需要输出一个计划[技能商品对比 参数: {products: [“iPhone 15”, “华为Mate 60”]}], [技能信息分析 参数: {aspect: “游戏性能”}], [技能文档生成 参数: {format: “简短报告”}]。开放域意图理解与参数生成对于全新的、未预定义的请求LLM可以尝试理解其本质并映射到最接近的现有技能或生成一个“特殊处理”的标记。例如“我心情不好给我讲个笑话吧。” 规则和分类模型可能都无法处理但LLM可以识别出这是请求娱乐内容的意图并触发相应的内容生成技能。关键设计Prompt Engineering 不是儿戏很多人觉得调用LLM就是写个Prompt这是大错特错。生产级的Prompt设计是一门工程。# 一个糟糕的Prompt示例 prompt “请判断用户的意图是什么{user_input}” # 一个相对专业的Prompt示例 system_prompt 你是一个智能助理的意图分析模块。你的任务是将用户的自然语言请求转化为可执行的技能调用指令。 你可以调用的技能列表如下 - query_order(order_id): 查询订单状态。需要参数订单号。 - apply_return(order_id, reason): 申请退货。需要参数订单号、退货原因。 - recommend_product(category, budget): 商品推荐。需要参数商品类别、预算范围。 - transfer_to_human(reason): 转接人工客服。需要参数转接原因。 请严格按照以下JSON格式输出且只输出JSON { confidence: 一个0到1之间的浮点数表示你对这个判断的置信度, primary_intent: { skill_name: 技能名称必须来自上述列表, parameters: {键值对参数参数名必须与技能定义一致} }, alternative_intents: [其他可能的意图数组可选], need_clarification: 布尔值true表示需要向用户追问更多信息, clarification_question: 如果需要追问这里写追问的问题 } 如果用户的请求无法匹配任何技能或者你非常不确定confidence 0.6请将skill_name设为unknownparameters设为空。 user_input “我上周买的鞋子尺寸不对想换货”这个Prompt好在哪里角色与上下文清晰明确了LLM的职责边界。输出格式严格结构化强制JSON输出便于后端程序化解析避免了模型自由发挥带来的解析困难。包含了置信度这是关键它让后续流程可以基于置信度做决策例如低于0.7的进入人工审核或直接转人工。考虑了追问场景当参数不足时能主动生成追问问题实现多轮交互。有兜底处理明确了“unknown”情况的处理方式。3.4 架构协同与流量调度三层架构如何协同工作需要一个调度器Orchestrator来管理流程。用户请求进入。调度器先调用规则引擎。如果匹配到高置信度规则直接返回意图结果流程结束。若不匹配或规则置信度低调度器调用本地微调的分类模型。如果分类模型返回的置信度高于阈值A如0.9采用其结果。如果分类模型置信度介于阈值A和阈值B之间如0.6-0.9调度器可能会将规则结果、分类结果以及原始query一起交给LLM做最终裁决Few-shot示例。如果分类模型置信度低于阈值B或者LLM裁决为“unknown”则进入兜底流程可以请求用户澄清、转人工客服、或者执行一个通用的“搜索”技能。这套混合架构在成本、速度和准确性之间取得了最佳平衡。据统计80%以上的高频、明确请求会在第一、二层被处理只有不到20%的复杂、长尾请求需要动用昂贵的LLM。4. 超越基础高级议题与避坑指南如果你在面试中能讲清楚上面的三层架构已经可以拿到一个不错的分数。但如果想给面试官留下“专家”印象还需要探讨以下更深层的问题。4.1 意图的持续学习与冷启动问题问题业务在变化新的商品、新的活动会带来新的用户表达方式。如何让意图识别系统自适应进化实战方案主动学习Active Learning回路将所有LLM层处理过的、低置信度的query以及用户最终通过其他路径如转人工解决的query自动收集到一个待审核池。定期如每天由运营人员或通过少量标注进行确认将其转化为新的训练数据迭代更新第二层的分类模型。Embedding聚类发现新意图定期对所有未识别unknown的query进行Embedding和聚类分析。如果某个聚类频繁出现且内部语义一致它很可能代表了一个新的、未定义的意图可以提示产品经理进行评估和添加。冷启动策略在新业务上线、完全没有标注数据时可以完全依赖规则和LLM层。利用LLM批量生成大量符合业务场景的模拟用户query作为初始训练数据来微调小模型。虽然质量不如真实数据但能快速搭建一个基线系统。4.2 多轮对话中的意图继承与切换问题在对话中用户的意图不是孤立的。如何让Agent记住上下文并做出连贯的决策解决方案这需要对话状态管理Dialog State Tracking, DST模块与意图识别模块紧密配合。维护一个对话状态对象其中包含当前对话的主题、已识别的意图栈、已填充的参数槽位、用户的历史发言等。意图识别模块的输入不仅是当前query而是“当前query 对话状态”。例如当对话状态显示正在执行“退货申请”且参数“订单号”仍为空时用户说“订单号是123456”意图识别模块应能将其识别为“填充参数”而非一个新的“查询订单”意图。LLM在此处有天然优势可以通过在Prompt中注入完整的对话历史让其自行理解上下文。但对于规则和小模型层需要精心设计状态感知的逻辑。4.3 评估体系如何衡量意图识别的好坏避坑提示千万不要只说“看准确率”。在生产系统中评估是多元的。离线评估标准测试集维护一个带有标注的测试集定期跑分类模型的准确率、召回率、F1分数。LLM调用评估对于LLM层评估其输出JSON的格式合规率、参数提取的准确率。可以用LLM本身作为裁判评估其意图拆解的合理性但需注意成本。在线评估A/B测试核心业务指标意图识别模块的优化最终要服务于业务目标。例如在客服Agent中可以对比A/B实验组下的“问题解决率”、“对话轮次”、“用户满意度评分”是否有提升。漏斗分析分析用户请求从进入到被各层处理最终成功触达技能的全流程转化率。寻找流失严重的环节。人工评估定期抽样一批对话日志由专业人员评估意图识别的结果是否合理。这是黄金标准但成本高。4.4 常见陷阱与实战心得陷阱一过度依赖LLM。初期为了快速验证所有请求都走LLM。一旦流量增长成本会失控延迟也无法接受。一定要尽早引入分层架构。陷阱二意图设计过细或过粗。过细会导致模型难以学习、技能间耦合混乱过粗会导致技能内部逻辑复杂用户体验差。建议从核心用户旅程出发定义MVP阶段的意图然后根据数据迭代。陷阱三忽略“拒识”能力。一个总是试图把用户请求归到某个已知意图的系统是危险的。必须设计明确的“unknown”处理流程比如优雅地回复“我还在学习这个功能您可以换种方式问问吗”或者直接转人工。陷阱四Prompt不稳定。LLM对Prompt的措辞敏感微小的改动可能导致输出格式或逻辑巨变。必须将Prompt版本化并进行严格的回归测试确保任何更改都经过评估。心得一日志日志日志记录每一个用户请求、每一层的处理结果、置信度、最终执行的技能。这是你分析和优化系统唯一、也是最宝贵的资料。心得二建立“意图运营”机制。意图识别不是一劳永逸的工程任务而是一个需要持续运营的产品功能。需要产品、运营、研发共同参与定期review未知请求、分析bad case、更新意图库和模型。回到最初的面试问题。现在当面试官再问“Agent意图识别怎么做”时你的回答应该是一个有层次、有深度、有实战感的论述从它在Agent中的核心决策定位谈起讲到面对成本、精度、开放性挑战时必然采用的分层混合架构规则/ML/LLM深入每一层的技术选型和工程化细节数据、模型、Prompt最后扩展到持续学习、状态管理和评估体系这些高级议题并辅以你踩过的坑和总结的心得。这样的回答展现的不仅是对一个技术点的了解更是一套解决复杂工程问题的系统化思维和能力。这才是面试官真正想听到的。
疾病分类数据集)
