RAG 找不到附录 G，问题不在向量库

标准 RAG 把文档切块、嵌入、存进向量库。查询也嵌入，取 top-k 最相近的块交给 LLM。流程很熟，问题也老：相似度回答的是“像不像”，相关性回答的是“能不能回答问题”。两件事经常不重合。

Avi Chawla 在推文里给了一个具体例子。同一家公司五份年报大概率共用模板，每年只改数字。FY2022 的问题可能和 FY2025 的块挨得很近，LLM 就可能从错误年份里取答案。跨引用更麻烦。某个块写着“见附录 G”，但那个附录表格在文本上跟它一点也不像，top-k 基本不会把附录 G 捞上来。

Vectorless RAG 换了一条路。它去掉 embedding 模型和向量库，把相似度搜索换成 LLM 推理。预处理阶段解析文档布局，生成一棵 ToC 树索引。每个节点放章节标题、页范围、短摘要。整棵树要能装进 LLM 的上下文。

查询时，LLM 同时拿到问题和树。它读章节标题和摘要，挑出最可能藏答案的几个章节。问债务，可能挑“财务摘要”，也会挑“附录 G”，因为附录 G 的摘要写着债务细节在那里。系统再拉完整章节，检查证据够不够。够，就基于完整章节回答，并给页码引用。不够，回到树里继续打开节点。聊天历史也在上下文里。问完资产接着问负债，它会回到同一份报告。

Avi Chawla 原帖里的视频把两条流程并排画了出来：

代价直接。每次查询都要在树上跑 LLM 调用。同一次运行里，top-k 向量搜索更便宜，当然不保证更准。树只在文档有真实结构时有用。适用边界清楚：长而结构化的文件、合同、手册适合树；大量短且互不相关的文本继续用向量库。有网友 Mohammad Vazin 说，百万级短工单用 BM25 加 reranker 成本更优。Avi 回复同意，短工单没有章节结构给树用。Dusan 提到，每往树下走一层就是另一次 LLM 调用，大手册的延迟会堆得很快。

年份混淆也有更便宜的解。有网友 Aakash Verma 说，先按财年 metadata 过滤再 top-k，通常就能解决 FY2022 和 FY2025 混在一起的问题。真正需要树的场景是“见附录 G”这类跨引用。另一个现实问题：扫描件 OCR 出来的 ToC 标题可能是错的。Avi 在回复里补了限制，标题和摘要组成的树必须装进 LLM 上下文，超大文档或大集合需要先缩小到某个文档或子树。

速度账也不能忽略。有网友 Subhash Dasyam 提到，递归调用会阻塞，没有 prefix caching，交互场景里每次查询几分钟很难接受。他引用论文结果说，GPT-5-mini 在 OOLONG 上比 base GPT-5 高 34 分，但那个基准偏检索；数学任务里开销会吃掉收益。另有网友 joel 用 SQLite 关键词搜索加 agent 记忆，在 LongMemEval 这个 500 题公开测试里，top five 找到正确对话的比例是 95.8%。Gafae Boran 则指出，用 Markdown 表格维护索引再按需打开文档，本质上是同一种模式：索引保持小，细节按需取。

这波讨论里最值得记住的判断不复杂。文档结构本身就是数据。把所有问题都丢给向量相似度，等于放弃章节、页码、跨引用这些信号。但树也不是免费午餐。选型只看两件事：文档有没有结构，查询愿不愿意付多次 LLM 调用。更稳的工程路径可能是先走便宜检索，证据不够再爬树。

参考链接：Avi Chawla 原帖 https://x.com/_avichawla/status/2116069319205663159 ，MIT Recursive Language Models 拆解 http://x.com/i/article/2029797316404899840 。