有人把三十页的产品说明书贴进对话框，连问三个问题。第一个回答还算靠谱，第二个开始把前面的参数换了个说法，第三个干脆绕开了原文里明确写着的限制条件。文档明明就在那儿，模型却像是读到后面忘了前面。
窗口变长之后，问题换了位置
大语言模型处理文本的方式，是把每个词压成向量，再让这些向量彼此“看”一眼，算清楚谁该关注谁。序列越长，这种两两比对的计算量涨得越快，工程上要靠稀疏化、分块、缓存这些手段把成本压下来。窗口从几千扩到几十万，听着是能力升级，实际是压力转移：信息确实都装进去了，可分配到每一段上的注意力被摊薄了。
这有点像把一份材料摊在一张过大的桌子上。每页都看得见，但没有哪一页被真正拿起来细读。位置也有关系，开头和结尾往往被记得更牢，中间那一段最容易滑过去。
检索和长窗口，不是一道选择题
检索增强的路子是先找出相关段落，再喂给模型；长窗口的路子是全塞进去，让它自己挑。前者省算力，但成败取决于切分是否合理、召回是否准；后者省掉了一整条工程链路，代价是把负担交给了注意力机制本身。
实务中更常见的做法是两者叠着用：先把长材料做结构化处理，拆成带标题的小节，需要精确引用时保留原文片段，需要概括时用摘要。这样既不至于让模型在几万字里漫游，也保留了上下文之间的连贯。
几条具体的写法
- 把关键约束放在最前面，重复一次在末尾，中间放细节。
- 长文档先让它自己列一份结构清单，确认章节对得上，再问具体问题。
- 要求引用时，让它指出原句所在的小节标题，而不是复述大意。
- 一次只推进一个改动，多轮叠加容易让前后约束互相打架。
它不会主动承认自己没看到
遇到没读到的部分，大语言模型很少说“这里我没看到”，更常见的反应是顺着已有上下文补一个听起来合理的答案。语气越流畅，越难分辨。所以判断一段输出能不能用，关键不在于它写得多顺，而在于你能不能把某句话指回原文的某一行。指不回去的，就还只是草稿。
这也是为什么在真实工作流里，模型的位置往往被放在中间：前头有人把材料整理清楚，后头有人核对出处。它省掉的是翻找和起草的时间，省不掉的是对内容负责的那一环。窗口还能继续变长，但这件事大概不会因此改变。