做对话式AI系统这件事我前后折腾了快三年从最初的规则模板到现在的混合架构踩过的坑比很多人见过的方案还多。上一篇聊了整体项目规划和技术选型这篇直接进入实操层面把从零搭建一套对话系统的完整流程拆开讲重点放在那些文档里不会写的细节上意图识别到底怎么设计才不翻车、对话状态管理什么时候该用缓存什么时候该入库、Prompt该怎么写才能让大模型稳定输出、以及上线之后最常出现的那几个鬼问题怎么排查。如果你正准备自己搭一套对话式AI或者已经在路上但被各种怪问题卡住这篇文章应该能帮你省下至少两周的试错时间。1. 整体架构怎么定对话式AI系统的四种姿势先泼一盆冷水不是所有对话系统都需要大模型。我见过太多人一上来就接GPT结果成本高、响应慢、还控制不住输出。对话式AI的架构选择本质上是你在效果上限和可控成本之间做权衡。1.1 规则模板流最朴素但最稳规则模板就是写if-else用正则表达式或者简单的关键词匹配来识别用户意图。比如用户说我要退款你就匹配退款这个词然后走退款流程。这套方案的优点很直接完全可控、零成本、响应速度毫秒级。缺点是脆弱得要命用户换个说法就失灵了。我想把钱拿回来订单不要了这种表达规则根本接不住。但别急着否定它。我现在做的系统里仍然保留了一层规则兜底。原因很简单对于高频的固定场景比如人工客服转人工退出规则比任何模型都可靠。大模型再强在这几个词上也可能理解偏。1.2 检索式对话给知识库加上对话外壳检索式的核心是提前把问答对或者文档片段存好用户提问时用相似度匹配找到最合适的答案返回。这就像你拿着地图找路地图里有的地方你都能到地图里没有的你肯定去不了。这套方案适合知识密集型的场景比如企业内部的FAQ、产品使用手册、政策查询。优点是答案可控、更新方便——知识库内容变了改文档就行不用重新训练模型。缺点是只能回答库里有的东西遇到没收录的问题就抓瞎。做检索式对话关键在两点一是文档切分要合理别把一个完整流程切成七零八落的小段二是检索的召回策略不能只依赖向量相似度关键词权重、标题匹配这些都得考虑进去。1.3 生成式对话大模型时代的默认选项现在聊对话式AI大部分人默认就是生成式。用户输入进大模型模型直接生成回复。好处是理解能力强、表达自然、能处理各种没见过的问法。坏处是容易一本正经地胡说八道而且费钱。用大模型做对话系统真正的学问不在模型本身而在你怎么约束它。这就要用到系统提示词、少样本示例、输出格式约束这些手段。因为我需要反复强调大模型是一匹好马但你不给它套上缰绳它就到处乱跑。1.4 混合架构我现在的主力方案我的主力方案是规则 检索 生成三层混合第一层规则拦截高频固定指令转人工、退出、骂人等第二层检索召回知识库中的标准答案有标准答案的先给标准答案第三层前两层都没命中才交给大模型生成这套架构的好处是80%的常规问题用便宜、快速、可控的方式解决只有20%的开放性问题才动用大模型。成本大概能省一半以上响应速度和稳定性却好了不止一个档次。注意混合架构最大的坑是层级之间的竞争。比如用户问了一个知识库里有标准答案的问题但检索没召回结果落到了大模型那里生成了一个和标准答案不一致的回复。解决方法是给每一层都加上置信度门槛检索结果低于某个阈值才允许下放到生成层。2. 核心模块拆解从意图识别到回复生成不管架构怎么选对话系统的基本模块是固定的。这四个模块我逐个拆开讲每个都说清楚为什么这么做而不是只讲怎么做。2.1 意图识别别一上来就上大模型意图识别的本质是把用户的自然语言映射到一个预定义的目标集合上。比如查询订单修改地址投诉建议就是三个不同的意图。很多新手喜欢直接用大模型做意图分类prompt写一大段让模型判断。但实测下来如果你只有十几个意图传统的文本分类方案——比如微调一个BERT模型或者甚至用TF-IDF加SVM——效果并不比大模型差而且延迟低、成本低、完全可控。我现在的做法是分两级第一级用规则和轻量分类器处理高频意图。比如查订单物流快递什么时候到这些直接用关键词和短句匹配就能覆盖90%。第二级才把复杂意图交给大模型。比如用户说我上周买的东西现在还没到而且那个优惠券好像也没用上这种信息密集、意图混合的句子规则和分类器都搞不定只能靠大模型理解。设计意图体系的时候有两条铁律意图粒度要够用就好不要拆得太细。查询订单和查询订单详情在业务上往往是同一个流程拆成两个意图只会让你多写两倍的训练数据和多处理两倍的边界情况。一定要留一个fallback意图或者叫未知意图。没有这个兜底所有识别不出来的话术都会强行走某个最近的意图那才是灾难。2.2 实体抽取与槽位填充对话系统的填空游戏如果说意图是用户想干什么实体就是用户想干这件事需要哪些信息。拿订机票举例帮我订一张明天去北京的机票——意图是订机票实体是明天时间和北京目的地。实体抽取看似简单实际坑特别多。最大的坑是实体值的泛化问题。比如你只收录了北京上海这些城市名用户说我想去趟西安你的实体列表里没有西安系统就识别不出来。解决思路有两个一是做开放实体识别不依赖预定义的实体列表而是靠模型理解上下文来抽取。比如用大模型抽取出目的地西安即使西安不在你的预设列表里也能通过上下文确认它是一个城市名。二是做实体归一化。比如用户说明儿明天明日这三个词要归一化成同一个日期值。后天下午三点要归一化成具体的时间戳。这一步不做后面的对话状态管理根本没法玩。槽位填充的意思是系统要主动向用户询问缺失的信息。用户说帮我订机票你至少要问清楚去哪里哪天走几个人。这里有一个我之前经常犯的错误一次问太多。用户只说了订机票你一口气问五个问题用户大概率直接流失。正确做法是一次问一个最关键的问题拿到答案之后再追问下一个。2.3 对话状态管理记住用户说了什么对话状态管理是整个系统里最容易被忽视、但崩起来最要命的模块。它的职责是记住用户在这场对话里已经提供了哪些信息还需要哪些信息以及当前进行到流程的哪一步。最简单的实现方式就是用一个本地字典存槽位比如state { intent: book_flight, slots: {destination: 北京, date: 2025-06-15}, current_step: ask_passenger_count }每次用户说话系统更新这个字典然后根据当前步骤决定下一步问什么。但真实场景远比这复杂。用户可能在多轮对话之间插一句等等我改一下时间这时候你要能定位到之前的槽位并更新它。用户还可能在一轮对话里同时提供多个槽位的信息比如明天去北京后天回来你要能一次性抽取并填入多个槽位。多轮对话的上下文窗口管理是状态管理的一个难点。我的经验是对话状态和模型上下文要分开管。对话状态用结构化的数据结构存比如上面的dict模型上下文只保留最近几轮的对话内容。不要把整个对话历史都塞进状态里更不要把状态数据直接拼进Prompt给模型看——两件事混在一起迟早出问题。2.4 回复生成与兜底策略AI也会无话可说回复生成在生成式方案里就是调用大模型在检索式方案里就是返回标准答案。这里重点聊几个生成时的细节。第一回复长度要控制。用户问你们几点上班答案是9点到18点就七个字。有些模型会给出您好感谢您的咨询我们的营业时间为工作日的上午9点至下午18点周末及法定节假日休息请您合理安排时间这种废话。解决方法是明确写出回复不超过20个字直接回答问题不要寒暄。第二回复格式要约束。比如你要返回结构化数据给前端渲染就得让模型输出JSON。最稳妥的做法是像下面这样在Prompt里给一个明确的示例并要求只输出JSON不要有任何其他内容。第三也是最容易翻车的生成内容的安全兜底。如果模型生成的内容包含不当信息或者模型拒绝回答比如用户骂人、问敏感问题你要有预案。我的做法是定义几个固定的兜底回复这个问题我还在学习中建议转人工客服处理。这里涉及一个我强烈建议所有做对话系统的人都做的设计可降级性。大模型挂了怎么办网络超时怎么办API返回乱码怎么办你的系统必须能在模型不可用的状态下自动降级到规则回答或者检索回答而不是直接报错给用户看。3. Prompt工程与知识库接入对话质量的真正分水岭同样的模型不同人写Prompt效果可能天差地别。Prompt工程不是玄学它有一套方法论。3.1 系统提示词的写法让模型知道它是谁、该干嘛系统提示词System Prompt是你在对话开始前给模型设定的角色和规则。一套高质量的提示词至少包含四个部分角色定义你是谁、服务对象是谁。比如你是一家电商平台的智能客服负责解答用户的订单、物流、售后问题。任务边界你能做什么、不能做什么。你只能回答与平台业务相关的问题。超出范围的问题统一回复该问题不在我的服务范围内。输出格式回答的结构要求。优先给出结论再补充说明。不要使用首先其次这类词。如果信息不足先提问。安全约束绝对不能做的事。不要编造订单信息不要承诺赔偿金额遇到投诉类内容转人工。有一个词我特别提醒不要比要更好用。模型对不要做什么的遵从度往往高于要做什么。我在提示词里写了不要编造之后编造率明显下降。3.2 上下文管理别把上下文塞爆大模型的上下文窗口有限你不可能把整段对话历史都塞进去。上下文管理的核心策略是裁剪 摘要。裁剪是说只保留最近N轮对话。我的经验值是业务类对话保留最近5到8轮就够了超过这个范围的对话内容用户自己都说不清模型更不用参考。摘要是说对早期对话的核心信息做结构化提取后保存。比如用户在20轮之前说过我的订单号是ABC123你不需要把原话留在上下文里只要把{order_id: ABC123}存进状态在需要的时候拼进Prompt即可。还有一个细节用户的问题和AI的回答在上下文里的权重是不一样的。用户刚说的这句话权重最高AI自己之前给出的回答反而可以适当压缩——因为模型回答的内容本来就源自上下文重复引用意义不大还白白占token。3.3 知识库检索让AI有据可查对话式AI系统里知识库的质量基本决定了系统的天花板。模型再聪明知识库里没有的内容它也不可能凭空知道。所以知识库的建设和检索值得投入大量精力。文档切分是第一道坎。我之前把一份操作手册按固定字数切成片段结果一个完整的操作流程被劈成两半检索时只召回一半生成的回答自然缺胳膊少腿。后来改成按语义完整性切分每个片段尽量是一个完整的主题单元比如一个操作步骤或一个概念解释。检索增强生成的流程我建议按这个顺序用户问题进来先做改写。比如那个东西咋退改写成如何申请退货改写后的query去检索效果比直接用原话好很多。用混合检索策略。向量相似度 关键词权重 标题匹配三个结果做加权融合而不是只信向量检索。检索到的片段要经过相关性过滤。有时候向量相似度高但语义上根本答非所问这一步需要用更精细的阈值或者二次重排来把关。最后把筛选后的片段拼进Prompt并要求模型严格基于以下资料回答资料中没有的信息不得编造。注意知识库检索最隐蔽的坑是检索命中但不相关。向量检索经常会把形式相似但内容无关的段落捞上来如果你不做相关性过滤模型就会拿着不相关的资料一本正经地乱答。实测下来加上一个简单的相关性重排哪怕只是用模型打分回答准确率能从60%提到85%以上。4. 测试与评估上线前你必须做的三件事对话系统不像传统软件你有没有bug不是能不能跑的问题而是答得对不对的问题。所以测试和评估的方法论完全不同。4.1 测试数据集没有基准一切优化都是自我安慰我见过太多团队用肉眼测几个例子就宣布效果挺好啊。等你把系统交给用户立刻被各种稀奇古怪的问法打脸。正确的做法是从一开始就维护一套测试集。测试集分两类标准测试集覆盖每个意图和每个关键槽位的典型问法用于验证核心流程。每种意图至少20条每个槽位至少10条。对抗测试集专门收集那些容易让系统翻车的说法。比如带错别字的、口语化的、中英文混杂的、指代不清的。这类数据不用多但每条都是宝。我自己的习惯是每次用户实际对话里出现了系统答错的案例就把它加入对抗测试集并且写明期望行为。这套数据的价值会随着时间积累越来越大——你后续做的任何优化都要用这套数据回归验证。4.2 评估指标别只盯着正确率对话系统的评估最少要看三个维度意图识别准确率用户表达了意图之后系统能不能识别对。这个用准确率Accuracy就够了。槽位填充完整率完成一次任务式对话系统是否收集齐了所有必要信息。用任务完成率来衡量。回答质量满意度生成式回答是否准确、完整、得礼貌。这块比较主观建议用规则检查 人工抽样结合。规则检查可以设定几条红线回答中是否出现我不知道、是否编造了具体数字、是否超过指定字数。还有一个我强烈推荐的指标转人工率。如果用户频繁要求转人工说明系统在大量场景下解决不了问题。这个指标越高越说明你的对话流程设计有问题而不是模型效果有问题。5. 常见问题与排查技巧实录最后这部分把我实际运营中遇到的几个高频问题整理出来。这些问题你在任何官方文档里都找不到答案但几乎每个做对话系统的人都会遇到。5.1 高频问题速查表现象可能原因排查方法解决方案用户说转人工但系统没反应转人工是高频指令但意图识别把人工归到了别的意图检查意图识别的分类日志在规则层添加转人工人工客服活人等高优先级规则同一个问题用户换个说法就答错测试集覆盖不足或者检索召回不准把新说法加入对抗测试集跑回归扩充测试集优化Query改写逻辑回答冗长且绕弯Prompt中没有明确回复长度要求查看Prompt配置在系统提示词中加入最多字数限制和先给结论指令大模型超时或报错导致系统崩溃没有做降级处理检查调用代码有无try-except增加超时熔断逻辑模型异常时降级到检索回答多轮对话中用户改了前面的信息对话状态更新逻辑有bug打印完整状态流转日志每次更新槽位时记录旧值和新值做增量更新知识库明明有答案系统却说不知道文档切分不合理检索没召回检索测试检查切分粒度按语义完整性重新切分文档优化混合检索排序5.2 几个值得写进代码里的经验先说状态日志。对话系统的线上问题90%靠日志排查。每轮对话我都强制记录三个东西用户输入的原始文本、当前系统状态、最终输出。这三样一拼出问题的时候能快速定位是哪一环坏了。再说效果优化的节奏。不要指望一步到位。我建议的节奏是先跑通流程用测试集验证主流程能走通然后灰度上线收集真实用户的失败案例每个迭代只解决一类问题比如这周只优化意图识别下周只处理检索召回。贪多嚼不烂一次动太多地方出了问题你连因果链都理不清。最后说一个很多人忽略的点对话系统的体验问题很多时候不是AI的问题是产品设计的问题。比如用户不知道该问什么这其实是引导话术设计的问题。在开场白里告诉用户你可以问我怎么退款、物流到哪里了、优惠券怎么用比任何模型优化都更能提升实际使用率。做对话式AI系统真正难的不是用上大模型而是让用户在有需求的时候恰好能得到他想要的答案。这套系统打磨到最后你会发现最值钱的不是模型权重而是你手里那套持续迭代的测试集、那把定义清晰的意图体系和那些踩过的坑换来的日志排查经验。