彻底抛弃RAG，让LLM像人一样翻文件找答案

推荐语

告别RAG碎片化检索，让LLM像人类一样直接翻阅完整文档，自主选择精准信息，实现更可靠的答案生成。

核心内容：
1. 传统RAG面临的语义完整性、溯源困难等核心挑战
2. 提出让LLM直接加载文档目录并选择阅读的新思路可行性
3. 新方案与传统优化方案在成本与效果上的对比分析

杨芳贤

53AI创始人/腾讯云(TVP)最具价值专家

本文的论述有具体的实验代码和数据支持，不要错过文末的github链接!

一、引言：RAG的普及与现实的差距

RAG（检索增强生成）已经成为大模型落地应用的标准配置。几乎所有面向企业知识库、文档问答的产品都在使用这一模式：先将文档切成片段，向量化存入数据库，收到用户问题后检索出最相关的几个片段，一并塞给大语言模型生成答案。

这个流水线看上去很合理，但真正用起来，很多团队发现结果并不如预期。答案常常“差点意思”——要么遗漏了关键信息，要么把上下文接错了位，有时还会自信地编造出文档里根本没有的内容。为了改善效果，人们开始在各个环节上做加法：换用不同的切片长度和重叠策略，加入重排序模型，甚至引入知识图谱构建复杂的实体关系网络。这些优化确实能带来一些提升，但付出的成本越来越高，而根本性的问题——碎片化检索与语义完整性之间的矛盾——始终没有解决。

本文提出一种不同的思路：与其继续给碎片化的RAG流水线打补丁，不如让大语言模型像人类一样，直接翻阅整理好的文档目录，自主决定读哪些文件，然后基于完整的原文给出答案。这种模式下，检索不再是给模型喂入一堆不知道上下文关系的碎片，而是让模型自己浏览知识库的骨架，选择精确的文件路径，打开原文档阅读。

一个很自然的顾虑是：大模型的上下文窗口装得下整个知识库的目录吗？以目前主流的256K上下文为例，如果将其中70%的空间用来加载经过精心设计的层级索引文件，完全可以容纳600到700个文件的路径与摘要。对于绝大多数企业来说，经过治理的高价值文档集往往就在这个数量级以内。这意味着，全量加载、一步到位的方案并非空想，而是现在就能做到的事。

二、传统RAG面临的三个核心挑战

在展开新方案之前，有必要先厘清传统RAG模式中几个难以回避的问题。

2.1 切片对语义完整性的影响

将文档按固定长度切分成片段，是RAG流水线的起点。这个操作看似中性，实则很容易破坏文档原有的逻辑结构。一个完整的论证可能被拦腰截断，表格和数据脱离标题后变得难以理解，跨段落的引用关系也一并丢失。虽然可以通过调整切片策略来缓解，但只要切片存在，语义的局部断裂就不可避免。模型看到的永远是孤立的碎片，而不是完整的语境。

2.2 溯源的可验证性问题

RAG方案通常会给出引用来源，但这些引用对应的往往是某个切片的编号，而不是用户可以直接打开核对的文件位置。用户想要验证答案是否正确，需要回到系统中去追溯那个片段，而这个片段本身可能已经脱离了原文的完整上下文。这种间接的引用机制提高了核验成本，也让幻觉更难被发现。当回答涉及多个文档时，片段之间的逻辑关系是否被正确保留，用户几乎无法判断。

2.3 GraphRAG等方案的适用边界

为了解决切片带来的碎片化问题，GraphRAG等方法应运而生。它通过构建实体和关系网络来捕捉跨文档的联系，在多跳推理等场景下表现出色。然而，这类方案的构建成本相当高，需要针对具体领域做大量抽取和建模工作。在实际的企业知识库场景中，真正需要复杂图推理的问题占比往往很低，大多数查询仍然是对具体政策、流程、条款的精准定位和理解。用高昂的基建成本去覆盖小概率场景，性价比值得商榷。

三、核心方案：构建可导航知识库，让LLM主动翻文件

针对上述问题，我们提出一种以“文件”为最小单位、依靠大模型自身导航能力来检索知识的方案。其核心思想是：将治理后的文档组织成清晰的目录结构，为每个文件生成简要摘要，汇总成一份索引文件。查询时，先将索引文件加载到上下文，让模型浏览并自行选择需要精读的文件，最后读取原文生成答案。

3.1 地基：以文件为最小单元，建立清晰的文档路径体系

首先需要对原始文档进行治理，统一转换为Markdown格式，并按主题组织在文件夹中，例如 /制度/考勤/。关键在于，每个文件应承载一个可被独立引用的知识单元——如果一份源文件内容庞大且包含多个可独立拆分的主题，就拆分成多个文件放入同一目录。索引的粒度就停留在文件级，不再向下深入到段落或章节。这样既保持了导航的清晰度，也让原文读取的精度自然对齐到文件边界。

3.2 预生成索引文件：一份LLM可以直接阅读的目录

基于上述目录结构，我们为每个文件生成一份简短摘要，然后采用层级合并的格式写入一个Markdown索引文件。例如：

# /制度/考勤
- 年假规定.md | 员工年假条件、天数计算与审批流程
- 加班调休规定.md | 加班认定、调休申请与补偿规则

这种写法将公共路径前缀提取为目录标题，子文件只保留文件名和摘要，相比逐行写出完整路径，可以节省15%到20%的上下文token开销。索引文件生成后会被缓存下来重复使用。当有文档新增或修改时，只需针对变更的文件重新生成摘要并局部更新索引文件对应条目，不需要全量重建。在每次查询时，系统只需一次性读取这个索引文件并将其注入上下文，完全不需要在运行时动态拼接。

3.3 检索范式的转变：从被动接收到主动探索

传统RAG的流程是：用户提问 → 检索器返回相关片段 → 片段嵌入prompt → 大模型生成答案。模型在这里是完全被动的，它只能基于被喂入的片段作答，没有机会主动获取更多信息。

本方案的流程则是：用户提问 → 加载预先生成的索引文件到上下文 → 大模型浏览整个目录，自主决定哪些文件与问题相关 → 系统根据大模型输出的文件路径列表，读取对应的原文并注入上下文 → 大模型基于完整的原文生成答案。

这一转变的核心在于，大模型不再是一个只能接收碎片的回答机器，而成为一个能够主动探索知识库的“翻文件者”。它看到的始终是完整的文档，而非被切散后可能丢失上下文的片段。

3.4 面对不同体量的三种策略

根据知识库的文件数量，可以灵活选择索引加载方式：

• 全量加载：当文件数在600–700以内（256K上下文下，层级合并索引加中等摘要），直接一次性将整个索引文件加载到上下文。这是最简洁、最理想的情况，也覆盖了绝大多数企业的全量知识库。

• 分块索引：当文件数超出全量加载窗口时，将索引按顺序分成多个批次（例如每批500条），让模型逐批浏览摘要，累积候选文件列表，最后统一读取所有候选文件的原文。这种方式保留了全部摘要信息，没有层级遗漏，是我们优先推荐的扩展策略。

• 分层索引：如果目录结构天然具有非常清晰的层级，也可以采用从根目录开始逐级下钻的方式。但这种方法有赖于目录归纳的准确性，且可能因为跨主题问题而漏掉相关文件，适合作为特殊场景的备用方案。

• 向量辅助补充：在需要跨主题快速定位的特殊情况下，可以引入向量检索作为辅助工具，但它在全量和分块策略下并不是必需的。

3.5 与传统RAG的对比

3.6 可行性基础

这套方案的可行性建立在几个已经成熟的现实条件之上：用7B级别的小模型即可完成文件摘要的生成，成本很低；大语言模型已经具备了在长上下文中浏览、比较和导航的能力；上下文窗口的持续扩大让全量索引加载从不可能变为可能。即便未来知识库规模继续增长，分块索引和分层索引也能从容应对，不存在技术天花板。

四、前置条件：文档治理，可以逐步推进

任何试图从文档中挖掘知识的方法，都绕不开文档本身的质量。如果原始文件本身混乱不堪、格式各异、内容重复或过时，无论采用什么检索策略，都很难得到理想的效果。

本方案的建议是，先对文档进行一轮轻量治理：筛选出真正有价值的文件，将格式统一清洗为Markdown，然后按照独立的知识单元进行拆分或合并，最后做一次人工审核确保内容准确。治理后的文档用于日常检索，原始文档则保留作为不可篡改的溯源副本。

这个过程的起步门槛并不高。通常只需要治理数十份高频使用的核心文档，就能搭建起一个最小可行知识库，成本在一两人周以内。文档治理并不是本方案的额外负担，而是所有严肃知识库建设的共有环节。

五、工程思路：文件系统 + 索引文件 + LLM

从工程实现的角度看，整个方案可以收敛到极简的形态。

核心资产只有三类：治理后的Markdown文档目录、预生成的索引文件（一个或多个.md）、以及一个轻量的应用层。应用层的职责很简单——读取索引文件、根据模型返回的路径读取原文、调用大模型API。文件摘要的生成可以离线完成，一台消费级显卡配合7B小模型就足够。

我们不再需要向量数据库、专门的检索服务、消息队列或图数据库。这些组件在某些场景下自有其价值，但就本方案的目标而言，它们都不在必需项之列。

整体工作流也很直白：扫描文档目录，为每个Markdown文件生成摘要，按层级合并格式写入索引文件。查询时，加载索引文件，大模型浏览并选择文件，系统按路径取原文，模型基于原文生成答案并附上精确的文件路径引用。

六、存储与性能：做减法之后的样子

在设计之初，我们曾考虑过沿用PostgreSQL加pgvector的组合来存储路径、摘要和可选的向量。但当实际测算数据量之后，发现这层依赖完全可以去掉。

以2000份文档为例，治理后的Markdown目录大约占用80MB空间，而索引文件本身只有数百KB。这种体量下，直接读取纯文本文件就完全够用，不需要引入数据库来管理。在全量加载和分块索引的策略下，文件系统自身就是最可靠的存储层。

向量检索的定位：非刚需，但仍有价值

当知识库规模极大，或者查询需求经常跨主题跳跃时，可以考虑引入向量检索作为辅助工具。具体的做法是：对文档原文做细粒度切片并向量化，使用pgvector进行存储和检索。但这里有一个与传统RAG本质不同的设计——我们只存储向量及其对应的文件路径和摘要，不保存切片后的原文。向量检索返回的结果，仅仅是作为大模型导航的参考信号，模型自主决定要不要去调阅对应的完整原文。

这样一来，向量搜索就不再是“把碎片喂给模型”的替代品，而是大模型手中一个可以主动调用的定位工具。答案的源头永远是完整的原文文件，而不是被检索出来的片段。这个组件完全按需引入，不必在项目一开始就内置，可以在方案演进中自然生长出来。

资源消耗方面，即便加上可选的向量索引，增加的量级也远低于传统RAG全套中间件的开销。响应延迟上，核心流程是索引文件读取、大模型导航和按需读原文，通常在秒级完成。如果启用了向量辅助，也只是增加一次毫秒级的向量检索，对整体体验几乎没有影响。

七、适用场景与边界

这套方案最适合的场景是：经过治理的企业内部知识库、政策制度汇编、产品手册、技术文档等对溯源准确性有明确要求的场合。在这些场景下，完整原文带来的语义完整性和可验证性是碎片化检索难以比拟的。

但也有一些场景不适合直接套用本方案：未经过清洗的杂乱文件堆、百亿级的公开网页搜索、实时流数据的处理，以及需要纯图推理的狭窄领域。对于这些场景，本方案的文档治理前提和文件级粒度可能不匹配，需要结合其他方法。

无论何种场景，本方案有一条明确的底线：不绕过文档治理，不生成虚构的引用。如果现状连基本的文档整理都难以推动，那么问题的根源很可能不在技术选型上。

八、落地路径：三步开始

如果认可这个方向，可以从以下步骤启动一个小规模试点：

1. 圈定高价值文档
   ：选取当前使用频率最高、被问到最多的数十份文档，将它们统一转为Markdown，按主题组织出合理的目录结构。
2. 生成索引文件
   ：为每个文件生成简短摘要，按层级合并格式写入索引文件并缓存。以后文档有增改时，只做增量更新，无需全量重建。
3. 搭建主动探索代理
   ：实现一个简单的查询循环——加载索引，让大模型输出需要阅读的文件路径列表，读取这些文件的原文注入上下文，最后生成答案。同时设定好护栏，比如禁止模型只凭摘要作答，以及限制最多探索轮数。
4. 在小范围内试运行，评估答案的准确性和溯源可靠性。如果文件数日后增长到超出全量加载窗口，自然切换到分块索引模式即可。

这个路径不依赖任何重型基础设施，一台普通的服务器、一套文件系统、一个大模型API就能跑起来。

九、总结

传统RAG的流水线设计，在某种程度上限制了大语言模型自身已经具备的推理和规划能力。当我们将检索固化为“找出最像的几个片段”时，模型被剥夺了主动浏览、比较和深入阅读的机会。

本文提出的方案，把文件系统当作知识库的骨架，把索引文件当作目录，把大语言模型当作一个会翻文件、能精读的同事。文件级的粒度、层级合并的索引格式、分块优先的扩展策略，共同构成了一个依赖极少、天然可溯源的轻量知识库方案。

如果你手头正有一批重要的文档等待被AI真正理解，不妨先从整理出最重要的几十份开始，生成第一个索引文件，让模型试着翻一翻。你可能会发现，答案一直就在完整的文件里，只是一直以来我们给模型看的东西，都太碎了。

配套github项目链接:

https://github.com/jsonlicn/knowledge-navigator