多模态检索技术演进：从单模态Embedding到Reranker的实战踩坑录

2024年初，我接手第一个跨模态检索项目时，市面上几乎找不到像样的Java集成方案。彼时团队面临的核心矛盾是：业务系统跑在JVM上，而多模态模型生态几乎全在Python侧。

三年的实战经历，让我踩遍了几乎所有坑。这篇文章，是一份完整的技术复盘。

技术选型的三个关键节点

第一个节点发生在2021年。当时团队需要实现"用商品图搜相似商品"功能。最朴素的做法是手动标注图片标签，然后用文本检索。但标签质量参差不齐，召回率惨不忍睹。

转折点来自CLIP模型的发布。我第一次看到"同一向量空间"这个概念时，意识到这才是真正的解法：不再依赖人工标签，而是让模型学会"理解"图片的语义。

第二个节点是SentenceTransformersv5.4的发布。多模态Embedding终于有了官方支持。更关键的是，Reranker模块的加入让检索精度从"能用"提升到"好用"。

第三个节点是ONNXRuntime的成熟。它让CLIP模型可以在Java进程内直接推理，彻底告别Python服务代理。

为什么必须用两阶段？

Embedding负责粗筛，优势是速度快、可预计算。一个768维向量的余弦相似度计算，在现代CPU上单次耗时不超过1毫秒。百万级文档库召回Top-100，全量预计算后毫秒级响应。

Reranker负责精排，代价是慢。以CrossEncoder方式运行时，查询和候选文档需要逐对拼接后重新编码。100个候选文档意味着100次模型前向传播，延迟从1毫秒跳到数百毫秒。

因此业界标准范式：Embedding做召回（量大快速），Reranker做重排（量小精准）。实测在电商场景下，两阶段架构相比纯Embedding召回，Top-10准确率提升约35%。

路径一：PythonHTTP服务。FastAPI封装SentenceTransformers，Java端RestTemplate调用。适合快速验证，但增加了网络开销和服务治理复杂度。

路径二：ONNXRuntimeJava版。CLIP模型导出ONNX后，Java进程内直接推理。无网络延迟，但需要手动处理输入预处理（图片resize、归一化等）。

路径三：SpringAI扩展。实现MultimodalEmbeddingModel接口，封装HTTP调用逻辑。适合Spring生态项目，代码更优雅。

我的建议：开发阶段用路径一快速迭代，生产环境根据性能要求选择路径二或三。

VLM-based模型（如Qwen3-VL）精度更高，支持复杂图文理解，但需要GPU支持。8B参数版本约需20GB显存，部署成本不低。

CLIP模型精度略逊，但CPU可推理。clip-ViT-B-32在普通服务器上单张图片编码耗时约200ms，勉强可接受。

实际选型时，考虑三个维度：精度要求、硬件条件、响应时间要求。缺一不可。

中文支持是第一个坑。Qwen系列对中文友好，CLIP主要是英文。如果你需要中英文混合检索，实测混用两个模型效果反而更好。

模态对齐质量参差不齐。不是所有"多模态模型"都真正对齐良好。我吃过这个亏——某个开源模型论文效果很漂亮，实测语义空间一塌糊涂。务必用实际数据评测。

输入格式处理繁琐。支持本地路径、URL、PILImage、base64四种格式，但不同模型对格式的兼容性不同。建议统一用URL或base64，减少踩坑。

多模态检索已经不是"未来趋势"，而是正在发生的现在。SentenceTransformersv5.4把这个能力门槛降到了前所未有的低点。你的Java项目，准备好了吗？