什么是 RAG？它解决了大模型的什么问题？

简化版

RAG（Retrieval-Augmented Generation，检索增强生成）就是先查资料、再回答：把用户问题拿去外部知识库检索出相关内容，连同问题一起交给大模型生成答案。它缓解大模型三个核心痛点——参数知识可能过时、缺少私有知识、回答缺少可核验依据。核心认知：RAG 主要提供外部事实和出处，微调更适合稳定调整行为模式；端到端效果由知识库、检索、组装和生成共同决定。

详细版

一条典型 RAG 链路：

离线建库：文档清洗 → 切分成 chunk → 每片用嵌入模型转向量 → 存进向量库；
在线问答：问题编码成向量 → 向量库召回最相似片段 → reranker 重排 → 拼进提示词 → 大模型基于「证据」生成答案。

关键不是「接个向量库」，而是整条证据链质量。影响因素包括知识覆盖、解析与切分、检索和重排、元数据与权限过滤、上下文组装、引用溯源与拒答策略。

RAG 不能天然消除幻觉：没召回到正确材料、材料自相矛盾、或模型无视上下文，答案照样错。

完整版教学

一、为什么需要 RAG——大模型的先天局限

大模型的知识是「烤进」参数里的，带来三个绕不开的问题：

参数知识会滞后：训练结束后权重不会自动吸收新政策；模型若没有外部工具，就无法可靠获知后续变化；
没有你的私有数据：内部文档、产品手册、客户数据，模型从没见过；
会一本正经胡说（幻觉）：不知道的也会流畅编，因为它本质是「预测下一个词」，不是「查证事实」。

常见手段包括 RAG（知识放外部、用时检索）、工具查询和微调。微调可以调整领域行为并在一定程度上注入知识，但不适合作为频繁更新事实的可靠数据库；需要新鲜、可引用内容时通常优先 RAG 或权威工具。成本高低取决于语料规模、查询量、基础设施和质量要求，不能一概而论。

二、RAG vs 微调：怎么选（高频对比）

维度	RAG	微调
更新知识	更新来源并完成解析、索引与缓存失效	重新准备数据并训练、评估、发布
知识时效	可接近数据源刷新速度	权重在下一次训练前固定
可溯源	可绑定检索证据与版本	参数知识通常难定位出处
典型优势	外部事实、私有资料、动态内容	稳定风格、格式与任务行为
主要成本	检索基础设施与每次查询链路	数据、训练、评估与模型托管

记忆钩子：可先用“RAG 管外部证据，微调管稳定行为”做选型起点。它不是严格二分：两者都可能影响最终知识表现，也常与工具调用组合。

RAG、Prompt 和微调三者怎么组合选型，在「什么是大模型微调？它与 Prompt、RAG 应该如何选择？」里有完整对比。

三、检索为什么用「向量」而不是关键词

传统词法搜索依赖共享词项；例如「商品不合适怎样寄回」与标题「退货流程说明」可能几乎没有共同词，单纯 BM25 容易漏掉。

向量检索（语义检索） 用嵌入模型把文本映射到高维空间，语义相近的文本向量距离也近：

"商品不合适怎样寄回" 的向量 ≈ "退货流程说明" 的向量（可能距离较近）
                         词法匹配：共享词少，排名可能较低

这就是 RAG 能「理解意图」的基础。实践中常把向量检索和关键词检索结合做混合检索，兼顾语义和精确匹配。

四、RAG 为什么能压制幻觉，但压不死

RAG 把「凭记忆答」变成「看着材料答」——给了可依据的证据，模型就不易凭空编。但它只是降低幻觉、不是根除，因为链路每一环都可能坏：

召回错（没找到正确材料）→ 模型只能瞎猜
材料矛盾（多个片段打架）→ 模型不知信谁
模型无视上下文（固执用记忆答）→ 材料对了照样错

所以生产级 RAG 必须评估：召回率、上下文相关性、回答正确性、引用一致性（详见 RAG 评估专题）。

五、RAG ≠ 万能：能力边界

RAG 的主要作用是提供外部事实与证据，它本身不会更新模型参数或保证推理、风格和复杂计算正确。检索到的范例、规则可以影响当前回答，但确定性计算仍宜交给工具，稳定行为调整可考虑微调。切分不好、嵌入模型不懂业务语义、知识库错误或生成器误用证据，都会让 RAG 失效；它是一套系统工程，不是「接个向量库」就完事。

六、常见误区与追问

误区：RAG 会修改/训练模型。 不改任何参数，只在推理时把检索到的上下文喂进 prompt。
误区：接了向量库就万事大吉。 知识覆盖、解析、召回、重排、组装和生成缺一不可；没有可靠证据时模型再强也无法保证答案。
误区：RAG 能彻底消除幻觉。 只能缓解——没召回、材料矛盾、模型无视上下文时照样错，需评估和拒答兜底。
误区：切分只会用固定长度。 按语义/结构切、加适量重叠往往更好（见切块专题）。
追问：RAG 和微调怎么选？ RAG 管「知道什么」（事实、实时、可溯源），微调管「怎么表现」（风格、格式、能力），常结合用。
追问：为什么用向量而非关键词？ 语义检索能匹配「字面不同、意思相同」的表达，关键词做不到；实践常混合检索。
追问：怎么知道 RAG 好不好？ 分层评估召回率、上下文相关性、答案正确性、引用一致性，别只看最终答案流畅度。

数字化拆分误差：200 个问题中，检索阶段有 170 个找到充分证据，生成阶段在这 170 个中答对 153 个。端到端正确率是 153/200=76.5%，条件生成正确率是 153/170=90%；前者才代表真实用户体验。

七、加强记忆

RAG 就是给大模型配了个随身资料库：答题前先检索相关材料，再带着材料生成，缓解参数知识滞后、缺私有数据和缺少依据的问题。选型可记：RAG 主要提供外部证据，微调主要调整稳定行为，工具负责实时状态和确定性动作；向量检索能匹配字面不同但语义接近的表达，也常与词法检索互补。RAG 可提升时效性与可追溯性，但成本和新鲜度取决于实现，而且只能缓解、不能根除幻觉。它是解析、切分、索引、检索、重排、组装、生成和评估共同组成的系统工程。

项目实战落地

项目里怎么做的

在《AI企业知识库》里，RAG 的离线和在线两段都落在具体的表和服务上：

数据分三层：MySQL 里依次是 knowledge_base（知识库，带切片参数）、knowledge_document（上传的文档和解析出的文本）、knowledge_segment（切好的片段）；片段向量单独存进 PostgreSQL + PGVector 的 knowledge_segment_vector 表，1024 维。
离线建库：支持 PDF、DOCX、TXT、MD 上传，解析出文本后按知识库上配置的切片长度切分，再逐条调用 Embedding 模型向量化入库。
在线问答：问题先向量化，在 PGVector 里按余弦相似度取前 5 条、相似度不低于 0.2 的片段；管理端测试页可以临时调 TopK 和阈值。
生成约束：系统提示词要求「严格基于给定资料回答问题；资料中没有的信息不要编造」，片段按「【资料1，相似度0.xx】」的格式拼进用户消息，末尾再要求「如果资料不足，请明确说明资料不足」。
结果展示：答案通过 SSE 流式返回，页面同时展示这次命中的资料来源和相似度。

为什么这样取舍

业务数据放 MySQL，向量放 PGVector。 知识库、文档、片段之间是普通的关系数据，用 MySQL + MyBatis 维护最顺手；相似度检索交给 PostgreSQL 的向量扩展，不用再引入一套专门的向量数据库。
只做基础 RAG。 这个项目的目标是把「解析 → 切片 → 向量化 → 检索 → 拼接 → 生成 → 溯源」整条链路第一次走通；混合检索、重排、查询改写和效果评测这些检索质量手段，放在《AI Agentic RAG高级企业知识库平台》里专门展开。

面试官还会追问

一条资料都没检索到的时候，还要不要调用大模型？项目里是怎么处理的？
为什么资料来源要在答案生成之前先推给前端？
系统里有多个知识库时，检索会不会串库？要做隔离该改哪里？

学完《AI企业知识库》，上面这些追问你都会迎刃而解。

简化版

详细版