Interview Bank

RAG in 14 Days: From Retrieval to Trustworthy Answers

D13 Going to Production: Incremental Sync and Deduplication, Permission-Based Filtering, Cache Layering, Tracing, and the Cost-Latency Ledger

• What can be cached in a RAG system, and what are the invalidation conditions for each?RAG 系统里有哪些东西可以缓存？各自的失效条件是什么？

  Common in ChinaCommon overseasIntermediate#caching#invalidation#cost-optimization

  How to reason about it · think before answering

  1. This looks like a giveaway and is actually a filter. 'Cache the question and answer' earns a third of the credit; the interviewer is waiting for the layering and the per-layer invalidation rules.
  2. Lead with a transferable rule: 'when must this be invalidated' is the same question as 'is that thing part of the key'. Leave something out of the key and changes to it will never invalidate the entry. With that rule the three layers derive themselves.
  3. Then go layer by layer. The answer layer maps a question to a final answer; its key needs the question, the permission scope, the index version, and the model plus prompt version. The retrieval layer maps a query to a hit list; its key needs the question, scope, topK, index version and embedding backend, but not the generation model. The embedding layer maps text to a vector; its key is just the text and the backend.
  4. Emphasize the counterintuitive part of the embedding layer: it is content-addressed, so the index version must not be in its key. Put it there and a single sync invalidates tens of thousands of vectors, which is exactly the full rebuild you added caching to avoid. This is the one layer that can live a long time, even on disk.
  5. Offer a concrete invalidation mechanism: version numbers rather than targeted deletion. Bump an index version whenever a sync actually changes something and old keys simply stop being computed. Targeted deletion would require enumerating which questions a change affected, and that list cannot be produced.
  6. Expected follow-up: can you give a real 'should have expired but didn't' case? Yes: an answer cache keyed only on the question. A document's limit changes from 200 MB to 500 MB, the index is updated, and the same question still returns 200 MB. Nothing errors; the log shows a clean cache hit. The same key also serves one department's answer to a user from another.

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

  1. 这题看起来是送分题，实际是筛人题。答成「把问答结果缓存起来」只拿到三分之一，面试官等着听的是「分几层」和「各自什么时候失效」。
  2. 先给一条能迁移到别的题上的判断依据：**「什么时候必须失效」这个问题，等价于「key 里有没有把那样东西算进去」。** key 少放一样，那样东西变了缓存就不会失效。有了这条，三层的答案自己就长出来了。
  3. 然后逐层给：答案层缓存问题到最终答案，key 要有问题、权限范围、索引版本、模型与提示词版本；检索层缓存检索式到命中块列表，key 要有问题、权限范围、topK、索引版本、向量后端，但不需要模型；向量层缓存文本到向量，key 只有文本和向量后端。
  4. 重点讲向量层的反直觉之处：它是**内容寻址**的，文本没变、模型没变，向量就不会变，所以**不能把索引版本放进它的 key**。放进去的话一次同步就作废几万条向量，正好绕回全量重建——你加缓存想省的那笔钱又花回去了。这一层可以放很久甚至持久化。
  5. 给一个具体的失效手法：用**索引版本号**而不是精确删除。同步只要真的改动了索引就把版本号加一，旧 key 再也算不出来，自然没人读得到。精确删除要求你能列出「这次改动影响了哪些问题」，而那是列不出来的。
  6. 可预期的追问：能举一个「该失效却没失效」的真实例子吗？答：答案缓存的 key 只放了问题本身，文档里的上限从 200 MB 改成 500 MB、索引已经更新，再问同一个问题仍然返回 200 MB。它不报错，日志上是一次漂亮的缓存命中；同一个 key 还会让另一个部门的用户直接命中别人的答案。

  Key points

  • Three layers — answer, retrieval, embedding — with lifetimes orders of magnitude apart; treating them as one thing is the mistake.
  • The rule is that 'when must it expire' equals 'is it in the key'; anything left out of the key can never invalidate the entry.
  • The answer key carries question, permission scope, index version, model and prompt version; the retrieval key drops the model and adds topK and the embedding backend.
  • The embedding layer is content-addressed and keyed only on text plus backend; adding an index version turns every sync back into a full rebuild.
  • Version-based invalidation beats targeted deletion because you cannot enumerate which questions a given change affected.

  答题要点

  • 分三层：答案、检索、向量，三者的寿命差着数量级，不能当成一件事。
  • 判断依据是「什么时候必须失效」等价于「key 里有没有算进那样东西」，key 少一样就永远失效不了。
  • 答案层 key 要有问题、权限范围、索引版本、模型与提示词版本；检索层去掉模型、加上 topK 与向量后端。
  • 向量层是内容寻址的，key 只有文本与后端；把索引版本放进去会让每次同步都退化成全量重建。
  • 用索引版本号做失效比精确删除可靠，因为「这次改动影响了哪些问题」根本列不出来。

Build an AI Short-Drama Production Pipeline With Agents in 14 Days

D3 Character Consistency: Character Sheets, Reference Images, and Style Locking — Keeping the Same Person the Same Person in Every Shot

• How would you design the cache key for reusing generated assets so that you save money without serving the wrong asset?生成类资产要做复用，缓存键你会怎么设计，才能既省钱又不会串戏？

  Common in ChinaCommon overseasDeep dive#caching#cost#image-generation

  How to reason about it · think before answering

  1. This question is about two kinds of cache error with wildly asymmetric cost. A miss only costs money; a wrong hit puts last episode's prop into this one. The first is a number, the second is a content incident.
  2. The derivation is one sentence: the key must be computed from every input that changes the artifact, and nothing else. Include something irrelevant, like the output path, and one directory refactor invalidates everything and you pay again; omit something relevant, like the prompt, and a changed description silently serves the old image.
  3. Concretely, hash the asset kind, the owning entity id, the variant name, the full prompt, the reference image identity and the seed. Take a short digest as the id, and store those fields verbatim in the metadata so any artifact can be reproduced.
  4. Then name the boundaries yourself: does the model id and version belong in the key? Yes. What if the style template changes? It is part of the prompt, so it invalidates everything by construction — which is why templates should carry a version number, letting you choose the blast radius.
  5. One more production note: never cache failed generations, or you will faithfully reuse an empty result that safety review rejected. Cache hits also belong in the cost ledger, flagged as hits, otherwise you cannot report how much caching saved.
  6. Expect the follow-up: should the cache expire? Content assets usually should not expire on time; invalidate explicitly by version instead, because a time-based expiry regenerates a whole episode at the least convenient moment.

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

  1. 这题考的是缓存的两类错误，而且两类的代价完全不对称。少命中只是多花钱，错命中会把上一集的道具塞进这一集——前者可量化，后者是内容事故。
  2. 推导链只有一句：**键必须由所有会改变产物的输入算出来，一项不多一项不少。** 多算了不该算的（比如输出路径），改一次目录结构缓存全部失效，白花一遍钱；少算了该算的（比如提示词），换了描述还命中老图，就是串戏。
  3. 落到这个场景，参与哈希的是：资产类别、归属对象、变体名、完整提示词、参考图标识、随机种子。用 sha1 之类取个短摘要当 id，元数据里再把这几项原样存一份，出问题能照着复现。
  4. 然后主动把边界说清楚，这是加分项：模型 id 与版本要不要进键？要。风格模板改了怎么办？它是提示词的一部分，进键之后天然全部失效——所以模板要谨慎改，或者给它一个版本号，让你能决定失效的范围。
  5. 生产视角还有一条：失败的生成不要写进缓存，否则你会稳定复用一张被审核拦下的空结果。命中缓存的那条路径也要记台账并标成命中，不然你算不出缓存到底省了多少钱。
  6. 可以预期的追问：缓存要不要过期？答案是内容型资产通常不设时间过期，而是靠版本号显式失效；时间过期会在你毫无预期的时候让一整集重新生成一遍。

  Key points

  • Derive the key from everything that changes the artifact: asset kind, owner id, variant, full prompt, reference image identity, seed, plus model id and version
  • Keep output paths and filenames out of the key, or one directory refactor invalidates the whole cache and you pay twice
  • Omitting inputs like the prompt causes wrong hits, which are content incidents and far costlier than misses
  • Store the hashed fields verbatim in metadata so any artifact is reproducible, and never cache failed generations
  • Record cache hits in the cost ledger flagged as hits, and invalidate explicitly by version rather than by time

  答题要点

  • 键由所有会改变产物的输入算出：资产类别、归属对象、变体名、完整提示词、参考图标识、随机种子，再加模型 id 与版本
  • 不要把输出路径或文件名放进键，改目录结构会让缓存整体失效，白付一遍钱
  • 少算提示词这类输入会导致错命中，那是内容事故，代价远高于少命中
  • 元数据里原样保存参与哈希的各项，出问题能复现；失败的生成不写缓存
  • 命中缓存也要记台账并标成命中，否则算不出缓存省了多少；失效靠显式版本号而不是时间过期

D8 A Workflow Engine: Turning the Pipeline Into a Resumable Task Graph

• How do you make a node that calls a paid generation API idempotent? What belongs in the cache key and what does not?怎么让一个会调用付费接口的生成节点是幂等的？缓存键里该放什么、不该放什么？

  Common in ChinaCommon overseasIntermediate#idempotency#caching#workflow-engine

  How to reason about it · think before answering

  1. The discriminator is the second half: what must not go in. People who only say 'hash the inputs' have usually never been burned by a cache. The two failure modes point in opposite directions: never hitting, and hitting when it should not.
  2. State the criterion first: include everything that changes the artifact, exclude everything that changes every run without affecting the artifact. Both lists fall out of that.
  3. Include four things: node id, implementation version, this node's own inputs (model id, prompt, duration, resolution), and the fingerprints of all dependencies. The version and the dependency fingerprints are the two people forget — miss the version and new code reads old artifacts; miss the dependencies and an upstream script change never propagates.
  4. Exclude: run id, timestamps, random values, absolute paths, and anything carrying a hostname or temp directory. Any of those makes every key new, and you will blame the cache instead of the key.
  5. Two implementation details worth volunteering: decide 'is it done' by checking the artifacts on disk, not the state file, because files get deleted by hand; and think about granularity — four shots in one node means one failed shot redoes all four, while finer granularity saves money at the cost of a much larger graph.
  6. Expect the follow-up 'does hashing dependency keys over-invalidate'. Yes. An upstream wording change that produces an identical artifact still invalidates downstream. Hashing the dependency's artifact content instead is tighter but requires reading the artifact every time — worth it for small files, not for large videos.

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

  1. 这题的区分度全在「不该放什么」那一半。只答「把输入哈希一下」的人，通常没在真实项目里被缓存坑过——缓存的两种病方向相反，一种是永远不命中，一种是命中了不该命中的。
  2. 先给判据：键里应该出现的，是所有会改变产物的东西；不该出现的，是所有每次都会变但不影响产物的东西。这一条能直接推出下面两张清单。
  3. 该放的四样：节点标识、实现版本号、本节点的输入（模型 id、提示词、时长、分辨率）、以及全部依赖的指纹。版本号和依赖指纹是最容易漏的两样——漏了版本号，改完代码读到旧产物；漏了依赖指纹，上游换了剧本你还在用旧的镜头。
  4. 不该放的：运行标识、时间戳、随机数、绝对路径、以及任何带机器名或临时目录的东西。放进去等于每次都是新键，你会以为缓存写坏了，其实是键设计错了。
  5. 还有两条落地细节值得主动说：判断「做没做完」要看磁盘上产物齐不齐，不能只信状态文件，因为文件可能被手删；以及幂等的粒度要想清楚，一个节点里跑四个镜头，第三镜失败就是四镜全重做，粒度更细更省钱但任务图会大很多。
  6. 可预期的追问是「依赖指纹会不会失效得太狠」。答：会。上游只是文案改了、产物其实一样，下游也会跟着重做。更省的做法是对依赖的产物内容做哈希而不是对它的键做哈希，代价是每次都要把产物读一遍——小文件划算，大视频不划算，这是要自己量的一笔账。

  Key points

  • One criterion: include what changes the artifact, exclude what changes every run without affecting it.
  • Must include: node id, implementation version, the node's own inputs, and all dependency fingerprints.
  • Must exclude: run id, timestamps, random values, absolute paths and host-specific data.
  • Decide cache hits by checking artifacts on disk, not by trusting the state file.
  • Choose the idempotency granularity explicitly: per node is simpler, per shot saves more but grows the graph.

  答题要点

  • 判据一句话：会改变产物的进键，每次都变但不影响产物的不进键。
  • 必放四样：节点标识、实现版本号、本节点输入、全部依赖的指纹。
  • 禁放：运行标识、时间戳、随机数、绝对路径与机器相关信息。
  • 命中判定看磁盘上产物是否齐全，不能只信状态文件。
  • 幂等粒度要显式选择：节点粒度实现简单，镜头粒度更省钱但图更大。