【精读】构建和扩展 RAG 系统的实践经验总结

本文是一份关于构建和扩展检索增强生成（RAG）系统的实践经验总结。原文作者 Jakob 基于他在谷歌设计和部署了超过 50 个 RAG 应用、服务约 500 万用户的经验，提炼出一套可复用的 RAG 设计决策蓝图

文章旨在帮助开发者理解 RAG 的核心概念，并指导他们如何围绕知识库构建、内容检索和响应生成这三大关键环节做出明智的设计决策，从而构建出实用且高效的 RAG 系统。

RAG 基本概念

我们先了解下 RAG 的基本概念，懂的朋友可以跳到下一章。

RAG（Retrieval Augmented Generation）是一种通过向大型语言模型（LLMs）提供外部知识库中的相关上下文，来增强其回答准确性和知识范围的技术。

其核心思想是在生成回答前，动态地从知识库中检索与用户问题最相关的信息，并将其注入到 LLMs 的提示词（Prompt）中。

以下面的提示词为例，RAG 检索到的内容会插入到 context 中，用户提问插入到 {question} 中：

System：你是一个智能助手，负责解答与给定知识库和提供图片相关的问题。

- 严格仅使用以下上下文内容或提供的图片输入来回答最后的问题。逐步思考后再回答。回答要具体，并从上下文中提供示例。

=============
{context}
=============

不要试图编造答案：
- 如果仅从上下文或提供的图片无法确定问题的答案，请说“我无法确定该问题的答案。”并解释缺少哪些信息来回答问题。
- 如果上下文为空且未提供图片，只需说“我不知道该问题的答案。”

问题：{question}

有帮助且具体的答案：

RAG 不仅仅局限于向量数据库和文本嵌入，任何能为 LLM 动态提供上下文检索的方式都属于 RAG 范畴。

设计决策

1、构建知识库

关键问题：

你要考虑

• • 知识来源有哪些
• • 如何管理（自建或外部API）
• • 数据结构（结构化、非结构化、半结构化）
• • 数据分块策略（chunking strategy）是什么

PS：Chunking (分块) 是将大型文档或数据源（尤其非结构化文本）分割成更小、更易于管理和检索的单元（chunks）的过程。这样做有助于LLM更精确地定位和利用信息，并提高检索效率。

实施要点：

• • 出所有潜在的知识源，并优先从易于控制的源开始着手。
• • 外部知识源（如 API）集成简单，但控制力弱，影响性能优化；自建知识库则维护成本高，但控制力强。
• • 数据预处理策略因数据格式而异：
• • 结构化数据可能需要保持其结构以支持分析性查询，而非文本嵌入；
• • 非结构化数据（如长文档）需进行分块（chunking）处理，以便精确定位信息。
• • 常见分块策略：
• • 基于Markdown/HTML标签
• • 递归字符分割
• • 固定Token长度
• • 基于行（结构化数据）
• • 逐帧（视频数据）
• • 切忌将文本嵌入视为解决所有问题的方案，不同数据格式需要特定处理方法，滥用可能损害搜索结果质量。

2、内容存储与检索

关键问题：

当我们准备好数据后，就要选择选择合适的数据存储方式。存储的决策和检索方法基于以下问题：

• • 我们的数据结构
• • 预期的用户查询类型
• • 预计查询并发量
• • 延迟要求
• • 知识存储量
• • 是否包含第三方管理的外部数据。

实施要点：

• • 数据存储的选择
• • 非结构化数据常用向量数据库或图数据库；
• • 结构化/半结构化数据常用关系型数据库、数据仓库或文档数据库。
• • 查询类型区分：
• • 抽取式查询 (Extractive questions)：寻找知识库中可能直接包含的特定信息，向量数据库的近邻搜索对此有效。
• • 聚合/分析式查询 (Aggregate/analytical questions)：需要跨数据点或文档进行推理和聚合，可能需要知识图谱、关系型数据结构或Text2SQL系统。
• • 必须确保所选数据库能满足应用的规模和延迟需求
• • 向量数据库（GCP相关的 Firestore Vector Search, AlloyDB, Vertex Vector Search，除了这些也有别的选择）
• • 结构化数据存储（BigQuery, AlloyDB）
• • 知识图谱存储方案（使用 graph2nosql 存到 nosql，Neo4j）。
• • 对于动态变化的公共数据（如 GCP 文档），可利用外部 API 作为RAG的知识源，避免频繁索引的开销。
• • 核心原则是知识库的构建应围绕知识本身，而非让知识去适应固定的技术方案。

3、生成有意义的响应

关键问题：

响应生成是直接面向用户的环节，你需要考虑到

• • 规划的用户界面类型（问答、对话、GUI 等等）
• • 用户查询的平均复杂度
• • RAG 管道是否为你某个系统的一部分

实施要点：

• • 如果是简单的问答界面，那可以直接展示相关文档/分块及摘要。
• • 复杂的应用（如对话式 或 GUI）中，RAG 可能只是大型处理流水线或多智能体系统的一个组件。普通的 RAG 流程无法应对复杂查询，但是有以下解决方案：
• • 深度研究 (Deep Research) 模式：将复杂用户查询分解为多个子问题并分别研究，然后合并结果形成定制化报告。这里有一篇博文推荐：深度研究的设计模式及其实现方法^[1]
• • 智能体循环 (Agentic Loop)：适用于处理多个潜在知识源的场景，Agent 能动态决定查询哪些知识库，并循环迭代直至满足任务完成的退出条件。

总结与建议

• • 每个 RAG 系统都是独特的，遵循上文提到的设计决策指南能帮助你构建成功的 RAG 系统
• • 数据质量是关键：“垃圾进，垃圾出”原则同样适用于RAG。
• • 用户中心：从概念阶段就需考虑用户可能提出的问题类型，否则产品可能无法满足实际需求。
• • 简单 RAG 适用于初期，但面对复杂查询和知识库时，需考虑引入如深度研究或智能体循环等高级模式，简化系统回答问题的难度。

最后，我还列举了你可以值得继续深入研究的方向：

• • 混合检索策略 (Hybrid Search)：结合关键词搜索、向量搜索以及其他检索方法，以提高不同类型查询的召回率和准确率。
• • RAG 评估与优化：建立有效的RAG系统评估指标和流程，持续监控和优化检索质量、生成效果及系统性能。
• • Deep Research：对数据进行深入、多步骤的研究
• • Agentic RAG 与多跳推理：探索使用智能体（Agent）来执行更复杂的查询分解、多轮检索和跨知识源推理。

精读原文：A quarter decade of learnings from scaling RAG to millions of users^[2