The exact-search caveat is the result, and I think it belongs in the bullets rather than the limits.

Your table is careful enough that this falls straight out of it. scifact, your numbers, exact Faiss:

  MUVERA 10,240   0.50021
  MUVERA  2,048   0.36757
  LEMUR   2,048   0.54910     +49.4% matched budget, +9.8% vs full width

Both of those reproduce off your table to the digit, so I am reading it the way you meant it.

Then the IVF line, on the same dataset, so nothing needs extrapolating: default IVF costs LEMUR 43% and MUVERA 25%.

  LEMUR   2,048   0.54910 -> 0.31299
  MUVERA  2,048   0.36757 -> 0.27568      LEMUR +13.5%
  MUVERA 10,240   0.50021 -> 0.37516      LEMUR -16.6%

The 49% becomes 14%. Against the full-width vector it goes negative.

What makes that more than a footnote is where your own threshold sits. txtai does exact search through 5,000 rows and switches to IVF above it. Five thousand rows is also about where saving 5x on storage starts being a reason to do anything at all. So the regime that motivates a fixed-vector encoding is the same regime the default index gives it back in. Someone who reads the post, indexes 200k documents and takes the default will measure the opposite of the headline.

You do say to pin faiss.components to IDMap,Flat. I would promote that out of the limits section, because it is load-bearing.

One presentational thing, since the post is what gets quoted and the blog is the part that is honest: the two bullets have different baselines. The 49 to 62% is against matched-budget 2,048 MUVERA, the 5x storage is against the 10,240 default, and against that same 10,240 the quality gain is 8.4 to 22.9%. No single configuration is both 49% better and 5x smaller.

The actual question, though, is about the geometry, because I think your two findings may be the same finding.

Mean centering went in because LateOn token vectors were anisotropic enough that the encoder had little useful variation left to preserve. IVF is a clustering index. It cares about exactly that property. LEMUR documents are OLS weights over a stored sample, which is a very different distribution from MUVERA's concatenated projections, and it would not surprise me if it clusters worse for the same underlying reason.

Does centering narrow the 43%, or is the IVF penalty independent of it? And which MUVERA width is the 25% measured on? Under the 10,240 reading the ordering inverts, under 2,048 it only compresses, and those are quite different recommendations.

Your geometry probe is not failing to explain the gap. It is the explanation, and it works through
the budget rather than through clustering quality.

nprobe is a cell budget. What decides recall is a document budget. Those are the same number only
when the cells are equal, and your own CV says they are not.

Your defaults reproduce from the source, exactly

# txtai/ann/dense/faiss.py
cells(count)  = max(min(round(4*sqrt(count)), int(count/39)), 1)
nprobe()      = 6 if count <= 5000 else round(cells(count)/16)
create()      = index_factory(d, "IVF{cells},Flat", METRIC_INNER_PRODUCT)

At 5,183: min(288, 132) = 132, and round(132/16) = 8. Both of your stated defaults, on the nose.
Worth noting you are 183 rows past the count <= 5000 step, which is what moved nprobe 6 -> 8.

The measurement

I built your exact index config (IVF132,Flat, inner product, n=5183, d=2048) on synthetic corpora,
with the arms calibrated to hit the mean pairwise cosine you reported, then read the scanned mass
off faiss's own counter, faiss.cvar.indexIVF_stats.ndis.

arm                        mean cos    CV      ndis/query   % of corpus scanned
LEMUR-like                    0.050   0.574         617.4        11.91%
MUVERA-like                   0.230   1.282        1379.2        26.61%
                                            nprobe/nlist = 8/132 =  6.06%   <- what the knob claims

Identical nprobe=8. The skewed arm scans 2.23x more of the corpus.

The instrument checks itself. On a fully isotropic arm (cos 0.000, CV 0.155) the counter returns
314.5 distances, 6.07% of the corpus, against an advertised 6.06%. So nprobe/nlist is the true
scanned fraction exactly when the cells are balanced, and only then.

First-order size bias gets the direction and most of the size: a query lands in cell i with
probability n_i/N, so the expected cell is m(1+CV^2), giving 1.99x against the measured 2.23x. The
residual is that the big cells sit together near the shared mean, so the extra 7 probes are
correlated with the first.

What that does to the default-IVF column

It was never a matched-budget comparison. The encoding with the flatter cluster histogram honours
nprobe=8 literally; the skewed one quietly draws about twice the documents for the same knob.
LEMUR is not degrading more under IVF. It is being scored at less than half the scan.

To match the MUVERA-like arm's scanned mass, the LEMUR-like arm needs nprobe around 20, not 8.

Log-interpolating your curve (nprobe 8 -> 0.32346, nprobe 64 -> 0.5085) to nprobe=20:

nprobe=12   gap 34.5%   0.3595
nprobe=20   gap 26.3%   0.4050     <- matched scanned mass

0.4050 against MUVERA-10240's default-IVF 0.37341, at one fifth the storage. That is crude, two
points and a log, and it is your data not mine. But it says the ordering may not invert at all.

The one line that settles it

faiss.cvar.indexIVF_stats.reset()
index.search(queries, k)
print(faiss.cvar.indexIVF_stats.ndis / len(queries))

Equalise ndis, not nprobe, and re-run the four cells. If the LEMUR penalty survives at matched
ndis, the routing story is dead and it really is representation.

Centering, and the leg that would kill this

Under this read centering is a pure routing effect, which is exactly why your exact column stayed
flat while IVF moved 11.4 points. So it has to show up in the cluster histogram:

• centering MUVERA should lower its CV, cutting its free scan (0.37341 -> 0.31308, matches)
• centering LEMUR should raise its CV, buying scan (-41.1% -> -29.7%, matches in direction)

That second one is the weak leg. LEMUR is already near-isotropic at cos 0.05, so there is not much
common component to remove. If you re-run the k-means CV before and after centering and LEMUR's CV
does not move up, my explanation is wrong and yours is right.

One thing on the exact column: 0.54910 -> 0.5484 is flat to 0.13%, not identical. Centering documents
only shifts every score by a per-query constant and should leave nDCG bit-identical. So either
queries were centered too, or that 0.0007 is tie-breaking. Which was it?

Two small ones

The not about 14% should be about 17%. 0.32346/0.27568 = 1.173. The 14.3% is a different ratio,
0.27568/0.24111, which is how much the extrapolation overshot MUVERA-2048. Both readings support
your point that it was optimistic, so nothing downstream moves.

And nprobe=64 is corpus-specific. txtai pins the scan fraction at 1/16 in both regimes, since
cells switches from n/39 to 4*sqrt(n) at n=24,336 and nprobe tracks it:

n=     5183   nlist=  132   nprobe=   8   6.06%
n=    24336   nlist=  624   nprobe=  39   6.25%
n=  1000000   nlist= 4000   nprobe= 250   6.25%

So 64 is nlist/2, an 8x cost, and it stays 8x at a million rows. Publishing it as a fraction
travels; publishing the integer does not.

Last thing, and it is the storage argument rather than a critique: neither MUVERA width leaves the
298-444 participation band. The extra 8,192 dimensions bought no additional spread, while LEMUR-2048
reaches 692 out of 2,048. That is a model-free version of your headline and it does not depend on
which index anyone picked.

Does LEMUR's cluster-size CV go up when you center it?

@Morgan-coded suggested this update to the article for the passage beginning withtxtai's Faiss backend uses exact search through 5,000 rows to clarify what's being discussed here.

txtai's Faiss backend uses exact search through 5,000 rows and switches to IVF above that threshold. At 5,183 rows on scifact, it selects `IVF132,Flat` with `nprobe=8`. Default IVF reduced NDCG at 10 by 41% for LEMUR-2048 (0.54910 → 0.32346), 34% for MUVERA-2048 (0.36757 → 0.24111), and 25% for MUVERA-10240 (0.50021 → 0.37341).

Raising `nprobe` to 64 recovered LEMUR-2048 to 0.5085, 7.4% below exact while remaining approximate. Tuned against tuned, LEMUR-2048 at 0.5085 still edged MUVERA-10240 at 0.48939 with one-fifth the storage. Collection-mean centering narrowed LEMUR's IVF gap from 41% to 30%, but hurt MUVERA under IVF, so it is not a general substitute for index tuning. These are single-dataset scifact/ColBERTv2 numbers from the same harness as the article's tables. Pin `faiss.components` to `IDMap,Flat` when exact search is practical; otherwise raise `nprobe` rather than accepting the default.

The residual is not representation quality. It is the participation ratio you already published, and it is the same number that makes LEMUR win the exact column.

Concession first: cell-size skew is dead as the main story. Your matched-mass run settles it, 9 not 20, and m(1+CV^2) overstated the real magnitude exactly the way my synthetic did.

The dose-response

Same rig, n=5183, IVF132,Flat, inner product, 1109 queries, 3 seeds. Calibrated to the numbers you measured this time, not the ones I guessed. Arms are unit vectors with a power-law covariance spectrum tuned to a target participation ratio, plus a common direction tuned to a target mean pairwise cosine. Metric is recall@10 of the probe set against exact, at matched scanned mass near 420 ndis/query.

cos held at 0.05, PR swept    cellCV   ndis/q   recall@10
PR=200                         0.991    431.1      63.8%
PR=300                         0.944    423.2      59.0%
PR=440                         0.888    417.0      52.7%
PR=692                         0.797    426.2      44.2%
PR=1000                        0.672    429.6      33.8%

PR 200 to 1000 costs 30 points of recall at constant mass. The CV column runs the other way: the arm that loses most has the flattest histogram.

The control says CV is not doing the work:

PR held at 692, cos swept     cellCV   ndis/q   recall@10
cos=0.00                       0.693    420.3      45.1%
cos=0.05                       0.797    426.2      44.2%
cos=0.23                       0.956    418.2      41.4%

CV moves 0.69 to 0.96 and recall moves 3.7 points. PR moves and it moves 30.

It lands on your number

Your two arms at their reported geometry, matched mass:

MUVERA-like  PR 370  cos 0.23    recall@10  54.5%
LEMUR-like   PR 692  cos 0.05    recall@10  44.2%    ratio 0.811

Your measured retention is 0.33656/0.54910 = 0.6129 against 0.37341/0.50021 = 0.7465. Ratio 0.821.

A model that knows nothing about either encoder except two geometry statistics you published reproduces your retention ratio to within a point. Single dataset, synthetic corpora, so not proof. But the residual has a name.

Two things I got wrong, so they do not cost you a run

I proposed neighbour contrast as the mechanism. It is flat: 2.79 at PR=200, 2.90 at PR=1000. Not that.

What moves is where the neighbours sit. Distinct cells holding a query's exact top-10 goes 6.27 to 8.83 out of 10 across the sweep, and the fraction in the query's nearest cell goes 23.1% to 9.7%.

I also expected a graph index to erase this, since HNSW does not partition. It does not:

matched-ish budget      ndis/q   recall@10   gap
MUVERA-like IVF132       433.1      54.5%
LEMUR-like  IVF132       426.2      44.2%    10.3
MUVERA-like HNSW32       536.4      71.4%
LEMUR-like  HNSW32       592.1      57.8%    13.7

LEMUR-like got the larger budget there and still lost by more. So this is not an IVF artifact. It is effective dimensionality making approximate search harder in general, which means pinning IDMap,Flat stays right, and it is right because it is exact, not because it is a better approximation.

The cheap check on real data

You have both indexes and the exact results already. Per query, count distinct cells holding its exact top-10, and the fraction in the query's nearest cell. No new index, no re-encode. I predict roughly 8/10 against 7/10, and about 14% against 20%. That is your query-centroid margin idea one step cheaper.

Why it matters for the article

Price of the fix, from the same sweep: LEMUR-like needs nprobe=16 to reach MUVERA-like's nprobe=8 recall. Twice the knob, 1.59x the scanned mass.

The uncomfortable part is that the storage win and the ANN penalty are the same property. 692 of 2048 dimensions carrying signal is why 2048-wide LEMUR beats 10240-wide MUVERA under exact search, and it is why the neighbours scatter under any partition. You do not get to bank both.

Does the limits section want that sentence?

Would you be able to succinctly summarize what you're trying to say in a single sentence or paragraph? It's hard to follow.

EDIT: I think what you're saying is that mean centering doesn't work with FAISS IVF. Do you think the same holds true for HNSW etc?

Your two statistics are one curve read at two points, and recall is that curve. Not a correlate of it.

For IVF-Flat with an exact scan inside probed cells, a true top-k neighbour is returned if and only if its cell is among the nprobe nearest centroids. It cannot be crowded out, because it already beats everything in the corpus. So

recall@nprobe(q) = |{i in exact top-k(q) : cellrank_q(cell(i)) <= nprobe}| / k

where cellrank_q orders cells by query-to-centroid distance. Exact, not approximate. I checked it against a real IVF scan rather than trusting the argument, 3 synthetic arms, nlist=132, k=10:

arm             nprobe   IVF recall   CDF(nprobe)   abs diff
LEMUR-like           1       0.0560        0.0560   0.00e+00
LEMUR-like           4       0.1630        0.1630   0.00e+00
LEMUR-like           8       0.2727        0.2727   0.00e+00
MUVERA-10240         1       0.0507        0.0507   0.00e+00
MUVERA-10240         4       0.1793        0.1793   0.00e+00
MUVERA-10240         8       0.2983        0.2983   0.00e+00
MUVERA-2048          1       0.0940        0.0940   0.00e+00
MUVERA-2048          4       0.2813        0.2813   0.00e+00
MUVERA-2048          8       0.4333        0.4333   0.00e+00

Which means your nearest-cell fraction is not a proxy for recall. It is recall at nprobe=1. And distinct-cell count is a lossy summary of the same rank multiset, one that throws away the ordering, which is the only part that decides retrieval.

The MUVERA-2048 cap is a CDF crossing, and it is already in your numbers

Read your table as two points on each arm's curve:

arm             CDF(1) = nearest   CDF(p) = recall   gain over ranks 2..p
LEMUR-unc            0.235              0.600              0.365
MUVERA-2048          0.215              0.649              0.434
MUVERA-10240         0.272              0.707              0.435

MUVERA-2048 starts below LEMUR-unc at rank 1 and finishes above it. The curves cross. That is what "scatter tolerant" is: nothing tolerates anything, the neighbours simply sit at ranks 2 to p instead of rank 1, and the probe budget collects them either way.

The part I did not expect: both MUVERA arms recover the same mass over ranks 2..p, 0.434 against 0.435. One point apart in a thousand. They differ only at rank 1, where the 10240 arm is ahead by 5.7 points. Meanwhile LEMUR-unc is not worst at rank 1 at all, it beats MUVERA-2048 there, and loses 0.07 in the tail.

So the question changes shape. Not "what makes MUVERA-2048 tolerant of scatter". Rather: why do two encoders at 2048 and 10240 have identical rank-2-to-p recovery, and why is LEMUR's deficit entirely in that stretch and not at the head.

This assumes the three recall figures are at one nprobe. If they are not, the third column is wrong and I would want the per-arm nprobe.

Your r = 0.52 to 0.63 needs a null

Nearest-cell fraction correlating with per-query IVF recall is corr(CDF_q(1), CDF_q(p)). Two points on the same per-query curve are correlated before any mechanism exists. So I measured what the identity alone produces, three quite different geometries, 1109 queries each:

geometry              nprobe   r(CDF1, CDFp)   r(distinct, CDFp)
power 0.6 + clumps         8           0.436              -0.608
power 0.6 + clumps        16           0.306              -0.502
power 0.9 isotropic        8           0.440              -0.686
power 0.9 isotropic       16           0.312              -0.558
power 0.3 isotropic        8           0.434              -0.337
power 0.3 isotropic       16           0.327              -0.295

0.31 to 0.44, stable across geometries that differ wildly in effective dimensionality. Your 0.52 to 0.63 is above that, so there is signal, but the mechanism-free floor is most of the way there.

The other column is the more useful one. Distinct-cell count is the stronger per-query correlate in every arm I ran, and it is negative, as it should be. You reported the weaker of your two statistics as the predictive one.

Where I was wrong

I tried to build a synthetic pair reproducing your crossing, more scatter and lower nearest-cell fraction but better recall. I got one at seed 11, margin 0.006. It reversed sign at two of three seeds. So I have no synthetic counterexample to offer, and the crossing in your data is the only measured one. Reporting the failed attempt because a 0.006 margin at one seed is exactly the kind of thing I would want flagged if I were reading it.

The cheap version of every sweep you have left

Record the rank, not the count. One pass over the exact top-10 gives a histogram over ranks 1..nlist, and the CDF of that histogram is the recall curve at every nprobe at once. nprobe 8, 9, 16 and 20 all fall out of the same pass, no search re-run, no re-encode. You already compute query-to-centroid distances at search time, so the rank is free.

It also prices centering directly. Centered LEMUR passing MUVERA-10240's default at nprobe=9 and uncentered at nprobe=20 are two crossings of one horizontal line, and the gap between the curves is the scan surcharge, in probes, per arm.

One caveat: this is IVF-Flat only. If anything reranks over quantized codes the equality becomes an upper bound, which is another argument for the IDMap,Flat pin.

If the rank histogram shows both MUVERA arms sharing a tail shape that LEMUR does not, is that still a property of the encoder, or of where kmeans put the centroids for each one?