Tom Aarsen

The extra speed has a storage cost: MICE-P uses 4-bit residual compression versus LateOn's 2-bit, plus a separate SPLADE index. Loading the model with CrossEncoder gives you pairwise reranking. The indexed pipeline is what adds reusable document representations.

huggingface.coMICE - a xpmir CollectionPapers and Models for MICE - Minimal Interaction Cross-Encoders.

Very nice work by @victormorand.eurosky.social and the team! 👏 Lovely to see the Ettin reranker recipe helping explore new retrieval architectures, and both checkpoints usable through Sentence Transformers. huggingface.co/collections/...

huggingface.coMICE - a xpmir CollectionPapers and Models for MICE - Minimal Interaction Cross-Encoders.

github.comGitHub - xpmir/mice: MICE - Minimal Interaction Cross EncodersMICE - Minimal Interaction Cross Encoders. Contribute to xpmir/mice development by creating an account on GitHub.

MICE-P compresses document vectors to 128d for storage with Fast-PLAID. SPLADEv3 retrieves candidates, whose vectors are decompressed and scored by MICE. This indexed path uses the authors' public implementation: github.com/xpmir/mice

The authors report a useful tradeoff: indexed MICE-P runs much faster than full cross-encoders, while scoring above LateOn + PLAID on BEIR13. Their chart combines DBPedia latency with decontaminated BEIR13 quality: arxiv.org/abs/2610.31932

huggingface.coMICE - a xpmir CollectionPapers and Models for MICE - Minimal Interaction Cross-Encoders.

Both models run through CrossEncoder with trust_remote_code=True. This 61M example runs MICE, but CrossEncoder re-encodes each query-document pair. It doesn't reuse document representations, so you don't get the document-precomputation savings.

MICE processes queries and documents separately in its lower layers, so the document representations can be computed ahead of time. The upper layers let query tokens attend to those document representations, keeping richer interactions than ColBERT's MaxSim.

huggingface.coMICE - a xpmir CollectionPapers and Models for MICE - Minimal Interaction Cross-Encoders.

huggingface.coMICE - a xpmir CollectionPapers and Models for MICE - Minimal Interaction Cross-Encoders.

Mice-P-61m & Mice-P-130m are Apache 2.0, built on the Ettin / ModernBERT family and trained with the Ettin reranker recipe. 61M or ~129M parameters, both with four interaction layers: huggingface.co/collections/...

10h

Big fan of @naverlabseurope.bsky.social 's Splade-code-{06B,8B}! Sparse models for code are underrated.

MTEB@mteb.org

1/ New on MTEB: naver/splade-code-06B and naver/splade-code-8B, sparse retrieval models for code. On CoREB(v1), built from rewritten programming-contest problems to limit overlap with training data, they score 59.43 and 59.61. The best of the 24 models evaluated so far scores 60.10.

huggingface.coSplade-Code - a naver CollectionLearned Sparse Retrieval Models for Code

10h

Models: huggingface.co/collections/...

🏎️ I've never seen MoE models for embedding & search this small: 1.5M, 27M & 115M parameters! VAGO Solutions' MoEdernColBERT models take on much larger dense retrievers, with 115M near or ahead of Qwen3-Embedding-0.6B in their overview at 8× the encoding throughput. Details 🧵

A good part of the quality gap may come from multi-vector retrieval: each token keeps a 128d vector, and MaxSim lets query tokens match different document tokens. That means more vectors to store & score than one dense vector per text, even with such a tiny encoder.

huggingface.coSauerkrautLM-MoEdernColBERT - a VAGOsolutions CollectionMultilingual ColBERT retrievers on the MoEdernBERT architecture (1.5M, 27M, 115M) with GGUF and CoreML builds

Very cool work by David Golchinfar & VAGO Solutions! 👏 MoEs at this scale make for a really interesting retrieval family, from a 1.5M encoder to a 115M model competing with much larger dense models. huggingface.co/collections/...

The team's encoder throughput on one RTX 6000 Ada, bf16, 512-token documents: - 1.5M: 43,255 docs/s - 27M: 6,708 docs/s - 115M: 1,132 docs/s - Qwen3-0.6B: 141 docs/s MoEdern uses their Triton kernel, with batch sizes tuned per model. Excludes tokenization & search.

Each transformer layer routes a token to 2 of 8 experts, plus one shared expert. They also shrink the embedding table by giving each token a short vector that's projected to the hidden size. For 1.5M, that saves ~3.4M parameters, although it doesn't result in speedups.

Even 1.5M edges out IBM's granite-97m-multilingual-r2 on English NanoBEIR: 0.591 vs. 0.589 nDCG@10 in their evaluation. The gap is much larger on GermanQuAD: 0.976 vs. 0.918. A 1.5M model holding its own against a 97M encoder is pretty nuts.

huggingface.coVAGOsolutions/SauerkrautLM-MoEdernColBERT-27M · Hugging FaceWe’re on a journey to advance and democratize artificial intelligence through open source and open science.

At 27M, it already passes Qwen3-Embedding-0.6B on their cross-lingual MKQA average: 0.684 vs. 0.681 Recall@20. Queries in six languages search English Wikipedia, at ~22× fewer parameters and 47× the reported encoding throughput. huggingface.co/VAGOsolution...

You can use all three with Sentence Transformers' MultiVectorEncoder, with trust_remote_code=True. Here, 1.5M matches the German mountain query and English capital query to the right documents. Higher MaxSim scores mean a better match.

huggingface.coVAGOsolutions/SauerkrautLM-MoEdernColBERT-115M · Hugging FaceWe’re on a journey to advance and democratize artificial intelligence through open source and open science.

In their overview, 115M beats Qwen3-Embedding-0.6B on 9 of 10 quality rows. English NanoBEIR is the exception: 0.643 vs. 0.648, while the six-language average is 0.585 vs. 0.574. Non-English NanoBEIR uses their translations. huggingface.co/VAGOsolution...

All three are Apache 2.0 multilingual multi-vector retrievers for German, English, Spanish, Dutch, French, Italian & Portuguese. And yes, 1.5M is the total parameter count, with just 0.88M active per token. Crazy! huggingface.co/collections/...

huggingface.coSauerkrautLM-MoEdernColBERT - a VAGOsolutions CollectionMultilingual ColBERT retrievers on the MoEdernBERT architecture (1.5M, 27M, 115M) with GGUF and CoreML builds

🔎 KURE might be the first major model suite to support all 4 Sentence Transformers model types! Dense, sparse & multi-vector embeddings, plus rerankers, all for Korean & English. And damn, the new 1.1B KURE-v3 is really good on English retrieval too 🧵

For reranking candidates, there's a 1.7B base model and a 149M nano model, both through CrossEncoder. Here's nano moving the photosynthesis answer to the top. Its scores are relevance logits, so higher is better, even when they're all negative.

huggingface.coKURE - a nlpai-lab CollectionKURE: Korea University REtrieval models

Very nice work by the NLP & AI Lab at Korea University! 👏 A full Korean-English retrieval toolkit, from three ways to index your documents to reranking your candidates, all usable through Sentence Transformers. huggingface.co/collections/...

KURE-Sparse-base/nano learn weighted terms you can search with an inverted index. At 593M / 149M parameters, the team reports 79.84 / 77.16 nDCG@10 across nine Korean retrieval tasks. Both load with SparseEncoder and trust_remote_code=True.

huggingface.conlpai-lab/KURE-v2 · Hugging FaceWe’re on a journey to advance and democratize artificial intelligence through open source and open science.

August's KURE-v2 completes the set with MultiVectorEncoder support. At 154M parameters, it keeps a 128d vector per token and uses MaxSim, letting different query tokens match different parts of a document. huggingface.co/nlpai-lab/KU...

On eight public English RTEB tasks (excluding code), the team reports: - KURE-v3 (1.1B): 68.59 - Qwen3-Embedding-8B: 68.61 Nearly matching an 8B model at 1.1B! These are nDCG@10 scores for that subset, so they differ from the full RTEB leaderboard.

huggingface.conlpai-lab/KURE-v3 · Hugging FaceWe’re on a journey to advance and democratize artificial intelligence through open source and open science.

KURE-v3 gives you one 2,048d vector per text, with Matryoshka support down to 256d. In the team's Korean retrieval evaluation, 1,024d retains 99% of its full-size score, so you can halve vector storage with very little loss. huggingface.co/nlpai-lab/KU...

The family now includes the new KURE-v3 & Sparse-base/nano, plus the recently released Reranker-base/nano and older multi-vector KURE-v2. Reranker-base even got a fresh retrain. All the models: huggingface.co/collections/...

huggingface.coKURE - a nlpai-lab CollectionKURE: Korea University REtrieval models

🔎 NVIDIA just released Nemotron 3.5 Embed 1B & 8B and Rerank 8B for searching text, tables, charts, and document page images. All three work with Sentence Transformers. Here's how to retrieve pages and rerank the results 🧵

Reranking also lifts NVIDIA's ViDoRe v3 image + text result from 58.82 to 67.56 nDCG@10, vs 66.03 with Qwen3-VL-Reranker-8B. Both rerankers score the same top 50 candidates from Embed 1B, making this a useful comparison of the second stage.

Great to see both a smaller embedding model and a multimodal reranker for teams searching mixed document collections! Very nice work by the NVIDIA team, it was very cool to see the announcement on the GTC Keynote.

Already using Nemotron 3 Embed for text retrieval? NVIDIA kept the language towers frozen when training 3.5's vision components, preserving the corresponding text embedding spaces. That means you can add image retrieval while reusing existing text vectors.

Rerank 8B scores each query-document pair jointly, including page images. Here it ranks the NeMo diagram first and the unrelated passage last. These are relevance logits, so higher is better.

NVIDIA's ViDoRe v3 comparison, using image + text inputs: - Embed 8B: 61.5 - Embed 1B: 58.8 - Qwen3-VL-Embedding-8B: 57.0 All nDCG@10. The smaller Nemotron model beats the Qwen 8B baseline here.

huggingface.coNVIDIA Nemotron 3.5 Embed, Rerank, and Parse: Advancing Agents with World-Class Retrieval ModelsA Blog post by NVIDIA on Hugging Face

With Sentence Transformers, you can search a NeMo diagram alongside text passages using the same query. Here the diagram and relevant text score well above the unrelated passage, with one 2048-dimensional vector per input.

You can search a PDF page as an image, as text, or with both together. The Embed models produce one vector per input, so you can use them with a conventional vector index. NVIDIA's full write-up: huggingface.co/blog/nvidia/...

huggingface.coNemotron 3.5 Retriever - a nvidia CollectionOpen, production-ready retrieval models built for high-accuracy enterprise RAG and agentic retrieval pipelines.

The collection has Embed 1B, Embed 8B, and Rerank 8B in BF16, plus an NVFP4 version of Embed 1B for Blackwell GPUs. The BF16 models have Sentence Transformers examples in their cards, and all use OpenMDW-1.1: huggingface.co/collections/...

🧵 I've just released Sentence Transformers v6.2.0! Featuring model merging with Arcee AI's mergekit, load models faster, & evaluators share work across GPUs automatically. Plus lower-memory losses, multi-vector improvements & plenty of fixes. Thread with highlights 👇

Python 3.14 & huggingface_hub 2.x are now supported. Two upgrade notes: - Single-vector int8/uint8 quantization needs explicit ranges or calibration data - Checkpoint module paths must be relative, without '..', even with trust_remote_code=True

github.comRelease v6.2.0 · huggingface/sentence-transformersRelease v6.2.0

Thanks to everyone who contributed to this release! Full release notes, examples & all 176(!) PRs: github.com/huggingface/... pip install sentence-transformers==6.2.0

Experimental: keep selected CrossEncoder linear layers computing in FP32 while the backbone uses BF16. Useful for reducing score ties caused by limited precision. Works in training & inference, including autocast. Stored parameter dtypes stay unchanged.

Also fixed: - FP16/BF16 pooling arithmetic - Multi-process worker errors reaching the caller - Quantized/offloaded model placement - Compiled-model checkpoint restoration - Ranking losses & quantized search rescoring Plus faster CPU cosine semantic_search.

Lower-memory training: - BatchSemiHardTripletLoss: quadratic intermediate memory instead of cubic - BatchAllTripletLoss: quadratic for paired labels - CoSENTLoss & AnglELoss, including sparse variants: linear intermediate storage Large BatchAll label groups can still be cubic.

Multi-vector improvements: - Fractional pool_factor for finer compression control - Optional fastcluster for faster token clustering - MaxSim blocks account for both query & document token counts to reduce memory use on long query batches

I also sped up loading, e.g. all-MiniLM-L6-v2: 6.39s to 2.66s, with HTTP requests down from 35 to 9. We now resolve the Hub revision once & reuse it across downloads. These are for loading models already in your cache. Across four tested models, loading time fell by 43 to 61%.

Training with DDP? Evaluators now share encode() & predict() across your training ranks automatically, for all four model types. Rank zero combines predictions, computes metrics over the full dataset & shares them for checkpoint selection and early stopping.

New: model merging for all four model types: dense, sparse, rerankers & multi-vector. Built on mergekit, with Linear, SLERP, TIES, DARE & more. Kudos to @chargoddard.bsky.social for a great collaboration there! Install with: pip install "sentence-transformers[merge]==6.2.0"