混合检索架构实践：向量+稀疏+图融合，召回率96%的工程之路

很多做搜索或者推荐系统的朋友，迟早会遇到一个尴尬的局面：数据量大了、业务复杂了，单靠某一种检索方式，要么召回不全，要么召回了但一堆乱七八糟的东西排在前面，用户体验直线下降。最近我这边在做一套混合架构的工程升级，目标很直接——在3000万级商品库和亿级用户行为链路上，把搜索召回率稳定做到96%以上，同时把接口响应压到毫秒级。这个项目代号就叫【混合架构7】，前六个版本其实都是探索，有纯向量方案的，有纯倒排方案的，也有简单拼接向量和倒排结果的，但真正把稠密向量、稀疏检索和图关系一起纳入工程层统一调度，是这次第七版才跑通的事。

这篇不是讲论文里的算法对比，就是工程落地过程中的真实记录：为什么这三个东西非要一起上、数据之间怎么建模、图关系从哪张业务表来、请求进来以后到底走了几条链路、为了压那几个毫秒我做了什么、以及96%召回率这个数字是怎么一步步抠出来的。

如果你是做搜索、推荐、广告召回，或者正在调研混合检索方案的架构师和开发，这篇文章应该能帮你省下不少试错的时间。

1. 项目背景与需求拆解

1.1 单一检索手段为什么不够用

先说一个朴素的问题：既然向量检索和倒排索引都是很成熟的技术，为什么非要混合？

我习惯拿一个例子说明白。用户搜“适合女生用的轻薄办公本”。

如果用纯粹的稠密向量检索，模型会把query映射成一个高维语义向量，在向量空间里找相似的内容。问题是，向量检索擅长捕捉“语义相近”，但它对“办公本”“轻薄”“女生用”这类带有强属性约束的条件，往往只是把语义相近的商品都拉回来，真正满足“轻薄”这个物理属性的商品可能排到很后面。也就是说，语义匹配不等于条件过滤。

如果用纯粹的稀疏检索，也就是传统倒排索引加BM25这类词频统计模型，它对关键词命中很敏感，搜“轻薄本”能召回所有标题含“轻薄”的商品。但一遇到同义词和口语化表达就抓瞎了。比如用户说“适合写论文的电脑”，而商品标题写的是“高性能笔记本”，字面几乎没有重叠，稀疏检索直接漏召回，这是它天生的问题。

至于图关系，它解决的是另一层问题。商品之间不是孤立的，它们共享类目、品牌、适用人群、关联搭配。比如用户搜“iPhone 15”，最应该召回的不只是手机本身，还包括配套的手机壳、数据线和充电器，或者至少提供一个可延展的关联结果集。图结构在表达这种“多跳关联”的时候有天然优势。但图检索本身做精确匹配并不擅长，你不可能用图遍历去替代全文检索。

所以答案就很清楚了：稠密向量负责语义泛化，稀疏检索负责关键词硬匹配，图关系负责类目和关联关系的上下文扩展。三者各有分工，也各有短板，混合架构就是把这三种能力放到同一个工程框架里统一编排，根据业务场景调整权重，而不是简单粗暴地做“线性叠加”。

1.2 从业务指标倒推工程要求

项目背景是这样：业务侧给的技术指标主要有两条，一条是P99响应时间控制在500毫秒以内，平均响应时间控制在80到100毫秒，这在搜索场景里差不多就是“毫秒级体验”；另一条是召回率，也就是核心top K结果命中率要达到96%以上。

为了说清楚“96%召回率”到底是什么口径，得先定义一下我们这边的评价方式。业务方人工标注了一批核心场景query，比如4100多组测试query，每组query有一个“期望召回的商品ID集合”，这些ID来自点击日志、加购记录和运营人工确认，总共约14万个有效商品。系统的目标就是把这14万个商品中属于对应query的商品尽可能多地捞出来，捞出来的比例除以期望集合的总数就是召回率。

一开始我以为是算法调参的问题，真做下来才发现，纯粹靠模型和检索策略能到90%就不错了，后面5到6个点的提升，几乎全是工程层和数据层的优化换来的。很多商品没有被召回，根本不是向量召回了但排序太低那么简单，而是这个商品的数据压根就没进到对应的召回通道里去。这就是工程问题，不是模型问题。

2. 整体设计与数据建模思路

2.1 图关系从哪里来：从MySQL业务表反推ER结构

很多朋友一听到“图关系”，第一反应就是要不要引入Neo4j，数据怎么灌，挺重的。其实做工程落地，图关系不一定非要搞出多大阵仗，可以思考的是：你已有的关系型数据库里，哪些表天然就是图结构。

我们这边主业务库是MySQL，大概400多张表。我挑出十一条核心的表关系做分析，从“商品主表”出发，还有“类目层级表”“品牌表”“商品属性表”“商品SPU与SKU关系表”“用户行为表”。这些表之间，维护着外键和关联关系。

说到这我想提一下，网上最近有个热词叫“mysql的表导出er关系图”，我们团队做图关系数据建模时用这个思路，原理就是把MySQL里通过外键、索引和查询条件建立的那些主外键关系识别出来，生成一张ER关系图，然后直接映射到图数据库或者图查询引擎的边上去。手工对着400张表抠关系会疯掉，但如果你先从ER图把核心链路上的关系理清楚了，再决定哪些实体入图，事情就简单多了。

我们最初图里只有4类节点和6种边关系：

• 节点：商品、类目、品牌、属性值
• 边：商品→类目（属于）、商品→品牌（属于）、商品→属性（拥有）、类目→父类目（层级）、商品→商品（搭配关联，来自行为日志）

后来发现这个模型太浅了，用户搜“运动鞋”，如果只做一层“运动鞋属于鞋类”的类目上卷，召回范围还是窄。所以后来加入了商品和商品之间的“行为共现”边，也就是大量用户都在同一会话里浏览过的两个商品，可以认为它们存在潜在关联。这个边的数据来自用户行为日志，每周离线聚合一次，量级在千万级别。

建议各位做图建模时，先想清楚一个问题：你希望图关系在检索链路里承担什么角色。如果只是给不同类目下的query做扩展词，那一层类目关系就够了。如果想让搜索能挖掘关联推荐，那行为共现边必须加。我们目前每次查询最多做两层图扩展，超过两层，延迟不可控，资源消耗也大，得在质量之间找出最优解。

2.2 稠密向量通道的数据准备与语义边界

稠密向量通道的核心工作是做query和商品的语义embedding。我们这边的商品总数是3000万，但并不是每个商品都平等对待。运营上有一个“核心商品池”的概念，大概800万商品，是近90天有曝光、有点击、有库存、状态正常的商品。早期我们给全部3000万商品都做embedding，但发现向量索引一大了，延迟就上来了，而且大量低质量长尾商品也被召回，指标反而变差。

做稠密向量检索前必须先做数据清洗和分层：

• 第一层是状态过滤，商品必须是上架状态，被运营下架的商品直接不进入召回池
• 第二层是质量过滤，有图片、有标题、有品牌、有类目信息的才进入向量池
• 第三层是时效分层，核心池的向量保持实时更新，长尾池的东西可以两天更新一次

向量模型的选型也是绕不开的话题。我们尝试过纯BERT类的中文模型，效果好，但单条商品embedding的耗时在CPU上要上百毫秒，这个量级完全没法上线。后来折中用了蒸馏过的轻量模型，精度掉了一些，但单条embedding的耗时降到了十几毫秒，配合GPU批量推理，全量800万商品大约五六个小时就能跑完一轮，边际成本可控。

embedding的粒度业界也有争议。有人用整条商品详情页的文本做向量，有人只用标题。我们的经验是：如果只用标题，跑出来的向量太稀疏，很多同义表达匹配不上；如果加上详情页，噪声又会变大。最终用的策略是拼接“标题加核心属性加三级类目名”的方式，类目名是决定性的，它相当于给向量模型提供了先验知识。

另外我们加了多向量策略，同一件商品不用一个向量，而是用三个向量表示：标题向量、类目向量、场景向量，三者分开存。query过来以后分别跟三个向量检索，然后合并排序。标题向量解决相关性，类目向量解决类目约束，场景向量解决用户意图泛化。这个设计对后面的召回率提升帮助很大，后面我会细讲。

2.3 稀疏检索通道的索引升级

稀疏检索这块，很多人直接用Elasticsearch的默认分词器，跑通了也就不再管了。但我建议每一个做生产环境的人都认真看一下自己的分词链路，因为这个环节影响的是召回率的下限。

我们线上最早用IK分词器加自定义词典，效果一般，很多商品里的专业术语、英文品牌词、型号词都切得稀碎。后来升级为“多路分词并存”的索引方式。简单说，同一段文本不只用一种方式分词，而是同时建立多组字段：

• 精确词字段，保留原始完整词，比如“MacBook Pro 14寸”，保留“macbook pro”这个完整品牌词
• 细粒度字段，拆成更细的term
• 同义词字段，扩展开来的同义词
• 拼音前缀字段，有些用户会用拼音首字母搜

这样索引体积的确变大了，膨胀比大概在2到3倍，磁盘成本能接受，但召回率提升明显。原来搜“mbp”可能什么都找不到，现在通过拼音字段能关联到“MacBook Pro”。还有个好处是英文大小写、简繁体这些也都在索引层面做归一化，不用跑到查询层去做复杂处理。

我特别想强调一点：稀疏检索的召回率优化，与其不停调BM25参数，不如把时间花在分析bad case上。BM25的k1和b参数调来调去，对整体召回率的影响可能只有零点几个百分点，但如果你发现大量query存在分词不合理、关键词缺失的问题，那是结构性的缺陷，调参救不了。这是我们做完整轮优化后的一个体会。

3. 工程层实现与查询链路设计

3.1 检索组件选型与核心权衡

混合检索涉及的组件不少，每个组件选型都有讲究。我们最终用的是：

• 稠密向量检索：Milvus，800万向量，768维，用IVF_PQ索引量化后放到内存
• 稀疏检索：Elasticsearch集群，存储倒排数据，我们用的是7.x的自建版本
• 图关系存储：Neo4j社区版不算太合适，我们在生产用的是NebulaGraph，性能更高一些，不过如果你公司Neo4j用得熟，Cypher表达能力也很强
• Redis：做结果缓存和向量缓存
• 召回编排层：Java服务，自研的召回路由组件

这里有一个架构上的教训。最早我们想把三个通道“揉”到一个服务里，想着减少网络开销，但发现这给开发协作造成了很大阻力，向量组在改索引参数，搜索组在调分词，图组在建边策略，互相干扰很大。后来拆成独立的三个召回服务，上游编排层通过RPC并行调用。

拆服务的代价是多几次网络跳转，本地测试环境单次RPC大约是0.5到1毫秒的局域网开销，换来的是各团队可以独立发布、独立扩容、独立降级。我认为这个取舍非常值得。

3.2 一个查询请求的完整调用链

拿一次真实请求为例。用户在搜索框输入“通勤小挎包女”，点击搜索，请求打到网关，然后进入编排服务。编排服务会做以下几件事：

第一步是query预处理。包括拼写纠错、query归一化、词权重计算。同时对query做分类，判断它偏向通用意图还是带有明确属性约束的意图。

第二步是并行发起三路召回。编排服务生成三个异步任务，同时调向量召回服务、稀疏检索服务、图关系召回服务。三路任务的超时设置各不相同：

• 向量召回设80毫秒超时
• 稀疏检索设60毫秒超时
• 图关系召回设50毫秒超时
• 只要有一路先返回了，编排层就先拿结果，不等最慢的那一路

第三步是合并候选集。三路召回的product ID先做并集去重，这里注意，不是简单的并集，而是给每一路设置了一个“保底配额”，即不管其他路怎么调权重，每一路至少要保留多少个结果进最终候选池。这么做是防止某一路因为排序策略太激进，把好结果全部截断了。

第四步是精排。候选集进来后，先用一个轻量级的cross-encoder模型做相关性打分，性能卡在20毫秒内，然后结合业务规则，例如类目约束、价格区间、库存状态和运营加权，做最终的排序调整。这里如果从头到尾跑大模型的精排，毫秒级就是做梦，所以精排模型也被刻意简化了。

整个链路的平均耗时我贴一个实测数据给大家参考：

• 整体P50响应：92毫秒
• 整体P99响应：485毫秒
• 其中向量召回通道平均耗时：35毫秒
• 稀疏检索通道平均耗时：28毫秒
• 图关系通道平均耗时：18毫秒（含两跳路径扩展）
• 融合排序耗时：20毫秒

3.3 融合排序里的权重动态调整

三路召回的候选集合并后，最关键的是怎么给每个候选打分。我们用的核心公式是一个加权融合分：

final_score = w1 * vector_score + w2 * sparse_score + w3 * graph_score + business_bias

这里面的w1、w2、w3不是拍脑袋定死的，而是根据query场景动态调整。比如用户输入的是一个明确的品牌型号词，比如“索尼a7m4”，那稀疏检索通道的权重应该更高，因为这类词靠精确匹配就够好，向量通道反而容易拉进一堆外形相似的杂牌相机。反过来，用户输入的是模糊的场景描述，比如“适合露营用的灯”，向量通道的w1要大，因为需要语义泛化来找那些标题没有写“露营”但本身是户外灯的商品。

权重怎么定？我们采用了一个朴素但有效的办法。4100组人工标注query按场景标签分类，然后用网格搜索加十折交叉验证，把每一天的调权结果记录到配置中心，线上热更新。也就是说，我今天改了权重，明天就能看到召回率变化。

我建议不要过度设计这个融合公式，毕竟在线搜索讲究稳定可控。能用一个可解释的加权公式，就不要上复杂的learning to rank模型。如果你后续要把召回率再往上提，可以考虑在精排阶段引入FFM或者LightGBM模型，但这是下一阶段的事了。

4. 毫秒级响应优化实战

4.1 向量索引的倒排量化参数选择

向量检索要做毫秒级，第一件事就是压缩搜索空间。全量800万商品、768维的向量，如果做暴力计算，一次查询的耗时是不可接受的。我们最终选择了Milvus的IVF_PQ组合，也就是先做倒排粗聚类，再做乘积量化。

有几个参数是用实际压力测试敲定的：

• nlist粗聚类中心数，我们设了4096
• nprobe探测中心数，从16到64都测过
• PQ的m参数，把768维切成了96段，每段用8bit量化，压缩比大约是8比1

最终线上nprobe取32。探测太少了会漏召回，太多了查询就慢。33毫秒左右的召回延迟就是在这个参数组合下测出来的。如果业务上对精度要求更高，可以调大nprobe和更底层的EF参数，但这需要和延迟做交换。对召回场景而言，我们允许向量召回阶段损失一些精确率，反正后面还有融合排序兜底。

内存占用方面，800万向量768维如果用float32存储，一个向量大概3KB，800万就是24GB。产品量化后，一个向量差不多370字节，整份索引大概3GB，一台机器就能扛住。如果你的单机内存扛不住，建议优先用量化而不是拆分到多台机器，跨机gather的代价很可能比你想的大。

4.2 缓存分层与热点数据隔离

毫秒级响应靠裸查是不可能稳的，尤其是热门query的并发可能冲到几千QPS，如果每个请求都完整走一遍三路召回加融合排序，资源开销和响应抖动都没法接受。所以缓存分层是必不可少的设计。

我们做了三层缓存：

• 第一层是JVM本地缓存，我用的Caffeine，缓存时间只有15到30秒，主要针对超高热度的query，比如节假日大促时期的那几十个核心词。本地缓存命中后，响应时间可以压到5毫秒以内
• 第二层是Redis分布式缓存，缓存时间2到5分钟，针对次热query。命中这一层大概要再加3到6毫秒
• 第三层才是真正的全链路实时召回

缓存时间为什么设这么短？因为商品数据的变化非常快，库存、价格、上下架状态都是分钟级甚至秒级变化。你要是缓存十分钟，很可能用户看到的结果里已经有不少无货商品了，体验会很差。

这里我想提醒一点：本地缓存和Redis缓存一定要设置合理的失效策略，而且要做结果中的商品ID与最新状态的对拍。也就是说，从缓存拿到候选集以后，不是直接把商品信息返回给用户，而是先批量查一次Redis里最新的商品状态，把下架和无货的商品剔除掉。这一步对用户体验很重要，但也意味着即使缓存命中了，下游依赖还是要去掉一大批。

4.3 离线预热与冷启动兜底

除了缓存，还有一个容易被忽略的点是冷启动链路。一个新上架的爆款商品，还没积累用户行为，也没有足够的上下文数据，很难被图关系通道捞到，这不利于召回率的稳定。

我们做了一套“离线向量预热”的方案。每天凌晨，离线任务把当天新上架并且运营标记为重点的商品，用模型生成embedding，然后插入向量库的同时，更新稀疏索引和“新品”标签。白天如果用户搜到了相关query，新品可以借助“新品加权”的规则直接进入候选池。

图关系通道的冷启动也做过一个trick。我们没有现成的行为共现边，就尝试用“同品牌加同三级类目”作为替代关系。比如有两款耳机都是“品牌A”、都属于“蓝牙耳机”类目，那我们就把它们构建一条弱关联边。虽然这种关系的强度不如真实行为共现，但至少让冷门新品有了被图关系通道召回的路径。实测下来，新品的7日搜索曝光量提升了大概20%。

5. 召回率攻坚：从90%到96%的现场实录

5.1 召回率不达标时，先查数据而不是查模型

在项目中期，我们的召回率一直卡在90%左右。当时第一反应是“向量模型效果不够好”，或者是“权重没调对”，于是花了一周去调模型、调权重，结果指标几乎不动。

后来团队做了一个动作：把300多个bad case拉出来，逐个看那个期望召回的product到底漏在哪一条链路。一查发现，超过一半的漏召回商品，根本没有进入任何一个召回通道，不是被排序压掉了，而是数据压根不存在于索引里。

原因让人哭笑不得。有一批商品是通过供应商系统同步的，同步流程里有一个状态字段，新同步的商品会先进入一个“待审核”状态，而我们的召回服务在捞数据时只处理了“已上架”状态，待审核的商品就一直躺在数据库里，没有同步到ES，也没生成向量。这是典型的数据管道缺陷，和数据无关，和模型更无关。

修好数据管道后，召回率直接跳了3个多点。这是我在这个项目里学到的最深刻的一课：召回的瓶颈往往不在顶部算法，而在底层的数据完整性上，这在很多系统里都是一样的。

5.2 图关系通道从“点缀”变成“刚需”的转折

图关系通道在这次项目前一直被认为是“锦上添花”，前期效果确实不突出。因为图关系召回的候选集和向量、稀疏两路的重合度太高了，比如搜“手机”，两路都把iPhone、华为、小米拉回来了，图关系再拉一遍，没有增量，只是浪费计算资源。

转折发生在优化“细分场景query”的时候。用户搜“iPhone 15手机壳”，稀疏检索召回的都是标题里带“iPhone15”和“手机壳”的商品，精准是精准，但量很少，而且很多是杂牌。向量通道召回了点语义相关的，比如手机壳周边配件，但相关度又不够。这时候图关系通道的价值就凸显了：通过商品节点“iPhone 15”往下坑，找到所有行为日志里与它高频共现的手机壳、保护膜、镜头膜、充电器，等于做了一个关联推荐式的召回。

做这类场景的调优时，我把图关系通道的触发条件限定为：query里包含明确的类目词或型号词，例如“手机壳”“充电器”“支架”，同时前缀命中某个特殊型号词。如果query太泛，比如就搜“手机”，图关系通道候选中权重就要降低，否则会喧宾夺主。

改造后，抽样测评了1400条细分场景query，整体准确率提升明显，并且为96%的召回率贡献了大约1.5个点。图关系在这个项目里的角色，也从“可选项”变成了必需项。

5.3 从四路召回加为多向量召回

刚才讲到我们给每个商品准备了三份向量，标题向量、类目向量、场景向量。这个设计最直接的好处是：同一个query可以同时与不同角度的“商品表示”做匹配。

举个例子，用户搜“秋冬风衣女中长款”，标题向量通道能召回标题文本整体相似的，比如“2024新款风衣女中长款”。但如果商品标题写的是“秋季新款外套女 中长款收腰显瘦”，它的标题向量与query的距离可能不近，却与“风衣”类目向量很近，类目向量通道就能把它捞回来。而场景向量通道还能再帮一把，把那些在穿搭场景内容里高频出现的、带着风衣属性的外套商品也带上来。

三路向量的召回结果先分别截断，再合并回去。怎么截断很讲究。目前线上是三路各自取top 2000，再合并去重进精排。如果只靠一路向量取top 2000，会把很多语义看似不近但实际是正确结果的商品漏掉，三路的边际贡献差不少。

多向量方案带来的索引成本大约是3倍，每一路查询都需要扫描一次。如果在单路查询本身已经要扫描几十毫秒的情况下，三路就是近100毫秒，直接爆炸。所以这里需要依赖向量库支持多向量同时查询，或者将三个向量合并为一个复合向量。如果你们的向量库不支持多路查询，也可以用加权拼接的方式合并成一个长向量，效果稍弱，但查询延迟能降下来。

5.4 评测集怎么建才不会被“过拟合”给骗了

回到96%召回率这个数字本身，我想提醒大家一个容易被忽略的因素：评测集本身的构建质量。

我们最终线上评测集不光有原始标注的4100组query，还引入了每月回放的线上搜索日志。如果某件商品在某次搜索后被用户点击、加购、下单，我们都会将“商品是否出现在该query的召回结果里”作为一次召回率样本。这种方式比人工标注覆盖面广，能暴露出不少长尾场景的bug。

但回放日志有一个坑：反馈有偏。点击和加购率高的是热门爆款，这些很容易被召回，会导致评估出来的召回率虚高。所以我们还是保留了人工标注的4100组query作为基准集，每次调优先看基准集分数，再看线上回放，两边对上了才算数。

此外建议各个团队都建立一个“bad case回归集”。每周收集上一周所有漏召回且被用户投诉或重点运营关注过的case，加入回归集，防止修复的bug下次改版时复发。没有回归集，优化就很容易变成打地鼠一样的拉锯。

6. 常见问题与排查技巧快查表

这部分整理一下字节跳动工程团队踩坑时积累的实用排查思路。我自己作为一线执行人员，每次上线前都要过一遍这些清单，排查效率高不少。

上面这些case里，数据管道断链和缓存击穿是最常见也最容易被忽视的。很多团队花大力气调模型，最后发现是Elasticsearch里有大量脏数据，这种情况很普遍，建议排查问题永远先确认数据对不对，再调算法。当你怀疑模型不行的时候，先花半天检查一遍链路里的每个数据段，很可能会有意外发现。

关于图关系通道，还有一个排查小技巧分享给你。如果对图查询结果的质量存疑，可以直接在调试环境里把图数据库的查询语句跑一遍，把扩展后的节点路径都打出来。很多时候不是关系错了，而是扩展层数太深导致引入了很多弱关联的结果。我们目前的默认配置是，图通道最多扩展两跳，第三跳基本不参与召回，最多给个性化推荐系统使用。

性能方面的建议也是实操出来的结论。向量检索的nprobe并不是越大越好，我们在800万这个数据规模上做过详细测试，从nprobe=16到nprobe=64，召回率提升不超过1.5个百分点，但延迟从25毫秒上升到55毫秒。这不是线性关系，到后面是投入产出比的急剧下降。如果你的系统对延迟极其敏感，建议就压在32左右，然后通过图关系和稀疏通道补足那1.5个点，让不同通道相互补位，比单通道追求极限性价比高得多。

7. 关于这套架构的扩展方向与后续规划

如果站在现在的节点往后看，这套混合架构能扩展的方向还有几个。

第一个是图关系通道会从“商品关联”扩展到“用户意图分群”。我们已经积累了比较丰富的用户点击和购买行为数据，下一步计划把“近期偏好某类商品的人群”作为图中的一种节点类型，然后让query在人群节点和商品节点之间做路径查找。典型场景是“给近期浏览过户外装备的用户推荐新上架的露营灯”，这不再是纯关键词检索能解决的问题了。

第二个方向是查询侧的弱语义理解。目前query的处理还是偏规则的：分词、专名识别、类目映射、买点提取。有些地方准确率不够稳，尤其当query是口语化长句的时候，规则很难覆盖。后续我考虑把query理解升级为基于小模型的方式，但前提是推理延迟要控制在3到5毫秒以内，这需要单独做模型压缩和工程优化。

第三个方向是预热范围扩展。我前面说了离线预热只覆盖新商品，做的是被动召回。更理想的做法是从用户的行为日志和行业日历里挖掘未来可能的热点query，提前把相关商品的向量、倒排、图关系都更新到位。比如大促前瞻活动机制会主推哪些商品，哪些潜在的流量词会出现，这套预热系统理论上可以把搜索引擎的一大段延迟从链路里“预支”出去。

如果你正在设计一套类似的系统，我个人在实战里的体会是：方案设计期一定把“链路可观测性”放在优先位置，把trace日志、慢查询日志、各通道的耗时和召回量指标从一开始就全部埋好。数据驱动决策是项目中期以后的核心，否则改了一堆也不知道是谁起了作用。

写到这里，我最后再分享一个非常细致但容易被忽略的工程细节。我们线上最终给每个商品分配了一个全局唯一的item_key，这个key既用于向量库中的ID，也用于Elasticsearch中的doc_id，也用于图数据库的顶点ID。所有通道都用同一个ID体系，调试的时候拿着item_key可以一路查下去，从原始MySQL数据查到图关系路径，几秒钟就能定位某个商品为什么没被召回。混合检索系统最怕的就是各通道ID不统一，到时候你拿着商品ID去对图数据库格式不对，去对ES格式也不对，排查一个问题搞一晚上。这是踩坑之后总结的一条铁律，你如果也要做混合检索，请在一开始就立好这个约定。