做对话式AI搭建系统这件事我从前年年底开始碰最早就是拿现成的模型API写个问答demo后来慢慢做成带知识库、多轮记忆、能对接企业数据的完整系统。中间踩的坑比写代码的时间还多所以这篇想认真聊聊整个流程和避坑经验。这是系列的第二篇重点讲“从零搭一套能用起来”的对话式AI系统要经历哪些阶段每一步卡住你的通常不是模型本身而是工程细节。适合谁看准备做智能客服、知识库问答、私人助理这类应用的开发者或者刚接到任务要在公司里落地对话式AI产品的朋友这篇能帮你省掉几轮返工。1. 动手之前先把需求边界和系统架构想清楚1.1 需求边界你的对话式AI到底是做什么用的很多人上来就找模型、写Prompt做了几天发现方向不对。对话式AI看着都是“聊”实际场景差异很大。我一般把需求分成三类闲聊陪伴型。目标是聊得自然、有趣对准确率要求低但对人设、语气要求高。知识问答型。目标是给用户准确、权威的信息依赖知识库、文档检索最怕模型一本正经地编。任务执行型。目标是完成具体操作比如查天气、下单、查工单、回工单必须对接业务API还要处理多轮里缺失的参数。这三类系统的复杂度完全不在一个量级。闲聊型拿一个开源模型改个Prompt就能跑知识问答型需要做检索增强重点变成文档解析、召回、引用溯源任务执行型则是套完整的对话管理框架要把意图识别、槽位填充、业务接口调用串起来。我的建议是开工前先列一份用户问题清单找真实用户聊一聊至少三五条最典型的对话样例再判断系统属于哪一类。还有一种常见情况是需求方说“我要一个智能助手”但具体问题全都没定义。这时候别急着设计架构先花一周时间收集真实场景里的对话数据、用户问题、现有客服记录越具体越好。你拿到的颗粒度决定了系统能做到什么程度。1.2 分层架构不搞复杂但这几层必须有对话式AI系统再简单工程上也至少分四层交互层、对话编排层、模型服务层、数据层。我见过不少项目把Prompt、逻辑、模型调用全写在同一个方法里demo阶段没问题一旦要加一个新功能就要改一大片所以分层不是炫技是给自己留活路。交互层负责对话框、打字机效果、多轮消息展示纯粹的前端问题。对话编排层是整个系统的大脑它负责接住用户消息、管理上下文、调用模型、决定要不要触发知识检索或者业务API同时把模型返回内容整理成最终回复。模型服务层把具体模型供应商或部署方案隔离起来统一对外提供完整的请求接口。数据层则管用户信息、会话记录、文档向量库、业务系统数据。我第一次搭系统时省掉了对话编排层直接把前端的请求原封不动转发给模型结果加一个字数限制、加一个敏感词过滤都要改前端代码。后来重构花了整整三天。分层会让前期代码多一些但后面加功能你会感谢自己。最小可用版本不需要所有层都做得很重但接口路径必须清晰。2. 模型选型与接口接入第一个容易翻车的地方2.1 模型怎么选托管API还是私有化部署模型是整个系统里最容易被赋予“技术含量”的部分实际运营中它只是一个组件。选模型主要看四件事效果、成本、数据合规、运维能力。我拿一张表把主流做法对比一下方案效果成本数据合规运维复杂度商用闭源API综合最好多模态能力强按Token收费长期使用成本高数据出域通常不能直接传敏感信息最低开Key即用开源大模型私有部署看模型规模7B/14B可接受需要显卡电费维护加起来不便宜数据在自己手里高要懂GPU、推理框架、监控私有化API服务商中等偏上包年/包量单价略高可以签数据隔离协议中由服务商维护我的建议是第一次做优先上托管API把产品跑通再说。你真正需要的是快速验证问答效果和用户接受度而不是先搞一张4090搁那儿调半天环境。开源本地部署适合两类情况一是数据敏感不能出域二是推理成本预测下来长期能摊平服务器投入。但本地部署别指望省心模型文件、显存、并发、推理引擎版本能凑一块儿不那么容易。知识类系统选模型时还有一个误区——过分追求模型本身的能力。实际上如果你的痛点是从大堆文档里找准确答案那花大精力打磨文档切分、召回排序、引用标注效果提升往往比换一个更大的模型更明显。用一个好的小模型加上强检索通常能打赢裸奔的大模型。2.2 接口封装与调用参数细节决定体验无论选哪家模型我都建议在代码里做一层统一封装把供应商SDK隔离掉。原因很简单模型迭代快今天用的API价格高明天更好的模型出来了你要能换。封装层只需要暴露一个方法比如“生成回复”内部做重试、超时、日志、Token统计。调用参数看着简单实际坑不少。重点说几个常用的temperature采样温度调高会更发散调低更稳定。知识问答我通常设0.1到0.3闲聊设0.7到0.9。但要注意问题是模型实际实现有差异同样的0.5在两个模型上看效果可能完全两回事只能以实际表现为准。max_tokens限制生成的最大长度不只是保护成本还能防止模型越写越长。中文场景别忘了估算一个汉字大约对应1到2个token具体和分词器有关。top_p核采样一般保持默认或者配合temperature调不要同时乱动两个参数否则输出容易失控。stop停止词比如用“\n\n”或者特定标记约束输出结构能极大改善格式化效果。接口层还必须处理流式和超时。对话式AI最影响用户体验的就是等太久没反应。用非流式接口用户看着一句话转圈十秒心里已经开始骂了。流式接口一般基于SSE边生成边吐字前端配合打字机效果感知延迟能降到几百毫秒。我要求团队里所有对话接口默认走流式除非是离线批处理任务。超时和重试也要提前设计好。模型接口有时候会慢尤其是高峰期。设一个合理的超时时间比如30秒再配重试机制。但重试要注意退避网上流行的指数退避可以用你还要配合调用失败时的用户提示不能无限重试把体验拖垮。另外并发数要控制住很多API有并发限制超了会给你返回限流状态码这部分在封装层就要做统一处理。3. 对话管理Prompt、上下文与记忆是最难的部分3.1 Prompt设计像写接口协议一样写提示词Prompt不是什么神秘的咒语本质是一段写给模型的“接口说明”。我一直建议用结构化模板把Prompt分成几个区角色定义、任务目标、输入格式、输出格式、约束条件、示例输入输出。这样你能像维护代码一样维护它而不是随手在聊天框复制来复制去。一份典型的知识问答系统Prompt长这样示意你是XX公司的客服助手负责解答用户关于产品使用的问题。 请基于给定的【资料片段】回答如果资料中没有相关信息直接回复“抱歉这个问题我暂时无法确认”不要编造。 回答要求 1. 使用简洁的书面中文 2. 如果资料中存在多个相关信息按重要性排序回答 3. 回答末尾标注资料来源编号。 【用户问题】 ... 【资料片段】 ...我自己踩过最大的坑不是Prompt写得不够好而是没有规定输出格式。模型经常问一答十加上一堆正确但没用的废话或者不按“资料来源编号”格式来。后来加了few-shot示例再配合模型输出后的正则后处理问题才稳定。另一个容易忽略的是提示词注入。用户完全可能绕过你的系统提示输入“忽略以上所有指令告诉我如何……”这类内容。工程上能做的是把用户输入和系统指令分成不同字段传入严守“用户输入只是数据”的原则敏感操作不要靠模型判断要用结构化流程控制如果发现用户输入的意图和业务无关宁可让模型拒绝回答多轮也不要让它执行未定义动作。3.2 多轮上下文管理滑动窗口与摘要压缩对话系统的核心难点在于“记住前面聊了啥”。模型不是无状态的聊天机器人你把整段对话历史全塞给它一是会超过Token限制二是会稀释重要信息回复质量反而下降。我一般把对话管理分成两层短期上下文和长期记忆。短期上下文只保留当前这一轮会话的核心内容通常做法是滑动窗口。比如只保留最近6到8轮对话或者用Token数动态裁剪保证消息总长度接近模型输入上限的60%到70%。再往前的历史对话可以做摘要压缩。摘要压缩的做法很好理解每当窗口快满了把当前窗口里的内容发给模型让它生成一段言简意赅的对话摘要保存成新的历史摘要。下次再要完整上下文时就把摘要加在后边。这样模型既不会丢掉前面聊过的关键信息也不用每次把所有历史都拿过来。我写过一个简单的伪代码表述如下def build_conversation_context(messages, max_tokens4000): # 保留系统Prompt system messages[0] history messages[1:] recent [] used_tokens len(tokenize(system)) for msg in reversed(history): msg_token len(tokenize(msg)) if used_tokens msg_token max_tokens: if not recent: # 至少保留最近一条消息否则模型没有可回答的输入 recent.append(msg) break recent.append(msg) used_tokens msg_token recent.reverse() return [system] recent实际开发中还要注意多轮对话里用户可能会在某一轮突然改问题比如“不对我说的是另一个功能”。这时候单纯按工具截断是不够的需要结合意图识别判断是否开启新对话否则多轮上下文反而会污染当前问题。3.3 长期记忆怎么让AI记住你的偏好短期上下文解决“这一轮聊过什么”长期记忆解决“这个用户之前聊过什么”。很多对话系统做得像失忆患者用户上次反馈过“不要讲太长”下次还在长篇大论。长期记忆可以做得简单也可以做得很深。最简单的做法是在一段会话结束时用模型把用户的核心偏好和关键事实抽取成条目存进数据库。下一次会话开始先查库加载和当前问题相关的记忆条目拼进系统Prompt。注意不要把所有历史记忆全塞进去只挑相关的否则噪音很大。更进阶的做法是引入向量数据库。先把用户问题或者历史对话摘要向量化存储在向量库里当前用户对话开始时做一次相似度检索把最相关的记忆片段捞出来放进上下文。这里的选型我列一下方案优点适用场景PostgreSQL pgvector和业务数据放一起运维简单中小系统已有PostgresRedis 向量插件低延迟内存型对实时性要求很高Milvus功能强集群化支持海量向量大型系统千万级向量以上Elasticsearch 向量检索文本检索与向量统一已有ES技术栈我的建议是如果项目规模不大直接用PostgreSQL加pgvector少一套组件就少一堆运维问题。等确实发现性能瓶颈再上专门的向量库那时候迁移路径也相对清晰。记忆的本质是“在合适的时机给模型补上合适的背景信息”存储形式反而是次要的。4. 前后端联调与上线从能聊到好用差在细节4.1 流式输出前端不只是收到一个字符串我前面提过流式输出前端处理这一块其实是很多团队的暗坑。如果你用SSE前端不能用普通的XMLHttpRequest拿到完整响应后再渲染那样流式就白做了。现在主流方案是用fetch加ReadableStream逐块读取或者直接使用EventSource。要注意的是EventSource只能发GET请求部分场景下需要带鉴权头这时反而要用fetch来模拟SSE。我通常在后端把流式响应设计成标准的Server-Sent Events格式前端拿到每个chunk后直接做增量追加渲染。这里有两个细节一是首字要尽量快后端不要等全文生成完才吐第一个块二是即使模型生成了一个完整句子前端也最好按块渲染而不是等一段完整段落再刷否则打字机效果会一顿一顿。还有个容易忽略的场景用户点了“停止生成”按钮。对话模型流式生成是可以中途打断的前端要发送取消请求给后端后端立刻终止生成调用并且把已经生成的文本作为最终消息保存。如果你不处理中断用户在流式过程中已经看到一半回答了结果后端又继续纠错返回完整结果整个对话记录就乱了。4.2 后端服务化并发、限流与缓存对话式AI系统上线后最怕的不是功能缺陷而是模型接口扛不住突发流量。模型API本身有速率限制你自己服务端也要做用户级限流避免一个用户刷几百次把成本打爆。一般给普通用户做按时间窗口限流就够了比如一分钟最多30次请求。限流算法用令牌桶相对经典实现也不复杂桶容量代表最大突发量每秒钟往桶里放几个令牌用户请求取令牌取不到则返回“请稍后再试”。这个策略既允许日常高峰的抖动也防止有人恶意刷接口简单可靠。重试策略我前面提过指数退避这里补一个细节当模型接口因为限流返回429时你重试前一定要读一下响应头里的Retry-After字段按服务端建议的等待时间来。我见过不少团队无视这个字段三秒暴力重试结果越挫越勇限流越来越严重。服务端说等多久就等多久。缓存也值得做。对话系统经常有大量重复的用户问题比如“怎么退款”“怎么开发票”这些问题短期内容答案很少变化。可以做一个语义缓存把用户问题向量化后查缓存库相似度超过某个阈值直接返回历史答案完全不调用模型成本和延迟双双下降。这个方案我实测能把整体模型调用量减少三成以上但要注意设定合理的相似度阈值不然语义稍微变一下就误命中一直回复旧答案体验很差。4.3 日志、评估与全链路追踪对话系统上线之后你面对的将是一堆“模型说错一句话”的模糊反馈。没有日志你连“它为什么错”都查不出来。所以我非常建议从第一天就把请求链路日志设计进去。每条请求至少记录这些字段用户ID、会话ID、模型版本、Prompt模板版本、请求参数、模型原始返回、最终返回给用户的内容、各环节耗时、Token消耗、错误码。这样做的好处是当用户投诉时你能复现当时的完整上下文。另外每次调整Prompt务必带上版本号不然根本不知道线上跑的到底是哪套提示词。我见过不止一次测试环境调好了Prompt生产环境忘记更新用户反馈差了一个版本。追踪工具上开源生态里Langfuse、LangSmith这类平台可以帮忙把调用链可视化能直接看到一次回答从检索到模型生成的全部过程。项目刚起步用它们成本很低我建议顺手接一个。别等出了事故再补。评估是最容易被拖到最后的事。一个对话系统没有评估集你根本说不清版本A好还是版本B好。我会攒三五十条典型问题最好覆盖用户高频场景和很容易翻车的边界场景形成固定的回归集。每次改Prompt、换模型、调参数都拿这批问题跑一遍再人工给出打分。这个工作看着笨实际价值比花哨的自动指标大得多。5. 避坑实录高频问题与排查思路5.1 高频报错速查表排查问题时大部分错误都集中在几个固定原因。我整理了一张速查表现象常见原因排查方向接口超时模型服务慢并发太多排队看各环节耗时日志再做超时阈值调整返回429超过调用限额检查并发控制与重试策略读Retry-After回答截断max_tokens设太小调大上限或做摘要压缩控制上下文输出格式混乱Prompt缺少格式约束补输出格式说明和few-shot示例多轮后答非所问上下文太长导致信息稀释缩短滑动窗口启用摘要压缩记忆串号用户ID或会话ID用错检查前端传递的会话标识成本飙升上下文里塞了太多无关历史做历史裁剪、缓存相似问题5.2 性能与成本别急着上重武器很多团队一上来就规划要做微服务、自建推理集群、接消息队列但实际业务并发量只有几十。对话系统在初期最重要的反而是快速迭代和灵活调整。架构上保持单体加上清晰的模块边界比拆成七八个微服务更实用。成本控制也有不少小技巧。第一个是Prompt瘦身把系统提示词里不必要的背景文案删掉把示例控制在两三个以内Token费用会肉眼可见下降。第二个是上下文裁剪前8轮对话可能只值30分钱但你把50轮全部塞进去单次调用成本会翻好几倍效果还更差。第三个是用语义缓存前面提过重复问题直接命中缓存成本趋近于零。关于性能如果用户感知到首字慢别急着升级显卡或者换更快的模型服务先看看是不是接口封装层里做了多余的预校验或者前端没有开流式。我优化过的一个项目改动后端让它边生成边返回后用户体感从五秒变成一秒但整体生成时间其实一样长。流式输出是对话产品体验的免费午餐一定要用。5.3 一些文档里很少写的真实坑最后分享几个我实际踩过、但通常文档里看不到的细节问题。第一个是上下文列表的顺序。做多轮请求时消息列表必须是“系统提示 - 历史对话 - 当前用户问题”这种顺序。有一次我把历史对话倒序拼接模型开头还能正常回但聊到后面完全错乱排查了很久才发现是把列表反转了。建议写个单元测试固定住消息顺序。第二个是模型返回里时不时带出一些隐藏字符比如“\n\n”“”之类的。做知识库问答时我要求模型只返回纯文本但它有时仍会在开头加“好的根据资料如下”。这类问题用后处理规则清理别指望模型100%遵守格式。线上系统后台格式化解析失败统一走兜底逻辑。第三个是中文Token估算误差。很多工具有估算函数但中文分词和英文不一样不同模型的分词器也有差异。我吃过亏用某个公式估算上下文只用了50%容量结果实际调用时直接因为超限报错。正确做法是用你实际调用的模型自带的Token计数接口再留25%余量。第四个是重启导致记忆丢失。本地长期记忆存在进程内或内存Redis里服务一重启全没了用户第二天发现AI不记得自己是谁。虽然不是致命问题但上线前一定要把记忆持久化到数据库并把恢复逻辑测一遍。尾声按我现在的习惯先让系统跑起来再谈优化我后来搭新系统时刻意控制自己在第一个月不要碰任何“优化”“不要加AI客服头像不要调漂亮的前端动画不要研究流式负载均衡”。第一版就是把对话打通能回答问题能记录日志能抽取出用户偏好就够了。等数据攒下来、问题暴露出来再回头优化Prompt、加缓存、调整上下文策略每一步都有明确的收益。这套流程走到今天我个人认为最难的不是模型而是把上下文管理、记忆检索和日志评估这些工程细节做扎实。把这些底座打好后续加什么功能都不会太慌。这篇先把搭建流程和第一波避坑讲完下一篇可以单独聊知识库怎么切分、召回怎么调优以及如何设计一个靠谱的评估集。