消息、上下文工程与压缩、会话存储/恢复/分叉（dg M06/M08/M09/M10）

面试题库

• 长对话里上下文放不下了，你会怎么压缩？什么时候触发、压掉什么、保留什么？When a long conversation outgrows the context window, how do you compress it — when do you trigger, what do you drop, and what do you keep?

  国内高频海外高频进阶#context-engineering#compression#cost

  分析过程 · 先想清楚再作答

  1. 这题的区分度不在「用摘要」三个字上，几乎人人都答得出。区分度在你有没有说出触发时机和保留清单——只答「让模型总结一下前面的对话」的，面试官会判定你没在长对话上线过。
  2. 先把问题拆成三问再逐个答：什么时候压、压掉什么、保留什么。这个拆法本身就是加分项，因为它说明你把压缩当成一个策略而不是一个函数。
  3. 触发用阈值不用定时器，也不能等报错。给一个具体数字并解释它：历史占用到预算的七成就动手，因为摘要本身是一次模型调用，有延迟也可能失败，卡到九成再压，一旦摘要超时下一轮就直接撞窗口上限了——七成是留给自己的抢救时间。
  4. 压掉的是过程性内容：中间推理、已经被消费完的工具原始返回值、用户后来推翻的需求。它们的共同点是价值已经沉淀进后面的结论里。保留的是系统提示词（它不属于历史）、最近若干条原文、以及用户明确声明过的约束和事实——后者写错了模型会当场失忆。
  5. 再补一条别人不会说的：切口必须对齐到一轮的开头。切在 assistant 的 tool_calls 和对应的 tool 结果中间，下一次请求就有了悬空调用，多数厂商的 API 直接返回 400。这一条最能证明你真的调过。
  6. 可以预期的追问有两个。一是摘要该用哪个模型：用便宜的小模型就行，摘要是抽取任务不是推理任务，这也接上了 D4 的分层路由。二是摘要调用失败了怎么办：降级到不摘要的滑动窗口（直接丢最早的几轮），保证请求发得出去，别让压缩失败连带整轮对话失败。

  How to reason about it · think before answering

  1. Saying 'summarize it' earns nothing — everyone says that. The signal is whether you name a trigger point and a keep-list; without those you sound like someone who never ran a long conversation in production.
  2. Split it into three questions before answering: when to compress, what to drop, what to keep. The split itself scores, because it frames compression as a policy rather than a function.
  3. Trigger on a threshold, not a timer, and never on an error. Give a number and justify it: compress at roughly 70% of the history budget, because summarizing is itself a model call that can be slow or fail. Waiting until 90% means one timed-out summary call and the next turn slams into the window limit.
  4. Drop the process: intermediate reasoning, raw tool payloads already consumed, requirements the user later reversed — their value has already settled into later conclusions. Keep the system prompt (it is not history), the most recent turns verbatim, and any constraint or fact the user stated explicitly. Getting that last one wrong makes the model visibly forget.
  5. Add the detail others miss: the cut must land on a turn boundary. Slicing between an assistant tool_calls message and its matching tool result leaves a dangling call, and most providers reject that request with a 400. This is the line that proves hands-on experience.
  6. Two follow-ups to expect. Which model summarizes? A cheap small one — summarization is extraction, not reasoning, which ties back to tiered routing. And what if the summary call fails? Degrade to a plain sliding window that drops the oldest turns, so a failed compression never fails the whole turn.

  答题要点

  • 阈值触发：历史占用到预算七成就压，因为摘要本身是一次会失败、有延迟的模型调用，必须留抢救余量
  • 压过程、留结论：丢中间推理和已消费的工具原始返回，保留系统提示词、最近若干条原文、用户明确声明的约束与事实
  • 切口必须对齐到一轮开头，切在 tool_calls 与 tool 结果之间会让下一次请求返回 400
  • 压缩是有损且不可逆的：原始历史另存一份只追加，发给模型的是压缩版，需要回溯或分叉时读原始版
  • 摘要用便宜的小模型；摘要失败要能降级成滑动窗口，别让压缩失败连累整轮对话

  Key points

  • Threshold-triggered at about 70% of the history budget, because the summary call itself is a slow, fallible model call that needs headroom
  • Drop process, keep conclusions: discard intermediate reasoning and consumed raw tool payloads; keep the system prompt, the recent turns verbatim, and explicit user constraints and facts
  • Align the cut to a turn boundary — slicing between tool_calls and its tool result makes the next request fail with a 400
  • Compression is lossy and irreversible: keep an append-only original, send the compressed version, and read the original when you need to backtrack or fork
  • Summarize with a cheap small model, and degrade to a sliding window if the summary call fails so compression failure never fails the turn
• 会话的持久化、恢复和分叉分别解决什么问题？实现时各有什么坑？What problems do session persistence, restore, and forking each solve, and what goes wrong in each?

  国内高频海外高频进阶#session-management#persistence#forking

  分析过程 · 先想清楚再作答

  1. 题干把三件事并列，考的其实是你能不能分清它们各自的动机——很多人会把三个都答成「存下来」，那就丢掉了全部区分度。
  2. 先一句话各给一个动机：持久化解决「进程重启和跨机器请求」，恢复解决「加载回来还能接着聊」，分叉解决「同一段历史要走出两条不同的后续」。动机不同，所以数据结构的要求也不同。
  3. 持久化的关键选择是只追加还是快照。答只追加并给理由：写入不受历史长度影响、能回放到任意一步、有审计轨迹；快照只是读加速手段，工程上常见的是「只追加为准 + 定期快照」。这一条直接决定了分叉能不能做。
  4. 恢复的两个坑要主动说。一是把当时的系统提示词一起存进了历史，里面有「现在时间」这类动态上下文，三天后读出来模型的日期判断全错——系统提示词不进持久化历史，每次现拼。二是存档存在了工具调用中途，最后一条是没有配对结果的 tool_calls，直接发出去就是 400，加载后必须做完整性校验，补一条「执行被中断」的结果或丢弃这条尾巴。
  5. 分叉最容易被忽视的是「父会话只读」这条语义。分叉不是回滚：回滚砍掉历史继续用，是破坏性的；分叉复制前 k 条长出新枝，两边都能继续。实现上要深拷贝，直接引用父会话的消息对象会让两条分支互相污染。
  6. 可以预期的追问：分叉多了存储怎么办？答按父引用加偏移存、读时拼接，代价是读路径变复杂；再顺手补一句成本要能顺着 parentId 聚合成一棵树，否则账算不清是哪个用户的哪次重试花的钱。

  How to reason about it · think before answering

  1. The question lists three things side by side, so it is really testing whether you can separate their motivations. Answering 'they all save the conversation' throws away the entire signal.
  2. Give one motivation each in a sentence: persistence survives process restarts and multi-instance routing, restore lets a loaded history keep the conversation going, forking lets one history grow two different futures. Different motivations imply different data structures.
  3. The key persistence choice is append-only versus snapshot. Choose append-only and justify it: writes are independent of history length, any point can be replayed, and you keep an audit trail. Snapshots are a read optimization, so production usually means append-only as the source of truth plus periodic snapshots. This choice is what makes forking possible at all.
  4. Volunteer the two restore traps. First, persisting the system prompt inside the history: it carries dynamic context like the current time, so a session loaded three days later has the model reasoning from a stale date. Rebuild the system prompt fresh on every load. Second, a session saved mid tool call ends with an unmatched tool_calls message; replaying it verbatim gets a 400, so validate on load and either append an 'execution interrupted' tool result or drop the dangling tail.
  5. For forking, the overlooked point is that the parent stays read-only. Forking is not rollback: rollback truncates and mutates, forking copies the first k messages into a new branch and both sides continue. Deep-copy the messages — sharing the parent's objects lets the branches contaminate each other.
  6. Expect the follow-up on storage: reference the parent plus an offset and stitch on read, at the cost of a more complex read path. Add that cost must aggregate up the parentId tree, or you cannot tell which user's retry burned which tokens.

  答题要点

  • 持久化解决进程重启与跨实例，选只追加：写入不受历史长度影响、可回放任意一步、有审计轨迹；快照只是读加速
  • 恢复要现拼系统提示词，不能把带「现在时间」的那份存进历史，否则读出来日期判断全错
  • 恢复必须做完整性校验：尾部悬空的 tool_calls 要补一条中断结果或丢弃，否则下一次请求返回 400；压缩水位也要一起恢复
  • 分叉是复制前 k 条并记住父会话与切点，父会话只读——这是它和破坏性回滚的根本区别，实现上必须深拷贝
  • 分叉的代价是存储放大与成本归属，规模上来后改成存父引用加偏移，账要能顺着 parentId 聚合成树

  Key points

  • Persistence handles restarts and multiple instances; prefer append-only for constant-cost writes, replayability and an audit trail, with snapshots purely as a read optimization
  • On restore, rebuild the system prompt fresh — persisting the one containing the current time makes the model reason from a stale date
  • Validate on restore: a dangling tool_calls tail needs an 'interrupted' tool result or must be dropped, or the next request returns 400; restore the compression watermark too
  • A fork copies the first k messages and records parent and cut point, leaving the parent read-only — that is what separates it from destructive rollback, and it requires a deep copy
  • Forking costs storage amplification and muddled cost attribution; at scale store a parent reference plus offset and aggregate spend up the parentId tree
• 短期上下文和长期记忆的边界怎么划？一条信息该往哪放，你的判断依据是什么？Where do you draw the line between short-term context and long-term memory, and how do you decide where a given fact belongs?

  国内高频海外高频基础#memory#context-engineering

  分析过程 · 先想清楚再作答

  1. 这题看着像概念题，其实考的是你有没有一条可执行的判据。背出「短期在 messages 里、长期在向量库里」只是描述现状，答不出「为什么这条该进长期」就没有区分度。
  2. 先把两者的工程属性摆出来，边界自然就清楚了：短期上下文随会话结束作废、全量进请求、按 token 计费、受窗口约束；长期记忆跨会话存在、不进请求而是检索后注入、按条存储、受检索质量约束。
  3. 给一条可复用的判据，这是本题的核心：问三句话——跨会话之后还需要吗、会随时间失效吗、能通过检索捞回来吗。三个都是「是」就进长期记忆，第一个是「否」就留在短期。举例说明：用户住上海进长期，用户刚才让我把段落改成三句话留短期。
  4. 点出最常见的误用：把长期记忆当上下文一次性全塞进去。用了半年攒两百条偏好，全塞进请求既撑爆窗口，又因为大量不相关记忆干扰模型判断——长期记忆的价值在于按需检索出最相关的三五条，不在于存了多少。
  5. 可以预期的追问：长期记忆怎么更新和失效？答要点是记忆要带时间戳和来源，用户改了主意要能覆盖旧记忆而不是并存两条矛盾的；再补一句删除权——用户要求删数据时，长期记忆是必须能定位并整体删掉的那一部分。

  How to reason about it · think before answering

  1. This looks conceptual but is really asking for an operational test. Reciting 'short-term lives in messages, long-term lives in a vector store' just describes the status quo and gives no signal.
  2. Lay out the engineering properties and the boundary draws itself: short-term context dies with the session, ships in full on every request, is billed per token and capped by the window; long-term memory spans sessions, is retrieved and injected rather than always sent, is stored per item and capped by retrieval quality.
  3. Give a reusable test — this is the core of the answer. Ask three questions: is it still needed after this session ends, does it expire with time, can retrieval find it again? Three yeses means long-term; a no on the first means it stays short-term. Illustrate: 'the user lives in Shanghai' is long-term, 'the user just asked me to shorten that paragraph to three sentences' is not.
  4. Name the common failure: stuffing all long-term memory into the prompt. Two hundred preferences accumulated over six months will both blow the window and drown the model in irrelevance. The value of long-term memory is retrieving the three or four relevant items, not the volume stored.
  5. Expect the follow-up on updates and expiry: memories need timestamps and provenance, and a changed preference must overwrite rather than coexist with a contradictory one. Add the deletion angle — long-term memory is the part you must be able to locate and erase when a user asks for their data to be deleted.

  答题要点

  • 短期上下文随会话作废、全量进请求、按 token 计费受窗口约束；长期记忆跨会话、按需检索后注入、按条存储受检索质量约束
  • 判据三问：跨会话还需要吗、会随时间失效吗、能被检索捞回来吗——三个都是就进长期记忆
  • 常见误用是把长期记忆整包塞进上下文，既撑爆窗口又用不相关的记忆干扰模型，正确做法是检索最相关的三五条
  • 长期记忆要带时间戳和来源，用户改主意时覆盖旧记忆，避免两条矛盾记忆并存
  • 长期记忆是合规上必须能按用户定位并整体删除的那一部分，短期上下文随会话删除即可

  Key points

  • Short-term context dies with the session, ships in full, and is billed per token under the window cap; long-term memory spans sessions, is retrieved on demand, and is capped by retrieval quality
  • The three-question test: is it needed after this session, does it expire, can retrieval find it — three yeses means long-term
  • The common failure is injecting the whole memory store, which blows the window and drowns the model in irrelevance; retrieve the three or four relevant items instead
  • Long-term memories need timestamps and provenance so a changed preference overwrites the old one instead of contradicting it
  • Long-term memory is the part that must be locatable and deletable per user for compliance, while short-term context simply dies with the session
• 上下文工程和 RAG 检索是什么关系？只做 RAG 不做上下文管理会出什么问题？How do context engineering and RAG relate, and what breaks if you do RAG without context management?

  国内高频海外高频深入#context-engineering#rag#retrieval

  分析过程 · 先想清楚再作答

  1. 题眼在「关系」。把两者说成并列的两种技术是最常见的失分答法——正确的框架是包含关系：上下文工程是「决定这次请求里放什么」，RAG 是它的一种供给手段，负责「从外部捞该放进去的东西」。
  2. 拆开看职责就清楚了：RAG 解决的是「信息不在模型参数里、也不在当前对话里」，靠检索把它取回来；上下文工程解决的是「取回来的东西、加上历史、加上工具定义，一共放不放得下、该按什么优先级放」。前者管来源，后者管预算。
  3. 所以只做 RAG 不做上下文管理会出三类问题，最好按这个顺序说。第一是挤占：检索回来的文档动辄几千 token，直接拼进去把对话历史挤没了，模型记得住资料却忘了用户三句话前说过什么。第二是干扰：召回条数调大看着安全，实际上不相关的片段会稀释模型注意力，准确率不升反降。第三是成本：检索结果每一轮都重发，一段两千 token 的资料聊十轮就付了十次。
  4. 给出正确的组合姿势：先给历史和检索结果各划一条预算线，检索结果只保留 top-k 且不跨轮重复注入，历史超线就压缩，两条线加起来必须留出输出空间。这套「分账」的说法比笼统的「要平衡」有说服力得多。
  5. 可以预期的追问：检索结果该放在系统提示词里还是当成一条 user 消息？答放在靠近当前问题的位置通常效果更好，而且要标注来源便于模型区分「资料」和「用户说的话」；顺带说清它是一次性上下文，不该被写进长期会话历史里反复重发。

  How to reason about it · think before answering

  1. The hinge word is 'relate'. Treating them as two parallel techniques is the standard weak answer — the right frame is containment: context engineering decides what goes into this request, and RAG is one supply mechanism that fetches what should go in.
  2. Separate the responsibilities and it becomes obvious: RAG solves 'the information is neither in the weights nor in this conversation' by retrieving it; context engineering solves 'the retrieved chunks plus the history plus the tool definitions all have to fit, in some priority order'. One owns sourcing, the other owns budget.
  3. So RAG without context management breaks in three ways, best delivered in this order. Crowding: retrieved documents run to thousands of tokens and squeeze out the conversation, so the model knows the manual but forgot what the user said three turns ago. Interference: raising top-k feels safe but irrelevant chunks dilute attention and accuracy drops instead of rising. Cost: retrieved text is resent every turn, so a 2k-token passage costs ten times over ten turns.
  4. Give the correct combination: budget history and retrieval separately, keep retrieval to top-k without re-injecting the same chunks every turn, compress history when it crosses its line, and make sure both lines together still leave room for output. This 'separate budgets' framing lands much better than a vague 'you need to balance them'.
  5. Expect the follow-up on placement: putting retrieved context near the current question usually works better, and it should be labeled with its source so the model can tell reference material from what the user actually said. Note too that it is single-turn context and should not be written into the persisted history and resent forever.

  答题要点

  • 不是并列关系而是包含关系：上下文工程决定这次请求放什么，RAG 是给它供货的一种手段，负责把不在模型和对话里的信息检索回来
  • 只做 RAG 会挤占历史：几千 token 的检索结果把对话挤没，模型记得住资料却忘了用户刚说的话
  • 召回条数越大越准是错觉：不相关片段会稀释注意力，准确率反而下降，应控制 top-k
  • 检索结果每轮重发会持续计费，属于一次性上下文，不该写进持久化历史反复重发
  • 正确姿势是给历史和检索各划一条预算线，历史超线就压缩，两条线之外还要留出输出空间

  Key points

  • They are not parallel: context engineering decides what enters the request, and RAG is one supply mechanism for information that is neither in the weights nor in the conversation
  • RAG alone crowds out history — multi-thousand-token retrievals evict the conversation, so the model knows the docs but forgot the user's last request
  • A bigger top-k is not safer: irrelevant chunks dilute attention and accuracy drops, so cap retrieval
  • Retrieved text is single-turn context; persisting it into the history means paying for it on every subsequent turn
  • Budget history and retrieval on separate lines, compress history when it crosses its line, and leave room for the output on top of both

评论

登录后即可参与讨论

还没有评论，来说第一句。