Name: 大模型知识引擎：RAG全栈工程实践
Author: MiniMax-M3

认识RAG：大模型的"知识外挂"

第 1 章　认识 RAG：大模型的"知识外挂"

如果你今天让 ChatGPT 介绍贵公司 2024 年推出的新产品，它会一本正经地告诉你"该产品于 2023 年发布，售价 199 美元"——可这完全是它编造的。再让它回答"我们公司的年假政策是什么"，它要么拒绝回答，要么生成一段看起来很像那么回事、实则毫无依据的条款。这些不是个别现象，而是大语言模型（LLM, Large Language Model）在企业落地时几乎必然会撞上的三面墙：幻觉（hallucination）、知识截止（knowledge cutoff）、私域知识缺失。本章要解决的核心问题正是：当大模型本身回答不了真实问题时，我们应该如何为它"外挂"一个可信赖、可更新、可治理的知识源？ 这个问题的标准答案，就是 RAG。

1.1　大语言模型的三大局限

要理解 RAG 为何而生，必须先把大语言模型的能力边界看清楚。下面这三类局限不是"可以忽略的小缺陷"，而是限制大模型从"玩具"走向"生产力"的根本性约束。

1.1.1　幻觉：模型会"自信地说错话"

幻觉指的是模型生成的内容看似流畅合理，但与事实不符、甚至完全虚构。在工程语境下，我们通常把幻觉分为三类：

1. 事实性幻觉（factual hallucination）：模型陈述了与客观世界不符的事实。例如问"秦始皇的父亲是谁"，模型可能回答"秦昭王"，听着像那么回事，但实际是"秦庄襄王"。 2. 忠实性幻觉（faithfulness hallucination）：模型没有忠实于给定的上下文。例如你给了模型一段文档，要求"基于以下资料回答"，模型却开始引用文档里不存在的内容。 3. 推理性幻觉（reasoning hallucination）：模型在多步推理中产生逻辑跳跃，结论看似对，实际前提就错了。

幻觉的根源在于大模型的本质：它本质上是一个条件概率分布 $P(y \mid x)$ 的近似器，训练目标是"下一个 token 看起来像人话"，而不是"下一个 token 是真的"。这就像一个博览群书但记忆会串台、口头表达能力极强的人，他能给出流畅答复，但事实正确率只能靠运气和 prompt 约束。

对企业应用而言，幻觉是最致命的缺陷。一个偶尔胡说八道的客服机器人，会比一个"我不知道"的机器人危险得多——前者会引导用户做出错误决策，后者至少能让人去查证。

1.1.2　知识截止：模型活在"训练快照"里

大语言模型的知识来自训练数据。一旦训练完成，模型参数就被"冻结"，它所知道的世界停留在某个时间点。这个时间点被称为 knowledge cutoff（知识截止日期）。例如 GPT-4 的原始训练数据截止于 2023 年 10 月，那么关于 2024 年的任何事件，它要么不知道，要么只能凭"语言模式"猜。

更要命的是，模型甚至不知道自己不知道。它不会主动说"这个事件发生在我的知识截止之后"，而是可能基于已有知识进行"补全"。比如你问"2024 年巴黎奥运会的男子百米冠军是谁"，一个知识截止在 2023 年的模型可能答错，但它答得极其自信。

知识截止问题对企业的影响是双向的：

**时效性信息**（股价、政策、新闻）会迅速过时；
**版本化信息**（产品规格、价格表）会随公司业务变化而失效。

仅靠加大训练数据、反复重训是治标不治本的做法——成本高昂且永远追不上变化。

1.1.3　私域知识缺失：模型不懂你的公司

第三个局限是 private domain knowledge missing（私域知识缺失）。大语言模型在公开互联网语料上训练，所以它知道"珠穆朗玛峰多高"、"Python 怎么写 for 循环"，但它不知道：

你公司产品的内部文档；
你客户的合同条款；
你工厂的设备操作手册；
你团队的代码仓库历史。

这些知识要么从未公开，要么属于商业机密，要么体量太小不值得训练。但对企业来说，恰恰是这些知识最有价值。

把以上三种局限放在一起看，它们共同指向同一个工程诉求：我们需要一种机制，能在推理时（inference time）动态、可控地把"对的、最新的、属于我们自己的"知识喂给模型，让它在生成答案时有据可依。这个机制，就是 RAG。

1.2　RAG 的基本定义：Retrieval-Augmented Generation = 检索 + 生成

RAG（Retrieval-Augmented Generation，检索增强生成） 是 2020 年由 Facebook AI Research（现 Meta AI）的 Patrick Lewis 等人在论文 *Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks* 中正式提出的范式。它的核心思想极其朴素：

> 在让大模型回答问题之前，先用一个检索器（Retriever）从外部知识库中找出与问题相关的片段，再把这些片段作为上下文（Context）和原始问题一起交给大模型，让大模型基于"给定资料"生成答案。

用公式可以表达为：

$$ \text{Answer} = \text{LLM}\big(\text{Prompt} \oplus \text{Retrieve}(\text{Query}, \mathcal{K})\big) $$

其中 $\mathcal{K}$ 是外部知识库（knowledge base），$\oplus$ 表示拼接（concatenation）。比起纯生成式问答：

$$ \text{Answer}_{\text{naive}} = \text{LLM}(\text{Prompt}) $$

RAG 多了一步显式的检索动作，把模型从"凭记忆答题"变成了"开卷答题"。

1.2.1　为什么这个朴素的范式有如此大的威力？

答案可以从三方面理解：

1. 可解释性（interpretability）：RAG 的回答可以挂上"出处（source citation）"，用户能追到具体哪几段文档。这极大提升了可信度。 2. 可更新性（freshness）：知识库的更新无需重训模型，只要替换或追加文档即可。今天的产品改版，明天的机器人就能答对。 3. 可治理性（governance）：企业可以控制哪些文档进入知识库，谁有权限修改——这是合规部门最喜欢的特性。

1.2.2　"检索增强"这个词的准确含义

注意，"检索增强"并不意味着 RAG 必须每次都做检索。工程实践中可以根据查询类型动态决定是否检索：当用户问"你好"时，可以直接由模型回答寒暄；当用户问"今年报税截止日"时，必须先检索日历文档。RAG 的"增强"二字，强调的是可选、可控、可追溯的外部知识接入能力，而不是"凡问必检"。

1.3　RAG 与微调、Prompt 工程的对比与适用场景

很多初学者会把 RAG 和另外两种"让模型变聪明"的技术——微调（Fine-tuning）与 Prompt 工程（Prompt Engineering）——混为一谈。它们解决的是不同层面的问题。理解这三者的分工，是企业架构选型的第一步。

1.3.1　三种方法的核心差异

我们用一个具体例子说明。假设你在做一家法律科技公司的合同审查助手：

**Prompt 工程**：你精心设计一段 system prompt，告诉模型"你是一位严谨的法律助理，回答必须引用条款编号"。这一改动**不改变模型参数**，只是引导模型以某种"人格"作答。
**微调（Fine-tuning）**：你收集 5000 条"合同条款—审查意见"对，在基座模型（如 Qwen、Llama）上做监督微调（Supervised Fine-Tuning, SFT）。训练后，模型参数被更新，它的"思维方式"真的变得更像法律助理。
**RAG**：你把公司过去十年的合同范本、法规库、判例库全部建成向量库，每次回答问题时先检索相关条款，再让模型基于检索到的内容作答。模型参数**完全不变**，变化的是"喂给模型的上下文"。

下表对比了这三种方法：

| 维度 | Prompt 工程 | 微调 (Fine-tuning) | RAG | | --- | --- | --- | --- | | 是否改变模型参数 | 否 | 是 | 否 | | 改动生效速度 | 即时 | 数小时到数天 | 即时 | | 知识更新方式 | 改 prompt | 重训或继续训练 | 替换文档 | | 适合注入什么 | 角色、风格、格式 | 推理模式、专业语感 | 事实性、时效性、私域知识 | | 成本 | 极低 | 高（算力、数据、标注） | 中（向量库、检索系统） | | 可解释性 | 弱 | 弱 | 强（可挂出处） | | 典型适用场景 | 通用助手、风格控制 | 领域专家、专用模型 | 知识问答、客服、文档检索 |

1.3.2　如何选择：三步决策法

在企业项目中，我们常用如下决策法：

1. 问题主要靠"风格"解决？ → Prompt 工程。例如"让客服语气更温柔"。 2. 问题主要靠"推理范式"解决？ → 微调。例如"让模型能像资深医生那样问诊"。 3. 问题主要靠"事实知识"解决？ → RAG。例如"让模型能引用最新的产品文档回答用户"。

更复杂的情况往往是组合拳：用微调让模型掌握领域语感，用 RAG 提供实时知识，用 Prompt 工程做整体人格与安全约束。三者不互斥，而是分层协作。

1.3.3　RAG 的"杀手级特性"：事实可更新

如果说有什么特性让 RAG 在企业落地中成为首选，那就是 事实可更新。一项业务规则变了，微调模型需要重新走一遍"数据准备—训练—评估—部署"流程，可能耗费数周；RAG 只需要把新文档写进向量库，几分钟即可生效。在合规、金融、医疗等"错一句话就出大事"的领域，这种敏捷性是决定性的。

1.4　经典 RAG 的两阶段架构

理解 RAG 的设计原理，必须掌握它的两阶段架构：离线索引（Offline Indexing） 与 在线推理（Online Inference）。这两个阶段在工程上是完全异步的，但在逻辑上必须闭环。

下面这张系统图展示了完整的经典 RAG 架构：

```mermaid flowchart LR subgraph OFFLINE["离线索引阶段 Offline Indexing"] A1[原始文档 Documents] --> A2[文档清洗 Cleaning] A2 --> A3[切块 Chunking] A3 --> A4[向量化 Embedding] A4 --> A5[(向量库 Vector Store)] end subgraph ONLINE["在线推理阶段 Online Inference"] B1[用户查询 User Query] --> B2[查询向量化 Query Embedding] B5[(向量库 Vector Store)] --> B3[检索 Retrieval] B2 --> B3 B3 --> B4[重排序 Reranking] B4 --> B5[上下文拼接 Context Assembly] B1 --> B5 B5 --> B6[大模型生成 LLM Generation] B6 --> B7[最终答案 Final Answer] end A5 -.写入.-> B5 ```

1.4.1　离线索引阶段：把"知识"变成"可检索的资产"

离线索引的目标是：把企业散落在各处的文档（PDF、Word、Wiki、数据库记录、网页）转化为一种可以高速相似度检索的数据结构。这一阶段通常包含四步：

第 1 步：文档清洗（Document Cleaning）。企业文档脏得超出想象——扫描版 PDF 带噪点、Word 文档有页眉页脚、网页有导航栏和广告。清洗阶段要：

用 OCR（如 PaddleOCR、Tesseract）把图片转文字；
去除页眉页脚、水印、目录；
统一编码、处理乱码；
把表格、列表恢复成结构化文本或保留特殊标记。

第 2 步：切块（Chunking）。向量模型（Embedding Model）对输入长度有限制（典型如 512 或 8192 个 token），且过长的文本会让向量表示"被平均掉"、失去语义焦点。因此我们必须把长文档切成合适大小的块（chunk）。常见策略有：

**固定长度切块**：每 512 个 token 一刀，简单但可能在句子中间切断；
**按段落切块**：以 `\n\n` 为分隔，符合人类阅读直觉；
**语义切块**：先用模型判断段落主题变化，再切；
**滑动窗口切块**：相邻块之间保留部分重叠，避免边界信息丢失。

切块是 RAG 系统中最容易被低估的环节——第 3 章我们会用整章篇幅深入讨论。

第 3 步：向量化（Embedding）。每个文本块通过一个 Embedding 模型（如 `text-embedding-3-small`、`bge-large-zh`、`m3e-base`）映射为一个高维向量（dense vector），典型维度 384、768、1024 或 3076。语义相似的文本，在向量空间中距离相近。可以用余弦相似度（Cosine Similarity）衡量：

$$ \text{sim}(u, v) = \frac{u \cdot v}{\|u\| \, \|v\|} = \frac{\sum_{i=1}^{n} u_i v_i}{\sqrt{\sum_{i=1}^{n} u_i^2} \sqrt{\sum_{i=1}^{n} v_i^2}} $$

第 4 步：写入向量库（Vector Store）。向量库（Vector Database）是专门为向量检索优化的数据库，常见的有 Milvus、Weaviate、Qdrant、Chroma、PGVector（在 PostgreSQL 上扩展）等。它不仅存向量，还存对应的原始文本和元数据（如来源文档、更新时间、所属部门）。索引算法通常采用 HNSW（Hierarchical Navigable Small World）或 IVF（Inverted File），能在亿级向量中实现毫秒级最近邻检索。

1.4.2　在线推理阶段：从"用户提问"到"可信答案"

在线推理阶段处理实时用户请求。同样分为四步：

第 1 步：查询理解与向量化。用户的原始问题可能口语化、有错字、夹杂上下文。系统通常会先做 query rewriting（查询改写），把"那个退款咋办"改写成"退款流程与时效"。然后用同一个 Embedding 模型把改写后的 query 变成向量。

第 2 步：检索（Retrieval）。向量库根据 query 向量，找出最相似的 K 个块（典型 K=3 到 K=10）。这一步叫做 top-K retrieval。工程上常配合 BM25 等稀疏检索（sparse retrieval）做混合检索（hybrid search），弥补纯向量检索在专有名词、编号等场景的不足。

第 3 步：重排序（Reranking）。向量检索召回的 K 个块，不一定每个都和 query 强相关。重排序模型（如 `bge-reranker-large`、`cohere-rerank`、`gte-rerank`）会对这 K 个块再做一次精细打分，挑出最相关的 N 个（N 通常远小于 K，比如 N=3）。

第 4 步：上下文拼接与大模型生成。把挑出的 N 个块拼成 context，与原始 query 一起塞进 prompt 模板：

``` 你是一个企业知识助手。请仅根据以下资料回答用户问题。如果资料中没有答案，请直接说"我不知道"。

【资料】 {context}

【用户问题】 {question}

【回答】 ```

大模型基于这份"开卷考卷"生成答案。这一步通常还会配合引用标注（citation），让答案的每一句话都能追到具体出处段落。

1.4.3　两阶段的核心思想：知识与计算解耦

经典 RAG 架构背后有一个深刻的设计哲学：把"知识"和"计算"解耦。大模型负责"如何说"（推理与表达），向量库负责"说什么"（事实与依据）。这让两边可以独立演进：知识更新不动模型，模型升级不动知识库。对于企业来说，这意味着可以分别组建"数据治理团队"和"AI 工程团队"，各自优化自己负责的部分。

1.5　RAG 在企业中的典型应用场景与价值

RAG 的应用场景可以用一句话概括：凡是"答案存在于某份文档里、且这份文档会变化"的场景，RAG 都能发挥价值。下面列出六个最典型的企业场景。

1.5.1　企业客服知识库

场景：用户问"如何重置路由器"，客服机器人需要在最新的《家庭网络故障排查手册》里找到答案。

**挑战**：产品频繁迭代；需要严格遵循公司话术；不能产生幻觉。
**RAG 价值**：手册更新即生效；可挂"出处段落"；可按用户身份（VIP/普通）控制可见知识。

1.5.2　内部制度问答（HR / IT / 法务）

场景：员工问"年假可以拆成半天休吗"，HR 机器人需要在《员工手册》里查找。

**挑战**：制度条款精确，不能误读；权限隔离（高管制度普通员工不可见）。
**RAG 价值**：把结构化制度文档结构化切块；按角色过滤向量库；答案附原文链接，便于员工复核。

1.5.3　医疗 / 法律文献问答

场景：医生问"某药物与某食物同服的相互作用"，AI 需要检索最新的临床指南。

**挑战**：知识极度专业；需要引用文献支持；时效性极强（新研究不断涌现）。
**RAG 价值**：可挂 PubMed、UpToDate 等专业库；答案标注"基于 XX 指南 YYYY 版"；避免幻觉导致的医疗事故。

1.5.4　代码仓库智能问答

场景：新人工程师问"用户登录失败应该看哪段日志"，AI 在公司 Git 仓库里检索。

**挑战**：代码语义难用 Embedding 直接表达；跨仓库、跨语言。
**RAG 价值**：结合 AST（抽象语法树）切块；结合符号检索（grep）；让模型回答时引用具体的 file:line。

认识RAG：大模型的"知识外挂"

第 1 章 认识 RAG：大模型的"知识外挂"

1.1 大语言模型的三大局限

1.1.1 幻觉：模型会"自信地说错话"

1.1.2 知识截止：模型活在"训练快照"里

1.1.3 私域知识缺失：模型不懂你的公司

1.2 RAG 的基本定义：Retrieval-Augmented Generation = 检索 + 生成

1.2.1 为什么这个朴素的范式有如此大的威力？

1.2.2 "检索增强"这个词的准确含义

1.3 RAG 与微调、Prompt 工程的对比与适用场景

1.3.1 三种方法的核心差异

1.3.2 如何选择：三步决策法

1.3.3 RAG 的"杀手级特性"：事实可更新

1.4 经典 RAG 的两阶段架构

1.4.1 离线索引阶段：把"知识"变成"可检索的资产"

1.4.2 在线推理阶段：从"用户提问"到"可信答案"

1.4.3 两阶段的核心思想：知识与计算解耦

1.5 RAG 在企业中的典型应用场景与价值

1.5.1 企业客服知识库

1.5.2 内部制度问答（HR / IT / 法务）

1.5.3 医疗 / 法律文献问答

1.5.4 代码仓库智能问答

1.5.5 销售