从原理到落地：一文讲透 RAG 检索增强生成

企业知识库问答、智能客服、文档助手，这些产品都要让大模型回答特定领域的问题，背后用的基本都是 RAG（Retrieval-Augmented Generation，检索增强生成）。本文不涉及代码，从大模型本身的局限讲起。

一、没有 RAG 时，大模型应用面临的问题

1.1 模型的知识只来自训练数据

大语言模型（LLM）的工作方式，是根据前面的文字预测下一个词（token）。它掌握的知识，都是训练阶段从海量文本中学来、压缩进模型参数里的。这种方式直接带来三个问题。

第一，幻觉。 训练数据里没有答案时，模型不会说”我不知道”。它的任务是继续预测下一个词，于是会生成一段语法通顺、看似合理、实则编造的内容，这就是”幻觉”（Hallucination）。对企业应用来说，一个自信地给出错误答案的系统，比直接说不知道的系统危害更大。

第二，知识过时。 模型的知识停留在训练数据截止的那一刻。假设训练数据截止到 2025 年，那么此后的政策变化、产品更新和新闻事件，模型一概不知。

第三，无法访问私有数据。 企业内部的制度文件、产品手册、合同和业务数据从没出现在公开互联网上，自然也不在训练数据里。模型没在你们公司上过班，对这些信息一无所知，而企业应用最需要回答的恰恰是这类问题。

1.2 两种直接方案及其局限

最容易想到的办法有两种，但都有明显的局限。

方案一：微调（Fine-tuning）。 用企业自己的数据再训练模型，把私有知识写进参数。

问题在于：

• 成本高、周期长。 每次训练都要准备数据、算力和时间。
• 更新慢。 企业文档天天在变，不可能改一份文件就重训一次。
• 无法溯源。 知识压进参数后，模型说不出答案出自哪份文件的第几页，用户难以核实。
• 仍会幻觉。 微调能让模型更熟悉某个领域，但不能保证它记住每个具体事实。

微调更擅长改变模型的行为方式，比如语气、输出格式或遵循某种流程，而不擅长精确注入大量事实。

方案二：把整个知识库塞进输入。 现在的模型能处理很长的输入，能不能每次提问都把全部文档一起交给模型？

听起来简单，实际行不通：

• 上下文窗口有上限，输入越长效果越差。 即使窗口已经很大，企业知识库的体量通常仍远超上限。更麻烦的是，研究发现输入很长时，模型对位于中间部分的信息利用得明显更差（”Lost in the Middle”现象），答案准确性反而下降。
• 成本高。 大模型按 token 计费，每个问题都附带整个知识库，费用会成倍增长。
• 速度慢。 模型要先读完全部内容再作答，响应时间让用户难以接受。

1.3 更合理的思路

既然不能把知识写进模型，也不能每次把全部资料都塞给模型，更合理的做法是：模型回答之前，先从知识库里找出与问题最相关的几段内容，只把这几段交给模型，让它据此作答。

这就是 RAG 的核心思想：先检索（Retrieval），再生成（Generation），用检索到的资料增强（Augmented）生成质量。

二、RAG 解决什么问题，边界在哪里

讲流程之前，先明确 RAG 的能力范围。这对产品经理尤其重要，因为它决定一个需求适不适合用 RAG 来做。

2.1 RAG 能解决的问题

• 知识时效。 知识放在外部知识库里，文档更新后只需重新处理这部分文档，不必重训模型。
• 私有数据接入。 内部资料可以留在企业自己的系统中，只在需要时检索出相关片段交给模型。
• 答案可溯源。 答案基于检索到的具体片段，系统可以标注出处，用户点击即可核实。
• 降低幻觉。 在提示词里约束模型”只依据给定资料回答，资料里没有就说不知道”，可以显著减少编造。注意是降低而不是消除，原因后文会讲。

2.2 RAG 不能解决的问题

• 不能提升模型本身的推理能力。 RAG 只负责找资料，找到之后的理解、推理和表达全看模型自身。
• 不擅长统计和全局汇总。 比如”公司今年一共签了多少份合同？”或”所有文档中提到最多的风险是什么？”。RAG 每次只检索少量最相关的片段，无法遍历全部数据做统计，这类问题更适合交给数据库查询或专门的分析工具。
• 检索不到，就答不出。 答案所在的文档如果没被正确解析、切分或检索到，模型再强也无从回答。
• 数据错，答案就错。 RAG 会忠实地基于检索结果作答，知识库里的文档过时或有误，答案也会跟着错。
• 不适合改变模型的行为方式。 如果需求是让模型用特定语气说话、按固定格式输出，应该用提示词或微调，而不是 RAG。

RAG 不会让 AI 变得更聪明，只是让它在回答之前先找到对的资料。

三、RAG 的基础流程

RAG 系统分两个阶段工作：

• 索引阶段（离线）： 提前把企业文档处理好、存起来，在用户提问之前完成。
• 查询阶段（在线）： 用户提问时，实时检索相关内容并生成答案。

下面以”为一家企业搭建知识库问答系统”为例，逐步说明。

3.1 分块（Chunking）

原来的问题： 企业的原始文档往往很长，一份文档里可能有好几个主题。整篇文档作为一个整体处理，语义会被平均化，既像在讲 A 又像在讲 B，检索时无法精确匹配具体问题。

分块解决什么： 把长文档切成许多小块（chunk），每块尽量只表达一个相对完整的意思，检索时就能精确定位到与问题相关的那一小段。

常见的切法有按章节、按段落和按固定字数（例如每 500 字一块），选哪种要看文档的实际结构。分块粒度对效果影响极大，第四部分会专门讨论。

3.2 向量化（Embedding）

原来的问题： 最直接的检索方式是关键词匹配，在文档里找和问题相同的字词。但它理解不了”意思相同、说法不同”的情况。用户问”怎么请假”，制度文件里写的是”休假申请流程”，关键词匹配就会漏掉。

向量化解决什么： 计算机不理解文字，只能处理数字。向量化就是用一个专门的模型（Embedding 模型）把每段文字转换成一组数字，也就是这段文字在”语义空间”中的坐标。

用简化的二维坐标来理解：

文本块	内容	向量（坐标）
A	张三是男性	(1, 1)
B	张三今年 30 岁	(2, 1)
C	本月销售额 1 万元	(1, -1)

Embedding 模型的关键特性是：意思相近的内容坐标距离近，意思无关的内容距离远。 上表中 A 和 B 都在描述张三，所以离得很近；C 讲的是销售额，与前两者离得远得多。

真实的 Embedding 向量通常有几百到几千个维度，人没法直观想象，但数学原理一样。正因为比较的是意思而不是字面，”怎么请假”和”休假申请流程”才能匹配到一起。

3.3 向量数据库

把每个文本块和对应的向量一起存起来，就得到了向量数据库。可以简单理解为一张表，至少有两列：文本内容和对应向量。到这里，索引阶段就完成了。

还有一个隐藏问题： 用户提问时，系统要把问题和库里的所有向量逐一比较。知识库有几百万个文本块时，逐一计算会非常慢。

向量数据库额外解决的： 专业的向量数据库会建立近似最近邻（ANN，Approximate Nearest Neighbor）索引，常见算法如 HNSW。它提前按位置关系把向量组织好，查询时只在一小部分区域内搜索，不必遍历全部数据。

代价： “近似”二字已经说明了一切。它用极少的精度损失换来数量级的速度提升，实际应用中这笔交换几乎总是划算的。

3.4 相似度检索与 Top-K 召回

用户提问，例如”张三是谁？”。系统先用同一个 Embedding 模型把问题也转成向量，假设得到 (1.5, 0.5)。

接着计算问题向量与库中各向量的相似度，常用两种方法：

• 余弦相似度： 计算两个向量夹角的余弦值。夹角越小，方向越一致，意思越相近。
• 欧氏距离： 直接计算两个坐标点之间的直线距离。距离越短，意思越相近。

按欧氏距离计算，上例中问题 (1.5, 0.5) 与 A、B 的距离都约为 0.71，与 C 的距离约为 1.58，因此 A 和 B 被认为与问题更相关。

系统按相似度排序后，返回最相关的前 K 个文本块，这一步叫 Top-K 召回。K 可以自行设定，比如 4、10 或更多。

3.5 重排序（Rerank）

原来的问题： 向量检索快，但只是一次粗筛。Embedding 模型把问题和文档分别转成向量再比较，转换时两者互相看不见对方。这种方式能判断”这段话和问题像不像”，却判断不了”这段话有没有回答问题”。

例如问题是”张三的年龄”，一段写着”李四的年龄是 28 岁”的文本在语义上和问题非常接近，很可能被召回，但它显然没有回答问题。

重排序解决什么： 用一个更精细的模型（通常是交叉编码器，Cross-Encoder），把问题和每个候选片段放在一起输入，逐一判断相关程度后重新排序，只保留真正能回答问题的几段。比如从召回的 4 个片段里选出最相关的 2 个。

代价： 重排序模型更准，也更慢，没法对整个知识库使用。所以业界通行两步走：先用向量检索从海量数据中快速召回几十个候选，再用重排序从中精选几个。召回负责快，重排负责准。

3.6 组装提示词与生成答案

最后，系统把三样东西组合成完整的提示词（Prompt）交给大模型：

1. 用户的原始问题；
2. 重排序后选出的参考资料；
3. 约束性指令，例如：”请严格依据以下资料回答；如果资料中没有相关信息，请回答’资料中未找到相关内容’，不要自行编造；请在答案中注明引用的资料编号。”

大模型基于这些内容生成答案，返回给用户。

以上步骤都在后台完成。用户只看到自己问了”张三是谁”，系统给出准确回答，可能还附上了出处链接。大模型本身没有任何改动，只是回答前多了一步查资料。

四、工程落地中的难点与对应方案

流程看起来简单，真到企业里落地，每个环节都有坑。下面按流程顺序，逐个说明常见问题和解决思路。

4.1 文档解析：一切的起点

问题： 企业数据很少是干净的纯文本，可能是 PDF、Word、Excel、PPT、扫描件或带图片的说明书。其中 PDF 最难处理，因为它的设计目标是打印出来好看，而不是让计算机读懂。直接提取文字时，双栏排版常被读成交错的乱序文字，表格被拆成一堆没有行列关系的数字，页眉页脚混进正文，图片和扫描件里的文字则完全丢失。

解决思路： 商业项目通常会组合多种技术：

• 版面分析模型： 先识别页面上哪里是标题、正文、表格、图片和页眉页脚，再按正确的阅读顺序提取内容。
• OCR（光学字符识别）： 识别扫描件和图片中的文字。
• 表格专项处理： 把表格还原成保留行列结构的格式（如 Markdown 表格），而不是一串散乱的数字。

为什么这一步最重要： 垃圾进，垃圾出。文档解析错了，后面的分块、检索和生成做得再好也没用，答案一定是错的。很多 RAG 项目效果不佳，根源就在这一步。

4.2 分块：粒度决定效果

分块是影响 RAG 效果最关键的环节之一，它面临一个根本矛盾。

块太大： 比如 1 万字一块，一个块里会混进多个主题。用户想查 A，检索出来的块里却夹着 B、C、D 等大量无关信息，既降低检索精度，又浪费模型的上下文。

块太小： 会造成语义断裂。比如”张三是一个好人”，如果”张三”切在一个块里、”是一个好人”切在另一个块里，检索到后者时，模型根本不知道是谁。

围绕这个矛盾，业界发展出几种逐步改进的方案。

改进一：按结构切分 + 重叠窗口。

• 原来的问题： 按固定字数机械切分，经常从一句话或一个段落中间切断。
• 解决什么： 优先按文档的自然结构（章节、段落）切分，同时让相邻块之间保留一小段重叠（比如前后各重叠 50 字），避免边界处的信息完全丢失。
• 代价： 重叠会带来一定的存储冗余。

改进二：父子块（小块检索，大块返回）。

• 原来的问题： 小块检索准，但信息不完整；大块信息完整，但检索不准，两者似乎不可兼得。
• 解决什么： 同时按两种粒度切分。检索时用子块（小块，如一两句话）做精确匹配；命中后，交给模型的是它所属的父块（大块，如整个段落或小节）。这样检索精度和上下文完整性都能兼顾。
• 代价： 需要维护块之间的层级关系，系统更复杂。

改进三：为每个块补充上下文。

• 原来的问题： 块从原文切出来后，就丢了所处的背景。比如某个块写着”该公司第二季度营收同比增长 3%”，单看这一块，不知道”该公司”是哪家、是哪一年。用户问”A 公司 2024 年二季度营收增长多少”时，这个块很可能检索不到。
• 解决什么： 向量化之前，先让大模型通读整篇文档，为每个块生成一两句背景说明（比如”本段出自 A 公司 2024 年第二季度财报的营收部分”），加在块前面再向量化。这就是 Anthropic 在 2024 年提出的”上下文检索”（Contextual Retrieval）。
• 代价： 索引阶段要为每个块额外调用一次大模型，处理成本上升。

分块没有通用的标准答案，目标是让每个块的信息颗粒度刚好：小到能精确检索，又完整到让模型看得懂。具体方案要结合文档类型反复测试。

4.3 查询处理：用户的问题往往不好检索

问题： 用户提问通常口语化、简短，甚至支离破碎。比如只输入”张三是谁”，或者在多轮对话里问”那他的上级呢？”。前者信息太少，后者有”他”这样的指代词，单独拿去检索，系统根本不知道”他”是谁。

改进一：问题改写（Query Rewrite）。

• 解决什么： 检索之前，先让大模型把原始问题改写得更完整、更规范、更贴近知识库的表述。例如把”张三是谁”改写为”张三的基本信息，包括性别、年龄、部门和职位”；在多轮对话中，结合历史记录把”那他的上级呢？”改写为”张三的直属上级是谁”。改写还能补上用户没说出口的隐含需求。
• 代价： 多一次大模型调用，延迟增加；改写也可能偏离用户原意。在 2026 年的多轮对话 RAG 评测 SemEval-2026 Task 8（MTRAGEval）中，有参赛团队发现：把用户的原始问题和改写后的问题拼在一起检索，效果优于单独使用其中任何一个。

改进二：问题拆解。

• 原来的问题： 复合问题，比如”对比 A 产品和 B 产品的价格和保修政策”，涉及多个知识点，分散在不同文档里，一次检索很难找全。
• 解决什么： 先把复合问题拆成多个子问题（”A 产品的价格””B 产品的价格””A 产品的保修政策”……），分别检索，再把结果汇总交给模型。
• 代价： 检索次数增加，响应变慢。

4.4 检索方式：单一检索各有盲区

问题： 向量检索擅长理解意思，对字面精确的内容反而不敏感。人名、产品型号、合同编号、错误代码（如”E-1024”）本身没多少语义，向量检索常常匹配不准。传统关键词检索正好相反：字对字精确匹配，却理解不了同义表达。

打个比方，关键词检索像查字典，必须一字不差；向量检索像问一个懂你意思的朋友，能听懂你想问什么，但给的答案可能有出入。

改进一：混合检索（Hybrid Search）。

• 解决什么： 同时做关键词检索（最常用的算法是 BM25）和向量检索，再合并两路结果。两者的盲区正好互补，这已是当前生产环境的标准做法。
• 代价： 需要维护两套索引。

改进二：结果融合（RRF）。

• 原来的问题： 两路检索的打分方式完全不同。关键词检索的分数可能是 15.3，向量检索的相似度可能是 0.82，尺度不一，无法直接相加比较。
• 解决什么： 倒数排名融合（Reciprocal Rank Fusion，RRF）不看具体分数，只看每个结果在各自列表中的排名。一个片段在两路检索中都排得靠前，最终得分就高。方法简单稳定，只有一个平滑常数 k，通常直接用原论文推荐的 60，基本不用调。

改进三：元数据过滤与权限控制。

• 原来的问题： 企业里不同员工能看的文档不同，普通员工不该通过问答系统查到高管的薪酬文件。如果只在界面上做限制，检索层却能拿到所有数据，就有泄露风险。另外，用户常常只想查某个部门、某个时间段的资料。
• 解决什么： 存储每个文本块时，同时记录元数据，比如所属部门、文档日期、密级和可访问人员。检索时先按元数据和用户权限过滤，只在有权访问的范围内搜索。
• 代价： 要和企业现有的权限系统打通，并在文档权限变化时同步更新。

4.5 生成环节：资料对了，答案仍可能错

问题： 即使检索到了正确资料，模型仍可能出错：可能无视资料，凭自己的印象作答；可能把几段资料错误地拼在一起；也可能在资料不足时照样编造。这正是前文说 RAG 只能降低、不能消除幻觉的原因。

解决思路：

• 强化指令约束： 在提示词中明确要求只依据资料作答，资料不足时直接说明。
• 要求引用出处： 让模型标注每个观点来自哪段资料。这既方便用户核实，也能倒逼模型言之有据。系统还可以自动检查引用是否真实存在。
• 选择合适的基座模型： 模型要有良好的指令遵循能力和长文本理解能力，输出稳定。

模型选型上，开源和闭源各有取舍。开源模型可以部署在企业内网，数据不出本地，安全性和可控性更强，但要自己承担部署和运维成本；闭源商业模型通过 API 调用，能力通常更强、用起来更方便，但需要评估数据合规要求。怎么选，取决于企业对数据安全的要求和预算。

无论选哪种，基座模型的能力都是底线。模型能力不足，即使检索到了完全正确的资料，最终答案也可能是错的。

4.6 评估：没有度量，就无法优化

问题： 前面介绍了大量优化手段，但每种手段在不同场景下效果不同。分块是 300 字好还是 800 字好？要不要加重排序？如果只靠人工随手提几个问题、凭感觉判断”好像变好了”，很容易误判，甚至改出新问题都不知道。很多 RAG 项目停滞不前，就是因为缺少评估体系。

解决思路： 建立测试集和评估指标，把 RAG 拆成检索和生成两部分分别评估。效果不好时，就能快速定位是没找到，还是找到了但没答好。

检索环节的指标：

• 召回率： 回答问题所需的资料，有多少被检索出来了？
• 命中率： 正确资料是否出现在返回的前 K 个结果里？排在第几位？

生成环节的指标：

• 忠实度： 答案里的每个说法，能否在检索到的资料中找到依据？这个指标直接衡量幻觉程度。
• 答案相关性： 答案是否真正回应了用户的问题，而不是答非所问？

测试集怎么来： 可以从真实的用户提问记录中挑选，可以请业务专家编写一批标准问题和标准答案，也可以让大模型从文档中自动生成问答对，再由人工审核。业界常用的开源评估框架有 RAGAS 等，可以借助大模型自动给上述指标打分。

五、2026 年 RAG 的进展与展望

“把文档切块存进向量库、按相似度检索、交给模型生成”，这种最基础的做法通常被称为”朴素 RAG”（Naive RAG）。到 2026 年，它已被视为原型阶段的方案。RAG 的思想没有过时，但形态正在明显变化。下面是几个最值得关注的方向。

5.1 从固定流水线到智能体自主检索（Agentic Search）

原来的问题： 传统 RAG 是开发者预先设计好的固定流水线：检索一次，拿到结果，生成答案，模型只能被动接收检索结果。第一次检索方向错了，系统没机会纠正；遇到需要多步查找的复杂问题，一次检索往往不够。

新方向解决什么： 让大模型以智能体（Agent）的身份主动掌控检索过程。系统给它一组搜索工具（关键词搜索、向量搜索、文件浏览、数据库查询等），由它自己判断要不要检索、用哪个工具、搜什么关键词、结果够不够、要不要换个思路再搜。这更接近人查资料的真实做法。

这一方向在 2025—2026 年有几项代表性进展：

• 编程工具率先转向。 Claude Code 的负责人 Boris Cherny 在 2025 年就公开分享过：早期版本用的是”RAG + 本地向量数据库”，后来发现让智能体自主搜索（grep、读文件等）效果通常更好，实现也更简单，还避开了数据安全、隐私和索引过时等问题；2026 年初他再次重申了这一点。不过各家做法并不一致：Cursor 仍保留了基于自研 Embedding 模型的代码库索引，让智能体把语义搜索和 grep 搭配使用，其公开的测试结果显示，两者结合的效果最好，在大型代码库中优势尤其明显。
• 学术研究提供了佐证。 亚马逊团队在 AAAI 2026 发表的论文《Keyword search is all you need》系统对比了两种方案：让智能体只用基础的关键词搜索工具（不建向量数据库），就能达到传统 RAG 系统九成以上的效果，在知识库频繁更新的场景中尤其有优势。论文所说的成本优势，主要指省去了向量数据库的基础设施和维护开销。
• 用训练提升检索策略。 以 2025 年发表的 Search-R1 为代表的研究，用强化学习专门训练模型”怎么搜”，让模型学会在推理过程中何时检索、如何调整查询。

代价与边界： 智能体检索要多轮调用大模型，响应更慢、API 费用更高。2026 年有开发者用日文 PDF 对上述亚马逊论文做了小规模复现（10 个问题）：智能体方案的准确率更高，但每个问题的平均 API 费用约为传统向量 RAG 的 8 倍，平均延迟也长了近 5 倍。因此务实的做法往往是按需路由：简单问题直接回答，常规问题走传统 RAG，复杂问题才交给多步检索。这种思路称为自适应 RAG（Adaptive RAG），最早由 2024 年的同名论文系统提出。

对产品经理来说，这意味着 RAG 正在从一个功能模块变成智能体的一项能力。检索不再是固定步骤，而是智能体可以调用的工具之一。

5.2 长上下文与 RAG：互补而非替代

原来的问题： 模型的上下文窗口扩展到百万 token 级别后，”RAG 已死”的说法一度很流行：既然模型能一次读完整个知识库，还需要检索吗？

2026 年的共识： 长上下文和 RAG 是互补关系。一种常见组合是：先用 RAG 把范围缩小到少数几份相关文档，再把这些完整文档（而不是零碎片段）放进长上下文窗口，让模型基于更完整的信息作答。这样既避免了切块导致的信息不全，也避免了全量输入导致的成本失控。

另一个相关技术是上下文缓存（Context Caching，也叫提示词缓存）：对于反复使用的大段固定内容（如一本产品手册），模型服务可以缓存其计算结果，后续请求直接复用，大幅降低重复输入的成本。

为什么 RAG 仍然必要： 成本仍是硬约束。对访问量大的应用来说，每次提问都输入上百页资料，在 2026 年初依然不可持续。此外，企业知识库的规模往往远超任何上下文窗口，长上下文本身也解决不了权限控制和来源追溯问题。

5.3 多模态与视觉文档检索

原来的问题： 前文提到，文档解析是 RAG 最难的环节之一。传统做法是先用 OCR 和版面分析把 PDF 转成文字再检索。但对图表密集、版式复杂的文档（财报、技术手册、幻灯片），转换本身就会丢失大量信息：图表里的趋势、表格的结构、图文之间的对应关系。2026 年业界普遍认为，对图表密集的资料，纯文本 RAG 存在一个靠优化分块突破不了的效果上限。

新方向解决什么： 2024 年提出的 ColPali 换了一种思路：不再把页面转成文字，而是把 PDF 的每一页直接当作图片，从图像本身生成向量，完全跳过 OCR。检索时，系统直接找到与问题最相关的页面图片，再交给能看懂图片的多模态大模型生成答案。ColPali 的作者同时发布了视觉文档检索评测 ViDoRe，此后沿用这一思路的 ColQwen 等模型不断刷新它的成绩。

目前主流的多模态 RAG 方案大致有三类：

• 图片转文字描述： 用多模态模型给图片写一段文字描述，再按普通文本处理。最简单，但描述本身可能出错，错误会污染整个索引。
• 统一多模态向量： 用一个模型把文字和图片映射到同一个向量空间，直接混合检索。
• 整页图像检索： 即 ColPali 的方式，对图表密集的文档检索效果最好。

代价： 整页图像检索要为每一页存几百到上千个向量（ColPali 约 1030 个），而传统方案每个文本块只存一个向量，存储和算力开销高出两到三个数量级，多数检索引擎还需要专门适配。相比之下，统一多模态向量的存储成本低得多，在不少企业文档场景中已经够用。

5.4 知识图谱与企业级治理

原来的问题： 标准 RAG 的检索基于概率：它返回的是与问题语义最相似的内容，不一定是最完整、最正确的内容。问题涉及多个实体之间的关系时（例如”张三负责的项目中，哪些供应商合同明年到期？”），答案分散在多份文档里，需要沿着”人 → 项目 → 合同 → 供应商”的关系链逐步追踪，单纯的相似度检索很难找全。

新方向解决什么：

• GraphRAG（图谱增强检索）： 索引阶段用大模型从文档中抽取实体（人、项目、产品、公司）及其关系，构建知识图谱。检索时不仅找相似片段，还能沿着图谱中的关系把相互关联的信息一并找出来，对需要跨文档关联或全局视角的问题尤其有效。代价是构建图谱成本很高，文档更新后图谱也要同步维护。
• 检索层的权限控制： 智能体开始代替用户自主检索后，权限问题更加突出。2026 年企业级 RAG 的一项基本要求是：权限必须在检索层执行，而不只是在界面上做限制，确保无论用户本人还是替用户干活的智能体，都只能拿到有权访问的数据。
• 实时数据接入： 越来越多的系统不再要求把所有数据提前导入知识库，而是在需要时直接查询企业的业务系统，获取最新数据。

5.5 展望：RAG 的思想在扩展，而不是消失

从这些进展看，检索正在从一个固定的技术模块，变成 AI 系统获取外部信息的通用能力。

具体的检索方式在变：从单一的向量检索，到关键词、向量、图谱和多模态混合；从开发者预设的固定流程，到智能体自主决策。但 RAG 的核心思想没变，反而更重要了：大模型不应只靠自己的记忆回答问题，而应在回答之前，先找到可靠、最新、有权访问的资料。

六、总结

回顾全文：

1. 没有 RAG 时， 大模型面临幻觉、知识过时和无法访问私有数据三大问题；微调和全量输入两种直接方案，都受限于成本、时效和效果。
2. RAG 的核心， 是在模型回答之前先检索相关资料，再基于资料生成答案。它能解决知识更新、私有数据接入和答案溯源的问题，但不能提升模型的推理能力，也不擅长统计汇总类问题。
3. 基础流程 分为离线索引（解析、分块、向量化、存储）和在线查询（检索、重排、生成）两个阶段。Embedding 负责找得快，Rerank 负责找得准，大模型负责写答案。
4. 落地难点 贯穿每个环节：文档解析决定效果上限，分块粒度决定检索精度，查询改写和混合检索提升召回能力，评估体系是一切优化的前提。
5. 2026 年的趋势 是智能体自主检索、长上下文与 RAG 结合、多模态视觉检索和企业级治理。检索形式更灵活了，但”先找对资料，再回答问题”的核心思想没有变。