过去一年大模型客服的讨论很多但不少方案仍停留在“接一个模型 挂一个知识库”的 Demo 阶段。真正把它放到游戏客服场景里会很快遇到一批更麻烦的问题问题类型复杂、版本资料频繁变化、用户问法高度口语化、历史公告有时效性、部分问题不能直接回答而必须转人工甚至同一句话在不同业务边界下应该给出完全不同的处理方式。所以一个能上线的智能客服系统重点不只是“模型会不会答”而是它能不能稳定地判断该不该答、用什么资料答、答错时怎么兜底、出了问题能不能追踪和回滚。这篇文章想分享一个游戏领域智能客服项目的工程化总览我们如何把一个 RAG 问答能力拆成可部署、可观测、可评测、可持续迭代的服务系统。一、系统不是一个模型而是一条链路在工程上我们没有把所有逻辑塞进一个巨大的 prompt而是拆成几类服务。最外层是网关和会话层负责对外接口、鉴权、会话上下文和客户端兼容。中间是问答编排服务负责一次用户提问从进入系统到产出最终结果的完整流程。内部还有独立的知识库检索服务处理向量召回、关键词召回、重排和知识快照加载。再往后是知识构建流水线把上游 wiki、FAQ、公告、设定资料等原始内容加工成可检索的知识资产。这个拆分带来的好处很直接线上问答和离线知识构建解耦知识库可以独立更新问答服务可以独立部署检索、生成、安全策略可以分别调试。对客服系统来说这比“一个服务里什么都做”更容易维护。二、问答流程被拆成多个 stage一次用户提问进入系统后并不是马上丢给大模型生成答案而是经过一条多阶段流水线。第一步是基础预检和意图判断。系统会先识别是否存在明显不适合 AI 直接处理的问题例如账号、充值、敏感政策、人工核验类诉求等。对于这类问题系统不应该为了“显得智能”而强答而应该直接给出合适的转人工或引导策略。第二步是 Router。它负责判断问题应该走 FAQ、RAG、闲聊、拒答、转人工还是其他业务路径。Router 的价值不是“更聪明地回答”而是减少后续链路走错方向。比如一个问题看起来像知识问答但实际上是账号资产申诉就不应该进入普通知识库生成答案。第三步是 Query Rewrite。游戏玩家的问题常常很短也可能带有别名、缩写、口语表达。改写阶段会在不改变原意的前提下把问题转换成更适合检索的形式提高召回质量。第四步是 Retrieval。这里会调用内部知识库服务从 FAQ、wiki、公告、设定资料等知识源中召回候选内容。对于公告和版本资料还需要考虑时效性过期内容不能随便拿来当当前答案依据长期有效内容和版本限定内容也要区分处理。第五步是 Generation。生成阶段不是让模型自由发挥而是要求它基于检索证据组织答案。客服答案尤其强调“少编、少猜、少扩展”宁愿转人工也不能把没有依据的内容说得很肯定。最后是 Output Gate 和 Policy。生成后的答案还要经过输出检查包括是否出现来源不一致、是否夹带不该展示的信息、是否应该转人工、是否符合业务边界。也就是说生成不是终点能不能把答案发给用户还需要最后一层判断。这种 stage 化设计最大的收益是每一步都可以单独观测和测试。当线上出现“答错了”时我们能知道是 Router 分错了、检索没召回、重排排序不对、生成幻觉了还是输出策略没有拦住。下面整体架构图三、知识库构建比想象中更重要很多 RAG 项目一开始会把注意力放在模型上但实际做下来知识构建的质量往往决定上限。在这个项目里知识并不是简单地把文档切块后塞进向量库。不同来源有不同处理方式FAQ 更适合短问短答匹配wiki 内容需要保留标题层级和上下文公告类内容要带发布时间和时效标签设定资料则要避免和玩法事实混淆。知识构建流水线会把原始资料转换成统一格式进行清洗、切分、embedding、索引构建和 manifest 记录。manifest 的作用是让每一次知识快照都可追踪当前线上用的是哪一批数据、包含哪些来源、文件摘要是什么、构建过程是否完整。这样当答案异常时排查对象不只是代码也包括知识版本本身。这也是客服系统和普通聊天机器人的一个重要区别客服不是“能聊就行”而是要知道每一句答案背后的资料依据是什么。四、上线能力兜底、追踪、回滚智能客服上线后最怕的不是“不够聪明”而是“错得很自信且没人知道为什么错”。因此系统里需要很多看起来不酷、但非常关键的工程机制。第一是 trace。每次请求都会记录从预检、路由、改写、检索、生成到输出检查的关键过程。trace 不是为了堆日志而是为了让问题可复盘召回了什么、为什么转人工、模型输出是什么、最终为什么被拦截。第二是 killswitch。当 AI 能力出现大面积异常或某类业务暂时不适合自动回答时运营和技术侧需要能快速关闭全局或局部能力而不是等重新发布代码。第三是 AssetGate。知识资产可能临时下线、纠错或撤回。即使某些内容仍存在于离线知识库里线上回答也应该能通过拦截名单阻止它继续出现在用户答案中。第四是流式和非流式一致性。很多客服前端需要流式体验但服务端也通常要提供同步接口用于后台、评测或调试。如果两条路径返回的正文结构不一致就会造成非常隐蔽的问题。因此流式输出不仅是体验功能也是一条需要被测试的协议链路。第五是部署和 smoke test。上线不是把服务启动起来就结束而是要验证健康检查、知识库 ready、检索可用、问答链路可用、转人工路径可用。尤其是 RAG 系统服务活着不代表知识已经加载完成。五、几点经验第一不要用单个 bad case 驱动 prompt 修改。客服系统里的问题分布很复杂一个 case 修好了可能会让另一批问题退步。Router、生成 prompt、检索策略的改动都应该进入评测集做整体对比。第二RAG 的关键不是“召回更多”而是“召回对、排序对、敢于不答”。客服场景里低置信度时转人工是正确行为不是失败。第三工程边界要比模型能力更早确定。哪些问题能答、哪些必须转人工、哪些资料能展示、哪些答案要拦截这些都应该进入系统策略而不是临时写在 prompt 里。第四知识版本和服务版本一样重要。没有知识快照、manifest 和构建记录线上答案问题很难复盘。总结来说智能客服从 Demo 到可上线中间差的不是一个更大的模型而是一整套工程纪律服务拆分、阶段化编排、知识构建、trace 观测、评测闭环、兜底和回滚。大模型负责生成能力但系统工程负责让它在真实业务里可控地工作。