面试题库

30 天从前端工程师到 Agent 工程师

D24 RAG 进阶：hybrid search、rerank、引用、recall 评估

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

  国内高频海外高频基础#rag#hybrid-search#retrieval

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

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

  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.

  答题要点

  • 向量检索比的是语义距离，强在同义改写，弱在型号、错误码、订单号这类没有语义的字符串。
  • BM25 强在低频稀有词的字面命中，弱在同义改写——两者的盲区由各自的计算原理决定，不重叠。
  • 所以第一轮开两路、各取 20 条，用 RRF 融合，把两边的盲区互相补上。
  • 举实测例子：E4032 那条 query 向量 top5 漏掉正确文档，关键词 top1 就是它；「邮费」那条反过来只有向量能召回。
  • 中文关键词那一路要处理分词，最简兜底是 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.
• 两路检索结果怎么合并？为什么不能直接加权求和？How do you merge two retrieval rankings, and why not just take a weighted sum of the scores?

  国内高频海外高频进阶#rag#rrf#ranking

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

  1. 题眼在后半句。前半句答「RRF」谁都会，后半句「为什么不能加权求和」才是筛人的地方——它考的是你有没有真的看过两路分数的分布。
  2. 怎么拆：先问自己两个分数是不是同一个量纲。余弦相似度有界（0 到 1）且分布密集，同一批候选常常只差 0.02；BM25 无上界，命中几个稀有词就能到 12 分。**不同量纲的数相加，等于让量纲大的那一路单方面决定结果**，权重只是在调「它说了算的程度」。
  3. 更麻烦的是它不稳定：权重在这批语料上调好了，换一批语料分布就变了，得重调。这是一个永远还不完的技术债。
  4. 结论：改用名次。RRF 把每一路的名次折算成 `1/(k + rank)` 再相加，k 取 60。名次是无量纲的，不需要任何标定。k 的作用是压平头部差距，让「两路都进前列」压过「一路排第一」——共识优先于单点自信。
  5. 一个能当场手算的例子很加分：两路排名 [a,b,c] 与 [c,d,a]，a 得 1/61 + 1/63 ≈ 0.0323；而分数直接相加的版本会把 BM25 里 12 分的 c 顶到第一。
  6. 可预期的追问：同分了怎么办？必须显式定序（比如按 id），否则结果取决于哈希表遍历顺序，同一份输入在不同语言、不同运行里给出不同排序——评估集量出来的数字也就不可复现了。这一条答出来会非常加分，因为它说明你真的跑过多次。

  How to reason about it · think before answering

  1. The second half is the real question. Anyone can say 'RRF'; explaining why weighted sums fail is what separates people who have looked at the score distributions.
  2. Decompose it: are the two scores even the same unit? Cosine similarity is bounded in 0 to 1 and tightly clustered — candidates often differ by 0.02. BM25 is unbounded and a few rare-term hits reach 12. Adding them lets the larger-magnitude channel decide everything; the weight only tunes how much it dominates.
  3. Worse, it is unstable. Weights tuned on one corpus drift on the next, so you re-tune forever.
  4. Conclusion: fuse ranks, not scores. RRF maps each rank to 1/(k + rank) and sums, with k = 60. Ranks are unitless and need no calibration. k flattens the head of the list so that 'top-ranked in both channels' beats 'first in one channel' — consensus over single-source confidence.
  5. A hand-checkable example helps: rankings [a,b,c] and [c,d,a] give a = 1/61 + 1/63 ≈ 0.0323, while a raw score sum promotes c on the strength of its BM25 12.
  6. Expected follow-up: what about ties? You must break them explicitly, e.g. by id. Otherwise ordering depends on hash-map iteration order and differs across languages and runs, which makes your evaluation numbers irreproducible. Mentioning this signals you actually ran it more than once.

  答题要点

  • 用 RRF：每一路的名次折算成 1/(k + rank) 再相加，k 取 60。
  • 不能加权求和是因为两个分数量纲不同——余弦有界密集、BM25 无上界，相加等于让 BM25 单方面决定结果。
  • 而且权重不可迁移：这批语料调好，换一批就得重调，是还不完的债。
  • 名次是无量纲的，不需要标定；k 压平头部差距，让两路共识压过单路自信。
  • 同分必须显式定序（按 id），否则结果依赖哈希表遍历顺序，评估数字不可复现。

  Key points

  • Use RRF: map each channel's rank to 1/(k + rank) and sum, with k = 60.
  • Weighted sums fail because the scores are different units — bounded, tightly clustered cosine versus unbounded BM25, so BM25 decides the outcome.
  • Weights also do not transfer: tuned on one corpus, they drift on the next.
  • Ranks are unitless and need no calibration; k flattens the head so cross-channel consensus outweighs single-channel confidence.
  • Break ties explicitly (by id) or ordering depends on hash iteration order and your evaluation numbers stop being reproducible.
• 重排（rerank）一般怎么实现？它解决了初步检索的什么问题，代价是什么？How is reranking usually implemented, what problem does it solve, and what does it cost?

  国内高频海外高频进阶#rag#rerank#latency

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

  1. 这题最容易答成「再排一次序，更准」。面试官想听的是**为什么第一轮不能直接排准**，以及**为什么重排不能对全库做**。
  2. 怎么拆：第一轮的排序依据是「检索信号」——余弦距离或词频统计，它们是为了能在百万条里快速筛选而设计的，代价就是粗。重排换了一种算法：把 query 和候选**拼在一起**送进同一个模型算相关度（cross-encoder），精度高得多，但复杂度是每条候选一次前向，没法对全库做。所以它必须跟在一个宽召回后面。
  3. 结论要区分两种实现：教学 / 原型可以用 LLM 批量打分（一次调用给 40 条打 0 到 10 分），生产用专门训练的 cross-encoder 重排模型。**代价说清楚：多一次 100 到 300 毫秒的调用，外加一台推理机器**——它不是按 token 计费的 API，是要占资源的。
  4. 把它放进漏斗里说最清楚：召回决定天花板，重排决定天花板上的东西能不能排到前五。实测的样子是——加了关键词那一路，recall@20 从 83% 涨到 95%（天花板抬高）；再加重排，recall@20 只到 98%，但 recall@5 从 80% 跳到 91%、MRR 从 0.732 到 0.908。
  5. 可预期的追问一：重排能不能提高召回？不能。它不引入新候选，只重排已有的那批——所以看 recall@20 判断重排效果是错的指标。
  6. 可预期的追问二：为什么不用 LLM 打分上生产？延迟不可控、成本按 token 走、分数会随提示词措辞漂移，而且没法做批量离线蒸馏。

  How to reason about it · think before answering

  1. The lazy answer is 'sort again, more accurately'. What the interviewer wants is why the first pass cannot rank well, and why reranking cannot run over the whole corpus.
  2. Decompose: the first pass ranks by retrieval signals — cosine distance or term statistics — which are designed to scan millions of items fast, and coarseness is the price. Reranking changes the algorithm: query and candidate go into one model together (a cross-encoder), which is far more accurate but costs one forward pass per candidate. Hence it must sit behind a wide recall stage.
  3. Distinguish two implementations. For teaching or prototypes, batch-score with an LLM (0-10 for 40 candidates in one call). Production uses a trained cross-encoder reranker. Name the cost: an extra 100-300 ms hop plus an inference box — it is not a per-token API, it consumes capacity.
  4. Framing it as a funnel is clearest: recall sets the ceiling, reranking decides whether what is under the ceiling reaches the top five. Measured: adding the keyword channel lifts recall@20 from 83% to 95%; adding reranking moves recall@20 only to 98%, but recall@5 jumps from 80% to 91% and MRR from 0.732 to 0.908.
  5. Expected follow-up 1: does reranking improve recall? No. It introduces no new candidates, so recall@20 is the wrong metric to judge it by.
  6. Expected follow-up 2: why not ship LLM scoring to production? Unpredictable latency, per-token cost, scores that drift with prompt wording, and no clean path to offline distillation.

  答题要点

  • 第一轮按检索信号粗排（余弦、词频），为的是能在大库里快速筛，代价是粗。
  • 重排把 query 和候选拼在一起过同一个模型（cross-encoder），精度高但每条一次前向，只能对几十条做。
  • 教学版可用 LLM 批量打 0 到 10 分；生产用专用重排模型，代价是多一次 100 到 300 毫秒的调用加一台推理机器。
  • 重排不提高召回，它提高的是 recall@5 与 MRR——实测 80% → 91%、0.732 → 0.908，而 recall@20 只从 95% 到 98%。
  • 所以判断重排效果要看前 k 小的指标，不要看 recall@20。

  Key points

  • The first pass ranks by retrieval signals so it can scan a large index fast; coarseness is the trade.
  • Reranking feeds query and candidate through one model together (cross-encoder): much sharper, but one forward pass per candidate, so only tens of items.
  • Batch LLM scoring works for teaching; production uses a dedicated reranker, costing an extra 100-300 ms hop plus an inference box.
  • Reranking does not raise recall — it raises recall@5 and MRR (measured 80% to 91%, 0.732 to 0.908) while recall@20 barely moves from 95% to 98%.
  • So judge a reranker by small-k metrics, never by recall@20.
• 怎么评估一个 RAG 系统的检索效果？评估集应该怎么构造？How do you evaluate retrieval quality in a RAG system, and how should the evaluation set be built?

  国内高频海外高频深入#rag#evaluation#recall

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

  1. 这题是国内面试的极高频题，也是最容易暴露「只搭过没调过」的一题。判据很简单：你的回答里有没有出现**具体的指标名和标注粒度**，没有就是没做过。
  2. 先把评估对象分清楚——这是最容易混的一步：**检索评估问「找得到找不到」，生成评估问「答得对不对」**。两套评估集要分开维护。混成一套的后果是分数掉了你分不清是检索漏了还是模型答砸了，而这两件事的修法完全不同。
  3. 评估集的形状：20 条左右的 query，每条**人工标注 1 到 3 个必须召回的 chunkId**。注意标注粒度是**块**不是文档——检索的单位就是块，标到文档级会让指标虚高。query 要覆盖真实分布，尤其要包含那些你知道会翻车的类型（编号、同义改写、跨文档）。
  4. 三个指标各回答一个问题：recall@5 是「进上下文的那几条覆盖了多少」，也就是你真正关心的数；recall@20 是天花板，它上不去说明问题在召回侧、重排再强也没用；MRR 对排序质量敏感，recall 打平时用它分高下。
  5. 生产视角：评估集一旦定下来就要冻结，换了样本分数就没有可比性——这和产线质检必须用固定的标准样品是同一个道理。同时线上要有对照指标（引用为空率、幻觉引用率、转人工率），因为离线过了不等于线上没事。
  6. 可预期的追问：标注成本这么高，20 条够吗？答：20 条不够做统计显著性，但足够做**回归**——它的作用是「改了检索之后别悄悄变差」。要做 A/B 定论再上规模，而且优先扩充失败案例，不是随机加样本。

  How to reason about it · think before answering

  1. This is a very common question in the Chinese market and the fastest way to expose someone who has assembled RAG but never tuned it. The test: does your answer contain concrete metric names and an annotation granularity?
  2. First separate what is being evaluated — the step people most often conflate. Retrieval evaluation asks 'was it found'; generation evaluation asks 'was the answer right'. Keep two separate sets. Merge them and, when the score drops, you cannot tell whether retrieval missed or the model fumbled — and those have completely different fixes.
  3. Shape of the set: about 20 queries, each annotated with 1-3 chunk ids that must be retrieved. Annotate at chunk level, not document level — chunks are the retrieval unit, and document-level labels inflate the numbers. Cover the real query mix, especially the types you know break: codes, paraphrase, cross-document.
  4. Three metrics, three questions. recall@5 is what actually reaches the model, so it is the number you care about. recall@20 is the ceiling — if it does not move, the problem is on the recall side and no reranker will save you. MRR is sensitive to ordering and breaks ties when recall is equal.
  5. Production view: freeze the set once agreed, because changing samples destroys comparability — the same reason a factory keeps fixed reference samples. Pair it with online counterparts (empty-citation rate, hallucinated-citation rate, escalation rate), since passing offline does not mean passing in production.
  6. Expected follow-up: is 20 enough given the labelling cost? Not for statistical significance, but enough for regression — its job is to stop retrieval silently getting worse. Scale up before you settle an A/B, and grow it from failure cases rather than random additions.

  答题要点

  • 检索评估和生成评估是两套：前者问「找得到找不到」，后者问「答得对不对」，分开维护。
  • 评估集是 20 条左右的 query，每条人工标 1 到 3 个必须召回的 chunkId——标到块级，不是文档级。
  • recall@5 是真正关心的数（模型只看得到这几条），recall@20 是天花板，MRR 衡量排序质量。
  • 评估集一旦定下来就冻结，否则分数没有可比性；线上再配引用为空率、幻觉引用率做对照。
  • 20 条不够做显著性但够做回归；扩充时优先补失败案例，不是随机加样本。

  Key points

  • Retrieval and generation evaluation are two separate sets: 'was it found' versus 'was the answer right'.
  • Around 20 queries, each labelled with 1-3 chunk ids that must be retrieved — chunk level, not document level.
  • recall@5 is what the model actually sees, recall@20 is the ceiling, MRR measures ordering quality.
  • Freeze the set once agreed or scores stop being comparable; pair it with online empty-citation and hallucinated-citation rates.
  • Twenty cases is a regression guard, not a significance test; grow it from failure cases, not random samples.