Liquid AI 发布 LFM2.5 检索模型：350M 参数、11 语言、边缘设备可用的多语言搜索方案

一句话看懂

Liquid AI 发布两个 350M 参数的检索模型，支持 11 种语言的多语言和跨语言搜索，可在边缘设备上以毫秒级延迟运行。

详细发生了什么

Liquid AI 本周发布了 LFM2.5-Embedding-350M 和 LFM2.5-ColBERT-350M 两个检索模型。它们都是 350M 参数，基于 3 月发布的 LFM2.5-350M-Base 构建，是 LFM 家族首批双向编码器模型。

两个模型共享同一骨干网络，但输出方式不同：

LFM2.5-Embedding-350M：稠密双编码器，每个文档生成一个 1024 维向量，适合追求最快搜索速度和最小索引的场景。
LFM2.5-ColBERT-350M：延迟交互模型，每个 token 生成 128 维向量，通过逐词匹配获得更高精度，但索引更大。查询长度上限 32 token，也可用于对第一阶段检索结果进行重排序。

架构上，团队将 LFM2 的因果注意力掩码替换为双向掩码，并将短卷积改为非因果模式，使模型能利用上下文双向信息。训练分三阶段：英语对比预训练 → 多语言蒸馏（11 种语言）→ 难负样本微调。

在 NanoBEIR 多语言检索基准上，ColBERT 模型平均 NDCG@10 达 0.605，Embedding 模型 0.577，均超过 Qwen3-Embedding-0.6B（0.556）。在 MKQA-11 跨语言问答任务上，两者 Recall@20 分别为 0.694 和 0.691。

模型已通过 Hugging Face 发布，采用 LFM Open License v1.0。同时提供 GGUF 格式，支持 llama.cpp 在 CPU 和边缘设备运行。在 MacBook Pro M4 Max 上，预计算文档嵌入后查询延迟中位数低于 10 ms。

中文圈视角

对中文开发者意味着什么？

多语言搜索能力：模型支持 11 种语言，包括阿拉伯语、德语、英语、西班牙语、法语、意大利语、日语、韩语、挪威语、葡萄牙语、瑞典语，不含中文。这是一个重要盲点：中文用户无法直接受益于该模型的中文搜索能力。如果要做中文搜索，仍需依赖国产模型如 BGE、GTE 或 Qwen-Embedding。
边缘部署价值：GGUF 格式和低延迟（<10 ms）意味着可以在手机、笔记本上本地运行语义搜索，无需联网。这对隐私敏感的应用（如本地文档检索、笔记搜索）很有吸引力。国内类似方案有 ModelScope 上的轻量级嵌入模型，但专门针对边缘优化的多语言模型较少。
与国产模型对比：Qwen3-Embedding-0.6B（6 亿参数）在 NanoBEIR 上得分 0.556，低于 Liquid AI 的 350M 模型（0.577/0.605），说明后者在效率上更有优势。但 Qwen 系列对中文支持更好，且开源协议更宽松（Apache 2.0）。LFM 使用自定义许可证，需注意商业使用限制。
RAG 场景：Liquid AI 定位为现有 RAG 管道的即插即用替代品。国内开发者如果构建多语言（非中文）RAG 应用，可以尝试替换；如果主要面向中文，建议继续使用 BAAI/bge-large-zh 或 Alibaba-NLP/gte-Qwen2-1.5B-instruct。

几条值得记住的细节

两个模型均基于 LFM2.5-350M-Base，参数 350M，上下文长度 32,768 tokens，但文档调优长度为 512 tokens。
ColBERT 模型查询长度上限 32 tokens，Embedding 模型无此限制。
在 H100 GPU 上，Embedding 模型查询延迟低至 1.5 ms（p50）。
模型支持 11 种语言：阿拉伯语、德语、英语、西班牙语、法语、意大利语、日语、韩语、挪威语、葡萄牙语、瑞典语，不含中文。
许可证为 LFM Open License v1.0，非标准开源协议，商用需核实条款。

一句话总结

Liquid AI 的 350M 检索模型在非中文多语言搜索上表现优异且适合边缘部署，但中文用户仍需等待或选择国产替代。