什么是上下文窗口？每位 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 个单词。但这只是估算。例如短语“Context windows affect application performance.”，分词器不一定会将其表示为 5 个完整单词；具体取决于分词器，一个或多个单词可能被拆成多个子词 token。

不同语言的分词结果也可能差异很大。含义和可见长度相近的两句话，因语言和分词器不同，消耗的 token 数可能相差甚远。关于分词器公平性的研究发现，即使分词器支持多语言，等价文本在某些语言对中的 token 化长度差异也可高达 15 倍。构建多语言应用时，开发者应使用目标模型实际采用的分词器测量 token 用量，而非根据词数估算。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

小型上下文窗口迫使开发者有所取舍：长文档需要分块，较早的对话历史需要摘要，外部知识只在实际需要时检索。

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

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

模型为何会在中间迷失

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

这意味着模型在技术上可以接收一份文档，却不一定能可靠地使用其中的每一部分。假设向 LLM 发送 100 份支持文档，因为其中一份包含客户问题的答案；更大的上下文窗口可能让这 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 和文本转语音，开发者则可配置提示词、知识库、工具、工作流和底层语言模型。富有表现力的表达方式，包括智能体如何传达语音中的情感上下文，同样依赖于决定智能体说什么的上下文。

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

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

上下文窗口常见问题