跳到正文
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 內容精選