AI Engineering Academy · 课时

上下文窗口：大小与影响

了解什么是上下文窗口、它如何限制对话长度和文档处理，并比较 GPT-4o、Claude 和 Gemini 的上下文大小。

上下文窗口：大小与影响 是 CoddyKit 上的免费 AI Engineering Academy 课时。这是第 2 节课，共 4 节。你可以在下方免费阅读本课时的完整内容 — 然后在浏览器中使用内置代码编辑器和全天候 AI 导师进行实践。这是 AI Engineering Academy 学习路径的一部分，你的进度在网页和 CoddyKit 应用中同步。 AI Engineering Academy 课程共包含 4 节课。

什么是上下文窗口？

上下文窗口是 LLM 在一次 API 调用中能够处理的最大令牌数量。它包括所有内容：系统提示词、之前对话中的所有轮次、您为 RAG 注入的任何文档，以及为模型响应预留的空间。如果总量超过上下文窗口，API 就会返回错误。

您可以把上下文窗口理解为模型的工作记忆。人类能够记住跨会话的过往对话，而 LLM 没有持久记忆——它只能“知道”当前上下文窗口中存在的内容。当对话超过窗口容量时，最早的内容必须被移除，这可能导致模型无法继续掌握之前的重要上下文。

2025 年的上下文窗口大小

上下文窗口的容量增长得非常快。2020 年，GPT-3 提供 4,096 个令牌。到 2025 年，领先的模型可提供：

GPT-4o 和 GPT-4o-mini：128,000 个令牌（约 100,000 个单词）
Claude 3.5 Sonnet / Opus：200,000 个令牌
Gemini 1.5 Pro：1,000,000 个令牌（一百万）
Gemini 1.5 Flash：1,000,000 个令牌

128K 的上下文窗口大约可以容纳 300 页文本、一本完整的小说，或一个中等规模的完整代码库。尽管如此，无限上下文仍不是一个已经解决的问题：注意力成本会随序列长度呈二次增长，使得非常长的上下文成本高昂，有时准确性还不如更短、更聚焦的上下文。

中间内容丢失问题

研究发现，LLM 不会平等地关注上下文窗口的各个部分。它们往往最关注上下文的最开头（首因效应）和最末尾（近因效应），而对中间内容的处理可靠性较低。

这被称为中间内容丢失问题。它对 RAG 系统有实际影响：如果您拼接 10 份检索到的文档，而最相关的文档恰好位于中间，模型可能无法有效使用它。最佳做法是将最重要的上下文放在注入文档的开头或末尾，而不是中间。

上下文与对话：一个实际示例

在聊天应用中，每次 API 调用都会包含完整的对话历史。随着对话增长，令牌数量也会增加。假设一段对话有 50 条消息，每条平均 100 个令牌，那么仅对话历史就已经占用 5,000 个令牌。再加上 2,000 个令牌的系统提示词和 10,000 个令牌的 RAG 上下文，在用户提出下一个问题之前，您就已经使用了 17,000 个令牌。

import tiktoken

def estimate_conversation_tokens(messages, model='gpt-4o'):
    enc = tiktoken.encoding_for_model(model)
    total = 3  # priming
    for msg in messages:
        total += 4  # per-message overhead
        total += len(enc.encode(msg.get('content', '')))
    return total

# Simulate a growing conversation
conversation = [
    {'role': 'system', 'content': 'You are a helpful coding assistant. ' * 20},  # ~100 tokens
]

for i in range(1, 21):
    conversation.append({'role': 'user', 'content': f'Question {i}: How do I implement feature X?'})
    conversation.append({'role': 'assistant', 'content': 'Here is how to implement that feature...' * 5})
    if i % 5 == 0:
        tokens = estimate_conversation_tokens(conversation)
        print(f'After {i} exchanges: {tokens} tokens')

有效上下文与最大上下文

拥有较大的上下文窗口，并不意味着您应该把它完全填满。研究一再表明，随着上下文逐渐填满，模型准确性会下降，尤其是在需要从长上下文中精确检索特定事实的任务中。一个聚焦且相关的 5,000 令牌上下文，往往比一个缺乏重点的 50,000 令牌上下文生成更好的回答。

这正是使用 RAG 而不是简单地把所有文档全部塞入上下文的核心理由：RAG 系统只检索最相关的 2～5 个片段，使上下文保持聚焦，并让模型的注意力集中在重要内容上。您可以把它理解为：为了回答一个问题，查询书籍的索引，而不是把整本书都读一遍。

对文档处理的影响

长上下文窗口支持以前无法实现的强大文档处理流程。现在，您可以将一份完整的 50 页 PDF 发送给 GPT-4o 并就其提问，让模型同时总结并交叉引用多份合同，或分析整个代码库中的模式和反模式。

但是，按照每百万输入令牌约 0.15 美元计算，每次查询处理一份 100,000 个令牌的文档，成本约为每次 0.015 美元。如果每天对一份很少变化的文档发起 10,000 次查询，那么您每天要为重复处理支付 150 美元。这就是为什么在生产环境的文档分析系统中，缓存和预处理策略极其重要。

上下文窗口与最大令牌数的关系

API 中的 max_tokens 参数限制的是输出长度，而不是整个上下文的长度。上下文总长度等于输入令牌数加输出令牌数。如果您的上下文窗口为 128,000 个令牌，而输入已经使用了 120,000 个令牌，那么无论您为 max_tokens 设置什么值，响应最多只剩 8,000 个令牌的空间。

请始终为输出预留足够的预算。对于对话助手，通常为输出预留 2,000～4,000 个令牌就足够了。对于代码生成或长篇内容，您可能需要 8,000～16,000 个令牌。请将令牌预算计算纳入您的上下文组装逻辑。

import tiktoken

def check_context_budget(
    messages,
    model='gpt-4o',
    max_context=128000,
    min_output_tokens=2000
):
    enc = tiktoken.encoding_for_model(model)
    input_tokens = sum(
        len(enc.encode(m.get('content', ''))) + 4
        for m in messages
    ) + 3

    available_output = max_context - input_tokens
    if available_output < min_output_tokens:
        raise ValueError(
            f'Not enough output budget: only {available_output} tokens '
            f'remaining, need at least {min_output_tokens}.'
        )
    return input_tokens, available_output

根据上下文需求选择模型

上下文窗口大小应当是您选择模型时的关键标准之一。请根据实际使用场景匹配模型的上下文窗口：

会话较短的聊天助手：8K～16K 通常足够；使用 gpt-4o-mini 可提高成本效率
针对中等文档的文档问答：32K～128K；gpt-4o 能很好地平衡质量与成本
包含数百页内容的法律或合同分析：128K～200K；可以考虑 Claude，它的长上下文性能出色
完整代码库或书籍分析：500K～1M；目前 Gemini 1.5 Pro 处于领先地位

如果您只需要 8K，却为 1M 令牌的上下文窗口付费，那就是昂贵的过度配置。请根据实际上下文需求选择合适规模的模型。

通过上下文缓存降低成本

当您在许多请求中反复查询同一份大型文档或系统提示词时，每次都要为相同内容进行令牌化和处理而付费。OpenAI 的提示词缓存会在相同的提示词前缀超过 1,024 个令牌时，自动将重复前缀的输入令牌价格折扣 50%。

为了最大限度地提高缓存命中率，请安排消息结构，使稳定内容位于最前面：先放系统提示词，然后放大型文档或上下文，最后放变化的用户问题。这样，较长的稳定前缀就会被缓存，而每次请求只需按全价处理较短的变化查询。

何时扩展，何时总结

面对不断增长的对话或大型文档，较大的上下文窗口为您提供了两种处理策略：扩展（将所有内容保留在上下文中）或总结（压缩旧内容以节省令牌）。正确的选择取决于您的使用场景。

在以下情况下选择扩展：您需要引用对话早期的具体事实；您正在分析一份需要引用特定章节的文档；或者总结会丢失关键细节。在以下情况下选择总结：早期对话的总体主题比具体措辞更重要；您即将达到上下文限制；或者同一上下文会被多次重复使用（这样总结只需支付一次成本）。

在生产环境中监控上下文长度

在生产环境中，请将每个请求的上下文长度作为关键指标进行跟踪。平均上下文长度突然上升，可能意味着上下文组装代码存在错误、用户粘贴了过长的输入，或者出现了反馈循环，即模型的长响应被重新送回上下文。当上下文长度超过模型最大容量的 80% 时，请设置警报。

还要跟踪截断事件——也就是您必须缩减上下文才能将其限制在窗口范围内的情况。频繁截断意味着您需要更好的上下文管理策略、更大上下文的模型，或采用基于 RAG 的方法来只检索相关内容，而不是发送全部内容。

快速检查

请测试您对本课 AI 工程概念的理解。

课程回顾

在本课中，您学到了：上下文窗口是一次 API 调用中输入与输出所共用的令牌总预算；中间内容丢失问题意味着上下文开头和末尾的内容处理得更可靠；以及聚焦的小型上下文通常优于庞大而缺乏重点的上下文，因此使用 RAG 比把所有文档都塞入上下文更合适。接下来，我们将学习如何在发送请求前计算和预测 API 成本。

常见问题解答

「上下文窗口：大小与影响」课时是免费的吗？

是的 — 「上下文窗口：大小与影响」的完整文本可在网页上免费阅读。要进行交互式练习（内置代码编辑器和全天候 AI 导师）并解锁 AI Engineering Academy 课程的其余内容，请升级到 CoddyKit PRO。 AI Engineering Academy 课程共包含 4 节课。

「上下文窗口：大小与影响」这节课中我会学到什么？

了解什么是上下文窗口、它如何限制对话长度和文档处理，并比较 GPT-4o、Claude 和 Gemini 的上下文大小。你通过在浏览器中直接运行的动手代码来练习 AI Engineering Academy，全天候 AI 导师会在你学习这节课的过程中回答你的问题。

学习 AI Engineering Academy 需要有经验吗？

无需任何先前经验。CoddyKit 上的 AI Engineering Academy 课程适合初学者到高级学习者，你可以从这里开始或从头开始，按照自己的节奏学习。这是第 2 节课，共 4 节。

「上下文窗口：大小与影响」课时需要多长时间？

大多数 CoddyKit 课程大约需要 5–10 分钟。每节课都很精短且互动，所以你能稳步进步，并在网页和应用中从离开的地方继续。

我能在这节 AI Engineering Academy 课中编写并运行代码吗？

能。每节 AI Engineering Academy 课都包含内置代码编辑器，你可以在浏览器中直接编写并运行真实代码，并获得即时 AI 反馈 — 无需本地设置。

此课程中的所有课时

← 返回 AI Engineering Academy