先说结论：让 AI 答一份几百页的文档,别一股脑把全文塞进上下文,先让它把目录索引建出来,问到哪一节再去抓哪一节。我前阵子折腾一个 400 多页的产品 PRD 问答,踩了这个坑,改成"先建目录、再定位"之后,答错率肉眼可见地降下来了。

为什么不能全文塞,我想分三段把里头的原理讲清楚,这玩意儿不是玄学,是实打实的机制问题。

第一段,上下文窗口是有物理边界的,塞满之后注意力会被稀释。

很多人以为现在模型上下文动不动 128K、200K,够大了,直接灌进去就行。真用起来才知道不是那么回事。一份 PRD 加上附录、变更记录,我数过 token,差不多 31 万,光这一项就超窗口。就算用能吃下的模型勉强塞进去,还有个更隐蔽的问题——注意力被摊薄。学界管这叫 "lost in the middle",大意是模型对一长串内容里靠中间位置的信息,召回率明显比开头结尾低。你问的那条恰好埋在第 230 页中段,它就容易答得含糊,或者干脆从别处抓个相近的段落糊弄你。我亲眼见过它把"灰度发布的回滚阈值"答成了另一节里"全量发布"的数字,两节隔了一百多页。

第二段,目录索引本质是给检索降维,把"读完一本书"变成"翻到那一页"。

这就是为什么要先建目录。建目录索引干的事,是先让 AB 把整篇文档的章节结构、每节标题、大致讲什么抽出来,形成一个轻量的"地图"。地图很小,几 KB,常驻在上下文里不占地方。等你抛出一个问题,它先在地图上定位:这问的是第几章哪一节?锁定章节,再只把那一两节的正文调进来回答。检索的搜索空间一下从"40 万 token 全文"塌缩成"目录 + 命中的那几节",信噪比天差地别。底层其实就是 RAG 的思路,只不过粒度卡在了"章节"这个对人类最自然的单位上,而不是机械地按固定字数切块——按字数切常常把一个完整论述从中间劈开,目录粒度能保住语义的完整。

第三段,先定位再检索,等于给模型套了一层"作用域",顺带能溯源。

还有个好处是约束。当模型被告知"只准在第 7 章里找答案",它瞎编、跨节串味的概率会小很多——作用域窄了,可发挥的空间也窄了。而且答完它能告诉你"这结论出自 3.2 节",我反查原文一对,对得上。这种可溯源性,在文档动辄上百页的时候特别值钱,不然你拿到一个答案根本没法验。

落到我的实操,大致是这么个流程:

具体搭的时候,我没自己写编排,用了个零代码就能配智能体的工具,拖几下把"建目录—问答—引用章节"的链路接起来,逻辑都是配出来的,没敲代码。说实话第一版做出来挺干的,目录抽得太粗,二级标题全丢了,问细节照样定位不准,我回去把摘要那步的提示词改细、让它连小节一起抽,才像样。还有个小毛病得提:每次问答它都要先过一遍目录定位,响应比直接问慢个两三秒,急性子可能受不了。但比起答错,我认这点延迟。

这事儿给我的感受是,长文档问答的胜负手压根不在模型多聪明,在你喂进去的东西干不干净。先建目录这一步看着多余,实则是把检索从"大海捞针"改成了"按图索骥"。你们处理超长文档时,是直接全塞,还是也做过类似的分层?评论区聊聊,我挺好奇大家切块的粒度卡在哪。

(模型/API 我走的讯飞星辰 MaaS,现成调,没自己部署算力。)