Ahmed Maaloul · Forschung

Ein Leck mit perfekter Kalibrierung: Same-Day-Leakage in der Verspätungsprognose messen

Sun, 13 Sep 2026 00:00:00 GMT

Veröffentlichte Modelle zur Verspätungsprognose werden regelmäßig auf einer zufälligen Aufteilung evaluiert, mit historischen Merkmalen, die über den gesamten Datensatz berechnet wurden. Beides sind Lecks. Beim Bau von TransportPredictor habe ich gemessen, was das zweite wert ist, und festgestellt, dass sich sein deutlichstes Symptom hinter einer Kennzahl verbirgt, die üblicherweise als Entwarnung gelesen wird.

Aufbau, und warum es US-Flüge sind

Knapp ist in europäischen Luftfahrtdaten nicht die Menge, sondern die Zielgröße. Keine Quelle veröffentlicht tatsächliche Abflugzeiten je Flug für europäische Flughäfen zu den Bedingungen, die dieses Projekt akzeptiert: kein Konto, kein API-Schlüssel, kein Kontingent, keine Aufbewahrungsklausel. Das US-Verkehrsministerium veröffentlicht genau das, gemeinfrei, für jeden Inlandsflug.

Die Methode entsteht deshalb dort, wo die Grundwahrheit in dieser Größenordnung vorliegt. Methoden lassen sich zwischen Regionen übertragen, angepasste Modelle nicht, und nichts in diesem Text beschreibt Frankfurt oder irgendeinen europäischen Flughafen. Leakage ist eine Eigenschaft davon, wie ein Merkmal gegen eine Uhr berechnet wird, nicht eine Eigenschaft eines Landes. Genau deshalb lässt sich diese Frage auf dem Korpus beantworten, der sie beantworten kann.

5.834.764 US-Inlandsflüge ab 15 großen Drehkreuzen, Januar 2023 bis Dezember 2024. Zielgröße ist ein Abflug mit 15 Minuten Verspätung oder mehr; die Basisrate im Testzeitraum liegt bei 18,7 %. Die Prognose erfolgt zwei Stunden vor dem planmäßigen Abflug. Ein Merkmal ist also nur zulässig, wenn es zu diesem Zeitpunkt bereits beobachtbar war. Die Aufteilung ist chronologisch und überschneidungsfrei: Die letzten beiden Monate werden zurückgehalten.

Zwei Varianten desselben Merkmals

Der stärkste Einzelprädiktor ist die Verspätungsquote, die am Abflughafen im bisherigen Tagesverlauf beobachtet wurde. Dafür gibt es zwei Rechenwege:

as-of: nur Flüge, die zum Prognosezeitpunkt tatsächlich abgeflogen waren;
ganzer Tag: ein Group-by über den Kalendertag, einschließlich der Stunden, die noch gar nicht stattgefunden hatten.

Die zweite Variante ist kein Strohmann. Genau das liefert ein Group-by von Haus aus.

Kodierung	PR-AUC	Brier-Skill	Kalibrierungsfehler
as-of	0.287	+0.015	0.050
ganzer Tag	0.348	+0.072	0.00008

Das Leck ist +21,3 % PR-AUC wert und verfünffacht den Brier-Skill nahezu.

Entscheidend ist die letzte Zahl

Der erwartete Kalibrierungsfehler des undichten Merkmals beträgt 0.00008. Auf die drei Nachkommastellen gerundet, die eine Ergebnistabelle üblicherweise führt, steht dort 0.000, und in sechs der neun besetzten Zuverlässigkeitsklassen ist die Abweichung exakt null. Die as-of-Kodierung kommt auf 0.050, rund sechshundertfünfzigmal schlechter.

Ein Modell, das die Antwort gesehen hat, ist auf genau diesen Daten kalibriert, weil Vorhersage und Ergebnis innerhalb jeder Klasse dieselbe Größe sind. Kalibrierung gilt gemeinhin als Beleg dafür, dass eine Pipeline sauber ist. Hier ist sie der deutlichste verfügbare Hinweis darauf, dass sie es nicht ist.

Warum eine grobe Prüfung das übersieht

Derselbe Test auf einer streckenbezogenen Verspätungsquote verschiebt die PR-AUC von 0.219 auf 0.223, ein Zuwachs von 1,7 %. Streckenbezogene Quoten sind über Monate stabil, ein Blick in die Zukunft verbessert die Schätzung daher kaum. Wer Leakage nur an einer groben, träge veränderlichen Gruppierung prüft, kommt zu dem Schluss, seine Pipeline sei sauber.

Was hier nicht behauptet wird

Nichts davon besagt, dass das as-of-Modell gut ist. Mit 0.287 gegenüber einer Basisrate von 0.187 ist es ein moderates Signal, und mehr geben zwei Stunden Vorlauf nicht her. Die Aussage betrifft ausschließlich die Größe des Abstands zwischen beiden Kodierungen und die Frage, wo er sich versteckt.

Der Rest der Arbeit

Diese Messung stammt aus einem größeren Projekt, dessen übriger Teil als Dashboard veröffentlicht ist. Es hält dieselbe Grenze ein und benennt sie auf jeder Seite: Frankfurt und 31 weitere europäische Flughäfen sind über die veröffentlichte Tagesreihe von EUROCONTROL abgedeckt, während das Modell je Flug das oben beschriebene amerikanische ist. Das Dashboard zeigt also Frankfurts tägliche Pünktlichkeit seit 2022, diese 32 Flughäfen im Ranking vor und nach Herausrechnen des netzweiten Tageseffekts, sowie eine Model Card mit einer nummerierten Liste dessen, was das Modell nicht aussagt, beginnend damit, dass es keinen europäischen Flughafen beschreibt.

Alles dahinter sind offene Massendaten. Kein Konto, kein API-Schlüssel, kein Kontingent, und jede Zahl ist auf den Commit zurückführbar, der sie erzeugt hat.

→ Das TransportPredictor-Dashboard öffnen

Eine Containment-Metrik ohne Untergrenze: ein Audit des Retrieval-Scorings in GraphRAG

Thu, 10 Sep 2026 00:00:00 GMT

Retrieval-augmentierte Systeme auf Basis von Wissensgraphen werden häufig mit einer Containment-Regel evaluiert: Eine Gold-Passage gilt als gefunden, sobald der Kontext die Oberflächenform einer daraus extrahierten Entität enthält. Beim Bau von Synapse bin ich auf eine Eigenschaft dieser Regel gestoßen, die niemand in einer Metrik haben will: sie hat keine Untergrenze.

Das Null-Kontroll-Ergebnis

Am saubersten zeigt das ein Retriever, der seine Aufgabe unmöglich erfüllen kann. Auf einem internen Multi-Hop-Benchmark mit 14 Fragen habe ich einen Null-Retriever bewertet, der nichts als das alphabetische Entitätsvokabular des Graphen zurückgibt. Keine Beschreibungen, keine Kanten, keine Prosa, und keine Möglichkeit, irgendeine Frage zu beantworten.

Unter Containment-Scoring erreicht er 100 % Fakten-Recall. Unter einer prosa-basierten Regel, die einen Fakt nur anrechnet, wenn der Kontext tatsächliche Evidenz dafür enthält, erreicht derselbe Retriever 0 %.

Es repliziert, und es ist nicht der Bug eines einzelnen Systems

Derselbe Mechanismus zeigt sich auf HotpotQA (n = 50). Dessen Both-gold-Regel rechnet eine Frage nur dann an, wenn beide zugehörigen Gold-Absätze gefunden wurden; ein Graph-only-Retriever erreicht darauf unter Containment 100 % und 0 % unter Prosa-Grounding, wobei 93 % seiner angerechneten Treffer aus Entitätsnamen-Blöcken stammen statt aus abgerufener Evidenz.

Um eine Implementierungs-Eigenheit auszuschließen, habe ich dieselbe Null-Kontrolle gegen ein zweites, unabhängig entwickeltes GraphRAG-System laufen lassen, LightRAG. Gleiches Bild: Ein Retriever ohne jede Evidenz erreicht 100 % unter Containment und 0 % unter Prosa-Grounding. Die Inflation ist eine Eigenschaft der Metrik, nicht einer Codebasis.

Was ehrliches Scoring übrig lässt

Unter prosa-basiertem Scoring ist der Vorteil des Wissensgraphen real, aber budgetneutral: Eine einfache Passagen-Baseline erreicht dasselbe Ergebnis und liest dabei 45 % des Kontexts. Das ist eine bescheidenere Aussage, als die meisten GraphRAG-Evaluationen treffen, und ich halte sie für die zutreffende in Setups wie diesem.

Der Fix

Das Paper schlägt Channel-Gated-Scoring vor: Eine Entität wird nur angerechnet, wenn sie über einen Kanal ankommt, der Evidenz tragen kann. Das kostet prosa-tragende Systeme nichts und beseitigt den freien Boden vollständig. Das Null-Kontroll-Protokoll ist mit dem Code veröffentlicht, sodass sich dasselbe Audit gegen jede eigene Retrieval-Eval fahren lässt, bevor man ihren Zahlen vertraut.

Wer ein GraphRAG-System mit Recall-artigen Metriken evaluiert, hat mit einer Null-Kontrolle den günstigsten Sanity-Check überhaupt: Wenn ein Retriever, der nur Entitätsnamen zurückgibt, punkten kann, misst die Metrik Vokabular, nicht Retrieval.

GraphRAG-Retrieval in Synapse messen

Thu, 10 Sep 2026 00:00:00 GMT

Die meisten RAG-Projekte werden ausgeliefert, ohne Retrieval überhaupt zu messen. Synapse bringt ein kleines Harness mit, backend/eval/, das aus „fühlt sich grounded an“ Zahlen macht, die sich über Änderungen hinweg verfolgen lassen. Diese Notiz dokumentiert, was gemessen wird und wie die Ergebnisse zu lesen sind.

Aufbau

Das Harness seedet einen Fixture-Graphen nach Neo4j (15 Entitäten, 10 Relationen), führt für jede Anfrage den Produktions-Retrieval-Pfad aus (retrieve_subgraph) und bewertet die zurückgegebenen Entitäten. Embeddings werden lokal mit fastembed berechnet, das Ganze läuft also offline:

docker compose up -d neo4j
make eval        # schreibt backend/eval/results.md

Die 8 Anfragen sind bewusst so paraphrasiert, dass sie keinerlei lexikalische Überlappung mit den Entitätsnamen haben. „Welche Technologie speichert Daten als verbundene Knoten und Kanten?“ muss Neo4j über Embedding-Ähnlichkeit erreichen; eine Stichwortsuche würde den Großteil des Sets verfehlen. Genau diese Eigenschaft wird getestet: Hybrides Retrieval (Vektor- und Volltext-Seeds, dann 1-Hop-Graph-Expansion) soll Paraphrase überleben.

Ergebnisse

Metrik	Wert
Hit@1	88 %
Recall@8	100 %
Precision@8	17 %
MRR	0.917

Hit@1 und MRR sind das Qualitätssignal: Bei 7 von 8 Anfragen ist die top-platzierte Entität eine korrekte, und jede Anfrage hat alle erwarteten Entitäten irgendwo in den Top 8. MRR ist der mittlere reziproke Rang, also der Durchschnitt von eins geteilt durch die Position der ersten korrekten Entität; 0.917 heißt, dass der erste Treffer fast immer ganz oben steht.

Precision@8 wirkt alarmierend, bis man sieht, dass sie konstruktionsbedingt niedrig ist. Die meisten Anfragen haben nur ein oder zwei relevante Entitäten, und der Retriever gibt 8 Kandidaten zurück, weil die UI eine Nachbarschaft hervorhebt, nicht einen einzelnen Knoten. Weniger Kandidaten zurückzugeben würde die Precision erhöhen und das Produkt verschlechtern.

Was hier nicht behauptet wird

Das ist eine Eval in Fixture-Größe: 8 Anfragen über einen Graphen mit 15 Entitäten. Sie fängt Regressionen im Retrieval-Pfad und validiert, dass Paraphrase den Weg durch die Embeddings übersteht, und genau das brauche ich von der CI. Über Retrieval-Qualität auf großen Graphen, verrauschten Extraktionen oder adversarialen Anfragen sagt sie nichts.

Sie erbt außerdem eine subtilere Schwäche des Entity-Level-Scorings selbst, aus der eine eigene Untersuchung wurde: Eine Scoring-Regel, die Entitätsnamen anrechnet, lässt sich von einem Retriever austricksen, der nichts anderes zurückgibt. Dieses Ergebnis, ein Null-Kontroll-Audit des Containment-Scorings mit Replikation auf HotpotQA und LightRAG, ist separat aufgeschrieben in dem Paper.