面试题 · 评估
搜索「检索增强」匹配到口述回答，相关段落已展开。查看匹配内容 ↓
在 RAG 系统中，稠密、稀疏和混合检索应如何选型？请说明技术考量、优化路径，以及项目回答中需要补充哪些可核验事实。
检索方案不能脱离语料和查询分布。稠密检索擅长语义改写，稀疏检索擅长专有名词、编号和数字的精确匹配；两类查询同时存在时，可以采用双路召回，再通过 RRF 或经过验证的加权策略融合。
| 方案 | 优势 | 主要风险 |
|---|---|---|
| 稠密检索 | 同义改写、自然语言意图 | 专有名词和长尾实体可能漏召回 |
| BM25 等稀疏检索 | 关键词、编号、错误码精确命中 | 难以覆盖语义改写 |
学习内容与项目面试，在同一条路上。
| 混合检索 | 同时覆盖语义和字面信号 | 两套索引增加延迟、成本和维护复杂度 |
RRF 只依赖名次，适合不同召回分数难以直接比较的情况；线性加权需要先校准分数，并用评测集确定权重，不能凭经验写一个固定值。
离线至少观察 Recall@K、MRR 或 NDCG，并按查询类型切片；线上还要看引用正确性、无答案识别、延迟和成本。指标定义、标注口径、样本量及数据泄漏检查必须与结果一起说明。
如果需要结合本人项目，只填写可核验事实：语料主要是【真实文档类型】；基线方案是【真实基线】；主要失败查询是【真实 bad case】；选择【真实检索或融合方案】的约束是【真实原因】；离线和线上分别用【真实指标】验证；代价是【真实延迟、成本或复杂度变化】。没有做过的优化和没有记录的指标应明确说明。
场景切入
假设要为电商客服设计 RAG：用户问‘我昨天买的充电宝怎么还没到？’，系统要同时匹配订单号和‘物流延迟’这种语义。检索链路应怎么设计，稠密和稀疏检索如何取舍？
层层追问
RAG检索你一般用什么方法？……如果用户输入的专有名词很多，比如‘iPhone 15 Pro Max 256G 钛金属’，纯语义检索会不会漏？……那你怎么把关键词和语义结合起来？具体融合策略是什么？
直球架构
说说你在RAG系统里用了哪些检索方法？技术选型怎么考虑的？针对检索效果做了哪些优化？比如索引切分、查询改写、重排序这些具体怎么落地？
这道题不要先报模型名，先说明语料和查询特征，再做检索选型。稠密检索擅长语义改写，但对编号、专有名词和精确数字可能不稳定；BM25 等稀疏检索正好相反，字面匹配强，却不擅长理解同义表达。两类查询都存在时，可以并行召回，再做融合。
融合方式常见的是 RRF 和线性加权。RRF 只使用结果名次，不要求两路分数同尺度，通常更容易建立基线；线性加权能表达业务偏好，但前提是先校准分数，并通过评测集确定权重。不能脱离数据直接断言某一种一定更好。
优化时应按链路定位问题。先检查文档解析和切块是否破坏语义，再看召回是否遗漏，之后才是融合和重排。Query Expansion、HyDE 或意图路由都有额外延迟和生成误差，不应该默认对所有请求开启。Cross-Encoder 只能改善已有候选的排序，不能救回根本没有召回的文档。
切块与元数据也是检索方案的一部分。标题、章节、表格位置、文档版本和权限标签如果在解析时丢失，后面换更强的 Embedding 也补不回来。多租户系统尤其要说明权限过滤发生在召回前还是召回后：召回后再过滤可能造成候选不足，也可能让不应访问的文档进入缓存或日志。增量更新还要验证旧向量删除、索引切换和查询缓存是否使用同一文档版本。
评测也要分层。召回阶段可以看 Recall@K，排序阶段根据单答案或多证据场景选择 MRR、NDCG，同时按专有名词、长问题、模糊问题等查询类型切片。线上还要记录引用正确性、无答案识别、P95 延迟、索引新鲜度和单次查询成本。只有指标定义、标注集和样本量都能解释，结果才可信。
消融实验要一次改变一个环节。例如先固定切块和召回候选，只比较有无重排；再固定重排，比较稠密、稀疏和混合召回。若同时修改 Embedding、chunk 大小和 Prompt，即使最终指标上升，也无法证明贡献来自哪里。还应保留效果变差的 query，说明方案的适用边界，而不是只展示平均分。
如果面试官要求结合项目，不要照搬一个现成故事。回答者需要补齐自己的文档类型、查询分布、原始基线、主要 bad case、方案取舍、评测方法和工程代价。没有做过消融或没有线上指标时直接说明，再给出下一步验证方案。这样既能讲清机制，也不会把教学示例包装成本人经历。