Interview Bank

RAG in 14 Days: From Retrieval to Trustworthy Answers

D1 Why Retrieve at All: Hallucination, Knowledge Cutoffs, and the Cost of Long Context; a Minimal Keyword-Only RAG

• When should you use retrieval-augmented generation, when should you fine-tune, and when is stuffing the documents into the context window good enough?什么时候该用检索增强生成，什么时候该微调，什么时候直接把文档塞进上下文就够了？

  Common in ChinaCommon overseasBasic#rag-basics#fine-tuning#long-context

  How to reason about it · think before answering

  1. This question shows up in almost every loop. The differentiator is not reciting three definitions, it is offering a decision rule the interviewer can reuse.
  2. Lead with the rule: is the model missing knowledge, or missing a way of speaking? Missing knowledge means retrieval; missing style or output shape means fine-tuning. That single cut covers most cases.
  3. Then line up the three options against three costs: cost of updating knowledge, cost per request, and whether the answer can be traced back to a source. Retrieval updates by editing a file, fine-tuning takes a retraining cycle, and long-context pays for the whole corpus on every call.
  4. Give long-context its fair case: when the corpus is small, changes rarely, and request volume is low, stuffing it in is the cheapest engineering decision you can make. It stops being cheap once the corpus grows or the same material is queried thousands of times a day.
  5. Close by naming when none of this applies: if the answer does not depend on any external document (rewriting, translating, reformatting), retrieval only adds noise, latency and cost.
  6. Expected follow-up: can you do both? Yes, and it is common. Fine-tuning controls format and refusal behaviour, retrieval supplies the facts.

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

  1. 这题几乎每场都问，区分度不在能不能背出三条定义，而在你会不会给一条判据。只说「RAG 适合动态知识、微调适合特定风格」的人一抓一大把，面试官等的是下一句。
  2. 先给一条能当场套用的判据：模型缺的是「知道什么」还是「怎么说」。缺知识走检索，缺风格与输出格式走微调，这一刀切下去能分掉八成场景。
  3. 再拿三笔账把三条路排开：知识更新的代价（改文件立刻生效 / 重训以天计 / 改文件立刻生效）、单次成本（只付取回的几段 / 只付推理 / 每次都付全量材料）、能不能归因（能 / 不能 / 能但材料一多定位会飘）。
  4. 把上下文直塞的适用边界说清楚：材料总量小、更新不频繁、对单次成本不敏感的场景它最划算，因为工程量近乎为零。一旦材料涨到几百篇，或者同一批材料每天要被问上万次，成本曲线立刻反超。
  5. 最后主动补一句「什么时候都不该用检索」——任务的答案不依赖任何外部文档时（改写、翻译、格式转换），加检索只会引入噪声、延迟和成本。能主动划出不该用的边界，比会背适用场景更能证明你做过。
  6. 可预期的追问：能不能既微调又检索？答案是可以，而且常见——微调管输出格式与拒答口径，检索管事实，两者解决的不是同一个问题。

  Key points

  • One rule: retrieval for missing knowledge, fine-tuning for a missing way of speaking.
  • Retrieval updates instantly by editing files, supports citation, and costs scale with the retrieved passages rather than the corpus.
  • Fine-tuning is good at locking in style and output schema, poor at loading facts, and offers no traceability.
  • Long-context stuffing wins when the corpus is small, stable and queried infrequently; it loses on cost and on locating facts once the corpus grows.
  • If the answer does not depend on any document, use none of them.

  答题要点

  • 一条判据：缺「知道什么」用检索，缺「怎么说」用微调。
  • 检索改文件即时生效、可归因、成本只跟取回的几段有关，代价是要自己建一套会出错的检索系统。
  • 微调擅长固化风格与输出格式，不擅长灌事实：数据一变就要重训，而且没法归因。
  • 长上下文直塞在小型、低频、少变的语料上最划算，材料变多或调用量变大之后成本与定位稳定性都会恶化。
  • 任务答案不依赖外部文档时三条路都不该用，直接调模型。

D2 Embeddings and Vector Search: Similarity, Dimensionality, and Model Choice; Storing Text in pgvector

• When are cosine similarity and inner product equivalent? What goes wrong if you rank by inner product on vectors that are not normalised?余弦相似度和内积什么时候等价？如果向量没有归一化，用内积排序会出什么问题？

  Common in ChinaCommon overseasBasic#embeddings#similarity#normalisation

  How to reason about it · think before answering

  1. This starts as a giveaway, but the second half is where candidates separate. Many can say 'they are equivalent after normalisation'; few can describe what breaks without it.
  2. State the definition: cosine similarity is the inner product divided by the product of the two magnitudes. When both magnitudes are 1, the divisor is 1 and cosine reduces to the inner product. That is the whole argument.
  3. Then the failure mode: an un-normalised inner product mixes 'how aligned' with 'how long'. Longer texts tend to produce larger-magnitude vectors, so ranking drifts systematically toward long documents, the same bias BM25's b parameter exists to counter.
  4. Stress that this bug is silent. Nothing throws, results still look plausible, and only an offline evaluation reveals the drift. Hence the engineering rule: normalise once at the embedding boundary, never at each call site.
  5. Add Euclidean distance for completeness: on normalised vectors, squared L2 equals 2 minus twice the inner product, a monotone function of cosine distance, so all three metrics produce the same ranking.
  6. Expected follow-up: which pgvector operator should you use? Since the vectors are normalised, `<=>` and `<#>` rank identically; prefer `<=>` for readability and because it stays correct if someone later forgets to normalise.

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

  1. 这题是送分题，但区分度藏在后半句。只答「归一化之后两者等价」的人很多，面试官真正想听的是「没归一化会怎么坏」，因为那是线上真的会发生的事。
  2. 先把定义摆出来：余弦相似度等于内积除以两个向量模长的乘积。模长都是 1 时除数就是 1，所以余弦相似度就是内积——这一句话就是等价的全部理由，不需要额外的假设。
  3. 再说没归一化的后果：内积里混着「方向有多一致」和「向量有多长」两层信息。文本越长，模型输出的向量模长往往越大，于是排序会系统性地偏向长文档——这跟 BM25 里 b 参数要压的是同一个毛病，只是换了个地方冒出来。
  4. 点出这类 bug 的性质：它不报错。程序照常跑、结果照常出，只是名次悄悄偏了，你要跑一轮离线评估才可能发现。所以工程上的做法是在 embedding 的出口统一归一化一次，而不是靠每个调用点自觉。
  5. 补一句欧氏距离：向量都归一化之后，欧氏距离的平方等于 2 减去 2 倍内积，也就是余弦距离的单调函数，三种距离排出来的名次完全一致。这一句能说明你理解的是关系而不是三条并列的规则。
  6. 可预期的追问：那 pgvector 里该用哪个运算符？答案是既然已经归一化，`<=>`（余弦距离）和 `<#>`（负内积）名次一样，选 `<=>` 的理由是可读性和「就算哪天有人漏了归一化也不至于错」。

  Key points

  • Cosine equals inner product divided by both magnitudes; with unit magnitudes the divisor is 1, so they coincide.
  • Without normalisation the inner product carries magnitude, and longer documents usually have larger magnitudes, biasing the ranking.
  • The failure is silent, so normalise once at the embedding boundary and verify with offline evaluation.
  • On normalised vectors L2 and cosine are monotonically related, so all operators rank the same.
  • In pgvector the operators are `<->` for L2, `<#>` for negative inner product and `<=>` for cosine distance.

  答题要点

  • 余弦相似度 = 内积 / 两个模长之积，模长为 1 时除数为 1，两者等价。
  • 没归一化时内积混入模长信息，长文档的向量模长普遍更大，排序会系统性偏向长文档。
  • 这类错误不报错，只能靠离线评估发现，所以要在 embed 出口统一归一化。
  • 归一化之后欧氏距离与余弦距离互为单调函数，三种运算符名次一致。
  • pgvector 里对应 `<->`（L2）、`<#>`（负内积）、`<=>`（余弦距离）三个运算符。

D3 Getting Documents In: Parsing PDF and HTML, Tables and Scans, Cleaning Rules, and Metadata You Must Keep

• Why is parsing quality the ceiling on retrieval quality? Walk through one concrete chain of propagation.为什么说解析质量决定了检索质量的上限？举一个具体的传导链条。

  Common in ChinaCommon overseasBasic#ingestion#data-quality#failure-analysis

  How to reason about it · think before answering

  1. This is a giveaway question that many people answer with a slogan. The only test is whether you produce a chain that lands on a concrete symptom instead of repeating garbage in, garbage out.
  2. Place it first: parsing sits before chunking, indexing, retrieval, context assembly and generation. Its errors are amplified by every later stage, and none of those stages can detect the problem because each is faithfully processing text that is already wrong.
  3. Give the chain: a pricing table in a PDF loses one column separator and comes out with cells shifted. Chunking splits on those wrong boundaries, so a plan name ends up next to the neighbouring column value. The index records the wrong term pairing. A user asks about that plan's storage quota, the corrupted chunk scores highest, and the model, faithfully answering only from the provided material, returns a wrong answer carrying a correct-looking citation.
  4. Name the nastiest part: nothing on that chain raises an error, and the answer even comes with a source, so it looks more trustworthy than usual. Parsing errors cannot be caught after the fact, only by assertions at ingest.
  5. Explain the word ceiling: every later optimisation, dense retrieval, hybrid search, reranking, query rewriting, improves how well you pick from the candidates. If the material itself is wrong, picking better still returns something wrong, so parsing caps all of them.
  6. Expected follow-up: how do you prove parsing is at fault? Reuse the habit from day one. Diagnose right to left and print the retrieved passages verbatim. If the source text is already scrambled, there is no point looking at the generation side.

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

  1. 这是一道送分题，但很多人答成口号。判据只有一个：有没有给出一条能落到具体现象上的链条，而不是重复一遍「垃圾进垃圾出」。
  2. 先说清位置：解析在切块、建索引、检索、组装、生成这五环之前，是第零环。它的错误会被后面每一环放大，而且后面每一环都无法察觉——它们只是在忠实地处理一段已经错了的文字。
  3. 给一条具体链条：一张套餐配额表在 PDF 里丢了一列分隔符，抽出来串了行；切块照着错误的边界切，「专业版」和隔壁那一栏的值被切进同一块；索引把错误的词对记进倒排表；用户问「专业版存储配额多少」，这一块分数很高被排到第一；模型只依据给定材料回答，于是给出一个错误但带着正确引用编号的答案。
  4. 点破最要命的一句：这条链上没有任何一环会报错，回答甚至是带出处的，看起来比平时更可信。所以解析的错误不能靠事后发现，只能靠入口处的断言拦。
  5. 反过来说明「上限」二字：后面所有优化——向量、混合检索、重排、查询改写——优化的都是「从候选里挑得更准」。材料本身错了，挑得再准也是错的，所以它们的天花板由解析封死。
  6. 可预期的追问：那怎么证明是解析的锅？答案接回 D1 那条习惯——排查从右往左看，把检索出来的原文打印出来自己读一遍，如果原文本身就是串行的，那就不用再往生成侧查了。

  Key points

  • Parsing is stage zero, before the five-stage pipeline; its errors are amplified downstream and invisible to every later stage.
  • Concrete chain: a shifted table, chunking on wrong boundaries, wrong term pairs in the index, that chunk ranked first, and a wrong answer delivered with a citation.
  • The dangerous part is that nothing errors out and the answer carries a source, so it looks more credible than usual.
  • Later techniques only improve selection from candidates; if the material is wrong, better selection still returns something wrong.
  • Diagnose right to left: print the retrieved passages first, and if the source text is already broken, stop looking at the generation side.

  答题要点

  • 解析是五个环节之前的第零环，它的错误会被后面每一环放大，而后面每一环都察觉不到。
  • 具体链条：表格串行 → 切块按错误边界切 → 倒排表记进错误词对 → 检索把它排第一 → 模型据此给出带引用的错误答案。
  • 最危险的是全程零报错，且答案带着出处，看起来比平时更可信。
  • 后面所有优化解决的是「挑得更准」，材料本身错了就都无效，所以上限由解析封死。
  • 定位方法是排查从右往左：先把检索到的原文打印出来读一遍，原文错了就不必再查生成侧。

D4 Chunking Strategies: Five Approaches — Fixed, Recursive, Structure-Based, Parent-Child, and Semantic — and Choosing by Evaluation, Not Intuition

• What overlap ratio would you use, and what concretely goes wrong when the overlap is too large?重叠区设成块长的百分之多少合适？重叠过大会带来什么具体问题？

  Common in ChinaCommon overseasBasic#chunking#overlap

  How to reason about it · think before answering

  1. This is a giveaway question, but the marks are in the second half, not the percentage. Stopping at 'usually ten to twenty percent' reads like someone who has never run it.
  2. Say what overlap is patching: fixed-length splitting cuts sentences in half, and overlap guarantees the broken sentence survives intact in at least one of the two neighbours. It is a patch for careless splitting, not an optimisation of its own.
  3. That yields the first conclusion: with structural or recursive splitting the boundaries already land on semantic positions, so the need for overlap drops sharply and can legitimately be zero. The ratio question is meaningless without naming the strategy.
  4. Give three concrete costs. Storage and tokens: at 400-character chunks, moving overlap from 0 to 80 grows total index tokens by roughly fifteen percent, which is storage cost in the vector store and comparison work at query time.
  5. Retrieval redundancy: the more neighbours overlap, the more likely the top results are three versions of the same passage. You think you handed the model three pieces of evidence; you handed it one, three times. Nothing fixes this before reranking.
  6. Citation resolution: when a sentence lives in two chunks, which one does the model cite. Expect the follow-up on deduplication: merge at the result layer using a content fingerprint or longest common substring, not by tweaking the chunker.

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

  1. 这是一道送分题，但送分点不在那个百分比上，而在后半句。只答「一般一到两成」就停住的人，面试官会认为他没跑过。
  2. 先说清重叠在补救什么：固定长度切法会把句子从中间切开，重叠让被切开的那句话至少在相邻两块之一里是完整的。它是给「乱切」打的补丁，不是一个独立的优化。
  3. 由此推出第一个结论：如果你用的是按结构切或递归切，边界本来就落在语义位置上，重叠的必要性会大幅下降，甚至可以是零。**重叠比例这个问题的前提是切法**，脱开切法谈比例就是背数字。
  4. 过大的代价要说三笔，越具体越好。存储与 token：块长 400、重叠从 0 加到 80，索引 token 会涨一成半左右，这笔钱在向量库是存储费、在检索时是比对量。
  5. 检索冗余：相邻块越像，前几名越可能是同一段话的三个版本，你以为给了模型三条证据，其实是一条说了三遍。这一条在重排之前基本无解。
  6. 引用定位：同一句话出现在两个块里，模型标出处该标哪一个，这会直接变成引用校验环节要处理的边界情况。可预期的追问就是「那你怎么去重」，答按内容指纹或最长公共子串在结果层合并，而不是在切块层想办法。

  Key points

  • Ten to twenty percent of chunk length is the working range, but that number assumes fixed-length splitting.
  • With structural or recursive splitting the boundaries are already semantic, so overlap can be small or zero.
  • Cost one: index tokens and storage grow noticeably; at 400-character chunks, an 80-character overlap adds roughly fifteen percent.
  • Cost two: neighbouring chunks become near-duplicates, so the top results are several versions of one passage and the evidence diversity is illusory.
  • Cost three: a sentence spanning two chunks complicates citation attribution and forces result-level deduplication.

  答题要点

  • 经验区间是块长的一到两成，但这个数字的前提是你用的是固定长度切法。
  • 按结构或递归切时边界本来就在语义位置上，重叠可以很小甚至为零。
  • 过大代价一：索引 token 与存储明显上涨，块长 400 时重叠加到 80 大约涨一成半。
  • 过大代价二：相邻块高度相似，检索前几名变成同一段话的多个版本，证据多样性是假的。
  • 过大代价三：同一句话跨块出现，引用标注和去重都要额外处理。

D6 The Generation Side: Ordering Context, Labeling Citations, When You Must Refuse to Answer, and Streaming Responses

• Does the ordering of retrieved passages in the context affect answer quality? If so, how would you order them?上下文里材料的排列顺序会影响回答质量吗？如果会，你会怎么排？

  Common in ChinaCommon overseasBasic#context-assembly#prompt-engineering#ordering

  How to reason about it · think before answering

  1. This is a warm-up question, but 'sort by relevance descending' only earns half the credit. The interviewer wants to know whether you treat position itself as a variable.
  2. State the conclusion first: it does matter. Models attend more reliably to material at the start and the end of the context, and are most likely to miss what sits in the middle. Plain descending order therefore parks your second-best passage in the worst spot.
  3. Give the ordering: rank one first, rank two last, rank three second, rank four second-to-last, folding inward. Whatever ends up in the middle is by construction the least important, so the cost of it being skipped is smallest.
  4. Round it out with the other assembly steps, which shows you have written this code: a deterministic tiebreaker (otherwise block numbers drift between runs and your logs stop matching), dedupe on normalised text, and a token budget that skips rather than stops when a block does not fit.
  5. Expected follow-up: how would you verify this? Do not guess. Hold the question set fixed, vary only the ordering, and measure. Position effects differ by model and context length, so treat it as a parameter to measure on your own data rather than a universal law.

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

  1. 这是一道送分题，但答成「按相关性从高到低排」就只拿到一半分。面试官想听的是你知不知道位置本身是个变量。
  2. 结论先说：会影响。模型对上下文开头和结尾的材料明显更敏感，正中间的最容易被读漏。所以简单按分数从高到低顺排，等于把第二重要的材料放进了最不容易被读到的位置。
  3. 给出排法：第 1 名放开头、第 2 名放结尾、第 3 名放第二位、第 4 名放倒数第二位，依次往里收。这样按分数排下来越靠中间的块本来就越不重要，被读漏的代价最小。
  4. 顺带把排序之外的三道手续说全，显得你真的写过这段代码：同分要有决胜键（否则块编号会在两次运行之间飘，日志对不上）、要按归一化文本去重（同一段话常在手册和问答里各出现一次）、要有 token 预算并且塞不下时不要直接停。
  5. 可预期的追问：这个结论怎么验证？答案是别猜——固定一批问题，只改排列顺序跑对照，看指标差多少。位置效应在不同模型、不同上下文长度上强弱不一样，把它当成一个要在自己数据上量的参数，而不是一条普适定律。

  Key points

  • Yes: material at the head and tail is used more reliably, the middle is most often skipped.
  • Put the strongest at both ends: rank one first, rank two last, rank three second, folding inward.
  • Assembly also needs a deterministic tiebreaker for stable numbering, dedupe on normalised text, and a token budget that skips oversized blocks instead of stopping.
  • The strength of the effect varies by model and context length, so measure it on your own data instead of quoting it as a law.

  答题要点

  • 会影响：开头和结尾的材料更容易被用上，正中间的最容易被读漏。
  • 排法是最重要的放两端：第 1 名开头、第 2 名结尾、第 3 名第二位，依次往里收。
  • 组装还要做三件事：同分给决胜键保证编号稳定、按归一化文本去重、控 token 预算且塞不下时跳过而不是终止。
  • 位置效应的强弱因模型与上下文长度而异，要在自己的数据上做对照实验量出来，不能当普适定律照搬。

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

• How would you draw the module boundaries of a RAG system, and which layer most needs to be swappable? Why?你会怎么划分一个检索增强生成系统的模块边界？其中哪一层最应该做成可替换的，为什么？

  Common in ChinaCommon overseasBasic#architecture#modularity#embeddings

  How to reason about it · think before answering

  1. This question separates people who have maintained such a system from people who have only built a demo. Reciting the pipeline diagram is not an answer; where you cut it is.
  2. Offer a reusable criterion first: cut where a layer is most likely to be replaced wholesale, not by lines of code or by tidy functional names.
  3. Apply it. Embedding models change several times a year, and each change invalidates every stored vector, so that layer must be an interface. Storage may move from PostgreSQL to a dedicated vector database, and both ingestion and query talk through it, so it is the single shared boundary. Chunking changes daily during tuning, so it belongs in config, not in code.
  4. Conclusion: the embedding layer is the one that must be swappable, because the swap is both likely and expensive, not because interfaces are good style.
  5. Name the cost of abstraction too: every indirection is one more hop while debugging, so the test is whether the change will actually happen.
  6. Expected follow-up: should the generation model be abstracted as well? Yes, but at lower priority, because swapping it does not force recomputation of stored data and rollback is cheap. It is a config value, not a layer.

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

  1. 这题考的是你有没有真的维护过这类系统。只按「解析、切块、检索、生成」复述一遍流程图，面试官会判定你只搭过 demo——流程图人人都会画，切口画在哪才是经验。
  2. 给一条可复用的判据再往下推：切口应该落在「将来最可能被整个换掉」的地方，而不是按代码量或者功能名称均分。
  3. 用它过一遍：embedding 一年会换好几次，换一次库里所有向量作废、必须全量重算，所以它必须是接口；存储可能从 PostgreSQL 换成专用向量库，而且摄取和查询都要通过它，所以它是两条链路的唯一交界；切块策略在调优期天天改，所以它必须是配置项而不是硬编码。
  4. 结论：最该做成可替换的是 embedding 那一层，理由不是「设计模式」，而是「换模型这件事真的会发生，且发生时代价极高」。
  5. 顺手点出抽象的代价：每多一层间接就多一次跳转和一份心智负担，所以判据是「那件事会不会真的发生」，不会发生的别抽象。
  6. 可预期的追问：那生成模型要不要也抽象？答案是要，但优先级低——换生成模型不需要重算任何存量数据，回滚也便宜，所以它是配置项而不是一层接口。

  Key points

  • Lead with the criterion: cut where a layer is most likely to be replaced wholesale.
  • The embedding layer is the one to abstract: swapping models invalidates every stored vector and forces a full recompute.
  • Storage is the single boundary shared by ingestion and query, so define its interface before either implementation.
  • Chunking and retrieval routes belong in configuration because they change most often during tuning.
  • Abstraction costs indirection, so only abstract changes that will actually happen.

  答题要点

  • 先给判据：切口落在最可能被整体替换的那一层，不按代码量或功能名称均分。
  • embedding 是最该抽象的一层：换模型意味着存量向量全部作废、必须全量重算，代价高且真的会发生。
  • 存储层是摄取与查询唯一的交界，接口要先定下来再谈两边实现。
  • 切块与检索路数做成配置项，因为它们在调优期改动最频繁，改一次不该动代码。
  • 抽象有成本，判据是那件事会不会真的发生；不会发生的抽象就是过度设计。