大语言模型有三个致命缺陷：幻觉、知识截止和领域特化不足。其中，幻觉和知识截止是 RAG 的主战场；而领域特化不足，则需要 RAG 与 Fine-tuning 协同解决——RAG 提供事实性知识，Fine-tuning 提供领域推理能力，两者互补而非替代。RAG（Retrieval-Augmented Generation）的核心思想是——不改变模型本身，而是在生成前先检索外部知识作为参考。本文从原理到工程落地，系统拆解 RAG 的架构演进与 7 个关键工程决策。

一、RAG 核心管线：四步构建知识增强链路

RAG 的完整流程可以拆解为四个阶段，每个阶段都有明确的输入输出和质量控制点：

阶段	核心动作	关键产出
Ingest	文档解析 → 分块 → Embedding 向量化	结构化向量块
Index	构建 HNSW/IVFFlat 索引，加速近似最近邻搜索	可检索的向量索引
Retrieve	查询向量化 → 相似度搜索 → Top-K 召回 → 融合排序	高相关性文档集
Generate	System Prompt + 检索文档 + 用户问题 → LLM 生成	有据可查的回答

与传统 Fine-tuning 的本质区别在于：RAG 改文档即可实时更新知识，无需重新训练模型，成本更低且幻觉可控。但在知识更新频率极低、需要模型深度内化领域知识的场景下，Fine-tuning 仍有其价值。两者并非互斥，生产系统中常常组合使用。

---

二、从 Naive 到 Agentic：RAG 的四代演进

RAG 架构经历了四个清晰的演进阶段，每一代都在解决上一代的核心痛点：

第一代：Naive RAG——最简单的实现路径：文档分块 → 向量化 → 相似度搜索 → LLM 生成。问题在于分块质量不可控、检索粒度单一、无法处理复杂查询。适合快速 PoC，但离生产差距明显。

第二代：Advanced RAG——在 Naive 基础上引入查询改写（query rewriting）、混合检索（hybrid search）、重排序（rerank）、上下文压缩等优化手段。这是目前大多数生产系统的实际水位。

第三代：Modular RAG——将 RAG 拆分为可插拔的独立模块：路由模块、检索模块、融合模块、生成模块，每个模块可独立替换和升级。Spring AI 的 VectorStore + ChatClient 组合就是典型的 Modular 思路。

第四代：Agentic RAG——引入 Agent 作为编排层，根据查询复杂度动态决定检索策略（向量？图谱？关键词？），支持多轮迭代直到信息充分。Dream-SaaS 的 AgenticRagOrchestrator 就是这个方向的实践。

演进阶段	核心能力	主要局限	适用场景
Naive	单路向量检索	召回质量不稳定	快速验证、内部 Demo
Advanced	混合检索 + Rerank	静态管线，无法自适应	大多数生产系统
Modular	模块可插拔替换	需设计模块接口	需要持续迭代的系统
Agentic	Agent 动态编排	复杂度高、延迟增大	复杂多跳问答场景

---

三、两层架构设计：检索层追召回，生成层保忠实

生产级 RAG 系统通常采用两层架构，各层有不同的优化目标：

第一层：检索层（Retrieval Layer）。负责从向量数据库中召回候选文档。这一层追求的是高召回率（recall）——宁可多召回一些不相关的，也不能漏掉关键文档。混合检索（向量 + BM25）和 RRF 融合都在这一层工作。

第二层：生成层（Generation Layer）。负责将检索到的文档组织成 prompt，调用 LLM 生成最终回答。这一层追求的是高保真度（faithfulness）——生成的内容必须忠实于检索到的文档，不能自由发挥。两层之间通过**上下文预算（Context Budget）**连接：检索层召回的文档可能很多，但 LLM 的上下文窗口有限，需要在生成层进行裁剪和编号引用。

---

四、从 Demo 到生产级：7 个关键工程决策

跑通一个 RAG Demo 可能只需要一个下午，但把它做到生产可用，每一个环节都有需要认真面对的工程决策。以下是 7 个最关键的决策点。

决策 1：文档解析——别让"脏数据"毁掉你的 RAG 系统

文档类型	推荐工具栈	关键考量
结构化 PDF	pdfplumber + 自定义布局分析	保留段落、标题层级、表格结构
扫描 PDF / 图像	Tesseract OCR + Layout Parser	OCR 精度、版面还原
Word / PPT	Apache POI + 样式清洗	去除模板水印、保留大纲结构
HTML / Web	Jsoup + Readability 算法	过滤广告、导航栏、脚注

**观点：**不要追求"通用解析器"。在金融、法律、医疗等行业，文档结构高度标准化，应优先构建领域专用解析 pipeline。初期成本虽高，长期 ROI 远高于通用方案。推荐采用分层策略——先用快速解析器处理结构化文档，失败后再降级至 OCR 流水线。

决策 2：分块策略——别让"一刀切"毁了召回率

分块是 RAG 中最容易被低估、却对最终效果影响最大的环节。四种主流策略各有适用场景：

分块方式	优点	缺点	适用场景
固定长度（512 tokens）	实现简单，计算均匀	易切断语义	日志、结构化文本
按标点/段落	保留自然语言边界	块大小不均	新闻、博客
语义分块	保持主题连贯	计算开销大	法律文书、技术手册
标题层级分块	利用文档结构	依赖源文档质量	Wiki、API 文档

实践中，混合策略往往更有效：先按标题层级划分大节，再在每节内使用语义分块控制长度。某金融合规知识库项目中，仅用固定长度分块时召回准确率仅 62%；切换为"标题+语义"混合后，提升至 89%。需要注意的是，语义分块通常通过计算句子间的 Embedding 相似度来切分，适合离线批处理场景；在线实时分块建议用更轻量的策略（如按段落或标题层级）。

决策 3：Embedding 选型——别让向量质量成为"阿喀琉斯之踵"

模型	维度	中文优化	适用场景
bge-large-zh-v1.5	1024	✅ 强	高精度，有 GPU 资源
text-embedding-v4	1024	✅ 强	阿里云生态，性价比高
text-embedding-3-small	1536	⚠️ 一般	快速验证，无合规要求
gte-Qwen2-7B-instruct	1024	✅ 极强	超长上下文（32k+）

**选型建议：**冷启动阶段用 bge-small-zh 快速搭建 pipeline；上线前在真实 query 集上对比至少 3 个候选模型的 Recall@k 和 MRR；建立动态降级机制——主模型故障时自动切至轻量备用模型。记住，没有"最好"的 Embedding 模型，只有"最合适当前约束"的模型。

决策 4：混合检索——别再只靠向量检索"单打独斗"

向量检索凭借语义理解能力成为 RAG 标配，但在以下场景中容易翻车：

• 关键词缺失敏感：用户查询包含特定实体（如"订单号 ORD20240512"），向量模型可能无法有效召回
• 短查询歧义："Java 内存泄漏"可能同时匹配 JVM 调优、GC 原理、代码示例等多个方向
• 数值/符号失真：向量对数字、版本号等结构化信息编码能力弱

BM25 的核心优势在于：对高频词降权、低频词提权，并引入文档长度归一化。在处理专业术语、实体名称、缩写等"硬关键词"时鲁棒性极强，且无需训练，开箱即用。

融合策略上，推荐使用 RRF（Reciprocal Rank Fusion）：对每个文档在不同检索通道中的排名取倒数加权求和。公式为 RRF(d) = Σ 1/(rank_i(d) + K)，其中 K 通常设为 60。简单、无需训练、抗噪声能力强。

决策 5：重排序——别省这一步

初次检索 Top-20 → Rerank 模型精排 → Top-6。Cross-Encoder 类重排器利用细粒度交互建模对候选文档精准打分，能显著提升最终排序质量。推荐 bge-reranker 系列，中文场景效果好且支持本地部署。注意控制输入 Reranker 的候选数量（通常 Top 50-100），平衡效果与延迟。

决策 6：上下文注入——控制幻觉与成本的平衡

直接拼接 Top-K 片段容易超出 LLM 上下文窗口。推荐做法：动态截断或摘要压缩冗余内容，严格控制输入 token 数在 LLM 上下文窗口的 70% 以内，预留生成空间。某医疗问答系统曾因未做长度控制，在输入超长病历时触发 LLM 截断机制，关键诊断信息丢失——生产级方案必须预设 token 预算。

决策 7：监控体系——RAG 可观测性的最后防线

监控维度	核心指标	为什么重要
数据流质量	解析失败率、分块丢失率、Embedding 延迟 P95	PDF 表格解析失败可能导致整页丢失却无告警
检索效能	Top-K 相关性均值、查询延迟 P99、缓存命中率	向量库负载高时近似搜索精度骤降
生成合理性	幻觉检测触发率*、引用缺失率、响应长度异常	强制要求每个回答附带 source_id 可拦截 80%+ 无源幻觉

*幻觉检测通常通过引用覆盖率（每个断言是否有源文档支撑）或 NLI 一致性模型实现，具体方案将在后续「RAG 评估体系」专文中展开。

---

五、小结与落地清单

RAG 的核心价值在于：在不改变模型的前提下，通过外挂知识库实现实时更新、幻觉可控、成本可控的知识增强。从 Naive 到 Agentic 的四代演进，本质上是**从"检索+拼接"走向"理解+推理"**的过程。

落地建议 Checklist：

• ✅ 文档解析：按文档类型选择专用解析器，不追求通用方案
• ✅ 分块策略：优先尝试"标题层级+语义"混合策略，通过采样验证块内信息完整性
• ✅ Embedding 选型：中文场景优先 bge 系列或通义 v4，上线前用真实 query 集对比评测
• ✅ 混合检索：BM25 + 向量双路召回，RRF 融合，简单有效无需训练
• ✅ 重排序：Cross-Encoder 精排 Top-K，控制候选数量平衡延迟
• ✅ 上下文管理：预设 token 预算，控制在 LLM 窗口 70% 以内
• ✅ 监控体系：用 Micrometer + OpenTelemetry 覆盖数据流、检索、生成三阶段

迁移路径上，建议从模块化解耦入手：先替换文档解析与分块组件，再逐步引入重排序与监控体系，避免全栈重构带来的风险。每个决策均需在准确性、延迟、成本三角中寻找业务可接受的平衡点。

下一篇我们将深入 RAG 的进阶环节——混合检索与重排序的工程实战，详细拆解 BM25 为什么在今天依然不可替代、RRF 算法的数学原理、以及 Cross-Encoder 重排器的选型与调优。

---

「深入理解 AI Agent」系列 · 第 1 篇

有问题评论区见，欢迎交流~