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

发布日期：2025-07-18 07:14:01 浏览次数： 2219

作者：Simon Wong 的非线性漫游

微信搜一搜，关注“Simon Wong 的非线性漫游”

本文是一份关于构建和扩展检索增强生成（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 能动态决定查询哪些知识库，并循环迭代直至满足任务完成的退出条件。