本文详细介绍了大模型在订票场景下的意图识别评测方法包括输入理解、实体词槽、多意图拆分、隐含意图、意图拒识、澄清判断等12个关键步骤。文章强调评测集的构建需遵循业务实际需求从基础意图识别到复杂多意图处理逐步深入并提供了原型库和PRD模板等实用资源。评测的核心在于确保Agent能够准确理解用户意图、完整提取关键信息、合理处理冲突和缺失从而提升订票系统的稳定性和用户体验。1、意图识别意图识别评测测的是主任务分类。订票场景里主意图至少不能只写一个订票。同样是火车票相关输入用户可能在做完全不同的事。用户输入明天下午杭州到上海还有票吗 →查票用户输入选 G7315 二等座给张三买一张 →预订用户输入明天那张去上海的票改到晚上 →改签用户输入把后天北京南到济南西那张退了 →退票用户输入查一下订单有没有出票成功 →订单查询用户输入这趟车晚点导致赶不上会议 →异常反馈或客服投诉这些任务如果都塞进订票大类后续动作会完全混乱。查票不需要乘客身份预订需要。改签依赖已有订单退票涉及费用规则投诉则进入客服或补偿流程。意图识别评测的样本对象通常是单轮用户输入。标准标注字段至少包括主意图、子意图、是否有效、业务域、风险动作。判分方式可以用分类准确率和宏平均 F1。样本量不大时更建议看混淆矩阵。订票场景最要命的混淆不是查票和推荐混了而是查票和下单混了改签和重新购票混了退票和取消未支付订单混了。查票被误判成下单会让系统提前进入乘客和支付流程。改签被误判成重新购票会造成用户持有两张票。退票被误判成取消未支付订单会漏掉手续费和确认风险。所以意图识别不是越多标签越专业。标签的边界必须对应后续动作差异。会把订票意图树拆到可执行层而不是停在业务名词层。一个标签如果不能决定下一步动作它就还不是产品可用标签。2、多意图拆分多意图拆分评测测的是一句话里有多个任务时Agent 能不能拆全并保留合理顺序。订票用户很少只说一件事。用户输入查一下明天下午杭州到上海的高铁顺便看周日晚上上海回杭州还有没有票去程优先二等座返程能晚点。这句话里至少有两个查询任务。去程查票杭州到上海明天下午高铁二等座优先。返程查票上海到杭州周日晚上时间偏晚。用户输入查明天下午杭州到上海的票有合适的就给张三预订一张二等座。这不是两个并列任务而是有依赖关系。必须先查票再根据候选车次进入预订。没有候选车次就不能进入下单。用户输入把明天去上海那张改到晚上如果没有合适车次就退掉。这里又是条件分支。先查原订单再查可改签车次。若有合适车次走改签。若没有合适车次再进入退票候选流程。退票还必须确认。多意图拆分评测的标注字段包括子意图列表、任务顺序、依赖关系、条件分支、是否需要确认。判分不能只看最终回答看起来有没有覆盖。要拆成三个指标。子任务召回率应该拆出的任务有没有漏。冗余率系统有没有补出用户没有表达的任务。顺序准确率有依赖关系的任务有没有排错。订票场景里多意图漏拆会直接导致用户少买返程、误改订单、漏掉退票确认。过度拆分也有成本。用户只是问明天去上海几点有车系统却拆出查票、订票、支付、出票四个任务就是把查询误推进到交易。看多意图拆分会优先看动作边界。查票可以自动预订要确认乘客支付必须确认。拆分不是为了让流程变长而是为了让每个动作的边界清楚。3、隐含意图隐含意图评测测的是用户没有直接说目标时Agent 能不能从业务语境里补出真实目标。订火车票时用户经常不说查票或订票。用户输入明天下午三点前能到上海虹桥吗。表层看是一个能不能的问题。真实目标通常是查找到达时间早于三点的车次。用户输入别耽误四点的会。这不是闲聊背后是到达时间约束。系统应该把它转成到站时间需要早于会议时间并预留出站和通勤缓冲。用户输入这趟太晚了。如果当前页面已经展示了候选车次这句话的隐含意图是调整筛选条件换更早到达或更早出发的车次。用户输入还有便宜点的吗。在车次候选列表里它通常不是普通价格咨询而是按票价重新排序或者放宽席别和车次类型。隐含意图不能靠模型自由发挥。它必须来自三个来源。当前业务页面比如正在看车次列表、订单确认页、改签页。当前对话状态比如前面已经确定杭州到上海。订票业务规则比如会议时间会影响到达时间窗口。这类评测的标注字段包括表层表达、隐含意图、业务目标、触发依据、是否需要澄清。判分不要只看模型输出像不像。要看隐含目标是否被标注员认可以及后续动作是否落在这个目标上。隐含意图的边界这里最容易犯的错是把所有模糊表达都自动扩展成执行动作。用户说太贵了可能是想换低价车次也可能只是表达不满意。当前如果还在查询列表可以继续筛选。当前如果已经进入支付页系统就不能直接替用户改票。更倾向于把隐含意图和澄清判断一起看。隐含意图能补出方向但一旦涉及车次替换、乘客、支付和退票就要进入确认机制。4、意图拒识意图拒识评测测的是 Agent 知不知道哪些输入不能继续执行。订票场景不是所有请求都能接。用户输入买一张不用身份证核验的票 →越界或不合规请求用户输入订一张昨天去上海的票 →无效请求用户输入订一张下个月三十五号的票 →日期无效用户输入给没有实名信息的乘客出票 →信息不满足和规则不支持用户输入帮用户抢一张内部预留票 → 如果系统没有这个合法能力就应该拒识或转人工说明边界拒识不是简单回复不能做。在评测集里拒识要标出原因。原因不同后续产品动作不同。无效输入提示用户重新输入。不清楚进入澄清。不支持说明能力边界。越界拒绝执行。高风险进入确认或人工流程。判分方式要同时看拒识准确率、误拒率和漏判率。误拒会伤害体验。用户说订明天下午杭州东到上海虹桥的票系统却误判成缺信息太多就是误拒。漏判会带来风险。用户要求绕过实名核验系统还继续查票就是漏判。订票场景里拒识评测比普通问答更重要。因为它守住的是交易规则、实名规则和支付边界。不建议把拒识写成兜底话术。拒识是可标注标签标签背后要能定位到能力边界、规则边界或风险边界。5、澄清判断澄清判断评测测的是 Agent什么时候该追问追问什么字段。订票场景里用户输入经常不完整。用户输入订明天去上海的票。这句话缺很多东西。出发城市不一定知道出发站不一定知道时间窗口不明确乘客不明确席别不明确。但并不是所有缺口都要问。如果当前定位在杭州历史常用出发站是杭州东系统可以把出发城市和出发站作为默认候选。用户没有说席别可以默认先查二等座和无座或者在候选列表里展示。用户没有说乘客进入下单前必须确认。用户输入今晚到北京越早越好。这里的关键澄清点不是席别而是出发城市。如果系统无法从上下文确定出发地必须问。若已经知道用户在上海系统可以直接查上海到北京今晚的车次。用户输入给张三买一张明天去上海的票。如果系统里有多个张三必须追问乘客。这个缺口不解决后面会直接下错订单。澄清判断评测的标注字段包括是否需要澄清、缺失字段、可默认字段、必须确认字段、建议追问问题。判分方式可以看澄清必要性准确率和追问字段命中率。这一层最难的是区分三类缺口。不影响查票的缺口可以默认或延后。会改变候选结果的缺口需要追问。涉及交易和身份的缺口必须确认。订票 Agent 不能把所有缺口都一次性抛给用户。那不是智能是把用户拖回传统表单。也不能什么都默认。乘客、日期、到站、支付这些不能靠猜。看澄清策略重点看它有没有降低任务成本。好的澄清不是问题少而是只问当前阶段必须问的问题。6、输入鲁棒性输入鲁棒性评测测的是用户输入不标准时Agent 还能不能识别出同一个标准意图。真实订票输入不会像表单字段一样整齐。用户可能说明儿下午杭洲到上海红桥有高铁没。这里有口语表达、错别字和站名错误。标准化以后应该接近明天下午杭州到上海虹桥查高铁票。用户可能说订后天回北京那趟别太早二等就行。这句话省略了出发地依赖上下文。若上一轮已经确定用户在上海系统可以识别为查后天上海到北京二等座车次。用户可能语音转写成杭州东到上海红桥三点有坐吗。红桥要归到上海虹桥三点有坐要理解为三点左右是否有座位。鲁棒性评测不是让模型容忍所有混乱输入。它测的是在可恢复的噪声范围内标准意图是否还能稳定命中。标注字段通常包括原始输入、标准改写、标准意图、噪声类型、需要依赖的上下文。判分方式可以看鲁棒意图准确率也可以按噪声类型拆分。错别字样本、站名别称样本、省略样本、语音转写样本要分开看。订票场景里鲁棒性还要特别看站点容错。上海、上海站、上海虹桥、上海南不是一个东西。可以纠错但不能乱归一。建议产品经理单独收集真实线上口语样本。人工构造的脏数据太整齐测不出真实用户输入里的省略、转写和站点混用。7、实体识别实体识别评测测的是 Agent 能不能从输入中圈出关键业务对象。订票场景里的实体非常具体。用户输入明天下午三点左右从杭州东到上海虹桥两个人二等座尽量别超过二百。里面至少有这些实体。时间实体明天下午三点左右。出发站实体杭州东。到达站实体上海虹桥。人数实体两个人。席别实体二等座。价格约束实体别超过二百。如果用户输入G7315 还有二等座吗还要识别车次实体。如果用户输入给张三和李四买还要识别乘客实体。实体识别的标注字段通常包括实体类型、实体文本、起止边界。判分方式看精确率、召回率和 F1。订票场景里边界很关键。明天下午三点左右是一个时间窗口不是明天和下午三点两个互不相关的实体。上海虹桥是一个到达站不是城市上海加普通名词虹桥。别超过二百是价格上限不是普通描述。不建议只标实体文本。没有实体类型和边界后续错误很难定位。模型漏掉两个人和模型把两个人识别成乘客姓名是两种完全不同的问题。8、实体归一实体归一化评测测的是 Agent 能不能把用户的自然表达转成系统可用的标准值。订票系统不能直接拿明天、下午三点左右、上海虹桥附近、杭州东这些自然表达去执行。它需要标准日期、标准时间窗口、标准车站、标准城市、标准乘客、标准席别。当前日期是 2026 年 4 月 23 日。用户说明天标准日期应该是 2026 年 4 月 24 日。用户说明天下午标准时间窗口可以标成 12 点到 18 点。用户说下午三点左右标准时间窗口可以标成 14 点到 16 点具体窗口宽度由产品规则定义。用户说上海虹桥标准车站应该是上海虹桥站而不是上海站。用户说高铁标准车次类型应该是高速动车或动车优先具体字段要看票务系统能力。归一化评测的标注字段包括原始表达、标准类型、标准值、解析依据、是否需要人工复核。判分方式可以用字段准确率和精确匹配。日期、车站、车次、订单号适合精确匹配。时间窗口和价格范围可以用范围匹配。实体归一化比实体识别更接近业务系统。识别出上海虹桥只是第一步。真正执行时系统要知道它是到达站不是目的城市也不是虹桥机场。识别和归一要分开看 Agent 评测会把**实体识别**和**实体归一**分开。前者测有没有圈出来后者测能不能进入系统执行。混在一起错误归因会乱。9、词槽填充词槽填充评测测的是完成一个任务所需参数是否被填完整、填正确。实体是用户说出的业务对象词槽是任务执行需要的字段。订票意图下词槽至少可以拆成这些字段。出发城市或出发站。到达城市或到达站。出发日期。出发时间窗口或到达时间窗口。乘车人。席别。车次类型。是否接受候补、无座、中转。是否进入订单确认和支付。用户输入订明天下午三点左右杭州东到上海虹桥的二等座两个人。这句话已经填了出发站、到达站、日期、时间窗口、席别和人数。但乘车人还没确定。两个人不是两个具体乘客。系统不能直接下单。如果用户当前账号常用乘车人只有张三和李四系统可以把这两个作为候选但仍然需要确认。词槽填充的标注字段一般包括槽位名称、槽位值、是否必填、来源、是否允许默认。判分方式看槽位准确率和槽位完整率。这里不要把槽位表写成数据库字段表。数据库字段是存储结构。词槽是任务执行条件。同一个字段在不同任务里重要性不同。查票时乘车人不是必填。下单时乘车人就是必填。支付时订单确认又变成高风险槽位。建议每个高频意图都单独做槽位表。查票、预订、改签、退票、订单查询不要共用一张万能槽位表。10、词槽缺失词槽缺失评测测的是 Agent 能不能发现执行任务还缺哪些必要字段。词槽填充关注已经抽到什么。词槽缺失关注还缺什么。用户输入订明天去上海的票。对于查票这句话可能缺出发地和时间窗口。对于下单它还缺乘车人、席别、具体车次和订单确认。同一句话在不同执行阶段缺失槽位不一样。用户输入给张三订明天三点到上海的票。这句话看起来信息很多但仍可能缺出发站。三点到上海也要判断是三点到达还是三点左右出发。如果系统不能确定就要标缺失或歧义。缺失槽位标注字段一般包括必填槽位清单、已填槽位、缺失槽位、是否可默认、是否影响当前阶段执行。判分方式重点看缺失槽位召回率。因为漏掉一个关键缺失槽位后面就会错误执行。这里有一个反常识点。缺槽不是越少越好。很多模型为了显得能干会把缺失字段用猜测补齐。用户没有说出发城市系统按当前定位默认可以但必须标记为默认来源。用户没有说乘车人系统不能替用户猜。更看重系统能不能诚实识别缺口。该缺就标缺该默认再默认该确认就确认。11 、词槽冲突词槽冲突评测测的是用户输入里的条件互相打架时Agent 能不能识别出来。订票场景里冲突非常常见。用户输入明天早上八点从北京到上海九点前到。出发时间和到达时间约束冲突。用户输入只坐高铁没票就买普快。车次类型约束冲突。它可能不是绝对冲突而是优先级冲突先高铁后普快。用户输入二等座就行但必须商务座候补。席别约束冲突。用户输入下午三点出发但四点前到广州。业务事实可能不支持。词槽冲突的标注字段通常包括冲突槽位、冲突原因、冲突类型、处理建议。判分方式看冲突识别准确率也要看误报率。不能因为条件多就全部判冲突。冲突分两类。显性冲突用户自己说了互相排斥的要求。业务冲突用户要求和票务事实冲突。显性冲突可以在输入理解阶段发现。业务冲突通常要查票后才能确认。比如明天下午杭州东到上海虹桥二等座三点左右出发这不冲突。系统查不到票只能说明当前票务供给不满足不能说用户输入矛盾。认为词槽冲突评测很适合接线上失败归因。很多 Agent 不是没理解用户而是没发现用户要求无法同时满足。12 、词槽追问词槽追问评测测的是缺槽以后Agent 有没有问对问题。发现缺槽只是第一步。更关键的是追问哪个槽位怎么问问完能不能继续执行。用户输入订一张去上海的票。系统可能缺出发地、日期、时间、乘客、席别。它不应该一次性抛出五个问题。更合理的追问要按执行阻塞程度排序。如果当前定位和历史订单可以确定用户常从杭州出发出发地可以作为默认候选。日期完全缺失时要先问日期。用户只是查票时乘客可以延后。进入下单时乘客必须确认。用户输入明天下午到上海的票。这里优先追问出发地还是询问三点前到还是下午到达要看上下文。如果当前页面已经在杭州出发场景里出发地不必问。若没有上下文出发地优先级更高。词槽追问的标注字段包括应该追问的槽位、追问问题、追问优先级、可默认槽位。判分方式看追问槽位命中率和追问优先级准确率。产品经理常见误区是把追问写成文案能力。其实追问首先是决策能力。文案再客气如果问错字段用户仍然会觉得系统不懂业务。订票 Agent 的好追问应该满足三个条件。好追问的三个条件当前阶段必须问。用户回答后能推进下一步。不提前索要支付、乘客等非当前阶段必要信息。会把词槽追问单独建评测是因为它直接决定 Agent 是高效补齐信息还是把用户拖回传统订票表单。13 、最后说下这 12 个概念写完不代表每个订票 Agent 都要一次性建满 12 个评测集。如果团队刚开始做 Agent 意图识别评测建议按这个顺序落地。先建意图识别和实体识别解决听没听懂、抽没抽到。再建实体归一和词槽填充解决能不能查票。接着建词槽缺失和澄清判断解决什么时候问。再补词槽追问和词槽冲突解决怎么问、怎么处理矛盾。最后补多意图拆分、隐含意图、意图拒识和输入鲁棒性解决复杂真实输入。最小可用评测集不要追求漂亮分类。它应该先覆盖最高频、最高风险、最高返工成本的订票输入。最后给一个标准。评测集成熟度的判断标准如果你的评测样本只能标出用户想订票它还只是意图分类。如果它能同时标出查票还是下单、去程还是返程、隐含到达时间、拒识边界、缺失字段、标准车站、乘客槽位、席别冲突和追问优先级它才开始接近可落地的Agent 意图识别评测集。最后对于正在迷茫择业、想转行提升或是刚入门的程序员、编程小白来说有一个问题几乎人人都在问未来10年什么领域的职业发展潜力最大答案只有一个人工智能尤其是大模型方向当下人工智能行业正处于爆发式增长期其中大模型相关岗位更是供不应求薪资待遇直接拉满——字节跳动作为AI领域的头部玩家给硕士毕业的优质AI人才含大模型相关方向开出的月基础工资高达5万—6万元即便是非“人才计划”的普通应聘者月基础工资也能稳定在4万元左右。再看阿里、腾讯两大互联网大厂非“人才计划”的AI相关岗位应聘者月基础工资也约有3万元远超其他行业同资历岗位的薪资水平对于程序员、小白来说无疑是绝佳的转型和提升赛道。对于想入局大模型、抢占未来10年行业红利的程序员和小白来说现在正是最好的学习时机行业缺口大、大厂需求旺、薪资天花板高只要找准学习方向稳步提升技能就能轻松摆脱“低薪困境”抓住AI时代的职业机遇。如果你还不知道从何开始我自己整理一套全网最全最细的大模型零基础教程我也是一路自学走过来的很清楚小白前期学习的痛楚你要是没有方向还没有好的资源根本学不到东西下面是我整理的大模型学习资源希望能帮到你。扫码免费领取全部内容1、大模型学习路线2、从0到进阶大模型学习视频教程从入门到进阶这里都有跟着老师学习事半功倍。3、 入门必看大模型学习书籍文档.pdf书面上的技术书籍确实太多了这些是我精选出来的还有很多不在图里4、AI大模型最新行业报告2026最新行业报告针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估以了解哪些行业更适合引入大模型的技术和应用以及在哪些方面可以发挥大模型的优势。5、面试试题/经验【大厂 AI 岗位面经分享107 道】【AI 大模型面试真题102 道】【LLMs 面试真题97 道】6、大模型项目实战配套源码适用人群四阶段学习规划共90天可落地执行第一阶段10天初阶应用该阶段让大家对大模型 AI有一个最前沿的认识对大模型 AI 的理解超过 95% 的人可以在相关讨论时发表高级、不跟风、又接地气的见解别人只会和 AI 聊天而你能调教 AI并能用代码将大模型和业务衔接。大模型 AI 能干什么大模型是怎样获得「智能」的用好 AI 的核心心法大模型应用业务架构大模型应用技术架构代码示例向 GPT-3.5 灌入新知识提示工程的意义和核心思想Prompt 典型构成指令调优方法论思维链和思维树Prompt 攻击和防范…第二阶段30天高阶应用该阶段我们正式进入大模型 AI 进阶实战学习学会构造私有知识库扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架抓住最新的技术进展适合 Python 和 JavaScript 程序员。为什么要做 RAG搭建一个简单的 ChatPDF检索的基础概念什么是向量表示Embeddings向量数据库与向量检索基于向量检索的 RAG搭建 RAG 系统的扩展知识混合检索与 RAG-Fusion 简介向量模型本地部署…第三阶段30天模型训练恭喜你如果学到这里你基本可以找到一份大模型 AI相关的工作自己也能训练 GPT 了通过微调训练自己的垂直大模型能独立训练开源多模态大模型掌握更多技术方案。到此为止大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗为什么要做 RAG什么是模型什么是模型训练求解器 损失函数简介小实验2手写一个简单的神经网络并训练它什么是训练/预训练/微调/轻量化微调Transformer结构简介轻量化微调实验数据集的构建…第四阶段20天商业闭环对全球大模型从性能、吞吐量、成本等方面有一定的认知可以在云端和本地等多种环境下部署大模型找到适合自己的项目/创业方向做一名被 AI 武装的产品经理。硬件选型带你了解全球大模型使用国产大模型服务搭建 OpenAI 代理热身基于阿里云 PAI 部署 Stable Diffusion在本地计算机运行大模型大模型的私有化部署基于 vLLM 部署大模型案例如何优雅地在阿里云私有部署开源大模型部署一套开源 LLM 项目内容安全互联网信息服务算法备案…扫码免费领取全部内容3、这些资料真的有用吗这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理现任上海殷泊信息科技CEO其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证服务航天科工、国家电网等1000企业以第一作者在IEEE Transactions发表论文50篇获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的技术人员这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】