面试题库

14 天 RAG：从检索到可信回答

D1 为什么要检索：幻觉、知识截止与长上下文的代价，以及一个纯关键词的最小 RAG

• 上下文窗口已经做到上百万 token 了，检索这一步会被淘汰吗？Context windows are now in the millions of tokens. Does that make the retrieval step obsolete?

  国内高频海外高频深入#long-context#cost#system-design

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

  1. 这是一道立场题，容易答成非黑即白。判断你有没有做过的地方在于：会不会区分「技术上能不能塞进去」和「工程上该不该每次都塞」，只谈前者的答案一听就是纸上谈兵。
  2. 先承认对方有道理的部分：窗口变大确实吃掉了检索的一部分场景。几十篇文档、更新不频繁、调用量不大的内部工具，直接全塞是最省事的选择，为它建一套检索系统是过度设计。
  3. 再给三条它吃不掉的理由。第一是成本：材料是按次计费的，同一份材料被问一万次就要付一万次，而检索只付取回的那几段；预填充缓存能缓解但不能消除，缓存也有有效期和命中率。
  4. 第二是规模：企业知识库动辄几十万篇，再大的窗口也塞不下，检索是唯一的入口。第三是归因与权限：答案要指回具体某一段，以及不同的人只能看到自己有权访问的材料——这两件事必须在把材料喂给模型之前完成，窗口再大也不解决。
  5. 还要补一条经验事实：材料变多之后，模型在长上下文里定位关键信息的稳定性会下降，出现「读了但没读到」。所以「全塞」并不总是等于「效果更好」，很多时候少而准反而更好。
  6. 可预期的追问：那检索的形态会不会变？会——窗口变大之后，取回的块可以更大、条数可以更多，重排与压缩的压力变小，检索从「精挑几句」变成「粗筛一批」。趋势是检索的粒度变粗，不是检索消失。

  How to reason about it · think before answering

  1. This is a position question and it is easy to answer as a binary. The signal is whether you separate what fits technically from what is worth paying for on every request.
  2. Concede the valid half first: bigger windows genuinely absorb part of the use case. For an internal tool over a few dozen stable documents with low traffic, stuffing everything in is the right call and building a retrieval stack would be over-engineering.
  3. Then give three reasons it does not absorb the rest. Cost is the first: context is billed per request, so the same corpus is paid for on every one of ten thousand queries, whereas retrieval only pays for the passages it returns. Prompt caching softens this but does not remove it.
  4. Scale is the second: enterprise corpora run to hundreds of thousands of documents and no window holds them. Attribution and access control are the third: pointing an answer at a specific passage, and showing each user only what they are permitted to see, both have to happen before the material reaches the model.
  5. Add the empirical point: as the supplied material grows, models become less reliable at locating the one relevant fact inside it. More context is not automatically better; fewer and more precise passages often win.
  6. Expected follow-up: does retrieval change shape? Yes. Larger windows allow bigger chunks and more of them, which relieves pressure on reranking and compression. Retrieval gets coarser, it does not disappear.

  答题要点

  • 先区分「能不能塞进去」和「该不该每次都塞」，前者是技术问题，后者是成本问题。
  • 小规模、低频、少变的语料确实可以直接全塞，为它建检索系统是过度设计。
  • 检索不会被淘汰的三个理由：按次计费的成本、几十万篇塞不下的规模、必须在喂给模型之前完成的归因与权限过滤。
  • 材料越多，模型定位关键信息的稳定性越差，全塞不等于效果更好。
  • 趋势是检索粒度变粗——块更大、条数更多、重排压力变小，而不是检索消失。

  Key points

  • Separate whether it fits from whether it is worth paying for on every request.
  • Small, stable, low-traffic corpora can legitimately be stuffed whole; building retrieval for them is over-engineering.
  • Three reasons retrieval survives: per-request cost, corpora too large for any window, and attribution plus access control that must happen before the model sees the material.
  • More supplied context reduces the reliability of locating a single fact, so stuffing everything is not automatically better.
  • The trend is coarser retrieval — bigger chunks, more of them, less reranking pressure — not the removal of retrieval.

D2 embedding 与向量检索：相似度、维度与模型选型，把文本存进 pgvector

• 把 embedding 维度从 1536 降到 512，你会损失什么？什么场景下这个损失可以接受？What do you lose when you cut embedding dimensions from 1536 to 512, and when is that loss acceptable?

  国内高频海外高频进阶#embeddings#dimensions#cost

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

  1. 这题考的是你会不会算账。只说「维度越低越省、精度越低」的答案没有区分度，面试官在等一个具体的成本模型和一个决策顺序。
  2. 先把三笔账列出来：存储与内存（向量数量乘维度乘每维字节数，近似最近邻索引要把它放进内存，所以基本等于机器预算）、检索延迟（每次比较就是一轮乘加，维度大致线性影响耗时）、检索质量（收益递减，低维段每加一档提升明显，高维段加倍只换来很小的改善）。
  3. 再说清降维为什么可行：主流模型用套娃式表示训练，重要信息压在靠前的维度上，所以直接截短再归一化仍然可用，这不是另训了一个小模型。截短必然有损失，损失多少只能在自己的数据上跑评估才知道。
  4. 给出决策顺序：先按存储与内存预算倒推一个维度上限，再从上限往下试两三档，看指标掉多少，掉得能接受就用低的。反过来「先选最高维再想办法省钱」基本都会返工。
  5. 点出可接受的典型场景：库很大而单条价值不高（比如日志、工单）、召回之后还有重排兜底（重排能把粗排的损失补回来一部分）、或者对延迟极敏感的在线场景。反过来法务、医疗这类一条都不能漏的场景就要谨慎。
  6. 可预期的追问：能不能不同文档用不同维度？不能——同一个索引里所有向量必须同维，改维度等于全库重建，这跟换模型是同一类迁移成本。

  How to reason about it · think before answering

  1. This is a cost-modelling question. 'Lower dimensions are cheaper but less accurate' earns nothing; the interviewer wants a cost model and a decision order.
  2. Lay out three costs: storage and memory (vector count times dimensions times bytes per dimension, which an ANN index must hold in RAM), query latency (roughly linear in dimensions), and retrieval quality, whose returns diminish sharply at the high end.
  3. Explain why truncation works at all: models trained with Matryoshka representations pack the most important information into the leading dimensions, so truncating and re-normalising keeps the vector usable. It is still lossy, and how lossy is an empirical question on your own data.
  4. Give the decision order: derive a dimension ceiling from your memory budget, then step down two or three notches and measure the metric drop. Choosing the largest model first and optimising cost later usually means redoing the work.
  5. Name the acceptable cases: large corpora of low individual value, pipelines where a reranker recovers some of the loss, and latency-critical online paths. Be conservative where a single miss is expensive, such as legal or clinical retrieval.
  6. Expected follow-up: can different documents use different dimensions? No. Every vector in an index must share one dimension, so changing it means rebuilding the whole index, the same migration cost as changing models.

  答题要点

  • 三笔账：存储与索引内存、检索延迟、检索质量，前两笔随维度近似线性，第三笔收益递减。
  • 套娃式表示让截短再归一化仍然可用，但一定有损失，损失多少要在自己的数据上评估。
  • 决策顺序是先按内存预算定上限，再往下试档位看指标掉多少。
  • 库大、单条价值低、后面还有重排兜底、对延迟敏感的场景，降维划算。
  • 同一索引里维度必须一致，改维度等于全库重建。

  Key points

  • Three costs: storage and index memory, query latency, and retrieval quality; the first two scale with dimensions, the third has diminishing returns.
  • Matryoshka representations make truncation viable, but it is lossy and the loss must be measured on your own data.
  • Decide by deriving a ceiling from the memory budget, then stepping down and measuring.
  • Truncation pays off for large corpora, low-value items, latency-sensitive paths, and pipelines with a reranker.
  • All vectors in one index share a dimension, so changing it forces a full rebuild.

D4 切块策略：固定、递归、按结构、父子与语义五种切法，以及用评估而不是直觉来选

• 语义切分比递归切分贵不少，你怎么向团队证明这笔钱值得花？Semantic chunking costs considerably more than recursive splitting. How would you prove to your team that the money is well spent?

  国内高频海外高频深入#chunking#evaluation#cost

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

  1. 这题表面问技术，实际考的是你会不会做一次带对照组的技术论证。上来就讲语义切分原理的人，答的是另一道题。
  2. 第一步是先承认它可能不值。语义切分的收益来自「文档没有可用的结构」；如果知识库是结构良好的文档，作者的标题层级已经免费替你做完了语义切分，这时候花的钱大概率打水漂。**先说清适用前提，再谈证明，这一步就把大多数候选人区分开了。**
  3. 第二步是把「值不值」翻译成可测的三笔账：指标涨了多少（同一批标准问题、同一个 token 预算下的命中率）、延迟涨了多少（切块是离线的，但更新链路的端到端时间会变）、钱涨了多少（首次全量 embedding 的费用，加上按更新频率折算的重算费用）。只报第一笔的论证不成立。
  4. 第三步是设计对照。递归切分是基线，语义切分是实验组，两组必须用同一份语料、同一批问题、同一个上下文预算、同一个检索器，只改切法这一个变量。改两个变量的实验，结论一文不值。
  5. 第四步是给决策一个门槛，而不是给一个感想。比如：命中率相对基线提升低于三个百分点就不上；提升超过五个百分点且重算成本在月度预算内就上；中间地带先在一类文档上灰度。**门槛要在跑数字之前定好**，否则你会不自觉地去迁就已经跑出来的结果。
  6. 可预期的追问是「有没有更便宜的办法拿到同样的收益」。答有：先试按结构切，它零成本且效果常常接近；结构确实不可用时，再考虑只对高价值的那一部分文档做语义切分，而不是全量上。

  How to reason about it · think before answering

  1. This looks like a technical question but it tests whether you can run a controlled technical argument. Launching into how semantic chunking works answers a different question.
  2. Step one is to concede that it may well not be worth it. The gain comes from documents that have no usable structure; if your knowledge base is well-formed documents, the authors' heading hierarchy already did the semantic split for free and the money is likely wasted.
  3. Step two is translating 'worth it' into three measurable numbers: how much the metric moved (hit rate on the same golden set under the same token budget), how much latency moved (chunking is offline, but the end-to-end update path changes), and how much it costs (the initial full embedding pass plus recomputation amortised over update frequency).
  4. Step three is the control. Recursive splitting is the baseline, semantic chunking the treatment, and they must share the corpus, the questions, the context budget and the retriever. Change one variable only; a two-variable experiment proves nothing.
  5. Step four is a decision threshold rather than an impression. For example: below three points of hit-rate gain, no; above five points with recomputation inside the monthly budget, yes; in between, roll it out on one document class first. Fix the threshold before you run the numbers, or you will quietly bend it to fit them.
  6. Expect the follow-up: is there a cheaper way to the same gain. Yes — try structural splitting first, since it is free and often nearly as good, and if the structure really is unusable, apply semantic chunking only to the high-value subset rather than the whole corpus.

  答题要点

  • 先讲适用前提：语义切分的收益来自文档没有可用结构，结构良好的文档上它大概率不值。
  • 把「值不值」翻译成三笔账：命中率涨多少、延迟涨多少、钱涨多少，只报第一笔不算论证。
  • 做对照实验：同语料、同问题集、同上下文预算、同检索器，只改切法一个变量。
  • 决策门槛必须在跑数字之前定好，避免事后迁就结果。
  • 先试零成本的按结构切；确需语义切分时也优先只覆盖高价值文档，而不是全量上。

  Key points

  • Start with the precondition: the gain comes from documents without usable structure, so on well-formed documents it usually is not worth it.
  • Translate 'worth it' into three numbers — hit rate, latency, and cost. Reporting only the first is not an argument.
  • Run a controlled comparison: same corpus, same golden set, same context budget, same retriever, with the splitting strategy as the only variable.
  • Fix the decision threshold before running the numbers so you cannot bend it to fit the result afterwards.
  • Try free structural splitting first, and if semantic chunking is genuinely needed, apply it to the high-value subset rather than the entire corpus.