什么是 RAG：让模型带着资料回答问题
魔当实验室 · 2026年10月
本文是"AI技术科普"系列第八篇，也是这个板块里最后一层：第 2 篇讲的引擎、运行时、客户端、界面应用四层，解决的是"模型怎么跑起来"；这一篇讲的层跑在这四层之上，解决的是"模型凭什么知道你的东西"。和《什么是 MCP》是配套的：一个把资料递到模型面前，一个把工具递到模型手里。模型信息口径均为 2026 年 10 月查询，具体功能与授权条款以各项目官网与其代码仓库、模型仓库为准。不评测、不排名次、不放下载和注册链接。
先把三个容易混在一起的问题分开
模型答不上你公司那份手册里的事，原因常被说成"它记不住"。这个说法会带偏选型，因为真实情况是三个性质完全不同的问题叠在一起。
第一是时效。权重一旦训练完成就冻在那儿了，它不知道之后发生的事；而你的资料每天都在变——新政策、新版本号、上周那条会议纪要。把这批东西重新"教"进模型是一笔完全不同的成本，甚至根本不在个人能做的范围里。
第二是出处。有些场景里"答得对"还不够，你得能指出这句结论来自哪一页。合同、病历、财务口径、给客户报价的规则，都是这类。资料里写错了、模型答歪了，是两种必须分开的责任，而只把整批资料塞进上下文，恰恰分不开。
第三才是成本与延迟。这一条最实在：把一整本手册每次提问都送进模型，和每次只取最相关的几段，费用和等待时间不在一个量级上。哪怕窗口装得下，账也不划算。
RAG（Retrieval-Augmented Generation，检索增强生成）针对的就是这三条：先在你的资料里找出相关片段，连问题一起交给模型，让它基于找回来的内容作答。一句话记住它的位置——RAG 不是让模型变聪明，是给它一本可以翻的参考书。资料没覆盖的问题它照样答错，资料本身写错了它跟着错，这两件事在链路外，不在链路内。
一条链路，四步，坑各在不同处
| 这一步 | 它在做什么 | 常见的坑 | 判断它坏在哪 |
|---|---|---|---|
| 解析 | 把 PDF、扫描件、Word、网页、电子书变成干净的文本与结构 | 双栏排版串行、表格被压成一行、扫描页根本没文字层、页眉页脚混进正文 | 答非所问且引文支离破碎，多半先烂在这里 |
| 切块与向量化 | 把长文切成能单独成立的片段，再用嵌入模型把每段变成一串数字 | 切得太碎丢了主语和指代；一段里塞两个主题；标题和正文被分到两块 | 检索命中了错误的段落，而不是没命中 |
| 检索召回 | 把你的问题也变成数字，从索引里取回最相近的若干片段 | 只用语义相似度、不做关键词匹配，专有名词和型号一查就飘；中文库用了纯英文的嵌入模型 | 明明文档里有那句话，却召不回来 |
| 重排与生成 | 把召回的几十条候选重新排序，只留最相关的几条交给模型 | 跳过重排直接把候选堆进上下文；或者给的片段太多，模型在噪声里选错 | 答案里出现了本该被排到后面的那段 |
这四步里，大多数人最先低估的是第一步。一份 PDF 转出来的文本如果顺序是乱的，后面三步再讲究也只是在垃圾上做了精密的算术。这也是为什么文档解析工具在本地工具清单里自成一类：MinerU 这类工具做的就是把 PDF、图片和电子书转成干净的 Markdown 或 JSON，我们在清单里记录的体积量级是 17GB 出头、内存建议 16GB，Windows 侧推荐带显卡——比很多人想象的重，因为它里面也放了版式识别的模型。而解析这一步的产物是可复用的：转成 Markdown 的那一份文件，比任何一个向量库都长寿，换嵌入模型、换软件、换套壳方案，它都不用重做。
切块这一头的进步最近两年很具体。传统切法的毛病是片段脱离上下文后没人知道它在说什么——"该方案预计提升 15%"这句话单独看，既不知道哪个方案、也不知道提升什么。现在的通行做法是在入库时就给每个片段补一句来自哪份文档、哪一章的说明（业内叫 contextual retrieval 一类的做法），代价是入库更慢、存储更大，收益是召回质量明显稳。这件事的实质很朴素：索引里存的不只是文字，还得有这段文字的身份证。
嵌入模型这一层，是本地能自己搞定的部分
检索靠的是把文字变成数字的那个小模型，这一档开源选择在 2026 年很充足，而且比大多数人以为的轻。
公开资料里被反复提起的是两类：智源那批 BGE 系列（BGE-M3 支持上百种语言、单段能吃到八千多词元，并且同时给出稠密、稀疏与多向量三种表示，所以它能一次做语义加关键词的混合检索），以及阿里放出的 Qwen3-Embedding / Qwen3-Reranker 一档（0.6B、4B、8B 三种规模，公开口径支持几十种语言，最小的那档权重只有几百兆、可以在 CPU 上跑）。榜单分数各家口径不统一，不必当真，对个人用户真正常用的是这条：先用最小的那档试试，通常够；不够再往上升规模。
这一层有两个坑值得提前知道。其一，嵌入模型不是随便换的。向量库里的数字只在生成它的那个模型的解释下有意义，换模型意味着整库重新嵌入——有人公开记录过自己上万条记忆的中文库全量重嵌花了三四个小时（社区记录，2026 年 10 月查询，当量级参考）。所以选它的时候，选的是未来半年不能轻动的一环。其二，中英混排和数字、型号、代码标识符是这一层的公共短板，纯语义相似度对"某个具体型号叫什么"这类问题经常不如最土的关键字匹配，这也是为什么带关键词一路的混合检索近两年重新变成了标配。
重排（rerank）是另一半答案。召回阶段要快，所以它会放进来一大批"可能相关"的片段；重排器再把这些候选逐条和问题对一遍，压到最靠前的几条。它不是可选项——跳过重排的 RAG，等于让模型在一堆七成的相关材料里自己猜哪条是真的，而模型面对矛盾材料时给出的往往是最顺的那个，不是最对的那个。开源这一档同样有 BGE-Reranker、Qwen3-Reranker 这类选择，授权多为 Apache 2.0，具体仍以仓库 LICENSE 为准。
至于这两年常被一起提起的 GraphRAG，它的定位是补另一块：向量检索擅长"哪段话最像这个问题"，不擅长"跨多份资料把一条因果链拼起来"。把资料整理成实体与关系再检索，确实能吃下这类多跳问题，代价是构建阶段要额外调用模型跑一整遍资料、成本高，而且图谱一旦建好就不太跟得上资料更新。个人知识库遇到这种问题的概率不高，别为了它先上工。
长上下文这么大，还需要 RAG 吗
这是 2026 年被问得最多的一句，答案比"需要/不需要"都复杂一点：长上下文重新划了分工边界，但没有取消检索这件事。理由有三条，都能在公开实测里找到对照。
装得下不等于用得上。 主流模型的窗口已经在 128K 到百万词元这个区间，但把关键信息放在超长上下文的中间位置时，模型的召回会明显退化——这是注意力机制的老毛病，各家模型都躲不开，"大海捞针"这类测试分数很高也不代表长文档里每一段都能被稳定读到。窗口是容量指标，不是可靠性指标。
成本和延迟是硬约束。 处理十万词元和处理一万词元，费用与等待时间都不在一个量级，而且注意力计算的增长比线性更糟。公开的企业级对比测试给出的结论方向一致：同一批文档、同样的日查询量下，检索式方案比整篇塞进去便宜一个到两个数量级、延迟也更低（多为项目方与第三方自测口径，2026 年 10 月查询，当量级参考）。对本地跑模型的读者来说，这条更直接：上下文越长，你那张卡上要同时装下的键值缓存越大，这正是第 3 篇算过的那笔账。
知识更新和权限这件事，窗口帮不上。 索引可以增量更新，今天补一条新纪要，下一次检索就拿到最新版；把文档重塞进提示词则是每次重做。而"这份资料只有这个部门能查"这类边界，更不是靠上下文解决的。
所以 2026 年更常见、也更划算的做法是两段式：先用便宜的检索把候选从很大压到一小段，再让长上下文模型在这一段里做比较和综合。按这个思路，分流其实很好判：只有一份文档、一次性问完，直接丢进客户端的附件框就行，别建库；资料有几十份以上、天天在更新、需要指出出处、或者你不想每次重贴一遍——那才是 RAG 的位置。
三种形态：你其实已经在用第一种
本地这一层的产品形状已经分得很清楚，我们的应用清单里三类都有，它们对机器要求的差别也很说明问题。
| 形态 | 清单里的例子（2026 年 10 月查询） | 它替你做到哪一步 | 对机器的真实要求 |
|---|---|---|---|
| 客户端的临时检索 | Chatbox AI 这类 AI 客户端、各家桌面客户端的文件附件功能 | 你拖进去的几个文件当次生效，用完就散，不建索引 | 极轻，这类包体可以只占 1GB 上下，对显卡无特殊要求 |
| 自带知识库的工作流平台 | MaxKB（明确把 RAG 管道和工作流编排写进定位）、AstrBot（聊天机器人带知识库与 Agent）、n8n 一类自动化平台 | 四步链路帮你固化下来：上传、解析、切块、索引、引用回跳都摆在界面上 | 内存 8GB 起、体验装几个 GB 就够；对显卡没有硬性要求，但知识库做大了，占的是硬盘——MaxKB 的安装要求里写的就是"存储大量文档和建设知识库，最好 100GB 以上" |
| 智能体自己在中途检索 | 各类本地个人助理与 Agent 工具 | 它决定该搜几次、搜完再决定要不要接着搜，把检索变成一次多步推理里的一环 | 重的是模型那一头，检索这一路本身很轻 |
这三类放一起能看出一件挺反直觉的事：RAG 这一层不吃显卡，吃的是硬盘、文档质量和你的整理功夫。同一份清单里，跑大模型的客户端建议预留上百 GB 硬盘，而做知识库编排的工具只要几个 GB 就能起来——因为向量索引本身就是文本加一串数字，它不需要算力堆，需要的是资料被规规矩矩地转成文本、按段落切开、并且有人负责更新它。
也顺带说清一件事：这类平台常用的授权条款里，GPL 与 AGPL 出现得很频繁，另有几款用的是"源码公开但不等于自由使用"那一类许可证（n8n 那两条许可证并列的写法就是典型）。自己本地用和把它做成服务卖给别家是两件事，别拿"开源"两个字直接推导出"可以商用"，一切以仓库 LICENSE 为准。这条和《模型文件到底从哪来》讲的是同一条原则。
和 MCP 是两件事，也别混为一谈
这个板块里上一篇讲 MCP的文章容易被读成"又一个连资料的方法"，两者其实处在链路的两侧。
RAG 处理的是你已经拥有的资料：把它们整理、索引，提问时把相关片段递到模型面前，答案的边界由你的库决定。MCP 处理的是模型与外部世界之间的接口：它让模型能够调用一套已经定义好的工具与数据入口，具体拿到什么取决于那个服务端连着什么。前者是你搭的库，后者是别人开的门。要做的事情是"在我这批文档里找答案"，那是检索的问题；是"去问一下那个系统、顺便做点事"，那才是接口的作用。
三个问题帮你定位
- 我的资料是一次性的还是要长期查？一份文件、问几轮就结束，用客户端的附件功能就够，别建库；几十份以上、每天在更新、还要指出出处，才轮到检索那一层。
- 我这份资料能不能被干净地转成文本？扫描版、双栏排版、表格密集的报告，先解决解析，否则后面每一步都在放大这一步的错误。
- 我能不能接受它照样会答错？检索只保证"模型看到了你的材料"，不保证材料本身正确、也不保证覆盖了你问的那件事。所以能不能看到引用来源、能不能一键回到原文，这一条应该当作选型的硬指标——它决定了答错时你能不能抓到原因。
RAG 的产出不是答案，是可复查的那份资料
这一层和语音那篇有同一个结论：跑完之后真正属于你的，不是这一次的回答，是你整理过的那批资料。回答会过期，而一份干净的 Markdown、一套稳定的切块方式、一个知道该找哪个嵌入模型的索引，是可以带着走的资产。
魔当实验室的看法是，个人用户在这个方向上的收益点比工程师的想象要窄一些——你多半不需要图谱、不需要多路召回、也不需要把候选堆到几十条。把资料转成整齐文本、按自然段切开、留好出处、先拿最小的嵌入模型跑一遍，这四件事做完，本地 RAG 就已经能覆盖大多数"它怎么就不知道我这个"的场景了。至于要不要为它单独搭一套平台，取决于你的资料多久更新一次、以及你愿不愿意承担换模型时整库重嵌的那几个小时。