Home / Blog / Guide

simlar on BEIR: Hybrid Retrieval Across 14 Datasets

A BEIR benchmark across 14 datasets: how simlar's hybrid retrieval stacks up against brute-force, FAISS, and turbovec dense search — on ranking quality and, especially, on latency at scale.

Every retrieval engine claims to be fast and accurate. The only way to know what that costs you is to run the same 14 BEIR datasets through it — from 3,633-document nfcorpus up to 8.8-million-document msmarco — and look at the numbers dataset by dataset, not just the average. This benchmark asks whether simlar's hybrid retrieval is actually worth it against plain dense search: brute-force exact search, FAISS, and turbovec.

Methodology

All four engines were evaluated against the same 14 BEIR datasets, using the same embedding model, WhereIsAI/UAE-Large-V1, and top_k=100. We report five standard BEIR metrics, averaged unweighted across datasets for the headline numbers: NDCG@100 (ranking quality within the top 100 results), Recall@100 (share of relevant documents retrieved in the top 100), P@100 (precision at 100), MAP, and MRR. Latency is retrieval_seconds, the total wall-clock time to answer every query in a dataset, which we also divide by query count for a per-query figure.

There's one important difference in how the four are configured. Brute force, FAISS, and turbovec run dense vector retrieval only, while simlar uses its native hybrid pipeline, combining text and vector retrieval with a text_k/vector_k split configured per dataset. The results reflect each engine's own configured retrieval path, not simlar forced into a dense-only mode to make the comparison symmetric.

turbovec didn't complete on msmarco — the process was killed before it produced results, almost certainly memory pressure on an 8.8-million-document corpus. So turbovec has results for 13 of the 14 datasets, and its macro-averages below are computed over those 13. Total retrieval-time comparisons exclude msmarco for all four engines, so every engine is measured over the same 13-dataset subset there.

simlar vs. brute force, FAISS, and turbovec

The headline result isn't really about accuracy — on ranking quality the four are close. It's about what happens to query latency as the corpus grows from thousands of documents to millions.

21.7×faster than FAISS — total retrieval time across all 14 datasets (62.6s vs. 1,358.6s)
70.6%Recall@100, macro-avg — highest of the four, though only a thin edge over turbovec's 70.6%
135×faster than FAISS per query on dbpedia-entity (4.6M docs): 1.96ms vs. 263.4ms
0.647MRR, macro-avg — best of the four; simlar's biggest single win is trec-covid at 0.955
EngineNDCG@100Recall@100P@100MAPMRR
simlar56.0%70.6%9.9%0.3990.647
faiss56.0%69.4%9.2%0.4070.642
brute force56.0%69.4%9.2%0.4080.642
turbovec †55.4%70.6%6.9%0.4080.620

† turbovec's row is a 13-dataset average (missing msmarco) — not directly comparable to the other three rows' 14-dataset average.

Recall@100 by dataset 0% 25% 50% 75% 100% quora brute force · quora: 99.7% turbovec · quora: 99.7% faiss · quora: 99.7% simlar · quora: 99.6% 99.6% arguana brute force · arguana: 99.2% turbovec · arguana: 99.2% faiss · arguana: 99.2% simlar · arguana: 99.2% 99.2% scifact brute force · scifact: 96.5% turbovec · scifact: 96.5% faiss · scifact: 96.5% simlar · scifact: 97.8% 97.8% fever brute force · fever: 95.9% turbovec · fever: 95.9% faiss · fever: 95.9% simlar · fever: 96.4% 96.4% nq brute force · nq: 94.1% turbovec · nq: 94.1% faiss · nq: 94.1% simlar · nq: 94.0% 94.0% hotpotqa brute force · hotpotqa: 88.6% turbovec · hotpotqa: 88.5% faiss · hotpotqa: 88.6% simlar · hotpotqa: 89.9% 89.9% fiqa brute force · fiqa: 75.9% turbovec · fiqa: 75.8% faiss · fiqa: 75.9% simlar · fiqa: 75.6% 75.6% climate-fever brute force · climate-fever: 62.6% turbovec · climate-fever: 62.6% faiss · climate-fever: 62.6% simlar · climate-fever: 62.9% 62.9% dbpedia-entity brute force · dbpedia-entity: 57.0% turbovec · dbpedia-entity: 56.8% faiss · dbpedia-entity: 57.0% simlar · dbpedia-entity: 60.8% 60.8% msmarco brute force · msmarco: 53.4% no data faiss · msmarco: 53.4% simlar · msmarco: 56.1% 56.1% scidocs brute force · scidocs: 53.2% turbovec · scidocs: 53.3% faiss · scidocs: 53.2% simlar · scidocs: 54.1% 54.1% webis-touche2020 brute force · webis-touche2020: 47.1% turbovec · webis-touche2020: 46.8% faiss · webis-touche2020: 47.1% simlar · webis-touche2020: 51.9% 51.9% nfcorpus brute force · nfcorpus: 36.7% turbovec · nfcorpus: 36.8% faiss · nfcorpus: 36.7% simlar · nfcorpus: 37.0% 37.0% trec-covid brute force · trec-covid: 11.5% turbovec · trec-covid: 11.5% faiss · trec-covid: 11.5% simlar · trec-covid: 13.2% 13.2%
brute force turbovec faiss simlar

Sorted by simlar's Recall@100, descending. Hover any bar for the exact value. turbovec has no msmarco entry.

Per-query retrieval latency by dataset (log scale, ms) 0.1ms 1ms 10ms 100ms nfcorpus brute force · nfcorpus: 0.07ms/query turbovec · nfcorpus: 0.08ms/query faiss · nfcorpus: 0.37ms/query simlar · nfcorpus: 0.09ms/query 0.09ms scifact brute force · scifact: 0.06ms/query turbovec · scifact: 0.09ms/query faiss · scifact: 0.08ms/query simlar · scifact: 0.12ms/query 0.12ms arguana brute force · arguana: 0.37ms/query turbovec · arguana: 0.04ms/query faiss · arguana: 0.19ms/query simlar · arguana: 0.2ms/query 0.2ms scidocs brute force · scidocs: 0.26ms/query turbovec · scidocs: 0.06ms/query faiss · scidocs: 0.69ms/query simlar · scidocs: 0.31ms/query 0.31ms fiqa brute force · fiqa: 0.42ms/query turbovec · fiqa: 0.11ms/query faiss · fiqa: 2.34ms/query simlar · fiqa: 0.48ms/query 0.48ms trec-covid brute force · trec-covid: 4.2ms/query turbovec · trec-covid: 0.64ms/query faiss · trec-covid: 3.28ms/query simlar · trec-covid: 1.44ms/query 1.44ms webis-touche2020 brute force · webis-touche2020: 7.73ms/query turbovec · webis-touche2020: 1.22ms/query faiss · webis-touche2020: 8.31ms/query simlar · webis-touche2020: 1.2ms/query 1.2ms quora brute force · quora: 2.89ms/query turbovec · quora: 0.6ms/query faiss · quora: 6.26ms/query simlar · quora: 0.64ms/query 0.64ms nq brute force · nq: 14ms/query turbovec · nq: 2.98ms/query faiss · nq: 31.56ms/query simlar · nq: 1.81ms/query 1.81ms dbpedia-entity brute force · dbpedia-entity: 34.59ms/query turbovec · dbpedia-entity: 5.7ms/query faiss · dbpedia-entity: 263.44ms/query simlar · dbpedia-entity: 1.96ms/query 1.96ms hotpotqa brute force · hotpotqa: 29.61ms/query turbovec · hotpotqa: 5.95ms/query faiss · hotpotqa: 66.27ms/query simlar · hotpotqa: 3.19ms/query 3.19ms fever brute force · fever: 30.02ms/query turbovec · fever: 6.51ms/query faiss · fever: 63.79ms/query simlar · fever: 2.85ms/query 2.85ms climate-fever brute force · climate-fever: 28.78ms/query turbovec · climate-fever: 6.47ms/query faiss · climate-fever: 99.54ms/query simlar · climate-fever: 3.43ms/query 3.43ms msmarco brute force · msmarco: 193.4ms/query no data faiss · msmarco: 227.81ms/query simlar · msmarco: 4.35ms/query 4.35ms
brute force turbovec faiss simlar

Sorted by corpus size, smallest to largest. Log scale — corpora span 3,633 to 8,841,823 documents. faiss's bar runs off the right edge on the three largest datasets; hover for the exact figure.

Across all 14 BEIR datasets, simlar's hybrid retrieval finished in a combined 62.6 seconds. FAISS needed over 22 minutes to answer the same queries.

Reading the numbers

  1. simlar is the only one of the four that gets relatively faster as the corpus grows, not slower. On the two largest corpora — fever (5.4M docs) and hotpotqa (5.2M docs) — simlar answers both in 42.6 seconds combined. FAISS takes 915.9 seconds for the same two; brute-force exact search takes 419.4 seconds. Summed across all 14 datasets, simlar's total retrieval time is 62.6s against 564.6s for brute force and 1,358.6s for FAISS.
  2. Brute-force and FAISS land on nearly identical accuracy, because in this configuration they're doing the same math. Their macro-average NDCG@100 differs by 0.0001 (0.5602 vs. 0.5601), and per-dataset numbers match to three decimal places almost everywhere — e.g. hotpotqa 0.7626 vs. 0.7626, fever 0.8416 vs. 0.8416. FAISS here runs an exact index, so any gap between the two is pure implementation overhead, not a search-quality difference — and FAISS is consistently the slower of the pair despite computing an identical ranking (dbpedia-entity: 13.8s brute force vs. 105.4s FAISS).
  3. simlar wins Recall@100 and MRR, ties NDCG@100, and gives up a little MAP. Pruning the candidate set down to a smaller text_k/vector_k instead of scanning everything costs about a point of MAP (0.399 vs. 0.407–0.408) in exchange for the latency win above — an honest trade, not a free one.
  4. turbovec is the only real competitor on speed, and simlar still leads it by 1.9–2.9× on the largest datasets. turbovec's 4-bit quantized vectors get it to 5.95ms/query on hotpotqa and 6.47ms on climate-fever; simlar answers the same queries in 3.19ms and 3.43ms. Where turbovec pulls ahead is small corpora with sparse-but-precise matches — arguana (8,674 docs), where turbovec's 0.04ms beats simlar's 0.20ms.
  5. The single biggest swing in the whole table is trec-covid. simlar's MRR there is 0.955 against 0.801–0.811 for the three dense-only baselines. With only 50 queries and a corpus of dense biomedical literature, the keyword half of simlar's hybrid fusion is doing real work that none of the other three have access to.

Picking a lane

simlar's hybrid retrieval is the only one of the four whose query latency stays flat as the corpus scales into the millions, and it does that while matching or beating the three dense-only baselines on Recall@100 and MRR — the honest cost is a small amount of MAP. turbovec is the closest thing to a real competitor on speed, but simlar still leads it by 1.9–2.9× on the largest datasets. Brute-force and FAISS are worth keeping around as a ground truth — they're not competing on latency, they're confirming everyone else's ranking is correct.

Deciding which retrieval engine fits your latency budget?

If you're evaluating hybrid retrieval against dense-only search for a corpus that's going to keep growing, we'd like to hear about your workload.

Talk to the TekDatum team