Die Regeln erscheinen vor
den Zahlen.
Telys ist 0.1.0b4 — dies sind prototyp-validierte Werte auf einem offengelegten System, keine Produktionszahlen. Ein Ergebnis zählt nur, wenn es unter gleicher Recall-Rate auf gleicher Hardware gemessen wurde, mit Rohdaten und dem Skript, das sie erzeugt hat. Die nachstehenden Regeln binden jede Zahl: was wir messen, gegen wen, und die Bereiche, in denen wir verlieren müssen.
Regeln, die das Harness durchsetzt — keine nachträglichen Vorbehalte.
Jede der folgenden Regeln ist als maschinelle Prüfung im Benchmark-Harness kodiert. Ein Durchlauf, der dagegen verstößt, wird nicht mit einer Fußnote versehen — er wird als ungültig markiert und aus jeder Auswertung ausgeschlossen.
“Jeder Multiplikator ist eine Hypothese, bis er unter gleicher Recall-Rate und gleicher Hardware gemessen wurde — mit Rohdaten und einem veröffentlichten Reproduktionsskript.”
Telys Benchmark-DoktrinEin Benchmark, den wir nicht verlieren können, ist wertlos
Der generierte Scorecard enthält einen obligatorischen Abschnitt „Wo wir verlieren", der automatisch aus allen Zellen befüllt wird, in denen ein Vergleichssystem gewinnt. Ist dieser Abschnitt leer, schlägt der Report-Build fehl — ein vollständiger Sweep gilt als defektes Harness, nicht als Triumph.
Embedded vs. Embedded ist der faire Vergleich
Wir stellen nie einen In-Process-Aufruf einem Konkurrenten gegenüber, der über TCP antwortet. Bei eingebetteten Bibliotheken ist In-Process vs. In-Process der ehrliche Transport. Bei Servern wird der Transport wie für wie abgeglichen — oder die Zahl wird annotiert und nicht als Schlagzeile verwendet.
Gleiche Stufen oder kein Vergleich
Ein In-Memory-Durchlauf wird nie gegen einen Konkurrenten gewertet, der jeden Commit fsynct. Jedes Ergebnis deklariert seine Persistenzstufe — in_mem, wal_async oder wal_fsync — und das Harness bricht jeden stufenübergreifenden Vergleich hart ab.
Wir behaupten nie, FAISS zu schlagen, wenn wir FAISS aufrufen
FAISS ist der ANN-Kern, den Telys einbettet — ein Fundament, kein Gegner. Jeder Vektor-Scorecard zeigt zuerst die rohe FAISS-Traversierungszelle; wo es ein Gleichstand ist, wird der Gleichstand ausgewiesen. Ehrliche Vorteile werden anderswo geltend gemacht: Rerank-Kernel, gefiltertes Planning und die Engine um den Index herum.
Jedes Vergleichssystem isoliert eine Aussage.
Eine einzelne Leaderboard-Zahl vermischt Algorithmus, Transport, Persistenz und Speicherformat. Die Auswahl ist so getroffen, dass jeder Vergleich genau eine Variable isoliert — mit einer Same-Node-Kontrolle unter jeder Schlagzeile.
| System | Typ | Was der Vergleich isoliert |
|---|---|---|
| FAISS (gleicher Node) | Kontroll-Baseline | Der Boden, kein Gegner. Telys bettet FAISS ein, daher ist die rohe FAISS-Zahl die Baseline, die wir sind; das veröffentlichte Delta ist das, was die Engine drum herum hinzufügt — bei gleichem Index-String und gleicher gemessener Recall-Rate. |
| Postgres + pgvector | Relational + Vektor | Die gefilterte Hybrid-Abfrage: ob das Einbetten eines skalaren Prädikats in den Kandidatenpfad einen Index schlägt, der über-fetchen oder nachfiltern muss — bei gleicher Recall-Rate über verschiedene Filter-Selektivitäten. |
| LanceDB / Chroma | Eingebettete Bibliothek | Die nächsten Konkurrenten, In-Process vs. In-Process — der einzige Ort, an dem eine In-Process-Zahl als faire Schlagzeile gilt. Gleicher ANN-Boden; der Vergleich isoliert die Engine drum herum: einheitlicher Row-ID-Raum, Cold-Open, Footprint. |
| Qdrant / Milvus | Server | Algorithmusqualität — Recall bei festem k — getrennt von Netzwerk-Roundtrips. Latenz wird mit annotiertem Server-Hop ausgewiesen und nie einem In-Process-Aufruf als Schlagzeile gegenübergestellt. |
| Pinecone | Managed Service | Recall bei festem k und Durchsatz pro Recheneinheit. Rohe Latenz gegenüber einer eingebetteten Engine wird nicht als Hauptaussage geführt; stattdessen trägt die Same-Node-Kontrolle den Qualitätsanspruch. |
| DuckDB / ClickHouse | Analyseengine | Scan und Aggregation über dieselbe physische Parquet-Datei, sodass der Speicherformat-Vorteil vom Engine-Vorteil getrennt wird. Vektorisierte Analytical Engines sind hier stark; ihre Siege werden veröffentlicht. |
Was gemessen wird.
Die Matrix definiert Messungen, keine hypothetischen Siege. Jede Latenz-Zelle gibt die vollständige Verteilung aus — nie nur den Mittelwert — unter Open-Loop-Angebotslast. Jede Speed-Zelle ist an ein Recall-Gate gebunden, das der Harness gegen mitgelieferte Ground Truth berechnet; eine Zelle, deren Gate nicht erfüllt ist, wird als ungültig ausgegeben und kann nicht in eine Scorecard eingehen.
| Workload | Setup | Was gemessen wird |
|---|---|---|
| cold-open | Page-Cache geleert, frischer Prozessstart | Zeit vom Prozessstart bis zur ersten erfolgreichen Abfrage — Segment-mmap und Index-Sidecar-Mapping gegen Server-Boot und Recovery. Separat vom Steady State gemessen, nie darin eingerechnet. |
| exact FLAT | Brute-Force-Exaktsuche, f32 und int8 | Der Distance-Kernel-Floor bei konstruktionsbedingt Recall 1,0, gegen die Same-Node-Exakt-Baseline auf denselben Puffern. Jede int8-Zelle gibt ihr Recall-Delta gegenüber f32 aus, sodass Quantisierungsverlust nie verborgen bleibt. |
| gefiltertes Hybrid | Skalares Prädikat + top-k, über drei Selektivitäten variiert | Latenz bei gleichem Recall, während der Filter enger wird, plus die vom Planer gewählte Strategie pro Zelle — Pre-Filter dann Exact, Pre-Filter dann IVF oder Search dann Post-Filter — sodass die adaptive Entscheidung nachvollziehbar ist. |
| full scan | Vollständiger Spalten-Scan und Aggregation | Roher Spalten-Durchsatz über gemeinsam genutztem Parquet, Engine gegen Engine auf identischen Bytes. |
| selektiver Scan | Prädikat-Scan bei niedrigen Trefferquoten | Ob Footer-Min-Max- und Zone-Map-Pruning tatsächlich Arbeit überspringen — ausgewiesen als gelesene Bytes und berührte Zeilen, nicht nur als Wanduhrzeit. |
python -m bench.orchestrator.run \
--suite vector --rig m-laptop
# one command: pinned comparators, content-addressed
# datasets, warmup, steady-state measurement
# reviewer mode: the same run with Telys excluded# every run emits a machine-checked ResultEnvelope; # a run that cannot fill every field is invalid index_string = "IVF4096,PQ16" # same for Telys and the FAISS control omp_num_threads = 8 # FAISS threading pinned, disclosed transport = "in_process" # headlined only vs in-process durability_tier = "wal_fsync" # cross-tier comparison hard-fails recall_at_k = 1.000 # harness-measured, never self-reported samples_path = "bench/results/filtered_impact.txt"
Läufe werden mindestens fünfmal über frische Prozessstarts wiederholt, auf fest zugewiesenen Hardware-Profilen, ein System nach dem anderen. Datensätze sind inhaltsadressiert; Query-Sets sind eingefrorene Dateien, nicht zur Laufzeit generiert. Die Harness-Spezifikation wird heute festgeschrieben; der Harness wird zusammen mit den Ergebnissen veröffentlicht.
Gemessen, konditioniert, reproduzierbar.
Jede Zeile ist ein echter Lauf auf dem oben genannten System, am daneben angegebenen Recall-Gate. Die Gewinnsurface ist das physische Layout: Auf einem identischen zusammenhängenden Subset erzielt unser Mojo-Scan dasselbe Ergebnis wie rohes FAISS — das Delta unten ist der Gewinn des key-partitionierten Layouts, kein schnellerer Distanz-Kernel. Dies sind Prototyp-Werte; sie werden unter dem vollständigen Fairness-Vertrag erneut ausgeführt, während der Harness reift.
| Workload | Setup + Recall-Gate | Gemessenes Ergebnis (M4 Max, Single-Thread, In-Process) |
|---|---|---|
| Gefilterter Slice · 0,1 % Sel. | N=1.000.000 D=128 K=10, warm, Recall 1,000 (exakt) | Partition-Slice p50 0,013 ms — Layout-Gewinn vs. Full-Scan ~373×, vs. Scatter-Gather ~19×. FAISS Flat auf identischem Subset: 0,040 ms (Unentschieden — belegt, dass der Gewinn im Layout liegt, nicht im Kernel). |
| Gefilterter Slice · 0,4 % Sel. | N=1.000.000 D=128 K=10, warm, Recall 1,000 (exakt) | p50 0,032 ms — ~128× vs. Full-Scan, ~10,8× vs. Scatter-Gather. FAISS-Flat-Kontrolle 0,035 ms (Unentschieden). |
| Gefilterter Slice · 1,6 % Sel. | N=1.000.000 D=128 K=10, warm, Recall 1,000 (exakt) | p50 0,112 ms — ~42× vs. Full-Scan, ~10,3× vs. Scatter-Gather. FAISS-Flat-Kontrolle 0,120 ms (Unentschieden). |
| Giant-Partition-Rettung | 247k Zeilen in N=400.000 D=128, nprobe kalibriert, Recall 0,9915 (Floor 0,98) | IVF-within-Partition stellt den Layout-Gewinn wieder her, wo ein exakter Slice degradiert: exakter Slice 1,71 ms → IVF 0,033 ms. Ohne IVF hält eine einzelne Giant-Partition nur ~4–5×. |
| Gesteuertes Auto-nprobe | N=1.000.000 D=128 Q=500 nlist=1000, Recall gehalten 0,998 (Floor 0,98) | FIND 0,28–0,31 ms bei Basis-nprobe=32 → 0,081–0,088 ms bei gesteuertem Auto-nprobe=8. Recall bleibt über dem Floor — kein stiller Recall-für-Geschwindigkeit-Tausch. |
| FIND vs. FAISS-Kontrolle | Iso-Recall, gleicher Transport, beide In-Process, N=1.000.000 D=128 | Telys 0,073–0,074 ms @0,998 vs. rohes FAISS 0,080 ms @0,999 — gleichauf bis leicht vorn. Skalierungsabhängig: zurück (0,74×) bei N=200k, bis zu ~1,6× nur bei großem speichergebundenem N. FAISS-Qualität, Mojo-beschleunigt. |
| GIL-freie Nebenläufigkeit | N=200.000 D=128, 12 Perf-Kerne, In-Process Mojo-IVF-Kernel | FIND-Durchsatz skaliert ×6,9 über 8 Threads (15.128 → 104.756 qps). Durchsatz-Skalierung, nicht Query-Latenz; kein Vergleich mit Server-Engines. |
| Insert-to-Recall-Frische | Basis N=100.000, M=300 Inserts, D=128, In-Process | Ein soeben eingefügter Vektor ist Top-1 bei der unmittelbar nächsten Abfrage: recall@1-of-new = 1,000. Insert p50 0,3 µs. Korrektheitsprüfung, kein Durchsatz-Headline. |
Jede Zelle oben lässt sich auf ein benanntes Skript und eine gespeicherte Rohausgabe in bench/results/ zurückführen (filtered_impact.txt, partitioned.txt, partition_acceptance.txt, opt.txt, telys.txt, concurrency.txt, freshness.txt). Der Persistence-Reopen-Wert wird zurückgehalten, bis ein neu gemessenes Rohsample vorliegt. Jeder Multiplikator ist eine Hypothese außerhalb der in jeder Zeile angegebenen Bedingungen.
Für Code gebaut — und an einem Code-Benchmark gemessen.
Telys ruft Code ab, daher ist der Qualitätsmaßstab CoIR, keine Allgemeintext-Suite. LexicalCodeIndex wird als mteb SearchProtocol eingebunden und von mteb.evaluate auf demselben Pfad wie die bm25s-Baselines bewertet — keine Methodiklücke, kein Self-Scoring. Baselines sind reproduzierbare Läufe vom 2026-07-21, nicht die veröffentlichten CoIR-Paper-Werte (mehrere davon lassen sich nicht reproduzieren). Metrik: nDCG@10.
| CoIR-Aufgabe | multigram | bm25-ref | bm25-code | Code-Lexikal · ausgeliefert | vs. beste Baseline |
|---|---|---|---|---|---|
| CodeTransOceanContest | 0.160 | 0.478 | 0.600 | 0.718 | ✅ |
| CodeTransOceanDL | 0.340 | 0.344 | 0.351 | 0.366 | ✅ |
| CosQA | 0.048 | 0.188 | 0.213 | 0.218 | ✅ |
| SyntheticText2SQL | 0.265 | 0.249 | 0.372 | 0.441 | ✅ |
| CodeFeedbackMT | 0.288 | 0.592 | 0.591 | 0.674 | ✅ |
| CodeFeedbackST | 0.162 | 0.682 | 0.682 | 0.722 | ✅ |
| StackOverflowQA | 0.223 | 0.703 | 0.687 | 0.733 | ✅ |
| AppsRetrieval | 0.001 | 0.048 | 0.014 | 0.034 | ❌ |
| Durchschnitt | 0.186 | 0.445 † | 0.488 | 7/8 | |
Sieben von acht Siegen; Durchschnitt 0.488 vs. 0.445 für die stärkere Baseline je Aufgabe († bestes aus bm25-ref / bm25-code, je Aufgabe) — und 2,6× den Multigram-Durchschnitt. Die einzige Niederlage, AppsRetrieval, liegt für jede lexikalische Methode nahe null: Lange Aufgabenstellungen gegen Code ist Embedding-Territorium.
Code-Token + BM25
Bezeichner werden so aufgeteilt, wie Code geschrieben ist — camelCase, snake_case, Punkt-Pfade — und fließen in einfaches IDF/BM25 ein. Das allein gewinnt die meisten Aufgaben: CodeTransOceanContest steigt von 0.478 auf 0.600, noch ohne jede Abstimmung.
Stopwörter raus, leichtes Stemming
Englische Stopwörter entfernt und ein leichter Suffix-Stemmer, damit natürlichsprachliche Anfragen mit Code-Token übereinstimmen — der Hebel, der SyntheticText2SQL von einer Niederlage auf 0.441 dreht.
k1 = 1,8 · b = 1,0
Die ausgelieferten Standardwerte, Algenta-abgestimmt auf CoIR: stärkere Termfrequenz-Sättigung und volle Längennormalisierung — der Hebel, der StackOverflowQA dreht.
Jede Zelle reproduziert aus einem einzigen Skript — bench/mteb_code_lexical.py — das beide Seiten durch denselben mteb.evaluate-Aufruf führt (Läufe vom 2026-07-21). code-lexical ist der Index, den Telys ausliefert, mit seinen ausgelieferten Standardwerten.
Siege, Unentschieden und Niederlagen — schriftlich fixiert.
Das Veröffentlichungsformat steht fest, bevor die erste Zahl existiert — die Zahlen können es nicht verbiegen.
Wo wir verlieren — schwarz auf weiß
Jede Scorecard enthält einen Abschnitt „Wo wir verlieren" und einen Abschnitt „Wo wir nur mit FAISS gleichziehen", beide automatisch aus den Zellen befüllt. Der Report schlägt fehl, wenn einer davon leer ist.
Das Feld ohne uns reproduzieren
Der Harness läuft mit ausgeschlossenem Telys, sodass ein Skeptiker die Komparator- und Kontrollzahlen allein reproduzieren und bestätigen kann, dass jeder Mitbewerber nach seiner eigenen Anleitung konfiguriert wurde — Configs committed und gegen Vendor-Defaults gedifft.
Jede Zelle ist auf Samples zurückverfolgbar
Jede veröffentlichte Zelle verlinkt ihre rohen Per-Operation-Samples und das exakte Skript, das sie erzeugt hat. Ergebnisse sind append-only, verschlüsselt mit der Engine-Revision und den statisch verlinkten Abhängigkeitsversionen.
Dies sind Prototyp-Zahlen, jede mit ihren Bedingungen. Halten Sie uns an diesen Vertrag — und an die Zahlen, während wir sie unter dem vollständigen Harness erneut ausführen.