上下文窗口是什么？长上下文有哪些问题？

详细解析#

窗口里装了什么#

输入：系统提示 + 工具定义 + 检索资料 + 历史消息 + 本轮问题
输出：模型的回答（推理模型还包括思考过程）
要求：输入 + 输出 ≤ 上下文窗口

• 输入超出窗口时，多数接口直接报错；也有的服务提供自动截掉早期内容的选项
• 很多模型还单独限制最大输出长度，通常比窗口小得多。输出达到上限会被截断，响应里的结束原因会标明是长度限制
• 推理模型的思考过程也算输出 token，同样占窗口、同样计费，见 推理模型
• 多轮对话每轮都要带上历史，越聊越长，需要截断或摘要，见 多轮对话的上下文怎么管理

长上下文的代价#

固定的长前缀（比如系统提示、反复使用的同一份长文档）可以用 Prompt Caching 降低成本和首 token 延迟。

位置效应：lost in the middle#

有研究把关键信息放在长上下文的不同位置测试，发现模型的表现呈 U 形：信息在开头或结尾时效果最好，在中间时明显变差。不同模型的程度不同，新模型有所改善，但"标称支持的长度"不等于"在这个长度上都能用好"。常见的"大海捞针"测试只考查能否找到一句话，比真实任务简单；需要综合多处信息的任务，效果随长度下降得更明显。

实践中的做法：

• 长文档放在前面，指令和问题放在最后，不少厂商的文档也这样建议
• 给每份资料加标签和编号（如 <doc id="3">），方便模型引用和定位
• 只放和任务相关的内容：先检索、筛选、重排，再放进上下文
• 关键约束可以在结尾简短重申一次

长上下文还是 RAG#

两者可以结合：用 RAG 召回更多、更大的片段，再交给长上下文模型。文档放不进窗口时的处理方法见 文档太长放不进上下文怎么处理，RAG 的链路见 RAG 的完整链路。

代码示例#

// 调用前检查预算；countTokens 用对应模型的分词器或厂商的计数接口实现
function checkBudget(messages: Message[], tools: Tool[], limits: { context: number; maxOutput: number }) {
  const input = countTokens(messages) + countTokens(tools)
  // 留一些余量：消息格式、角色标记本身也占 token
  if (input + limits.maxOutput > limits.context * 0.95) {
    throw new Error(`输入约 ${input} token，加上预留的输出会超出上下文窗口`)
  }
}

const res = await llm.chat({ messages, tools, maxTokens: 2000 })
// 结束原因的字段名和取值各家不同，如 finish_reason 为 length、stop_reason 为 max_tokens
if (res.finishReason === 'length') {
  // 输出被截断：提高输出上限、让模型分段输出，或者提示用户内容不完整
}

面试官可能追问#

易错点#

• 窗口包括输出：输入把窗口塞满了，模型就没有空间生成回答
• 多轮对话的成本是每轮输入的累加，不是只算新增的消息
• "支持 X 长度"不代表在这个长度上的效果和短文本一样好
• 输出被截断时要检查结束原因，否则会把半截内容当成完整结果