Liquid AI a publie deux nouveaux modeles de recherche, LFM2.5-Embedding-350M et LFM2.5-ColBERT-350M, et l'essentiel tient dans leur taille : avec 350 millions de parametres chacun, les deux surpassent le plus gros Qwen3-Embedding-0.6B sur la recherche multilingue. Ce sont les premiers membres bidirectionnels de la famille LFM, construits a partir du checkpoint LFM2.5-350M-Base que Liquid a livre en mars, et ils sont optimises pour une recherche multilingue et cross-lingue rapide a travers 11 languages : l'arabe, l'allemand, l'anglais, l'espagnol, le francais, l'italien, le japonais, le coreen, le norvegien, le portugais et le suedois.

Les deux modeles empruntent des chemins differents pour la meme tache. LFM2.5-Embedding-350M est un bi-encodeur dense : il compresse un document entier en un seul vecteur 1024-dimensional, ce qui maintient l'index de recherche compact et les consultations peu couteuses. LFM2.5-ColBERT-350M utilise plutot l'interaction tardive, en conservant un vecteur 128-dimensional distinct pour chaque token et en faisant correspondre une requete mot par mot au moment de la recherche. Cette correspondance au niveau du token tend a etre plus precise et a mieux se generaliser aux sujets sur lesquels le modele n'a pas ete entraine, au prix d'un index plus volumineux. Disposer des deux dans une meme famille permet a une equipe de choisir le compromis qui lui convient, ou d'utiliser le bi-encodeur peu couteux pour recuperer et le modele ColBERT pour reordonner.

Les chiffres confirment l'affirmation sur la taille. Sur NanoBEIR Multilingual, un benchmark de recherche evalue par NDCG@10, le modele ColBERT obtient une moyenne de 0.605 et le modele d'embedding 0.577 a travers les 11 languages, tous deux devant Qwen3-Embedding-0.6B a 0.556, le precedent LFM2-ColBERT-350M a 0.540 et le gte-multilingual-base d'Alibaba a 0.528. Sur MKQA-11, un test de question-reponse cross-lingue evalue par Recall@20, les deux atteignent 0.694 et 0.691, la encore au-dessus de Qwen3 a 0.638. Les ecarts ne sont pas ecrasants, mais un modele de 350M qui depasse un modele de 0.6B sur la recherche multilingue est le genre de resultat qui compte quand on paie pour chaque vecteur que l'on stocke et que l'on sert.

La vitesse est l'autre moitie de l'argumentaire. Liquid rapporte un embedding de requete en environ 7.3 millisecondes a la mediane sur un CPU de MacBook M4 Max, et environ 1.5 milliseconds sur un GPU H100. Les deux modeles prennent en charge un contexte de 32,768-token, optimise a 512 tokens pour les documents, et sont livres aux formats standard et GGUF afin de tourner sous llama.cpp. Comme le formule l'entreprise, ils sont assez petits pour tourner a peu pres partout. Les deux sont disponibles des maintenant sur Hugging Face sous la LFM Open License v1.0.

Pour quiconque batit de la recherche, c'est cette combinaison qui constitue la partie interessante. La qualite de la recherche a generalement augmente avec la taille du modele et la facture qui l'accompagne ; faire entrer une meilleure recherche multilingue dans un modele qui tient sur un telephone ou un seul CPU pointe donc dans l'autre direction : une recherche privee, sur l'appareil et peu couteuse a servir, qui ne fait pas appel a une API hebergee. Les reserves meritent d'etre enoncees clairement. Ce sont des modeles de recherche et d'embedding, pas des modeles de chat ; les benchmarks sont NanoBEIR et MKQA plutot que la suite MTEB complete ; et battre un modele de 0.6B est une victoire reelle mais etroite, pas un bond au-dela des plus gros embedders commerciaux. Reste que la direction est claire, et c'est la direction que prend la recherche par petits modeles depuis le debut de l'annee.