recall = TP / (TP + FN) # 该搜的都搜了吗

1️⃣ 考察意图

这道题表面是背公式，实际考察候选人对检索系统“召回”的工程理解深度。面试官想看的不是“Recall = TP/(TP+FN)”，而是：在RAG/搜索系统中，TP和FN如何定义？Recall@K与全量Recall的区别？如何在不显著牺牲Precision的前提下提升Recall？ 刁钻点在于：候选人能否跳出教科书，讲清楚“为什么Recall是RAG的瓶颈”、“多路召回如何量化收益”、“评估时如何避免标注偏差”。答好了能展示：系统设计思维、工程取舍能力、对检索前沿（如ColBERT、混合检索）的认知。

2️⃣ 标准答

1. 定义澄清：TP/FN在检索场景下的具体化

在检索中，TP是“检索到的相关文档”，FN是“未检索到的相关文档”。但实际标注时，全量相关文档（FN的分母）几乎不可能穷举——这是Recall评估的核心坑。
工程上常用Recall@K（前K个结果中相关文档占比）替代全量Recall。例如MS MARCO数据集用Recall@20评估，因为用户只看前20条。
坑：如果业务场景是“必须召回所有相关文档”（如法律检索），Recall@K会低估真实召回率，需改用全量Recall（需人工标注全部相关文档，成本极高）。

2. 影响Recall的关键因素与优化手段

检索算法：
BM25：基于词频和逆文档频率，对精确匹配敏感，但语义泛化差。默认参数k1=1.5, b=0.75，可调低b（如0.5）提升长文档召回。
向量检索：用DPR或ColBERT生成稠密向量，通过HNSW索引近似搜索。但HNSW的ef_construction参数（构建时）和ef_search（搜索时）直接影响Recall：ef_search从100提到500，Recall@20可提升5-8%，但延迟增加3倍。
混合检索：BM25 + 向量检索加权融合（如RRF算法，权重系数k=60），通常比单路Recall高10-15%。
查询改写：
用LLM生成同义查询（如“苹果手机”→“iPhone 15”），通过Query Expansion提升Recall。但需控制扩展数量（3-5个），否则引入噪声。
坑：LLM改写可能过度泛化（如“苹果”扩展出“水果”），需加业务规则过滤（如只扩展品牌+型号组合）。
索引质量：
文档分块（chunking）策略：固定大小（256 tokens） vs. 语义分块（如LangChain的RecursiveCharacterTextSplitter）。语义分块能提升跨段落相关文档的Recall，但需额外计算开销。

3. 工程取舍：Recall vs. Precision vs. Latency

高Recall策略：多路召回（3-5路） + 重排序（Rerank）。例如：BM25（路1）+ 向量检索（路2）+ 知识图谱（路3），合并后用Cross-Encoder（如Cohere Rerank 3）重排Top-100。代价：延迟从50ms升到300ms。
低Recall场景：如果业务容忍漏检（如新闻推荐），可只保留向量检索，用更小的ef_search（如50）换取低延迟。
评估陷阱：Recall@K对K值敏感。K=10时Recall可能仅60%，K=100时能到90%，但用户不会翻100页。需结合业务定义“有效K”（如电商场景K=20）。

4. 实际落地的坑 + 解法

坑：标注数据偏差。人工标注的相关文档往往只覆盖高频查询，导致Recall虚高。解法：用A/B测试对比线上用户点击率（CTR），而非仅依赖离线Recall。
坑：多路召回结果重复。BM25和向量检索可能返回相同文档，浪费计算资源。解法：用MinHash去重，或设置RRF的k值（如k=60）降低重复权重。

3️⃣ 答题模板（30 秒电梯版）

“这个问题我从三个层面回答：第一，Recall在检索中的定义是TP/(TP+FN)，但工程上常用Recall@K替代全量Recall，因为全量标注成本太高。第二，提升Recall的核心手段包括混合检索（BM25+向量检索）、查询扩展（LLM生成同义查询）和索引优化（语义分块）。第三，必须做trade-off：高Recall会引入噪声和延迟，需结合业务场景选择Recall@K的K值，并通过Rerank控制Precision。总结一句：Recall是RAG的瓶颈，但优化时不能只看离线指标，必须用线上CTR验证。”

4️⃣ 高频追问 & 应对

追问 1：如果业务要求Recall@20达到95%，但当前只有80%，你会怎么优化？

首先分析瓶颈：是检索算法问题还是查询质量问题？如果是检索算法，尝试混合检索（BM25+向量检索，权重用RRF），通常能提升5-10%。如果是查询质量，用LLM做Query Expansion，生成3个同义查询，但需加规则过滤（如只扩展品牌名）。如果还不行，考虑增加检索路数（如知识图谱），但延迟会从100ms升到300ms。最后，如果业务允许，降低K值（如K=10），因为Recall@10可能更容易达标。

追问 2：你怎么评估Recall的准确性？如果标注数据不全怎么办？

核心方法是分层抽样：对高频查询（占80%流量）人工标注全部相关文档，对低频查询用弱监督（如用户点击作为正样本）。另外，用A/B测试验证：如果优化后Recall提升但CTR下降，说明Recall虚高（引入了噪声）。还可以用互信息指标：计算检索结果与用户行为的互信息，间接衡量召回质量。

追问 3：多路召回中，不同路的权重怎么确定？

常用方法：RRF（Reciprocal Rank Fusion），公式为score = sum(1/(k + rank_i))，k通常取60。优点是无需训练，但权重固定。更优方案是学习型融合：用LightGBM训练一个模型，输入每路的得分、文档长度、查询长度等特征，输出最终得分。但需要标注数据（相关/不相关），成本较高。工程上，先用RRF快速上线，再逐步替换为学习型融合。

5️⃣ 避坑 · 常见错误答法

❌ 只背公式：“Recall = TP/(TP+FN)，TP是检索到的相关文档，FN是未检索到的。” → ✅ 必须补充工程定义：TP/FN在检索中如何量化？Recall@K与全量Recall的区别？标注偏差如何影响评估？
❌ 盲目追求高Recall：“我会用10路召回，确保Recall达到99%。” → ✅ 必须谈trade-off：多路召回增加延迟和噪声，需结合业务场景（如法律检索 vs. 新闻推荐）选择路数，并通过Rerank控制Precision。
❌ 忽略评估陷阱：“我只看离线Recall指标。” → ✅ 必须强调：离线Recall可能虚高（标注偏差），需用线上CTR或A/B测试验证。

6️⃣ 简历呼应

如果你有RAG项目：从“多路召回优化”切入，展示你在MS MARCO上对比BM25、向量检索、混合检索的Recall@20实验，并分析不同查询类型（如长尾查询 vs. 高频查询）的表现差异。
如果你只做过传统NLP：用“文本分类中的F1-score”类比Recall，说明检索场景下TP/FN的定义更复杂（需人工标注），并迁移你的特征工程经验（如查询扩展中的同义词替换）。
如果你是校招无项目：聚焦“Recall@K的数学推导与HNSW参数调优”，复现一篇论文（如ColBERT的端到端检索），并写一篇博客分析ef_search对Recall的影响。
《ColBERT: Efficient and Effective Passage Search via Contextualized Late Interaction》
《Hybrid Search: Combining BM25 and Dense Retrieval for Better Recall》
《HNSW: Hierarchical Navigable Small World Graphs for Approximate Nearest Neighbor Search》
《Query Expansion Techniques in Information Retrieval: A Survey》
《Evaluating Recall in Large-Scale Retrieval Systems: Pitfalls and Best Practices》

—— 本场面试完 ——