面经策

当需要处理超长大模型上下文窗口限制时，有哪些可行的工程解决方案？ ​

  • 标签：大模型

🏛 业务架构师 ​

超长上下文的工程方案我按"成本从低到高"排：

  1. 截断与滑动窗口：只保留最近 N 轮+系统提示，最简单。适合对话场景的初级方案，代价是丢失早期信息。
  2. 摘要压缩：用小模型把早期历史滚动摘要成"会话纪要"注入，兼顾记忆与窗口。客服、长对话的主流方案。
  3. 检索式记忆（外置记忆）：历史全量存向量库，按当前问题检索相关片段注入——上下文不够，检索来凑。这是 Agent 长期记忆的标准架构。
  4. 分治处理（Map-Reduce）：长文档切块分别处理再归并结论，适合文档汇总类任务。
  5. 换长窗口模型：2026 年主流模型窗口已到 128K~1M，直接换模型常比工程改造便宜——这是"花钱买省事"的选项，先算 token 成本账。

业务选型逻辑：先问"真的需要全量上下文吗"——多数场景用户要的只是"最近几轮+关键事实"，滑动窗口+关键信息抽取就够；确需超长输入的（合同审阅、代码库理解），优先评估长窗口模型的费用，工程手段做兜底。我的原则：上下文管理是为业务目标服务的，不要为了技术完备性把系统复杂化。

🏗 系统架构师 ​

超长上下文的工程解法我分会话内、跨会话、架构级三层，这是从治标到治本：

会话内（上下文管理）：

  • 滑动窗口 + 摘要压缩（旧对话滚动摘要成"会话记忆卡"）；
  • 结构化裁剪：工具结果、检索片段按相关性打分保留 Top-N，长输出落盘只回填摘要 + 指针；
  • 分层记忆注入（见下）。

跨会话（记忆系统）：

  • 短期：当前会话原文（窗口内）；
  • 中期：会话摘要 + 关键实体，向量化入库；
  • 长期：用户画像、偏好、事实三元组存结构化库，按 query 检索注入——本质是"上下窗口不够，用检索补"，RAG 思想用于记忆。

架构级：

  • 任务分解：把大任务拆给子 Agent（子查询、子文档），父级只聚合结论——MapReduce 模式处理长文档分析；
  • 模型与成本策略：按任务选窗口档位（普通对话 32K、文档分析 128K~1M），长窗口模型按 token 计费贵且 attention 有稀释，能用检索解决的不要硬塞；
  • Prompt Cache：稳定前缀缓存，降低重复长上下文成本。

量级判断：100K token 的 prefill 在无缓存时 2~5 秒级、成本占大头——所以"少塞、会检索、能缓存"是长上下文工程的三字诀。

💻 全栈开发专家 ​

超长上下文的工程解法，按「不动架构 → 动架构」排列：

  1. RAG 化（首选）：长文档切块入向量库，按需检索——不是所有内容都要同时在场。成本最低、可溯源。
  2. Map-Reduce 摘要：分段各自摘要（map），再汇总摘要（reduce），分层递归可以处理任意长度。代价是丢失细节，适合「只要结论」的任务：
python
from langchain.chains.summarize import load_summarize_chain
chain = load_summarize_chain(llm, chain_type="map_reduce")
  1. 滑动窗口 + 滚动摘要：对话场景保留最近 K 轮原文，历史压缩成摘要常驻；工具结果落盘只留引用。
  2. 上下文压缩：检索内容用 Extractive compressor 抽相关句、LLMLingua token 级压缩。
  3. 分层记忆外置：会话状态存库（LangGraph checkpointer / Store），需要时再取，等于把上下文变成缓存。
  4. 直接上长窗模型：Gemini/Qwen 等已有 1M token 窗口，但贵、慢、且「lost in the middle」——中段信息利用率显著下降，长窗不等于全读。

我的决策顺序：先问「真的需要全量上下文吗」——90% 场景 RAG 就够；确需全局理解（整本书问答、大规模代码重构）再上 map-reduce 或长窗模型，并配合「先摘要定位、再原文细读」的两阶段策略。