W3D2 学习手册 1.全景 2.BM25 3.向量 4.RRF 5.MetaFilter 6.Rerank 7.keyword 8.ES向量 9.链路 10.评测 11.实战达标① 达标② 自测速记

FDE W3D2 学习手册 · 混合检索与 Rerank（BM25 + 向量 + RRF + BGE Reranker）

W3 Day2 · A 级（必须掌握，面试核心）· 5h · 学完能讲透"为什么单路检索不够，BM25+向量+RRF 怎么融合、为什么还要 Rerank"

本日定位：W2 讲了 Embedding 与"问题-知识对齐"，W3D2 落到"检索执行层"——企业 RAG 几乎不用单一向量检索，而是 BM25（关键词）+ 向量（语义）+ RRF（融合）+ Reranker（精排）的组合拳。这是你 Java+大数据背景最能讲清"工程链路"的一环。
学完能回答：① BM25+向量+RRF 怎么融合、为什么需要 Rerank；② 药品名称/ICD 编码/保单号这种精确匹配为什么用 keyword 字段而不是向量；③ 完整检索链路与评测指标。
使用方法：通读原理 → 重点看「🔧工程含义」「🎤面试话术」「⚠易错点」→ 做自测清单 → 配合《FDE-W3D2-评测题.md》。选中不熟的词可标注（左下★重要 / 右下📌待查）。

一、混合检索全景：为什么单路检索不够

纯向量检索靠语义相似，但有三处天生短板：① 精确匹配弱——"保单号 PICC2025-0098"这种字符串，向量检索找不到精确等价；② 稀有词/专有名词语义漂移（"奥希替尼"和"泰瑞沙"是同药不同名，向量未必拉近）；③ 高频词主导时语义被稀释。BM25 恰好补足这些：基于词频与逆文档频率的精确/准精确匹配。

结论：企业知识库（尤其医疗理赔）要"既要语义召回，又要精确命中"，所以采用「BM25 关键词召回 ∪ 向量语义召回 → RRF 融合 → Reranker 精排」的混合架构。

工程含义：混合检索是"召回率"与"精确率"的折中。单向量召回率高但精确率差（易召不相关的近义 chunk）；BM25 精确率高但召回率差（同义表述召不回）。两者融合取长补短，再用 Reranker 在 Top-K 上精排提精确率。

单路向量检索有两个坑：精确匹配弱（保单号、药名查不准）、专有名词语义漂移。所以我用混合检索——BM25 做关键词精确召回，向量做语义召回，RRF 把两路分数融在一起，最后用 BGE Reranker 在 Top 候选上精排。这样既召回得全，又排得准。

① "向量检索比 BM25 先进所以该只用向量"是常见误区——向量在精确匹配和稀有实体上反而更弱。② 混合检索不是简单 concat 两路结果，要用 RRF 等融合算法归一化（见 s4）。③ 别忘了 Metadata Filter 要先于或并行于检索做权限/范围过滤（s5、W3D3）。

二、BM25 关键词检索原理与医疗精确匹配

2.1 原理

BM25 是 Elasticsearch 默认的相关性打分，基于：词频（TF）、逆文档频率（IDF）、字段长度归一化。

score(q,d) = Σ_{t∈q} IDF(t) · ( f(t,d)·(k1+1) ) / ( f(t,d) + k1·(1−b+b·|d|/avgdl) ) IDF(t) = ln( (N − n_t + 0.5) / (n_t + 0.5) + 1 )

k1：控制词频饱和（默认 1.2），词出现越多分数越高但有上限。
b：控制字段长度惩罚（默认 0.75），长文档被降权。
IDF：越稀有的词权重越高——"奥希替尼"比"保险"权重高。

2.2 医疗场景的精确匹配

BM25（keyword 字段）适合：药品名称、ICD-10 编码、保单号、条款编号等确定性字符串。用户问"ICD 编码 C34 的理赔"时，BM25 能精准命中含 C34 的 chunk，向量检索却可能把它和"C34 相关肺癌"的泛化内容混在一起。

工程含义：BM25 是"字面命中"，对编码/编号/专名这类"错一个字符就全错"的查询是刚需。医疗理赔里一个保单号、一个 ICD 码直接关联钱和合规，必须 keyword 精确匹配。

BM25 基于词频+逆文档频率打分，擅长字面精确匹配。像药品名称、ICD 编码、保单号这种确定性字符串，用户问"C34"就是要精确命中含 C34 的条款，BM25 在 keyword 字段上最稳。这部分恰恰是向量检索的弱项。

① BM25 默认对中文要分词（ik_max_word / ik_smart），否则按字切会丢语义。② BM25 对同义词无能为力——"泰瑞沙"和"奥希替尼"它当两回事，这正是要靠向量补充的。③ 精确字段（保单号）要用 keyword 类型而非 text，否则会被分词破坏精确性（见 s7）。

三、向量检索原理与语义召回

3.1 原理

把 query 和 chunk 都用 Embedding 模型编码成向量，用相似度（余弦/点积）度量语义接近度，取 Top-K。这是"语义召回"——用户问"肺癌靶向药报销"，即使 chunk 写的是"非小细胞肺癌 NSCLC 用药补偿"，也能召回。

sim(q, d) = cosine(E_q, E_d) = (E_q · E_d) / (‖E_q‖ · ‖E_d‖) 召回 = top_k { d | sim(q,d) 最高 }

3.2 向量检索的边界

强项	弱项
同义/近义表述召回（口语化问题）	精确字符串/编码匹配弱
跨表述的语义对齐	稀有实体、新药名语义漂移
长尾 query 有兜底	高频词主导时语义被稀释

工程含义：向量检索解决"用户不会照着手册原文问"的问题。但 Embedding 质量决定上限，医疗专有名词多，要选领域适配好的中文模型（如 bge 系列），并配合 BM25 补精确。

向量检索把 query 和 chunk 编码成向量，用余弦相似度召回语义接近的。强项是同义表述召回——用户口语问"肺癌靶向药"能召回到写"NSCLC 用药补偿"的 chunk。弱项正好相反：精确字符串和稀有药名它反而弱，所以要和 BM25 配合。

① 向量相似度是"语义近"不是"事实对"，高分 chunk 可能语义相关但答非所问。② 必须用 同一 Embedding 模型编码 query 和 doc，否则空间不对齐（呼应 W3D1 embedding_version）。③ 相似度阈值不能一刀切，要按评测定（太高漏召回、太低噪声多）。

四、RRF 倒数排名融合（Reciprocal Rank Fusion）

4.1 为什么需要融合

BM25 分数和向量余弦分数量纲不同（一个可能 0~20，一个 -1~1），不能直接相加。RRF 用"排名"而非"分数"融合，天然规避量纲问题。

4.2 公式

RRF_score(d) = Σ_{r ∈ {bm25, vector}} 1 / (k + rank_r(d)) 通常 k = 60；rank_r(d) 是文档 d 在第 r 路结果中的排名（第1名 rank=1）

例：chunk A 在 BM25 排第 2、向量排第 5 → RRF = 1/(60+2) + 1/(60+5) = 0.0161 + 0.0154 = 0.0315。两路都靠前的 chunk 总分最高。

4.3 为什么用排名不用分数

不依赖各路分数归一化，工程简单鲁棒。
对"某一路特别强"有平滑效果，避免单路分数主导。
k 控制排名靠后项的衰减速度，k 越大越看重头部。

工程含义：RRF 是混合检索的"胶水"。它让 BM25 和向量两路结果能公平合并，且不需调权重——很多企业图省事直接用 RRF 而非手动调 α（α·bm25 + (1-α)·vec），因为 RRF 对两路质量波动更鲁棒。

BM25 分数和向量分数量纲不同，不能直接加。RRF 用"排名"融合：每个文档的得分是各路 1/(k+排名) 之和，k 一般取 60。两路都靠前的 chunk 总分最高。它不依赖分数归一化，比手动调 α 权重更鲁棒，是混合检索最常用的融合方式。

① RRF 只看排名不看原始分数，所以某路"极度自信的高分"和"微弱高分"在 RRF 里被拉平——若某路质量极差（如全错），它会拖累但不至于淹没另一路。② 不要先各自截断 Top-K 再 RRF 但 K 太小会丢另一路的宝贵召回，K 取 50~100 较稳。③ RRF 是"无监督融合"，若要针对业务优化可上学习排序（LTR），但成本高。

五、Metadata Filter：先过滤再检索

Metadata Filter 在检索前/中用 chunk 的元数据（部门、版本、状态、文档类型）缩小候选集，等价于"在子集里检索"。

# Elasticsearch：先按 metadata 过滤，再 kNN 向量检索
{
  "knn": {
    "field": "embedding",
    "query_vector": [...],
    "k": 50,
    "filter": {
      "bool": {
        "must": [ {"term": {"status": "active"}},
                  {"term": {"doc_version": "v2025Q2"}} ]
      }
    }
  }
}

5.1 两种过滤时机

方式	做法	适用
预过滤（pre-filter）	先按 metadata 筛候选，再算相似度	权限/范围强约束（W3D3 ACL）
后过滤（post-filter）	先召回再过滤	软性偏好（如优先新版本）

工程含义：Metadata Filter 是"检索的 WHERE 条件"。医疗场景里它和权限强绑定——用户只能检索自己部门/自己保单范围内的 chunk，这既是性能优化也是合规刚需（W3D3 详述）。务必用 W3D1 设计的元数据字段承接。

Metadata Filter 就是检索的 WHERE 条件，用 chunk 上的元数据（状态/版本/部门）缩小候选。两种时机：预过滤先筛再检索（权限强约束用这个），后过滤先召回再筛（软偏好用这个）。它既提速又承接权限，字段来自 W3D1 设计的元数据。

① 后过滤可能把召回集过滤到不足 K 个，导致答案缺失——权限过滤务必用预过滤或保证候选充足。② 过滤字段要建索引（keyword/term），否则全表扫慢。③ 过滤条件写错（如版本写死旧版）会导致"搜不到新内容"，和 W3D1 的版本问题联动。

六、BGE Reranker：精排原理与实践

6.1 为什么融合之后还要 Rerank

RRF 融合解决了"召回融合"，但融合后的 Top 结果仍是"两路粗略叠加"，精确率有限。Reranker 用交叉编码器（cross-encoder）对 (query, chunk) 逐对深度打分，捕捉更细的相关性，把真正该排第一的顶上去。

6.2 BGE Reranker 原理

BGE Reranker（如 BAAI/bge-reranker-large）是 cross-encoder：把 query 和 document 拼接输入同一个 Transformer，输出一个相关性分数（0~1）。它比 bi-encoder（向量检索）更准，因为能看到 query 与 doc 的双向交互，但慢——所以只作用在召回的 Top-N（如 50→重排→取 5~10）。

向量检索/BM25 召回 Top-50 → BGE Reranker 对 (q, d_i) 逐对打分 → 取重排后 Top-5~10 送 LLM

from transformers import AutoModelForSequenceClassification, AutoTokenizer
import torch
tok = AutoTokenizer.from_pretrained("BAAI/bge-reranker-large")
model = AutoModelForSequenceClassification.from_pretrained("BAAI/bge-reranker-large")
pairs = [[query, d] for d in top50_chunks]
inputs = tok(pairs, padding=True, truncation=True, return_tensors="pt", max_length=512)
scores = model(**inputs).logits.view(-1).float()   # 越大越相关
ranked = [d for _, d in sorted(zip(scores, top50_chunks), reverse=True)][:8]

官方资源：BAAI/bge-reranker-large (HuggingFace)；中文 RAG 教程：B站 2025 最全 RAG 教程（含 Rerank）。

工程含义：Reranker 是"精确率放大器"。召回阶段要"宁错勿漏"（高召回），精排阶段把噪声压下去（高精确）。工程上 Reranker 是瓶颈（逐对推理），要限制作用条数、批处理、或用更小模型（bge-reranker-v2-m3）降本。

RRF 融合并非终点，融合结果精确率还有限。所以我再接一层 BGE Reranker：它是 cross-encoder，把 query 和每个候选 chunk 拼一起过模型打出相关性分，能捕捉细粒度交互，比向量检索准得多。但慢，所以只作用在召回的 Top-50 上重排，取前 5~10 给 LLM。召回要"宁错勿漏"，精排压噪声。

① Reranker 慢在"逐对推理"，作用条数必须限制（50 量级），否则延迟爆炸。② 别把 Reranker 当召回用——它不检索，只排序已有候选，前面必须有 BM25+向量召回。③ 中英文/领域适配：选 bge-reranker-v2-m3 等多语言版，纯 large 中文未必最优。④ Reranker 分数和生产阈值要按评测定，别拍脑袋。

七、关键词字段 vs 向量字段：药品名 / ICD / 保单号为什么用 keyword

7.1 核心区别

维度	keyword 字段（精确）	text 字段（分词后 BM25）	向量字段（语义）
匹配方式	整体精确相等	分词后词项匹配	语义相似度
适用	保单号、ICD 码、药名编码	章节标题、正文	口语化语义查询
对"错一字"	直接不匹配（正确行为）	可能部分匹配	可能近似召回（危险）

7.2 为什么保单号/ICD 不能用向量

保单号 PICC-2025-0098 是任意字符串，语义上无"近义"概念——它的 neighbors 不该是别的保单号。向量检索会把"PICC-2025-0098"和"PICC-2025-0099"当成"相似"（共享前缀 token），但业务上它们是两个完全不同的保单，召回隔壁保单内容是严重错误。ICD 编码同理：C34 和 C34.1 是不同细分，向量相似度会模糊这种区分。

精确标识符 → keyword 字段 + term 查询（精确命中）语义查询 → text + BM25 / 向量（相似召回）

工程含义：把"标识符"当"语义"检索是医疗 RAG 的高危错误。正确做法是在 chunk metadata 里冗余存 keyword 类型的药名/ICD/保单号字段，查询时先抽取实体→用 term 精确过滤，语义检索只负责"描述性"部分。这才是"精确 + 语义"双轨。

保单号、ICD 编码、药品名编码是"标识符"，不是"语义词"。用向量检索会把它和相似字符串（如相邻保单号）当近义召回，但业务上那是两个完全不同的东西——召回隔壁保单是严重事故。所以这些字段要用 keyword 类型做 term 精确匹配，向量只负责描述性语义查询。工程上在 chunk metadata 里冗余存 keyword 字段，查询先抽实体再精确过滤。

① 别把保单号既当 text 又当向量——text 会被分词破坏精确性，向量会近义串味。应用独立 keyword 字段。② 实体抽取（从 query 里提出 ICD/保单号）本身要准，抽错实体过滤器就失效——可用规则/NER。③ keyword 字段大小写、连字符敏感，入库和查询要保持一致归一化。

八、Elasticsearch 向量检索与 kNN 配置

Elasticsearch 8.x 原生支持 dense_vector 字段与近似 kNN（HNSW 图）。一套 ES 同时存 keyword/text/dense_vector，天然支持混合检索。

PUT claim_kb
{
  "mappings": {
    "properties": {
      "content":        { "type": "text",  "analyzer": "ik_max_word" },
      "drug_name":      { "type": "keyword" },          // 药品名精确
      "icd_code":       { "type": "keyword" },          // ICD 精确
      "policy_no":      { "type": "keyword" },          // 保单号精确
      "embedding":      { "type": "dense_vector",
                          "dims": 1024,
                          "index": true,
                          "similarity": "cosine" },
      "doc_version":    { "type": "keyword" },
      "status":         { "type": "keyword" }
    }
  }
}

8.1 混合检索的两种 ES 写法

bool + knn：BM25（must/should）与 knn 同在一个 bool 查询，ES 内部线性融合（可设 boost）。
RRF via rankfusion（ES 8.9+）：用 rank 块的 rrf 显式融合多路（推荐，可控）。

官方文档：Elasticsearch kNN 向量检索；Terms Query（精确过滤，ACL 用）。

工程含义：选 ES 做混合检索的好处是"一个引擎管全部"——keyword 精确、text BM25、dense_vector 语义、bool 过滤权限，都在一次查询里完成，运维简单。HNSW 的 ef_construction/m 参数影响召回率与内存，要按数据量调。

Elasticsearch 8.x 支持 dense_vector + HNSW 近似 kNN，而且一个索引能同时存 keyword（精确）、text（BM25）、dense_vector（语义）、还有 bool 过滤权限。混合检索用 bool+knn 或 ES 8.9+ 的 rank.rrf 显式融合。好处是一个引擎管全部，运维简单。HNSW 的 ef/m 参数要按数据量调平衡召回和内存。

① HNSW 是近似检索，召回率 < 100%，参数没调好会漏关键 chunk——医疗场景要验证召回率达标。② dense_vector 的 dims 必须和 Embedding 模型输出一致，否则写入报错。③ 不要对超大数据集用暴力 kNN（exact），延迟高；近似 kNN 要建图。④ keyword 字段若误设为 text，精确匹配失效。

九、融合 + 精排的完整检索链路

用户 Query → 实体抽取（ICD/保单号/药名） → 并行：BM25(keyword+text) 召回 Top-50 ｜向量 kNN 召回 Top-50 → Metadata Filter（active/版本/权限）预过滤 → RRF 融合两路 → Top-50 候选 → BGE Reranker 逐对精排 → Top-8 → 送 LLM 生成（附引用 chunk_id）

9.1 各环节的"职责边界"

环节	目标	失败后果
BM25+向量召回	高召回（宁错勿漏）	漏召→答案无依据
Metadata Filter	范围/权限正确	越权/旧版
RRF	两路公平融合	某路淹没
Reranker	高精确（压噪声）	噪声进 LLM→幻觉

工程含义：链路是"漏斗"。召回宽、精排窄。每一层都可独立评测（召回率看前两层，精确率看 Reranker）。任何一层出问题都能用 W3D1 的评测集定位——这正是数据工程与检索工程联动的价值。

完整链路：先抽实体（ICD/保单号），并行跑 BM25 和向量各召回 Top-50，用 metadata 预过滤（active/版本/权限），RRF 融合成 Top-50 候选，再 BGE Reranker 精排取 Top-8 给 LLM。召回要宽（宁错勿漏），精排要窄（压噪声），每层都能用评测集独立验证。

① 实体抽取失败会导致精确过滤失效，要兜底（抽不到就纯语义检索并提示）。② Reranker 输出 Top-8 但若前层召回就漏了正确答案，精排再强也救不回——召回是地基。③ 整条链路延迟要评估：向量+BM25 并行 ~50ms，Reranker Top-50 可能 100~300ms，要算进 SLA。

十、评测：召回率 / 精确率 / NDCG 与 RAGAS

10.1 检索层指标

指标	含义	在混合检索的意义
Recall@K	Top-K 中含多少应召回 chunk	衡量"召回宽不宽"，漏召是致命伤
Precision@K	Top-K 中相关比例	衡量精排效果
MRR / NDCG@K	相关结果排名质量	衡量 Reranker 是否把对的顶上去

10.2 RAGAS（生成+检索联合评测）

context_precision / context_recall：检索质量（对应上面的指标）。
faithfulness：答案是否忠于检索到的上下文（防幻觉）。
answer_relevancy：答案是否切题。

工程含义：没有评测的检索调参是盲人摸象。混合检索的每个旋钮（BM25 boost、RRF 的 k、Reranker 候选数、阈值）都要在评测集上量化对比。用 W3D1 的 Golden Case 的 expected_chunks 算 Recall@K，用 RAGAS 看端到端。

检索层看 Recall@K（漏召致命）、Precision@K、NDCG@K（排名质量）；端到端可用 RAGAS 的 context_precision/recall + faithfulness + answer_relevancy。每个旋钮（BM25 权重、RRF 的 k、Reranker 候选数）都要在评测集上量化对比，不能凭感觉调。Golden Case 里的 expected_chunks 正好用来算 Recall@K。

① 只看 Precision 不看 Recall 会"排得准但漏了关键 chunk"，答非所问。② RAGAS 的 faithfulness 依赖 LLM 评判，有自身偏差，重要结论要人工抽查。③ 指标要在固定评测集版本上比（呼应 W3D1），否则前后不可比。④ NDCG 对"正确答案排在很后面"敏感，是检验 Reranker 的好指标。

十一、实战：保险知识库混合检索（特药理赔）

11.1 场景

用户问："我母亲肺腺癌 EGFR 突变，医生开奥希替尼，保单 PICC-2025-0098 能报多少？"

处理流程

实体抽取：药名=奥希替尼（=泰瑞沙），ICD≈C34，保单号=PICC-2025-0098。
BM25（keyword）：用 term: {policy_no: PICC-2025-0098} + icd_code: C34 精确命中该保单适用条款；text 部分匹配"奥希替尼/靶向药报销"。
向量：语义召回"EGFR 突变 NSCLC 用药补偿"等描述性 chunk。
Metadata Filter：status=active, doc_version=v2025Q2，并叠加 ACL（仅该用户可见，W3D3）。
RRF + Rerank：融合后精排，取 Top-8 送 LLM，附 chunk_id 引用。

bool_query = {
  "bool": {
    "must": [ {"term": {"policy_no": "PICC-2025-0098"}},
              {"term": {"status": "active"}} ],
    "should": [ {"match": {"content": "奥希替尼 靶向药 报销"}},
                {"knn": {"field":"embedding","query_vector":q_vec,"k":50}} ]
  }
}
# 再用 rank.rrf 融合 should 里的两路，最后 BGE Reranker 精排

工程含义：真实查询往往是"精确标识符 + 描述性语义"混合。正确架构是"标识符走 keyword 精确过滤，描述走 BM25+向量语义"，二者在 bool/rrf 里汇合。单一向量检索处理这种 query 必然顾此失彼。

真实理赔 query 是"精确+语义"混合：保单号 PICC-2025-0098 走 keyword term 精确过滤，奥希替尼/EGFR 走 BM25+向量语义召回，再 metadata 过滤版本和权限，RRF 融合后 BGE Reranker 精排取 Top-8。标识符和语义各走各的道，最后汇合——这才是医疗 RAG 的正确打法。

① query 里同时有保单号和口语描述时，若只用向量会把别的不相关保单的相似描述也召回。② 实体抽取把"泰瑞沙"归一成"奥希替尼"很关键，否则 BM25 漏命中。③ 返回答案必须带 chunk_id 引用，医疗合规要可溯源（呼应 W3D1）。

十二、面试达标线①：BM25+向量+RRF 融合与 Rerank 必要性

环节	作用	为什么必要
BM25	关键词/精确召回	向量在精确匹配、稀有实体上弱
向量 kNN	语义召回	BM25 在同义/口语上弱
RRF	按排名融合两路	两路分数量纲不同，不能直加；RRF 鲁棒
BGE Reranker	Top-N 精排	融合结果精确率有限，需 cross-encoder 压噪声

核心一句话：单路各有短板——BM25 精确但不懂同义，向量懂语义但精确匹配弱。所以 BM25+向量并行召回，用 RRF（按排名而非分数融合，规避量纲）合并，再用 BGE Reranker（cross-encoder）在 Top 候选上精排提精确率。召回要宽、精排要窄，Rerank 是精确率放大器，不能省。

十三、面试达标线②：精确匹配为什么用 keyword 字段而不是向量

标识符（保单号/ICD/药名编码） → 无"近义"概念 → 必须 keyword + term 精确匹配向量检索会把 PICC-...098 与 PICC-...099 当"相似"召回 → 但业务上是两个不同保单 → 严重错误

标识符无语义近义：保单号、ICD 码、药品编码是确定性字符串，邻居不该是"相似串"。
向量会近义串味：共享前缀/字符的标识符被向量当成相近，召回隔壁保单/相邻 ICD 是合规事故。
正确做法：chunk metadata 冗余存 keyword 字段，查询先抽实体→term 精确过滤；语义部分才走 BM25+向量。
工程联动：keyword 字段大小写/连字符归一化，实体抽取要准，否则过滤失效。

十四、W3D2 自测清单

能说清单路向量检索的三处短板，解释为什么企业用混合检索。
能写出 BM25 打分公式要素（TF/IDF/长度归一化 k1/b），说清医疗精确匹配场景。
能解释向量检索原理（余弦相似度）及其强项/弱项边界。
能写出 RRF 公式，说清为什么用"排名"而非"分数"融合（量纲问题）。
能区分 Metadata Filter 的预过滤与后过滤时机及适用。
能讲清 BGE Reranker 是 cross-encoder、为什么慢但要接在召回之后精排。
能解释 keyword / text / 向量三字段区别，以及为什么保单号/ICD/药名用 keyword。
能画出 ES dense_vector + HNSW 的混合检索映射，说清 bool+knn 与 rank.rrf。
能画出"实体抽取→并行召回→过滤→RRF→Rerank→LLM"完整链路及每层职责。
能说清 Recall@K / NDCG / RAGAS 在检索评测中的意义与陷阱。
能用特药理赔场景讲清"标识符走 keyword、语义走 BM25+向量"的混合实战。
能讲清达标线①（融合与 Rerank 必要性）与达标线②（精确匹配用 keyword）。

十五、高频面试题速记卡

Q：为什么不用纯向量检索？

向量在精确匹配、稀有实体、标识符上弱；BM25 补精确，两者混合取长补短，再用 Rerank 精排。

Q：RRF 为什么用排名不用分数？

BM25 与向量分数量纲不同无法直接相加；RRF 用 1/(k+排名) 融合，规避归一化，比手动调 α 权重鲁棒。

Q：Reranker 和向量检索有什么区别？

向量是 bi-encoder（各自编码再算相似，快但不细）；Reranker 是 cross-encoder（query+doc 拼接打分，准但慢），所以只作用在召回 Top-N 精排。

Q：保单号为什么不能用向量检索？

保单号是标识符无近义概念，向量会把相邻保单号当相似召回，但业务上是两个不同保单——严重错误，必须 keyword+term 精确匹配。

Q：ICD 编码该用什么字段？

keyword 字段做 term 精确匹配。C34 与 C34.1 是不同细分，向量相似度会模糊区分，医疗上不允许。

Q：Metadata Filter 预过滤和后过滤怎么选？

权限/范围强约束用预过滤（先筛再检索）；软偏好用后过滤。权限必须用预过滤，否则可能召回不足或越权。

Q：Reranker 作用条数为什么要限制？

cross-encoder 逐对推理慢，作用 50 条量级可控延迟；它只排序不检索，前面必须有召回。

Q：ES 怎么做混合检索？

一个索引存 keyword/text/dense_vector，用 bool+knn 或 ES 8.9+ 的 rank.rrf 显式融合，HNSW 近似 kNN。

Q：怎么评测检索质量？

Recall@K（漏召致命）、Precision@K、NDCG@K（排名质量）；端到端用 RAGAS。每个旋钮在评测集量化对比。

Q：真实理赔 query 怎么处理？

先抽实体（药名/ICD/保单号），标识符走 keyword 精确过滤，描述走 BM25+向量语义，RRF 融合后 Rerank 精排，带 chunk_id 引用。

FDE W3D2 学习手册 · 混合检索与 Rerank（面试级）· 配合《FDE-W3D2-评测题.md》自测

📌 待查★ 重要