本文深入探讨了订票场景下智能Agent的评测关键涵盖意图识别、多意图拆分、隐含意图、意图拒识、澄清判断、输入鲁棒性、实体识别、实体归一、词槽填充、词槽缺失、词槽冲突和词槽追问12个维度。文章强调评测集需细化到可执行层区分主意图与子意图关注实体识别与归一评估词槽填充与缺失以及处理冲突与追问。评测集的成熟度应从基础意图分类逐步完善最终实现精准识别与高效交互降低任务成本提升用户体验。很多团队做订票 Agent 评测上来就看最后有没有给出车次。真正让系统返工的不是车次推荐不准而是前面没有把用户一句订明天下午去上海的高铁拆成可标注判断。不是 Agent 会下单以后才需要评测而是输入理解、实体词槽先被评测压实订票链路才可能稳定。老王这篇只写这两层。订火车票是一个很适合讲 Agent 意图识别的场景。用户一句话通常很短系统背后却要完成一串判断。用户输入可能是订明天下午三点左右从杭州东到上海虹桥的二等座两个人靠窗优先别太晚到能改签就行。这句话表面是订票。拆开以后它至少包含目标城市、出发站、到达站、时间窗口、席别、人数、偏好、软约束、风险动作和可能的售后要求。如果评测集只标一个订票意图后面出错时根本不知道问题在哪。这篇先收窄只写意图识别分类里最靠前的两层。输入理解标注判断 Agent 有没有听懂用户目标。实体与词槽标注判断 Agent 有没有抽对执行参数。01PART意图识别意图识别评测测的是主任务分类。订票场景里主意图至少不能只写一个订票。同样是火车票相关输入用户可能在做完全不同的事。用户输入明天下午杭州到上海还有票吗 →查票用户输入选 G7315 二等座给张三买一张 →预订用户输入明天那张去上海的票改到晚上 →改签用户输入把后天北京南到济南西那张退了 →退票用户输入查一下订单有没有出票成功 →订单查询用户输入这趟车晚点导致赶不上会议 →异常反馈或客服投诉这些任务如果都塞进订票大类后续动作会完全混乱。查票不需要乘客身份预订需要。改签依赖已有订单退票涉及费用规则投诉则进入客服或补偿流程。意图识别评测的样本对象通常是单轮用户输入。标准标注字段至少包括主意图、子意图、是否有效、业务域、风险动作。判分方式可以用分类准确率和宏平均 F1。样本量不大时老王更建议看混淆矩阵。订票场景最要命的混淆不是查票和推荐混了而是查票和下单混了改签和重新购票混了退票和取消未支付订单混了。查票被误判成下单会让系统提前进入乘客和支付流程。改签被误判成重新购票会造成用户持有两张票。退票被误判成取消未支付订单会漏掉手续费和确认风险。所以意图识别不是越多标签越专业。标签的边界必须对应后续动作差异。老王会把订票意图树拆到可执行层而不是停在业务名词层。一个标签如果不能决定下一步动作它就还不是产品可用标签。02PART多意图拆分多意图拆分评测测的是一句话里有多个任务时Agent 能不能拆全并保留合理顺序。订票用户很少只说一件事。用户输入查一下明天下午杭州到上海的高铁顺便看周日晚上上海回杭州还有没有票去程优先二等座返程能晚点。这句话里至少有两个查询任务。去程查票杭州到上海明天下午高铁二等座优先。返程查票上海到杭州周日晚上时间偏晚。用户输入查明天下午杭州到上海的票有合适的就给张三预订一张二等座。这不是两个并列任务而是有依赖关系。必须先查票再根据候选车次进入预订。没有候选车次就不能进入下单。用户输入把明天去上海那张改到晚上如果没有合适车次就退掉。这里又是条件分支。先查原订单再查可改签车次。若有合适车次走改签。若没有合适车次再进入退票候选流程。退票还必须确认。多意图拆分评测的标注字段包括子意图列表、任务顺序、依赖关系、条件分支、是否需要确认。判分不能只看最终回答看起来有没有覆盖。要拆成三个指标。子任务召回率应该拆出的任务有没有漏。冗余率系统有没有补出用户没有表达的任务。顺序准确率有依赖关系的任务有没有排错。订票场景里多意图漏拆会直接导致用户少买返程、误改订单、漏掉退票确认。过度拆分也有成本。用户只是问明天去上海几点有车系统却拆出查票、订票、支付、出票四个任务就是把查询误推进到交易。老王看多意图拆分会优先看动作边界。查票可以自动预订要确认乘客支付必须确认。拆分不是为了让流程变长而是为了让每个动作的边界清楚。03PART隐含意图隐含意图评测测的是用户没有直接说目标时Agent 能不能从业务语境里补出真实目标。订火车票时用户经常不说查票或订票。用户输入明天下午三点前能到上海虹桥吗。表层看是一个能不能的问题。真实目标通常是查找到达时间早于三点的车次。用户输入别耽误四点的会。这不是闲聊背后是到达时间约束。系统应该把它转成到站时间需要早于会议时间并预留出站和通勤缓冲。用户输入这趟太晚了。如果当前页面已经展示了候选车次这句话的隐含意图是调整筛选条件换更早到达或更早出发的车次。用户输入还有便宜点的吗。在车次候选列表里它通常不是普通价格咨询而是按票价重新排序或者放宽席别和车次类型。隐含意图不能靠模型自由发挥。它必须来自三个来源。当前业务页面比如正在看车次列表、订单确认页、改签页。当前对话状态比如前面已经确定杭州到上海。订票业务规则比如会议时间会影响到达时间窗口。这类评测的标注字段包括表层表达、隐含意图、业务目标、触发依据、是否需要澄清。判分不要只看模型输出像不像。要看隐含目标是否被标注员认可以及后续动作是否落在这个目标上。隐含意图的边界这里最容易犯的错是把所有模糊表达都自动扩展成执行动作。用户说太贵了可能是想换低价车次也可能只是表达不满意。当前如果还在查询列表可以继续筛选。当前如果已经进入支付页系统就不能直接替用户改票。老王更倾向于把隐含意图和澄清判断一起看。隐含意图能补出方向但一旦涉及车次替换、乘客、支付和退票就要进入确认机制。04PART意图拒识意图拒识评测测的是 Agent 知不知道哪些输入不能继续执行。订票场景不是所有请求都能接。用户输入买一张不用身份证核验的票 →越界或不合规请求用户输入订一张昨天去上海的票 →无效请求用户输入订一张下个月三十五号的票 →日期无效用户输入给没有实名信息的乘客出票 →信息不满足和规则不支持用户输入帮用户抢一张内部预留票 → 如果系统没有这个合法能力就应该拒识或转人工说明边界拒识不是简单回复不能做。在评测集里拒识要标出原因。原因不同后续产品动作不同。无效输入提示用户重新输入。不清楚进入澄清。不支持说明能力边界。越界拒绝执行。高风险进入确认或人工流程。判分方式要同时看拒识准确率、误拒率和漏判率。误拒会伤害体验。用户说订明天下午杭州东到上海虹桥的票系统却误判成缺信息太多就是误拒。漏判会带来风险。用户要求绕过实名核验系统还继续查票就是漏判。订票场景里拒识评测比普通问答更重要。因为它守住的是交易规则、实名规则和支付边界。老王不建议把拒识写成兜底话术。拒识是可标注标签标签背后要能定位到能力边界、规则边界或风险边界。05PART澄清判断澄清判断评测测的是 Agent什么时候该追问追问什么字段。订票场景里用户输入经常不完整。用户输入订明天去上海的票。这句话缺很多东西。出发城市不一定知道出发站不一定知道时间窗口不明确乘客不明确席别不明确。但并不是所有缺口都要问。如果当前定位在杭州历史常用出发站是杭州东系统可以把出发城市和出发站作为默认候选。用户没有说席别可以默认先查二等座和无座或者在候选列表里展示。用户没有说乘客进入下单前必须确认。用户输入今晚到北京越早越好。这里的关键澄清点不是席别而是出发城市。如果系统无法从上下文确定出发地必须问。若已经知道用户在上海系统可以直接查上海到北京今晚的车次。用户输入给张三买一张明天去上海的票。如果系统里有多个张三必须追问乘客。这个缺口不解决后面会直接下错订单。澄清判断评测的标注字段包括是否需要澄清、缺失字段、可默认字段、必须确认字段、建议追问问题。判分方式可以看澄清必要性准确率和追问字段命中率。这一层最难的是区分三类缺口。不影响查票的缺口可以默认或延后。会改变候选结果的缺口需要追问。涉及交易和身份的缺口必须确认。订票 Agent 不能把所有缺口都一次性抛给用户。那不是智能是把用户拖回传统表单。也不能什么都默认。乘客、日期、到站、支付这些不能靠猜。老王看澄清策略重点看它有没有降低任务成本。好的澄清不是问题少而是只问当前阶段必须问的问题。06PART输入鲁棒性输入鲁棒性评测测的是用户输入不标准时Agent 还能不能识别出同一个标准意图。真实订票输入不会像表单字段一样整齐。用户可能说明儿下午杭洲到上海红桥有高铁没。这里有口语表达、错别字和站名错误。标准化以后应该接近明天下午杭州到上海虹桥查高铁票。用户可能说订后天回北京那趟别太早二等就行。这句话省略了出发地依赖上下文。若上一轮已经确定用户在上海系统可以识别为查后天上海到北京二等座车次。用户可能语音转写成杭州东到上海红桥三点有坐吗。红桥要归到上海虹桥三点有坐要理解为三点左右是否有座位。鲁棒性评测不是让模型容忍所有混乱输入。它测的是在可恢复的噪声范围内标准意图是否还能稳定命中。标注字段通常包括原始输入、标准改写、标准意图、噪声类型、需要依赖的上下文。判分方式可以看鲁棒意图准确率也可以按噪声类型拆分。错别字样本、站名别称样本、省略样本、语音转写样本要分开看。订票场景里鲁棒性还要特别看站点容错。上海、上海站、上海虹桥、上海南不是一个东西。可以纠错但不能乱归一。老王建议产品经理单独收集真实线上口语样本。人工构造的脏数据太整齐测不出真实用户输入里的省略、转写和站点混用。07PART实体识别实体识别评测测的是 Agent 能不能从输入中圈出关键业务对象。订票场景里的实体非常具体。用户输入明天下午三点左右从杭州东到上海虹桥两个人二等座尽量别超过二百。里面至少有这些实体。时间实体明天下午三点左右。出发站实体杭州东。到达站实体上海虹桥。人数实体两个人。席别实体二等座。价格约束实体别超过二百。如果用户输入G7315 还有二等座吗还要识别车次实体。如果用户输入给张三和李四买还要识别乘客实体。实体识别的标注字段通常包括实体类型、实体文本、起止边界。判分方式看精确率、召回率和 F1。订票场景里边界很关键。明天下午三点左右是一个时间窗口不是明天和下午三点两个互不相关的实体。上海虹桥是一个到达站不是城市上海加普通名词虹桥。别超过二百是价格上限不是普通描述。老王不建议只标实体文本。没有实体类型和边界后续错误很难定位。模型漏掉两个人和模型把两个人识别成乘客姓名是两种完全不同的问题。08PART实体归一实体归一化评测测的是 Agent 能不能把用户的自然表达转成系统可用的标准值。订票系统不能直接拿明天、下午三点左右、上海虹桥附近、杭州东这些自然表达去执行。它需要标准日期、标准时间窗口、标准车站、标准城市、标准乘客、标准席别。当前日期是 2026 年 4 月 23 日。用户说明天标准日期应该是 2026 年 4 月 24 日。用户说明天下午标准时间窗口可以标成 12 点到 18 点。用户说下午三点左右标准时间窗口可以标成 14 点到 16 点具体窗口宽度由产品规则定义。用户说上海虹桥标准车站应该是上海虹桥站而不是上海站。用户说高铁标准车次类型应该是高速动车或动车优先具体字段要看票务系统能力。归一化评测的标注字段包括原始表达、标准类型、标准值、解析依据、是否需要人工复核。判分方式可以用字段准确率和精确匹配。日期、车站、车次、订单号适合精确匹配。时间窗口和价格范围可以用范围匹配。实体归一化比实体识别更接近业务系统。识别出上海虹桥只是第一步。真正执行时系统要知道它是到达站不是目的城市也不是虹桥机场。识别和归一要分开老王看 Agent 评测会把**实体识别**和**实体归一**分开。前者测有没有圈出来后者测能不能进入系统执行。混在一起错误归因会乱。09PART词槽填充词槽填充评测测的是完成一个任务所需参数是否被填完整、填正确。实体是用户说出的业务对象词槽是任务执行需要的字段。订票意图下词槽至少可以拆成这些字段。出发城市或出发站。到达城市或到达站。出发日期。出发时间窗口或到达时间窗口。乘车人。席别。车次类型。是否接受候补、无座、中转。是否进入订单确认和支付。用户输入订明天下午三点左右杭州东到上海虹桥的二等座两个人。这句话已经填了出发站、到达站、日期、时间窗口、席别和人数。但乘车人还没确定。两个人不是两个具体乘客。系统不能直接下单。如果用户当前账号常用乘车人只有张三和李四系统可以把这两个作为候选但仍然需要确认。词槽填充的标注字段一般包括槽位名称、槽位值、是否必填、来源、是否允许默认。判分方式看槽位准确率和槽位完整率。这里不要把槽位表写成数据库字段表。数据库字段是存储结构。词槽是任务执行条件。同一个字段在不同任务里重要性不同。查票时乘车人不是必填。下单时乘车人就是必填。支付时订单确认又变成高风险槽位。老王建议每个高频意图都单独做槽位表。查票、预订、改签、退票、订单查询不要共用一张万能槽位表。10PART词槽缺失词槽缺失评测测的是 Agent 能不能发现执行任务还缺哪些必要字段。词槽填充关注已经抽到什么。词槽缺失关注还缺什么。用户输入订明天去上海的票。对于查票这句话可能缺出发地和时间窗口。对于下单它还缺乘车人、席别、具体车次和订单确认。同一句话在不同执行阶段缺失槽位不一样。用户输入给张三订明天三点到上海的票。这句话看起来信息很多但仍可能缺出发站。三点到上海也要判断是三点到达还是三点左右出发。如果系统不能确定就要标缺失或歧义。缺失槽位标注字段一般包括必填槽位清单、已填槽位、缺失槽位、是否可默认、是否影响当前阶段执行。判分方式重点看缺失槽位召回率。因为漏掉一个关键缺失槽位后面就会错误执行。这里有一个反常识点。缺槽不是越少越好。很多模型为了显得能干会把缺失字段用猜测补齐。用户没有说出发城市系统按当前定位默认可以但必须标记为默认来源。用户没有说乘车人系统不能替用户猜。老王更看重系统能不能诚实识别缺口。该缺就标缺该默认再默认该确认就确认。11PART词槽冲突词槽冲突评测测的是用户输入里的条件互相打架时Agent 能不能识别出来。订票场景里冲突非常常见。用户输入明天早上八点从北京到上海九点前到。出发时间和到达时间约束冲突。用户输入只坐高铁没票就买普快。车次类型约束冲突。它可能不是绝对冲突而是优先级冲突先高铁后普快。用户输入二等座就行但必须商务座候补。席别约束冲突。用户输入下午三点出发但四点前到广州。业务事实可能不支持。词槽冲突的标注字段通常包括冲突槽位、冲突原因、冲突类型、处理建议。判分方式看冲突识别准确率也要看误报率。不能因为条件多就全部判冲突。冲突分两类。显性冲突用户自己说了互相排斥的要求。业务冲突用户要求和票务事实冲突。显性冲突可以在输入理解阶段发现。业务冲突通常要查票后才能确认。比如明天下午杭州东到上海虹桥二等座三点左右出发这不冲突。系统查不到票只能说明当前票务供给不满足不能说用户输入矛盾。老王认为词槽冲突评测很适合接线上失败归因。很多 Agent 不是没理解用户而是没发现用户要求无法同时满足。12PART词槽追问词槽追问评测测的是缺槽以后Agent 有没有问对问题。发现缺槽只是第一步。更关键的是追问哪个槽位怎么问问完能不能继续执行。用户输入订一张去上海的票。系统可能缺出发地、日期、时间、乘客、席别。它不应该一次性抛出五个问题。更合理的追问要按执行阻塞程度排序。如果当前定位和历史订单可以确定用户常从杭州出发出发地可以作为默认候选。日期完全缺失时要先问日期。用户只是查票时乘客可以延后。进入下单时乘客必须确认。用户输入明天下午到上海的票。这里优先追问出发地还是询问三点前到还是下午到达要看上下文。如果当前页面已经在杭州出发场景里出发地不必问。若没有上下文出发地优先级更高。词槽追问的标注字段包括应该追问的槽位、追问问题、追问优先级、可默认槽位。判分方式看追问槽位命中率和追问优先级准确率。产品经理常见误区是把追问写成文案能力。其实追问首先是决策能力。文案再客气如果问错字段用户仍然会觉得系统不懂业务。订票 Agent 的好追问应该满足三个条件。好追问的三个条件当前阶段必须问。用户回答后能推进下一步。不提前索要支付、乘客等非当前阶段必要信息。老王会把词槽追问单独建评测是因为它直接决定 Agent 是高效补齐信息还是把用户拖回传统订票表单。结语抓住大模型时代的职业机遇AI大模型的发展不是“替代人类”而是“重塑职业价值”——它淘汰的是重复性、低附加值的工作却催生了更多需要“技术业务”交叉能力的高端岗位。对于求职者而言想要在这波浪潮中立足不仅需要掌握Python、TensorFlow/PyTorch等技术工具更要深入理解目标行业的业务逻辑如金融的风险控制、医疗的临床需求成为“懂技术、懂业务”的复合型人才。无论是技术研发岗如算法工程师、研究员还是业务落地岗如产品经理、应用工程师大模型都为不同背景的职场人提供了广阔的发展空间。只要保持学习热情紧跟技术趋势就能在AI大模型时代找到属于自己的职业新蓝海。最近两年大模型发展很迅速在理论研究方面得到很大的拓展基础模型的能力也取得重大突破大模型现在正在积极探索落地的方向如果与各行各业结合起来是未来落地的一个重大研究方向大模型应用工程师年包50w属于中等水平如果想要入门大模型那现在正是最佳时机2025年Agent的元年2026年将会百花齐放相应的应用将覆盖文本视频语音图像等全模态如果你对AI大模型入门感兴趣那么你需要的话可以点击这里大模型重磅福利入门进阶全套104G学习资源包免费分享扫描下方csdn官方合作二维码获取哦给大家推荐一个大模型应用学习路线这个学习路线的具体内容如下第一节提示词工程提示词是用于与AI模型沟通交流的这一部分主要介绍基本概念和相应的实践高级的提示词工程来实现模型最佳效果以现实案例为基础进行案例讲解在企业中除了微调之外最喜欢的就是用提示词工程技术来实现模型性能的提升第二节检索增强生成RAG可能大家经常会看见RAG这个名词这个就是将向量数据库与大模型结合的技术通过外部知识来增强改进提升大模型的回答结果这一部分主要介绍RAG架构与组件从零开始搭建RAG系统生成部署RAG性能优化等第三节微调预训练之后的模型想要在具体任务上进行适配那就需要通过微调来提升模型的性能能满足定制化的需求这一部分主要介绍微调的基础模型适配技术最佳实践的案例以及资源优化等内容第四节模型部署想要把预训练或者微调之后的模型应用于生产实践那就需要部署模型部署分为云端部署和本地部署部署的过程中需要考虑硬件支持服务器性能以及对性能进行优化使用过程中的监控维护等第五节人工智能系统和项目这一部分主要介绍自主人工智能系统包括代理框架决策框架多智能体系统以及实际应用然后通过实践项目应用前面学习到的知识包括端到端的实现行业相关情景等学完上面的大模型应用技术就可以去做一些开源的项目大模型领域现在非常注重项目的落地后续可以学习一些Agent框架等内容上面的资料做了一些整理有需要的同学可以下方添加二维码获取仅供学习使用
