从 Demo 到可上线：一个游戏智能客服 RAG 系统的工程化拆解
过去一年，大模型客服的讨论很多，但不少方案仍停留在“接一个模型 + 挂一个知识库”的 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 观测、评测闭环、兜底和回滚。大模型负责生成能力，但系统工程负责让它在真实业务里可控地工作。