# 一. 什么是 RAG RAG 即 **检索增强生成**（Retrieval-Augmented Generation），是一种将 **信息检索** 与 **大语言模型生成** 相结合的 AI 架构。 它的核心思路非常简单： 1. 用户提出问题 2. 系统先从知识库中 **检索** 出相关内容 3. 将检索到的内容连同问题一起交给大模型 4. 大模型基于这些"证据"**生成** 回答 **类比理解**：大模型像一个博学的老师，但不了解你公司的具体情况。RAG 就是给老师配了一个助手，先帮老师查阅公司的规章制度和业务资料，老师再基于这些材料给出建议。 RAG 的概念最早来自 2020 年 Meta/FAIR 的论文，提出了 RAG-Sequence 与 RAG-Token 两种经典范式（按序列或按 Token 融合检索证据），此后迅速成为 AI 应用的主流架构。 # 二. 为什么需要 RAG ## 1\. 大模型的固有缺陷 尽管大模型能力强大，但存在几个无法回避的问题： | **问题** | **表现** | **举例** | | --- | --- | --- | | 知识固化 | 训练后无法自动更新知识，存在"知识截止日期" | 无法回答最新发布的产品信息 | | 幻觉问题 | 没有答案时会"一本正经地胡说八道" | 编造不存在的政策条文 | | 缺乏私有知识 | 不具备企业内部数据和业务规则 | 无法回答"我们平台退货包运费吗？" | | 上下文窗口有限 | 无法一次性处理超长文档 | 无法读完一本超长的产品手册再回答 | ## **2\. RAG 的优点** - **回答更准确**：基于真实数据生成，避免"凭空编造"的问题 - **知识实时更新**：更新知识库即可，无需重新训练模型 - **可溯源、可验证**：每个回答都能追溯到具体的检索来源 - **成本更低**：相比模型微调，RAG 是更轻量的解决方案 - **领域适配强**：接入私有知识库，瞬间变成"领域专家" ## 3\. RAG 的缺点 - **系统复杂度增加**：引入检索环节会增加响应延迟，研究表明检索环节占 RAG 总耗时的 60% 以上 - **可能会降低准确性：**对于长文档问答，和给完整的文档作为上下文相比，检索召回的数量有限，比如你跟他说“帮我总结整本书的内容”，可能只总结了一部分 - **不能完全消除幻觉**：RAG 降低了幻觉概率，但不能让模型完全无误 ## 4\. RAG 典型应用场景 | **场景** | **描述** | **RAG 价值** | | --- | --- | --- | | 🛒 电商客服 | 回答商品咨询、退换货政策、订单查询 | 基于平台真实数据回答，避免模型胡编 | | 📚 企业知识库 | 员工查询内部制度、SOP、产品文档 | 让内部知识即时可查，提高查询效率，降低沟通成本 | | 🏥 医疗问答 | 基于医学文献和诊疗指南回答专业问题 | 降低幻觉风险，提供可溯源的专业回答 | | ⚖️ 法律咨询 | 基于法规条文和判例回答法律问题 | 引用具体法条，提升回答权威性 | | 📊 研究分析 | 基于行业报告和市场数据生成分析 | 整合多源信息，提供有据可依的洞察 | ## 5\. RAG vs 微调：如何选择？ 作为 AI 产品经理，经常需要在 RAG 和微调之间做选择。两者的目标相同——让模型在特定领域表现更好，但路径完全不同。 | **对比维度** | **RAG** | **微调（Fine-tuning）** | | --- | --- | --- | | 核心思路 | 让模型"查资料"再回答 | 让模型"学会"特定领域知识 | | 知识更新 | ✅ 更新知识库即可，秒级生效 | ❌ 需要重新训练，周期长 | | 成本 | ✅ 低，无需大量 GPU | ❌ 高，需要算力和标注数据 | | 可解释性 | ✅ 可追溯到具体来源 | ❌ 黑箱，难以解释 | | 适用场景 | 知识密集型问答、客服、搜索 | 风格迁移、格式规范、特定推理能力 | | 数据需求 | 非结构化文档即可 | 高质量标注数据 | **实践建议**：在大多数业务场景中，**优先考虑 RAG**，因为它成本低、见效快、易维护。只有当 RAG 无法满足特定需求（如调整模型的输出风格或推理模式）时，才考虑微调。两者也可以结合使用。 # 三. RAG 的整体架构 RAG 系统的完整工作流程可以分为两大阶段：**离线数据准备** 和 **在线查询响应**。 ## **1\. 📦 离线阶段：数据准备** ```mermaid flowchart LR A["原始文档
(PDF/网页/FAQ等)"] --> B["数据清洗
与提取"] B --> C["文本分片
(Chunking)"] C --> D["向量化
(Embedding)"] D --> E["存入向量数据库"] ``` ## **2\. 🔍 在线阶段：查询响应**（从向量数据库检索） ```mermaid flowchart LR F["用户提问"] --> G["Query 处理
(改写/扩展)"] G --> H["向量检索
(Top-K)"] H --> I["重排序
(Rerank)"] I --> J["构建 Prompt"] J --> K["LLM 生成回答"] K --> L["返回用户"] ``` # 四. RAG 工作链路详解 ## 1\. 离线阶段：数据准备 数据准备是 RAG 系统的"地基"，直接决定了后续检索和生成的质量。 ### 1.1 数据提取与清洗 将各类原始数据（PDF、Word、网页、FAQ、音视频、图片等）统一处理为可用的文本格式 > 现在也有多模态的向量模型，比如[Jina CLIP](https://jina.ai/zh-CN/news/jina-clip-v1-a-truly-multimodal-embeddings-model-for-text-and-image/)，可以直接将图片转为向量。 **以电商客服为例：** - **参考数据源** - 帮助中心与FAQ（退换货、运费、发票、质保） - 客服 SOP 与话术（不同场景的处理流程和话术） - 商品信息（规格参数、商品介绍、使用说明） - 订单与物流字段说明（状态含义、异常件类型解释） - 历史的客服对话记录 - **提取与清洗步骤** 1. **结构化关键信息**：把政策中的 **适用范围、条件、例外、时效、责任方** 拆成清晰条目。 2. **标准化术语**：统一同义词（如“包邮”“免运费”“运费全免”）与字段命名（如“退款成功”“退款完成”）。 3. **补足上下文**：为容易歧义的条款补齐前提（如“7 天无理由”是否排除定制类目）。 - **输出形态建议** - **结构化知识：**如FAQ，方便精准命中高频问题。 - **非结构化知识**：不必硬改为 Q&A 格式，保持原有文档结构即可，具体的分片处理策略和最佳实践详见下一节。 ### 1.2 文本分片（Chunking） 将长文档切成语义相对独立、长度适中的小片段。这是影响 RAG 效果的**关键**。 **主流分片策略：** | **分片策略** | **描述** | **优点** | **缺点** | | --- | --- | --- | --- | | 固定大小切片 | 按固定的 Token 或字符数量直接将文本截断，通常配合设置一定的重叠量防止语义被硬性切断 | 逻辑最简单，处理速度最快，计算成本极低，不需要复杂的解析逻辑 | 极其容易破坏句子的完整语义，导致检索到的内容缺乏上下文（例如把一个长句从中间劈开） | | 分隔符切片 | 根据多种字符（如\\n\\n、\\n、中文句号、英文句号）来分割。 | 实现简单，比固定大小切片更好地保留语义完整性，按自然段落或句子边界切分，通用性强 | 对于结构极其复杂的长篇文档，依然可能在极限情况下出现轻微的语义截断 | | 基于文档结构切片 | 针对特定格式文档（Markdown、HTML、PDF、Word），利用其自带的结构标签（标题层级、表格、段落节点）进行精准分割 | 完美保留作者的原始排版逻辑、章节上下文以及表格等富文本信息 | 极度依赖文档本身的格式规范度，且切分出的文本块大小可能极其不均匀（有的章节只有一句话，有的章节有几千字） | | 语义切片 | 先将文本拆分成极小的基本单元（如单句），计算相邻句子的 Embedding 向量相似度；当相似度急剧下降（出现"断崖"）时，在此处执行切分 | 能够最大程度保证每个文本块内部的语义高度聚焦、连贯且独立 | 需要进行大量的前置 Embedding 相似度计算，处理耗时较长，对算力资源要求较高 | | 基于大模型的切片 | 利用 LLM 在入库前预处理文档，通过"**命题提取**"将复杂长段落拆解、重写为多个独立、自包含的短陈述句（补全代词和缺失上下文），再进行切分和向量化 | 检索精度极高，彻底解决了传统切片中代词指代不明或上下文缺失导致的检索失败问题 | 预处理时的 Token 消耗巨大，构建知识库的速度非常缓慢。 | 通常只适用于高价值、高频检索的核心数据 | **分片最佳实践：** 除了选择合适的分片策略，以下实践可以显著提升分片质量和检索效果： - **拼接上下文前缀**：每个分片自动拼接上级标题，确保单独检索到时仍能理解语境（如 `[第三章 退换货政策 > 3.2 七天无理由 > 适用范围] 正文内容……`） - **生成元数据**：为每个分片补充一句话摘要、适用场景标签、假设性问题，提升检索召回率 - **保留完整步骤**：操作/流程类内容按步骤节点切分，避免把一个完整流程拆散到多个分片中
**命题提取**是 RAG 中一种高级的文本预处理技术，核心思想是：**在入库前用大模型将复杂段落拆解、改写为多个独立、自包含的短陈述句**。 **（1）为什么需要它？** 传统切片方式有一个常见痛点：切出来的文本块里经常包含代词（"它""该产品""上述情况"）或省略了前文的关键上下文，导致这个片段**单独拿出来看时语义不完整**，检索时就容易匹配失败。 **（2）怎么做？** 用 LLM 对原始段落做如下处理： 1. **拆解**：把一个长段落拆成多个独立的事实陈述 2. **补全**：把代词还原为具体实体，把省略的前提条件补上 3. **重写**：确保每个短句**不依赖任何上下文就能被理解** **（4）举个例子** **原始段落：** > 我们平台的七天无理由退货政策适用于大部分商品。但定制类和生鲜类除外。它的退货运费由买家承担。 **命题提取后：** - "该平台的七天无理由退货政策适用于大部分商品。" - "定制类商品不适用七天无理由退货政策。" - "生鲜类商品不适用七天无理由退货政策。" - "七天无理由退货的退货运费由买家承担。" 每一条都是**自包含、无歧义**的独立陈述，检索时匹配精度会大幅提升。 ### 1.3 向量化（Embedding） 将每个文本分片通过 Embedding 模型转换为高维向量。向量之间的距离反映了语义相似度——意思越接近的内容，向量空间中的距离越近。 **Embedding 模型选型** 可以参考 MTEB LeaderBoard（目前最全面的向量模型评测榜单，覆盖检索、分类、聚类、语义相似度等多个维度，地址是 [https://huggingface.co/spaces/mteb/leaderboard](https://huggingface.co/spaces/mteb/leaderboard)[）](https://huggingface.co/spaces/mteb/leaderboard%EF%BC%89) **闭源商业 API** | **模型名称** | **特点与适用场景** | 链接 | | --- | --- | --- | | OpenAI `text-embedding-3-small/large` | 目前性价比和综合效果的标杆，适合追求极致效果、不想折腾部署的场景 | [https://developers.openai.com/api/docs/models/text-embedding-3-small](https://developers.openai.com/api/docs/models/text-embedding-3-small) | | Cohere `embed-multilingual-v3.0` | 多语言支持极佳，配套 Rerank 模型业界顶流 | [https://cohere.com/blog/introducing-embed-v3](https://cohere.com/blog/introducing-embed-v3) | | 豆包 `doubao-embedding` | 字节跳动火山引擎出品，支持中英双语，维度最高 2048，适合国内网络环境 | [https://www.volcengine.com/docs/82379/1521766?lang=zh](https://www.volcengine.com/docs/82379/1521766?lang=zh) | | 通义千问 `text-embedding-v3` | 阿里云出品，支持多语言，维度最高 2048，中文语境表现稳定 | [https://help.aliyun.com/zh/model-studio/text-embedding-synchronous-api](https://help.aliyun.com/zh/model-studio/text-embedding-synchronous-api) | **开源私有化部署** | **模型名称** | **特点与适用场景** | | --- | --- | | BGE (BAAI General Embedding) | 中文及多语言开源领域标杆，各大榜单长期霸榜，闭眼选默认方案 | | M3E (Moka Massive Mixed Embedding) | 中文开源圈经典，垂直领域理解深，FastGPT/Dify 等常作默认推荐 | | Jina Embedding | 支持超长上下文（如 8k+ Token），适合超大文档整体向量化 | | Nomic Embed | 全开源、支持长上下文，英文和代码检索表现优异 |
**选型建议：** - **0-1 测试项目**：直接接 OpenAI 的 `text-embedding-3-small`，省心且便宜。 - **企业级应用**：考虑到数据合规与安全，本地部署开源的 `BGE-m3` 或 `M3E` 是目前最稳妥的方案。 ### 1.4 存入向量数据库 将生成的向量及其对应的原文和元数据存入向量数据库，构建可快速查询的索引。 **（1）结构** 向量数据库包括集合（相当于表）和集合数据（想到于表里的每行的数据） 每个集合有向量和标量字段 - **ID（必须）：**主键 - **向量字段（必须且只有一个）：**就是存储向量化后的数据 - **标量字段（可选，可自定义多个）**：原文内容、来源文档名、章节标题、更新时间、标签等 **（2）检索机制** 将用户查询向量化后通过集合的**向量字段**进行检索 **（3）和传统数据库的核心区别** | **对比维度** | **传统数据库（MySQL）** | **向量数据库（Milvus）** | | --- | --- | --- | | 查询方式 | `WHERE name = '退货政策'`（精确匹配） | "退货怎么办"（语义相似搜索） | | 核心数据 | 字符串、数字、日期 | 高维向量 + 原始文本 + 元数据 | | 索引类型 | B-Tree、Hash | HNSW、IVF\_FLAT 等向量专用索引 | | 返回结果 | 精确匹配的行 | 按相似度排序的 Top-K 条结果 | **（4）常见向量数据库** Milvus、FAISS、Pinecone、Weaviate、Chroma、PGVector 等。 ## 2\. 在线阶段：查询响应 当用户发起提问时，系统实时执行以下流程： ### 2.1 Query 处理 用户的原始提问往往不是最佳的检索查询。通过查询改写、扩展等手段优化检索效果。 **常见优化策略：** **（1）查询改写** 核心思路是用 LLM 把用户的口语化问题转成更适合检索的表述。在用户提问和检索之间加一步 LLM 调用，用 Prompt 指示模型改写查询。常见手段包括： - **去口语化**：去除语气词、缩写，提炼正式表述（如「买的东西到了发现坏了咋办」→「商品签收后发现损坏的售后处理流程」） - **补全指代**：结合对话上下文，把"它""这个"替换成具体实体 - **HyDE（假设性文档嵌入）**：让 LLM 先生成一段"假设性答案"，再用这段答案去做检索，因为答案和知识库文档的语义更接近 **（2）查询扩展** 核心思路是从多个角度生成子查询，提升检索的 **召回率**。用 LLM 将一个问题拆成多个子查询，分别检索后合并结果。例如： - 用户原始问题：「RAG 系统怎么提升效果？」 - 扩展子查询 1：「RAG 检索阶段有哪些优化方法？」 - 扩展子查询 2：「RAG 生成阶段如何提升回答质量？」 - 扩展子查询 3：「RAG 知识库建设的最佳实践是什么？」 每个子查询分别检索 Top-K，将所有结果去重、合并后送入 LLM 生成最终回答，覆盖问题的不同侧面，避免单一查询遗漏相关内容。 **（3）意图识别** 核心思路是先判断用户问的是什么类型的问题，再 **路由到不同的处理逻辑**，避免所有问题都走同一套检索流程。 | **识别到的意图** | **路由策略** | | --- | --- | | 查询事实类（"退货政策是什么"） | 走向量检索知识库 | | 查询数据类（"上个月销量多少"） | 调用数据库 / BI 接口 | | 闲聊类（"你好呀"） | 直接用 LLM 回复，不走检索 | | 操作类（"帮我下个单"） | 路由到对应的业务 API |
**实践建议**：这三者通常**组合使用**——先做意图识别决定走哪条路，再对需要检索的查询做改写和扩展，最后去检索知识库。LangChain 和 LlamaIndex 等框架都提供了现成的模块来实现这些策略。 ### 2.2 向量检索（Retrieval） 将处理后的查询向量化，在向量数据库中搜索最相似的 Top-K 个分片。 **检索方式对比：** | **方式** | **原理** | **优势** | **劣势** | | --- | --- | --- | --- | | 向量检索 | 基于语义相似度匹配 | 理解语义，支持模糊匹配 | 精确关键词匹配较弱 | | 关键词检索（BM25） | 基于关键词匹配和词频统计 | 精确匹配强，速度快，成本低 | 不理解语义，同义词匹配差，这也就是以前智能客服机器人很智障的原因 | | **混合检索（推荐）** | 结合向量检索 + 关键词检索 | 兼顾语义和精确匹配 | 系统复杂度略高 | ### 2.3 重排序（Rerank） 重排序的目标是：在“第一阶段检索”拿到的一批候选证据里（通常 20–200 条），用更强但更慢的模型做**精排**，把真正与问题最相关的 Top-N（通常 3–10 条）挑出来。 **（1）为什么需要重排序？** - **向量检索的打分不够“精确”**：Embedding 更像“粗筛”，擅长语义相近，但对细节约束（时间、条件、否定、数字）不敏感。 - **混合检索会带来噪声**：BM25 和向量检索合并后，召回更高，但不相关片段也会混入。 - **Top-K 不能太大也不能太小**： - 开得太大：Prompt 变长、成本上升、注意力被稀释； - 开得太小：容易漏掉关键信息，准确度降低。 Rerank 让你“先多召回，再精挑”。 **（2）它到底做了什么？** 把问题和每条候选片段**拼成一对**（Query, Doc），用模型直接判断“这条证据对回答问题有多有用”，输出一个相关性分数，然后排序。 **（3）实现方式** 把 Query 和 Doc 放在一起编码，直接输出相关性分数。 - 优点：精度高，能理解细粒度约束（条件、时间、否定、数值）。 - 缺点：需要对每条候选都跑一次推理，成本随候选数线性增长。 工作流程： ```python 用户问题: "七天无理由退货包运费吗？" ↓ 第一阶段：向量检索召回 Top-50 条候选片段 ↓ 第二阶段：Cross-Encoder 逐一打分 - ("七天无理由退货包运费吗？", 片段1) → 0.92 - ("七天无理由退货包运费吗？", 片段2) → 0.87 - ("七天无理由退货包运费吗？", 片段3) → 0.23 ↓ 按分数排序，取 Top-5 + 过滤低于阈值的 → 送入 LLM ``` 代码实现最常用的是**Hugging Face** 的`sentence-transformers` 库 ```python from sentence_transformers import CrossEncoder # 1. 加载模型（常用模型见下方） model = CrossEncoder("BAAI/bge-reranker-v2-m3") # 2. 构造 (query, doc) 对 query = "七天无理由退货包运费吗？" docs = ["退货运费由买家承担", "定制类不支持无理由退货", "..."] pairs = [(query, doc) for doc in docs] # 3. 打分 scores = model.predict(pairs) # 4. 按分数排序，取 Top-N ranked = sorted(zip(docs, scores), key=lambda x: x[1], reverse=True) top_docs = [doc for doc, score in ranked[:5] if score > 0.3] ``` **（4）常见 Rerank 模型选型** **闭源商业 API** | **模型名称** | **特点与适用场景** | | --- | --- | | Cohere `Rerank` | 业界顶流，多语言支持极佳，API 接入简单，适合不想自己部署、追求极致效果的场景 | | Jina `Reranker v2` | 支持多语言和长文档，性价比高 | **开源私有化部署** | **模型名称** | **特点与适用场景** | | --- | --- | | `BAAI/bge-reranker-v2-m3` | 中文效果最佳的开源方案，支持多语言，闭眼选默认方案 | | `cross-encoder/ms-marco-MiniLM-L-6-v2` | 轻量级，速度快，适合英文场景和对延迟敏感的应用 |
**选型建议：** - **0-1 测试项目**：直接用 Cohere Rerank API，省心。 - **企业级应用**：本地部署 `bge-reranker-v2-m3` 是目前最稳妥的方案。 - **在 Dify / FastGPT 等平台中**：直接在知识库设置里开启 Rerank 并选模型即可，无需写代码。 **（5）关键参数怎么选** - **Top-K（召回数）**：常见 20–100 起步；知识库噪声大时可更高，但要配合重排序。 - **Top-N（送入生成的证据数）**：常见 3–8；如果答案需要多条证据拼接，可提高到 10–15。 - **阈值过滤（score threshold）**：低于阈值的证据不喂给 LLM，减少“带着错证据生成”。 **（6）最小可用实现（推荐路径）** 1. 先用向量或混合检索拿 Top-K。 2. 用 Cross-Encoder rerank 得到排序。 3. 取 Top-N + 分数阈值过滤。 4. 在 Prompt 里要求模型“只基于证据回答，并引用片段来源”。 ### 2.4 构建 Prompt 将用户原始问题 + 检索到的相关内容组装成增强 Prompt，明确指示模型"只能依据以下资料回答"。 **Prompt 模板示例：** ``` 你是一个专业的客服助手。请根据以下参考资料回答用户问题。 如果参考资料中没有相关信息，请诚实告知用户。 【参考资料】 {检索到的文档片段} 【用户问题】 {用户的原始提问} 请基于参考资料给出准确、简洁的回答，并标注信息来源。 ``` ### 2.5 LLM 生成回答 大模型基于增强 Prompt 生成最终回答，并可以引用来源，方便用户验证。 # **五. 效果评估** RAG 系统的效果评估通常可以划分为 **黑盒评估** 和 **白盒评估** 两种方式。 ## 1\. 黑盒评估 黑盒评估将整个 RAG 系统视为一个“黑盒”，不关心中间检索了什么文档，只关心 **“用户输入问题”** 后，**“系统最终输出的回答”** 质量如何。通常适合用来向业务方汇报系统整体可用性。 ### 1.1 **人工评估** 由人类评估员（如产品经理、业务专家、数据标注员）对 RAG 系统的最终输出进行抽检和打分。 - **常见形式**：人工抽检的准确率、Bad Case 的归因分析等。 - **优点**：**准确度最高**，人工抽检是最终的“黄金标准”，能发现自动化评估和模型难以察觉的微妙业务错误或常识问题。 - **缺点**：**成本高、周期长**，耗费人力，无法做到高频、实时的自动化反馈；且评估标准有时难以完全统一，存在一定主观性。 ### 1.2 **业务指标评估** 基于真实的线上业务数据和用户行为反馈，来衡量 RAG 系统在真实场景下的表现。 - **常见指标**： - **用户侧**：每次 AI 独立结束会话后推送的 1-5 星评价、点赞/点踩率等。 - **业务侧**：如智能客服的转人工率、拦截率、问题解决率等。 - **优点**：**贴近真实业务**，能直接反映 RAG 系统带来的最终商业价值和真实用户体感（比如到底省了多少客服人力）。 - **缺点**：反馈数据往往存在 **稀疏性**（用户主动留评率通常很低）；且评价有时容易受到产品规则或用户情绪的干扰，存在噪音（例如用户对公司退货政策本身不满，而不是对 AI 回答不满，却给 AI 打了 1 星）。 ### 1.3 **LLM-as-a-Judge（大模型裁判）** 利用 GPT-5 等高级模型作为裁判进行打分，这在自动化评估中非常流行。 RAGAS是目前业界非常流行的基于 **LLM-as-a-Judge** 的 RAG 自动化评估框架。它无需大量人工标注的“标准答案”，而是让大模型自己去对比“问题”、“检索到的上下文”和“生成的答案”，给出多维度的评分。 - **Faithfulness（忠实度）**：最终答案是否完全基于检索到的上下文生成的？有没有胡编乱造？（评估生成幻觉） - **Context Precision（上下文精确度）**：检索到的上下文中，真正有用的信息是否排在前面？（评估检索排序） - **Context Recall（上下文召回率）**：检索到的上下文是否包含了回答问题所需的全部信息？（评估检索覆盖度） - **Answer Relevance（答案相关性）**：最终答案有没有直接回答用户的原始问题？（评估生成质量） **RAGAS 基础使用示例（Python）：** ```python from datasets import Dataset from ragas import evaluate from ragas.metrics import ( faithfulness, answer_relevance, context_recall, context_precision, ) # 1. 准备评估数据（通常是 RAG 系统运行后记录的真实日志） data_samples = { "question": ["七天无理由退货包运费吗？"], # 用户提问 "answer": ["一般商品退货运费由买家承担，生鲜类不支持七天无理由。"], # RAG 生成的最终回答 "contexts": [ ["七天无理由退货的退货运费由买家承担。", "生鲜类商品不适用七天无理由退货政策。"] ], # RAG 检索到的文档片段 "ground_truth": ["不包运费，由买家承担。生鲜不支持。"] # 人工标准答案（部分指标如 Recall 需要） } # 将数据转换为 HuggingFace Dataset 格式 dataset = Dataset.from_dict(data_samples) # 2. 执行评估 # 注：RAGAS 默认调用 OpenAI 的大模型作为裁判，需要配置环境变量 OPENAI_API_KEY result = evaluate( dataset=dataset, metrics=[ context_precision, context_recall, faithfulness, answer_relevance, ], ) # 3. 输出评分（0~1分，分数越高越好） print(result) # 输出类似：{'context_precision': 1.0, 'context_recall': 1.0, 'faithfulness': 1.0, 'answer_relevance': 0.95} ``` ## 2\. 白盒评估 白盒评估是将 RAG 系统拆解开，分别对 **检索与重排阶段（Retrieval）** 和 **生成阶段（Generation）** 进行独立诊断，精准定位问题（是没搜到，还是生成错了），适合产品经理和研发用来调优。 ### 2.1 检索与重排阶段评估 主要评估 **“有没有捞到相关信息，且排得靠不靠前”**： | **指标** | **含义** | **适合场景** | | --- | --- | --- | | **Recall@K**（召回率） | 在返回的前 K 条结果中，命中了多少条真正相关的内容。关注"**有没有捞到**"，不关心排在第几位。 |
| 例：标准答案需要 3 条证据，你检索 Top-10 里命中了 2 条 → Recall@10 = 2/3 ≈ 66.7% | 评估召回覆盖度，K 越大召回越高但噪声也越多 | | **MRR**（平均倒数排名） | 第一条正确结果排在第几位，取其倒数，再对所有查询求平均。关注"**最相关的那条排得多靠前**" 例：Query A 第一条正确结果在第 2 位 → 1/2；Query B 在第 1 位 → 1/1；MRR = (0.5 + 1) / 2 = 0.75 | 只需命中一条关键证据的场景（如 FAQ） | | **NDCG**（归一化折损累积增益） | 不仅看是否命中，还看**相关度高的结果是否排得更靠前**，排名越靠后得分"打折"越狠。关注"**整体排序质量**" 例：假设有 3 条结果，相关度分别为 3、2、1（3 最相关）。如果实际排序把相关度 3 排第一，得分最高；如果把 1 排第一，虽然也命中了，但 NDCG 会低很多。 | 需要多条证据、且证据重要性有差异的场景 | ### 2.2 生成阶段评估 主要评估 **“大模型基于检索到的内容，发挥得怎么样”，**评估方法：**受控生成测试。** - **实现思路：**我们不再让模型去自己检索，而是直接将"金上下文"(GoldenContext，即人工准备的、最完美的上下文信息)和用户问题一起喂给生成模型。 - **核心目标：**通过控制输入，我们可以隔离生成模型的能力，专门评估它在理解和总结给定信息上的表现，而不用担心它被糟糕的检索结果所干扰。 - **评估指标：在这种受控环境下，我们可以再次使用忠实度（Faithfulness）和答案相关性（Answer Relevancy）**这两个指标。但此时，它们衡量的就是生成模型纯粹的"看文说话"能力。如果此时的忠实度依然很低，那就说明问题出在生成模型本身，它可能过于"富有想象力"，需要通过调整Prompt或进行微调来约束。 # 六. RAG 的演进方向 ## **1\. 初级 RAG** 最基础的"检索 + 生成"流程，适合入门和简单场景 ## **2\. 进阶 RAG** 引入查询改写、混合检索、重排序、答案合成等优化手段，显著提升效果 ## **3\. 代理式 RAG** Agentic RAG 是当前 RAG 领域最受关注的演进方向，核心思路是将 **AI Agent（智能体）引入 RAG 管道**，让系统从"固定流水线"进化为"自主决策的智能体系统"。
**一句话理解**：传统 RAG 像一台自动售货机（投入问题 → 固定流程 → 吐出答案），Agentic RAG 像一个会思考的研究助理（拿到问题 → 判断该查哪里 → 查完不满意再换个方式查 → 综合多轮结果给出答案）。
**Agentic RAG 的四大设计模式：** 1. **反思（Reflection）**：Agent 对检索结果和生成内容进行自我评估，质量不达标就重新检索 2. **规划（Planning）**：将复杂问题拆解为多个子任务，制定执行计划，逐步完成 3. **工具使用（Tool Use）**：不仅能查向量库，还能调用搜索引擎、数据库、API 等外部工具 4. **多智能体协作（Multi-Agent）**：多个专门化的 Agent 各司其职（检索 Agent、分析 Agent、生成 Agent），协作完成复杂任务 **传统 RAG vs Agentic RAG：** | **维度** | **传统 RAG** | **Agentic RAG** | | --- | --- | --- | | 工作方式 | 固定流程：检索 → 拼 Prompt → 生成 | Agent 动态决策：要不要检索、检索哪里、要不要再查一次 | | 数据源 | 通常单一知识库 | 可跨多个数据源、工具、API 灵活调度 | | 复杂问题 | 只能一次性检索，难以处理多跳问题 | 支持多步推理，迭代检索，逐步逼近答案 | | 自我纠错 | 无，检索到什么就用什么 | Agent 可反思检索质量，判断是否需要补充检索 | | 适用场景 | 简单知识问答、FAQ | 复杂分析、跨领域推理、多步任务 | # 七. RAG 实战清单 作为 AI 产品经理，在落地一个 RAG 项目时，需要包含以下步骤： ## 1\. 知识库建设 - 明确数据源范围（哪些文档需要纳入？） - 确定数据更新机制（多久更新一次？） - 选择合适的 Embedding 模型 - 确定分片策略和参数 - 数据质量保障流程（清洗、去重、格式化） ## 2\. 检索策略 - 选择检索方式（向量检索 / 关键词检索 / 混合检索） - 是否需要查询改写和意图识别 - 是否引入 Rerank 重排序，如果引入选择哪个 Rerank 模型 - 确定 Top-K和Top-N 参数 ## 3\. 生成策略 - 设计高质量的 Prompt 提示词 - 选择合适的生成模型（性能 vs 成本权衡） - 是否需要答案溯源和引用标注 - 兜底策略设计（检索不到相关内容时如何处理） ## 4\. 效果评估 - 定义和监控评估指标 - 建立测试集（覆盖核心业务场景的 Q&A 对） - 线上 Bad Case 收集与归因闭环 **记住**：RAG 系统的效果 = 知识库质量 × 检索质量 × 生成质量。三个环节环环相扣，任何一个短板都会拖累整体效果。作为产品经理，核心工作就是在这三个环节之间找到最优平衡。