![客服软件防错设计 (1).png](https://developer.qcloudimg.com/http-save/yehe-11404834/34077c6c73cfe60110aa6387b603e9fa.png)
> 本文以聊天宝 AI 话术模块为例，探讨 RAG（Retrieval-Augmented Generation）架构在企业客服场景下的工程实现，包括向量检索、提示词工程、匹配距离调参等关键环节。

## 一、为什么客服场景需要 RAG

大模型直接回答客服问题，常见两个问题：

1. **幻觉**：模型编造不存在的产品功能、错误的价格政策
2. **过时**：模型知识截止日期前的产品信息早已变更

RAG 的核心思路是：让模型在回答前，先从企业自有知识库中检索相关文档，再由模型基于检索结果生成回答。这样做有两个直接好处：

- 回答内容**可溯源**，每句话都能对应到具体文档
- 知识库更新后，AI 回答**无需重新训练**即可同步

## 二、系统架构概览

聊天宝 AI 话术模块的 RAG 链路如下：

```
用户咨询 → 语义编码（Embedding） → 向量检索（相似度匹配 Top-K）
→ 上下文组装（Prompt Engineering） → LLM 生成 → 话术候选返回
```

整个链路分为三个阶段：**索引构建**、**检索推理**、**生成增强**。

## 三、索引构建：如何组织企业知识

### 3.1 文档分块（Chunking）

知识库的文档通常较长（如产品手册、FAQ 文档），直接对整篇做 Embedding 效果很差——向量平均后语义会被稀释。实践中通常做**固定窗口分块**，常用策略有：

- **按段落分块**：以自然段落为单位，适合结构化 FAQ
- **重叠滑动窗口**：块大小 512 tokens，步长 256 tokens，减少边界信息丢失
- **层次索引**：先按文档维度建索引，再在文档内按段落建子索引，支持检索粒度控制

聊天宝的话术库本身具有天然的分类结构（一级分类、二级分类），因此在分块之外，还额外维护了一个**分类标签层**，用于检索后对结果做二次过滤。

### 3.2 向量模型选型

生产环境中常用的 Embedding 模型：

| 模型 | 维度 | 特点 |
|------|------|------|
| text-embedding-3-small | 1536 | OpenAI 官方，性价比高 |
| text-embedding-3-large | 3072 | 精度更高，速度略慢 |
| BGE-large-zh | 1024 | 中文优化，开源可私有部署 |
| M3E | 1024 | 中文开源，支持混合检索 |

选择维度不是越高越好。维度越高，单条向量占用的存储和计算量越大；在客服场景 512~1024 维足够，过高反而容易引入噪声。

## 四、检索推理：匹配距离的工程调参

### 4.1 相似度度量选择

向量检索有两种常用度量：

- **余弦相似度（Cosine）**：衡量方向一致性，对向量长度不敏感
- **内积相似度（Dot Product）**：对向量长度敏感，高频词的影响更大

余弦相似度是客服场景的默认选择，因为客服话术通常短文本，方向一致性比绝对量级更重要。

### 4.2 匹配距离（Threshold）配置

Top-K 检索后，系统会用一个**距离阈值**过滤低质量匹配结果。这个阈值的设置是 RAG 系统的核心工程挑战之一：

- **阈值过高**：匹配结果过少，AI 无话可说，回复质量下降
- **阈值过低**：无关内容被召回，AI 被干扰，生成内容偏离主题

实践中通常通过**召回率 + 精确率**的人工评测来确定初始阈值，再根据用户反馈持续调整。

### 4.3 混合检索策略

纯向量检索的弱点在于：**语义相近但表述不同的词**容易被漏掉，而**表述相同但语义不同**的词容易被错误召回。

解决方案是**混合检索**（Hybrid Search）：

```
最终得分 = α × 向量相似度 + (1-α) × BM25 关键词得分
```

BM25 是传统关键词检索算法，对精确匹配敏感；向量检索对语义相似性敏感。两者互补，`α` 通常设置在 0.7~0.8 之间。

## 五、生成增强：Prompt Engineering 的工程实践

检索到的 Top-K 文档直接塞给大模型，效果往往不如预期。原因在于：模型不知道如何使用检索结果，容易被无关内容带偏。

聊天宝 AI 话术模块的提示词模板设计了几个关键约束：

```
【系统提示词框架】

你是一名企业客服，参考以下话术库内容生成回复：
---
{检索到的上下文}
---
要求：
1. 优先使用上下文中的原文表述，不要自行发挥
2. 如果上下文没有覆盖用户问题，直接说"这个问题我暂时无法回答"
3. 回复长度控制在 3 句以内
4. 不要在回复中出现"根据检索结果"、"我查了一下"等表述
```

这个框架的关键点：

- **位置标记**：`---` 明确区分检索内容与用户问题，降低混淆风险
- **兜底策略**：当检索结果不足时，模型必须诚实说"无法回答"，而不是瞎编
- **长度约束**：客服回复需要简洁，3 句以内是最优实践

## 六、返回条数配置：用户体验的平衡

聊天宝支持配置返回 1~5+ 条话术候选。这个参数直接影响用户体验：

- **1 条**：最简单，但"唯一答案"容易出错，用户没得选
- **3 条（默认）**：兼顾覆盖度和选择成本，推荐值
- **5+ 条**：适合复杂问题，需要人工二次筛选

生产环境中，**3 条 + 按相关度排序**是多数场景的最优解。

## 七、工程踩坑记录

以下是我们落地过程中遇到的实际问题：

| 问题 | 原因 | 解决方案 |
|------|------|---------|
| 新增话术无法被检索到 | Embedding 是离线的，新增后未重建索引 | 引入增量索引机制，新增文档 5 分钟内可检索 |
| 竞品话术被错误复用 | 知识库中存在跨客户共享内容 | 增加数据隔离层，按企业 ID 做向量空间隔离 |
| 英文咨询回复质量差 | Embedding 模型中文强、英文弱 | 对英文输入切换到多语言 Embedding 模型 |
| 夏天咨询回复了冬天话术 | 分块时丢失了时效性上下文 | 增加时间戳元数据字段，检索时做时间过滤 |

## 八、多模态内容的 RAG 处理

除了纯文本话术,现代客服系统还需要处理**多模态内容**：图片、产品文档、报价单 PDF。这些内容的检索与发送有其特殊性。

### 8.1 图片素材的检索策略

图片不像文本可以做 Embedding，通常通过**结构化标签**实现检索：

```
图片素材元数据：
├─ 文件名：产品报价单_v2.png
├─ 标签：#报价 #高客单价 #B端客户
├─ 分类：产品资料 > 报价单
└─ 使用频次：47次
```

客服搜索"报价"时，系统同时检索文本话术和图片标签，返回两者混合的结果。这种设计避免了图片内容理解的复杂度，依靠**人工标注 + 使用频次**做排序。

### 8.2 云文档的分段发送

客服经常需要发送长文档（如产品手册 PDF、使用指南 Word）。直接发送整个文档的问题：

- 客户不想看 50 页文档，只需要其中 1 页
- 发送后无法追踪客户看了哪部分

**解决方案：云文档分段发送**

聊天宝的云文档支持在发送时指定文档的特定页或特定段落：

```python
# 发送特定页
def send_document_page(doc_id, page_range, target_window):
    doc = get_cloud_doc(doc_id)
    if page_range == 'all':
        send_file(doc.path, target_window)
    else:
        # 提取指定页，生成临时文件发送
        temp_file = extract_pages(doc.path, page_range)
        send_file(temp_file, target_window)
        cleanup_temp(temp_file)
```

分段发送的好处：
- 客户只收到相关内容，不会信息过载
- 系统记录客户看了哪些页，帮助销售判断客户关注点

### 8.3 表情包库的语义匹配

表情包在客服场景越来越重要，但表情包的检索是个难题——**如何用文字搜表情**？

聊天宝的表情包库采用**语义标签映射**：

```
表情包语义映射：
├─ "感谢" → [握手表情, 爱心表情, 感谢表情]
├─ "道歉" → [抱歉表情, 鞠躬表情]
├─ "庆祝" → [鼓掌表情, 撒花表情, 蛋糕表情]
└─ "确认" → [OK手势, 点头表情, 比心]
```

客服输入"感谢客户"，系统不仅返回文字话术，还会推荐相关的表情包。这种设计的关键是**建立语义标签库**，将抽象情绪映射到具体表情。

## 九、总结

RAG 架构在客服场景落地的核心不是模型有多强，而是**检索质量**和**提示词设计**的工程精细度：

1. **文档分块策略**决定检索上限，分块过粗或过细都不行
2. **匹配距离阈值**需要持续调优，没有一劳永逸的默认值
3. **混合检索**是工程落地的推荐标配，不是可选项
4. **提示词兜底策略**决定了系统在边界情况下的行为下限
5. **多模态内容**（图片、文档、表情包）的检索需要结构化标签辅助

对于正在构建类似系统的团队，建议先用小规模数据集跑通全链路，再逐步扩大知识库规模和用户量。RAG 不是一个"部署即完成"的项目，而是一个需要持续迭代的数据工程系统。

本文以聊天宝 AI 话术模块为例，探讨 RAG（Retrieval-Augmented Generation）架构在企业客服场景下的工程实现，包括向量检索、提示词工程、匹配距离调参等关键环节。

RAG 架构在客服场景的落地实践：从检索到生成的完整链路

人工智能

后端

架构设计

本文探讨RAG架构在企业客服场景的工程实现，包括向量检索、提示词工程、匹配距离调参等关键环节。通过聊天宝AI话术模块案例，分析文档分块、混合检索、多模态处理等优化策略，解决大模型幻觉和知识过时问题，提升客服回答准确性和时效性。

2026采购季 | AI焕新·智启新局

cslr

lexiang

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

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

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

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

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

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

社区新版编辑器体验调研

RAG 架构在客服场景的落地实践：从检索到生成的完整链路-腾讯云开发者社区-腾讯云

RAG 架构在客服场景的落地实践：从检索到生成的完整链路

RAG 架构在客服场景的落地实践：从检索到生成的完整链路

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐