RAG检索方法如何优化？

这个问题其实在问，[[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分析看是召回不足还是重排不准，决定要不要切更细或者加父子文档结构。

所以总的来说，我会把混合检索当成基线方案先跑通，再根据业务反馈迭代。我更倾向在工程上先保证检索的召回率，再通过重排和过滤提升精度，而不是一开始就追求完美。