考察点
这道题表面问「窗口不够怎么办」，实际考察你对长上下文问题的整体判断力：知不知道「塞进窗口」和「用好窗口」是两回事（lost in the middle），能不能按业务场景（单文档问答/多文档汇总/多轮对话/代码库理解）给出不同方案，以及成本意识——128K token 塞满一次的推理成本是多少。追问常往 RAG vs 长上下文的取舍、上下文压缩、位置外推原理上走。
参考答案
先判断：是真不够，还是用得不对
动手之前先量化需求：业务输入的典型长度分布是什么？如果只是少量 case 超窗口，截断策略就够了；如果主体流量都在百万 token 级（代码库、长合同、财报合集），才需要架构级方案。另外要记住「窗口能装下 ≠ 模型能看好」：实测里模型对长上下文中间部分的信息利用率明显下降（lost in the middle 现象），关键信息放在开头或结尾效果最好，这决定了塞内容时的排布策略。
方案谱系，按侵入性从低到高
1. 截断与选择（成本最低）。对超长输入做有损裁剪：对话系统保留最近 N 轮 + 最早 system prompt；文档问答只保留相关性高的段落。配合「关键信息放首尾」的排布原则，往往 80% 的问题在这一层就解决了。
2. 摘要压缩（多轮对话标配）。对话历史超过阈值后，把早期轮次让模型压缩成摘要，后续请求带「摘要 + 最近 K 轮」。LangChain 的 ConversationSummaryMemory 就是这个思路。进阶做法是分层摘要：对话滚雪球式地逐级压缩。代价是摘要丢细节，涉及「用户三轮前提过的具体数字」这类问题会翻车，关键事实要结构化抽取（用户偏好、订单号）单独存，不依赖摘要。
3. RAG（长文档问答的主流答案）。与其把 500 页文档塞进窗口，不如切块建索引，按需检索 Top-K 相关片段。这是成本、效果、可解释性的综合最优：一次调用只用几千 token，还能给引用来源。代价是跨文档的全局性问题（「这份年报的风险敞口总体如何」）检索切块很难覆盖。
4. 分治处理（MapReduce / Refine）。全局性问题用 MapReduce：每个文档块独立总结，再对中间结果递归合并。Refine 模式是顺序滚动：带着已有答案逐块更新。适合财报分析、合同审阅这类「必须读全文」的场景。代价是调用次数多、延迟高，且合并阶段本身也可能超窗口，需要分层。
5. Agent 化阅读。给模型配检索、翻页、查目录等工具，让它像人一样「查阅」长材料，而不是一次性吞掉。Claude Code 读代码库就是这个范式——模型自主决定读哪部分，多轮迭代。这是当前处理超长输入最有前途的方向，但工程复杂度和 token 消耗都高。
6. 扩窗口本身（模型层）。位置插值、NTK/YaRN 缩放 + 长文本继续训练，把 4K 模型扩到 128K；或者用原生长上下文模型（Gemini 的 1M 级别）。这条路解决「能装下」，但每 token 的推理成本随长度平方/线性增长（注意力 O(n²)、KV cache O(n)），全量塞长文对大多数业务是亏本买卖。
选型决策
实践中是一个决策树：单文档问答、局部信息 → RAG；需要全局理解的中等文档（几十页）→ 直接进长上下文窗口；全局理解 + 超长（上百页以上）→ MapReduce 或 Agent；持续多轮交互 → 摘要 + 结构化记忆。RAG 和长上下文不是对立关系，实际系统是组合用：RAG 粗筛到 50 页，再让长上下文模型精读。
成本上给个量级：塞满一次 128K 窗口，按主流 API 定价是几块到十几块人民币一次调用，而 RAG 方案单次只要几千 token，差两个数量级。高频业务里这个差距直接决定方案可行性。
可能的追问
- RAG 和直接长上下文怎么选？ 看信息密度和全局性：局部事实查询用 RAG，需要通读理解的用长上下文；也看调用频率——高频场景 RAG 的成本优势是决定性的。
- lost in the middle 怎么缓解？ 关键信息放开头或结尾；检索结果按相关性重排（最相关的放两端）；用 rerank 控制送进模型的 chunk 数量，宁缺毋滥。
- 摘要压缩丢了关键细节怎么办？ 摘要之外并行维护一个结构化事实表（实体、数字、承诺事项），每轮更新，回答时一起注入；或保留原文可回查的检索通道。