RAG 架构演进与工程踩坑：从基础 RAG 到 Agentic RAG 的完整路径

一、为什么 RAG 不是"向量数据库 + LLM"

第一版 RAG 系统几乎都是这样的：把文档切片 → Embedding → 存向量库 → 用户查询也 Embedding → 检索相似文档 → 塞给 LLM 生成答案。这不是 RAG，这只是语义相似度匹配，离真正的知识检索还差一个数量级。

从工程视角看，RAG 本质是一个检索增强的端到端系统：分块 → 检索 → 重排序 → 压缩 → 生成 → 评估。每一环都有独立的优化空间、独立的失败模式、独立的可观测指标。任何一环做不好，整体体验就崩。

graph LR
    A[文档] -->|分块| B[Chunk]
    B -->|Embedding| C[向量库]
    D[查询] -->|Embedding| E[检索]
    C --> E
    E -->|Top-K| F[重排序]
    F -->|压缩| G[上下文]
    G -->|Prompt| H[LLM]
    H --> I[答案]

二、Naive RAG：基线架构与三大痛点

Naive RAG 是入门级实现，2023 年绝大多数 RAG demo 都属于这一类。它有三大核心痛点：检索质量差、上下文噪声、无法多跳推理。

2.1 检索质量差

纯向量检索对专有名词、罕见词、精确匹配的场景表现糟糕。比如问"Redis 的 AOF 重写机制"，向量检索返回的是语义相似但无关的文档。原因是 Embedding 把"Redis"和"数据库"映射到相近空间，丢失了精确匹配能力。

2.2 上下文噪声

Top-K 检索返回 5-10 个文档片段，其中很多是不相关或弱相关的。塞给 LLM 后，模型被噪声误导，生成幻觉。这是 Naive RAG 最常见的失败模式。

2.3 无法多跳推理

复杂问题需要多步推理——先查 A，再查 B，再综合。Naive RAG 只做单跳检索，遇到"X 和 Y 的关系是什么"这类问题就抓瞎。

graph LR
    A[Naive RAG] --> B[向量检索]
    B --> C[Top-K]
    C --> D[塞给 LLM]
    D --> E[噪声导致幻觉]

三、Advanced RAG：检索前/中/后的工程优化

Advanced RAG 是对 Naive RAG 的系统性优化，把优化点分成三个阶段：检索前（Pre-Retrieval）、检索中（Retrieval）、检索后（Post-Retrieval）。每个阶段都有明确的优化手段。

3.1 检索前优化

核心是查询改写与扩展——把用户原始查询改写成更适合检索的形式。

• HyDE：用 LLM 生成假设答案，再用假设答案的 Embedding 检索
• Multi-Query：生成多个查询变体，分别检索后合并
• Step-Back：抽象出更上层的概念再检索

3.2 检索中优化

核心是混合检索与重排序——结合多种检索方式，精细化排序。

• BM25 + 向量混合：传统关键词 + 现代语义
• 多路召回：不同 Embedding 模型分别召回
• RRF 融合：Reciprocal Rank Fusion 算法

3.3 检索后优化

核心是上下文压缩与重排序——剔除无关内容，保留关键信息。

• Cross-Encoder 重排序：query-doc 配对打分
• LLM 压缩：让 LLM 提炼关键句
• 元数据过滤：按时间/类别/作者过滤

graph TB
    A[Pre-Retrieval
查询改写] --> B[Retrieval
混合检索]
    B --> C[Post-Retrieval
重排序压缩]
    C --> D[LLM 生成]

四、混合检索：BM25 + 向量的双路召回

混合检索是Advanced RAG 的核心武器。它把传统 BM25 关键词检索与向量语义检索结合，互补短板。

4.1 为什么需要 BM25

向量检索对专有名词、缩写、版本号、错误码等精确匹配场景无能为力。比如搜"K8s Pod OOMKilled"，向量检索可能返回"Pod 概念"相关文档，但不会精确匹配到"OOMKilled"。BM25 关键词检索在这里优势明显。

4.2 BM25 vs 向量

4.3 RRF 融合算法

Reciprocal Rank Fusion 是最常用的融合算法——给每个文档在不同检索结果中的排名打分，按 1 / (k + rank) 加权求和。k 通常取 60。该算法的优势是无需调参、效果稳定。

graph LR
    A[查询] --> B[BM25 检索]
    A --> C[向量检索]
    B -->|Top-K| D[RRF 融合]
    C -->|Top-K| D
    D --> E[最终 Top-N]

五、重排序与上下文压缩

检索返回 Top-K 文档后，还需要精细化排序——这就是重排序（Reranking）。它是 RAG 质量的关键拐点。

5.1 Cross-Encoder 重排序

Cross-Encoder 把 query 和 doc 一起输入模型，输出配对相关性分数。比 Bi-Encoder（分别编码再算相似度）精准得多，但计算量大，只能用于少量文档重排。常用模型：BGE-Reranker、Cohere Rerank、bge-reranker-v2。

5.2 LLM 重排序

用 LLM 直接对文档打分（如 GPT-4）。优势是理解力最强，能捕捉细微相关性；劣势是成本高、延迟大。生产中慎用，只在 Top-10 重排序时偶尔使用。

5.3 上下文压缩

重排序后还需要压缩上下文——删除冗余信息、保留关键句。LLM 压缩（如 LongLLMLingua）可把 10 段文档压缩到 3 段，上下文窗口利用率提升 3 倍。

graph LR
    A[Top-50 检索] -->|重排序| B[Top-10]
    B -->|压缩| C[Top-3 关键段]
    C -->|Prompt| D[LLM]

六、语义分块：从固定切分到智能分块

文档分块是 RAG 的第一步，也是最容易被忽视的步骤。分块质量直接决定检索效果。

6.1 固定切分 vs 语义切分

固定切分（按字符数/Token 数）简单但破坏语义完整性——一句话被切成两半，检索时永远找不到。语义切分（按句子边界、段落、章节）保留语义完整，但需要 NLP 处理。

6.2 主流分块策略

• Recursive：递归按段落/句子/词切分（LangChain 默认）
• Semantic：用 Embedding 检测语义边界
• Markdown：按标题层级切分（适合结构化文档）
• LLM-based：用 LLM 智能切分（成本高）

6.3 Chunk Size 选型

Chunk Size 不是越大越好。经验数据：256-512 tokens 是中文 RAG 的甜点。太大则噪声多，太小则语义不全。表格、代码块特殊处理（保持原子性）。

graph LR
    A[固定切分
破坏语义] --> B[问题]
    C[Semantic
保留语义] --> D[更好的检索]

七、评估体系：RAGAS 与四维指标

RAG 评估是最难但最重要的部分。没有评估体系，调参就是盲人摸象。

7.1 四维评估指标

• Faithfulness：答案是否忠实于检索上下文（无幻觉）
• Answer Relevancy：答案与查询的相关性
• Context Precision：检索上下文的相关性
• Context Recall：检索上下文的完整性

7.2 RAGAS 框架

RAGAS 是业界主流的 RAG 评估框架——基于 LLM-as-judge，无需人工标注即可评估四维指标。我们每周跑一次评估，监控 RAG 质量变化。

7.3 评估驱动开发

我们建立了评估集（100+ 真实业务问题）+ 自动化评估 pipeline。每次改动分块策略、Embedding 模型、Prompt 模板都先跑评估，对比基线。评估驱动开发让优化有了客观标准。

graph LR
    A[改动 RAG 配置] --> B[跑 RAGAS 评估]
    B --> C{质量提升?}
    C -->|是| D[上线]
    C -->|否| E[回滚/调整]

八、工程化：可观测、降级、缓存

RAG 是分布式系统，需要工程化支持：可观测、降级、缓存。

8.1 可观测性

RAG 链路长（分块→检索→重排→生成），必须全链路 Trace。我们用 OpenTelemetry 追踪每一步：检索耗时、重排得分、LLM token。生产事故 80% 来自检索链路。

8.2 降级策略

RAG 链路任何一环都可能挂——Embedding 服务挂、向量库挂、LLM 限流。必须有多级降级：

• L1 切换备选服务：主 Embedding 挂则切备
• L2 简化检索：跳过重排、跳过压缩
• L3 直接 LLM：放弃 RAG，纯 LLM 回答

8.3 缓存策略

RAG 缓存有三种：查询缓存（相同 query 直接返回）、Embedding 缓存（文档 Embedding 复用）、检索结果缓存（query + 上下文组合缓存）。命中率达 30% 时可降低 50% 成本。

九、Agentic RAG：多步推理与工具调用

Agentic RAG 是 RAG 的下一代形态——LLM 不再被动检索，而是主动规划检索步骤。它结合了 RAG 与 Agent 的优势。

9.1 核心思想

复杂问题需要多步推理：先查 A，再决定查 B 还是 C，再综合。Agentic RAG 让 LLM 自己决定检索路径，而不是固定流程。

9.2 主流模式

• ReAct：推理 + 行动循环
• Plan-and-Execute：先规划再执行
• Multi-Agent RAG：多个检索 Agent 协作

9.3 trade-off

Agentic RAG 的代价是复杂度和成本——每次检索都是一次 LLM 决策，延迟和成本增加 3-5 倍。适用于复杂场景（研究、咨询），不适用于简单问答。

graph LR
    A[用户问题] --> B{需要多跳?}
    B -->|否| C[简单 RAG]
    B -->|是| D[Agentic RAG]
    D -->|规划| E[步骤 1: 检索 A]
    E -->|规划| F[步骤 2: 检索 B]
    F -->|综合| G[答案]

十、未来形态：GraphRAG 与 Self-RAG

RAG 还在快速演进。我们看到的未来形态有两个：GraphRAG（知识图谱增强）和 Self-RAG（自我反思）。

10.1 GraphRAG

GraphRAG 把文档构建成知识图谱，检索时结合图遍历和向量检索。优势是能处理实体关系和全局问题（如"总结所有文档主题"）。劣势是构建成本高。

10.2 Self-RAG

Self-RAG 让 LLM 自己判断是否需要检索、检索什么，并对生成的答案自我评估。减少了不必要的检索，提升效率。

10.3 选型建议

大多数场景用Advanced RAG + 混合检索 + 重排序足够。只有遇到明确多跳/全局/关系问题，才考虑 GraphRAG/Agentic RAG。不要追新，先用好基线。

graph TB
    A[Naive RAG] --> B[Advanced RAG]
    B --> C[Agentic RAG]
    B --> D[GraphRAG]
    B --> E[Self-RAG]

📌 关键架构决策清单