RAG 系统全景指南：从 0 到生产级的完整设计流程

写给有后端工程经验、正在学习 AI 应用工程的开发者。 本文目标：在你脑海中建立一张完整的 RAG 系统地图，知道每个环节做什么、为什么做、有哪些选择。

先回答一个最基本的问题：RAG 到底在解决什么

LLM 有三个硬伤：知识止步于训练截止日期、无法访问你的私有数据、以及会在不知道的事情上一本正经地编造答案（幻觉）。

RAG（Retrieval-Augmented Generation）的解决思路很直接：不要让模型凭记忆回答，让它带着参考资料回答。 就像开卷考试——模型仍然需要理解和推理的能力，但不需要背诵所有知识。

具体做法是：用户提问 → 从知识库中检索最相关的内容片段 → 把这些片段塞进 LLM 的 prompt 作为 context → LLM 基于 context 生成回答。

这个思路 2020 年由 Facebook AI Research 在论文中提出，到 2026 年已经成为构建知识密集型 AI 应用的标准架构。

全景地图

RAG 系统
│
├── 一、数据摄入层（Ingestion Pipeline）—— 离线处理
│   ├── 1.1 文档加载与预处理（Document Loading & Preprocessing）
│   ├── 1.2 分块（Chunking）
│   ├── 1.3 上下文增强（Contextual Enrichment）[可选]
│   ├── 1.4 向量化（Embedding）
│   └── 1.5 索引存储（Indexing & Storage）
│
├── 二、查询处理层（Query Pipeline）—— 在线处理
│   ├── 2.1 查询理解与改写（Query Understanding & Transformation）
│   ├── 2.2 检索（Retrieval）
│   ├── 2.3 重排序（Reranking）
│   └── 2.4 上下文压缩与组装（Context Compression & Assembly）
│
├── 三、生成层（Generation）
│   ├── 3.1 Prompt 构建（Prompt Construction）
│   ├── 3.2 答案生成（Answer Generation）
│   └── 3.3 引用与溯源（Citation & Attribution）
│
├── 四、评估层（Evaluation）
│   ├── 4.1 检索质量评估
│   ├── 4.2 生成质量评估
│   ├── 4.3 端到端评估
│   └── 4.4 引用质量评估
│
└── 五、运维层（Operations）—— 生产环境特有
    ├── 5.1 可观测性（Observability）
    ├── 5.2 索引刷新（Index Refresh）
    ├── 5.3 成本优化
    └── 5.4 安全与合规

下面逐层展开。

一、数据摄入层（Ingestion Pipeline）

这是离线处理阶段。把你的原始文档变成可被检索的向量索引。80% 的 RAG 失败可以追溯到这一层。

1.1 文档加载与预处理

做什么：把各种格式的原始文档（PDF、Word、HTML、Markdown、数据库、API 返回的 JSON 等）统一转成干净的结构化文本。

为什么重要：Garbage in, garbage out。PDF 的 OCR 错误、HTML 的导航栏噪音、表格的错位提取——这些问题如果不在这一步解决，后面所有环节都会被污染。

关键设计决策：

  • 文档解析工具的选择。简单文本用基础库（PyPDF、python-docx）就够了。复杂文档（扫描 PDF、多栏布局、嵌套表格）需要专业工具如 Unstructured.io、LlamaParse、Docling、或 Azure Document Intelligence。
  • 元数据提取。在这一步就应该提取并保存：文件名、页码、标题层级、创建/修改时间、文档类型。这些 metadata 在后面的检索过滤和结果展示中至关重要。
  • 预处理规范化。统一编码（UTF-8）、清除格式噪音（页眉页脚、水印文字）、处理特殊字符。

用你的 Java 经验理解：这一步相当于 ETL pipeline 的 Extract + Transform 阶段。

1.2 分块（Chunking）

做什么：把长文档切成适合 embedding 和检索的小块。

为什么重要：这是你之前详细学过的内容。核心 trade-off 是 chunk 太大检索不精准，chunk 太小丢失上下文。

推荐默认配置（基于 2026 年最新 benchmark）：

  • 策略：Recursive Character Splitting
  • Chunk size：512 tokens
  • Overlap：50-100 tokens（10-20%）
  • 不同文档类型用不同策略（Markdown 按标题切、代码按函数切、表格按行切）

关键原则：从简单策略开始，用 evaluation 数据驱动参数调优。不要一上来就追求 semantic chunking。

1.3 上下文增强（Contextual Enrichment）[可选但强烈推荐]

做什么：给每个 chunk 补充它在原文中的上下文信息，弥补 chunking 导致的上下文丢失。

核心方法：

  • Contextual Chunking（Anthropic 方法）：用 LLM 给每个 chunk 自动生成一段上下文前缀，描述该 chunk 在整篇文档中的位置和背景。Anthropic 报告减少 49% 的检索失败。
  • 文档摘要追加：在每个 chunk 的 metadata 中加入该文档的全局摘要。
  • 标题层级前缀：把 chunk 所在的标题路径（如"第3章 > 认证模块 > JWT 实现"）拼接到 chunk 文本前面。

这一步有成本（每个 chunk 调一次 LLM），但对检索质量的提升非常显著。

1.4 向量化（Embedding）

做什么：把文本 chunk 转换成高维向量（通常 768-3072 维），使语义相似的文本在向量空间中距离更近。

关键设计决策：

  • 模型选择。2026 年的主流选项：
    • 商用 API：Voyage AI 的 voyage-3-large 在 MTEB 排行榜领先，支持 32K 上下文；OpenAI 的 text-embedding-3-large/small 是最普及的选择
    • 开源自托管：BGE-M3（多语言最优）、E5-large-v2（英文场景、CPU 上 10ms 延迟）
    • 你计划用 BGE-M3，这对中日英多语言场景是正确的选择
  • 维度与成本的 trade-off。更高维度 = 更精确但存储更贵、查询更慢。很多模型支持 Matryoshka embedding（可以截断到更低维度而只损失很少精度）。
  • 注意：embedding 模型的最大输入长度是硬上限，不是目标值。512 tokens 的 chunk 在 8192-token 的模型上通常比塞满窗口效果更好。

1.5 索引存储（Indexing & Storage）

做什么：把向量和对应的文本、metadata 存入可快速检索的数据库。

关键设计决策：

  • 向量数据库选择：
    • pgvector（你计划使用的）：PostgreSQL 扩展，适合已有 PG 基础设施的团队。优点是运维熟悉、可以和业务数据同库；缺点是大规模（>10M 向量）性能不如专用数据库
    • 专用向量数据库：Pinecone（全托管）、Weaviate（开源）、Qdrant（开源）、Chroma（轻量级、适合原型）
    • 内存数据库：Redis（同时支持向量搜索和缓存，减少组件数量）
  • 索引类型：HNSW（最常用，查询快但内存占用大）、IVFFlat（适合大数据集，需要权衡精度和速度）
  • 同时存储原始文本和 metadata。检索到向量后需要取回原文送给 LLM，所以原始文本必须和向量一起存储或可关联查询。

二、查询处理层（Query Pipeline）

用户提问后的在线处理流程。这里的每一步都会影响最终检索到的 context 质量。

2.1 查询理解与改写（Query Understanding & Transformation）

做什么：在去检索之前，先优化用户的查询，使其更适合向量检索。

为什么重要：用户的原始问题经常是模糊的、口语化的、或者太复杂的。直接拿去做 embedding 检索，效果通常不好。

核心方法：

  • 查询改写（Query Rewriting）：用 LLM 把用户的口语化问题改写成更适合检索的表述。比如"这个东西怎么用"→“XXX API 的使用方法和参数说明”。
  • 查询扩展（Query Expansion）：生成多个语义相关的变体查询，每个变体去检索，然后合并结果。提高召回率。
  • 查询分解（Query Decomposition）：复杂问题拆成多个子问题。“比较 A 和 B 在性能和成本上的差异”→ 分别检索 A 的性能、B 的性能、A 的成本、B 的成本，再合并。
  • HyDE（Hypothetical Document Embedding）：让 LLM 先生成一个"假设性的答案"，然后用这个假设答案（而不是原始查询）去做向量检索。原理是假设答案在语义空间中比问题本身更接近真正的答案文档。

实际建议：第一版不加任何查询变换，用原始查询直接检索。如果 evaluation 显示 context recall 低，再逐步加入查询改写和扩展。

2.2 检索（Retrieval）

做什么：从向量数据库中找到与查询最相关的 chunk。

三种主要策略：

Dense Retrieval（稠密检索）：把查询也做 embedding，然后在向量空间中找最近邻（通常用 cosine similarity）。擅长理解语义——“如何验证用户身份"能匹配到讨论 authentication 的文档。但对精确关键词匹配较弱——搜索一个具体的错误码可能不如传统搜索。

Sparse Retrieval（稀疏检索）：基于关键词匹配的传统检索，如 BM25。对精确匹配很强（搜索错误码、产品名称、专有术语），但不理解同义词和语义。

Hybrid Retrieval（混合检索） ⭐ 推荐：同时跑 Dense + Sparse，然后用 Reciprocal Rank Fusion (RRF) 合并结果。2026 年的共识是混合检索几乎总是优于单独使用任一种方式，recall 提升 1%-9%。

检索数量的设定：常见起点是检索 top-20 候选，后面通过 reranking 缩减到 top-5 送入 LLM。具体数值通过 evaluation 调整。

2.3 重排序（Reranking）

做什么：对检索返回的候选 chunk 做二次排序，把真正最相关的排到前面。

为什么需要：向量检索的 cosine similarity 是一个粗粒度的相关性度量。两个 chunk 可能 cosine 得分相近，但实际相关性差很多。Reranker 用更精细的模型（通常是 cross-encoder）逐一评估每个 chunk 与查询的相关性。

工作方式：

检索返回 20 个候选 chunk
→ Reranker 对每个 (query, chunk) pair 打分
→ 按分数重排
→ 取 top-5 送入 LLM

主流选项：Cohere Rerank（商用 API，$1/1000 次搜索）、BGE-Reranker（开源）、ColBERT（late interaction 模型，精度高但部署复杂）。

实际影响：Reranking 通常能显著提升最终答案质量，因为它确保了 LLM 看到的是真正最相关的 context，而不只是向量空间中最近的。

2.4 上下文压缩与组装（Context Compression & Assembly）

做什么：在把 chunk 送入 LLM 之前，做最后的优化——去重、压缩、排序。

核心操作：

  • 去重：如果多个 chunk 内容高度重复（比如 overlap 区域），合并或去除冗余。
  • MMR（Maximal Marginal Relevance）：在保持相关性的同时最大化多样性——避免 top-5 个 chunk 都在说同一件事。
  • 上下文排序：研究表明 LLM 对 context 开头和结尾的信息关注度最高，中间的信息容易被"忽视”（lost-in-the-middle 效应）。把最相关的 chunk 放在最前面和最后面。
  • 长度控制：确保总 context 不超出 LLM 的 context window，同时为 system prompt、对话历史和输出留够空间。

三、生成层（Generation）

检索到了相关 context，现在让 LLM 基于这些 context 生成回答。

3.1 Prompt 构建（Prompt Construction）

做什么：把 system prompt + 检索到的 context + 用户问题组装成最终的 LLM prompt。

典型的 prompt 结构：

[System Prompt]
你是一个基于提供的参考资料回答问题的助手。
只基于以下参考资料回答。如果参考资料中没有相关信息，明确说"我无法在提供的资料中找到相关信息"。
回答时引用具体来源。

[Retrieved Context]
--- 参考资料 1（来源：xxx.pdf，第3页）---
<chunk 1 的内容>

--- 参考资料 2（来源：yyy.md，章节：认证）---
<chunk 2 的内容>

...

[User Query]
用户的原始问题

关键原则：

  • 明确指示模型"只基于提供的 context 回答"——减少幻觉
  • 明确指示"如果不知道就说不知道"——比编造答案好
  • 要求引用来源——提高可验证性
  • Prompt 模板应该存在专门的文件里，不要散落在代码中

3.2 答案生成（Answer Generation）

做什么：调用 LLM 生成最终回答。

关键设计决策：

  • 模型选择：取决于质量要求和成本预算。GPT-5.4、Claude Opus 4.6 用于高质量场景；GPT-5.4 Mini、Claude Sonnet 4.6、MiniMax M2.7 用于成本敏感场景。
  • Temperature 设置：RAG 场景通常用低 temperature（0-0.3），因为你希望模型忠实于 context，而不是发挥创造力。
  • Streaming：生产环境几乎总是用 streaming 输出，减少用户感知的首 token 延迟（TTFT）。
  • Fallback 策略：LLM API 可能超时或报错，需要 retry + 降级方案（比如主模型超时就切到更快的模型）。

3.3 引用与溯源（Citation & Attribution）

做什么：在回答中标注每个事实来自哪个来源文档的哪个位置。

为什么重要：这是 RAG 相比纯 LLM 的核心优势之一——可验证性。用户可以点击引用去查看原文，确认答案的准确性。对企业客户尤其关键。

实现方式：

  • 在 prompt 中给每个 context chunk 编号（[1]、[2]…），要求模型在回答中标注引用编号
  • 回答生成后，将引用编号映射回原始文档的具体位置（文件名、页码、段落）
  • 前端展示时提供跳转到原文的链接

四、评估层（Evaluation）

这是大多数教程忽略但生产系统必须有的环节。没有评估，你不知道系统好不好，改了什么参数也不知道是变好了还是变差了。

4.1 检索质量评估

评估的是"检索层有没有找对 chunk"。

指标含义
Context Recall应该被检索到的 chunk 中，实际被检索到了多少（越高越好）
Context Precision被检索到的 chunk 中，有多少是真正相关的（越高越好）
MRR（Mean Reciprocal Rank）第一个正确的 chunk 平均排在第几位

Context Recall 低 → chunk 太小或策略切断了关键信息，或者检索的 top-K 太小。 Context Precision 低 → chunk 太大混入了无关内容，或者缺少 reranking。

4.2 生成质量评估

评估的是"LLM 的回答质量"。

指标含义
Faithfulness回答是否忠实于检索到的 context（vs 幻觉）
Answer Correctness回答是否与预期答案一致
Answer Relevancy回答是否与用户问题相关

Faithfulness 低 → 模型在 context 之外"编造"信息，需要调整 prompt 或降低 temperature。 Answer Correctness 低但 Faithfulness 高 → 问题出在检索层，送给模型的 context 不对。

4.3 端到端评估

端到端评估看的是从用户问题到最终答案的整体质量，不拆分检索和生成。

最有效的方式是准备一组 (question, ground_truth_answer) 对，跑整个 pipeline，对比系统输出和 ground truth。

4.4 引用质量评估

这就是之前我们讨论的那个话题的位置。评估系统生成的引用是否准确指向了原文。

评估工具：Ragas 和 DeepEval 是 2026 年最常用的 RAG 评估框架，覆盖以上所有指标。你的学习计划里已经包含了这两个工具。

Evaluation-Driven Development 的流程：

  1. 准备 50-100 条评测数据
  2. 用默认配置跑 baseline
  3. 记录各项指标
  4. 一次只改一个参数，对比指标变化
  5. 迭代优化

五、运维层（Operations）

从原型到生产，差距就在这里。

5.1 可观测性（Observability）

必须监控的指标：

  • 每个环节的延迟（embedding 耗时、检索耗时、LLM 生成耗时）
  • 每次请求的 token 消耗和成本
  • 检索返回的 chunk 数量和相关性分数分布
  • LLM 回答的 faithfulness 分数（可以用 LLM-as-judge 自动评估）
  • 错误率（API 超时、embedding 失败、检索为空）

工具：Langfuse（你计划使用的）是 2026 年最常用的 LLM observability 平台之一，支持 trace 每个请求在 pipeline 中的完整路径。

5.2 索引刷新（Index Refresh）

文档会更新。你的 RAG 系统需要有策略来保持索引与源文档同步。

  • 全量重建：适合文档量小（<10K 文档）的场景，定期全部重新 chunking + embedding
  • 增量更新：只处理新增和修改的文档。需要追踪文档版本（文件 hash 或修改时间）
  • 刷新频率：动态内容（产品目录、客服知识库）每天；静态文档（技术手册、合同）每周或手动触发

5.3 成本优化

RAG 的成本主要来自三个地方：

  • Embedding API 调用：摄入时一次性成本 + 索引刷新时的重复成本
  • LLM API 调用：每次用户查询都要调用，是持续成本大头
  • 向量数据库存储和查询：与数据量和 QPS 成正比

优化手段：

  • 语义缓存（Semantic Cache）：相似的查询直接返回之前的结果，不重复调用 LLM。可以大幅降低 LLM 成本。
  • 模型路由（Model Routing）：简单问题用便宜快速的小模型，复杂问题用强大的大模型。
  • embedding 维度缩减：用 Matryoshka embedding 降维，减少存储和查询成本。

5.4 安全与合规

  • Prompt injection 防御：用户可能在查询中嵌入恶意指令，试图让 LLM 泄露 context 内容或做意料之外的事。需要输入过滤和输出审查。
  • 数据隔离：多租户系统必须确保 tenant A 的查询不会检索到 tenant B 的文档。通过 metadata 过滤（查询时加 tenant_id 过滤条件）实现。
  • PII 处理：如果文档包含个人信息，需要在摄入阶段脱敏，或者在返回结果时过滤。
  • 数据主权：如果数据不能出境，需要用自托管的 embedding 模型和向量数据库，而不是云 API。

六、进阶架构模式

以上是标准 RAG 架构。当标准架构的评估指标遇到瓶颈时，可以考虑以下进阶模式：

Agentic RAG

让 LLM 自己决定是否需要检索、检索什么、检索几次。不是固定的"检索一次→生成"，而是一个 agent loop：模型可能先检索一次，发现信息不够，再改写查询检索第二次，直到收集到足够的 context 才生成答案。

GraphRAG

在向量检索之外加入知识图谱。向量检索擅长找语义相似的文本，但不擅长回答需要跨文档推理的问题（比如"A 公司的 CEO 和 B 公司的 CTO 是不是校友"）。知识图谱存储实体和关系，能补充这类结构化推理能力。

Multi-modal RAG

不只检索文本，还检索图片、表格、图表。比如用户问"Q3 的营收趋势如何"，系统检索到相关的表格和图表，一起送给 LLM（需要多模态模型）。

Self-RAG

模型在生成过程中自我评估：先生成一段回答，然后判断"我需不需要检索更多信息来支撑这段话？“如果需要，触发额外检索。这是 RAG 和推理的深度结合。

你的第一个 RAG 项目应该怎么做

基于你的学习计划和技术栈选择，这是我建议的路径：

第一步：最简可行 RAG

用最简单的配置跑通全流程：

  • Markdown/PDF 文档 → Recursive Splitting (512 tokens) → BGE-M3 embedding → pgvector 存储
  • 用户查询 → 向量检索 top-5 → Claude/GPT 生成回答
  • 用 Ragas 跑一次 baseline evaluation

第二步：加入核心优化

根据 evaluation 结果逐步加入：

  • Hybrid retrieval（向量 + BM25）
  • Reranking（BGE-Reranker 或 Cohere）
  • 查询改写
  • Contextual Chunking

每加一个组件，跑一次 evaluation，量化提升。

第三步：生产化

  • 加入 Langfuse observability
  • 实现增量索引更新
  • 加入语义缓存
  • 部署到 GCP Cloud Run

这个路径对齐了你的 v4 学习计划中 Production RAG System 作为第一个 portfolio 项目的目标。

参考来源

  • Lewis et al., “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks”, Facebook AI Research, 2020 — RAG 原始论文
  • NVIDIA Technical Blog: Finding the Best Chunking Strategy for Accurate AI Responses, 2025
  • Anthropic: Contextual Retrieval Paper, 2024
  • Vectara / FloTorch Benchmark: 50 academic papers, 7 strategies, February 2026
  • Redis Blog: RAG at Scale — How to Build Production AI Systems in 2026
  • PremAI: Building Production RAG — Architecture, Chunking, Evaluation & Monitoring, 2026
  • Towards AI: 9 RAG Architectures Every AI Developer Must Know, 2026
  • ZTABS: RAG Architecture Explained — Complete Guide, 2026