全文优先：整篇读，而不是切成碎片去检索

检索掩盖了什么样的失败​

标准流程是：把文档切成碎片、做向量嵌入、检索出和你的问题最相似的几片，再依据这几片作答。它好用的时候确实好用。它失败的时候，失败得无声无息：回答流畅、有出处，却恰好漏掉了那一段本该改变结论的话——因为那一段的相似度分数不够高，没被检索出来。

你从回答本身看不出来。没有任何信号告诉你「有三段相关内容没给模型看」。一次好的检索和一次坏的检索，看起来一模一样。

而这恰恰对最值得问的那些问题影响最大：

• 作者在哪里改变了立场？——证据散落在好几章里，没有哪一个片段单独装着它。
• 这篇论文没有主张什么？——「没有」是没法做向量嵌入的。
• 这两个来源在哪里有分歧？——需要两边都看到，而检索优化的是和问题的相似度，不是对分歧的覆盖。

一篇二十页的论文，能在现在的上下文窗口里放下好几遍。把它切块，是在解决一个你根本没有的问题。所以第一个问题不是「哪些片段相关」，而是「放不放得下」。放得下，模型就读你会读的东西，检索遗漏这一整类失败就不会出现。

「放不放得下」是一个预算，不是窗口大小​

这一点值得说精确，因为「我们把你的整份文档都放进去」正是那种该让你担心账单的话。

门槛大约是 4 万个汉字，或者 2.5 万个左右的英文单词——足以覆盖大多数论文、报告和较长的单章。在门槛以内，全文整篇放进去；超过门槛，就不这么做。

这个预算远小于现在的模型技术上能接受的长度。这是有意的，也是这一页真正想表达的设计主张：要紧的上限不是「放得下多少」，而是「模型还能注意到多少」。 超过一定的量，长上下文中间部分的回忆就变得不可靠——再往里塞，就从有帮助变成了有害，还更花钱。一个明确的预算，加上超出预算时的结构化路径，胜过一个被随意使用的大窗口。

由此有两个结果，都和花费有关：

• 文档那一块是稳定的，所以会被缓存。 每一轮都以同样的方式组装，放在所有变化的内容之前，服务商就能复用它。对同一篇论文问第二个、第三个问题，不用每次都为这篇论文全价再付一遍。
• 不需要为此建任何索引。 没有嵌入流程，没有向量库，提问之前也不用等文件夹处理完。在预算以内根本没有流水线——文档就是被直接读了。

你加入对话的文档会被优先完整读取；文件夹里的其余内容，只在问题需要时才检索。

放不下的时候怎么办​

书是放不下的，假装放得下是另一种失败。答案也不会变成「再多塞一点、碰碰运气」。它会变成一个人面对一本没读过的书时会做的事：先看结构，再读和问题相关的部分。

1. 先看结构。 建一张章节级的地图并沿着它导航。结构正是切块会破坏的东西，而关于整本书的问题恰恰依赖它。
2. 然后按需读整节。 判断某一章相关之后，模型把那一节完整读完——不是其中一小截，也不是按相似度排序出来的某个片段。意思不会在一个随意的边界处被截断。
3. 搜索用来定位，而不是用来「回忆」。 找某一句特定的话是查找，就按查找来做——关键词搜索，返回要打开的那一节，而不是去猜哪个片段意思最接近。精确的词——一处引用、一个法条编号、一个变量名——恰恰是相似度最容易搞混的。

同样的机制可以扩展到不止一本书。一个问题里加入好几份文档，预算从小到大分配，所以放在一本四百页的书旁边的三页简报，依然会被完整读到，不会被挤掉。把问题指向整个文件夹时则什么都不硬塞——否则最小的那些文件，不管相不相关，会先把预算吃光。每份文档有一句话主旨，按讲的是什么挑出问题需要的那几份，再用读书的方式去读：先结构，再按需读章节。

这和「长上下文能取代 RAG」有什么不同​

这不是在说上下文窗口已经让检索过时了。大规模的资料库依然需要检索，而且永远需要。

这里的主张要窄得多：这个决定应该按每份文档来做，而不是按整个架构来做。 多数工具什么都切块，是因为什么都切块更容易实现。这份简单的代价，由用户以看不见的遗漏来承担。

你在哪里会遇到它​

• 跨文档问答——本页描述的行为
• PDF 阅读器——依据全文回答一篇论文
• EPUB 阅读器——书放不下时会怎样

博客文章：怎样就一整本书向 AI 提问 · 为什么它里面没有向量数据库