← 返回闯关手册

图解10个Agent可标注评测类型：以火车票案例讲解

核心内容速览

• 标签拆到可执行层：意图标签的边界必须对应后续动作差异——查票/预订/改签/退票混在一个大类里，出错时无法定位。
• 多意图拆分看三个指标：子任务召回率、冗余率、顺序准确率；漏拆和过度拆分同样有害。
• 拒识是可标注标签，不是兜底话术：无效/不清楚/不支持/越界/高风险五类原因对应五种产品动作；拒识准确率、误拒率、漏判率同时看。
• 缺槽不是越少越好：模型为显得能干会猜测补齐缺失字段——诚实标缺、默认标来源、该确认就确认。
• 好追问是决策不是文案：当前阶段必须问、回答后能推进、不提前索要非当前阶段信息。
• 落地顺序：意图+实体识别 → 归一+词槽填充 → 缺失+澄清 → 追问+冲突 → 多意图/隐含/拒识/鲁棒性。

适合谁 · 怎么用

先修：a05（Agent Eval 概念五件套）。做对话/任务型 Agent（客服、订票、政务、办公助手）的 PM 与测试必读——尤其评测集只标了「意图大类」的团队。与 a29（工具调用评测）互补：一个管输入理解层，一个管执行层。

闯关自测

先合上原文在心里作答，再点开对照。全对 = 本篇真正通关。

Q1　意图标签拆到什么粒度才算够用？

拆到「能决定下一步动作」的可执行层：查票不需要乘客、预订需要、改签依赖订单、退票涉及费用——标签边界必须对应动作差异，停在业务名词层的标签无法定位错误。

Q2　词槽缺失评测的反常识点是什么？

缺槽不是越少越好。模型会为显得能干而猜测补齐缺失字段；正确做法是诚实识别缺口——该缺就标缺，默认值标记来源，涉及交易身份的必须确认。

Q3　「好追问」的三个条件？

① 当前阶段必须问；② 用户回答后能推进下一步；③ 不提前索要支付、乘客等非当前阶段必要信息。追问首先是决策能力，不是文案能力。

以下为原文全文

上方为本站原创导读，下方为原文完整收录，便于对照阅读。

一、写在前面：返工的不是结果，是没拆开的输入

很多团队做订票 Agent 评测，上来就看最后有没有给出车次。真正让系统返工的不是车次推荐不准，而是前面没有把用户一句「订明天下午去上海的高铁」拆成可标注判断。不是 Agent 会下单以后才需要评测，而是输入理解、实体词槽先被评测压实，订票链路才可能稳定。

订火车票是一个很适合讲 Agent 意图识别的场景。用户一句话通常很短，系统背后却要完成一串判断。用户输入可能是「订明天下午三点左右从杭州东到上海虹桥的二等座，两个人，靠窗优先，别太晚到，能改签就行」。这句话表面是订票，拆开以后，它至少包含目标城市、出发站、到达站、时间窗口、席别、人数、偏好、软约束、风险动作和可能的售后要求。如果评测集只标一个「订票」意图，后面出错时根本不知道问题在哪。

本篇只写意图识别分类里最靠前的两层：输入理解标注（判断 Agent 有没有听懂用户目标）与实体词槽标注（判断 Agent 有没有抽对执行参数）。

二、意图识别：标签边界必须对应动作差异

意图识别评测测的是主任务分类。订票场景里，主意图不能只写一个「订票」。同样是火车票相关输入，用户可能在做完全不同的事：

• 「明天下午杭州到上海还有票吗」→ 查票

• 「选 G7315 二等座，给张三买一张」→ 预订

• 「明天那张去上海的票改到晚上」→ 改签

• 「把后天北京南到济南西那张退了」→ 退票

• 「查一下订单有没有出票成功」→ 订单查询

• 「这趟车晚点导致赶不上会议」→ 异常反馈或客服投诉

这些任务如果都塞进「订票」大类，后续动作会完全混乱。查票不需要乘客身份，预订需要；改签依赖已有订单，退票涉及费用规则，投诉则进入客服或补偿流程。

意图识别评测的样本对象通常是单轮用户输入。标准标注字段至少包括：主意图、子意图、是否有效、业务域、风险动作。判分可以用分类准确率和宏平均 F1；样本量不大时，更建议看混淆矩阵。

订票场景最要命的混淆不是查票和推荐混了，而是：查票和下单混了（系统提前进入乘客和支付流程）、改签和重新购票混了（用户持有两张票）、退票和取消未支付订单混了（漏掉手续费和确认风险）。

所以意图识别不是越多标签越专业。标签的边界必须对应后续动作差异——一个标签如果不能决定下一步动作，它就还不是产品可用标签。意图树要拆到可执行层，而不是停在业务名词层。

三、多意图拆分：召回、冗余、顺序三个指标

多意图拆分评测测的是一句话里有多个任务时，Agent 能不能拆全，并保留合理顺序。订票用户很少只说一件事：

「查一下明天下午杭州到上海的高铁，顺便看周日晚上上海回杭州还有没有票，去程优先二等座，返程能晚点」——至少两个查询任务（去程查票 + 返程查票）。

「查明天下午杭州到上海的票，有合适的就给张三预订一张二等座」——这不是并列任务，而是依赖关系：必须先查票，有候选车次才能进入预订。

「把明天去上海那张改到晚上，如果没有合适车次就退掉」——条件分支：先查原订单，再查可改签车次；有则改签，没有则进入退票候选流程，且退票必须确认。

标注字段：子意图列表、任务顺序、依赖关系、条件分支、是否需要确认。判分不能只看最终回答「看起来有没有覆盖」，要拆成三个指标：

1. 子任务召回率——应该拆出的任务有没有漏；

2. 冗余率——系统有没有补出用户没有表达的任务；

3. 顺序准确率——有依赖关系的任务有没有排错。

多意图漏拆会直接导致用户少买返程、误改订单、漏掉退票确认。过度拆分也有成本：用户只是问几点有车，系统却拆出查票、订票、支付、出票四个任务，就是把查询误推进到交易。看拆分要优先看动作边界：查票可以自动，预订要确认乘客，支付必须确认。拆分不是为了让流程变长，而是为了让每个动作的边界清楚。

四、隐含意图：从业务语境补目标，而非自由发挥

隐含意图评测测的是用户没有直接说目标时，Agent 能不能从业务语境里补出真实目标：

「明天下午三点前能到上海虹桥吗」——表层是「能不能」的问题，真实目标是查找到达时间早于三点的车次。「别耽误四点的会」——背后是到达时间约束，应转成到站时间早于会议时间并预留出站缓冲。「这趟太晚了」——若当前页面已展示候选车次，隐含意图是调整筛选条件、换更早车次。「还有便宜点的吗」——在候选列表里通常不是价格咨询，而是按票价重排或放宽席别。

隐含意图不能靠模型自由发挥，它必须来自三个来源：当前业务页面（正在看车次列表还是订单确认页）、当前对话状态（前面已确定的信息）、业务规则（会议时间影响到达窗口）。标注字段：表层表达、隐含意图、业务目标、触发依据、是否需要澄清。判分不看「输出像不像」，要看隐含目标是否被标注员认可、后续动作是否落在该目标上。

最容易犯的错是把所有模糊表达都自动扩展成执行动作。「太贵了」在查询列表页可以继续筛选，在支付页系统就不能直接替用户改票。隐含意图要和澄清判断一起看：能补出方向，但一旦涉及车次替换、乘客、支付和退票，就要进入确认机制。

五、意图拒识：守住交易、实名与支付边界

意图拒识评测测的是 Agent 知不知道哪些输入不能继续执行：

• 「买一张不用身份证核验的票」→ 越界或不合规请求

• 「订一张昨天去上海的票」→ 无效请求

• 「订一张下个月三十五号的票」→ 日期无效

• 「给没有实名信息的乘客出票」→ 信息不满足、规则不支持

• 「帮用户抢一张内部预留票」→ 系统没有这个合法能力，应拒识或转人工说明边界

拒识不是简单回复「不能做」，评测集里要标出原因，因为原因不同、后续产品动作不同：无效输入（提示重新输入）、不清楚（进入澄清）、不支持（说明能力边界）、越界（拒绝执行）、高风险（进入确认或人工流程）。

判分要同时看三个指标：拒识准确率、误拒率、漏判率。误拒伤害体验（信息完整的订票请求被误判缺信息），漏判带来风险（要求绕过实名核验还继续查票）。订票场景里拒识评测比普通问答更重要——它守住的是交易规则、实名规则和支付边界。拒识不是兜底话术，是可标注标签，标签背后要能定位到能力边界、规则边界或风险边界。

六、澄清判断：只问当前阶段必须问的

澄清判断评测测的是 Agent 什么时候该追问、追问什么字段。「订明天去上海的票」缺很多东西：出发城市、出发站、时间窗口、乘客、席别都不明确——但并不是所有缺口都要问。

如果当前定位在杭州、历史常用出发站是杭州东，出发地可以做默认候选；没说席别可以先查二等座和无座；没说乘客，进入下单前必须确认。「给张三买一张明天去上海的票」——如果系统里有多个张三，必须追问乘客，这个缺口不解决，后面会直接下错订单。

标注字段：是否需要澄清、缺失字段、可默认字段、必须确认字段、建议追问问题。判分看澄清必要性准确率和追问字段命中率。最难的是区分三类缺口：不影响查票的（可默认或延后）、会改变候选结果的（需要追问）、涉及交易和身份的（必须确认）。不能把所有缺口一次性抛给用户——那不是智能，是把用户拖回传统表单；也不能什么都默认——乘客、日期、到站、支付不能靠猜。

七、输入鲁棒性：可纠错，但不能乱归一

输入鲁棒性评测测的是用户输入不标准时，Agent 还能不能识别出同一个标准意图。真实输入不会像表单一样整齐：「明儿下午杭洲到上海红桥有高铁没」有口语、错别字和站名错误，标准化后应接近「明天下午杭州到上海虹桥查高铁票」；「订后天回北京那趟，别太早，二等就行」省略了出发地，依赖上一轮上下文；语音转写的「三点有坐吗」要理解为「三点左右是否有座位」。

鲁棒性不是让模型容忍所有混乱输入，而是测在可恢复的噪声范围内，标准意图是否还能稳定命中。标注字段：原始输入、标准改写、标准意图、噪声类型、需要依赖的上下文。判分看鲁棒意图准确率，并按噪声类型拆开看（错别字、站名别称、省略、语音转写要分开统计）。

订票场景要特别看站点容错：上海、上海站、上海虹桥、上海南不是一个东西——可以纠错，但不能乱归一。建议单独收集真实线上口语样本：人工构造的脏数据太整齐，测不出真实输入里的省略、转写和站点混用。

八、实体识别：类型和边界比文本更重要

实体识别评测测的是 Agent 能不能从输入中圈出关键业务对象。「明天下午三点左右从杭州东到上海虹桥，两个人，二等座，尽量别超过二百」至少包含：时间实体、出发站实体、到达站实体、人数实体、席别实体、价格约束实体。说「G7315 还有二等座吗」要识别车次实体；「给张三和李四买」要识别乘客实体。

标注字段：实体类型、实体文本、起止边界。判分看精确率、召回率和 F1。边界很关键：「明天下午三点左右」是一个时间窗口，不是「明天」加「下午三点」两个无关实体；「上海虹桥」是一个到达站，不是城市加普通名词；「别超过二百」是价格上限，不是普通描述。不要只标实体文本——没有类型和边界，错误很难定位：模型漏掉「两个人」和把「两个人」识别成乘客姓名，是两种完全不同的问题。

九、实体归一：识别是圈出来，归一是可执行

实体归一化评测测的是 Agent 能不能把自然表达转成系统可用的标准值。订票系统不能直接拿「明天」「下午三点左右」「上海虹桥附近」去执行，它需要标准日期、标准时间窗口、标准车站。假设当前日期是 2026 年 4 月 23 日：「明天」→ 2026-04-24；「明天下午」→ 12:00-18:00；「下午三点左右」→ 14:00-16:00（窗口宽度由产品规则定义）；「上海虹桥」→ 上海虹桥站而非上海站；「高铁」→ 高速动车或动车优先。

标注字段：原始表达、标准类型、标准值、解析依据、是否需要人工复核。判分用字段准确率：日期、车站、车次、订单号适合精确匹配，时间窗口和价格范围用范围匹配。实体识别和实体归一要分开评测——前者测有没有圈出来，后者测能不能进入系统执行；混在一起，错误归因会乱。

十、词槽填充：槽位是任务条件，不是数据库字段

词槽填充评测测的是完成任务所需参数是否被填完整、填正确。实体是用户说出的业务对象，词槽是任务执行需要的字段。订票意图下词槽至少包括：出发城市/站、到达城市/站、出发日期、时间窗口、乘车人、席别、车次类型、是否接受候补/无座/中转、是否进入订单确认和支付。

「订明天下午三点左右杭州东到上海虹桥的二等座，两个人」——出发站、到达站、日期、时间窗口、席别、人数都已填，但「两个人」不是两个具体乘客，乘车人未定，系统不能直接下单；即使常用乘车人只有张三和李四，也只能作为候选，仍需确认。

标注字段：槽位名称、槽位值、是否必填、来源、是否允许默认。判分看槽位准确率和槽位完整率。注意：同一个字段在不同任务里重要性不同——查票时乘车人不是必填，下单时是必填，支付时订单确认变成高风险槽位。建议每个高频意图单独做槽位表，查票、预订、改签、退票、订单查询不要共用一张万能槽位表。

十一、词槽缺失：缺槽不是越少越好

词槽缺失评测测的是 Agent 能不能发现执行任务还缺哪些必要字段。词槽填充关注「已经抽到什么」，缺失关注「还缺什么」。同一句话在不同执行阶段缺失槽位不一样：「订明天去上海的票」对查票缺出发地和时间窗口，对下单还缺乘车人、席别、具体车次和订单确认。「给张三订明天三点到上海的票」信息看似很多，仍可能缺出发站，且「三点到上海」要判断是到达还是出发——不能确定就要标缺失或歧义。

标注字段：必填槽位清单、已填槽位、缺失槽位、是否可默认、是否影响当前阶段执行。判分重点看缺失槽位召回率——漏掉一个关键缺失槽位，后面就会错误执行。

这里有一个反常识点：缺槽不是越少越好。很多模型为了显得能干，会把缺失字段用猜测补齐。用户没说出发城市，按当前定位默认可以，但必须标记为默认来源；用户没说乘车人，系统不能替用户猜。更看重的是系统能不能诚实识别缺口：该缺就标缺，该默认再默认，该确认就确认。

十二、词槽冲突：查不到票不等于用户矛盾

词槽冲突评测测的是用户输入里的条件互相打架时，Agent 能不能识别：「明天早上八点从北京到上海，九点前到」是出发与到达时间冲突；「只坐高铁，没票就买普快」可能是优先级而非绝对冲突（先高铁后普快）；「二等座就行，但必须商务座候补」是席别冲突；「下午三点出发，但四点前到广州」是业务事实不支持。

标注字段：冲突槽位、冲突原因、冲突类型、处理建议。判分看冲突识别准确率，也要看误报率——不能因为条件多就全判冲突。冲突分两类：显性冲突（用户自己说了互相排斥的要求，输入理解阶段可发现）和业务冲突（用户要求与票务事实冲突，要查票后才能确认）。「查不到票」只能说明供给不满足，不能说用户输入矛盾。词槽冲突评测很适合接线上失败归因——很多 Agent 不是没理解用户，而是没发现用户要求无法同时满足。

十三、词槽追问：追问首先是决策能力

词槽追问评测测的是缺槽以后，Agent 有没有问对问题。「订一张去上海的票」可能缺出发地、日期、时间、乘客、席别——但不应该一次性抛五个问题，要按执行阻塞程度排序：出发地有定位和历史订单可做默认候选；日期完全缺失要先问；查票阶段乘客可延后，进入下单必须确认。

标注字段：应该追问的槽位、追问问题、追问优先级、可默认槽位。判分看追问槽位命中率和追问优先级准确率。常见误区是把追问当文案能力——其实它首先是决策能力：文案再客气，问错字段用户仍然觉得系统不懂业务。

好追问满足三个条件：1. 当前阶段必须问；2. 用户回答后能推进下一步；3. 不提前索要支付、乘客等非当前阶段必要信息。词槽追问值得单独建评测，因为它直接决定 Agent 是高效补齐信息，还是把用户拖回传统订票表单。

十四、落地顺序与成熟度标准

写完这些概念，不代表每个订票 Agent 都要一次性建满全部评测集。建议的落地顺序：

1. 先建意图识别和实体识别——解决「听没听懂、抽没抽到」；

2. 再建实体归一和词槽填充——解决「能不能查票」；

3. 接着建词槽缺失和澄清判断——解决「什么时候问」；

4. 再补词槽追问和词槽冲突——解决「怎么问、怎么处理矛盾」；

5. 最后补多意图拆分、隐含意图、意图拒识和输入鲁棒性——解决复杂真实输入。

最小可用评测集不要追求漂亮分类，先覆盖最高频、最高风险、最高返工成本的输入。

最后给一个评测集成熟度的判断标准：如果你的评测样本只能标出「用户想订票」，它还只是意图分类；如果它能同时标出查票还是下单、去程还是返程、隐含到达时间、拒识边界、缺失字段、标准车站、乘客槽位、席别冲突和追问优先级——它才开始接近可落地的 Agent 意图识别评测集。