NeoMME's card offers Matryoshka truncation and no quantization. On SciFact its token vectors at one bit per coordinate take 5.1 KB per document and score 0.707 nDCG@10; the dense head tops out at 0.553 at any size. On page images the 1-bit token index is within noise of fp32 too.

For now, I tried a small experiment in Colab: * * * The short version is: **I would not change the architecture yet.** What looks most useful now is separating a few effects that are currently superimposed: 1. **basin geometry** — especially threshold/connectivity behavior in 64-D versus the 3-D view; 2. **64-D candidate generation vs full-4096-D discrimination** ; 3. **“different data can coexist in one memory” vs “different data actively compete in retrieval.”** Those are slightly different questions, and each seems testable with a fairly small control. I also think the full-300 rerun is the right reset point. Since the old `.7822` came from the first 50 claims, I would treat the current full-300 result as the useful baseline going forward rather than trying to reconcile new changes against the old number. ### What I would try first Priority | Small check | What it separates ---|---|--- 1 | Plot `threshold -> largest connected component` in both 64-D and 3-D | projection effects vs basin/graph effects 2 | Measure 64-D shortlist recall before doing the 4096-D stage | candidate generation vs final ranking 3 | Compare `BM25+64D`, `BM25+4096D`, and the current three-arm fusion | dimensionality benefit vs fusion benefit 4 | Keep the current mixed-memory test, but call harder distractors a separate test | co-location vs retrieval interference 5 | Only if something looks suspicious, compare exact 64-D search with HNSW | representation quality vs ANN approximation The first two seem especially high-information for relatively little work. What I actually tested in Colab, and what it does **not** reproduce (click for more details) 1. Basin geometry: I would diagnose the giant component before replacing the clustering method (click for more details) 2. 64-D and 4096-D: I would measure their *roles*, not just their final scores (click for more details) 3. I think “same memory” contains two useful but different tests (click for more details) 4. Exact search is a cheap control if the ANN layer ever becomes ambiguous (click for more details) 5. A note on “SciFact is lexical first” (click for more details) 6. Only after the above: fusion parameters and evaluation hygiene (click for more details) Things I would **not** chase yet (click for more details) So if I were choosing only three next checks, I would use: 1. Basin: threshold -> component-size curve + inspect the bridge merges 2. Retrieval: 64-D shortlist recall -> full-4096-D rerank -> compare against the three-arm RRF 3. Memory mixing: keep the current filtered co-location test and only add a hard-distractor test if that is a separate property you actually want to measure What I like about those three is that none of them requires throwing away the current design. They mostly answer **which component is already doing what**. Once those boundaries are visible, the next architectural move — if one is needed at all — should be much easier to choose.

splatRAG 3 teaser — SciFact, poisoned store Local Gaussian-splat memory. Append-only cold log. BM25 + 64-d HNSW. The 3-d field is PCA of those 64-d vectors — the picture, not the index. SciFact (BEIR test, 300 claims, k=10) on a store that also holds 5,000 Urban Dictionary rows, dreamed together: ┌───────────────┬────────┬─────────┐ │ │ R@10 │ nDCG@10 │ ├───────────────┼────────┼─────────┤ │ Floors we set │ 0.88 │ 0.75 │ ├───────────────┼────────┼─────────┤ │ This run │ 0.8804 │ 0.7624 │ └───────────────┴────────┴─────────┘ Handshake: splatrag handshake --k 10 --no-ingest. Eval filters domain=scifact so slang cannot rank as a false positive. The science documents still sat in the same field as the junk. The old public SplatRagBench hybrid 0.7822 nDCG@10 is the first 50 claims (Nomic). Honest full-300 on that binary was 0.6664. What moved v3 over the floors: RRF (BM25×1.3, k=10) on the top 30, then a third RRF arm from the query’s full 4096-d Qwen3-Embedding-8B cosine. 64-d was already in hybrid; the leftover 4032 dimensions were sitting unused. Pure cosine rerank of that pool died (0.7174). SciFact is still lexical first. Basins pack in 64-d (k-NN, cosine 0.80). 3-d union-find had mashed 4,035 papers into one unlabeled well. Below is example of AI’s memory. On below you see one big color cause basins still need to settle.

I spent a few days testing a simple hypothesis: does training a binary embedding model natively (with a binary loss) produce better retrieval than just binarizing a float model post-hoc? The setup is deliberately small : bert-mini (~11M params), CPU-only training on a Mac Mini M4 Pro, NLI 550k pairs, 3 epochs. Key results on SciFact Recall@10: * Float32 384-dim: 0.313 * Post-hoc binary 384-dim: 0.236 (−25%) * Native binary 2048-dim: 0.276 (−12% vs float, but +17% vs post-hoc) * Native binary 4096-dim: 0.296 (−5% vs float, +25% vs post-hoc) And at 1M vectors with FAISS (AVX2+POPCNT on x86): * Native binary 2048-dim: 12× faster than float32, index 6× smaller The three things that made the binary model actually converge: 1. STE with {-1,+1} (not {0,1}) 2. tanh contrastive loss (aligns with the Hamming metric at eval) 3. Differential learning rate — projection head at 50× the encoder LR Models and code on GitHub / HuggingFace (korben99/bne-binary-2048). Happy to hear if you’ve seen similar or contradictory results, especially at larger scales or with bigger backbones. Also curious whether the 2048-dim sweet spot holds with e.g. MiniLM.

YouTube video by CrazyTech

Update: Quora (523K passages, 10K queries) just dropped → **0.8818 nDCG@10** pure dense → 95.26 % Recall@10, 99.45 % Recall@100 Current 5-dataset average: **0.6279** (SciFact, NFCorpus, TREC-COVID, ArguAna, Quora) — already +10 % over the ~0.52 hybrid ceiling everyone accepted as final. Still zero reranker, zero BM25, zero distillation. Just Nomic Embed v1.5 + one prefix + proper normalization.