Liquid AI 发布了两款全新的检索模型，LFM2.5-Embedding-350M 和 LFM2.5-ColBERT-350M，而最引人注目的就是它们的规模：两款模型各自仅有 3.5亿参数，却都在多语言搜索上击败了规模更大的 Qwen3-Embedding-0.6B。它们是 LFM 家族中首批双向模型，基于 Liquid 于 3 月推出的 LFM2.5-350M-Base 检查点构建，并针对涵盖 11 种语言的快速多语言和跨语言检索进行了调优，这些语言包括：阿拉伯语、德语、英语、西班牙语、法语、意大利语、日语、韩语、挪威语、葡萄牙语和瑞典语。
这两款模型以不同的路径完成同一项工作。LFM2.5-Embedding-350M 是一款密集型双编码器：它把整篇文档压缩成单一的 1024 维向量，从而使搜索索引保持小巧，查找成本低廉。LFM2.5-ColBERT-350M 则改用后期交互方式，为每个 token 保留一个独立的 128 维向量，并在搜索时逐词匹配查询。这种 token 级别的匹配往往更准确，对模型未曾训练过的主题也具有更好的泛化能力，代价则是更大的索引。把两者纳入同一家族，使得团队可以选择适合自身的取舍方案，或者用成本低廉的双编码器进行检索，再用 ColBERT 模型重新排序。
这些数字印证了关于规模的说法。在 NanoBEIR Multilingual 这一以 NDCG@10 计分的检索基准上，ColBERT 模型在 11 种语言上的平均分为 0.605，嵌入模型为 0.577，两者均领先于得分 0.556 的 Qwen3-Embedding-0.6B、得分 0.540 的上一代 LFM2-ColBERT-350M，以及得分 0.528 的 Alibaba gte-multilingual-base。在 MKQA-11 这一以 Recall@20 计分的跨语言问答测试中，两者分别取得 0.694 和 0.691，再次超过得分 0.638 的 Qwen3。这些胜出并非压倒性的，但当你要为存储和服务的每一个向量付费时，一款 3.5亿参数的模型在多语言检索上压过一款 0.6B 的模型，正是那种举足轻重的结果。
速度则是这套卖点的另一半。Liquid 报告称，在 MacBook M4 Max 的 CPU 上，查询嵌入的中位耗时约为 7.3 毫秒，而在 H100 GPU 上约为 1.5 毫秒。两款模型都支持 32,768 token 的上下文，针对文档调优为 512 token，并以标准格式和 GGUF 格式发布，因此可以在 llama.cpp 下运行。用该公司的话来说，它们足够小巧，几乎可以在任何地方运行。两款模型现已在 Hugging Face 上以 LFM Open License v1.0 提供。
对于任何正在构建检索系统的人来说，这种组合正是有趣之处。搜索质量通常随着模型规模以及随之而来的账单一同攀升，因此把更出色的多语言检索能力塞进一款能装进手机或单个 CPU 的模型，指向的恰恰是另一个方向：私密、设备端且服务成本低廉的搜索，无需调用托管的 API。这些注意事项值得明明白白地说清楚。它们是检索和嵌入模型，而非聊天模型；所用的基准是 NanoBEIR 和 MKQA，而不是完整的 MTEB 套件；而击败一款 0.6B 的模型是一次实实在在但范围有限的胜利，并不是一举超越最大的商用嵌入模型的飞跃。尽管如此，方向是明确的，而这正是小模型检索全年以来一直前进的方向。