高频面试题

什么是上下文窗口 Context Window？它有什么限制？

面试官问上下文窗口，通常不是想听模型支持多少 token，而是想看你能否管理长任务里的信息、噪声和成本。

适合阶段：LLM / Agent 工程核心能力：上下文预算 · 长上下文治理 · 失败模式

面试官角度分析，想考什么

• 上下文窗口是什么？
  考你是否理解它是一次模型调用的可见信息容量。
• 窗口越大是不是越好？
  考成本、延迟、噪声和位置偏置的权衡。
• 上下文满了怎么办？
  考摘要、检索、滑动窗口和结构化 state。
• 它和记忆、RAG 有什么关系？
  考概念边界。

可直接抄走的 30 秒参考答案

上下文窗口就是模型一次调用能看到和生成的 token 上限。它不是无限记忆，里面要放系统提示词、用户输入、历史、工具定义、RAG 资料和输出空间。限制不只是容量，还包括成本、延迟、截断、位置偏置和噪声干扰。生产里要做上下文治理，比如历史摘要、检索召回、结构化 state、工具结果截断和动态工具加载。

面试回答详解，知其所以然

上下文窗口不是“聊天记录长度”，而是模型当前这次推理能访问的全部信息环境。

1. 上下文窗口包含什么

system prompt + 用户输入 + 历史消息 + 工具定义 + RAG 文档 + 中间结果 + 输出空间

对普通问答来说，窗口主要放系统提示词和对话历史；对 Agent 来说，还会放工具 schema、计划、工具结果、错误反馈、状态和证据。

2. 核心限制

• 容量限制：超过窗口会报错或被截断。
• 输出限制：输入太长会挤占输出空间。
• 成本限制：输入 token 越多，费用和延迟通常越高。
• 位置偏置：模型更容易关注开头和结尾，中间信息可能被忽略。
• 噪声干扰：塞入太多无关材料会降低判断质量。
• 污染累积：错误摘要、无关工具结果或注入内容会影响后续轮次。

3. 大窗口不是万能解

大窗口能缓解容量问题，但不能自动解决信息选择问题。把整本文档、全部历史和所有工具都塞进去，模型仍可能找不到关键证据，还会更贵、更慢、更难调试。

4. 常见治理方法

• 滑动窗口：保留最近对话，适合短任务，但可能丢早期约束。
• 滚动摘要：把旧历史压缩成摘要，省 token，但可能失真。
• 检索式上下文：需要时从外部文档或记忆召回相关片段。
• 结构化 state：把目标、约束、决策、证据 id 放到稳定字段里。
• 工具结果蒸馏：长 JSON 和日志只回传关键字段或引用。
• 动态工具加载：只暴露当前任务需要的工具定义。

5. 生产落地边界

上下文管理要可观测：记录每轮装入了哪些资料、哪些被截断、摘要由谁生成、证据来自哪里。否则模型答错时，很难判断是模型推理错、检索错、摘要错还是上下文被污染。

面试官追问3个问题

追问一：长上下文模型能替代 RAG 吗？

• 考察点：是否理解知识选择和成本边界。
• 回答方向：不能完全替代。长窗口可以容纳更多信息，但 RAG 负责从海量资料中选相关证据，并提供来源和更新能力。

追问二：上下文满了你会先删什么？

• 考察点：是否能做优先级判断。
• 回答方向：先删重复、低相关、可重新检索的信息；保留系统规则、当前目标、关键约束、最新用户输入和证据引用。

追问三：prompt caching 能解决上下文窗口问题吗？

• 考察点：是否区分成本优化和容量治理。
• 回答方向：caching 降低重复前缀成本和延迟，但不扩大窗口，也不解决噪声、位置偏置和污染问题。

扩展知识

上下文窗口、记忆和 RAG

• 上下文窗口：模型这一轮实际可见的信息。
• 记忆：外部持久化信息，需要被选择性写入和召回。
• RAG：从外部知识库检索相关证据，再放进上下文。
• 压缩：把已有上下文重新组织，节省窗口空间。