首先声明，RAG 不是坏主意，在其擅长的场景里依然是目前最佳选择。我们认真实践过，也在某些场景下跑通了。
去年，我们花了几个月搭建过几套完整的 RAG 管线：包括基础的 Naive RAG，一些进阶的 RAG 比如精排序、常见分块优化、混合多路检索等等。从文本提取到 Rerank 模型，每一个环节都花了不少时间优化，工程上看着很漂亮。但最终我们不得不承认一个事实：效果没那么好。
这篇文章不是要批判 RAG，而是诚实地分享我们遇到了哪些问题，尤其是我们在开发一个桌面知识库的时候遇到的问题，以及我们后来怎么想的。
做本地桌面应用，Embedding 模型的选择是一个没有好答案的问题。
小模型（参数量 < 500M）在设备上跑得动，但语义理解的质量一直不稳定——碰到专业文档、跨语言搜索、长文档时，召回率明显下降。大模型（1B+）质量虽然稍微好一点，但我们的场景希望用户能在普通的笔记本上也能流畅运行，1B 以上的模型内存和计算开销太大，后台常驻时对系统资源的占用让人无法接受。
桌面应用没有服务器可以依赖，只能在"跑得动"和"效果好"之间妥协。选了一个，另一个就要让步。这个困境在服务端应用里不存在，在本地优先应用里却是无解的。
向量语义搜索有一个根本性的弱点：它对专业术语的理解很差。
原因并不复杂。Embedding 模型是在通用语料上训练的，而代码函数名、医学缩写、法律条款、产品专名这些词在训练语料里出现频率低，在向量空间里的位置偏僻且不稳定。
实际表现是什么样的？用户搜 "RLHF"，不一定能找到写着 "Reinforcement Learning from Human Feedback" 的文档。搜"LTV"，可能匹配不到写着"用户生命周期价值"的分析报告。搜某个产品的型号，向量搜索根本抓不住这个词的准确语义。
这不是配置问题，不是参数调优能解决的，业内常见做法是做 embedding 模型的微调，但一般都是针对特定领域，只能在 ToB 场景中 work。
Embedding 优势是模糊语义匹配，它的劣势恰好就是精确词汇匹配。而用户的真实需求往往是两者都要。
召回率低和准确性差，是 RAG 管线的两个经典问题。针对准确性问题，业界的标准解法是引入 Rerank 模型做最后一步的精排。
我们也做了这一步，然后发现问题并没有被解决，只是被转移了。
Rerank 模型比 Embedding 模型更重、更慢。引入它之后，整个检索链路的延迟大幅上升，对本地应用来说尤其明显。更关键的是，Rerank 模型同样是在通用语料上训练的，同样存在专业词汇不敏感的问题——它只是在你已经召回的候选里重新排序，而不能召回那些一开始就没被捞到的文档。
最终结果：链路变慢了，架构变复杂了，根本问题还在。引入 Rerank 后，排序质量的提升非常有限，反而让 BM25 的作用几乎被掩盖了。
分块（Chunking）是 RAG 最无法绕开的问题。
文档被切成固定大小的片段之后，每个片段都与它的前后文脱节了。AI 拿到的是一段从报告中间截取的内容，不知道这段话在哪个章节，不知道前一段在讲什么，也不知道后续有没有结论。
最糟糕的情况是：一个关键段落恰好横跨两个 Chunk 的边界，两个 Chunk 都能匹配到，但又各自不完整。AI 拿到的两份碎片都沾了边，却都缺少关键信息，最终给出一个似是而非的回答。
这个问题业内有很多补丁办法，比如：加大 Chunk 重叠，加入父 Chunk 检索，引入 Small-to-Big 策略……每个补丁都能在某个维度上改善问题，但也都会带来新的代价——更多 Token、更复杂的管线、更难调试的行为、更加无法通用。
我们把这些补丁叠在一起，得到了一个复杂、易出错，但仍然不够好的系统。
通用分块策略对不同文档类型的效果差异极大，这是我们当初没有充分预判到的。
论文有 Abstract + 正文 + References 的结构；书籍有章节层级和页眉页脚；合同有条款编号和交叉引用；代码文档有 API 列表和示例代码；表格类文档的"内容"是列名和数据类型，而不是单元格里的文字……
固定窗口切块的策略不理解这些结构，分块点往往切在语义中间，把标题和它的正文分开，把条款编号和条款内容切断，把表头和数据分离。
每种文档类型其实需要完全不同的处理逻辑。但针对每种类型都写特化的解析器和分块策略，工作量巨大，维护成本也高——而且即使都做完了，效果也只是"比通用策略好一些"，仍然是碎片化的。
以上五个问题单独看，每个都还在可接受的范围内，但当 RAG 被实际接入 AI Agent 使用的时候，所有问题叠加在一起，效果非常糟糕。
一个真实的场景：AI 在帮用户分析一份合同，调用 search() 检索相关条款，拿到了 10 个 Chunk。有几个 Chunk 沾了边，但信息不完整。AI 无法判断该怎么继续，只好调整关键词重新搜索。再拿到 10 个 Chunk，还是不够。再换关键词，再搜一次。
每次搜索都是黑盒：AI 不知道换哪个关键词才能找到它需要的内容，不知道文档里到底有没有这个信息，不知道自己距离答案有多远。这种低效不是 Agent 能力不够，而是工具本身的设计不支持它做出合理的决策。
RAG 在设计上是为"用户直接提问"场景优化的，不是为"Agent 自主探索"场景设计的。
这些问题不是我们独有的，业内已经有明显的应对趋势：
微软的 GraphRAG 引入知识图谱来缓解上下文碎片化问题，把相关实体和关系显式地存储下来，而不是靠碎片拼凑。
PageIndex 不按固定大小切 Chunk，而是以页面为单位建立索引，保留文档的自然边界。
Agentic RAG 尝试让 AI 自主决定检索策略，而不是走固定管线——方向是对的，但在 RAG 架构上叠加 Agent 逻辑，复杂度随之翻倍。
最彻底的转向来自 Claude Code 和 Manus。它们干脆放弃了 RAG，回到最原始的方式：Glob + Grep + Read。找文件、搜关键词、读内容。没有向量数据库，没有 Embedding 模型，没有 Chunk 管线。效果反而更好。
这让我们想明白了一件事：RAG 的设计假设是"LLM 不够聪明，需要我们帮它把信息预处理好"。这在 GPT-3.5 时代是合理的。但现在的 LLM 已经有能力自主使用工具完成多步检索任务——它们不需要预切碎片，它们需要的是线索：文件在哪，结构是什么，然后它自己能决定读什么、读多少。
Glob + Grep + Read 对代码库很有效，但对用户文档行不通。代码库里 src/services/auth.ts 这个路径本身就在告诉你这是认证服务；但 2024年度总结(修改版)(最终版).docx，路径告诉你的信息约等于零。更别提 PDF 和 Word 是二进制格式，grep 根本读不了。
所以我们的问题变成了：能不能给文档也建立一套等价的"目录索引"，让 AI 用 search → outline → read 的方式渐进式地翻阅你的文件？
我们把这套方案叫做 Outline Index，一种渐进式披露大量文档给 AI Agent 的方法。
核心思想一句话：不替 AI 组装信息，而是给它一个大纲。
为每个文档建立一份结构化"名片"，包含文档的元数据（标题、作者、关键词、摘要）和结构大纲（章节标题、层级关系、行号范围）。AI 按三层路径访问文档：
这与人类阅读的方式完全一致：先找书，看目录，翻到对应章节精读。AI 在这个过程中有完整的上下文，知道自己在文档的什么位置，可以决定"再多看一点"，也可以跨文档对比。
对比传统 RAG：同样的场景下，Outline Index 方式的 Token 消耗约 800-3400，AI 拿到有完整上下文的精确信息。传统 RAG 返回 10 个预切碎片，消耗 4000-6000 tokens，AI 对文档结构一无所知。
另一个副产品：Embedding 的对象从原文 Chunk 变成了 Outline Index 本身。一个文档只需要一个向量。10000 个文档 ≈ 10000 个向量 ≈ 30MB 存储，检索速度也快得多。
关于领域词汇不敏感的问题，BM25 全文检索补上了这块短板。双路检索（BM25 精确匹配 + 向量语义理解），通过 RRF 融合，不再需要 Rerank 模型。
Outline Index 是 Linkly AI 的核心技术。如果你对具体的实现细节感兴趣，可以阅读这篇我们发布在少数派的文章：Outlines Index：一种渐进式披露大量文档给 AI Agent 的方法。
如果你想体验实际效果，请下载 Linkly AI，以及 linkly-ai-cli，接入到某个 AI 客户端中体验，实测效果远好于 RAG。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。