AI 应用的上下文窗口管理
date
May 5, 2025
slug
llm-context-window-management
status
Published
summary
探索大型语言模型(LLM)的上下文窗口局限性及解决方案，详解全上下文 vs 检索增强生成(RAG)的权衡，分析 OpenAI Deep Research 等产品的混合策略实现，设计更智能、响应更快的AI产品，有效平衡准确性与计算成本。
tags
产品设计
LLMs
AI
Context
上下文
type
Post
上下文窗口的本质及其局限性
大模型的记忆机制
想象一下，你正在和一个记忆力有限的朋友聊天，当你们的对话持续几个小时后，这位朋友只能记得最近说的几句话和最开始的几句话，而中间讨论的大量内容则被模糊甚至遗忘了。
这就是当今大型语言模型的工作方式，而最开始的几句话通常是 System Instruction，最近说的几句话就是你新发给大模型的内容。
所谓"上下文窗口"，本质上就是 LLMs 能够"记住"并处理的文本量，通常以"令牌" (token) 为单位计量。对英文来说，一个 token 大约是 4 个字符或 1 个单词；对中文则大约是一个汉字。这个窗口就像模型的短期工作记忆，决定了它在任何时刻能回顾和利用多少之前的信息。
上下文窗口大战
近年来，各大模型提供商不断在"上下文窗口大小"上打广告战，从 GPT-4 的 128K，Claude 3 的200K，到谷歌 Gemini 号称的 1M 甚至 10M。
这里也存在一个公开的秘密：标称的上下文长度与模型能有效利用的上下文之间存在显著差距。
Perplexity
在之前很长一段时间 Perplexity 曾被认为是确定长度外推上限的主要指标，但后续的研究发现困惑度并不能真正反映大型语言模型在长上下文下游任务中的实际表现，下游任务可能包括问答（QA）、摘要（Summ.）、信息检索（Retrieval）等，一个模型可能在困惑度上表现良好=能较好地预测长文本中的下一个词，但这并不意味着它能有效地理解长文本中的关键信息，回答复杂问题，或者生成高质量的长篇文本摘要。
简单来说应该说，预测下一个词做得好 ≠ 真正理解长文本，在实际应用中，模型可能擅长接着写，但在回答问题、提取关键信息或总结长文本时表现不佳。这就像是背诵和理解的区别，一个人可以很好地背诵课文（预测下一个词），但不一定真正理解课文内容（回答问题、做摘要啥的）。
Lost in the Middle
原则上，大型语言模型在理论上具有全局注意力可以利用整个对话历史或文档上下文而不会遗忘。然而，在实际应用中，LLM 表现出强烈的位置偏置，偏向于输入中的某些部分而忽视其他部分。
实证研究表明，LLM 有时对最近的 token 和有时对上下文的起始部分关注较多，而对中间部分关注较少，这也被叫做首因效应 (primacy bias) 和近因效应 (recency bias) 。
其中提到了一条 U 型性能曲线：当相关信息位于长输入的开头或结尾时，模型回答效果最佳，但如果所需信息被埋在中间，性能则大幅下降
而后来也有 ∞
Bench: Extending Long Context Evaluation Beyond 100K Tokens 说并没有发现答案位于上下文中心位置时 LLMs 的准确度会下降：
当然，这篇论文的结论仍然是认为 “尽管当前 LLMs 声称擅长处理如此广泛的上下文，但在实际应用中，它们表现出显著的性能下降”
Fiction.LiveBench
另外也还有 Fiction.LiveBench，这个会更加有名一些，这主要是他们有一套内部的评估机制，同时还会及时测试最新的模型。
简单来说，Fiction.liveBench 就像是一个专门测试AI阅读理解能力的考试，特别关注AI是否能真正理解长篇故事的内容，记住所有重要角色和事件，并能回答需要深度思考的问题。而目前在他们的测试中也只有 OpenAI o3 做到了大部分上下文窗口下能达到 100 分。
上下文管理的方法
在现实应用中，当 AI 助手"忘记"用户之前提到的关键需求或限制条件时，用户体验和信任度会大幅降低。
例如，一个客服聊天机器人在长对话中忘记了用户明确表示的关键信息，或者一个法律文档分析工具遗漏了合同中间的关键条款，都可能导致非常不好的用户体验问题。
在上下文管理的产品设计方法论中，有两个最重要的方向：全上下文 (Full Context) 和 RAG (即检索增强)。
全上下文方法相对直接：将所有历史内容都塞进模型的上下文窗口中，让模型自行判断哪些信息重要。
这就像给一个学生完整的教科书，而不是精简的笔记。这种方法的好处是不会丢失任何潜在相关的信息，理论上可以获得最佳答案质量。
然而，它的代价也很明显：处理时间长、API 调用成本高，而且当对话历史超出上下文窗口时就完全失效了。
而 RAG 则像是给学生提供有针对性的笔记和参考资料，而非整本教科书；按照我个人的定义，RAG 主要是用各种方式找到相对较短但最相关的内容，只有这些内容才会塞进模型的上下文窗口中——检索合适的内容和使用尽可能少地上下文。
它有多种实现形式：文本分块会将长文本切成小段，每次只检索最相关的片段；摘要化会压缩大量信息为精炼摘要；滑动窗口则保留最近的一部分内容，扔掉更早的部分；还有重排序技术，调整文本在上下文中的位置，将重要内容放在不易被"遗忘"的位置。
实际应用中，RAG 并非单一技术，而是一系列方法的总称，不同 RAG 方案的效果可能天差地别。例如，简单地保留最近 n 条消息的方法，与智能提取关键事实并整合为结构化记忆的方法，在效果上会有显著差异。
这两种方法各有适用场景：全上下文适合对准确性要求极高且对话长度有限的情况；而 RAG 方法则更适合需要处理超长对话或对响应速度和成本敏感的场景。
在实际产品设计中，选择哪种方法不是非此即彼的决定，而是需要基于具体需求的权衡。
Mem0 的研究案例
2025 年 4 月，Mem0 发布了Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory对比了全上下文方法与他们提出的记忆管理系统。
它们创建了一个动态提取、整合和检索对话中重要信息的系统。简单来说，这个系统会在你和 AI 聊天时，自动提取重要的事实和信息（比如你提到的偏好、经历等），将这些信息存储起来，并在需要时检索相关信息：
- 先看看背景：
- 看看最近的十条消息（"刚才说到哪里了？"）
- 回顾最近十条消息之前的聊天摘要（它不记忆一定数量内的消息，只会存储摘要）
- 然后再提取重点：
AI 会思考："在这段新对话中，有什么值得记住的信息？"比如你说"我喜欢意大利菜，但对奶制品过敏"，AI 会把这两点作为重要信息提取出来
- 最后再整理笔记（记忆）：
- 检查是否与已有笔记冲突（如果你之前说过喜欢奶酪，现在说对奶制品过敏，系统会更新这个信息）
- 决定是添加新笔记、更新旧笔记还是删除错误信息
他们的结果表面，准确性方面，全上下文方法略胜一筹，达到了约 73% 的 LLM-as-a-Judge 评分，而 Mem0 系统则达到约 67-68%。
当然这并不代表 Mem0 的 RAG 没有用，它最大的优点是响应时间和成本，响应时间减少了85-91%，token 消耗也大幅降低。
更有趣的是，在不同类型的问题上，这两种方法的表现差异各不相同。对于需要时间推理的问题（例如"上个月我们讨论的那个项目现在进展如何？"），Mem0 的图结构增强版本甚至超过了全上下文方法。
不过上述 Mem0 论文中使用的模型只是 GPT 4o mini，而新发的 GPT 4.1 mini 根据 OpenAI 自己的文章，在长上下文的评估中均全面超越了大部分过往的模型。
但是我觉得这项研究也带来了一些启示：没有一种万能的上下文管理方法。选择全上下文还是基于 RAG 理念的各种系统，都应该基于具体的应用场景、用户需求和资源限制。
在某些对准确性要求极高的场景，牺牲一些速度和成本换取最高准确率可能是合理的（全上下文）；而在大规模部署、用户对响应速度敏感或资源有限的情况下，选择基于 RAG 理念的各种系统（比如说 Mem0 这样的记忆系统）可能是更明智的决定。
面向用户决策的上下文管理策略
上面的论文们为我们提供了一定的“事实基础”，但具体到产品决策，还需要更细致的策略。实际上，上下文管理策略的选择应该基于多维度的考量，而非简单的二选一。
对于面向专业用户的高风险领域产品，如法律文档分析、医疗诊断辅助或金融建议，准确性通常是首要考量。在这些场景中，即使付出较高的计算成本和稍长的响应时间，全上下文方法可能仍是更佳选择，同时还可以结合基于 RAG 和 Multi Agent 的重复检查。毕竟，在这些领域，一个错误的建议或遗漏的关键信息都可能导致严重的后果。
相反，对于面向 C 端用户的产品、需要处理大量并发请求的应用、移动端应用或对成本特别敏感的场景，RAG 一类的方法的优势则更为突出。想象一个客服聊天机器人需要同时服务数千用户，响应速度和计算成本可能会比极致的准确性更重要（当然这里存在一条可用性的门槛，必须要迈过那条可用性的门槛才能进一步考虑速度和计算成本）。
实际产品中，混合策略往往是最实用的。例如，在初始阶段采用全上下文以快速响应，随着对话深入、复杂度增加和上下文的累计，可以考虑转向轻量级 RAG，但是对于特别看中效果的一些关键功能，可以启用全上下文模式以确保最高准确性。
以 Deep Research 举例，想象一下你在用 Deep Research 在执行一个复杂的市场研究任务时的工作方式。它不应该是简单地一次性阅读所有资料，而是像一个专业研究员一样，先制定计划，然后在不同阶段采用不同的信息处理策略：
研究计划与核心导向：过程中肯定要将研究计划、用户的核心需求和已确认的关键事实持续保留在上下文中。这些信息是研究的"北极星"，需要在整个过程中保持清晰可见，以确保研究不偏离方向。这部分采用的是接近全上下文的策略。
细节信息与支持材料：对于大量的次要细节、背景资料和支持证据，则采用 RAG 方法按需检索。而不是始终将所有信息保留在上下文中，这种"用时取、用后放"的方式才能提高效率。
跨会话记忆管理：当研究持续数十分钟甚至更长时间时，对已处理的信息进行智能压缩，提取关键结论并丢弃原始细节，保留精华而非全部。这些压缩后的记忆会在后续会话中重新启用，使研究能够连贯进行。
这种混合方法的巧妙之处在于，它平衡了全局视角与细节探索。核心论点和研究方向始终保持在系统的"意识"中，而海量的细节则被组织成易于检索的形式，在需要时才调用。
对产品设计者而言，理解这种混合策略的价值至关重要。它不仅提高了效率和准确性，还大大降低了计算成本。如果完全依赖全上下文方法，Deep Research 将无法处理超过一定规模的研究任务；而如果完全依赖 RAG，则可能失去研究的连贯性和深度。
通过智能地决定"什么应该始终记住"与"什么可以临时查询"，才能够在有限的计算资源下处理远超其上下文窗口的复杂研究任务，同时保持研究质量和连贯性。
这正是为什么在构建像 Deep Research 这样的复杂 AI 产品时，混合上下文策略不是一种选择，而是一种必然，核心还是对于用户场景的把控，和计算资源、成本和效果的权衡。
评估需求时，可以考虑以下关键问题：
- 用户对响应速度的敏感度如何？
- 准确性对产品有多重要？
- 产品的使用场景是否涉及超长对话或文档？
- 计算资源和成本限制是什么？
- 用户期望是什么？
对这些问题的回答将指引你选择最适合的上下文管理策略。
一些常见的应对上下文限制的技巧
最重要的是任务分解设计，复杂对话任务应被设计成可管理的子任务链，而非单个庞大的任务。每个子任务可以有明确的输入、输出和上下文需求，这样系统就能更有效地管理每个环节所需的上下文。例如，一个旅行规划助手可以将任务分解为目的地选择、住宿搜索、活动安排等子任务，每个子任务专注于自己的上下文需求，而不是试图在单个对话中管理全部信息。Building effective agents 中就有列举不同的工作流设计。
同时在任务执行中，最好做到状态尽量显化，让用户更加明确，在长时间工作流中，关键状态（如用户目标、约束条件、已完成步骤）可以考虑显式记录并在需要时展示给用户确认，而非仅仅依赖 AI 的"记忆"。这不仅可以增强系统的可靠性，还为用户提供了校正错误理解的机会。
最后可以考虑记忆分层管理，一般认为受人类记忆系统启发，可以将 AI 的记忆分为短期记忆和长期记忆短期记忆包含最近的对话内容，直接放入上下文窗口；长期记忆则存储在外部数据库中，包含用户偏好、历史交互中的关键信息等。关键是建立智能的检索机制，在需要时将长期记忆中的相关内容重新唤起到短期记忆中。例如，当用户提到"我们上次讨论的那个项目"时，系统应能快速识别并检索相关的历史信息。
这些技巧不仅有助于解决技术层面的上下文限制问题，还能显著改善用户体验，使 AI 产品在长对话场景下更加可靠和实用。关键是认识到上下文管理不仅是一个技术问题，也是一个产品设计问题，需要从多个维度综合考虑。
尾巴
在设计 AI 产品时，上下文管理应该被视为核心设计考量，而非技术细节。产品应该尽早在规划阶段就思考：
- 我们的场景会产生多长的对话或文档？
- 用户期望AI记住什么信息？
- 准确性与响应速度的权衡对我们的产品有何影响？
全上下文与 RAG 的选择不是非黑即白的。全上下文方法可能提供稍高的准确性，但代价是显著增加的延迟和成本。对大多数产品来说，某种形式的 RAG 是实用的选择，尤其是当产品需要规模化部署或支持长时间交互时。但具体的实现策略需要根据产品的独特需求定制，同时也会显著增加开发成本。
随着技术的快速发展，产品策略需要灵活调整。新的研究和模型正在不断推出，例如 OpenAI最近发布的 GPT-4.1 系列在长上下文处理方面有显著改进。今天的最佳实践可能很快就会过时，因此建立对产品性能的持续监测机制，并保持对最新研究的关注，也是至关重要。
最后，我认为只有更好地理解并应对用户需求和技术限制之间平衡的产品，才能可以构建更智能、更自然、更可靠的产品体验。
随着 AI 技术继续快速发展，我们可以期待上下文管理策略也将不断演进，但无论技术如何变化，以用户为中心的设计思维和对技术限制的深刻理解，将始终是构建 AI 产品的基石。
