AI 客服系统设计：RAG 知识库设计

在 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
                     │
                     ▼
                  最终回答

整个流程分为四步：

1. 根据用户问题识别业务意图（Intent）
2. 路由到对应知识库（Collection）
3. Retriever + Reranker 获取最相关知识
4. LLM 结合 Memory 生成最终回复

---

二、知识库如何规划

不要把所有知识混到一个 Collection。

建议按照业务拆分。

knowledge/

├── faq/
├── products/
├── logistics/
├── after_sale/
├── payment/
├── activity/
├── policy/
├── manuals/
└── excellent_cases/

每一类数据都有不同特点，因此需要采用不同的 Chunk 策略和 Metadata。

---

三、FAQ 知识设计

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，召回率会明显提高。

---

四、不同数据采用不同 Chunk 策略

不同数据结构完全不同，因此不能统一按照 500 Token 切片。

1）FAQ

特点：

• 一问一答
• 内容短
• 独立性强

Chunk：

Question

+

Answer

一个 FAQ 就是一个 Chunk。

不要跨 FAQ 合并。

---

2）商品知识

例如：

商品说明书

电池

屏幕

摄像头

充电

尺寸

Chunk：

按照功能模块切分。

Chunk1

电池

支持80公里续航

------------

Chunk2

充电

支持20W快充

------------

Chunk3

摄像头

4800万像素

建议：

200~500 Token。

---

3）售后政策

例如：

退款政策

换货政策

保修政策

每条政策作为一个 Chunk。

例如：

退款政策

7天无理由退款

......

========

换货政策

质量问题30天可换

不要把所有政策放到一个 Chunk。

---

4）物流知识

物流 FAQ 一般也是一问一答。

例如：

物流一直没更新怎么办？

↓

等待24小时

一条物流规则就是一个 Chunk。

---

5）PDF 产品手册

PDF 通常几十页。

不要固定长度切片。

建议：

章节

↓

一级标题

↓

二级标题

↓

正文

例如：

第一章

安全说明

Chunk1

-----------------

第二章

安装说明

Chunk2

-----------------

第三章

保养说明

Chunk3

建议：

300~600 Token。

---

6）用户协议

例如：

隐私协议

退款协议

会员协议

协议内容较长。

建议：

按照章节切。

例如：

第一章

定义

第二章

用户权利

第三章

免责声明

建议：

500~800 Token。

---

五、不同数据采用不同 Metadata

Metadata 的作用：

不是给模型看的。

而是给 Retriever 做过滤（Filter）。

例如：

用户：

退款多久到账

可以直接过滤：

category=refund

减少无关召回。

---

FAQ Metadata

{
    "id":10001,
    "category":"refund",
    "priority":10,
    "version":1,
    "language":"zh",
    "source":"faq.json"
}

适用于：

• FAQ
• 常见问题

---

商品知识 Metadata

{
    "product":"Bike-A100",
    "category":"battery",
    "model":"2026",
    "language":"zh",
    "version":"2.1"
}

适用于：

不同型号商品。

例如：

Bike A100

Bike A200

直接过滤：

product=A100

避免命中错误型号。

---

售后政策 Metadata

{
    "policy":"refund",
    "country":"CN",
    "version":"2026",
    "effective_time":"2026-01-01"
}

例如：

不同国家退款政策不同。

Retriever 可以直接过滤：

country=JP

---

产品手册 Metadata

{
    "product":"Camera-X1",
    "chapter":"安装",
    "language":"zh",
    "source":"manual.pdf"
}

便于后续定位来源。

---

优秀客服案例 Metadata

{
    "intent":"refund",
    "emotion":"angry",
    "score":5,
    "agent":"AI"
}

以后可以专门学习：

退款

+

愤怒用户

优秀回复。

---

六、Embedding 流程

不同数据最终都会进入统一的 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 客服系统。