为什么放弃了 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 。