什么是上下文窗口？每位 LLM 用户都该了解的内容

上下文窗口是大型语言模型（LLM）在单次请求中能处理的信息量。它以 token 衡量，可包含提示词、对话历史、系统指令、检索到的文档、工具结果，以及模型生成的回复。

更大的上下文窗口让模型能在单次请求中处理更多信息。例如，排查 bug 的编码智能体可同时参考相关源文件、文档、测试结果和近期代码变更，而不必逐项分析并在请求之间丢失有用上下文。

不过，更大的上下文窗口并不等于完美记忆。更长的提示词需要更多计算、消耗更多 token，也可能让模型更难识别真正重要的细节。长上下文模型研究，包括 Lost in the Middle 研究和 NVIDIA 的 RULER 基准测试，都反复发现，随着上下文变长，模型对可用信息的利用会减少，尤其当相关信息淹没在大量不太有用的内容中时。

本文将介绍上下文窗口的工作原理、衡量方式、填满后会发生什么，以及开发者如何有效管理它。

摘要

• 上下文窗口是 LLM 在单次请求中可使用的 token 总预算，涵盖用户提示词、对话历史、检索内容和输出。
• 更大的上下文窗口支持更长的文档、代码库和对话，但不能保证模型能充分利用其中每一部分。
• 模型从长提示词中间位置检索信息时最不可靠，这一规律已在 Lost in the Middle 研究和 RULER 基准测试中得到验证。
• 有效的上下文管理（检索、摘要、缓存）通常优于单纯增加发送的 token 数量。
• 最佳上下文策略应匹配实际工作负载，而非采用宣传中最大的上下文窗口。

AI 模型中的上下文窗口是什么？

上下文窗口是模型的活动工作区，所有与当前请求相关的信息会先在这里汇集，再由模型生成回复。

以一个 AI 智能体为例：它需要总结一段客户支持对话并建议解决方案。为做好这件事，模型必须处理：

• 系统提示词
• 客户消息
• 对话历史
• 公司政策
• 工具和 API 结果
• 输出内容

无论窗口有多大，所有这些内容都要在同一个上下文窗口内争夺空间。

上下文窗口不包含训练数据。训练会将信息永久编码进模型参数，塑造模型通常“知道”的内容；而上下文窗口只保存为当前任务提供的信息。

这一区别在实际应用中很重要：如果应用需要模型基于特定政策、客户记录或技术文档进行推理，不能仅因为模型曾接受过相似材料训练，就认为它能获取这些信息。通常必须通过提示词直接输入模型的工作上下文，或通过检索、工具系统提供；否则模型会依据通用知识推理，而非眼前的实际文档。

分词与上下文窗口：数据如何处理

LLM 处理文本前，分词器会将文本拆分为称作 token 的更小单位。一个 token 可以表示完整单词、单词的一部分、标点符号或其他短文本片段。

对于英语，一个实用估算是：1 个 token 大约代表 4 个字符，或约四分之三个单词。按此估算，100 个 token 约等于 75 个单词。不过这只是近似值。以“上下文窗口会影响应用性能”为例，分词器不一定会将它表示为 5 个完整单词；具体取决于分词器，一个或多个单词可能被拆成多个子词 token。

不同语言的分词情况也存在显著差异。两句话即使含义相近、视觉长度相似，因语言和分词器不同，消耗的 token 数量也可能大不相同。关于分词器公平性的研究发现，即使使用支持多语言的分词器，等效文本在某些语言对中的 token 长度也可相差多达 15 倍。构建多语言应用时，开发者应使用模型实际采用的分词器测量 token 用量，而不要根据词数估算。

20 万 token 的上下文窗口听起来很大，但持续追加对话历史、检索文档、工具回复和系统指令的应用，可能比预期更快接近这个上限。因此，生产环境中的应用通常会监控 token 用量，并使用摘要、历史裁剪、检索过滤和提示词压缩等方法，将最相关的信息保留在活动上下文中。

语言模型中的上下文窗口如何工作？

上下文窗口通过 Transformer 架构的注意力机制工作：模型在生成回复前，会计算输入中每个 token 与其他所有 token 的关系。

以这句话为例：“客户退回了笔记本电脑，因为它无法充电。”要正确理解这句话，模型必须弄清客户、笔记本电脑、退回和充电之间的关系。序列越长，这类关系的数量增长越快。

在标准自注意力机制中，所需计算量大致会随序列长度的平方增长。例如，1 万 token 的提示词需要约 1 亿次成对比较，而 10 万 token 的提示词需要约 100 亿次。现代模型会通过多种架构和基础设施优化来降低实际成本，但底层的扩展问题并未消失。

长对话还会带来第二项限制：键值缓存，即 KV cache。生成过程中，模型会保留先前 token 的中间表示，而不是为每个新 token 重新计算，这能显著加快推理速度。但缓存本身会占用内存，并会随着序列变长而增大。

AI 模型的最大上下文长度及其重要性

模型的最大上下文长度决定了它在单次请求中可接收和处理的信息量。不过，模型能否有效利用大上下文窗口是另一个问题。

更长的上下文窗口支持了早期 LLM 难以实现或并不实用的用例。开发者可向模型提供完整代码仓库、长篇法律文档、研究论文、会议记录或大量对话历史，而无需先将材料缩减到几千个 token。

这很重要，因为保留更多原始上下文可提高模型准确回答问题、识别远距离信息之间关系，以及完成依赖整篇文档的任务的能力。例如，编码助手可能需要查看多个文件，才能理解函数如何被调用；法律文档助手则可能需要比较某一节的定义与文档后面很远处描述的义务。

不过，更大的上下文窗口不会自动带来更好的结果。超长输入可能增加成本和延迟，模型也可能较少关注埋在大量上下文中间的信息。因此，开发者应有选择地加入相关信息，清晰组织长输入，并在适当情况下使用检索、摘要和上下文裁剪等技术。

按模型比较上下文窗口大小

当前主要模型系列的上下文窗口差异很大，从几十万个 token 到 1,000 万个 token 不等。以下是当前旗舰模型的对比：

提供商不断发布新模型并提高上限，宣传的限制变化很快，因此应将此类表格视为快照，而非永久排名。上下文大小也只是选择模型时的一个因素，无法单独说明推理质量、输出限制、延迟或成本。

小型与大型上下文窗口的影响

小型上下文窗口迫使开发者进行取舍。长文档会被分块，较早的对话历史会被总结，外部知识也只会在实际需要时才检索。

大型上下文窗口消除了部分限制。无需先拆分所有内容，就能提供更多示例、保留更多对话历史，或分析更大规模的文档集。

但更大的窗口会带来另一种问题：注意力稀释。当提示词包含大量信息时，模型可能难以识别与当前请求最相关的细节。重要指令或证据可能埋没在相关性较低的内容中，增加回复不完整、不一致或不够精确的风险。

模型为何会在中间“迷失”

当信息位于长提示词的开头或结尾附近时，模型往往最容易检索到；埋在中间时则效果最差。颇具影响力的 Lost in the Middle研究通过将问题答案放在长提示词的不同位置，并测量模型找到答案的频率，直接验证了这一点。结果显示，上下文开头和结尾的准确率始终最高，中间最低。

这意味着模型在技术上可以接收一份文档，但未必能可靠地利用其中每一部分。若因为 100 份支持文档中有 1 份包含客户问题的答案，就将它们全部发送给 LLM，更大的上下文窗口或许能容纳全部 100 份文档。但模型仍需从 99 份无关文档中找出那段相关内容，更长的窗口并不能保证它能做到。

因此，值得区分模型宣传的上下文窗口与其在特定工作负载下的有效上下文窗口。诸如RULER 和 LongBench等基准测试试图衡量这一差距。RULER 发现，即便模型在简单检索测试中接近满分，随着上下文长度和任务复杂度增加，性能仍会下降。LongBench 评估的任务范围更广，包括文档问答、多文档推理、摘要、少样本学习和代码补全。

长上下文仍有实际价值。容量和理解能力只是不同属性，为特定任务选择模型时，两者都很重要。

管理上下文限制：开发者最佳实践

良好的上下文管理意味着控制哪些信息会到达模型：在相关时提供与任务相关的信息，而不是试图在每次请求中最大化 token 数量。以下实践可帮助开发者减少不必要的上下文、提升回复质量，并控制成本和延迟。

1. 检索相关信息，而非加载全部内容

检索增强生成（RAG）让应用可以搜索外部知识库，并仅将相关段落插入模型上下文。无需在每个支持请求中加入整本 500 页手册，应用只需检索与客户实际问题最接近的几段内容。

这样可减少 token 用量，并让模型更清楚哪些内容最重要。检索质量同样关键：生产级 RAG 系统通常会通过谨慎切分文档、检索多个候选段落、对候选结果重排序，以及在构建最终提示词前过滤无关内容来改善结果。例如，ElevenLabs重建了 RAG 管道，加入查询改写和并行模型调用，将检索延迟中位数降低了一半。

2. 有意识地管理对话历史

对话应用会快速累积上下文。无限期附加所有历史消息会浪费 token，并可能将无关细节带入后续轮次。

应用可通过保留最近几轮对话、总结较早交流、将持久事实提取为结构化记忆，以及仅在较早细节再次相关时再检索它们来解决这一问题。这在模型立即需要的短期对话上下文与可在后续调回的长期应用记忆之间，形成了有用的划分。

3. 上下文重复时使用缓存

许多应用会重复发送相同的大段指令，或回答与此前处理过的问题在语义上相似的问题。缓存可减少这类开销。

提示词或上下文缓存可更高效地复用重复输入，而语义缓存则更进一步：它能识别新问题是否与系统已回答的问题大致相同。“退货政策是什么？”和“我有多长时间可以退货？”虽然是不同字符串，但语义缓存可将它们视为同一个问题，从而跳过完整生成调用，同时降低延迟和 token 成本。

4. 在真实上下文长度下衡量性能

不要只根据模型提供商宣传的 token 上限来选择上下文策略。应测试有代表性的生产工作负载，并随着上下文长度增加，衡量回复质量、检索准确率、延迟、token 用量、成本和失败率。

比较不同策略，例如提供更多上下文、检索更少段落、总结对话历史，或结合检索与摘要。拥有 100 万 token 上下文窗口的模型在技术上可能支持你的应用，但更小且经过精心检索的提示词，可能以更低成本带来更快、更准确的结果。

使用 ElevenAgents 构建可扩展的语言解决方案

上下文管理对对话式智能体尤为重要：它们必须结合当前话语、之前轮次、业务指令、客户信息、知识库内容和工具结果，同时还要足够快地回复，让对话保持自然。

ElevenAgents将这些组件整合到一个平台中，用于构建和部署AI 语音智能体。其编排引擎可协调语音识别、LLM 和文本转语音，开发者则可配置提示词、知识库、工具、workflow 和底层语言模型。富有表现力的传达方式，包括智能体如何表达语音中的情感上下文，同样依赖于最初决定智能体说什么的上下文。

在知识管理方面，ElevenAgents 同时支持完整上下文文档和RAG，并可直接在平台上配置。小型文档会直接放入智能体提示词，因此其内容在整个对话中持续可用。大型知识库则会被建立索引，由 RAG 为每个查询检索相关段落，而不是一次性将所有内容加载到上下文窗口中。

立即注册 ElevenAgents，或联系我们的团队，了解部署选项。

上下文窗口常见问题