ES+Milvus双引擎RAG：图文混排知识库的检索融合实战

先抛个结论：纯向量检索解决不了所有RAG问题，纯ES更是会被口语化查询打到自闭。

我把这个结论的来龙去脉理清楚，是在一个真实的生产级图文混排知识库项目里验证过的。项目本身不复杂：企业产品手册、维修指南、FAQ，文本和配图混在一起，用户用自然语言提问，系统要能从海量内容里准确召回最相关的段落。最初大家觉得RAG嘛，文档切一切、embedding灌进向量库、问一句搜一下不就完了。等真跑到线上，各种问题就浮出来了——用户问"显示接口"匹配不到"DP接口"，问"便宜的4K屏"匹配不到任何带价格语义的内容，有时候明明答案是几十页前的插图，检索结果却把不相关的纯文本顶在最前面。

这篇文章主要拆解我是怎么把ES和Milvus组成双引擎RAG，并最终落到生产环境的。核心解决三件事：为什么必须双引擎而不是二选一、BM25分数和向量分数怎么归一化到同一把尺子、召回结果如何做重排融合才能让图文混排的命中率真正可用。适合正在做企业知识库RAG、或者想给现有检索系统加语义能力的团队参考，尤其适合图文混合内容的场景。

1. 为什么"双引擎"不是炫技：单一检索路线在图文场景下的致命短板

1.1 纯向量库在精确匹配上的失控

Milvus这类向量数据库，核心优势在语义召回。你把文本和图片分别过一遍CLIP或者SigLIP，映射到同一个向量空间，然后拿用户query的向量去算近邻，它确实能理解"支持DP接口的显卡"和"DisplayPort"之间的关系。

问题在于，向量检索对"精确"这件事非常迟钝。举一个我们线上真实踩过的例子：产品手册里有一条内容是"型号：GTX-4090-Ultra；接口：HDMI 2.1 / DP 1.4；功耗：450W"。用户问"GTX 4090 Ultra功耗多少"，向量检索能把这条召回来。但用户问的是"功耗低于500W的显卡有哪些"，整个知识库根本没有"低于"这个概念的精确表达，向量检索就是把分数最高的几条返回给你，它不会因为"450W"在数值上满足"小于500W"就把这条排在前面，它只认语义相似。

更麻烦的是型号和编号。产品库里有大量形如"ABC-100-X23"这样的SKU编码，向量模型经常把数字位搞混，"X23"和"X24"在语义空间里几乎重合，但业务上这是完全不同的两个东西。这种场景下，纯向量库里你一点办法都没有，只能靠过滤条件硬筛，或者接受糟糕的准确率。

1.2 纯ES的字符串匹配救不了口语化查询

既然向量搞不定精确匹配，那把系统整个换成ES行不行？也不行。ES的BM25全文检索在"关键词命中"这件事上非常强，型号、术语、精确短句，都是它的舒适区。但用户不会总是用精确术语提问。

比如用户问"你们有没有带DP口、价格还便宜点的显卡"，ES拿到这个query，分词之后可能匹配到"显卡"这个通用词，然后被大量包含"显卡"二字的页面淹没。它不理解"DP口"等于"DisplayPort"，也不理解"便宜点"是一种价格排序的意图，更不理解用户可能还想看到对应的显卡图片。知识库里的内容是图文混排的，单靠ES根本没法把图片相关的内容纳入召回体系，图片没有文本词频，不参与BM25打分。

1.3 双引擎的正确分工：精确与语义各司其职

所以双引擎不是为了架构好看，是两种检索模式的能力互补太明显，丢掉任何一个都会漏掉大量有效结果。

• ES负责精确检索、结构化过滤和元数据约束：产品型号、SKU编码、接口类型、维护日期、文档分类，这些该用倒排索引解决的，交给BM25和term查询。
• Milvus负责语义召回和跨模态图文匹配：文本query去匹配图片的语义向量，文本query去匹配口语化改写后的文本向量，让"DP口"和"DisplayPort"这种非字面匹配成为可能。

两条召回通道在并行阶段互不干扰，各自返回一批候选结果，进入融合层统一打分排序。这个架构思路本身不复杂，真正复杂的是后面要说的分数归一化和融合策略。

2. 图文混排场景下的数据建模与索引落库：段落粒度的核心设计

2.1 以"段落"为最小检索单元的图文统一模型

图文混排最难处理的，不是向量模型选哪个，而是数据怎么切、怎么建模。我的做法是，不管原文是一页PDF、一张流程图，还是一个多级标题下的章节，统一切到"段落"粒度，一个段落就是一条独立的检索记录。

段落分三类：纯文本段落、纯图片段落、图文混合段落。纯图片段落没有文本内容，只有图片URL、OCR出来的文字、以及图片的语义向量；图文混合段落则是文本和图片一起出现，文本以markdown格式保留图片引用位置。

{ "paragraph_id": "para_102938", "doc_id": "doc_0042", "doc_title": "GTX系列显卡安装指南", "category": "installation_guide", "product_model": "GTX-4090-Ultra", "text_content": "将显卡插入PCIe x16插槽，连接8pin供电线...", "image_url": "https://cdn.example.com/gtx-pcie-slot.png", "text_vector": "[0.023, -0.015, ...]", "image_vector": "[0.102, -0.086, ...]", "publish_date": "2025-03-14" }

这里有个很容易被忽视的点：一条段落记录同时保留text_vector和image_vector。原因在于，一个图文混合段落被召回后，前端要同时展示文本和图片才能给用户完整答案。如果只存文本向量，图片内容会全部漏检；如果只存图片向量，纯文本问题的语义匹配又变差。两个向量字段并存，才能保证无论用户从文本角度还是图片角度提问，都能命中同一条段落。

2.2 ES侧索引设计：元数据约束和BM25的配合

ES索引的设计重点是"该过滤的提前过滤，该分词的仔细分词"。字段上，除了text_content用标准的IK分词器或者你定制的行业词典，其他元数据字段全部走keyword或数值类型，这样在检索阶段可以拿product_model、category、publish_date做精确过滤。

实际项目里，我强烈建议在检索阶段先用元数据过滤缩小范围，再跑BM25。比如用户只看"安装指南"类目下的内容，就先把category限定住；用户提到了具体型号，就把product_model作为filter条件。这个习惯能显著减少BM25在高基数文档集合下的误匹配，也能给后面的分数归一化省掉很多麻烦。

ES侧我的索引mapping大致这样：

{ "mappings": { "properties": { "paragraph_id": { "type": "keyword" }, "doc_id": { "type": "keyword" }, "doc_title": { "type": "text", "analyzer": "ik_max_word" }, "category": { "type": "keyword" }, "product_model": { "type": "keyword" }, "text_content": { "type": "text", "analyzer": "ik_max_word" }, "publish_date": { "type": "date" } } } }

keyword字段一律不做全文检索，避免模糊匹配把范围搞乱。text_content和doc_title才走全文分词，并且我对doc_title执行了更高的boost，标题命中的段落比正文命中的优先级更高——这是从用户点击行为里总结出来的规律，标题相关性和用户最终想要的答案之间高度相关。

2.3 Milvus侧Collection设计：多向量字段与索引参数选择

Milvus这边的设计，取决于你的版本。Milvus 2.4之后的版本支持在同一个Collection里挂多个向量字段，我最新的项目就这么做：一个Collection里同时放text_vector和image_vector，两个字段用不同的索引类型和参数。如果你的版本还停留在旧版，那就开两个Collection，用paragraph_id做外键关联，效果一样，只是检索的时候需要并行查两个Collection再合并ID。

我给图片向量用的是CLIP系列模型，文本向量用的是配套的text encoder，这样文本和图片天然落在同一个语义空间里，文本query可以直接检索图片向量。索引参数上，我测试下来比较稳妥的一套配置是：

这里有个坑：如果你选的是IP内积，向量入库之前一定要做归一化，否则内积结果会被向量模长严重干扰，长文本的向量模长天然偏大，导致检索结果无脑偏向长文本。归一化之后，内积等价于余弦相似度，语义可比性才有保障。

检索时，Milvus会返回很多命中的段落，但速度相对ES会慢一些，所以Milvus侧召回数量不要贪多，我一般控制在top 100以内。再多的话，重排阶段的计算压力会指数上升，而收益趋近于零。

3. 分数归一化：让BM25和向量分数真正"同台竞技"

3.1 两种分数的原生分布差多远

双引擎召回之后，你会拿到两套完全不同的分数体系。

ES的BM25分数，理论上范围是0到正无穷，实际运行中受文档长度、词频、字段boost影响非常大。有的query命中的文档BM25得分能到20多，有的query只有3、4分。这个分数本身没有"绝对含义"，只能在同一批检索结果里做相对排序。

Milvus这边，如果你向量归一化后用的是IP内积，分数范围会落在[-1, 1]；如果是欧氏距离，那是越小越相似，跟BM25的方向正好相反；如果用了某些embedding模型的原始cosine分数，范围可能是[0.6, 0.95]这种局部区间。

直接把两边的分数加在一起排序，是我见过最多的低级错误。你想想，一个BM25得10分的精确匹配，和一个cosine得0.85的语义匹配，谁更重要？数值上10比0.85大得多，但0.85的语义匹配可能才是用户真正想要的。反过来，如果把BM25缩放成0到1，两者的权重又无从谈起——到底语义占比高还是关键词占比高，根本没有依据。所以第一步必须做归一化，让两边分数落在可比的尺子上，第二步才能考虑权重和融合。

3.2 min-max、百分位与滑动窗口校准：三种生产可用的归一化方案

我把生产上验证过的归一化方案按推荐程度列一下：

方案一：min-max归一化，最直接但最不稳

def min_max_norm(score, min_score, max_score): if max_score == min_score: return 1.0 if score >= max_score else 0.0 return (score - min_score) / (max_score - min_score)

用当前这轮检索结果里的最小值和最大值做映射。优点是零成本、实时计算。缺点也很明显：每一轮query的分数分布都不一样，可能这轮query的BM25最高分是8，下一轮最高分是20，min-max归一化后8和20都会变成1.0，跨query之间完全不可比。如果你的融合策略需要根据语义权重和关键词权重做全局权衡，这个方案会让权重永远调不准。

方案二：百分位映射，用离线分布做校准函数

离线准备几百条代表性query，分别记录ES和Milvus的原始分数分布，算出5分位、50分位、95分位。线上查询时，用分位数做线性插值，把原始分数映射到0到1的百分位区间。

# 预先统计出的百分位，实际值按你的数据分布来 percentiles_es = {5: 1.2, 50: 3.8, 95: 15.7} percentiles_milvus = {5: 0.55, 50: 0.73, 95: 0.91} def percentile_norm(score, percentiles): if score <= percentiles[5]: return 0.0 if score >= percentiles[95]: return 1.0 # 取50分位和95分位做线性映射，也可以多段映射 return (score - percentiles[5]) / (percentiles[95] - percentiles[5])

这个方案的优点是跨query打分稳定，缺点是离线分位数分布可能随时间漂移。线上内容更新频繁的话，你得定期重算分位数。

方案三：滑动窗口自适应归一化，生产环境最推荐

用最近N次检索的分数来动态估算min和max，相当于给min-max加了一个滑动窗口。实现上可以用一个带遗忘因子的在线统计器，每一轮查询结束，把当轮的分数分布更新进去。

class SlidingScoreNormalizer: def __init__(self, window_size=200, decay=0.98): self.window = [] self.window_size = window_size self.decay = decay self.ema_min = None self.ema_max = None def update(self, scores): self.window.extend(scores) if len(self.window) > self.window_size: self.window = self.window[-self.window_size:] current_min = min(self.window) current_max = max(self.window) if self.ema_min is None: self.ema_min = current_min self.ema_max = current_max else: self.ema_min = self.decay * self.ema_min + (1 - self.decay) * current_min self.ema_max = self.decay * self.ema_max + (1 - self.decay) * current_max def norm(self, score): if self.ema_max == self.ema_min: return 1.0 return (score - self.ema_min) / (self.ema_max - self.ema_min)

滑动窗口的好处是能缓慢跟踪线上数据分布的变化，不会因为某一次奇怪的query导致整个归一化失效。线上我用的就是这个方案，效果比固定min-max稳很多。

3.3 归一化之后还需要做的三件小事

归一化不是结束，后面还有三个工程细节，少了任何一个效果都会打折扣。

第一，给每个引擎单独设置"可信分阈值"。归一化之后，ES低于0.15的结果基本是噪声，Milvus低于0.3的结果大概率语义不相关。融合之前先过滤掉这些低分结果，能显著降低后面重排阶段的压力。阈值不能拍脑袋定，要拿着线上真实query的标注数据去调，宁可多召回一点给重排，也不要一开始就错杀。

第二，两边归一化后的分数分布可能还是不对齐。比如ES归一化后经常集中在0.4到0.9，Milvus集中在0.1到0.6。这时候要通过一个"引擎置信权重"来对齐，不是简单乘个系数，而是对分数做一次幂变换或者log变换，让两边的分布形状接近。我在ES侧用过score ^ 0.8这样轻微的压缩，在Milvus侧用过score / (score + 0.2)这种饱和函数，具体参数从验证集上回归出来。

第三，归一化的输入要按业务类型分开。FAQ问答和产品参数查询的分数分布是完全不同的。FAQ语义匹配通常是Milvus分数高，产品参数查询经常是ES分数高。如果你把所有检索混在一个归一化器里，最后一定是两边打架。我的做法是按doc类型建了两套归一化器和融合权重，这样效果才真正稳定。

4. 从召回融合到精排：为什么RRF比加权求和稳，重排模型解决什么问题

4.1 加权求和的三宗罪

归一化做完了，很多人会顺手做加权融合：

score = 0.5 * norm_es + 0.5 * norm_milvus

这个公式看起来合理，实际上有三个坑。

第一个坑是权重难以标定。0.5和0.5看起来公平，但不同query下两边的靠谱程度完全不一样。有的query明显是精确型号查询，ES权重应该拉高；有的query是口语化描述，Milvus权重应该拉高。固定权重等于假设所有query的分布一致，这个假设在真实场景里基本不成立。

第二个坑是分数经过归一化后，仍然保留了"绝对分数"的部分误导信息。一个ES分数0.9的结果，可能是因为这一个文档特别短、BM25统计上占便宜，而不是它真的相关。加权求和没法区分"高分的可靠"和"高分的侥幸"。

第三个坑是可解释性差，线上调参全靠玄学。你说0.5不行改0.6，为什么改0.6？拿不出依据。一旦出问题，你根本不知道是归一化偏了还是权重偏了。

4.2 RRF融合：用排名替代分数，屏蔽分布干扰

RRF（Reciprocal Rank Fusion）的思路是彻底不看分数，只看排名：

def rrf_fusion(es_results, milvus_results, k=60): fused_scores = {} for rank, doc_id in enumerate(es_results, start=1): fused_scores[doc_id] = fused_scores.get(doc_id, 0) + 1.0 / (k + rank) for rank, doc_id in enumerate(milvus_results, start=1): fused_scores[doc_id] = fused_scores.get(doc_id, 0) + 1.0 / (k + rank) return sorted(fused_scores.items(), key=lambda x: x[1], reverse=True)

k值取60是RRF原始论文里的经验值，在实际项目中我也测过20、50、100，60确实是综合效果最好的。k越小，排名靠前的结果权重越高，融越发激进；k越大，排名的影响越平滑，相当于容忍更多长尾结果。60这个值在多数场景下能达到平衡。

RRF的好处在于，它绕开了分数大小不一致的核心问题，只保留"谁排前面"这个最稳定的信息，所以对归一化误差不敏感，对引擎差异也不敏感。ES召回的前3名和Milvus召回的前3名，哪怕两者分数分布差一个数量级，RRF也能公平地都给到高分。如果同一个doc在两个引擎的召回列表里都出现在前10，它的融合分会被自然放大，这正是"多重证据加持"的体现。

在双引擎RAG里，我的做法是：ES取top 50，Milvus取top 100，两者取并集后用RRF融合，再截断到top 50，交给后面的精排。这里有个细节——ES召回数量小于Milvus，是因为ES的BM25对精确匹配的精度更高，前面50条已经覆盖了大部分有效结果；Milvus语义召回范围广、噪声多，需要多捞一些给后面精排去筛选。

4.3 引入Cross-Encoder精排：RRF解决"召回"，重排解决"准"

RRF之后的结果，排序逻辑是"多引擎共同认可的程度"，还不是"和用户query真实相关的程度"。比如一个段落虽然被两个引擎都排到前10，但它可能只包含query里的一个侧面，整体上并不算一个好答案。这时候需要引入Cross-Encoder重排模型，对query和候选段落做一次真正的深度语义交互评分。

Cross-Encoder和向量检索用的Bi-Encoder原理不同。Bi-Encoder是把query和段落分别编码成向量再算相似度，速度快、可以离线建索引，但语义交互不足。Cross-Encoder是把query和段落拼成一个序列直接送进模型，让模型同时看两边的token做深度交互，效果更好但速度慢得多，所以只能用于精排阶段。

我用的是bge-reranker-v2-m3，重排的输入是"query + 段落文本"。对纯图片段落，输入是"query + OCR文本 + 图片向量对应的标签文本"，没有OCR的话就用图片的alt文本。一定要重排的还是比RRF融合后的top 50，而不是全量召回集，不然延迟扛不住。Cross-Encoder跑50条，每条大概几十毫秒，总延迟能接受。

精排输出的分数，才是最终排序依据。最后再在精排分数上叠加一个业务兜底逻辑：如果某个段落是精确型号匹配（比如SKU完全相等），给它加一个强加成；如果段落是配图段落且用户问题带"图"字或"长什么样"，给它提权。这些业务规则属于锦上添花，但确实能解决不少bad case。

重排模型对纯向量召回和纯ES召回的提升幅度，我们做了个对比实验：

数据说明，RRF已经把召回率抬上去了，但MRR（排序质量）还是不够，重排模型是最后一步把"正确答案排到最前面"的关键杠杆。240ms的延迟在内部知识库场景完全可接受，如果需要降到200ms以内，可以把重排范围从top 50缩到top 30，MRR损失很小。

5. 生产环境落地的几条实测避坑经验：双写一致性、延迟预算和监控指标

5.1 双写一致性：ES和Milvus数据不同步是怎么排查出来的

双引擎架构绕不开的一个问题是：同一份文档，既要写ES，又要写Milvus，两边数据怎么保持同步。

我们的初始方案是用Canal监听业务数据库的binlog，然后异步写ES和Milvus。上线头几天一切正常，直到有一天用户反馈"昨天刚更新的手册搜不到"。一查，ES里有这条数据，Milvus里没有；再过一会儿，Milvus来了，ES的refresh interval还没到。两边写入链路的速度天然不一致，加上异步重试，必然产生一个可见的时间窗口，在这个窗口里检索会漏数据。

排查链路是这样的：

• 确认ES里有没有：GET /index/_search按doc_id查到数据在。
• 确认Milvus里有没有：按主键query，数据确实缺失。
• 检查消费进度：发现binlog消费程序在写Milvus时因为向量模型推理超时，抛异常后进入了重试队列。重试队列是串行的，前面的任务堵住，后面的任务全部延迟。

修复方案是两件事。第一，写入端改为并行+独立重试，ES和Milvus分别维护各自的重试队列，失败互不阻塞，重试带上幂等ID，保证重复消费不会产生脏数据。第二，删除操作要双删，ES和Milvus主键一致，删除时必须两个引擎都删，只删一个会造成幽灵数据。Milvus按主键删除走expression过滤，注意确认删除实际生效，Milvus对删除的可见性有时延。

5.2 延迟预算分配：从用户点击到答案渲染的每一毫秒都花在哪了

生产级RAG必须算清楚延迟预算。用户感知到的延迟，一半以上来自检索链路，所以我把一次完整检索的延迟分成四个阶段：

总预算240ms，线上p99实测在290ms左右，主要波动来自Milvus的集群负载和重排模型的GPU推理排队。如果你们的业务对响应时间更敏感，我有几个亲测有效的降延迟手段：

• 向量检索的ef降到64，延迟能砍掉20%，召回率只损失不到1%。
• CrossEncoder改成小模型，比如ms-marco-MiniLM-L-6-v2，单条推理从40ms降到15ms，MRR降幅在3%以内。
• ES侧把refresh interval从1s调到5s，写入压力降了三分之二，查询侧基本无感。

5.3 监控什么才能知道检索质量在退化

RAG上线只是起点，检索质量会随着知识库内容变化、用户query分布变化而悄悄退化。只盯着系统延迟和CPU使用率远远不够，得监控业务层面的指标。

我维护的监控面板里，最重要的三个业务指标：

无结果率：每天有多少query最终一个段落都没返回。无结果率突然升高，大概率是embedding模型或向量索引出问题了。Top1命中率：抽样看返回的第一条结果是否为正确答案，这个指标和用户满意度直接挂钩。反馈闭环：用户点了"有帮助"还是"没帮助"，这个信号可以回流到重排模型的训练集里，做周期性微调。

技术上还要监控ES的慢查询、Milvus的segment状态、消费goroutine积压数量、跨引擎数据一致性差异条数。一致性差异条数这个指标尤其重要，我就是靠它发现过一次ES写入成功但Milvus丢失的老大难问题，后来在两边各加了一个校验任务，定期核对ID集合差异，超过阈值就报警。

最后分享一个经验细节：上线新embedding模型或新重排模型之前，一定要拿着线上真实query的历史记录做离线评测，否则模型换完你都不知道效果是变好了还是变差了。我们离线评测的测试集就是线上用户真实query和对应的正确答案段落，每周更新一次，任何模型替换都必须过这一关。我见过太多项目，模型换了半天靠直觉说"好像变准了"，一跑离线测试发现MRR掉了8个点，白白回滚一次。这种哑巴亏，吃一次就够了。