RAG检索方法如何优化？
对比 BM25、向量检索与混合检索,技术选型与性能优化策略
原题：在RAG系统中，常用的检索方法有哪些？请对比不同方法的优缺点，并阐述在实际项目中如何进行技术选型以及后续的性能优化策略。
重排与优化 · 字节真题
30 秒回答
- 能列举至少3种检索方法（向量检索、关键词检索、混合检索等）并对比优缺点
- 阐述技术选型的核心考量维度（数据特征、延迟要求、精度要求、成本）
- 给出具体的性能优化手段（索引优化、重排序、缓存策略）
- 体现工程权衡思维，而非单纯罗列技术
回答与解析
答案要点
- 能列举至少3种检索方法（向量检索、关键词检索、混合检索等）并对比优缺点
- 阐述技术选型的核心考量维度（数据特征、延迟要求、精度要求、成本）
- 给出具体的性能优化手段（索引优化、重排序、缓存策略）
- 体现工程权衡思维，而非单纯罗列技术
常用检索方法对比
| 方法 | 核心机制 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|---|
| 稠密向量检索 | Embedding语义匹配 | 语义理解强，容错性好 | 对长尾/专业术语弱，计算成本高 | 开放域问答、语义相似查询 |
| 稀疏向量检索 | BM25/TF-IDF关键词匹配 | 精准匹配强，可解释性好 | 语义鸿沟，同义词失效 | 专业术语、ID类查询 |
| 混合检索 | 稠密+稀疏融合 | 兼顾语义与精准 | 系统复杂，融合策略需调优 | 通用生产环境首选 |
| 图检索 | 实体关系遍历 | 多跳推理强 | 构建成本高，延迟大 | 知识图谱场景 |
技术选型考量
数据特征决定底座
- 结构化/半结构化数据多 → 优先关键词+过滤条件
- 非结构化文档多、用户问题口语化 → 稠密向量为主
- 专业领域（医疗/法律）→ 必须混合检索，稀疏兜底
延迟与精度的权衡
- 在线场景（<100ms）：HNSW索引 + 粗排截断Top-K
- 离线/准实时：可接受IVF-PQ的精度损失换内存
成本约束
- 向量维度、索引类型直接决定内存占用；百亿级需考虑分片+磁盘索引方案
性能优化策略
索引层
- 量化压缩（PQ/SQ）：内存降80%，精度损失可控
- 分层索引：高频走内存HNSW，低频走磁盘IVF
检索流程
- 两阶段检索：向量召回Top-100 → 轻量重排模型精排Top-10
- 查询改写：HyDE、Query2Doc扩展，解决短查询语义缺失
系统层
- 结果缓存：高频Query直接命中
- 异步预计算：热门文档块预加载
实际项目中，建议先混合检索跑通基线，再通过Badcase分析决定优化方向——是向量模型不够准、还是召回不足、或是融合权重不对，对症下药。
口语版讲法(约4分钟)
- 一句话定位：RAG检索的本质是平衡语义与精准
- 三种方法对比：稠密、稀疏、混合，边界划分
- 业务案例：企业合规文档检索，技术选型
- 优化策略：索引、重排、缓存
- 风险与判断：混合检索是基线，迭代靠Badcase
这个问题其实在问，RAG系统里怎么平衡检索的语义理解能力和精准命中能力。先说我的核心判断：没有一种检索方法能通吃所有场景，真正落地时往往是混合方案打底，再根据业务数据特征做取舍。
常用方法主要有三种。稠密向量检索，就是靠Embedding做语义匹配，比如用户问“退款多久到账”，它能匹配到“退单处理时效”这种同义表述，容错性很好。但短板也很明显，对专业术语和长尾实体很弱，比如搜“订单号A123456”，它可能拉出一堆语义相关的订单描述，就是找不到那一条。稀疏向量检索，也就是BM25或TF-IDF，走关键词精准匹配，对订单号、错误码这类结构化查询非常准，可解释性也强。但它有语义鸿沟，用户说“帮我查下最近一笔退款”，如果文档里全是“退货”“取消”“售后”，关键词就断开了。所以混合检索就是把两条路结合起来，先各自召回再融合排序，兼顾语义和精准。
举个例子，企业内部的合规文档检索。员工问“去年Q4的供应商审计报告”，用纯稠密检索可能把“审计流程”“供应商准入”都召回来，但真正要的是那份具体文档。这时候混合检索里，稀疏那一路用关键词“2023 Q4 供应商 审计”精准定位，稠密那一路用语义兜底，避免换词漏掉。前提是融合策略要调好，比如权重配比或者用Rerank模型二次排序，否则融合不好反而两头不讨好。
技术选型上，核心看数据特征和延迟要求。如果文档结构性强，比如有标题、时间、编号，我会优先把结构化字段做成过滤条件，再在正文上做向量检索。如果是开放域问答，用户问题很口语化，那就主攻稠密向量，但一定要加Hybrid Search兜底。延迟上，在线场景必须压到100毫秒以内，那就用HNSW索引加粗排截断，只取Top-200再过重排；离线分析可以接受IVF-PQ的精度损失来省内存。
性能优化方面，我一般从索引、流程、系统三层下手。索引层用Product Quantization对向量做量化压缩，内存能降80%，精度损失可控。流程层做两阶段检索，先用Bi-Encoder快速召回Top-100，再用Cross-Encoder精排到Top-10，这样既快又准。系统层加结果缓存，高频query直接命中，但要注意缓存失效策略，比如文档更新后要清掉相关缓存，否则用户拿到的是旧数据。
这里有个延伸点：很多时候检索效果不好，不是方法选错了，而是文档分块粒度没调好。比如一份采购合同，如果整块嵌入，用户问“违约金比例”，向量可能被合同主旨带偏；但如果切太碎，又会丢失上下文。我一般先用固定大小分块，再通过Badcase分析看是召回不足还是重排不准，决定要不要切更细或者加父子文档结构。
所以总的来说，我会把混合检索当成基线方案先跑通，再根据业务反馈迭代。我更倾向在工程上先保证检索的召回率，再通过重排和过滤提升精度，而不是一开始就追求完美。
关键一句:检索效果不佳时，问题常出在文档分块粒度，而非检索方法本身。
面试官还可能这样问
- 问法 1 · 场景切入
假设你在做一个电商客服RAG，用户问“昨天那个订单发货了没”，你会怎么去检索知识库？是用关键词匹配订单号，还是用向量找类似对话？这两种方法各有什么利弊，实际你会选哪种？
- 问法 2 · 层层追问
RAG系统里你一般怎么找相关文档的？……那如果用户问的问题很口语化，比如“那个东西能不能退啊”，纯关键词可能匹配不上，你怎么办？……混合检索的话，你怎么融合两种结果？权重怎么定？
- 问法 3 · 直球架构
说一下RAG系统中常用的检索方法，对比优缺点。然后结合一个具体场景，比如法律文档检索，你会怎么选技术方案？后续性能优化你从哪几个方面入手？