跳到正文
IFAI

开源项目

Liquid AI 发布 LFM2.5 检索模型:350M 参数支持 11 种语言

首次发布 传播指数 45

Liquid AI 发布两款 350M 参数的多语言检索模型 LFM2.5-ColBERT-350M 与 LFM2.5-Embedding-350M,支持阿拉伯语、日语等 11 种语言。二者分别针对极速检索和高精度匹配设计,在 NanoBEIR 评测中拿下同类第一,并提供 GGUF 格式支持端侧运行。

Liquid AI 发布 LFM2.5 检索模型:350M 参数支持 11 种语言
图:liquid.ai

Liquid AI 推出的 LFM2.5-ColBERT-350M 和 LFM2.5-Embedding-350M,是两款只有 350M 参数的轻量多语言检索模型。它们能帮你用极低的算力成本,在商品目录、常见问题知识库或技术支持文档里做跨语言搜索,甚至可以直接跑在普通笔记本和边缘设备上。

两个模型分别能做什么

这两款模型都支持阿拉伯语、德语、英语、西班牙语、法语、意大利语、日语、韩语、挪威语、葡萄牙语和瑞典语共 11 种语言,但使用场景不同。

LFM2.5-Embedding-350M 走的是经典单向量路线。它把整篇文档压缩成一个密集向量,查询时速度最快、生成的向量索引最小,也最省存储成本。如果你要搭建百万级规模的检索系统,或者对机器显存和硬盘容量抠得很紧,选它最划算。

LFM2.5-ColBERT-350M 则采用晚期交互机制。它会为每个词元都生成一个向量,在搜索时逐词比对相关性。这种方式牺牲了一部分存储空间,索引体积更大,但换来的是更高的匹配精度和更强的跨语言泛化能力。如果你更在乎搜得准不准,它更合适。

怎么把生成模型改成检索模型

以往基于自回归架构的因果语言模型只能从左往右读文本,并不适合做需要全局上下文理解的检索任务。Liquid AI 的做法比较取巧,它们直接基于 3 月发布的通用底座 LFM2.5-350M-Base 动了手术。

开发团队给底座打了几个双向补丁。首先把原本遮挡未来词元的注意力掩码换成了双向掩码,让每个词都能同时看到前后文。其次把架构里的短卷积层改成非因果卷积,使其能对称地混合局部信息。

改完之后,骨干网络就从一个生成式解码器变成了一个双向编码器。接着团队分三个阶段进行训练:先在海量英文数据上做对比学习预训练,再通过强教师模型向 11 种语言做多语言和跨语言知识蒸馏,最后用挖掘出的难负例进行微调。

测试表现与部署门槛

虽然体量只有 350M,但测试成绩压过了不少体积更大的对手。在多语言评测 NanoBEIR 上,LFM2.5-ColBERT-350M 的平均分达到 0.605,LFM2.5-Embedding-350M 达到 0.577。作为对比,6 亿参数的 Qwen3-Embedding-0.6B 分数为 0.556,阿里的 gte-multilingual-base 为 0.528。

在跨语言问答测试 MKQA-11 上,两款模型分别拿下了 0.694 和 0.691 的召回率,同样排在同类模型榜首。即使在非英语语种里,检索表现也保持得很平稳,没有出现明显的语言偏科。

在硬件门槛上,官方已经把模型权重挂到了 Hugging Face,并且同步提供了适配 llama.cpp 的 GGUF 格式。在普通 CPU 或笔记本上,带缓存的查询延迟在 7 到 8 毫秒左右;放到企业级 GPU 服务堆栈下,查询延迟更是只有 1.3 到 1.5 毫秒。如果你想在自己的领域数据上微调,官方也提供了配合 sentence-transformers 的微调示例。

为什么重要

我们认为这两款模型的亮点在于把高水平的多语言检索门槛打到了极低水平。过去要在端侧或低成本服务器上做多语言 RAG,开发者往往只能用英文主导的小模型或者被迫忍受低精度的多语言翻译检索。现在 350M 的体积配合 GGUF 格式,意味着即便没有昂贵的独立显卡,单台普通工控机或轻薄本也能流畅运行高质量的跨语种本地知识库。

不过要注意的是,它们目前主要针对短文本检索进行优化,更适合电商 SKU 搜索、客服 FAQ 和技术手册排查,并不适合超长论文或复杂整书的宏观分析。如果你正在为多语言业务搭建轻量级私有化检索链路,这两个模型非常值得立刻下载实测。

来源 (1)

  1. [1]
    liquid.ai(在新标签页打开)原文liquid.ai

每日 AI 内容精选