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，字母数字整词保留，生产上专门的中文分词扩展。