RAG客服系统：检索增强生成RAG

可视化演示

演示文档分块嵌入、向量检索Top-K与上下文增强生成，理解RAG结合外部知识提升LLM回答准确性的流程。

RAG 基本概念：为什么大厨需要菜谱库

你餐厅那位天才主厨，背过上万个菜谱，可一旦顾客问起新菜、小众菜，他要么面红耳赤地沉默，要么一本正经地胡诌——“斐济名菜？加半斤盐，猛火三小时！”把顾客吓得不轻。作为老板，你需要的不是让他背更多菜谱，而是给他一个随时能翻的菜谱库。这正是 RAG（Retrieval-Augmented Generation，检索增强生成）的设计初衷：不改变模型本身，而是给模型接一个“外部记忆”。

客服场景的痛点也是如此。用户问“你们的退款什么时候到账”，模型大概率没背过你们公司的财务政策，但知识库里躺着标准答案。RAG 先把问题拿去检索，捞出最相关的政策条文，再让模型基于条文组织回答。与“重新训练模型”相比，RAG 可以随时增删知识、不用花高昂的微调成本，是知识密集型场景最务实的方案。

标准 RAG 流程包含三个阶段：检索（Retrieval）、增强（Augmentation）、生成（Generation），可以浓缩为下面的过程：

$$\mathcal{R}(q) = \operatorname*{TopK}_{d \in D} \operatorname{Sim}(q, d), \qquad \hat{y} = \operatorname{LLM}\big(\operatorname{Aug}(q, \mathcal{R}(q))\big)$$

1. 知识库 D：存放全部客服资料（退换货、物流、发票政策）的文档集合，相当于整座菜谱库。

$$\mathcal{D}$$

2. 相似度函数 Sim：衡量问题 $q$ 与每篇文档 $d$ 语义接近程度的函数，分数越高越相关。

$$\operatorname{Sim}(q, d)$$

3. TopK 截断：从所有文档中只取分数最高的 $K$ 份，过滤无关噪声，控制输入长度。

$$\operatorname*{TopK}_{d \in D}$$

4. 增强 Aug：把检索到的片段与原始问题拼装成标准 Prompt，相当于把菜谱摊开在操作台上。

$$\operatorname{Aug}\big(q, \mathcal{R}(q)\big)$$

5. 生成 LLM：大模型阅读增强后的输入，产出一条有据可依的回答。

$$\hat{y} = \operatorname{LLM}(\cdot)$$

整个过程就是给主厨装了一台“菜谱检索机”：先翻索引（检索）、把相关页摊开（增强）、照着菜谱开口（生成）。主厨还是那个主厨，但有了外挂菜谱，他再也不会上来就“加半斤盐”。

向量检索原理：给菜谱贴“口味坐标”

如果菜谱库只有五十本，靠人工分类完全可以——川菜、粤菜、甜点各放一柜。可库藏达到几万本时，人工整理就崩了：“水煮鱼”该放川菜还是热菜？顾客问“哪道菜又辣又下饭”，按柜子找根本答不上来。RAG 需要更聪明的办法：给每一份菜谱和每一个问题都贴上一组“口味坐标”，用坐标距离判断“像不像”。

这组“口味坐标”就是向量（Embedding）。Embedding 模型能把任意一段文本（一句话、一篇文档）转换成一串几百上千维的浮点数向量。语义相近的文本，向量在空间中的方向就接近；语义风马牛不相及，方向就相差很远。这些向量不会存在普通表格里，而是存入向量数据库——一种专门按“高维坐标就近查找”设计的索引柜。

如何度量两个向量“像不像”？最常用的是余弦相似度：

$$\operatorname{sim}(q, d) = \frac{q \cdot d}{\lVert q \rVert_2 \cdot \lVert d \rVert_2}$$

1. 点积：两个向量逐维度相乘再求和，量化方向一致性，方向越一致数值越大。

$$q \cdot d$$

2. L2 范数：向量各维度平方和再开方，代表向量长度，写在分母用于消除文本长短的影响。

$$\lVert q \rVert_2 = \sqrt{\sum_{i} q_i^2}$$

3. 归一化比值：用点积除以两个长度的乘积，只看方向、不看长度，得到稳定的相似度分数。

$$\frac{q \cdot d}{\lVert q \rVert_2 \cdot \lVert d \rVert_2}$$

回到餐厅：每份菜谱被画成一个“口味坐标点”，顾客的问题也被画成一个坐标点。“水煮鱼”和“毛血旺”坐标挨得很近，系统一眼就能判断“这位客人要川味重口”。坐标怎么存、怎么快速找邻居，正是向量数据库的看家本领。

检索与重排：海选与决赛的配合

几万份菜谱，顾客问一句“适合小孩吃的清淡菜”，理论上可以跟所有菜谱逐一算相似度，但每次都全量计算实在太慢太贵。聪明的餐厅分两步：先“海选”，用快而粗的法子从几万份里捞出前 100 份候选；再“决赛”，用精而细的法子从 100 份里排出前 3 名。这就是召回（Recall）与重排（Rerank）的分工。

召回的常见策略有三种：纯向量检索（语义理解好）、BM25 关键词检索（订单号、型号等精确匹配好），以及两者结合的混合检索。多路召回得到几份不同的排名列表后，怎么合并成一份？常用 RRF（Reciprocal Rank Fusion，倒数排名融合）：

$$\operatorname{RRF}(d) = \sum_{r \in \mathcal{R}} \frac{1}{k + r(d)}$$

1. 候选集合 R：向量检索、BM25 等多路召回各自返回的排名列表的集合。

$$\mathcal{R}$$

2. 排名位置 r(d)：文档 $d$ 在某一列表中的名次，从 1 开始。

$$r(d)$$

3. 加权融合：对每路结果求 $\frac{1}{k + r(d)}$ 再相加，各路都靠前的文档获得最高融合分。

$$\sum_{r \in \mathcal{R}} \frac{1}{k + r(d)}$$

重排阶段通常用一个更强大、也更慢的 Reranker 模型，对海选出的 Top-100 精读后打精细分，最终只把 Top-K（一般取 3~5）作为上下文送进大模型。K 太小容易漏关键信息，太大则稀释注意力、抬高成本。对应餐厅：跑堂小二先抱来一百本“可能沾边”的菜谱（召回），主厨亲自快速翻一遍，只留三本真正对得上胃口的摊在操作台上（重排）。既快，又不失精准。

注入与生成：把菜谱摆上操作台，开火

检索到的三份菜谱如何变成一道成品菜？直接把文档和问题一股脑扔给模型说“回答吧”？当然不行——就像你不能把三本菜谱连盘子一起摔进锅里。这一步叫注入（Augmentation）：把用户问题、检索到的上下文、系统指令按模板拼装成 Prompt。Prompt 的结构直接影响回答质量，客服场景通常包含三层：人设指令（“你是一位严谨的客服助手，请严格依据资料回答”）、检索上下文、用户问题。

注入了上下文之后，上下文管理也是门学问：内容过长会被截断，多份自相矛盾的文档会让模型左右为难。工程上通常会对检索片段做去重、按与问题的相关度重排，并在 Prompt 中明确“资料不足时请直接说不知道”。从数学角度看，RAG 的生成阶段可表示为：

$$\hat{y} = \operatorname*{arg\,max}_{y} \prod_{t=1}^{T} P\big(y_t \mid q, \mathcal{R}(q), y_{<t}\big)$$

1. 生成条件：预测第 $t$ 个词时，模型同时参考问题、检索文档和已生成词，保证回答不离谱。

$$P\big(y_t \mid q, \mathcal{R}(q), y_{<t}\big)$$

2. 连乘：整句概率等于每个词条件概率的乘积，让模型整体权衡，而不是只看局部。

$$\prod_{t=1}^{T} P\big(y_t \mid q, \mathcal{R}(q), y_{<t}\big)$$

3. arg max 寻优：在所有可能的回答中找出概率最高的那条，作为最终输出。

$$\hat{y} = \operatorname*{arg\,max}_{y} \prod_{t=1}^{T} P(\cdot)$$

对应餐厅：操作台上摆好三本菜谱、附带顾客备注“少辣、不要香菜”，主厨照着这些情报动火炒菜。菜是菜谱里的做法，但口味完全贴合眼前这位客人——这就是“增强”在生成阶段的价值。

客服系统实战：把流水线搬进生产环境

光有算法还不够，你要把它变成一天能服务一万个顾客的“智能咨询台”。生产级客服系统的典型链路是：用户提问 → 检索服务（向量库 ANN 搜索 + 重排）→ 生成服务（大模型推理）→ 返回答案。链路背后还有一条知识库流水线：把散落的政策文档、FAQ 表格清洗、去重、切分成合适的片段，再用 Embedding 模型向量化，写入向量数据库。

工程上要先算清成本账。大模型 API 按 token 计费，RAG 每个环节都在花钱，单次请求的成本模型可以这样拆：

$$\text{Cost} = C_{\text{embed}} + C_{\text{search}} + C_{\text{prompt}} + C_{\text{output}}$$

1. 向量化成本：用 Embedding 模型把用户问题转成向量，按调用次数计费。

$$C_{\text{embed}}$$

2. 检索成本：向量数据库的 ANN 近似近邻搜索和重排模型计算的机器开销。

$$C_{\text{search}}$$

3. 输入成本：注入的 Prompt 上下文越长，输入侧 token 费用越高，所以 Top-K 必须克制。

$$C_{\text{prompt}}$$

4. 输出成本：回答越长，生成侧费用越高，需要设置 max tokens 上限。

$$C_{\text{output}}$$

除了成本，还有三件事必须做：限流与缓存——高频常见问题直接走缓存，别每次都搜库调模型；隐私脱敏——用户姓名、手机号在入知识库前要清洗；引用溯源——回答必须附带“哪些文档片段支撑了这句话”，方便审计和排错。对应餐厅：咨询台从“厨师口述”升级为“标准流水线”——点菜（提问）、传菜员到档案柜取证（检索）、后厨统一炒制（生成）、上菜附上菜谱页码（溯源）。流程标准化，才能规模化。

效果评估：试菜员与顾客共同打分

菜好不好吃，不能只靠厨师自夸。客服 AI 也一样，上线前必须“试菜”：准备一批带标准答案的测试问题集，让 RAG 系统跑一遍，再从多个维度打分。评估要分开看：检索好不好是一回事，回答好不好是另一回事，两者可能互相拖后腿。

衡量“检索好不好”的核心指标之一是召回率 Recall@K——知识库里真正相关的文档，有多少被成功捞了出来：

$$\operatorname{Recall@K} = \frac{\lvert \text{相关文档} \cap \text{TopK 文档} \rvert}{\lvert \text{相关文档} \rvert}$$

1. 交集数量：检索返回的 TopK 文档与人工标注的相关文档重叠的个数。

$$\lvert \text{相关文档} \cap \text{TopK 文档} \rvert$$

2. 相关文档总数：标注集中与这个问题有关的全部文档数量。

$$\lvert \text{相关文档} \rvert$$

3. 比值：分子除分母，满分 1.0，反映检索的“全不全”。

$$\frac{\lvert \text{相关文档} \cap \text{TopK 文档} \rvert}{\lvert \text{相关文档} \rvert}$$

回答质量则常用 RAGAS 框架——一套专为 RAG 设计的自动评估指标，重点关注三维度：忠实度（回答是否严格基于检索文档、没有自行发挥）、答案相关性（是否正面回答问题）、上下文相关性（检索内容是否与问题相关）。落地时结合人工抽检，形成“评测 → 发现短板 → 调优（换 Embedding、调 chunk 大小、加 Reranker）→ 再评测”的闭环。对应餐厅：Recall@K 是试菜员核对“端上来的菜是否覆盖顾客真想要的菜”，RAGAS 是逐口检查色香味是否达标。有了打分表，厨师改进才有方向。

常见问题：餐厅的兜底预案

运营一年，咨询台难免遇到幺蛾子，最典型三类：幻觉（检索没捞到好东西，模型开始胡编）、检索失败（知识库明明有答案却搜不到）、知识更新慢（涨价政策改了三天，库还是旧的）。这些问题不是“可能遇到”，而是“一定会遇到”，需要提前设计防线。

要对“回答是否靠谱”做量化判断，工程上常用忠实度（Faithfulness）指标：

$$\text{Faithfulness} = \frac{\text{回答中被检索文档支持的句子数}}{\text{回答总句子数}}$$

1. 支持句数：逐句比对，句子的关键信息能在检索文档中找到对应依据，才算“支持”。

$$\text{回答中被检索文档支持的句子数}$$

2. 总句子数：大模型生成回答包含的全部句子数量。

$$\text{回答总句子数}$$

3. 忠实度比值：结果越接近 1 说明回答越脚踏实地；明显低于 0.7 就要警惕幻觉风险。

$$\frac{\text{支持句数}}{\text{总句子数}}$$

对策是体系化的：检索端用混合检索 + 更细粒度切分提高命中率；生成端在 Prompt 中写明“资料不足时必须回答不知道”；知识端建立定期重建索引的更新流水线；系统层面再加一道兜底话术——当检索最高得分低于阈值时，直接转人工客服。对应餐厅：厨师偶尔还是会说错菜名（幻觉），那就加保险——没有十足把握的菜，直接说“这道菜我不确定，请让经理来”。正是这些兜底预案，才让 RAG 客服系统真正顶住真实世界的考验。

AI 应用场景

Python 演示

import mathimport refrom collections import Counter  class SimpleRAG:    """简化版 RAG 客服系统：TF-IDF 检索 + 模板生成"""     def __init__(self):        self.docs = {}        self.doc_vectors = {}        self.idf = {}        self.k = 3  # 默认召回 Top-K     def tokenize(self, text):        """中文按字符 bigram 切分，兼顾鲁棒性"""        text = re.sub(r'\s+', '', text)        if len(text) <= 1:            return [text]        return [text[i:i + 2] for i in range(len(text) - 1)]     def fit(self, knowledge_base):        """构建知识库：doc_id -> 文本，并计算 TF-IDF 向量"""        self.docs = knowledge_base        doc_tf = {}        df = Counter()        for doc_id, text in knowledge_base.items():            tokens = self.tokenize(text)            tf = Counter(tokens)            doc_tf[doc_id] = tf            df.update(set(tokens))        n_docs = len(knowledge_base)        self.idf = {            token: math.log((n_docs + 1) / (freq + 1)) + 1            for token, freq in df.items()        }        self.doc_vectors = {}        for doc_id, tf in doc_tf.items():            vec = {}            for token, count in tf.items():                vec[token] = count * self.idf.get(token, 0)            norm = math.sqrt(sum(v * v for v in vec.values()))            if norm > 0:                vec = {t: v / norm for t, v in vec.items()}            self.doc_vectors[doc_id] = vec     def retrieve(self, query, k=None):        """检索：返回 (doc_id, score) 列表，按余弦相似度降序"""        k = k or self.k        q_tf = Counter(self.tokenize(query))        q_vec = {}        for token, count in q_tf.items():            q_vec[token] = count * self.idf.get(token, 0)        q_norm = math.sqrt(sum(v * v for v in q_vec.values()))        if q_norm > 0:            q_vec = {t: v / q_norm for t, v in q_vec.items()}        scores = []        for doc_id, doc_vec in self.doc_vectors.items():            score = sum(q_vec.get(t, 0) * w for t, w in doc_vec.items())            scores.append((doc_id, score))        scores.sort(key=lambda x: x[1], reverse=True)        return scores[:k]     def generate(self, query, top_docs):        """生成：把检索结果拼成上下文，套模板输出回答"""        context = '\n'.join(self.docs[did] for did, _ in top_docs)        return '根据知识库，关于「{}」的回答：\n{}'.format(query, context[:120])     def ask(self, query):        """完整 RAG 流程：检索 -> 增强 -> 生成"""        top_docs = self.retrieve(query)        return self.generate(query, top_docs)  if __name__ == '__main__':    kb = {        "kb01": "退换货政策：自签收之日起7天内支持无理由退换货。",        "kb02": "物流查询：标准快递预计3-5个工作日送达。",        "kb03": "退款说明：退款将在1-3个工作日原路退回。",        "kb04": "会员积分：每消费1元累计1积分，积分可兑换优惠券。",        "kb05": "发票开具：支持电子发票，下单后可在线申请。",    }    bot = SimpleRAG()    bot.fit(kb)    top = bot.retrieve("怎么申请开发票")    print("Top 命中：", [did for did, _ in top])    print(bot.ask("怎么申请开发票"))

1. def tokenize(self, text)按中文 bigram 切分文本，让“退款多久到”这类短句也能提取出可匹配的特征。
2. df.update(set(tokens))统计每个词出现在多少篇文档中，这是计算 IDF（逆文档频率）的基础。
3. self.idf = {...}词越罕见 IDF 越高，避免“的”“了”这类高频词主导相似度。
4. vec[token] = count * self.idf.get(token, 0)用 TF 乘以 IDF 得到词的权重，构成文档向量。
5. norm = math.sqrt(...)计算向量长度，后面用它做归一化，消除文档长短的影响。
6. scores.sort(key=lambda x: x[1], reverse=True)按相似度从高到低排序，取出 Top-K 个文档。
7. context = '\n'.join(self.docs[did] for did, _ in top_docs)把命中的文档拼成上下文，这就是“注入”增强。
8. bot.ask("怎么申请开发票")一行调用走完“检索 → 增强 → 生成”全流程。

常见误区

面试题