RAG系统构建与扩展的实践经验总结

本教程基于谷歌工程师 Jakob 在设计和部署超过 50 个 RAG 应用、服务约 500 万用户的实战经验，提炼出一套可复用的设计蓝图。全文围绕 知识库构建、内容检索 与 响应生成 三大核心环节，帮助你从零搭建高效、可扩展的 RAG 系统。

RAG 基本概念

首先了解 RAG 的基本概念，熟悉的朋友可以跳过此章节，直接进入下一部分。

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

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

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

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

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

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

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

问题：{question}

有帮助且具体的答案：

小提示： RAG 不仅仅局限于向量数据库和文本嵌入，任何能为 LLM 动态提供上下文检索的方式都属于 RAG 范畴。例如通过 SQL 查询、知识图谱、甚至是外部 API 获取的实时数据，都可以作为 RAG 的上下文来源。

设计决策

1、构建知识库

关键问题：你需要考虑

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

小提示： 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 能动态决定查询哪些知识库，并循环迭代直至满足任务完成的退出条件。

常见问题

• Q：RAG 中的分块大小如何选择？
  A：分块大小取决于文档类型、查询颗粒度和 LLM 的上下文长度。通常建议从 512~1024 tokens 开始尝试，并基于检索效果进行调整。对于精确定位的问题，小块更有效；对于需要整体理解的场景，可以适当增大。
• Q：向量数据库和传统搜索引擎如何协同？
  A：可以结合使用，形成混合搜索（Hybrid Search）。例如先通过关键字搜索召回一批候选结果，再使用向量相似度进行重排序，或采用加权融合的方式同时利用稀疏和密集检索的优势。
• Q：RAG 系统上线后如何评估效果？
  A：建议从检索质量（如命中率、MRR）、生成质量（如准确率、忠实度）以及端到端满意度三个维度建立评估指标。可以使用人工评测或利用 LLM 作为裁判（LLM-as-judge）进行自动评估。

总结与建议

• 每个 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]

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：RAG系统构建与扩展的实践经验总结要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题