Los nuevos modelos de recuperacion de 350M de Liquid AI superan a un rival casi del doble de su tamano, y funcionan en un portatil

Liquid AI ha lanzado dos nuevos modelos de recuperacion, LFM2.5-Embedding-350M y LFM2.5-ColBERT-350M, y el titular es el tamano: con 350 millones de parametros cada uno, ambos superan al mayor Qwen3-Embedding-0.6B en busqueda multilingue. Son los primeros miembros bidireccionales de la familia LFM, construidos a partir del checkpoint LFM2.5-350M-Base que Liquid publico en marzo, y estan afinados para la recuperacion multilingue y translingue rapida en 11 idiomas: arabe, aleman, ingles, espanol, frances, italiano, japones, coreano, noruego, portugues y sueco.

Los dos modelos toman caminos distintos para el mismo trabajo. LFM2.5-Embedding-350M es un bi-codificador denso: comprime un documento entero en un unico vector de 1024 dimensiones, lo que mantiene pequeno el indice de busqueda y baratas las consultas. LFM2.5-ColBERT-350M usa en cambio la interaccion tardia, conservando un vector independiente de 128 dimensiones para cada token y cotejando una consulta palabra por palabra en el momento de la busqueda. Esa coincidencia a nivel de token tiende a ser mas precisa y a generalizar mejor a temas con los que el modelo no fue entrenado, a costa de un indice mas grande. Tener ambos en una misma familia permite a un equipo elegir el compromiso que le conviene, o usar el bi-codificador barato para recuperar y el modelo ColBERT para reordenar.

Las cifras respaldan la afirmacion sobre el tamano. En NanoBEIR Multilingual, un benchmark de recuperacion puntuado con NDCG@10, el modelo ColBERT promedia 0.605 y el modelo de embedding 0.577 a lo largo de los 11 idiomas, ambos por delante de Qwen3-Embedding-0.6B con 0.556, del anterior LFM2-ColBERT-350M con 0.540 y del gte-multilingual-base de Alibaba con 0.528. En MKQA-11, una prueba de respuesta a preguntas translingue puntuada con Recall@20, los dos quedan en 0.694 y 0.691, de nuevo por encima de Qwen3 con 0.638. Las victorias no son aplastantes, pero que un modelo de 350M supere a uno de 0.6B en recuperacion multilingue es el tipo de resultado que importa cuando pagas por cada vector que almacenas y sirves.

La velocidad es la otra mitad del argumento. Liquid informa de un embedding de consulta en unos 7.3 milisegundos en la mediana sobre una CPU de MacBook M4 Max, y aproximadamente 1.5 milisegundos en una GPU H100. Ambos modelos admiten un contexto de 32,768 tokens, afinado a 512 tokens para documentos, y se publican en formatos estandar y GGUF para que funcionen bajo llama.cpp. Como dice la empresa, son lo bastante pequenos para funcionar casi en cualquier lugar. Ambos estan disponibles ahora en Hugging Face bajo la LFM Open License v1.0.

Para cualquiera que este construyendo recuperacion, esa combinacion es lo interesante. La calidad de busqueda suele haber subido con el tamano del modelo y la factura que lo acompana, asi que meter una mejor recuperacion multilingue en un modelo que cabe en un telefono o en una sola CPU apunta en la direccion contraria: busqueda privada, en el dispositivo y barata de servir, que no llama a una API alojada. Conviene enunciar las advertencias con claridad. Estos son modelos de recuperacion y de embedding, no modelos de chat; los benchmarks son NanoBEIR y MKQA en lugar del conjunto completo MTEB; y superar a un modelo de 0.6B es una victoria real pero acotada, no un salto por delante de los mayores generadores de embeddings comerciales. Aun asi, la direccion esta clara, y es la direccion hacia la que la recuperacion con modelos pequenos ha venido avanzando todo el ano.