Public benchmarks · winnex-madhava 1.9.13 · pip install from PyPI

Three honest benchmarks, explained transparently

What the Winnex Madhava engine actually proves — and what it does not. Three public Kaggle notebooks, run with winnex-madhava==1.9.13 + winnex-ai-normalize==1.4.1 installed from PyPI, on real datasets. Every metric below is explained: what it measures, why it matters, and its honest limits.

0
bound violations
across all runs
100/100
genuine & deterministic
certificate exclusions
NaN→0.0
FAISS recall on
damaged data
NDCG 1.0
winnex ranking,
≥ FAISS ANN

Kaggle — Certificate (v2, legal+medical) Kaggle — Damaged dataset Kaggle — NDCG vs FAISS

01The per-document certificate — what a "proof" really is

Kernel: winnex-1913-certificado-v2-jus-med. This is the property no ANN index (HNSW, IVF, ScaNN) offers: for every document the engine discards, it can prove that document could not be in the true top-K.

The mathematics, in one line

For a query q and a document v, the Cauchy–Schwarz inequality gives an upper bound on their true similarity:

cos(v, q)  ≤  ⟨Pv, Pq⟩ + ‖v−PᵀPv‖·‖q−PᵀPq‖  =  UB(v,q)

If UB(v,q) < threshold — where threshold is the exact score of the 10th result — then v mathematically cannot be in the true top-10. The engine records this at the moment of pruning: it is a witness, not a post-hoc judge. This is what a compliance layer can sign (WORM) and what a regulator can audit.

What the certificate reports, per query

FieldMeaningWhy it matters
total_excluded_countHow many documents the bound proved outside the top-KThe scale of the provable pruning
genuine_exclusionsEvery sampled excluded doc has upper_bound < global_thresholdConfirms the certificate is not reporting false exclusions
deterministic_commitmentTwo calls with the same query return the identical sampleReproducibility for audit
count_matchcommitment.total_excluded == audited.audit_excludedThe compact commitment agrees with the full audit
recall_guaranteepool_only vs exact_globalHonest scope: is the top-K global, or only best-within-the-pool?

Measured results (real embeddings, larger corpora)

CorpusNdModeNDCG@10Recall@10Gen. excl.DeterministicExample exclusion
GloVe400,000100default1.00001.0100/100100/100UB −0.012 < 0.604
GloVe400,000100audit_exhaustive1.00001.0100/100100/100exact_global
HN-OpenAI100,0001536default0.98051.0100/100100/100

Read carefully: recall@10 = 1.0 here means the engine returns the exact top-10 of the same embedding space (verified against a numpy brute-force ground truth on the same vectors). It does not mean the embeddings capture human relevance — see the honesty section below. What the certificate adds is different and orthogonal: for every one of the ~37.8M accumulated exclusions on GloVe, the engine can prove it was not in the true top-K.

Why this exists — legal & medical retrieval

In legal e-discovery or medical triage, "we searched and didn't find it" is not acceptable if you cannot show why a document was set aside. An ANN index returns a fast guess with no way to prove a miss. Madhava returns the top-K and, for every discarded document, a signed bound proving it was outside the true top-K of the index. That is the difference between "the model thinks" and "the math proves". The notebook embeds real Supreme-Court judgments and medical transcriptions with multilingual / biomedical sentence transformers to exercise the certificate on domain text.

02Damaged data — why the dataset is corrupted, and what that means

Kernel: winnex-1913-dataset-danificado. The question: what happens when the input is broken — not the engine?

Why this dataset, and why it matters

Real-world corpora are dirty. The most instructive case is Word2Vec GoogleNews: 94.7% of its raw vectors are NaN — the file itself is corrupt. A naive pipeline indexes it, the engine reports bound_violations = 0 (true — the bound is internally consistent), and nobody notices the results are garbage. That silent failure is the danger this benchmark exists to expose.

The core finding — measured, not asserted

We inject a controlled corruption (5–10% NaN rows into an otherwise clean corpus) and run both pipelines on the same broken data:

PipelineWhat it does with NaNResult
Winnex quality gateDetects dataset.nan (FAIL) and blocks the corpus before indexingBlocked — refuses to index garbage
Winnex allow_unsafe=TrueIndexes anyway (to show the alternative)recall@10 = 0.0, NDCG = 0.0
FAISS (FlatIP / HNSW)No quality gate — indexes the NaN silentlyrecall@10 = 0.0 (FlatIP & HNSW)
quality gate FAILED — dataset.nan: 1,000,000 of 10,000,000 values are NaN/inf (10.0000%) — the engine would silently produce garbage scores with 0 bound violations. ✓ quality gate BLOCKED the corpus — it did not index garbage

The allow_unsafe row is the honest counterfactual: if you force the engine past its own gate, recall collapses to 0.0. The bound is still "0 violations" — because the bound is about internal consistency, not data quality. That is exactly why the gate exists: to stop a 0.0-recall corpus from being indexed as if it were a 1.0.

What "0 bound violations" does and does not mean

This is why the normalize layer runs a quality gate before the engine — it is the input firewall. The damaged-data notebook demonstrates the firewall catching a real corruption that FAISS, having no such layer, indexes silently.

03NDCG vs FAISS — ranking quality, measured by order

Kernel: winnex-1913-ndcg-vs-faiss. Recall@10 answers "are the right 10 present?" — it ignores order. NDCG@10 with graded relevance punishes a correct-but-misordered ranking. This is the metric that separates an exact ranking from an approximate one.

Why graded NDCG, not binary

With binary relevance (a document is either in the top-50 or not) and a ground truth of exactly k relevant items, NDCG@k collapses toward recall — any ranking that places the k correct items in the top-k scores ~1.0 regardless of order. Graded relevance (rel = 1/(rank_in_GT + 1)) makes the position matter: putting the 3rd-best document first costs NDCG. Measured on synthetic data, a perfectly-reversed top-10 scores 0.56 under graded NDCG vs 1.0 under binary — the distinction the benchmark needs.

Results on real datasets (ground truth = numpy brute-force, top-50)

DatasetdMethodNDCG@10Recall@10Build (s)Latency/query
GloVe100 Winnex (pca)1.00001.05.8721.2 ms
FAISS FlatIP1.00001.00.086.7 ms
FAISS HNSW0.99591.056.80.38 ms
FAISS IVF0.99541.00.822.3 ms
MNIST784 Winnex (pca)1.00001.018.67.4 ms
FAISS FlatIP1.00001.00.1915.7 ms
FAISS HNSW1.00001.019.10.39 ms
HN-OpenAI1536 Winnex (pca)0.97530.99115.6 ms
FAISS FlatIP (exact)0.97860.99148.3 ms
FAISS HNSW0.97310.991.08 ms
FAISS IVF0.96990.9919.4 ms

Reading the table honestly

  • Winnex ranks at or above the ANN indexes on every dataset — NDCG 1.0 on GloVe/MNIST, and on HN-OpenAI (0.9753) it sits between exact FlatIP (0.9786) and the ANN methods, while being ~3× faster than the exact scan (15.6 vs 48.3 ms).
  • FAISS HNSW is the latency king (0.4–1 ms). We do not hide that. It is an approximate index without a per-document proof — that is the trade the benchmark makes explicit, not a bug.
  • The winnex build is not free — it runs a quality gate + PCA routing. On GloVe it is 5.9 s vs HNSW's 56.8 s (winnex wins); on MNIST 18.6 s vs HNSW's 19.1 s (parity). The build cost is reported honestly in every cell.
  • HN-OpenAI recall is 0.991, not 1.0 — in pool_only mode the top-K is exact within the k1 pool, not proven global. The recall_guarantee field says so. Nothing is rounded up.

04The metrics, explained honestly — and their limits

Ground truth: what we compare against

The recall and NDCG in these notebooks are measured against a numpy brute-force exact scan over the same vectors — a real external ceiling, not the motor's own search_exact. This avoids the circularity of "the engine scoring itself".

Honest limit: the ground truth is computed in the embedding space. It proves the engine retrieves the geometrically-correct neighbors; it does not prove the embeddings capture human relevance. Two documents that are near in vector space but unrelated semantically will still be "correctly" retrieved. Embedding quality is a separate question the engine does not and cannot solve.

Recall vs NDCG vs the certificate — three different claims

  • Recall@10 — "are the true top-10 present?" Measures completeness of the returned set.
  • NDCG@10 (graded) — "are they in the right order?" Measures ranking quality.
  • Certificate (excluded set) — "for every document we did NOT return, can we prove it was outside the top-K?" This is unique to Madhava; no ANN index offers it.

They answer different questions. A benchmark that reports only recall can hide a misordered ranking; one that reports only latency hides the absence of proof.

What "0 bound violations" means — precisely

It means: every document the engine pruned via the Cauchy–Schwarz bound was provably not in the exact top-K of the scored pool. It is a soundness guarantee about the pruning, reproduced on every run.

Honest limit: it is not a statement about data quality or semantic relevance. On a corrupted corpus you can have 0 violations and useless results — which is precisely why the quality gate (benchmark #2) exists as a separate, earlier layer.

Scope: pool_only vs exact_global

By default the exact post-filter re-scores only the survivors of the k1 pool. The result is exact within that pool — the engine reports recall_guarantee = "pool_only". When a compliance workflow needs the global guarantee, audit_exhaustive=True forces the pool to cover the whole corpus (k3 == N) and reports "exact_global", at a predictable O(N·d) cost.

These notebooks run both modes and report both — the honest scope is never assumed.

The reproducibility contract

Everything here is public and runnable: PyPI winnex-madhava==1.9.13 + winnex-ai-normalize==1.4.1, the exact notebook source in each Kaggle kernel, and full execution logs. If a number looks surprising, run the notebook — it will reproduce. We would rather show a 0.975 than claim a 1.0.

Winnex AI — deterministic vector search with mathematical proof. · GitHub · Kaggle · PyPI: winnex-madhava · Stack Whitepaper (PDF)

Honesty policy: all benchmarks are auto-executed public notebooks. Metrics report what was measured, including non-perfect numbers. Claims that could not be measured are not made.