这个系列我已经写了四篇前几篇从大模型的基本概念、提示词设计、接口调用一直讲到如何把一个能“聊天”的demo拼出来。但很多人真正卡住的位置其实不是“能不能聊起来”而是“怎么把一个能聊的东西变成一个能交付、能上线、能维护的系统”。第五篇我就集中聊这部分基于 ChatGPT 这类大模型做对话式 AI 和聊天机器人时那些光看文档学不到、不踩几次坑很难明白的事情。下面所有内容都以我实际做过的一个客服机器人项目为底项目代号就叫“某客服机器人”技术选型是大模型接口 规则兜底 知识检索的组合方案。文章里提到的模块、参数、排查思路都是可以直接拿来用的。1. 先想清楚你做的到底是“对话”还是“系统”1.1 从能用到能用住差了什么很多人第一次把 ChatGPT 的接口接进来发现“哇什么都能说”就以为聊天机器人已经做完了。实际上这中间差了整整一个量级。你用一个网页对话框测试时每次对话都是独立的新会话上下文就那几条消息错了重来一遍就行。但真实场景里用户是从公众号、小程序、网页客服、App 多个入口进来的每个人带着前 20 条聊天记录中途可能断线重连机器人背后还挂着订单查询、物流接口、售后规则这些硬逻辑。我见过太多项目死在同一个地方对话能力没问题但没有会话管理、没有用户标识、没有接口超时保护、没有日志追踪。系统一上线用户问一句“我的订单到哪了”机器人调不到订单接口就开始一本正经地编物流信息用户立刻投诉。所以第五篇我先把话放前面你做的不是“对话”是一个带有对话界面的业务系统。ChatGPT 只是其中的大脑但大脑要跟手脚配合才能真正走路。1.2 前四篇铺垫的能力第五篇怎么用起来简单回顾一下系列前面的内容第一篇讲了大模型对话背后的概率生成机制理解“它为什么有时候会胡说”第二篇重点做了提示词编写包括角色设定和约束句式第三篇把 API 调通讲了流式输出与返回格式的坑第四篇引入了多轮上下文管理知道怎么把历史消息塞给模型。第五篇默认你已经具备这些基础能力因为我们要在其上叠加的是工程化问题会话存储怎么设计、日志怎么打、效果怎么测、成本怎么控、模型出错怎么兜底。如果你还没看过前四篇我建议先补一下基础不然下面很多参数和报错会让你看得很懵。1.3 一个严谨的对话系统应该包含哪几层从分层角度看一个可以上线的对话式 AI 系统往细了拆至少有五层接入层负责不同的渠道接入统一会话入口会话管理层管用户ID、会话ID、历史消息、上下文轮次知识与业务层检索知识库、调用业务接口、执行规则模型网关层请求大模型、统一鉴权、超时重试、流式转发数据分析层日志、指标、用户反馈、质检回放前两篇你主要跟第三层的模型本身较劲从第五篇开始你的注意力会往两侧迁移既要往上层看用户体验也要往下层看稳定性和成本。这个转变才是从“做功能”到“做产品”的分水岭。2. 对话机器人主流程的核心模块拆解2.1 会话入口与消息格式的统一真实项目里几乎不可能只有一个对话入口。我那个项目一开始只做了网页版结果领导说公众号也要、小程序也要、企微也要。每个渠道的消息格式千奇百怪公众号带的是图文结构小程序里是 formId企微有消息类型标签。如果让业务代码直接对接每个渠道每次新增渠道都要改一遍会非常痛苦。我的做法是在接入层定义一个统一消息中间对象核心字段包括class UnifiedMessage: channel: str # 渠道标识如 wechat / miniapp / web user_id: str # 渠道侧用户ID session_id: str # 会话ID由我方生成 msg_type: str # text / image / button content: str # 文本内容或者结构化内容JSON raw: dict # 原始消息方便排查所有渠道进来后先转换成这个对象后续逻辑不关心消息从哪来。新增一条渠道只需要写一个适配器把对方的消息模型映射成 UnifiedMessage。这样做还有个额外好处测试的时候可以直接用脚本构造 UnifiedMessage不需要真的打开小程序去发一条消息。02.2 session 和上下文管理决定机器人“记不记得”上下文管理是第四篇聊过的重点这里只说工程化实现。我项目里会话存储选的是 Redis主要看中两点一是 TTL 过期天然适合会话失效场景二是支持 Hash 结构方便按会话维度存消息列表与状态位。我保存历史消息时不是一股脑全存而是分层保存原始消息完整保留用于质检与追溯摘要短句每 5 轮对话后由模型生成一次摘要用来压缩长会话最近 N 轮消息构造请求时直接用超过预算就交给摘要兜底举个例子如果单次请求最多塞 3000 个 token 的历史信息我会倒序取最近 6 轮完整对话比如约 2500 token再用摘要补到预算内剩余约 500 token。这里注意顺序模型的注意力对越靠后的内容越敏感所以完整对话里要优先保留最新的几轮摘要只是为了保持“故事主线”。2.3 知识检索和工具调用要走在模型前面模型自己不知道你公司的库存、价格、退换货规则。所以要在请求大模型之前先完成知识库检索和业务接口动作。我常用的方式是这样的流程用户输入进来先做实体抽取比如订单号、商品名用抽取结果去检索知识库或调用订单查询接口把检索结果和接口返回内容作为“参考信息”拼进 prompt再让模型基于参考信息组织回复这种架构比让模型直接回答要稳得多。因为模型的任务从“凭空想答案”变成了“在规定材料里概括答案”幻觉率会明显下降。知识检索向量化会涉及 chunk 切分和 embedding 选择不细化讲了单说一个原则检索出来的片段宁短勿长条数控制在 3 条以内且每一条都必须带上来源编号便于后期质检。2.4 模型网关给大模型请求加上门槛模型网关是很多人容易漏掉的一层。我一开始也是业务代码直接调接口后来发现权限、限流、重试、模型切换这些逻辑散落在各个服务里非常难维护。后来抽了一个独立网关层职责集中成四个鉴权与配额每个业务线有自己的 key 和用量配额协议转换支持同一套请求结构切换不同模型服务阈值控制包括每分钟请求数、每用户每日请求数重试与熔断幂等请求可以重试触发连续错误就熔断网关不在大而全关键是把所有外部依赖收敛到一个出口出问题时定位更快。某次线上事故一个业务方把温度调到了 0.95 导致接口响应速度骤降最后就是靠网关日志定位出来的那是后话。3. 几个容易被低估的配置细节3.1 系统提示词要分层不要一把梭一个成熟的机器人设置单靠一段几百字的系统提示词是远远不够的。我这边会把系统提示词按模块拼装最后合成一大段发给模型。拼接顺序如下[角色定义] 你是某某公司的智能客服机器人名字叫小X。 [业务规则] 退换货规则、售后时效、违禁词策略。 [行为约束] 不能编造订单信息、不能承诺赔付金额、不能脏话。 [对话指南] 用户情绪激烈时先安抚、再给方案无法回答就转人工。 [参考信息] 本次请求检索到的知识片段与业务接口返回。为什么要分开维护因为每一类内容的更新频率完全不同。角色定义可能半年不变业务规则要跟着运营活动频繁改安全约束则是任何时候都不能动的底线。混在同一个提示词文件里改一次规则就可能误伤安全内容出事了排查也麻烦。拼装的时候要注意 token 预算。我在项目里给系统提示词留了 1200 token超过就会被截断。截断顺序也有讲究业务规则最先被截其次是参考信息角色定义和行为约束永远保留。毕竟“不能编造信息”这类安全约束一旦被截整个机器人就会开始裸奔。3.2 温度和 top_p 不是越高越好很多新手以为温度调高一点机器人更“像个真人”于是把 temperature 设到 0.8、0.9。实际上在客服场景这个操作非常危险。温度高意味着每次回答的随机性大同样一个问题上午回的和下午回的可能不一样用户就会觉得机器人口径不一致甚至怀疑是不同人在值班。我的经验是客服、FAQ、订单查询temperature 0.2 左右闲聊陪伴、故事生成temperature 0.7 或 0.8内容总结、信息抽取temperature 0top_p 我现在很少单独调一般固定 0.9。保持默认 1 也不是不行但遇到长文本生成把 top_p 调到 0.9 能明显减少输出杂音。这两个参数要配合调而不是同时加大。文档里有个小坑不建议两个参数一起改容易互相打架我实践下来也确实如此。3.3 输出长度与成本是同一件事对话式 AI 的成本大头在 token。输出长度 max_tokens 设置错了既影响体验也多烧钱。很多人为了保险把 max_tokens 设到 2000结果一句“您好请问有什么可以帮您”也要等模型生成很久因为模型在给自己“留后路”。更惨的是过长输出被中间截断用户看到半句话。我的做法是区分场景FAQ 类回复 max_tokens 设到 300复杂分析类设到 800代码生成或长文总结另外单独开接口。不能一个参数走天下。另外输出长度直接影响延迟输出 token 越多响应越慢。用户等 3 秒还能接受等 10 秒就会直接关掉页面。3.4 超时、重试与降级一个都不能少大模型接口再稳也有抖动。真实情况里我遇到过某段时间服务商限流每次请求都报 429也遇到过网络抖动单次请求延迟从 1 秒飙到 30 秒。如果代码里没有超时控制客服机器人就会变成卡死状态。我的超时策略固定成三级连接超时3 秒整体请求超时10 秒非流式流式首包超时5 秒重试策略用指数退避第一次失败等 1 秒重试第二次等 2 秒第三次等 4 秒最多重试 2 次。超过重试次数就触发降级降级到规则引擎或 FAQ 精确匹配。绝不能连续无限重试否则雪球越滚越大把后面的正常请求全拖垮。4. 效果评估怎么量化一个“会聊天”的系统4.1 别信感觉要建评测集很多团队测试对话机器人就是点开对话框问几句“嗯回答得不错可以上线”。这种测法最大的问题是样本量太小、没有对照。你今天问“怎么退货”明天问“你们几点下班”感觉都正常但用户不会按你的测试脚本提问。我项目里建了一个离线评测集格式非常简单可以放进 Excel也可以存 JSON[ { case_id: C001, question: 你们家的运费是买家出还是卖家出, expected_keywords: [商家承担, 包邮, 免运费], expected_label: positive, context: 用户来自限时秒杀订单页 } ]每个测试 case 里不只存问题还存了期望关键词、期望情绪、上下文场景。为什么存这么细因为同一个问题在不同场景下的正确回答不同。“运费谁出”这个问题秒杀商品和生鲜商品的政策就不一样评测时不对齐前置条件就没法判断模型的回答对不对。评测集维护到 300 条以上才开始有参考价值。每轮模型更新我都先离线跑一遍评测集对比新版本和旧版本的回答正确率。只有离线评测过了才敢放到线上灰度。这个流程跟传统软件里的回归测试很像只是断言谓词从“是否等于”变成了“是否符合关键词与约束”。4.2 在线评估指标不要只看准确率离线评测看的是模型能力上限在线评估看的是系统真实表现。我常用五个指标转人工率机器人解决不了用户主动要求转人工用户流失率用户对话中途离开且超过 30 分钟未回会话时长正常问题应该在 1-3 分钟内解决过长说明绕弯子重复提问率用户问同一个问题超过三次说明上次没答明白负面反馈率用户点了踩、给了差评或者输入了负面情绪词这五个指标里我最看重“重复提问率”因为它直接反映用户是否真正获得答案比模型回答的“流畅度”真实得多。有一次我们上下线新版提示词离线评测准确率升了 5%但重复提问率飙升后来发现是新版提示词里加了太多套话用户根本找不到重点。4.3 用模型当裁判但要设计好评分标准人工评测 300 条用例太累了后面我引入了大模型评委即“用一个模型来给另一个模型的回答打分”。这个方法现在已经很常见但很多人用得糙直接写一句“请你判断以下回答是否准确”打分效果一塌糊涂。我的裁判 prompt 会包含四个评分维度事实准确性、完整度、友好度、合规性。每个维度 1-5 分各自有明确描述。比如事实准确性的 5 分标准是“回答全部来自参考信息没有额外编造信息”3 分标准是“存在部分编造但不影响核心结论”。没有这种颗粒度的评分标准大模型评委很容易变成“给满分的老好人”。裁判模型也会犯错。我一般让裁判模型输出 JSON 格式的评分结果并附理由每周抽 30 条评分结果让人工复核把复核结果再反馈给评分标准持续迭代裁判 prompt。这个方法在项目里跑了两周评分稳定性明显提升。4.4 线上环境要留“后门”效果评估不能等到问题爆发才做。我给系统设了几个线上后门灰度开关、白名单用户、一键回滚。每一次 prompt 更新或模型版本切换都先让 5% 的流量试跑观察 24 小时核心指标。白名单用户则固定是团队内部人员上线任何改动前让内部人员先用新版本聊几十轮比什么测试都直观。灰度不是简单地把流量切一部分过去要保证同一个用户始终命中同一个策略版本否则用户上一句用的是旧逻辑下一句切到新逻辑上下文会产生严重割裂。我的实现是给会话打 bucket 标签按 user_id 哈希取模这个哈希维度在网关层统一控制保证会话期间版本一致。5. 常见故障与排查实录5.1 模型开始一本正经地胡说八道幻觉是这个领域的老大难。有一次我们的客服机器人被用户问“你们会开发票吗”系统没检索到发票相关信息模型就自己编了一个“满 100 元可以开发票”的回答。用户很生气因为在订单备注里根本没有这个规则。排查之后发现根因是知识检索条数设的是 5 条但相关度都不高模型把所有内容都当成了可参考依据再加上没有“查不到就直说不知道”的护栏。解决方案有三步检索 topK 降到 3并加最低相似度阈值低于阈值直接判定无相关知识提示词中强制声明“如果参考信息中不存在答案必须回答无法确认并建议转人工”输出后增加轻量校验比如用正则匹配“发票≈相关关键词”模型没给出参考信息里的关键信息时触发补充追问效果非常明显幻觉率从早期的 12% 下降到了 3% 左右。5.2 用户翻旧账机器人把前面的回答忘了上下文管理最容易出问题的点是“用户突然问一个之前提过的问题”。比如用户 10 分钟前说“我要退一件衣服”中间聊了一堆别的事然后突然冒出一句“那我现在怎么操作”如果系统只把最近 5 轮消息发给模型模型根本不知道用户指的是“退款操作”会回答成“你问的是什么呢”。我们的解决方式是上下文摘要快照。每当累计对话超过 8 轮就让模型生成一段不超过 150 字的摘要存入会话状态。用户翻旧账时摘要能提供一个粗粒度记忆。但摘要也有副作用它会丢细节。比如订单号藏在第 3 轮摘要里可能只写了“用户要退款”没有订单号。所以更稳的做法是额外维护一个“关键信息表”在每轮对话里抽取订单号、商品名、金额、用户诉求存成结构化字段。这个关键信息表会在构建请求时作为额外上下文塞给模型。模型看到的不是第 3 轮原文而是一段简单的“本会话关键信息订单号 PO123456商品 红色卫衣用户申请退款运费 10 元”既节省 token 又精准。5.3 响应突然变得很慢排查起来一头雾水慢的问题比错的问题更难查因为慢的原因太多。我经历过一次比较典型的线上延迟事故现象就是用户发送消息后 15 秒才收到回复。排查链路是接入层日志显示消息到了但模型网关日志显示业务请求过了 8 秒才进来于是定位到问题出在我们自己的服务端不在模型厂商那边。进一步看发现是我们某个服务把历史消息从 Redis 里取出来后做向量检索而向量库那台机器 CPU 爆了因为检索接口的每日调用量翻了一倍数据库连接池被打满。最后用三招解决给向量检索接口加独立限流把向量库的读连接池从 20 调到 60超过排队直接快速失败历史消息全文检索改走 SQL 兜底不做向量召回。好了之后P95 延迟从 11 秒降到 2.4 秒。遇到慢问题第一反应不是去换模型而是先看自己的日志。大模型接口延迟再不稳定十有八九的“慢”都是中间链路自己拖的。5.4 月底一算费用整个人都不好了费用失控是新手团队最容易忽略的问题。我见过一个小团队上线第一个月模型费用跑了小十万一问才知道他们把每次会话的完整历史都拼进去而且还给每个用户开了高温度低缓存的配置。控制成本我总结出五个手段会话历史用摘要压缩而不是无脑塞全文高频相似问题走缓存相同问题 24 小时内直接命中统一答案不走模型无关闲聊单独用小模型兜底分诊识别后再路由到大模型输出长度按场景精确控制给每天的费用设熔断线达到阈值自动限制高消耗账户缓存这块是省钱大头。客服场景里常见问题其实非常集中前 100 个问题可能覆盖 60% 的进线量。把这些问题对应的标准答案缓存下来既省了费用又让响应时间变得极短。唯一要注意的是缓存答案不能当成永久答案业务规则一变就要主动失效缓存。5.5 转不了人工用户情绪炸了客服机器人永远逃不开“转人工”设计。第一个版本我只做了一个简单逻辑——用户说三次“人工”就转接。结果用户说“我要找真人”机器人答“好的正在为您转接”然后系统里压根没有转人工通道体验瞬间崩掉。后来我把转人工做成一套完整的策略用户主动要求转人工、识别到负面情绪词、连续两轮未能解决问题三种条件都会触发转接。转接时把整个会话摘要和关键信息表自动附带给人工客服人工客服打开工作台就能看到用户刚才问过什么、机器人给过什么方案。这个设计极大减少了用户的重复描述成本也让人工客服对机器人的信任度上升了不少。6. 持续迭代从版本管理到反馈闭环6.1 提示词也要做版本管理很多人维护提示词靠复制粘贴改了几版之后根本不知道线上跑的是哪份。提示词和代码一样必须进版本管理并且每个版本都要配自己的评测结果。我现在规定 prompt 改版必须走三个步骤修改后先离线评测再灰度 5% 流量跑 24 小时最后全量发布并记录变更日志。变更日志记录得更细改动了几行、影响了哪些场景、评测集通过率是多少、灰度期转人工率变化是多少。这些记录是系统优化最重要的资产比代码库里的注释更有价值。6.2 用日志搭建一条可回放的时间线对话机器人的调试最怕的就是“用户说了一句什么机器人回了一句什么然后呢”没有日志你只能靠用户截图还原现场效率极低。我的日志结构长这样{ trace_id: abc123, session_id: sess_001, user_id: user_001, channel: miniapp, question: 你们能开发票吗, retriever_results: [ {chunk: 发票规则第一章, score: 0.82} ], prompt_used: ...完整拼好的prompt, model_response: 可以的满100元可以开具电子发票, latency_ms: 1800, token_usage: {prompt: 520, completion: 120}, confidence: 0.91 }有了 trace_id用户投诉时可以一键拉出完整链路。日志不只用来排查故障也是评估小费的重要组成部分。上线初期我每天都会花半小时随机挑几条日志看模型有没有语气生硬、答非所问、关键信息遗漏这样的手动巡检比看任何指标都直接。6.3 用户反馈闭环不只是点踩和点赞用户主动点踩的比例非常低绝大多数人遇到问题会直接关闭页面。所以我还用了一个隐性反馈信号输入纠正。比如用户先问“订单号码是什么”机器人答了订单状态用户又追了一句“我是问怎么查订单号”这里就存在一个隐性的“上一轮回答不匹配”信号。我会把这些场景单独捞出来归入 low_satisfaction 池每周人工复核一次。低满意度样本池越攒越有价值。它不只是质量问题清单更是提示词改版方向的来源。有一次我们发现很大比例的低满意度样本都集中在“物流赔付”这个问题上于是专门给系统提示词补了赔付规则的详细说明下一次评测集命中率直接从 71% 升到 89%。6.4 承认边界模型负责聪明系统负责稳定做到最后你会发现再强的模型也没法保证 100% 正确。对话机器人的根本设计思路不是追求“每一句都完美”而是“错误不致命用户有路可退”。我项目里最后保留了三层防线模型回答后先经过规则引擎的违禁词和低置信度拦截拦截后转搭好的兜底策略兜底答不了就走人工工单工单也处理不了就把会话转移到人工优先队列。这个设计里每个环节都有不可替代的职责模型是其中很重要的一环但绝不是唯一的一环。这个项目的经验说到底是这么一句话ChatGPT 赋予了对话机器人惊人的上限而真正决定产品能不能信得过的是下限工程。前四篇帮你把上限抬高第五篇这些内容是为了让你不用时刻盯着下限发愁。如果你正准备把一个对话式 AI 项目推上线我个人最实在的建议就是先拿一周时间补齐日志、降级、评测集这三件事然后再去调模型参数你会发现后面顺利很多。