Benchmarks (Beta)
Two questions decide whether Aito fits a problem: is it accurate enough? and is it fast enough? This section answers both with reproducible numbers ā accuracy against tuned ML baselines and public datasets, and throughput/latency against the kind of engine you'd otherwise reach for.
We try to be honest about where Aito wins and where it doesn't.
Where Aito competes ā and where it doesn't
Aito is a predictive database: the same from/where you filter with is
the evidence for predict / recommend / relate, with no training step
and an explanation ($why) behind every result. That framing sets what the
benchmarks should ā and shouldn't ā measure.
- Prediction quality is the point. Against tuned gradient-boosting and AutoML pipelines (Random Forest, LightGBM, FLAML) and against an LLM+RAG setup, Aito is competitive and often better at scale on the hard, high-cardinality, cross-table targets ā the ones a bag-of-features model struggles with. And it gets there with zero training time and full explainability. That's the differentiator; that's what these suites measure first.
- Raw query speed is not our competition area ā and that's fine. For plain indexed search and filtering, a specialized engine (Elasticsearch, a native C++ columnar store) will be faster, and we don't try to beat them at their own game. Aito's bar on that axis is "not too slow": fast enough to serve interactive queries while carrying the prediction layer those engines don't have. The Performance page states this plainly, with numbers.
The trade you're evaluating is: a single system that predicts, recommends, relates and searches over your live data with no model-training pipeline ā versus stitching a search engine to a separately-trained, separately-served ML stack. These benchmarks are here to show that trade is a good one on quality, and acceptable on speed.
Accuracy suites
Each suite is a real task with a held-out test set and published baselines, run as a server-side booktest so the numbers are reproducible. We're starting with a focused set and will extend it with more common ML benchmarks over time.
- Automated GL coding / invoice routing ā predict processor, acceptor and GL code from invoice text with both the v1 and v2 engines, vs Random Forest / LightGBM / FLAML AutoML. The headline: Aito wins on GL code and the hard cross-table processor target with 0 s training (and v2's link priors rank the true candidate far higher than v1).
- Intent classification (Banking77) ā 77-way fine-grained intent on 13k banking queries. ~79% top-1 with zero training, shown in honest context against fine-tuned transformer sentence-encoders.
- Text classification (Reuters, BBC News) ā coming soon.
- Retrieval / RAG (BEIR SciFact) ā coming soon ā where Aito's inverted index feeds retrieval-augmented generation.
Performance
- Write & query performance ā ingest throughput, query latency, and how they scale ā with an honest read on how Aito compares to a specialized search engine, and where the prediction latency lands.
How the numbers are produced
Every figure comes from a run, not a slide. Accuracy suites are booktests over
fixed test sets; performance figures come from the InvoicePerf /
FlatInvoicePerf harnesses. Some numbers on these pages are currently
hand-transcribed from those runs and marked for generation at
documentation-build time so they update themselves and can't drift ā the
mechanism that reads a run's metrics.json and interpolates it into these
pages is being wired in.
Note: Benchmarks are beta. Synthetic-data suites use a single random seed; test sets are small (nā200 for invoice routing), so treat specific numbers as point estimates with real uncertainty (±~7pp at n=200) and read the direction ā which method scales, which stalls ā as the durable signal.