**摘要**：9 月 1 日起，国内首个规范人工客服与智能客服协同的国家标准 GB/T 47746—2026 正式实施，明确要求智能客服的回答符合企业真实政策、不得越权承诺。这篇从 RAG 落地拆三件事：知识库按站点分类、答案带 sources 可追溯、差评审核成 FAQ 闭环，附 collection 命名与知识处理流程。

---

## 一、国标点名的那个问题,恰好是 RAG 的软肋

### 1.1 9 月 1 日之后,「答非所问」不再只是体验问题

《顾客联络服务 人工与智能客户服务协同要求》(GB/T 47746—2026) 由市场监管总局（国家标准委）于 2026 年 5 月 25 日发布，9 月 1 日起实施，是国内首个聚焦人工客服与智能客服协同机制的国家标准。人民日报 9 月 16 日的评论把消费者最常吐槽的三件事摆到了台面上：问 A 答 B、反复念说明书、情况紧急还在绕圈子。

几乎同一时间，中国消费者协会发布的《2026 年上半年全国消协组织受理投诉情况分析》给出了一个更硬的信号：售后服务问题在投诉性质中占比 26.79%，排在首位，AI 客服「人工接入困难」也被点名为投诉热点之一。

把这两条放在一起看会发现，被点名的表面是转人工，真正的病根在知识：答不出、答不准、答了不该答的，用户才非要找人。

### 1.2 国标真正卡的是「有据可查」和「不越权承诺」

新国标对协同机制提了四条明确要求，其中两条跟知识质量直接相关：标准化问题交给智能客服，复杂及涉及安全的事项流转人工；人机切换要同步客户信息，不能让用户重复描述。

另外两条落在责任上。经营者要建立 AI 客服的上岗与测试机制，上线前经过业务规则训练和沙盒测试，确保回答符合企业真实政策、不越权承诺；同时不得以「算法生成不具备法律效力」为由拒绝履约，标准明确把人工客服和智能客服视为完整的服务。

「确保回答符合企业真实政策」翻译成工程语言就是一句话：每一条回答都要能追到它依据的那份文档。这正是检索增强生成（Retrieval-Augmented Generation，RAG）要解决的问题。

### 1.3 对做 RAG 的开发者意味着什么

不少团队做 RAG 的第一版是「把 PDF 传进去，能答就行」。国标落地后验收标准抬高了：能不能答是一回事，答错了能不能查到是哪份文档错了、这份文档归谁维护、改完之后再问是否生效，是另一回事。

后面这三件事拼的是知识库的治理能力，换个更大的模型解决不了。

## 二、先把「答得准」拆成可检查的四个环节

### 2.1 什么是可溯源的 RAG 客服问答

可溯源的 RAG 客服问答，是指客服在回答用户问题时，先从该站点专属的知识库中检索出相关片段，再由模型基于这些片段组织答案，并把被引用的知识条目连同答案一起返回给用户与运营后台。它和「把文档丢给大模型自由发挥」的区别只有一点：答案里的每个事实都能回指到一条可编辑、可上下线的知识。

### 2.2 分类、检索、引用、回收:一条链路四个卡点

| 环节 | 做对了是什么样                | 做错了会怎样                        |
| ---- | ----------------------------- | ----------------------------------- |
| 分类 | 知识按站点与业务类型分开存放  | 内部制度答给了外部客户              |
| 检索 | 只检索当前站点的知识集合      | 空集合时兜底到全局知识,答出别家口径 |
| 引用 | 答案带 sources,可回指知识条目 | 答错了查不出依据,没法纠             |
| 回收 | 差评能一键沉淀成 FAQ          | 同一个问题被反复答错                |

四个环节里，前两个属于架构，后两个属于运营。国标卡的是前两个，日常能不能「越用越准」看后两个。

## 三、知识库怎么按站点分类,才查得准

### 3.1 三档分类:系统预置 + 租户默认 + 站点覆盖

知识分类没有一套通用答案，客服中台的做法是分层：系统预置一批分类方案，租户选一套作为默认，单个站点可以再覆盖。同一套底座服务不同行业的客户时，不用改代码。

预置的分类方案大致长这样：

| 方案             | 适用场景               | 默认分类                                          |
| ---------------- | ---------------------- | ------------------------------------------------- |
| ecommerce_cs     | 商品、订单、售后、优惠 | 产品知识、FAQ、业务规则、商品参数、营销素材       |
| internal_policy  | 内部制度与流程         | 制度文件、流程规范、材料清单、FAQ、通知公告       |
| admin_ops_help   | 后台系统操作帮助       | FAQ、操作流程、规则与权限、字段与格式、风险与边界 |
| software_support | 软件安装与故障排查     | 功能教程、安装激活、故障排查、版本兼容、FAQ       |

分类的作用不只是给运营一个文件夹。它同时决定了知识写进哪个向量集合，以及检索时从哪里找。

### 3.2 collection 按站点生成,答案溯源的第一道保障

站点知识库的向量集合按站点生成，命名格式固定：

```
{siteId}__cs-{category}

# 示例
site_xxx__cs-product      # 产品知识
site_xxx__cs-faq          # FAQ
site_xxx__cs-marketing    # 营销素材
```

配套的隔离规则里有两条值得单独说：客服主会话只读取当前站点的 collection；站点 collection 为空时，不再兜底到全局的 cs-product。

第二条是关键。兜底看着贴心，实际是把「这个站点没配知识」这个明确的问题，悄悄换成了「答了一个不属于这个站点的答案」。国标要求回答符合企业真实政策，这种兜底恰好相反。

### 3.3 从上传到可检索:知识处理流程与状态回写

知识进库是一个异步过程，运营在后台看到的是状态流转，不是一句「已上传」：

```
POST /v1/knowledge/documents                  # 提交文档或 FAQ, 写入向量任务
GET  /v1/knowledge/documents/{docId}/status   # 查询处理状态

# 异步处理链路
文档解析 -> 分块 -> 清洗 -> 写入向量 collection

# 状态回写
processing -> done / failed
```

后台会把向量化状态直接展示在知识库页面上，运营能看到总文档数、FAQ 条目数、向量化完成比例和最近更新时间。少了这一步，知识库会变成黑盒：文档传了、答不出来，也不知道卡在哪一环。

## 四、让答案「可查」:sources 引用怎么落地

### 4.1 为什么把 sources 单独作为一类事件

客服对话走的是流式输出，服务端到事件流（Server-Sent Events，SSE）把内容拆成几类事件发送：正文增量、引用来源、营销推荐、结束标志。引用不塞进正文，而是单独一条事件，前端把它渲染成答案下方的引用条。

这样做有两个实际好处。用户侧看到依据会更愿意相信；运营侧，一条回答到底命中了哪条知识，有独立数据可以统计。产品的可观测指标里就有一项专门盯知识库质量，叫 RAG sources 命中率。

### 4.2 一条带引用的回答,链路是怎么走的

用户提问后，链路大致是：意图分类判断这是知识类问题，去当前站点的 collection 检索，把命中的片段交给模型，模型生成答案，服务端把答案、sources 和意图一起落库。

落库这一步很重要。会话记录里同时保存了 AI 回复、sources 和 intent，意味着事后复盘时「这条回答引用了哪条知识」可以被反查。国标说要确保回答符合企业真实政策，能被反查是前提。

## 五、「越用越准」的闭环:从差评到 FAQ

### 5.1 差评不是投诉,是知识缺口信号

用户点了一个 bad，多数团队的处理是「知道了」。但这条反馈其实带着两个信息：模型答错了，而且这个问题值得有一条标准答案。

产品把这类信号单独收口到一个页面：汇总 bad 反馈和低分内容，能看到原始会话上下文，可以更新审核状态，也可以把差评问题一键创建为 FAQ。

### 5.2 从 bad 反馈到 FAQ 的三步

- 收集：触发扫描把新的差评加入待审核列表；
- 判断：结合原始会话上下文，确认是知识缺失、知识过期还是表述问题；
- 沉淀：确认后一键创建 FAQ，进入知识库治理流程。

状态本身是可跟踪的。消息级记录里有一个 reviewStatus 字段，取值是 pending、reviewed、faq_created 三态；用户评价通过反馈记录关联到具体的 assistant 消息上，不混在消息正文里。三态加上关联关系，才能回答「这条差评到底处理完了没有」。

```
reviewStatus: pending  ->  reviewed  ->  faq_created
feedback:     good / bad      # 关联在 assistant 消息上, 不内嵌进消息正文
```

### 5.3 知识缺口分三类,补法不一样

把差评和未命中的问题归到一起看，缺口基本落在三种情况：

- 空白型：被反复问到，知识库里根本没有对应条目；
- 过期型：有条目，但和最新政策、流程不一致；
- 冲突型：同一问题存在多条口径不同的答案。

三类缺口的处理动作完全不同。空白型要补内容，过期型要改版本，冲突型要合并条目并明确唯一口径。判断不出类型，就只能在「再培训一下」上打转。

## 六、上线前先过一遍这份清单

- 站点知识分类是否已选定，是否与实际业务对得上；
- 是否存在空 collection 兜底到全局知识的情况；
- 向量化状态是否在后台可见，失败任务有没有人跟进；
- sources 是否能落库并被反查；
- 差评审核是否有明确责任人，faq_created 的条目有没有真的改；
- 涉及政策的答案，是否有一条「不确定就转人工」的兜底路径。

## 七、FAQ

**Q1：RAG 能不能彻底消灭答非所问？**
不能。RAG 的作用是把答案约束在企业自己的知识里，答不出时应该拒绝回答并转人工，而不是编一个像样的答案。把「不知道」做出来，比追求「什么都能答」更接近国标要求。

**Q2：知识库按站点隔离，会不会让维护成本翻倍？**
会增加，但可以用分类模板压住。租户选一套默认分类方案，站点继承，只有业务差异大的站点才覆盖。真正需要逐站点维护的是内容，不是结构。

**Q3：sources 引用能解决什么问题？**
它解决追责与纠错。答错了能查到依据在哪，才谈得上修；否则只能整体重建知识库，成本高还找不到根因。

**Q4：差评审核一定要人工介入吗？**
目前需要。差评本身信息量不足，是知识缺失还是表述问题要人来判断。系统能做的是把信号聚合好、把上下文准备好、把状态记录下来。

**Q5：知识库多久更新一次比较合适？**
没有固定周期。更实际的判断标准是看未命中问题和新差评的积累速度，积累快了就说明该补。

## 让「答得准」变成可验证的事

国标把标准立在了「回答要符合企业真实政策」这一条上，对做 RAG 的团队来说这其实是好消息：它把「答得像不像人」这种没法验收的目标，换成了「答得有没有依据、依据能不能查、错了能不能改」这种可以落地的目标。

如果你正在给业务站点搭知识库问答，可以先从两件小事开始：把空集合兜底关掉，把差评审核跑起来。前者防止答错别人的话，后者保证以后答对。

**想看看上面这套知识库隔离、sources 溯源和差评审核流程在自己业务里怎么落，可以在评论区留下业务场景，我们按站点维度做一次技术对接沟通，也支持申请智能客服能力的试用与私有化部署评估。**

**标签**：#智能客服 #RAG #知识库 #大模型应用 #知识溯源 #客服系统 #私有化部署 #多租户SaaS

摘要：9 月 1 日起，国内首个规范人工客服与智能客服协同的国家标准 GB/T 47746—2026 正式实施，明确要求智能客服的回答符合企业真实政策、不得越权承诺。这篇从 RAG 落地拆三件事：知识库按站点分类、答案带 sources 可追溯、差评审核成 FAQ 闭环，附 collection 命名与知识处理流程。

解决 AI 客服 “胡说八道”：可溯源 RAG，让每一条回答有据可查

9 月 1 日起，国内首个规范人工客服与智能客服协同的国家标准 GB/T 47746—2026 正式实施，明确要求智能客服的回答符合企业真实政策、不得越权承诺。这篇从 RAG 落地拆三件事：知识库按站点分类、答案带 sources 可追溯、差评审核成 FAQ 闭环，附 collection 命名与知识处理流程。

人工智能

后端

新闻资讯

9月1日起实施的国家标准GB/T47746—2026要求智能客服回答须符合企业真实政策、不越权承诺。本文从RAG落地角度拆解三件事：知识库按站点分类、答案带sources可追溯、差评审核成FAQ闭环，附collection命名规则与知识处理流程，帮助开发者构建合规可验证的客服问答系统。

大模型应用

代码解释

SaaS

2026上云采购 | AI焕新·智启新局

lexiang

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

解决 AI 客服 “胡说八道”：可溯源 RAG，让每一条回答有据可查-腾讯云开发者社区-腾讯云

解决 AI 客服 “胡说八道”：可溯源 RAG，让每一条回答有据可查

解决 AI 客服 “胡说八道”：可溯源 RAG，让每一条回答有据可查

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐