为什么放弃了 RAG？ RAG 的六大难题

RAG 本身并不算是个坏主意。我们认真实践过，也确实在某些场景下跑通了。

去年，我们花了几个月搭过几套完整的 RAG 管线：三阶段处理（ Extract 、Chunk 、Embed ），三种搜索策略（ Vector 、BM25 、Hybrid + Reranking ）。从文本提取，粗排，到 Rerank 精排，每一个环节都认真做了一遍。工程量不小，技术上看着很漂亮。

但最终不得不承认一个事实：效果不好

这篇文章不是要批判 RAG ，而是诚实地分享下我们具体遇到了哪些问题，以及我们后来怎么想的。以及，小广告。。。

问题一：Embedding 模型两难

做本地桌面应用，Embedding 模型的选择是一个没有好答案的问题。

小模型（参数量 < 500M ）在设备上跑得动，但语义理解质量不稳定碰到专业文档、跨语言搜索、长文档时，召回率明显下降。大模型（ 1B+）质量好，但在普通用户的笔记本上内存和计算开销太大，后台常驻时对系统资源的占用让人无法接受。

桌面应用没有服务器可以依赖，只能在"跑得动"和"效果好"之间妥协。选了一个，另一个就要让步。这个困境在服务端应用里不存在，在本地优先应用里却是无解的。

问题二：领域词汇不敏感

向量语义搜索有一个根本性的弱点：它对专业术语的理解很差。

原因并不复杂。Embedding 模型是在通用语料上训练的，而代码函数名、医学缩写、法律条款、产品专名这些词在训练语料里出现频率低，在向量空间里的位置偏僻且不稳定。

实际表现是什么样的？用户搜 "RLHF"，不一定能找到写着 "Reinforcement Learning from Human Feedback" 的文档。搜"LTV"，可能匹配不到写着"用户生命周期价值"的分析报告。搜某个产品的型号，向量搜索根本抓不住这个词的准确语义。

这不是配置问题，不是参数调优能解决的，业内常见做法是做 embedding 模型的微调，但一般都是针对特定领域，只能在 ToB 场景中 work 。

Embedding 优势是模糊语义匹配，它的劣势恰好就是精确词汇匹配。而用户的真实需求往往是两者都要。

问题三：Rerank 的代价

召回率低和准确性差，是 RAG 管线的两个经典问题。针对准确性问题，业界的标准解法是引入 Rerank 模型做最后一步的精排。

我们也做了这一步，然后发现问题并没有被解决，只是被转移了。

Rerank 模型比 Embedding 模型更重、更慢。引入它之后，整个检索链路的延迟大幅上升，对本地应用来说尤其明显。更关键的是，Rerank 模型同样是在通用语料上训练的，同样存在专业词汇不敏感的问题它只是在你已经召回的候选里重新排序，而不能召回那些一开始就没被捞到的文档。

最终结果：链路变慢了，架构变复杂了，根本问题还在。引入 Rerank 后，排序质量的提升非常有限，反而让 BM25 的作用几乎被掩盖了。

问题四：碎片化的上下文

分块（ Chunking ）是 RAG 最无法绕开的问题。

文档被切成固定大小的片段之后，每个片段都与它的前后文脱节了。AI 拿到的是一段从报告中间截取的内容，不知道这段话在哪个章节，不知道前一段在讲什么，也不知道后续有没有结论。

最糟糕的情况是：一个关键段落恰好横跨两个 Chunk 的边界，两个 Chunk 都能匹配到，但又各自不完整。AI 拿到的两份碎片都沾了边，却都缺少关键信息，最终给出一个似是而非的回答。

这个问题业内有很多补丁办法，比如：加大 Chunk 重叠，加入父 Chunk 检索，引入 Small-to-Big 策略……每个补丁都能在某个维度上改善问题，但也都会带来新的代价更多 Token 、更复杂的管线、更难调试的行为、更加无法通用。

我们把这些补丁叠在一起，得到了一个复杂、易出错，但仍然不够好的系统。

问题五：不同文档类型需要特殊处理

通用分块策略对不同文档类型的效果差异极大，这是我们当初没有充分预判到的。

论文有 Abstract + 正文 + References 的结构；书籍有章节层级和页眉页脚；合同有条款编号和交叉引用；代码文档有 API 列表和示例代码；表格类文档的"内容"是列名和数据类型，而不是单元格里的文字……

固定窗口切块的策略不理解这些结构，分块点往往切在语义中间，把标题和它的正文分开，把条款编号和条款内容切断，把表头和数据分离。

每种文档类型其实需要完全不同的处理逻辑。但针对每种类型都写特化的解析器和分块策略，工作量巨大，维护成本也高而且即使都做完了，效果也只是"比通用策略好一些"，仍然是碎片化的。

问题六：Agent 使用体验极差

以上五个问题单独看，每个都还在可接受的范围内，但当 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 已经有能力自主使用工具完成多步检索任务它们不需要预切碎片，它们需要的是线索：文件在哪，结构是什么，然后它自己能决定读什么、读多少。

我们的解法：Outline Index

Glob + Grep + Read 对代码库很有效，但对用户文档行不通。代码库里 src/services/auth.ts 这个路径本身就在告诉你这是认证服务；但 2024 年度总结(修改版)(最终版).docx，路径告诉你的信息约等于零。更别提 PDF 和 Word 是二进制格式，grep 根本读不了。

所以我们的问题变成了：能不能给文档也建立一套等价的"目录索引"，让 AI 用 search → outline → read 的方式渐进式地翻阅你的文件？

我们把这套方案叫做 Outline Index。

核心思想一句话：不替 AI 预切信息，而是给它一张地图。

为每个文档建立一份结构化"名片"，包含文档的元数据（标题、作者、关键词、摘要）和结构大纲（章节标题、层级关系、行号范围）。AI 按三层路径访问文档：

• search：搜索相关文档，返回文件列表和 Metadata ，约 50 tokens/文件
• outline：查看文档的结构地图，约 200-500 tokens/文件
• read：精准读取指定章节的原文，按需加载

这与人类阅读的方式完全一致：先找书，看目录，翻到对应章节精读。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 。