在 AI 客服系统中，真正决定回答质量的不是模型，而是 RAG（Retrieval-Augmented Generation）知识库。
一个成熟的客服 RAG 并不是把所有文档 Embedding 后放入向量库，而是需要根据不同类型的数据，采用不同的 知识组织方式、Chunk 策略、Metadata 设计和检索策略。
本文介绍一套适合企业级 AI 客服系统的 RAG 设计方案。
用户问题
│
▼
Query Rewrite（问题改写）
│
▼
Intent Router（意图识别）
│
┌──────────────┼──────────────┐
│ │ │
▼ ▼ ▼
FAQ库 商品知识库 售后知识库
│ │ │
▼ ▼ ▼
Semantic Search Semantic Search Semantic Search
│ │ │
└──────────────┼──────────────┘
▼
Top20 Candidate
│
▼
Reranker排序
│
▼
Top5 Chunk
│
▼
Prompt + Memory
│
▼
LLM
│
▼
最终回答整个流程分为四步：
不要把所有知识混到一个 Collection。
建议按照业务拆分。
knowledge/
├── faq/
├── products/
├── logistics/
├── after_sale/
├── payment/
├── activity/
├── policy/
├── manuals/
└── excellent_cases/每一类数据都有不同特点，因此需要采用不同的 Chunk 策略和 Metadata。
FAQ 是客服命中率最高的数据。
推荐使用 JSON，而不是 Word 或 Excel。
示例：
{
"id":10001,
"category":"refund",
"question":"退款多久到账？",
"similar_questions":[
"退款什么时候到账",
"多久能收到退款",
"退款几天到账"
],
"answer":"退款一般会在1~3个工作日原路退回。",
"keywords":[
"退款",
"到账"
],
"priority":10,
"version":1
}Embedding 内容建议：
Question
+
Similar Questions
+
Keywords
+
Answer例如：
退款多久到账？
退款什么时候到账
多久收到退款
退款
到账
退款一般1~3个工作日到账相比只 Embedding Answer，召回率会明显提高。
不同数据结构完全不同，因此不能统一按照 500 Token 切片。
特点：
Chunk：
Question
+
Answer一个 FAQ 就是一个 Chunk。
不要跨 FAQ 合并。
例如：
商品说明书
电池
屏幕
摄像头
充电
尺寸Chunk：
按照功能模块切分。
Chunk1
电池
支持80公里续航
------------
Chunk2
充电
支持20W快充
------------
Chunk3
摄像头
4800万像素建议：
200~500 Token。
例如：
退款政策
换货政策
保修政策每条政策作为一个 Chunk。
例如：
退款政策
7天无理由退款
......
========
换货政策
质量问题30天可换不要把所有政策放到一个 Chunk。
物流 FAQ 一般也是一问一答。
例如：
物流一直没更新怎么办？
↓
等待24小时一条物流规则就是一个 Chunk。
PDF 通常几十页。
不要固定长度切片。
建议：
章节
↓
一级标题
↓
二级标题
↓
正文例如：
第一章
安全说明
Chunk1
-----------------
第二章
安装说明
Chunk2
-----------------
第三章
保养说明
Chunk3建议：
300~600 Token。
例如：
隐私协议
退款协议
会员协议协议内容较长。
建议：
按照章节切。
例如：
第一章
定义
第二章
用户权利
第三章
免责声明建议：
500~800 Token。
Metadata 的作用：
不是给模型看的。
而是给 Retriever 做过滤（Filter）。
例如：
用户：
退款多久到账可以直接过滤：
category=refund减少无关召回。
{
"id":10001,
"category":"refund",
"priority":10,
"version":1,
"language":"zh",
"source":"faq.json"
}适用于：
{
"product":"Bike-A100",
"category":"battery",
"model":"2026",
"language":"zh",
"version":"2.1"
}适用于：
不同型号商品。
例如：
Bike A100
Bike A200直接过滤：
product=A100避免命中错误型号。
{
"policy":"refund",
"country":"CN",
"version":"2026",
"effective_time":"2026-01-01"
}例如：
不同国家退款政策不同。
Retriever 可以直接过滤：
country=JP{
"product":"Camera-X1",
"chapter":"安装",
"language":"zh",
"source":"manual.pdf"
}便于后续定位来源。
{
"intent":"refund",
"emotion":"angry",
"score":5,
"agent":"AI"
}以后可以专门学习：
退款
+
愤怒用户优秀回复。
不同数据最终都会进入统一的 Embedding Pipeline。
Document
│
▼
Document Loader
│
▼
Parser
│
▼
Semantic Chunk
│
▼
Metadata Enrichment
│
▼
Embedding
│
▼
Milvus整个流程建议离线完成。
不要在用户提问时实时生成 Embedding。
推荐采用两阶段检索。
User Query
│
▼
Intent Router
│
▼
Collection
│
▼
Retriever
Top20
│
▼
Reranker
Top5
│
▼
LLM为什么需要 Reranker？
Retriever 擅长"找得到"。
Reranker 擅长"排得准"。
例如：
用户：
钱怎么还没退？Retriever 可能返回：
退款多久到账
退款失败
退款流程Reranker 会重新排序：
①退款多久到账（最高）
②退款流程
③退款失败最终送入 LLM 的就是最相关的 Top5。
knowledge/
├── faq/
│ ├── refund.json
│ ├── logistics.json
│ ├── payment.json
│ └── account.json
│
├── products/
│ ├── bike_a100.md
│ ├── iphone16.md
│ └── camera.md
│
├── policy/
│ ├── refund.md
│ ├── exchange.md
│ └── warranty.md
│
├── manuals/
│ ├── user_manual.pdf
│ └── quick_start.pdf
│
└── examples/
├── excellent_cases.json
└── standard_reply.json每类数据使用独立的 Chunk 策略、Metadata 和 Collection，可以有效提高召回准确率和维护效率。
一个企业级 AI 客服 RAG 的核心设计原则如下：
| 模块 | 推荐方案 |
|---|---|
| 知识库划分 | FAQ、商品、物流、售后、政策、手册、优秀案例独立管理 |
| FAQ 数据格式 | JSON，一问一答，支持 Similar Questions、Keywords |
| Chunk 策略 | FAQ 按问答切、商品按功能切、政策按条款切、PDF 按章节切 |
| Embedding 内容 | Question + Similar Questions + Keywords + Answer |
| Metadata | 根据业务设计，如 category、product、policy、country、version 等 |
| 检索流程 | Intent Router → Retriever(Top20) → Reranker(Top5) → LLM |
| 向量库 | Milvus（生产）、Chroma（开发） |
| 更新方式 | 离线索引，支持版本管理与增量更新 |
核心思想：不要让所有知识采用同一种 Chunk、同一种 Metadata、同一种检索策略，而应根据数据特点进行分类设计。只有知识组织合理，RAG 才能真正发挥效果，支撑生产级 AI 客服系统。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。