预训练把海量知识压进了模型权重，这些知识确实能被调用——问一句「水的沸点是多少」，模型答得又快又准，不需要查任何东西。这叫parametric knowledge（参数化知识）：知识存在参数里，与模型不可分割。
但如果你把它当数据库用，会立刻撞上五堵墙，而且每一堵都无法靠「换个更大的模型」绕过：
| 问题 | 具体表现 | 为什么模型规模解决不了 |
|---|---|---|
| 时效性 | 训练截止之后的事情一概不知 | 再大的模型也有截止日期 |
| 私有性 | 你公司的内部文档从不在训练数据里 | 公开模型永远不会知道你的东西 |
| 可溯源 | 答案给不出依据，无法核查 | 权重里的知识没有「出处」这个概念 |
| 可更新 | 改一个事实要重新训练 | 知识在参数里是分布式存储的，无法定点修改 |
| 权限 | 无法做到「A 能看、B 不能看」 | 权重对所有用户是同一份 |
RAG（Retrieval-Augmented Generation，检索增强生成）的思路就是分工：把「怎么说话、怎么推理」留在参数里，把「事实是什么」放到外部可检索的索引中——后者称为 non-parametric knowledge（非参数化知识）。回答问题时先检索，再把检索到的内容随问题一起送进模型。
这个分工之所以成立，是因为两类能力的更新频率差了几个数量级：语言能力和推理模式极其稳定，事实却每天都在变。把它们绑在一起，等于让最稳定的部分被最易变的部分拖着一起重训。RAG 本质上是一次架构解耦，和把配置从代码里抽出来是同一个动作。
hallucination（幻觉）常被描述成「模型在撒谎」，这个拟人化的说法会把排查方向带偏。更准确的机制是这样的：
模型被训练来做一件事——给出统计上最合理的下一个 token。它没有被训练去区分「我知道」和「我不知道」，因为训练数据里几乎全是自信的陈述句，很少有人在写作时说「关于这个我不确定」。于是当问题落在训练数据覆盖稀疏的区域时，模型不会停下来，它会继续生成看起来最像正确答案的内容——形式完美、语气自信、内容捏造。
关键推论：幻觉不是一个可以被彻底修复的 bug，而是生成机制的固有产物。模型内部没有一个可靠的「知识边界」信号来告诉它何时该沉默。工程上能做的是把边界外移（RAG：把它不知道的变成它看得到的）和把边界显性化（引用约束、拒答设计——见 6.3），而不是指望某次升级把它消灭。
这解释了 RAG 为什么能缓解幻觉，也解释了它为什么不能根治：检索到正确的资料，只是让「照着抄」比「编」更容易；模型仍然可能忽略资料、误读资料，或者在资料没覆盖的部分继续发挥。RAG 把幻觉问题从「不可控」变成了「可检验」——因为现在你至少能对比答案和原文了。这个转变本身才是它最大的价值。
引入检索的同时也引入了一整条新的失败链路，每一环都会独立地出问题：文档没入库 → 切分切坏了（3.2）→ 检索没召回 → 召回了但排序靠后被截断 → 模型没用上下文 → 用了但读错了。端到端答错时，问题可能在这六环里的任何一环，而它们的排查手段完全不同。3.5 节专门讲怎么把这条链路拆开来量。
Lewis 等人在 2020 年提出了 RAG 这一名称与框架。值得注意的是他们给出的动机——论文开篇指出的问题，六年后依然是今天工程实践中最痛的三件事：
① 大模型确实把事实知识存进了参数，但访问和精确操纵这些知识的能力有限；② 为决策提供依据（provenance）是开放问题；③ 更新模型的世界知识是开放问题。
论文对比了两种形式：整个生成序列都基于同一批检索段落，以及每个 token 可以使用不同段落。今天工程上几乎全部采用前者——因为它简单、可缓存、可溯源，而这些工程属性比后者理论上的灵活性更重要。这是一个典型的「学术上更优的方案输给了工程上更省事的方案」案例。
更值得记住的是这篇论文确立的心智模型：参数化记忆 + 非参数化记忆。今天所有关于「RAG 还是长上下文」「RAG 还是微调」的争论，本质上都是在问同一个问题——这块知识应该放在哪种记忆里。有了这个框架，那些争论会清楚很多（见 3.4 与 5.1）。
向量存储：从「在现有数据库上加向量能力」（PostgreSQL + pgvector、Elasticsearch、OpenSearch）到专用向量数据库（Qdrant、Weaviate、Milvus 等），以及托管服务。选型建议：数据量在百万级以内、且已有关系型数据库的团队，优先用现有数据库的向量扩展——省掉一整套运维，且天然支持与业务字段的联合过滤（权限、时间范围），而这恰恰是纯向量库的弱项。
Embedding 模型：闭源 API 与开源模型（BGE、E5、GTE 等系列）均可用。关键不是排行榜分数，而是是否支持你的语言、你的领域，以及向量维度（直接决定存储与检索成本）。详见 3.3 与附录 A。
编排框架：LangChain、LlamaIndex 等提供开箱即用的 RAG 流水线。建议先手写一遍最小实现（切分 → 向量化 → 检索 → 拼 prompt，通常不到两百行），理解每一环的行为后再决定是否引入框架——否则出问题时你会不知道该在哪一层排查。
最容易被忽略的一环：增量更新与删除。文档更新后旧的 chunk 是否被清理？删除的文档是否还能被检索到（合规风险）？这些在原型阶段完全不可见，却是生产系统的主要维护成本来源。设计索引时就要想清楚文档与 chunk 的对应关系怎么维护。
能缓解：幻觉高发于模型知识稀疏的区域。RAG 把相关事实直接放进上下文，让「照着材料回答」成为比「凭印象生成」更容易的路径——本质上是把问题从「回忆」变成了「阅读理解」，而后者是模型更擅长的任务。
不能根治，因为生成机制没变：① 检索可能没召回正确材料，模型面对缺失信息仍会自行发挥；② 材料在上下文里，模型仍可能误读或忽略它（尤其材料长、位置靠中间时，见 3.4）；③ 材料本身可能过时或错误——RAG 会忠实地把错误答案讲得很有说服力；④ 问题超出材料覆盖范围时，模型不会说「资料里没有」，除非你明确要求它这么做。
真正的价值转变：RAG 把幻觉从「不可检验」变成「可检验」——有了引用，你才能自动比对答案与原文，才能做 groundedness 评估（3.5）。可观测性的提升比错误率的下降更重要。
用「多久变一次 + 是否需要溯源」两把尺子量：
A 请假流程 → 索引。私有、会变、且回答时最好能给出制度原文链接（员工要能核对）。典型 RAG 场景。
B 中文语法 → 参数。极其稳定，且已在预训练中充分覆盖。把语法规则塞进检索索引是纯粹的浪费。
C 库存数量 → 都不是，应该是工具调用。这是本题的陷阱。实时且高频变化的结构化数据不该进向量索引——索引会立刻过期，且数值型精确查询正是向量检索最不擅长的。正确做法是让模型调用查询接口（4.1）。「能用一次 API 调用精确拿到的东西，不要用检索去近似。」
D 行业术语 → 看情况，两者可能都需要。术语的含义相对稳定，若该行业在公开语料中覆盖充分，参数化知识已经够用；但如果是小众领域，或贵司对术语有特定定义，则需要索引。此外还有第三条路：术语的表达风格若需要模型内化（而非查阅），那才是微调的适用场景（5.1）。
这是一道考察知识分层理解的题。四个层面的回答：
① 更新成本。索引更新是写一条记录（秒级）；微调更新是重新训练加验证（天级起）。知识每天在变，这条差异是决定性的。
② 可溯源。RAG 能返回「答案来自哪份文档的哪一段」，这在企业场景中往往是合规硬要求而非加分项。微调进权重的知识永远给不出出处。
③ 权限控制。RAG 可以在检索层按用户权限过滤——不同用户检索到不同文档。微调后的模型对所有人是同一份权重，无法做到「A 能看 B 不能看」，这经常是企业部署的一票否决项。
④ 微调不擅长注入事实。这一点最容易被误解：微调更适合塑造行为（输出风格、格式、领域推理方式），而不是灌输事实。少量样本上的事实微调既容易被遗忘，又容易引发过拟合与灾难性遗忘（5.3）。
加分回答：主动指出两者不互斥——常见的成熟形态是微调塑造行为 + RAG 提供事实。以及点出第三条路：如果需求只是「让模型知道几条固定规则」，把它写进 system prompt 往往比这两条路都便宜（5.1 的升级路径）。