Quanta: A Self-Contained Python Library for Hybrid Retrieval over Quantised Embeddings, Lexical Indexes, and Knowledge Graphs
Ioannis E. Livieris
cs.IR, cs.AI
2026-09-16
Quanta unifies 4-bit dense search, BM25, and graph traversal. Graph only enlarges candidates; content re-scores them. A clinical case grows the pool ~3.3x, with no labeled eval.
A serious RAG stack often means four systems at once: a vector index, a full-text engine, a graph database, and a document store. Each brings its own ops surface and failure modes, and the glue that fans a query across them is rewritten per project. Dense encoders handle vocabulary mismatch; BM25 covers rare tokens such as product codes and statute numbers. Neither uses relationships the corpus owner already knows but the text never states: a diagnosis that is comorbid with another, a drug that interacts with another.
Quanta treats that as one retrieval problem, not four services. It is an MIT-licensed Python library that exposes 4-bit quantized dense search, Tantivy BM25, and graph traversal behind a single async SEARCH(). The paper is explicit: this is a system description. A controlled retrieval evaluation is left for later.
Vector compression is delegated entirely to TURBOVEC, an implementation of TurboQuant. Quanta claims no contribution to quantization or approximate nearest neighbor. One million 768-dimensional vectors at 4 bits occupy about 366 MiB versus 2.86 GiB in float32. Search is exact over the quantized representation, linear in corpus size, with no external ANN service.
Fusion is weighted Reciprocal Rank Fusion. Cosine, BM25, and hop distance are incommensurable, and score normalization is query-dependent, so the library fuses ranks. A document missing from a leg contributes nothing from it. Default krrf is 60. Dense indexes split wdense; BM25 and the graph get their own weights.
The graph is the real design split from GraphRAG. Pass one ranks by content and BM25, takes the top GRAPHSEEDK as seeds, then runs a bounded BFS for GRAPHHOPS. Newly admitted IDs are not injected with a synthetic score. They are re-scored by a second dense search constrained to that allowlist, so an expanded neighbor competes on similarity to the query. Default wgraph is 0: the graph decides what is considered, never how it ranks. With wdense=0.7 and wgraph=0.3, a one-hop neighbor can overtake the best content match (0.0159 versus 0.0115). Tuning therefore targets seed size and hop count, not graph weight.
Metadata filters use the same allowlist: resolve the predicate first, then scan only admissible vectors, instead of fetching top-K and silently shrinking effective K. Optional backends have null implementations, so a deployment can start as pure vector search.
The bundled clinical graph is synthetic: 100 patients, 30 physicians, 12 ICD-10 diagnoses, 12 procedures, 12 medications, 5 hospitals, plus nine authored COMORBIDWITH edges and ten INTERACTSWITH edges. Narratives are in Greek. Text uses a 768-d multilingual encoder, images a 512-d CLIP encoder, all 4-bit, 107.3 KiB versus 858 KiB in float32.
Three dense legs (diagnoses, procedures, patient summaries) plus BM25, with wdense=0.5, wbm25=0.3, wgraph=0. At k=6, three seeds, two hops, pass one yields about 18 IDs; BFS reaches 50 nodes; 41 to 42 are new; about 70% get a constrained similarity; the pool grows by roughly 3.3x. For "heart failure, dyspnoea", E11 (type 2 diabetes) sat sixth on BM25 alone and was absent from dense top-k. Expansion from I50 across a comorbidity edge admits it; the dense term becomes 0.0025, fused score rises from 0.0046 to 0.0071, and rank moves to fourth. Dense or dense-plus-BM25 finishes in 7 to 9 ms; expansion raises that to 44 to 115 ms.
The same substrate drives a 12-tool agent. Six unseen clinical questions were answered by a local 27B open-weight model with no errors. Tool calls took 19 to 984 ms against 19 to 32 s turns, retrieval under 5% of the turn. An English referral matched a Greek nephrology narrative at cosine 0.620 after quantization.
For a team that wants hybrid retrieval without operating four services, this is a single-process path. Treating the graph as a candidate expander, then re-scoring by content, avoids the common failure where proximity promotes a neighbor over the best match. The allowlist serves metadata filters and expansion re-scoring with one primitive. At this corpus size, 4-bit exact scan is cheap relative to generation.
It does not show that retrieval is more accurate. There are no relevance judgments and no baseline ranker. Linear scan on 100 synthetic patients says nothing about million-scale corpora.
The authors say this themselves: the measurements characterize the architecture, they do not establish retrieval superiority. The graph is authored, not extracted, so the study tests expansion, not extraction quality. Default wgraph=0 is insufficient when expanded documents have no vectors; then the graph leg must enter fusion and hop distance can dominate again. "Six questions, no errors" has no control system, and generation dominates latency, so it does not speak to retrieval quality. The 0.620 cosine is a single point, not a retrieval metric. Exact search over quantized vectors will break first as the corpus grows.