在 1.1 节和 2.4 节中，我们反复强调了大语言模型的一个根本性短板：知识是静态存储在参数权重中的，它没有“硬盘”，无法像数据库一样精确查证事实。这意味着任何超出训练数据时间窗口的信息、企业内部私有文档、高度专业且更新频繁的知识（如医疗指南、法律条文），都是 LLM 的盲区。更危险的是，它面对这些盲区时并不会坦诚“不知道”，而是容易凭借统计模式拼凑出看似合理的错误答案——即幻觉。
RAG（Retrieval-Augmented Generation，检索增强生成） 正是目前业界解决这一问题的核心工程范式。它的核心思想极其朴素，却极其有效：在让 LLM 回答问题之前，先帮它“翻书”找到相关资料，然后让它基于资料作答。这一机制直接弥补了 LLM 的静态知识缺陷，被广泛应用于企业知识库问答、智能客服、法律文书分析、医疗辅助诊断、学术文献综述等场景。
本章将从技术原理、核心组件、落地全流程、关键调优点和常见陷阱五个方面，给出可直接指导工程落地的说明。
一、RAG 的核心原理：外挂知识库 + 检索 + 生成
RAG 本质上是将 信息检索（IR） 与 大语言模型生成 结合起来的一个流水线。其运行逻辑可以拆解为三个阶段：
- 离线索引阶段：将企业或场景相关的所有文档（PDF、网页、数据库记录、Markdown 等）提前进行切片、向量化，并存入向量数据库，构建可检索的外部知识库。
- 在线查询阶段：当用户提出问题时，先用同一个向量化模型将问题转化为向量，从向量数据库中检索出语义最相似的若干文本片段（Chunks）。
- 增强生成阶段：将检索到的文本片段作为“参考资料”，与用户的问题一起组装成 Prompt，喂给大语言模型。模型在这些资料的约束下生成最终答案，并要求其注明信息来源（Citation）。
用 1.1 节的大白话来说：RAG 相当于给了“概率接龙引擎”一本可以快速翻阅的参考书。当接龙接到需要事实支撑的地方时，模型可以“看一眼”参考书上的原文，而不是纯凭记忆乱猜。
典型 Prompt 模板示例（简化）：
你是一个专业助手。请根据以下参考资料回答用户问题。
如果参考资料中不包含答案，请直接说明“未找到相关信息”，不要编造。
参考资料：
[1] {检索到的文档片段1}
[2] {检索到的文档片段2}
用户问题：{用户输入}
答案：通过这样的 Prompt Engineering，模型被强制约束在“参考资料范围内”进行生成，从而极大降低幻觉风险。
二、RAG 系统的五个核心组件
一个生产可用的 RAG 系统，远不止“向量数据库 + LLM”这么简单。它通常包含以下五个关键模块，缺一不可：
1. 文档解析与预处理（Ingestion）
- 多格式解析：能处理 PDF（含扫描件）、Word、Excel、HTML、Markdown、图片中的文字（OCR）等异构格式。
- 版面分析：对于复杂排版（表格、双栏、页眉页脚），需要保留结构信息，而不是粗暴地抽出行列。例如，表格被切成碎片后会完全丧失原意，需要专门处理。
2. 文本切片策略（Chunking）
这是 RAG 工程中最容易被低估但影响最大的环节。切片过大，检索精度降低，且容易超出 LLM 上下文窗口；切片过小，语义碎片化，丢失上下文关联。
- 常用切片单位：500–1500 Token，依据模型上下文长度和业务特点调整。
- 切片优化技巧：
- 语义边界切片：尽量在段落、标题、列表等自然边界处切分，而非硬截断。
- 重叠窗口：相邻 Chunk 之间保留 10%–20% 的重叠部分，防止关键信息落在切分边界被割裂。
- 父子文档结构：检索时用小粒度 Chunk（确保高相关性），但生成时召回该 Chunk 所属的大粒度父文档（提供充足上下文），这是前沿方案中效果好但工程较复杂的模式。
3. 向量化与嵌入模型（Embedding）
- 模型选型：必须使用高质量、针对检索对齐过的 Embedding 模型，如
text-embedding-3-large、bge-large-zh、jina-embeddings-v2等。这类模型能将语义相似的文本在向量空间中映射得足够近。 - 多语言与领域适配：通用 Embedding 模型在垂直领域（如医药、法律）效果可能骤降，可考虑领域微调或专门的 Embedding 模型。
- 维度与成本权衡：向量维度越高，语义表征越精细，但存储和检索成本也越高。1024 或 1536 维是较常见的选择。
4. 向量数据库与检索策略
- 向量数据库选型：Milvus、Qdrant、Weaviate、Chroma、Pinecone 等。选择依据包括规模（百万/千万/亿级）、并发 QPS、是否支持混合检索、运维复杂度等。
- 检索模式：
- 稠密检索（Dense Retrieval）：纯语义向量相似度搜索，擅长理解同义词和意图，但可能漏掉精确关键词匹配（如产品型号“X-100”）。
- 稀疏检索（Sparse Retrieval）：基于 BM25 等传统关键词匹配算法，对专有名词、数字、代码等高鉴别力词汇效果极好。
- 混合检索（Hybrid Search）：将稠密和稀疏检索的结果进行加权融合（Reciprocal Rank Fusion, RRF），是当前工业界的主流实践。
- 检索后处理：对召回片段进行重排序（Re-rank），利用 Cross-Encoder 模型对初筛结果精细打分，仅保留 Top-K 个最相关片段，能显著提升答案质量。
5. 生成与引用机制
- Prompt 组装：将用户问题、检索到的 Chunks、系统指令（角色、约束、引用要求）组合为完整 Prompt。
- 强制引用：在 Prompt 中明确要求模型在生成答案时标注引用的 Chunk 编号或原文片段。这不仅是给用户看的“证据”，更重要的是约束模型的生成行为。
- 后处理与安全：对生成结果进行事实一致性校验（比如用另一个 LLM 检查答案是否忠于检索资料），过滤敏感词，避免泄露检索资料中的隐私信息。
三、RAG 完整落地流程（七步法）
以下步骤可直接作为项目执行清单：
第1步：需求分析与知识范围界定
- 明确系统需要回答哪些类型的问题（FAQ 类、综合分析类、多文档对比类）？
- 知识库的文档类型、数量级、更新频率、语言分布。
- 明确答案对时效性、准确性、可溯源性的要求。
第2步：知识处理与索引构建
- 采集文档 → 解析 → 清洗（去重、去水印、去冗余格式）→ 切片（确定 Chuck Size 和 Overlap）→ 向量化 → 存入向量数据库。
- 同步建立元数据索引（文档来源、日期、分类），用于后续过滤（如“只查2024年的政策文件”）。
第3步：检索管道搭建与调优
- 配置 Embedding 模型、向量数据库连接、检索方式（稠密/稀疏/混合）。
- 设定初始 Top-K（如 10）和 Re-rank 后保留数（如 3–5）。
- 编写检索查询的改写或扩展逻辑（如将用户口语化问题改写成更适合检索的关键词串）。
第4步：生成 Prompt 优化
- 设计包含角色、约束、引用格式的 Prompt 模板。
- 处理“参考资料不足”时的拒绝话术，避免模型硬编。
- 可引入链式推理或多步查询（例如先让模型判断需要用到的文档类别，再进行检索）。
第5步：端到端集成与测试
- 将检索、生成、引用组装为 API 或 Web UI。
- 构建测试集：至少 50–100 个真实场景问题及其预期答案/要点。
- 人工评估答案的准确性、完整性、相关性，记录幻觉率。
第6步：迭代优化与评测闭环
- 分析 Bad Cases：是切片不合理导致关键信息未找到？检索范围太窄？还是 Prompt 约束不够？
- 调整切片策略、检索参数、Re-rank 模型、Embedding 模型或 Prompt，重新测试。
- 建立自动化评测脚本（如用 RAGAS、TruLens 等框架对检索召回率、答案忠实度、上下文相关性评分）。
第7步：上线运维与持续更新
- 规划知识库增量更新机制（新文档定时入库，旧文档下架）。
- 监控检索延迟、生成延迟、Token 消耗、幻觉投诉率。
- 设置人工兜底策略：对于审查严格或高风险场景，可增加人工审核环节，或保留“转人工”出口。
四、RAG 落地的三个关键调优点
1. 切片粒度是“命门”
没有银弹。需要通过迭代测试找到最适合业务的 Chunk Size。例如，法律合同可能适合 800–1200 词的大块（保持条款完整性），而 FAQ 场景适合 200–500 词的小块（精准匹配问题-答案对）。记录每一次调整对检索命中率和答案准确率的影响，形成自己的最佳实践。
2. 检索质量决定生成上限
“垃圾进，垃圾出”在 RAG 中体现得淋漓尽致。如果检索回来的前 K 个片段就是不相关的，再好的模型也生成不出正确答案。花 70% 的精力在检索端（包括切片、Embedding 选型、混合检索、Re-rank）是值得的。可以考虑加入查询重写（Query Rewriting），让 LLM 在检索前先将用户模糊问题展开成更具体的检索语句。
3. 不要忽视数据安全与访问控制
RAG 系统中往往涉及企业内部数据库或专有文档，需要严格控制数据权限。例如，不同部门员工提问相同问题，检索可见的文档范围应不同。这需要在向量入库时添加权限元数据，并在检索时进行过滤，而不能将全部文档混在一个库中让所有人检索。
五、常见陷阱与避坑指南
| 陷阱 | 表现 | 解决思路 |
|------|------|----------|
| 切片过碎导致语义丢失 | 答案不完整，或模型声称“没找到信息” | 增大 Chunk Size，或启用父子文档模式 |
| 检索只靠向量相似度，漏关键词 | 产品型号、数字编码类问题返回无关内容 | 引入 BM25 或稀疏检索做混合检索 |
| 嵌入模型未对齐领域 | 检索结果看似相关，但得分虚高 | 微调领域 Embedding 或使用领域专用模型 |
| Prompt 遗漏“不知道”指令 | 无相关文档时，模型仍强行编造答案 | 在模板中明确：“如无相关信息，回复‘未找到’” |
| 元数据过滤缺失 | 用户问“最新政策”，召回的却是三年前的文件 | 入库时记录日期，检索时按时间或标签过滤 |
| 多轮对话上下文丢失 | 用户追问细节时，系统仍在用初始问题检索 | 将对话历史摘要或相关问题改写加入检索 query |
| 多模态文档处理失败 | 扫描件 PDF 中的文字无法被检索 | 预置 OCR 流程，或图片描述转文本 |
六、小结
RAG 是将 LLM 从“封闭的百科全书”变为“可以随时查阅外部活文档的研究助理”的关键技术。它的本质不是某种高深的算法创新，而是检索系统 + 大模型生成的工程组合。因此，RAG 落地成败的核心往往不在于 LLM 本身有多强，而在于：
- 文档处理与切片是否保留了语义完整性；
- 检索策略是否能找到“对的”上下文；
- Prompt 是否充分约束了模型的“编造冲动”。
在 24.3 节，我们将超越 RAG 的单次检索-生成模式，进入 Agent 智能体 的领域——让 LLM 能够规划任务、反复调用工具、维护记忆，实现更复杂的自主行为。RAG 可以被视为 Agent 的基础“工具”之一，理解它也是掌握 Agent 的前置条件。