The rotation should have been learned
What I got wrong
That post finished on two claims. The first, that "the rotation matters more than the rest of the scheme", I still think holds. The second was my reading of the Qdrant/Elastic split, where I treated Qdrant's preference for a "good default with mathematical guarantees and no calibration step" as one of two equally defensible positions and left it there. That's the one I'd narrow.
The paper
ASH is by Mariano Tepper, who is at Elastic now, and Ted Willke at IBM. It learns an orthonormal projection from your data, a PCA basis with a rotation that gets refined against the quantiser itself, projects the indexed vectors down to fewer dimensions and quantises them at a higher bitrate per dimension. The query never gets quantised at all - it's projected once, stays in floating point, and that asymmetry is where a good chunk of the speed comes from, since the projection acts as an encoder applied once per query rather than something undone on every dot product.
So it's the rotate-then-quantise shape I said was the durable part, with the rotation learned instead of sampled. Two things in it work against what I wrote.
The first is an assumption I hadn't looked at properly. Data-oblivious methods buy their guarantees by treating the input as isotropic, and section 4 says flatly that "these assumptions do not hold for modern vectors produced by embedding models". A Hadamard rotation is the right move when you have no idea which coordinates carry the energy, since it spreads the energy out. Embedding vectors are not in that situation - they come out of a trained model with fairly consistent structure in how variance sits across dimensions, and a random rotation discards that to make the quantiser's job uniform. Elastic had already got to roughly the same place from the benchmark side with OSQ's anisotropic loss, which I wrote about at the time without joining the two up.
The second is cost. Most of my sympathy for skipping calibration was really about what calibration used to involve: a k-means pipeline over the corpus, codebooks to train and store, a re-encode when things drifted. Table 7 prices the ASH version. On ada002-1m, 982,790 vectors at 1536 dimensions, training the projection at 2 bits down to 768 dimensions takes 2.05 seconds, and encoding the corpus takes another 1.08. The worst row in the table is 3072 dimensions with no reduction applied, at 34 seconds to train and another 6 to encode. Roughly three seconds per million vectors for the sensible configurations, which is small enough that I don't think it should be deciding anything.
I leaned on that same property again the day after, wondering whether being calibration-free was what would finally make late interaction affordable at scale. The storage argument there still stands, but the reason I gave for liking TurboQuant's version of it doesn't.
Where I'd still hold back
Cost was only part of the case for data-oblivious quantisation, and it's the part I can now wave away. The rest of it is about robustness. A learned projection is fitted to a sample of one corpus and inherits whatever that sample gets wrong, where a random rotation behaves the same on everything you throw at it. If you're Qdrant, serving customers whose embeddings you never see, "works the same on anything" is a different sort of promise from "quick to calibrate". ASH doesn't really engage with that - there's nothing in the paper about what happens to a learned projection as a corpus drifts away from what it was trained on. Retraining costs three seconds, so the fix is cheap enough, but knowing you need to is the harder half.
The more interesting claim
What I keep coming back to is that ASH is arguing the field has been optimising the wrong variable.
BBQ, RaBitQ, Weaviate's RQ, TurboQuant - all of them compete on bits per dimension with the dimensionality held fixed, heading towards one bit at full width. ASH says spend a fixed payload differently: fewer dimensions, more bits on each one. It reports 1-bit ASH competitive with 4-bit LeanVec, which uses four times the space, and repeatedly competitive with PQ and TurboQuant configurations at twice its footprint.
Those are the authors' own numbers and deserve the usual discount. Nobody outside has reproduced them, most of the accuracy comparisons live in the plots rather than in the text, and the paper concedes the trade-off gets "more nuanced" at low bitrates, which is where production sits. In May I gave Elastic credit for benchmarking TurboQuant themselves rather than taking the paper's word for it, and the same standard applies here.
The result that convinced me isn't a benchmark though. RaBitQ and extended RaBitQ turn out to be ASH with the dimensionality reduction switched off and the projection set to a random orthogonal matrix, and at one bit the training procedure recovers ITQ, a learning-to-hash method from 2011. The data-oblivious methods sit inside the same family, in the corner where you skip the learning step.
So if you're picking a quantiser and "no calibration required" is on your requirements list, find out what calibration actually costs before you let it rule anything out. I didn't, and it shaped what I wrote in May.
There's a second thread here about ASH's landmark vectors and where they come from in an inverted index. Anyone who's been following DiskBBQ can probably guess; that one needs its own post.