Das Metrik-Problem
Ein symmetrischer Score belohnt die Memory, die auf alles antwortet — auch auf Fragen, die ihr Store nicht stützen kann. VeriBench bewertet Memory so, wie ein Deployment dafür bezahlt: NET(λ) = (richtig − λ·falsch) / n, wobei λ die deklarierten Kosten einer Falschantwort relativ zum Schweigen sind. Recht und Medizin fahren mit hohem λ; Brainstorming mit niedrigem. Eine Zahl, gesweept über λ ∈ {1, 2, 5, 10} — festgelegt vor jedem Lauf.
✓ Kein LLM-Richter, kein Netzwerk, kein Leaderboard-Theater — ein Befehl, rohe JSONs im Repo commitet.
Memory-Benchmarks messen, wie viel zurückkommt. Keines bepreist, was falsch zurückkommt.
Auf der beantwortbaren Hälfte eines Korpus rufen eine Memory mit Gate und ein roher Vector Store fast identisch ab — recall@k sieht keinen Unterschied. Der Unterschied erscheint bei den Fragen, die der Store nicht beantworten kann: eine Memory ohne Enthaltungs-Floor liefert trotzdem ihren nächsten Nachbarn, mit voller Zuversicht. In Produktion ist das eine fabrizierte Antwort; in einem symmetrischen Benchmark ist sie unsichtbar.
NET(λ) macht sie per Konstruktion sichtbar: eine richtige Antwort bringt +1, eine falsche kostet λ, Schweigen kostet nichts. Die Break-even-Genauigkeit ist λ/(1+λ) — dieselbe Schwelle, auf die Verimems SLA-Regler den Store einstellt. Das Benchmark misst den Store bei genau der Zahl, mit der der Betreiber ihn einstellt.
Hypothese, Metrik, λ-Sweep und Widerlegungsbedingungen sind vor jedem Lauf in PREREGISTRATION.md commitet. Scoring und Ergebnis-Mapping wurden zuerst geschrieben und unit-getestet — ein günstiges Ergebnis lässt sich nicht durch nachträgliche Metrikwahl fabrizieren.
Echte Datensätze, die wir nicht geschrieben haben: HaluEval QA und SQuAD v2 (beantwortbare + unbeantwortbare Splits, disjunkt). Korrektheit ist id-entscheidbares Retrieval — kein LLM-Richter irgendwo in der Schleife.
Ein verwürfelter Store muss tief negativ gehen (tut er: NET(1) = −0.94) und dasselbe Retrieval mit Floor aus muss auf Unbeantwortbarem fabrizieren (tut es: 100 Falschantworten). Besteht eine Kontrolle, ist das Benchmark kaputt — genau dafür ist sie da.
Head-to-Head-Läufe nutzen den identischen Embedder (multilingual-e5-base) auf beiden Engines, offline, mem0 im Raw-Store-Modus (sein LLM wird nie aufgerufen — diese Achse ist per Deklaration außer Scope, nicht per Auslassung).
| System | ✓ | ✗ | ∅ | coverage | NET(1) | NET(2) | NET(5) | NET(10) | negativ ab λ |
|---|---|---|---|---|---|---|---|---|---|
| Verimem · Floor τ=0.8 (Produkt-Default) | 182 | 4 | 114 | 0.62 | +0.593 | +0.580 | +0.540 | +0.473 | 45.5 |
| mem0 2.0.11 · wie ausgeliefert (ohne Floor) | 200 | 100 | 0 | 1.00 | +0.333 | 0.000 | −1.000 | −2.667 | 2.0 |
| mem0 + angeschraubter Floor 0.75 (auf der Eval getunt) | 166 | 0 | 134 | 0.55 | +0.553 | +0.553 | +0.553 | +0.553 | nie |
| Derselbe Store, Floor OFF (τ=0-Kontrolle) | 192 | 100 | 8 | 0.97 | +0.307 | −0.027 | −1.027 | −2.693 | 1.9 |
| Verwürfelte Kontrolle (Sanity: muss scheitern) | 5 | 287 | 8 | 0.97 | −0.940 | −1.897 | −4.767 | −9.550 | 0.02 |
Ehrlich gelesen, in beide Richtungen: wie ausgeliefert wird mem0 jenseits von λ=2 netto-negativ — 100 fabrizierte Antworten auf der unbeantwortbaren Hälfte; Verimems Produkt-Default bleibt bis λ≈45 positiv. Aber ein Floor lässt sich an jede Engine anschrauben: mit einer auf dieser Eval getunten Schwelle erreicht mem0 flache +0.553 — was unseren Default bei λ≥5 auf diesem Korpus schlägt. Die verbleibenden Unterschiede: die Engine liefert selbst keinen Floor, die angeschraubte Schwelle wurde auf dem Test-Set gewählt, und die flache Linie heißt, sie beantwortet nichts, dessen sie sich nicht sicher ist — coverage 0.55 gegen unsere 0.62, mit 182 gegen 166 richtigen bei λ=1.
| System | ✓ | ✗ | ∅ | coverage | NET(1) | NET(2) | NET(5) | NET(10) | negativ ab λ |
|---|---|---|---|---|---|---|---|---|---|
| Verimem · Floor τ=0.8 (Produkt-Default) | 163 | 49 | 88 | 0.71 | +0.380 | +0.217 | −0.273 | −1.090 | 3.3 |
| Verimem · bester Floor 0.85 (auf der Eval getunt) | 98 | 7 | 195 | 0.35 | +0.303 | +0.280 | +0.210 | +0.093 | 14.0 |
| mem0 2.0.11 · wie ausgeliefert (ohne Floor) | 200 | 100 | 0 | 1.00 | +0.333 | 0.000 | −1.000 | −2.667 | 2.0 |
| mem0 + angeschraubter Floor 0.80 (auf der Eval getunt) | 44 | 0 | 256 | 0.15 | +0.147 | +0.147 | +0.147 | +0.147 | nie |
SQuADs Distraktor-Passagen komprimieren das Score-Band, und man sieht es: beim Produkt-Default fällt der Crossover auf λ≈3.3, und NET bei λ=10 positiv zu halten kostet coverage 0.35. Enthaltung ist ein Regler, keine Magie — das Korpus entscheidet, wie teuer Ehrlichkeit ist. Falsch wäre, diese Tabelle zu verstecken.
Die Tabellen oben: externe Daten, beantwortbar + unbeantwortbar, Floor an vs. aus vs. Wettbewerber, verwürfelte Kontrolle. Die Achse, auf der Fabrikation zum bepreisten Ereignis wird.
Ein Store, der eine Scheinkorrelation treu bestätigt hat, beantwortet do(X)-Fragen selbstsicher falsch — und landet selbst bei λ=1 im Minus. Provenienz ist keine Kausalität; ein Benchmark, das sie nicht unterscheidet, belohnt die Verwechslung.
Kollusion (N Identitäten, ein Feed) plus ein vertrauter Sleeper. Nur eine Zwei-Kanal-Trust-Policy — unabhängige Bestätigung und Ergebnis-Feedback — bleibt netto-positiv; jeder Einzelkanal scheitert an genau einem der beiden Angriffe. Die Achse hinter Verimems Zwei-Kanal-Source-Trust.
alle Achsen, deterministisch, null API-Keys
git clone https://github.com/aureliocpr-ctrl/verimem && cd verimem
pip install -e .
python -m benchmark.veribench.run_all # every axis, one reproducible entrypointSpec, Prä-Registrierung und jedes rohe Ergebnis-JSON liegen im Repo unter benchmark/veribench/ und benchmark/results/. Wettbewerber sind eingeladen — der mem0-Adapter ist in-tree als Arbeitsbeispiel; reicht den offiziellen Adapter eurer Engine als PR ein und wir führen ihn zu gleichen Bedingungen aus.