面试题：LLM 上下文窗口与多轮对话超限

题目

一个 AI 对话应用在每次请求时，都会将 system prompt、之前的对话记录和用户本次输入一起发送给模型。对话开始时工作正常，但轮次增多后，接口返回“超过上下文窗口限制”的错误。

请回答：

1. 什么是 Token？它与字符数、字数是什么关系？

2. 为什么对话轮次增加后会超过上下文窗口？

3. 你会如何在前端和BFF中处理这个问题？

回答1

1. token在LLM中表示字符的消耗，但token不等同于一个字符或一个字数，一个token可能是由多个字符组成；

2. LLM会读取之前会话的记忆，每次会话请求时，都有可能将多个会话记录一起再发送给LLM；

3. 前端增加显示上下文百分比，增加上下文压缩操作，在BFF中对对话采用RAG后发送给LLM

解答1

结论：方向部分正确，但基础概念和方案边界还不够准确。45 / 100。

1. 正确点

• 知道 Token 与字符数、字数不是固定的一一对应关系。

• 识别到多轮对话通常会重复发送历史消息，因此上下文会不断增长。

• 提出了上下文占用提示和压缩，说明你注意到了产品体验与工程处理。

• RAG 可以用于从历史信息中选择相关内容，但需要明确适用方式。

2. 遗漏点

• Token 还可能对应单词的一部分、标点、空格或多个字符，具体取决于模型使用的 tokenizer。

• 上下文通常不只有对话历史，还可能包含：

  • system prompt

  • 工具定义

  • RAG 检索内容

  • 当前输入

  • 为模型输出预留的 Token

• 没有说明超限后的截断、摘要、错误提示和重新生成策略。

• 前端看到的消息并不是全部上下文，因此只能显示估算值；准确预算通常应由 BFF 管理。

3. 错误点

“LLM 会读取之前会话的记忆”不够准确。

多数模型 API 请求本身是无状态的：模型不会自动读取之前的会话，而是应用在当前请求中重新传入历史消息。真正保存会话的是应用或服务端。

“对对话采用 RAG”也不能直接等同于上下文压缩：

• 截断：直接丢弃部分消息。

• 摘要：把多条历史压缩成较短内容。

• 检索：从历史信息中选择当前可能相关的部分。

• RAG：通常强调从外部知识源检索内容，也可以用于历史记忆检索，但可能漏掉关键上下文。

4. 更适合面试口述的表达

你可以先这样开头：

Token 是模型处理文本的基本计量单位，由tokenizer根据模型规则进行切分，并不固定对应一个字符或一个单词。多数模型 API 本身没有持续会话记忆，多轮对话是应用在每次请求时重新传入历史消息，因此历史消息、system prompt、工具定义和预留输出共同消耗上下文窗口。

后面的解决方案先不要展开，我通过追问确认你是否真正理解。

5. 递进追问

假设模型上下文窗口为 16K Token：

• system prompt 和工具定义占 3K

• 当前用户输入占 1K

• 需要为模型输出预留 2K

• 历史消息已经占 15K

此时 BFF 应该如何处理历史消息？请说明你的处理顺序，以及前端应该向用户展示什么。不要只回答“使用 RAG”。

6. 下一步复习建议

重点补强这条链路：

无状态模型请求
-> 请求上下文组成
-> 输入与输出 Token 预算
-> 截断 / 摘要 / 检索
-> 前端提示与失败恢复

回答2

1. 优先保留用户身份和任务目标，其次是最近的消息，对于较早的消息进行摘要或者淘汰

2. 比如任务目标不能拆开，可能会导致任务偏差；较早的消息也不能单独删除，应提取其中比较重要的信息片段

3. BFF则降级处理，删除一些较早片段信息，前端要提示上下文已被压缩

解答2

结论：这次补答有明显提升，62 / 100。已经形成基本策略，但消息完整性和降级处理还需要补强。

分项：

• 正确性：27 / 40

• 原理理解：12 / 20

• 工程应用：12 / 20

• 边界与权衡：4 / 10

• 面试表达：7 / 10

正确点

• 保留优先级基本合理：任务目标和长期约束优先，其次是近期消息。

• 知道较早内容可以通过摘要减少 Token。

• 知道压缩后需要向用户说明，避免用户误以为模型仍掌握全部历史。

遗漏点

• Tool Call 和 Tool Result 必须成组保留，不能只保留其中一个。

• 应尽量保留完整对话轮次，避免在一条消息中间按字符截断。

• 摘要完成后必须重新计算 Token，而不是假设一定满足限制。

• 原始消息应该继续保存在数据库中，方便恢复、审计或重新生成摘要。

• 压缩后仍然超限时，还需要停止请求、要求新建会话或让用户确认舍弃哪些信息。

错误点

“删除较早片段信息”需要区分两个动作：

• 从本次模型请求中移除：合理。

• 从数据库永久删除原始会话：通常不合理。

上下文窗口管理的目标是减少发送给模型的内容，不代表必须删除用户的原始会话记录。

完整面试口述答案

Token 是模型处理文本的基本计量单位，由具体模型的 tokenizer 进行切分，它和字符数、字数不是固定的一一对应关系。一个 Token 可能是一个词的一部分、标点、空格或者多个字符。

多数模型 API 本身是无状态的，模型不会自动读取之前的会话。为了实现多轮对话，应用会在每次请求时重新发送 system prompt、工具定义、历史消息、当前输入以及检索内容，这些内容再加上模型输出共同占用上下文窗口。

在这个例子中，模型总窗口是 16K，扣除 3K 的 system prompt 和工具定义、1K 当前输入以及 2K 输出预留后，历史消息最多只能使用 10K，实际工程中还应保留一定安全余量。

BFF 首先使用目标模型对应的 tokenizer 估算 Token，然后按优先级组织上下文：保留 system prompt、当前输入、任务目标和用户确认过的长期约束；其次保留最近的完整对话轮次；更早的历史生成滚动摘要，或者只检索与当前问题相关的内容。

处理过程中不能拆开 Tool Call 和对应的 Tool Result，也应避免从一条消息中间随意截断。摘要后需要重新计算 Token。如果仍然超限，可以继续减少早期消息或检索结果；如果已经无法安全压缩，就停止模型请求，提示用户新建会话或确认舍弃部分历史。

原始会话仍然保存在数据库中，只是不全部发送给模型。前端可以显示上下文占用的估算值，并明确提示“较早内容已被摘要，部分细节可能无法继续使用”，同时提供新建会话或查看原始记录的入口。

本题首次正式回答记录为 45 分，本次补答作为追问表现记录为 62 分，不单独增加能力证据。下一次建议通过不同场景复测 Token 预算、摘要和检索的边界。