容量与检索是两回事
模型能够接收一大段文本，不代表它在回答时总能准确找到最早的关键句。文件里如果有多个相似日期、重复名称或互相冲突的修订版，漏读和误引的概率会上升。尤其是“总结这 200 页”的任务，流畅的摘要可能掩盖缺失的章节。
用四类问题测长文本
第一类是精确定位：某项条款在第几节。第二类是跨段关联：正文要求和附录例外是否冲突。第三类是顺序判断：最终版本覆盖了哪些旧版本。第四类是信息缺失：文档没有写的内容，模型能否明确说没有。只用一个“藏针”问题测出正确，不足以证明整份文档都能可靠处理。
检索并非万能补丁
把文档切块后做 RAG，可以降低单次输入长度，但切块边界可能把条件和结论拆开。相似度检索也可能把同名但不同年份的段落排到前面。设计时要保留章节标题、页码、版本和相邻片段，并让模型输出可核对的引用。否则从“长上下文漏读”变成“检索错段落”。
预算和隐私也会改变方案
整份文档反复送入云端模型，可能增加费用和数据暴露范围。本地模型加检索能降低传输，但可能在复杂跨段推理上不如更强的云端模型。可把检索、抽取与最终判断拆成几步，记录每一步结果，让人能发现错误来自哪个环节。
长上下文不是宣传页上的数字竞赛。老哥网模型实验室更愿意展示一组可复查问题：从材料中找到证据、在证据之间推理、承认没有证据。只有这三步都稳定，窗口大小才真正转化为使用价值。
给“记住”一个可检验的定义
用户问模型是否记住开头，可能指四件不同的事：能复述某句话、能正确定位页码、能结合后文推断，或能在后续对话里持续使用。测试时应把它们拆开。一个模型通过简单的原句复述，并不证明它能处理跨章节的条件冲突；一次摘要没提到某段，也可能是摘要目标没要求它覆盖。
对重要文件，可以要求输出“结论—证据—页码”三列。找不到证据时留空，避免用常识补全。文档更新后重新建立索引，并保存版本号。这样即使模型答错，也能追到是读取、检索、推理还是引用环节出了问题。
若文档中有表格和扫描页，测试时还要单独检查 OCR 与版面解析。模型在纯文本样本上表现良好，不意味着它能把跨页表格的表头和数值对应正确。输入处理质量往往是长文本系统真正的短板。
这也是为什么重要结论需要人工抽查原文：窗口足够长，只代表材料能进入系统，不代表所有条件都被同等重视。