把一份几十页的产品手册交给 AI大模型，再问一个需要跨三章对照才能回答的问题，比如某个参数在两种工作模式下分别怎么设置。回答通常不会空着，它会给出结构完整、语气笃定的答案，只是其中一半对、一半错。错的那一半，恰恰藏在手册中段某页的一句备注里。
这个场景在工程侧反复出现。上下文窗口从几万 token 扩到几十万，看起来“读完整本手册”已不成问题，但真正卡住人的，往往不是装不装得下。
装得下，和用得上，是两件事
上下文变长，是模型输入容量的变化，不是理解能力按比例放大。一段长文档里信息密度并不均匀：开头有目录和概述，结尾有附录和变更记录，真正的约束条件可能埋在中段一句不起眼的说明里。工程实践里常见的观察是，模型对长输入两端的注意力更集中，中段信息容易被稀释。这不必夸张成“遗忘”，但它确实说明，把资料一股脑推给 AI大模型，不等于它读懂了。
另一个被低估的因素是干扰。手册里同时存在旧版本说明、例外情况、面向不同型号的参数表。人读的时候会自动跳过无关段落，模型却要在一片相似表述里判断哪句适用于当前问题。输入越长，这种判断的负担越重。
整篇输入与先检索，各自付出什么
面对这类需求，工程上有两种常见做法。
- 整篇塞入：把文档全量放进上下文，让模型自己找。省掉预处理，适合一次性问答、文档量不大的场合；代价是成本与延迟随长度上升，噪声也跟着进来。
- 先检索再喂：把文档切块、建索引，按问题召回若干片段再交给模型。片段更干净，可控性好；代价是切分会切断上下文，召回一旦漏掉关键段落，模型再强也补不回来。
两条路各有适用面。文档结构清晰、问题范围明确时，检索路线通常够用；需要通篇把握语气、风格或前后一致性时，整篇输入省去了切块的麻烦。值得先判断的是：这个问题依赖的是某一句话，还是整份材料的脉络。
让它说清楚依据哪一段
比答案对错更值得关注的，是模型能不能说清自己依据了哪一段。要求它回答时标注出处、在材料里找不到时明确说找不到，会明显改变输出形态：从“看起来像答案”变成“可以核对的答案”。这一步做起来不复杂，却常被跳过；加一句提示词让回答显得完整很容易，让它承认信息不足，反而需要产品层面留出余地。
还有一层边界：AI大模型擅长归纳、改写、按格式抽取，不擅长在信息缺失时凭空补出正确结论。当文档本身存在矛盾或版本混杂，模型容易把冲突抹平，给出一段读起来通顺、实际上掩盖了问题的文字。这类输出不容易被当成错误。
评测要贴着自己的问题走
通用评测反映的是平均表现，落到具体业务上参考价值有限。更实际的做法是从自己的文档里挑出几十个真实问题，覆盖单点查找、跨段对照、信息缺失三类，跑一轮看错误集中在哪。错误分布本身就有信息量：若错的多是跨段对照，问题可能出在切块策略；若错在信息缺失时仍然硬答，问题出在提示约束。
把这几件事放在一起看，我的判断是：上下文窗口继续扩大是确定的趋势，但它解决的是“能不能放进去”，不解决“放进去之后能不能用对”。围绕 AI大模型 搭建文档问答，值得先想清楚问题依赖哪一段、依据怎么核对、缺失时怎么退出，再去比较窗口大小。把资料全部倒进去，是省事的一步，也常常是容易让人误判的一步。