企业级 RAG 多路召回智能客服实战：第 1 章，从 Demo 到生产架构

企业级 RAG 多路召回智能客服实战：第 1 章，从 Demo 到生产架构

很多团队第一次做 RAG 智能客服时，路线大概是这样的：

1. 准备一批产品文档；
2. 切成 chunk；
3. 调 embedding 模型；
4. 写入向量库；
5. 用户提问时向量检索 TopK；
6. 把检索结果和问题一起塞给大模型；
7. 得到一个看起来还不错的回答。

这个 Demo 很重要，因为它能快速验证"企业知识 + 大模型问答"的基本可行性。但只要进入真实客服场景，问题就会立刻变多：

• 用户说法非常口语化，和文档标题、文档正文并不一致；
• 一个问题可能需要 FAQ、产品手册、工单经验、订单系统一起参与；
• 用户问的是售后流程，但向量库召回了一堆营销介绍；
• 大模型回答很流畅，但引用依据不够准确；
• 不同部门、不同客户、不同角色能看的知识范围不一样；
• 老文档没有下线，新文档还没生效，回答开始前后矛盾；
• 线上客服最关心响应速度、解决率、转人工率，而不仅是"能不能回答"。

所以，企业级 RAG 智能客服不是"向量库 + 大模型"的简单拼接，而是一套围绕知识、召回、推理、流程、权限、评测和运营持续迭代的应用系统。

这一章先不写代码，我们先把整体架构讲清楚。后续章节会一章一章拆开做。

一、为什么智能客服特别适合 RAG

RAG，全称 Retrieval-Augmented Generation，可以理解为"检索增强生成"。它的核心思想是：不要让大模型只凭训练时学到的通用知识回答，而是在回答前先从企业自己的知识库里找依据，再让模型基于这些依据组织答案。

智能客服天然适合 RAG，原因有三个。

第一，客服回答高度依赖企业内部知识。

比如产品规格、退换货规则、合同条款、套餐限制、故障排查步骤，这些内容经常变化，而且大模型预训练数据里通常没有。即使模型"知道一点"，也很容易过时。

第二，客服问答需要可追溯。

企业不是只要一个像人一样的回答，而是要知道这句话依据哪篇文档、哪个 FAQ、哪条政策。特别是金融、政务、医疗、工业软件、ToB SaaS 等场景，回答不能凭感觉。

第三，客服系统需要和业务流程联动。

真实用户经常不是单纯问知识，而是在表达诉求：

• "我这个订单为什么还没发货？"
• "发票开错了能改吗？"
• "设备报 E102 怎么处理？"
• "这个账号为什么没有权限？"

这些问题有些要查知识库，有些要查订单，有些要走工单，有些要转人工。RAG 是核心，但不是全部。

二、Demo 版 RAG 和企业级 RAG 的差距

Demo 版 RAG 通常只验证一件事：用户问题能不能从文档里找到相似片段，然后交给大模型回答。

企业级 RAG 至少要多考虑七件事。

1. 知识从哪里来

企业知识不是只有 PDF。常见来源包括：

• 产品手册、帮助中心、Markdown 文档；
• FAQ 问答对；
• 历史客服工单；
• 在线网页和知识库系统；
• 数据库里的结构化信息；
• API 返回的实时业务数据；
• 人工维护的规则、话术和禁答清单。

这些数据格式不同、质量不同、更新频率不同，进入 RAG 之前必须治理。

2. 用户真正想问什么

用户不会按照文档标题提问。

文档里写的是"账号权限开通流程"，用户问的是"为什么我点不了导出按钮"。如果只做向量相似度，可能召回不到最关键的权限说明。

企业级系统通常需要做意图识别、问题改写、同义词扩展、行业词库匹配，甚至根据当前用户角色和页面位置补充上下文。

3. 召回不应该只有一路

只靠向量召回，很容易漏掉精确词、编号、错误码、型号、政策条款。

比如用户问"E102 报错怎么处理"，关键词 E102 比语义相似度更重要。用户问"套餐 A 和套餐 B 区别"，FAQ 召回可能比普通文档 chunk 更稳定。用户问"我的订单到哪了"，应该查业务接口，而不是查知识库。

所以企业级智能客服通常采用多路召回。

4. 检索结果要排序和压缩

召回多不等于回答好。

如果一次召回 30 个片段，全塞给大模型，不仅成本高，还会把不相关内容带进上下文，增加幻觉。实际系统里需要 Rerank、去重、合并、上下文压缩和引用保留。

5. 权限必须前置

企业知识有权限边界。

同一个问题，内部员工、渠道商、普通客户、VIP 客户看到的答案可能不同。权限过滤不能只靠提示词告诉大模型"不要回答"，而应该在检索阶段就控制可见数据范围。

6. 回答需要可评测

不能只靠人工感觉"好像回答得不错"。

线上要关心：

• 是否命中正确知识；
• 是否引用了可靠来源；
• 是否回答完整；
• 是否出现编造；
• 是否应该转人工；
• 响应时间是否可接受；
• 用户是否继续追问或投诉。

没有评测，就没有持续优化。

7. 系统要能运营

客服系统上线后，每天都会暴露新问题：

• 哪些问题没有命中知识库；
• 哪些问题频繁转人工；
• 哪些回答用户点了"不满意"；
• 哪些文档已经过期；
• 哪些问题应该沉淀为 FAQ。

企业级 RAG 的价值不只是自动回答，还包括反向推动知识库建设。

三、企业级 RAG 智能客服的总体架构

一个可落地的企业级 RAG 多路召回智能客服，可以拆成八层：

用户入口
  |
  v
会话层：用户身份、渠道、上下文、历史消息
  |
  v
理解层：意图识别、问题改写、实体抽取、权限上下文
  |
  v
召回层：向量召回、关键词召回、FAQ召回、规则召回、接口召回
  |
  v
排序层：Rerank、去重、融合排序、上下文压缩
  |
  v
生成层：Prompt 组装、大模型回答、引用来源、拒答策略
  |
  v
动作层：查订单、建工单、转人工、发送链接、触发流程
  |
  v
观测层：日志、评测、反馈、监控、知识运营

这套架构的重点不是"层数多"，而是每一层都解决一个生产问题。

四、多路召回到底是什么

多路召回不是把几个检索方式随便并排放在一起，而是根据不同问题类型，用不同通道找到最可能有用的信息。

常见召回通道可以这样划分。

1. 向量召回

适合语义相似问题。

例如：

• "怎么重置登录密码？"
• "忘记账号了怎么办？"
• "无法进入后台怎么处理？"

这些说法不一定和文档完全一样，但语义接近。向量召回可以找到相似片段。

2. 关键词召回

适合精确词、错误码、型号、政策编号。

例如：

• "E102"
• "HTTP 429"
• "V3.2.1"
• "A100 套餐"

这类问题里，精确匹配非常关键。BM25、倒排索引、标题字段加权通常比纯向量更稳。

3. FAQ 召回

适合高频标准问答。

客服场景里有大量固定问题，比如"怎么开发票""能不能退款""密码忘了怎么办"。这类问题如果已经有人工验证过的标准答案，优先走 FAQ 可以提升稳定性和一致性。

4. 规则召回

适合强约束场景。

比如敏感问题、禁答问题、必须转人工的问题、必须展示固定话术的问题。规则召回不是为了智能，而是为了可靠。

5. 结构化数据召回

适合查询业务状态。

比如订单、物流、余额、权限、工单状态。这类问题不能靠文档回答，必须调用数据库或业务 API。

6. 历史工单召回

适合复杂问题排查。

历史工单里往往有一线客服和工程师处理过的真实案例。它不像产品文档那么规整，但很有经验价值。后续可以通过清洗、脱敏、摘要，把它变成可召回的案例库。

企业级 RAG 的关键，是把这些召回通道融合起来，再交给后面的排序和生成模块。

五、一次问答请求应该怎么流转

假设用户问：

我们客户后台导出报表一直提示没有权限，但我是管理员，怎么处理？

一个比较完整的流转可能是：

1. 会话层识别用户身份、企业租户、当前渠道；
2. 理解层提取实体：导出报表、没有权限、管理员；
3. 意图识别判断这是"权限故障排查"，不是普通功能介绍；
4. 问题改写为："管理员导出报表提示无权限的原因和处理步骤"；
5. 向量召回找权限配置相关文档；
6. 关键词召回匹配"导出报表""管理员""权限"；
7. FAQ 召回匹配高频问题"管理员为什么不能导出报表"；
8. 业务接口查询当前用户是否拥有报表导出权限、租户是否开启该功能；
9. Rerank 把最相关的文档、FAQ、接口结果排在前面；
10. Prompt 组装时要求模型只基于召回内容回答；
11. 生成答案时给出排查步骤、可能原因和引用来源；
12. 如果接口显示权限异常，动作层可以引导用户提交工单或转人工；
13. 观测层记录本次召回、回答、用户反馈和是否解决。

注意，这里大模型不是系统的全部。它更像是一个会组织语言、会推理总结的回答器。真正决定答案可靠性的，是前面的知识治理、召回设计和权限控制。

六、企业级 RAG 的技术选型原则

技术选型不要一开始就追求"全家桶"，而要围绕问题来选。

1. 文档处理优先考虑可维护性

PDF、Word、HTML、Markdown 都能解析，但解析效果差异很大。企业系统要记录来源、版本、更新时间、所属部门、权限范围，而不是只保存一段纯文本。

2. 向量库优先考虑过滤能力和更新能力

客服知识经常变。向量库不仅要能检索，还要支持元数据过滤、增量更新、删除、租户隔离和批量重建。

3. 检索系统优先考虑混合召回

向量检索适合语义，关键词检索适合精确匹配。两者不是替代关系，而是互补关系。

4. 大模型优先考虑稳定输出

客服系统不适合过度自由发挥。Prompt 应该明确要求：

• 只能基于给定材料回答；
• 材料不足时说明无法确认；
• 给出分步骤建议；
• 保留引用来源；
• 遇到高风险问题转人工。

5. 工程架构优先考虑可观测

每次问答都应该记录：

• 原始问题；
• 改写后的问题；
• 命中的召回通道；
• 召回文档 ID；
• Rerank 分数；
• 最终 Prompt；
• 模型回答；
• 用户反馈；
• 耗时和成本。

没有这些日志，后面很难优化。

七、本系列最终会做成什么

后续章节会逐步把这个系统落下来。最终目标是搭建一个具备以下能力的企业级 RAG 智能客服：

• 支持文档、FAQ、历史工单、结构化数据进入知识库；
• 支持向量召回、关键词召回、FAQ 召回、规则召回、接口召回；
• 支持 Rerank、去重、融合排序和上下文压缩；
• 支持多轮对话、意图识别、问题改写和人工转接；
• 支持租户、角色、部门级权限过滤；
• 支持回答引用来源和低置信度拒答；
• 支持离线评测、线上监控和用户反馈闭环；
• 支持从 Demo 部署到生产环境。

我们不会只停留在概念层面。后续会逐步给出数据结构、接口设计、核心代码、Prompt 模板、评测脚本和上线策略。

八、这一章的结论

企业级 RAG 智能客服的难点不在于"让大模型回答一句话"，而在于让它稳定、可控、可追溯地解决业务问题。

一句话总结：

Demo 版 RAG 关注"能不能答"，企业级 RAG 关注"答得准不准、依据是什么、谁能看到、出了问题怎么改"。

从下一章开始，我们进入第一块硬骨头：知识库数据治理。因为召回效果的上限，往往不是由模型决定的，而是由知识进入系统时的质量决定的。