LFM2.5 Retrievers: Bi-directional LFMs for Fast Multilingual Search

Liquid AI’s June 2026 release introduces two 350M-parameter retrieval models: LFM2.5-Embedding-350M and LFM2.5-ColBERT-350M, designed for fast multilingual and cross-lingual search across 11 languages, with a small enough footprint to run on laptops, CPUs, and edge-friendly setups.

What Was Released

Liquid AI introduced two retrieval models built on the same base:

• LFM2.5-Embedding-350M A standard dense bi-encoder that produces one vector per document.
• LFM2.5-ColBERT-350M A late interaction model that keeps token-level embeddings and uses MaxSim scoring.

At a high level:

• The embedding model is optimized for speed and compactness.
• The ColBERT model is optimized for ranking quality and fine-grained matching.

Both support 11 languages and are designed specifically for short-context retrieval tasks like FAQs, support docs, and product search.

Embedding vs ColBERT: The Real Trade-off

The difference isn’t just architectural — it directly affects how you design your system.

LFM2.5-Embedding-350M

• One vector per document
• Small index size
• Fast retrieval
• Easy integration with vector DBs (FAISS, Milvus, etc.)

LFM2.5-ColBERT-350M

• Token-level representations
• Larger index
• Uses MaxSim (query-token to document-token matching)
• Much better at nuanced and cross-lingual matching

A simple way to think about it:

• Embedding model = recall engine
• ColBERT = precision engine

In practice, the strongest pattern is combining both.

Architecture: The Interesting Part

The most important technical change is how Liquid AI converts a causal decoder into a bidirectional retriever.

They start with:

• LFM2.5–350M-Base (a causal model)

Then apply two key modifications:

1. Causal attention → Bidirectional attention Tokens can now attend to both left and right context.
2. Causal convolutions → Non-causal convolutions Local token mixing is no longer directional.

Why this matters:

• Causal models are great for generation.
• Retrieval needs full-context understanding.

This small architectural shift makes the model suitable for embedding and token-level retrieval tasks without retraining from scratch.

Training Strategy

The training pipeline follows a familiar but well-executed structure:

1. Large-scale English contrastive pretraining
2. Multilingual + cross-lingual distillation
3. Fine-tuning with hard negatives

One notable detail:

• They used LLM-based translation to expand multilingual training pairs.

Also interesting:

• The embedding model gets more cross-lingual supervision, because ColBERT inherently handles cross-lingual alignment better through token interactions.

Benchmark Signals (What Actually Matters)

On multilingual retrieval benchmarks like NanoBEIR, reported numbers show:

• ColBERT-350M ≈ 0.605 NDCG@10
• Embedding-350M ≈ 0.577
• Both outperform comparable models like Qwen3-Embedding-0.6B in that setup

Interpretation:

• The gap is real but not massive
• You’re trading ~5% quality for major gains in cost and simplicity

Latency-wise:

• ColBERT is still usable in low-latency setups (few milliseconds in optimized environments)
• But embedding models remain significantly cheaper to scale

Where These Fit in a RAG Stack

Here’s the practical view.

Use LFM2.5-Embedding-350M when:

• You need scalable, low-cost retrieval
• You’re using a vector database
• Your corpus is large
• Latency matters

Use LFM2.5-ColBERT-350M when:

• Ranking quality is critical
• Queries are ambiguous or multilingual
• You care about token-level matching (finance, legal, technical docs)

Best pattern (recommended):

• Stage 1: Dense retrieval (Embedding model)
• Stage 2: Reranking (ColBERT)

Example flow:

• Retrieve top 100 candidates with embeddings
• Rerank top 100 → top 10 using ColBERT

Python Example

Here’s a simple dense retrieval setup:

from sentence_transformers import SentenceTransformer
import numpy as np

model = SentenceTransformer("LiquidAI/LFM2.5-Embedding-350M")
corpus = [
    "Return policy: 30 days with receipt.",
    "Guía de devolución: 30 días con recibo."
]
queries = ["How do I return an item?"]
corpus_emb = model.encode(corpus, normalize_embeddings=True)
query_emb = model.encode(queries, normalize_embeddings=True)
scores = np.matmul(query_emb, corpus_emb.T)
print(scores)

This alone gives you cross-lingual retrieval out of the box.

Key Takeaways

• These are small but powerful retrievers (350M) that actually fit real-world constraints.
• The embedding model is your default for most systems.
• The ColBERT model shines in reranking and complex queries.
• The architectural shift to bidirectional LFMs is simple but impactful.
• The best production setup is hybrid retrieval (dense + late interaction).