帮我订一张明天从北京到上海的高铁早上8点左右二等座。这一句话系统要完成20个步骤先判断你是要订票还是查班次判断错了就返回时刻表而不是付款链接再识别出北京指的是北京南站不是北京站高铁主要从南站发车再把早上8点左右解析成06:00到09:30这段时间范围……任何一步出错要么系统多追问你两轮要么给你订了一张退不了的错票。我见过的大部分初版订票 Agent这条主流程有5到6个环节是错的最后能端到端跑通的不超过一半。这篇把三条链路里最容易出问题的20个概念用这次订票请求逐个解释。不讲公式不背定义每个概念直接对到一个真实的产品设计场景。01PART意图需求评审时说要做意图识别开发问你意图清单在哪你说就是判断用户想干嘛这不是意图清单这是废话。没有明确列出来的意图清单开发根本不知道系统要支持哪些功能。意图就是系统给用户这次操作贴的标签。不是 AI 猜出来的是你提前定好的。订票是一个意图退票是另一个系统要做的就是判断用户这句话对应哪个标签。订火车票 Agent 的意图清单通常是这五个订票下一张新票查询车次看有哪些班次退票已购票申请退款改签修改已购票的日期或车次问政策问儿童票、学生票、退改签规则等用户说帮我订一张明天从北京到上海的高铁落到订票意图。这个清单很重要没有它开发不知道要做什么运营也没法按意图维度统计转化率和投诉原因。意图清单的颗粒度是产品设计阶段最重要的决策不是技术问题是业务问题。粒度太粗订票和改签混成一类出了问题追不到原因粒度太细每个意图的训练样本太少模型训不好。02PART意图识别同样是想订票用户可能说帮我订一张高铁票也可能说明天我得去趟上海第二种说法没有订/买/票这些关键词靠关键词匹配根本抓不到。识别机制不对一半的真实用户进不了主流程。意图识别就是让系统自动判断用户这句话属于哪个意图。本质是一个分类问题输入一句话输出一个意图标签和一个置信度分数。三种做法关键词匹配。写规则订/买/预订 匹配订票意图退票/退掉 匹配退票意图。好处是简单快坏处是说法稍微变一下就抓不到而且容易误命中不退理由 也会命中退票规则模型分类。用一个专门训练过的语言理解模型做分类明天我得去趟上海这种隐式表达也能识别需要标注数据大模型判断。直接把用户输入喂给大语言模型让它判断意图不需要训练但速度慢、成本高适合长尾场景或刚起步阶段高频场景比如订票通常的选择是模型分类做主力关键词规则兜底大模型处理没见过的长尾说法。三者分开用别指望一个方案全搞定。03PART置信度用户说明天去上海的高铁没有说要订也没有说要查。系统该执行订票流程还是返回查询结果如果置信度只有55%就直接下单用户拿到付款链接会一脸懵。置信度就是模型对自己判断结果的把握程度范围0到1。1是完全确定0是完全不知道。模型看到明天去上海的高铁这句话可能会给出这样的判断订票0.55查询车次0.38其他0.07结果取最高值是订票。但0.55意味着模型只有55%的把握剩下45%可能是别的意图。这种情况不该直接执行应该追问请问您是要购买车票还是查询班次信息置信度多高才算够要看这个意图出错的代价意图建议阈值原因订票≥0.85 才执行最终会扣钱出错代价高查询车次≥0.60 就执行只返回信息没有副作用问政策≥0.60 就执行信息展示类错了再补就行这不是技术参数是产品决策。同一个置信度订票场景偏保守查询场景偏激进这个阈值你要在需求里写清楚。04PART未知意图用户在订票过程中突然问从北京到上海大概几公里这不是用户跑题是系统根本没有准备过距离查询这个意图所有意图的置信度都压得很低系统不知道怎么接。OODOut-of-Domain域外问题就是用户问了一个系统没有预定义意图的问题。不是用户说错了是系统没有这个功能但用户不知道。订火车票 Agent 里OOD最常见的三种来源超出产品边界用户问北京到上海的距离、城市天气、沿途景点新出现的需求比如电子学生证推出后用户问电子学生证能买学生票吗以前没有这个问题模糊表达“明天的事帮我处理一下”置信度被几个意图分摊都不高四种处理方式兜底回复。“没听明白您要做什么目前我可以帮您订票、查询、退改签”追问澄清。给候选意图让用户选是要订票还是查询转人工。复杂问题和高价值用户路由到人工大模型兜底。接通用大语言模型直接回答北京到上海约1300公里再引导回订票主线OOD 数据是下一个版本的选题库。如果一周内有几百个用户都在问距离那下一版就该新增距离查询意图把它变成系统能处理的正式功能。05PART实体订票意图识别对了系统知道要订票但订哪天的、从哪到哪、什么车型、什么席别这些具体参数怎么知道靠实体提取。意图是做什么实体是用什么做。实体就是从用户输入里提取出来的有用信息片段是执行意图所需要的参数。“帮我订一张明天从北京到上海的高铁早上8点左右二等座”这句话里包含的实体通用实体不分行业都有的时间明天、早上8点左右地点北京、上海领域实体订票这个行业特有的车型高铁席别二等座我见过太多团队意图识别投了80%的精力实体识别就用通用预训练模型一刀切结果高铁和二等座这种领域特有的词根本识别不出来订票流程在第一步就卡死了。问答助手里绝大多数关键实体是领域实体必须自定义词典或做领域专项训练不能指望通用模型自动搞定。06PART命名实体识别NER实体的概念明白了接下来的问题是系统怎么从一段话里找出这些实体不是人工标注是要让机器自动识别。这件事就叫NER。NERNamed Entity Recognition命名实体识别就是让系统自动从文字里找出哪些词是实体、分别是什么类型。输入“帮我订一张明天从北京到上海的高铁”输出明天 → 时间实体北京 → 地点实体上海 → 地点实体高铁 → 车型实体帮/我/订/一/张/从/到/的 → 不是实体忽略NER本质上是给文本里的每个字打标签然后把连续相同标签的字合并成一个完整实体。这是整个信息提取流程的第一步这步没做好后面全是空架子。订火车票 Agent 里的NER通常分两层先用通用模型识别明天这类时间词和北京、上海这类地名再加领域专项处理来识别高铁、二等座这类业务词。两层不分领域实体识别能力会很弱。07PARTBIO 标注体系NER识别出实体了但计算机在内部是怎么表示明天是时间实体北京是地点实体的靠的就是BIO 标注一套给每个字打标签的规则。BIO是NER模型内部的标注方案用三种标签标记每个字BBeginning实体的第一个字IInside实体里除第一个字之外的其他字OOutside不属于任何实体的字用帮我订明天从北京举例明是时间实体的开头打 B-时间天是时间实体的后续字打 I-时间。系统从左到右扫把连续的 B-I 合并成一个完整实体这就是明天这个时间实体被识别出来的底层过程。产品侧不需要熟练掌握这套规则但要知道如果上线后发现实体识别出来的边界不对比如北京南站被切成了北京南站两段问题大概率在这层的标签预测出了错让算法同学从日志里查标签就能定位。08PART实体边界识别“早上8点左右”是一个整体的时间实体还是早上8点左右三个独立的词切法不同后续系统能不能查到对应班次完全不一样。实体边界识别就是确定一个实体从哪个字开始、到哪个字结束。听起来简单但这是NER里最容易出错的环节。订票场景里最典型的边界歧义早上8点左右应该识别为整体一个时间范围06:00 到 09:30不能切成早上8点两段北京南站是一个完整站点实体不能切成北京南站两个词上海虹桥是一个完整站点不能拆成上海虹桥边界识别错了是系统性影响实体错了归一化出来的结果是错的拿去查接口得到的是错的用户最后看到的班次全跑偏。用户说早上8点左右系统给出晚上8点的班次就是这个环节失败的典型结果。产品侧能做的是设计槽位的时候把每个槽位期望接收的实体边界规则写清楚跟 NLP 工程师提前对齐不要等上线了再被用户帮你测出来。09PART嵌套实体用户说从北京南站出发系统既要识别北京城市又要识别北京南站站点但这两个实体有重叠北京这两个字同时属于两个实体。这就是嵌套。嵌套实体是一个实体里包含另一个实体的情况两者共享部分文字。订票场景需要精确到站所以这里的处理逻辑是优先保留外层北京南站同一个城市可能有多个站订票必须精确到站名北京这个城市名只在没有外层时才用。标准BIO体系每个字只能打一个标签没法同时标注内外两层。常见处理方案只保留外层实体订票场景最常用的选择实现最简单按粒度分两层处理先识别大实体再识别小实体精度高但实现复杂用专门处理嵌套的模型精度最高工程成本也最高时间表达里嵌套也很常见明天早上8点左右就是三层明天日期 早上时段 8点左右大概的精确时间。处理不好归一化出来的时间段会出错。10PART实体歧义用户说从北京出发北京到底是哪个北京北京站、北京南站、北京西站、北京朝阳站四个站名里都有北京但用户只要一个。这就是歧义。实体歧义是同一段文字对应多种可能实体的情况是实体识别里最难处理的问题。订票场景里的三类歧义类型歧义同一个词可以是不同类型的实体。北京既可以是城市地点实体也可以指北京站站点实体。边界歧义同一段文字可以切成不同的实体。北京南站如果切成北京南站南站没有意义必须整体识别。指代歧义用户说订那班车那班车指的是上一轮推荐的G1还是G3多轮对话里最常遇到。歧义本身不是错误是语言的自然属性。系统要做的是检测到歧义然后用上下文消解或者追问澄清不能假装歧义不存在直接随便给用户订一个。11PART实体消歧用户说从北京出发系统发现有歧义下一步不是直接弹一个站点列表让用户选。先用上下文推一推能推断出来就不要追问追问多一次转化率就掉一截。实体消歧就是在发现歧义后利用上下文把候选答案缩小到唯一一个的过程。两种消歧方式利用当前句子消歧用户说的是高铁那北京大概率指北京南站高铁 G/D 字头主要从北京南站发车用户说的是普速列车那北京更可能是北京站利用对话历史消歧第一轮用户说了订高铁第三轮说改个时间从北京出发北京继承上文还是北京南站用户上次订的是北京西站出发这次再说从北京出发可以优先匹配北京西站消歧的优先顺序先查对话历史信号最强再看当前句子上下文两个都推不出来再追问。能消歧不消歧直接追问是懒设计。12PART实体归一化用户说明天的高铁系统识别出明天和高铁这两个实体直接拿着这两个词去查12306接口必然查不到。12306只认日期格式2026-04-28只认车型代码不认明天和高铁这种自然语言。实体归一化就是把用户说的话转换成系统能直接处理的标准格式。这次订票请求的归一化结果用户原始表达归一化后明天2026-04-28早上8点左右06:00 ~ 09:30北京北京南站站点代码BJP2上海上海虹桥站点代码AOH高铁G字头车型同时包含D字头动车二等座席别代码M时间归一化是订票场景里最复杂的子问题。明天、后天这类相对时间需要结合当前系统时间计算早上8点左右这类模糊表达要转化为时间范围下下周五这类复合表达需要分步解析。归一化做差了12306接口返回空结果用户看到的是没有符合条件的车次但其实是系统查的东西根本就不对。13PART实体链接归一化只是把语言变成了结构化参数但参数还得对应到12306数据库里真实存在的车次和余票。拿着参数去找真实数据这一步叫实体链接。没有它参数再标准也只是数字不能用。实体链接就是把归一化后的参数对应到数据库或知识库里具体存在的真实条目。参数包2026-04-28BJP2AOH06:00到09:30席别M→ 调12306余票接口 → 匹配到三个候选车次G106:12发车二等座余票327张G307:00发车二等座余票156张G708:08发车二等座余票89张链接成功才有下一步把这三个车次展示给用户选。链接失败有两种情况没找到那天没有符合条件的班次走OOD或追问找到多条但用户没说选哪条展示列表必须追问不能随机选一个直接下单。12306接口返回的余票是几秒前的数据用户真的点下单时可能已经卖完。所以订票这类系统实体链接成功后还要在最后一步再查一次实时余票确认下单时候还有。这不是AI的问题是数据源的问题要在产品设计时预留这个校验步骤。14PART槽位意图识别出来了实体也提取并归一化了但订票还差临门一脚乘客是谁、身份证号是多少这些信息不在用户第一句话里但不知道就没法下单。系统需要一个框架来定义订票这件事需要哪些信息这就是槽位。槽位就是意图执行所需的参数容器提前定义好完成这个意图需要哪些信息。实体是提取出来的值槽位是等待被填入的格子。订票意图的完整槽位定义槽位[出发日期]必填缺失追问接受时间实体槽位[出发站]必填缺失追问接受站点实体槽位[到达站]必填缺失追问接受站点实体槽位[席别]必填缺失用默认值二等座接受席别实体槽位[乘客姓名]必填缺失追问接受人名实体槽位[身份证号]必填缺失追问接受证件号实体槽位[出发时间偏好]选填可忽略接受时间范围实体槽位[车型偏好]选填缺失默认全部接受车型实体每个槽位要定义三件事必填还是选填、缺失时怎么处理、接受什么类型的实体。这些在写需求文档时就要写清楚不是开发阶段再讨论的事。15PART槽位填充实体识别出来了槽位也定义好了但怎么知道明天该填进出发日期槽位而不是到达日期槽位北京该填进出发站而不是到达站这个匹配过程叫槽位填充。槽位填充就是把识别并归一化后的实体按规则填入对应的槽位。帮我订一张明天从北京到上海的高铁早上8点左右二等座这一句话填充结果8个槽位6个填上了2个必填缺失。系统不能直接下单必须先追问乘客信息。填充要保证两件事类型匹配手机号实体不能填进出发站槽位位置唯一北京南站只能填进出发站不能同时填进到达站。看起来基础但系统设计不严谨时靠字符串顺序判断出发到达的方案用户说从上海到北京就会反过来订。16PART槽位验证乘客姓名和身份证号都填进来了看起来可以下单了。但12306不允许跳过验证必须确认姓名和身份证号是真实匹配的否则下单到一半被接口拒掉用户体验崩。槽位验证就是对已经填充的槽位值做合法性检查确保这个值能被后续业务正常处理。订票场景的两层验证格式校验不用调后端本地规则就能判断身份证号是否18位最后一位校验码是否正确出发日期是否合法是否早于今天出发站和到达站是否相同不能自己到自己业务校验需要调后端服务用12306实名认证接口验证姓名和身份证号是否真实匹配检查目标车次该席别是否还有余票从查询到下单这几秒可能已经卖完检查乘客是否已经在同一车次买过其他席别一人一座规则格式校验失败提示用户重新输入业务校验失败要区分原因告诉用户怎么办实名不匹配让用户检查输入没余票让用户改席别或改时间已购买过让用户去查已有订单。17PART槽位触发追问乘客姓名和身份证号缺失了系统该怎么问这里有设计的讲究问得不好用户直接放弃订票。槽位触发追问就是必填槽位缺失时系统主动开口要这个信息的机制。追问设计直接影响订票完成率。三个原则说清楚要什么。不要说请补充信息要说请提供乘车人姓名。乘客信息是泛词姓名才是具体的字段用户照着说就行。一次只问一个。当前缺乘客姓名和身份证号两个槽位先问姓名用户回答后再问身份证号。一次问两个用户大概率只答一个系统还得再追一轮效率更低。有记忆不重复问。用户在第二轮提供了张三第三轮系统不能再问请问您叫什么名字。槽位填上就是填上了当前会话内不重置。做了很多对话设计评审一次追问多个槽位是最高频的问题。很多团队知道要问清楚但没意识到次数要控制。订票追问超过三轮完成率会断崖下跌用户直接关掉。18PART多轮槽位积累用户第一句话提供了6个槽位的信息第二句补了姓名第三句补了身份证号。三轮对话这个订票的进度需要一直保存在系统里不能每轮都重新开始。多轮槽位积累就是跨多轮对话把槽位逐步填满的机制每一轮的新信息都累积到同一个订单的槽位状态里。这次订票的完整三轮流程实现多轮槽位积累的核心是保存当前会话每个槽位的填充状态每轮新的用户输入先匹配未填槽位而不是重新识别意图意图不变的情况下槽位状态持续累积不重置。当意图在多轮中发生切换时用户突然说不订了帮我查查有哪些班次系统要判断保留还是清空原有槽位。订票切到查询可以保留出发地、到达地、日期订票切到退票所有订票槽位必须清空。19PART槽位冲突用户在第3轮看到车次列表后说其实我要一等座席别槽位从二等座被覆盖为一等座。系统要识别出来并处理不能假装没看到也不能静默覆盖用户不知道修改是否生效。槽位冲突是用户在同一次对话里给出了前后矛盾的槽位值系统需要判断用哪个。两种冲突来源用户主动修正“其实我要一等座”、“改成后天吧”明确的覆盖信号前后不一致第一轮说从北京第三轮又说从北京西站系统要判断是同一个地方的细化继续用还是换了个站重新处理处理原则低风险槽位直接用新值。席别从二等座改一等座直接覆盖明确告诉用户已更新为一等座正在刷新车次列表。不要静默覆盖用户要知道修改生效了。高风险槽位先确认再覆盖。改出发日期会触发新一轮余票查询和价格变化系统先说已为您切换为后天的车次原订单信息将清空是否继续得到确认才执行。20PART冷启动意图订火车票 Agent 上线第一天没有任何用户对话历史意图识别模型怎么训练高铁、二等座这些领域专有词从哪来开发说没数据没法训产品说没系统没有数据陷入死循环。冷启动就是系统在完全没有历史数据的情况下怎么让意图识别链路先跑起来。四步走Step 1规则先行整理订票领域的关键词词典订票/买票/预订 匹配订票意图退票/退掉 匹配退票意图顺便把所有站点名整理成词典12306全量站点大约3000个席别枚举完整。规则可以保证核心路径不出错但说法稍微变一下就抓不到。Step 2种子数据加扩充每个意图人工写20到30条典型话术“明天去上海/帮我订张高铁/预订一下后天的票”用同义词替换和改写扩充到100条以上训练一个小样本意图分类模型。这一步很多团队卡住写30条容易但写得覆盖用户真实说法很难。最有效的方法是找5个真实用户问他们会怎么说我要订票这件事。他们说出来的话术比任何技术手段增强出来的都管用。Step 3借用预训练模型市面上有很多已经在大量中文文本上训练过的语言理解模型BERT是其中一类它们自带基础的语言理解能力。直接在这类模型上用你的100条数据做微调效果比从头自己训练要好得多数据需求少一个数量级。别从零开始站在别人的肩膀上。Step 4大模型零样本兜底把用户输入直接发给大语言模型问它这句话是要订票还是退票还是其他不需要任何训练数据直接能用。速度慢、成本高适合用来处理前三步覆盖不到的长尾说法或者验证这个场景到底走不走得通。把冷启动的目标和稳定运行的目标混在一起是很多团队第一天就卡死的原因。第一天不需要90%准确率先把订票这条主流程跑通有真实流量了再迭代。先活着再变好。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】