完整题目
在RAG系统中，您采用了哪些检索方法（如密集检索、稀疏检索等）？请说明选择这些方法的原因，并讨论可能的优化策略。
本文目录
答案要点
- 区分密集检索与稀疏检索的适用场景
- 说明混合检索的设计动机和融合策略
- 列举至少2-3种具体的检索优化手段
- 能结合业务场景解释选型原因
- 提及重排序（Rerank）在检索流程中的作用
核心检索方法
1. 密集检索（Dense Retrieval）
- 基于Embedding模型（如BGE、M3E）将query和文档编码为稠密向量
- 优势：语义理解能力强，能捕获"汽车"和"轿车"的语义关联
- 适用：开放域问答、语义相似度高的场景
2. 稀疏检索（Sparse Retrieval）
- 传统BM25或TF-IDF，基于词项匹配
- 优势：精准匹配专有名词、ID、代码片段；可解释性强
- 适用：关键词明确的查询、长尾实体检索
3. 混合检索（Hybrid Retrieval）
- 实际生产中的主流方案：Dense + Sparse并行召回
- 融合策略：线性加权（α·Dense_score + (1-α)·Sparse_score）或RRF倒数排序融合
选型原因（字节场景）
- 内容平台场景：用户query口语化严重，需要语义理解 → Dense为主
- 电商/搜索场景：商品ID、品牌名需精准匹配 → 必须保留Sparse
- 成本权衡：全Dense需GPU资源，Sparse在CPU即可低延迟服务
关键优化策略
| 层级 | 具体手段 |
|---|---|
| 索引优化 | HNSW参数调优（ef_construction/ef_search）、量化（PQ/IVF）降存储 |
| 查询优化 | Query改写（HyDE生成伪文档）、意图分类路由不同检索策略 |
| 结果优化 | 两阶段检索：粗排（Top-K召回）+ 精排（Cross-Encoder Rerank） |
| 数据优化 | 文档分块策略（按语义/结构切分）、元数据过滤预筛选 |
Rerank环节尤为重要：用轻量Cross-Encoder（如bge-reranker）对Top-100重排，NDCG@10提升15-20%常见。
换一种问法，检查是否真正理解
场景切入
假设你在做一个电商客服的RAG系统，用户问“我的订单怎么还没到”，系统需要同时理解“订单延迟”这个语义，又要精确匹配订单号。你实际会怎么设计检索策略？
层层追问
RAG里你一般怎么从文档里找答案？……如果只用向量检索，碰到“iPhone15”这种精确型号会不会漏？那你怎么把精确匹配加进来？……两个结果怎么融合？
直球架构
在RAG系统中，你采用了哪些检索方法？请说明选型原因，并讨论至少两种优化策略，包括索引、查询或重排序方面的具体手段。
练习口述回答 · 约4分钟
- 点题：本质是场景匹配与工程取舍
- 密集检索 vs 稀疏检索：边界划分
- 混合检索的设计动机和融合策略
- 优化重点：重排和索引优化
- 风险与收尾：判断姿态
这道题其实是在问一个很本质的问题：你面对一个具体的业务场景，怎么在语义理解和关键词精准命中之间做取舍。说白了，没有银弹，真正落地往往是两条腿走路。
先说[[密集检索]]，也就是用 [[Embedding]] 模型把 query 和文档都转成向量，依赖语义匹配。它的好处很明显，用户说“轿车”你能联想到“汽车”，口语化的表达也能对上。但它有个前提：你的语料质量够好，Embedding 模型得覆盖你的领域。如果用户查的是“退款流程”，但你的文档里全是“退货政策”，向量距离可能就不够近。
再说[[稀疏检索]]，就是传统的 [[BM25]] 或者 [[TF-IDF]]，基于词项匹配。它的优势在精准匹配专有名词、订单号、错误码这些场景，而且可解释性强，召回结果你很清楚为什么出来。但它的边界也很清楚：用户说“怎么退钱”，它可能就匹配不到“退款”这个词，因为词不一样。
所以实际业务中，我倾向用[[混合检索]]，也就是 Hybrid Search，把密集和稀疏并行召回，然后通过 RRF 或者线性加权融合。举个例子，在客服退款场景里，用户可能说“我买的东西坏了怎么退”，这时候密集检索能理解意图，召回“退款政策”相关文档；但同时用户也可能直接说订单号“OD20241001”，这时候稀疏检索能精确命中。两者互补，缺一个都不行。
这里有个坑：融合比例不是拍脑袋定的。如果密集检索权重太高，专有名词可能被淹没；稀疏检索权重太高，语义匹配又不够。我一般会用一批标注数据去调那个 α 系数，或者直接用 RRF 这种无参方案，效果稳定很多。
优化策略这块，我最看重的是[[重排]]。 粗召回可以拉很大，比如 Top-100，但真正给 LLM 的只有 Top-5 到 Top-10，中间这层必须靠一个轻量 [[Cross-Encoder]] 做精排。用 bge-reranker 对 Top-100 重排，NDCG@10 提升 15% 到 20% 很常见。没有这一步，前面召回再准也可能被噪声带偏。
还有一个常见失败场景：文档切分不合理。比如把一篇完整的技术手册按固定长度切，结果一个完整的概念被切到两个 [[Chunk]] 里，检索出来信息不全。我一般会按语义边界切，比如用 [[Sliding Window]] 加标题层级，或者用 [[Parent Document]] 策略，先检索子块，再拿父块给 LLM。
最后说判断收尾。我在这类系统里，会把混合检索加两阶段精排看作一个默认架构，但具体选型要看场景：如果业务里专有名词多、查询短，稀疏检索权重得提高；如果用户 query 口语化严重、内容平台，密集检索为主。更重要的是，上线前一定要做回放测试，拿历史真实 query 跑一遍，对比 Recall@K 和延迟，不达标就回滚。 因为很多问题只有线上数据才暴露得出来。