面试场景题：上下文窗口不够时，你怎么设计系统才像一个做过线上的人
“上下文窗口不够怎么办？”是 AI 系统设计面试里的高频题，但很多候选人只会回答“上 RAG”或“做摘要”。本文从面试官视角拆解这道题真正考察的能力：问题分型、方案比较、系统边界、指标验证与失败回退，并给出一套高分答题结构，帮助候选人把概念答案升级为工程答案。
📷 Photo by Tima Miroshnichenko via Pexels
一、这道题不是在考“你知道哪些技术”，而是在考“你会不会先定义问题”
很多候选人一听到“上下文窗口不够”，就立即开始报方案：
- 上 RAG
- 做摘要
- 换长上下文模型
- 做记忆系统
这些方案本身都没错，但面试官通常不会因为你说出这些名词就给高分。因为真正的系统设计能力，首先体现在：
- 你有没有先界定到底是哪一种“不够”
上下文不够，可能是完全不同的四类问题：
- 知识装不下：需要访问外部事实或大规模文档
- 任务历史太长：需要保留长任务状态和阶段信息
- 实时成本过高：即使能装下，也不值得每次都塞进去
- 上下文被污染：问题不是容量，而是无关信息太多
如果候选人能先把题目拆开，面试官通常会立刻判断：这个人不是在背答案，而是在做系统分析。
二、高分开场方式：先问约束，再给方案
这类题最稳的答法，不是立刻给结论，而是先补齐设计约束。你可以这样开场：
我会先判断这是知识量问题、任务状态问题还是成本问题，因为不同类型需要的方案不同。然后我会根据时延预算、数据更新频率、是否要求证据追溯、以及任务是否跨多轮持续执行，决定优先采用检索、摘要、长上下文还是工作流拆分。
这句话有三个好处：
- 展示你会分型
- 展示你关注约束
- 给后续展开留足空间
面试官通常最怕听到“一上来就固定方案”，因为那说明候选人习惯用模板，不习惯根据现实场景做判断。
三、这道题最常见的四种方案，应该怎么比较
1）RAG：适合解决“外部知识装不下”
当问题主要是：
- 文档太多
- 知识持续更新
- 需要引用证据
RAG 通常是优先选项，因为它本质上解决的是“按需取证”，而不是暴力扩容。
但高分回答不能只说优点，还要说边界：
- 误召回怎么办
- 权限和版本如何处理
- 重排和引用如何做
2）摘要 / 会话分段：适合解决“长任务历史太长”
如果问题核心是长任务状态延续，例如：
- 一个任务跑了几十分钟
- 会话跨多阶段推进
- 用户回来时需要恢复上下文
那么单纯 RAG 未必足够，阶段摘要和会话分段更关键。因为这里需要保留的是任务运行时，而不只是知识片段。
3）长上下文模型：适合解决“近期连续状态很多，且大部分都相关”
如果当前任务需要保留大量近期上下文，且这些上下文大部分都强相关，那么更长窗口可能更合适。
但成熟回答必须补一句：
- 长窗口不是自动更稳，仍然要考虑成本、注意力稀释和噪声污染。
4）工作流拆分 / 外部状态存储：适合解决“不是文本放不下，而是任务状态不该都放在 prompt 里”
很多候选人会漏掉这一层。实际上，真正成熟的系统往往不会试图把所有状态都塞回模型，而会把：
- 阶段状态
- 工具回执
- 审批结果
- 恢复指针
放到外部系统中，由模型按需读取。这是从“上下文管理”走向“状态管理”的关键一步。
四、面试官真正想听的，不是你选了什么，而是你为什么这样选
同一个题目里，技术栈答案可以不同，但高分答案通常都有清楚的取舍依据。例如：
- 如果文档高频更新且要证据引用，我会优先 RAG
- 如果是长任务恢复，我会优先会话分段和阶段总结
- 如果大部分信息都是近期连续状态，我会考虑长上下文模型
- 如果任务跨多工具和审批，我会把关键状态外置，不全靠 prompt 持有
面试官要听到的是这种“条件 -> 方案”的映射，而不是“我喜欢某个方案”。
这也是为什么这道题的核心不是知识面，而是决策逻辑。
五、一个高分回答至少要覆盖的五个模块
1）问题分型
先定义这是知识容量问题、任务状态问题还是成本问题。
2）方案比较
至少比较两到三种方案，而不是只讲一个。
3）系统边界
说清楚什么放在模型上下文里，什么放在外部系统里。
4）失败回退
例如：
- 检索失败怎么办
- 摘要失真怎么办
- 长上下文成本爆炸怎么办
5）指标验证
至少要说：
- 正确率 / 完成率
- 时延 / 成本
- 误召回率 / 返工率
没有指标，这道题就还是停留在概念层。
六、低分回答通常输在哪里
低分回答最常见有三种。
第一种：只会报一个名词
例如：
- “我会用 RAG，因为现在大家都这样做。”
这类回答没有解释场景，也没有说明为什么别的方案不合适。
第二种：把所有方案都说一遍，但没有主次
例如：
- “我会用 RAG、摘要、长上下文、缓存、向量库、记忆系统……”
这听起来很全，但没有决策结构，反而像在背 checklist。
第三种：只说 happy path，不说失败治理
如果候选人不提：
- 误召回
- 摘要漂移
- 费用失控
- 权限和版本错误
面试官通常会判断：做过 demo，没做过生产。
七、一个可直接套用的高分回答模板
你可以按下面结构直接组织口头回答：
- 先确认这类“不够”是知识量问题，还是长任务状态问题
- 如果是外部知识过多且高频更新，我优先 RAG，因为它解决按需取证和可更新性
- 如果是长任务状态延续，我会做会话分段和阶段总结，而不是把全部历史塞给模型
- 如果近期状态高度相关，我才会考虑长上下文模型，但会受成本和时延预算约束
- 对于跨工具任务，我会把关键状态外置到系统中，模型只读取必要摘要和证据
- 最后通过完成率、时延、成本、误召回率来验证方案是否真的有效
这个结构的好处是：既有判断逻辑，也有落地路径，还能自然接住追问。
八、追问来了怎么接：准备三条“深入链路”
面试官听完初答后，通常会沿三个方向追问。
1）为什么不是直接换长上下文模型？
你可以答：
- 因为长上下文解决的是容量上限，不自动解决知识更新、证据追溯和成本问题。
2）RAG 如果误召回怎么办？
你可以答：
- 通过 metadata filtering、rerank、引用校验和低置信回退来治理，而不是把所有召回结果直接注入。
3）摘要如果越压越偏怎么办？
你可以答：
- 阶段摘要只保留状态骨架，原始证据和日志仍保留在旁路系统中，需要时回查。
这三条追问链，基本足以覆盖面试官最常见的深挖。
九、为什么这道题特别能区分“会用框架”和“会做系统”
真正做过系统的人，通常会自然提到：
- 分型
- 约束
- 回退
- 指标
而只会用框架的人，更容易停留在：
- 某个工具名字
- 某个论文概念
- 某个流行架构图
所以这道题的区分度很高。它不要求你背复杂算法，但非常要求你是否具备工程上的边界意识和取舍意识。
十、结论：高分不在于“知道所有方案”，而在于“能根据问题类型做正确取舍”
“上下文窗口不够怎么办”这道题，看似在问技术选型，实际是在问你是否理解系统设计的本质：先界定问题，再在约束下做取舍，并给出能验证、能回退、能扩展的方案。
因此，最稳的高分路径不是背一个万能答案，而是把问题拆清楚，把方案比较讲清楚，把工程边界和指标验证补完整。做到这三点，即使没有完全相同的实战经历，也能答出成熟度。
联动阅读：