完整题目
在大模型应用开发中，您通常会选择哪些检索方法？请说明选择这些方法的技术考量和使用场景。
本文目录
答案要点
- 能区分稠密检索与稀疏检索的适用场景
- 理解混合检索的融合策略（如RRF）
- 知道何时需要重排序（Cross-encoder）
- 掌握查询改写/扩展技术（HyDE、多查询）
- 能结合业务场景说明选型依据
核心检索方法及选型
1. 向量检索（Dense Retrieval）
- 技术：Embedding模型（BGE、M3E、OpenAI-ada）+ 向量库（Milvus/Faiss）
- 场景：语义匹配、长文档理解、跨表述查询（如"苹果价格"→"iPhone多少钱"）
- 考量：对短查询效果差，需配合查询扩展
2. 稀疏检索（BM25/TF-IDF）
- 技术：Elasticsearch、Lucene倒排索引
- 场景：关键词精确匹配、ID查询、数字/专有名词检索
- 考量：零成本、可解释性强，但语义理解弱
3. 混合检索（Hybrid）
- 做法：向量+稀疏双路召回，RRF或线性加权融合
- 场景：通用RAG系统标配，兼顾语义与精确匹配
- 关键：融合权重需根据业务调优，通常α=0.5-0.7偏向向量
4. 重排序（Re-rank）
- 技术：Cross-encoder（BGE-reranker、Cohere-rerank）
- 场景：召回Top-K后精排，计算成本高但精度提升明显
- 取舍：在线延迟敏感时，可离线预计算或裁剪候选集
5. 查询改写（Query Transformation）
- HyDE：用LLM生成假设文档，再用该文档做向量检索
- 多查询扩展：LLM生成3-5个变体查询，并行检索后去重
- 场景：用户问题模糊、短查询、专业术语对齐
字节场景下的典型选型
| 场景 | 方案 |
|---|---|
| 抖音电商客服（商品/订单查询） | 混合检索 + 结构化过滤（类目、店铺ID） |
| 飞书知识库（长文档问答） | 向量检索 + 重排序 + 上下文压缩 |
| 搜索广告（Query-Ad匹配） | 双塔模型在线向量召回 |
核心原则：没有银弹，先做Badcase分析，再决定加稀疏、加重排还是改Embedding模型。
换一种问法，检查是否真正理解
场景切入
假设你现在做一个电商客服RAG系统，用户问“上次买的充电宝能退吗”，你准备怎么检索订单信息和商品条款？是只用向量检索，还是也会考虑关键词匹配？
层层追问
做RAG的时候，召回这一步你一般用什么方法？……那如果用户问题很短，比如“价格”，直接向量检索效果不好怎么办？……你会不会考虑把BM25和向量结合起来？融合的时候怎么处理得分归一化？
直球架构
请你列举一下在RAG应用里常用的检索方法，并说明每种方法适合什么场景，选型时主要考虑哪些技术因素？比如稀疏检索、稠密检索、混合检索、重排序这些，你分别在什么情况下会用？
练习口述回答 · 约4分钟
- 检索选型本质是语义匹配 vs 精确匹配的权衡
- 混合检索是标配，但融合策略和重排才是关键
- 查询改写解决短查询和模糊问题
- 落地风险：数据分布、延迟、一致性
这道题其实是在问，怎么在语义理解和精确命中之间做权衡。检索方法很多，但真正落地时，没有哪个是万能的，往往是几种方法组合着用。
先说最基础的，[[稠密检索]]和[[稀疏检索]]的边界。稠密检索靠 [[Embedding]] 做语义匹配，比如用户问“苹果价格”，它能召回“iPhone多少钱”这种同义表述，适合长文档、跨表述的查询。但它的弱点是短查询效果差，而且对专有名词、数字、ID 这类精确信息不敏感。反过来稀疏检索，像 [[BM25]] 和 [[TF-IDF]]，基于关键词倒排，精确匹配很强，比如查订单号、错误码，它零成本、可解释性强，但语义理解基本没有。
所以真正落地的 [[RAG]] 系统，[[混合检索]]是标配。把向量和关键词两条路的结果融合起来，常用 RRF 或者线性加权。但这里有个坑：融合权重不是固定不变的，得根据业务调。比如电商客服场景，用户问“我买的那个红色连衣裙还没发货”，语义匹配更重要，我会把向量权重调到0.7；但如果用户直接报订单号，那 BM25 的权重就要拉高。融合之后还有个关键步骤，[[重排]]，用 [[Cross-Encoder]] 做精排，虽然计算成本高，但精度提升非常明显。不过线上延迟敏感时，我会限制重排的候选集大小，比如只对 Top-50 重排，或者离线预计算一些高频查询的结果。
再一个就是查询改写。用户的问题经常很模糊，比如“退款政策”，直接检索效果不好。我会用 HyDE，让大模型先生成一个假设的文档，再用这个文档去检索，相当于把模糊的查询扩展成完整的表述。或者用多查询扩展，生成几个变体并行检索，最后去重，这在用户问题很短或者专业术语不对齐时特别有用。
举个例子，电商客服场景。用户问“我申请退款但商家说已经发货了”，这个查询既包含语义，又包含精确的订单状态。我的方案是：先用混合检索召回相关文档，然后用规则把订单号提取出来做结构化过滤，最后用 Cross-Encoder 重排。如果召回结果里没有直接答案，再触发查询改写，重新检索。
落地风险我特别关注三点：一是数据分布变化，比如双十一期间查询意图分布跟平时完全不同，线上需要监控 Recall 和延迟，如果指标下降，可能要重新调权重或者换 Embedding 模型；二是延迟，重排和查询改写都会增加耗时，线上要设超时和降级策略；三是一致性，比如混合检索的分数归一化做不好，会导致融合结果不稳定。
另外，当数据量特别大或者查询特别多样时，纯向量检索的 [[ANN]] 召回质量可能下降，这时候我会考虑用 [[ColBERT]] 这种细粒度交互模型，或者做 [[Self-RAG]] 让模型自己判断要不要检索，而不是每次都用同样的流程。
所以整体上，我会把检索选型看成一组可插拔的模块，没有银弹，核心是先做 Badcase 分析，看失败是语义匹配不够，还是精确命中缺失，再对症下药。