先说个背景。在智联招聘这个平台上，求职者和招聘者之间，怎么实现高效匹配，一直是个核心命题。

招聘者发布职位，想找到合适的人；求职者上传简历，希望找到心仪的坑。我们的目标很明确：给双方提供最精准的匹配结果。

具体到搜索推荐场景，候选人或职位列表会经历召回、粗排、精排、重排一连串筛选，从亿级候选集中挑出最合适的简历或职位来展示。

在召回阶段，除了传统的规则召回，我们还引入了向量召回。这次重点聊的，就是其中一种向量召回方式：用职位去召回简历，也就是JD2CV。

为了方便，下文把职位简称为JD，简历简称为CV。

向量召回实现方式

模型训练样本怎么选？

正样本很简单，直接从系统日志里拿那些有正向交互的JD-CV对。

负样本分三块：

• 一部分是batch内的负采样。
• 另一部分来自全库的随机负采样。全库采样能更好地模拟实际的召回场景。
• 还有一部分是根据业务规则挑出来的hard负样本，用来提升模型训练效果。

模型结构怎么搭？

我们采用的是双塔模型。一个塔处理JD的文本信息，另一个塔处理CV的文本信息，各自映射成一个低维向量。

然后通过计算向量间的相似度，用对比学习的损失函数来优化。让相关的JD和CV向量挨得更近，不相关的离得更远。

实践证明，这种方式能有效提高匹配精度。

模型离线怎么测？

第一种评估方式，是用模型去预测给定的正负样本对，然后算AUC和JD维度的GAUC。

但这种方法受限于有限的样本集，很难全面反映召回模型在真实场景下的表现。

为了得到更接近线上环境的结果，我们换了一套评估方案，分两步走：先实际执行一次召回操作，再对召回结果做详细评估。

为什么选择Milvus？

为了支撑这个流程，我们调研了好几款向量数据库，最后选了Milvus。原因有三个：

• 易用性：API接口简洁，文档丰富，上手快，集成也方便。而且支持标量过滤与向量相似性搜索结合，能实现更灵活的混合搜索。
• 高性能：得益于优化的算法和索引结构，处理大规模数据的向量检索任务时效率很高，能满足我们的性能需求。
• 社区支持：社区活跃，生态丰富，提供多语言支持和工具链，遇到问题能较快找到解决方案。

召回结果怎么评估？

在评估召回结果时，我们用了两种方法：

• 体感评估：对不同模型召回结果中各自独有的部分，用大模型做体感标注，统计结果看哪个模型表现更好。
• 量化指标：通过召回率、精准率这些关键指标，来评估模型在实际召回任务中的表现。

Milvus使用及具体评估过程

部署与数据准备

我们用Milvus官方提供的docker-compose方式部署了2.4.5版本。评估时采了百万级别的CV数据，单节点部署完全够用。

同时部署了管控平台Attu，方便加载、删除数据集合，修改索引类型，以及进行向量搜索等操作。

为了方便数据导入和召回测试，还开发了相应的接口，让评估流程更自动、更便捷。

数据准备方面，基于线上JD的流量分布情况，按城市粒度采样了一些JD数据，用模型生成对应的JD向量。

然后对采样城市的全量CV做向量生成，通过写入接口存入Milvus。

为了确保评估准确性，索引类型选的是FLAT，保证能100%召回相关数据。

召回与评估

召回过程就是通过JD编号，从JD集合里查出对应的JD向量，再用这个向量从CV集合中召回最相似的topK CV。

相似度用内积来度量，最终得到一组JD-CV匹配对。

评估环节，前面已经提到，一方面是体感标注，另一方面是根据正向行为记录构建正例集，算召回率、精准率这些指标，最终对模型做综合评估。

踩过的坑

使用Milvus过程中也遇到了一些问题：

• 索引类型选择：分析召回结果时，发现有些模型预测分数高的记录没召回来，分数低的反而回来了。排查后发现是索引类型的问题。最初用的IVF_FLAT索引，虽然能提高查询速度，但无法保证100%召回率。后来查官网文档，改成FLAT索引，问题才解决。
• 条件查询问题：用Python SDK做条件查询时，传入的filter参数不生效。跟社区沟通排查后，把filter改成expr参数，问题就搞定了。

总结

必须承认，Milvus确实是一款功能强大、易部署的向量数据库。

它帮我们优化了召回评估流程，节省了不少时间成本，也为模型上线前提供了更充分的评估依据。

未来，我们还会继续探索更多应用场景，进一步挖掘Milvus的潜力，用它的丰富功能提升业务召回效率和准确性。