当老板说"给商品图加个搜索功能"时：我和小明的多模态检索落地记

记得那天午后，小明满脸愁容地来找我："老大，客户想要上传商品图片就能搜到相似商品，团队里没人做过类似的需求，怎么办？"

看着小明焦头烂额的样子，我想起自己三年前第一次面对这个需求时的茫然。那时候的多模态检索还是一片荒漠，没有成熟的工具链，没有现成的解决方案，我们几乎是摸着石头过河。

但现在不一样了。SentenceTransformers已经进化到v5.4版本，多模态能力直接内置其中。今天，我想把这个经历分享给你——不只是讲技术，更是讲讲我们是怎么一步步把这个功能做起来的。

小明的困境：文本检索的局限

小明的团队之前用的是传统的关键词匹配搜索。用户想找"红色碎花连衣裙"，系统就匹配"红色"+"碎花"+"连衣裙"这三个词。

问题随之而来。用户上传了一张图片：深红色、带有暗纹的真丝连衣裙。系统无法理解图片内容，关键词匹配完全失效。

这不是个例。电商平台里，70%以上的搜索需求都涉及视觉特征——款式、颜色、材质、图案。这些信息用文字很难描述清楚，但用图片表达却直观得多。

多模态检索的价值就在这里：它能让机器"看懂"图片，把图片和文字映射到同一个语义空间。你上传一张红色连衣裙，系统就能找到所有风格相似的商品。

我们先从小处着手。

第一版方案用的是纯Embedding检索。原理很直接：把商品图片和商品标题都编码成向量，存入向量数据库。用户搜索时，把查询图片也编码成向量，然后计算相似度，返回最近的K个结果。

Embedding做的是"粗筛"——速度快，可以从百万级商品库里快速召回候选集。但它有个天然缺陷：向量相似度≠语义相关性。

举个例子，用户搜索"商务休闲两件套"，系统可能会召回"休闲运动套装"——因为它们在向量空间里确实很接近。但真正的商务需求应该匹配正装款式。

这时候Reranker就派上用场了。Reranker不是简单计算向量距离，而是让模型真正"理解"查询和候选之间的关系。它把查询和候选文档拼接在一起，深度交互后输出相关性评分。

两阶段检索由此诞生：Embedding做粗筛（快），Reranker做精排（准）。就像先用大网眼筛子快速捞鱼，再用小网眼精挑细选。

小明按照我们的建议，分三步走。

第一步，离线处理。每天上新商品时，用多模态模型编码商品图片，存入Milvus向量数据库。这个过程可以批量处理，不影响在线服务。

第二步，在线召回。用户上传图片后，系统实时编码查询图片，然后去向量数据库召回Top-50候选。

第三步，精排重排。对Top-50候选调用Reranker模型，精确计算每个候选与查询的相关性得分，返回Top-10最终结果。

上线第一周，小明兴奋地告诉我："搜索转化率提升了23%！"用户不再需要绞尽脑汁描述自己想找什么，上传图片就能找到心仪的商品。

小明也踩过一些坑，这里总结出来，希望你能避开。

模型选择要量力而行。VLM模型（如Qwen3-VL）效果好，但需要GPU支撑。如果团队没有GPU资源，CLIP模型是更务实的选择——它可以在CPU上运行，虽然慢一些，但足够实用。

中文场景优先考虑国产模型。CLIP模型对英文支持更好，中文理解能力有限。Qwen系列对中文更友好，实测中文商品检索效果明显更优。

模态对齐质量要实测。不同模型在"图文对齐"这件事上参差不齐。有些模型论文数据很漂亮，实际落地效果却差强人意。建议先用你的真实数据做评测，不要迷信论文数字。

输入格式要统一。模型支持多种图片输入方式（本地路径、URL、PIL对象、base64），但不同模型兼容性不同。建议在入口层统一处理，避免后续维护的麻烦。

如果你现在也在做类似的项目，有几点心得可以分享。

不要一上来就追求完美。先用Python服务+HTTP调用的方式快速验证核心逻辑，确认这条路走得通，再考虑性能优化和架构升级。过度设计是很多项目失败的原因。

两阶段检索不是万能的。对于实时性要求极高的场景（如搜索联想），纯Embedding可能更合适。Reranker适合对精度要求高、可以容忍一定延迟的场景。选对场景很重要。

最后，保持技术敏感度。多模态检索领域发展很快，新模型、新工具层出不穷。SentenceTransformers降低了门槛，SpringAI正在补齐Java生态的短板。这个方向，值得持续关注。

小明后来跟我说，他从这个项目里学到最重要的东西是：遇到新需求不要慌，先理解本质，再找工具，最后动手实现。技术世界没有银弹，但永远不缺解决问题的路径。

希望这篇文章能帮到你。