Interview Bank

From Frontend Engineer to Agent Engineer in 30 Days

D6 Messages, Context Engineering and Compression, Session Storage/Recovery/Forking (dg M06/M08/M09/M10)

• How do context engineering and RAG relate, and what breaks if you do RAG without context management?上下文工程和 RAG 检索是什么关系？只做 RAG 不做上下文管理会出什么问题？

  Common in ChinaCommon overseasDeep dive#context-engineering#rag#retrieval

  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.

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

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

  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

  答题要点

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

D24 RAG, Level Up: Hybrid Search, Reranking, Citations, Recall Evaluation

• Why isn't pure vector search enough — what does keyword search add?为什么单纯的向量检索不够，还要加一路关键词检索？

  Common in ChinaCommon overseasBasic#rag#hybrid-search#retrieval

  How to reason about it · think before answering

  1. The discriminator is not whether you know the term 'hybrid search' — it is whether you can name a concrete query that vector search will always miss. No example means you have only read architecture diagrams.
  2. One causal chain: vector search compares semantic distance, so both its strength and its weakness come from that compression step. Synonyms match (shipping fee vs postage), but strings with no semantics collapse together — error codes, SKUs, order ids, person names.
  3. BM25 has the mirror-image profile: a term matters more when it is frequent in this document and rare across the corpus. So it nails low-frequency literals and fails completely on paraphrase.
  4. State the conclusion as 'their blind spots do not overlap, and that follows from how each one computes' — not the vague 'two channels are safer'. A measured example lands best: for 'what does E4032 mean', the correct doc is absent from the vector top-5 and is the keyword top-1.
  5. Expected follow-up 1: how do you merge the two rankings? Answer RRF, and explain why weighted sums fail (see q02).
  6. Expected follow-up 2: how do you do keyword search over Chinese? Postgres's default parser effectively does not tokenize Chinese; the cheapest workable fallback is character bigrams, keeping ASCII words and codes whole. Production needs a real Chinese tokenizer extension. Answering this usually proves you actually built it.

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

  1. 这题的区分度不在「你知不知道有 hybrid search」，而在**你能不能说出一个向量检索一定会漏的具体例子**。答不出例子的，一听就是只看过架构图。
  2. 推导链只有一句：向量检索比的是语义距离，所以它的强项和弱项都来自「压缩成语义」这一步——同义词能对上（运费 / 邮费），而没有语义的字符串会被压到一起（E4032、SF-3000、订单号、人名）。
  3. 关键词那一路（BM25）的性质正好相反：一个词在本文档里越频繁越相关、在全语料里越常见越不值钱，所以它对低频稀有词极准，对同义改写完全无能。
  4. 结论要说成「两者的盲区不重叠，而且是由计算原理决定的不重叠」——不是「多一路更保险」这种模糊说法。举一个实测例子最有说服力：查「E4032 是什么意思」，向量 top5 里没有那篇讲支付错误码的文档，关键词 top1 就是它。
  5. 可预期的追问一：那怎么合并两路结果？答 RRF，并说清为什么不能加权求和（见 q02）。
  6. 可预期的追问二：中文怎么做关键词检索？答 Postgres 默认分词器对中文等于不分词，最简可用的兜底是 bigram（相邻两字切开），但英文与编号必须整词保留；生产要上专门的中文分词扩展。这一条能答出来，基本就说明你真动手做过。

  Key points

  • Vector search compares semantic distance: strong on paraphrase, weak on SKUs, error codes and order ids that carry no semantics.
  • BM25 is strong on rare literal terms and weak on paraphrase — the blind spots follow from the algorithms and do not overlap.
  • So run both channels wide (top 20 each) and fuse with RRF so each covers the other's gap.
  • Give a measured example: for the E4032 query the correct chunk is missing from vector top-5 but is keyword top-1; a 'postage vs shipping fee' query is the reverse.
  • Chinese keyword search needs tokenization: character bigrams as the cheap fallback, ASCII words kept whole, a real tokenizer extension in production.

  答题要点

  • 向量检索比的是语义距离，强在同义改写，弱在型号、错误码、订单号这类没有语义的字符串。
  • BM25 强在低频稀有词的字面命中，弱在同义改写——两者的盲区由各自的计算原理决定，不重叠。
  • 所以第一轮开两路、各取 20 条，用 RRF 融合，把两边的盲区互相补上。
  • 举实测例子：E4032 那条 query 向量 top5 漏掉正确文档，关键词 top1 就是它；「邮费」那条反过来只有向量能召回。
  • 中文关键词那一路要处理分词，最简兜底是 bigram，字母数字整词保留，生产上专门的中文分词扩展。

Context Engineering in 5 Days

D3 Managing Context for Tool Results and Retrieval: Loading on Demand, Summarizing and Pruning, Structured Returns

• How do you choose between just-in-time loading and pre-inference retrieval, and how would you combine them?按需加载和预先检索怎么选？混合策略应该怎么搭？

  Common in ChinaCommon overseasIntermediate#retrieval#just-in-time#hybrid

  How to reason about it · think before answering

  1. This tests situational judgment. Calling just-in-time more advanced reads as trend-following, because pre-inference retrieval is genuinely better in many cases.
  2. Separate with three questions: can the needed material be scoped in advance (yes favors pre-retrieval), how fast does the material change (fast means indexes go stale, favoring just-in-time), and can it be fetched in one shot (multi-hop exploration forces just-in-time).
  3. Name the underlying difference: pre-retrieval hands the what-to-fetch decision to a retrieval algorithm and settles it before inference; just-in-time hands it to the model and spreads it across the run. The first is faster and more predictable, the second handles not knowing in advance.
  4. Conclusion is hybrid: preload the small, stable, always-relevant slice such as a project's standing instruction file, and use runtime search primitives for the rest. That gives a fast start without stale indexing, which is what coding agents converge on.
  5. Expect the follow-up on cost: just-in-time adds round trips and latency, and every fetched body stays in context consuming budget, so it must be paired with trimming.

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

  1. 这题在考场景判断。答「按需加载更先进」的会被当成跟风，因为预先检索在很多场景里就是更好的选择，说不出它好在哪说明没做过。
  2. 怎么拆：用三个问题分开。需要的资料范围事先能不能确定（能就预先检索）、资料变化快不快（变得快索引一建就旧，偏按需加载）、一次能不能取完（要顺着线索翻好几层就只能按需）。
  3. 把两者的本质差别点出来：预先检索把「取什么」的决定权交给检索算法，在推理之前一次性做完；按需加载把这个决定权交给模型自己，在推理过程中分多次做。前者延迟低、可预测，后者能应付事先不知道要什么的情况。
  4. 结论是混合：把最稳定最常用的一小部分预先放进去（比如项目的常驻说明文件），其余靠运行时的搜索原语现取。这样既有起步速度，又不会被过期索引拖住。这也是编码类 Agent 的主流做法。
  5. 可预期的追问：按需加载的成本在哪？多了几轮往返，延迟更高，而且每一次取回的正文都会留在上下文里继续占预算——所以它必须和裁剪配套，取回来的东西该扔的时候要扔。

  Key points

  • Three questions: can scope be fixed in advance, how fast does the data change, and can it be fetched in one shot.
  • Pre-retrieval delegates the fetch decision to an algorithm before inference; just-in-time delegates it to the model during the run.
  • Most real systems are hybrid: preload the stable core, use runtime search for the rest, avoiding stale indexes.
  • Just-in-time costs round trips and latency, and fetched bodies keep consuming budget, so pair it with trimming.

  答题要点

  • 三个判断：范围能不能事先确定、资料变化快不快、一次能不能取完。
  • 预先检索把取什么的决定交给检索算法并在推理前做完；按需加载把它交给模型并分多次做。
  • 多数真实项目是混合：稳定常用的一小部分预加载，其余靠运行时搜索原语现取，避开索引过期。
  • 按需加载的代价是多轮往返与延迟，且取回的正文会继续占预算，必须和裁剪配套。

RAG in 14 Days: From Retrieval to Trustworthy Answers

D7 Week One Capstone: Assembling Six Days of Parts Into a One-Command Question-Answering Service, and a Retrospective

• What should the ingestion path and the query path share, and what concretely goes wrong when you over-share?摄取链路和查询链路应该共享哪些代码？强行复用会带来什么具体问题？

  Common in ChinaCommon overseasIntermediate#architecture#ingestion#retrieval

  How to reason about it · think before answering

  1. The word to notice is 'over-share'. The interviewer wants the boundary, not a recital of DRY.
  2. Start from how the two paths differ. Ingestion is batch: tens of seconds, and a failure just means rerunning it. Query is online: hundreds of milliseconds, and a failure is visible to the user immediately. Error handling, timeouts and concurrency are simply not the same problem.
  3. Hence the rule: share the interface, not the flow. The only genuinely shared thing is the storage interface, plus the embedding function signature.
  4. Name the symptom of over-sharing: the extracted module fills up with isIngest branches, every change has to be verified on both paths, and eventually nobody dares touch it.
  5. Add the one thing that truly must match: chunks and queries must be embedded by the same model. That is shared configuration, not shared code, and the model name belongs in the vector table so a silent mismatch is detectable.
  6. Expected follow-up: what about chunking? The query path never chunks. Even when it needs a parent block, it reads it back through storage rather than importing the chunker.

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

  1. 题眼在「强行」两个字。面试官想看的是你能不能说出复用的边界，而不是背诵「不要重复自己」。
  2. 先说清两条链路的性质差异：摄取是批处理，几十秒跑完，失败重跑一遍就行；查询是在线请求，几百毫秒要出结果，失败用户当场看到。错误处理、超时、并发策略天然不同。
  3. 所以结论是：**共享接口，不共享流程**。两边唯一该共享的是存储层的那个接口，以及 embedding 的函数签名——注意后者共享的是签名和模型选择，不是调用流程。
  4. 给出强行复用的具体症状：抽出来的公共模块里开始出现 isIngest 这类分支，一个改动要同时验证两条链路，最后没人敢动它。
  5. 补一条真正必须一致的东西：给块算向量和给问题算向量必须用同一个模型。这不是复用代码，是复用配置——而且要把模型名写进向量表，否则模型换了没人发现，检索会静默地返回垃圾。
  6. 可预期的追问：那切块逻辑呢？查询侧压根不切块，所以它只属于摄取链路；真要在查询侧用到（比如 D11 的父子回填），走的也是存储层读回大块，不是把切块器搬过来。

  Key points

  • Share the interface, not the flow: storage is the only boundary, plus the embedding signature.
  • The two paths have different error handling and latency budgets; batch can rerun, online must fail fast.
  • Over-sharing shows up as isIngest branches and changes that must be verified twice.
  • What must match is the model choice, not the code: record the model name alongside every stored vector.
  • Chunking belongs to ingestion only; the query path reads larger units back through storage.

  答题要点

  • 共享接口不共享流程：唯一的交界是存储层，加上 embedding 的函数签名。
  • 两条链路的错误处理与延迟约束根本不同，批处理可以重跑，在线请求必须快速失败。
  • 强行复用的症状是公共模块里长出 isIngest 分支，改一次要验两条链路。
  • 必须一致的是模型选择而不是代码：块与查询要用同一个 embedding 模型，并把模型名记进向量表。
  • 切块只属于摄取；查询侧需要大块时通过存储层读回，而不是把切块器搬过去。