Checkr verkürzt Metrik-Analysen mit KI-Kontext von Stunden auf Minuten
Checkr hat nach eigenen Angaben eine Analyse, die früher Stunden dauerte, auf wenige Minuten verkürzt, indem das Unternehmen seinem KI-Agenten auf Basis von dbt und Omni strukturierten Geschäftskontext mitgibt. Sarah Fischbach, Staff Analytics Engineer bei Checkr, stellte den Ansatz in einer Session gemeinsam mit Chris Merrick, Mitgründer und CTO von Omni, vor, wie dbt Labs berichtet.
- Checkrs Snowflake- und dbt-Projekt umfassen mehr als 6.000 Modelle, und ein direkt angebundener KI-Agent lieferte jedes Mal eine andere falsche Antwort.
- Die Lösung war eine dritte Ebene aus KI-Kontext in Omni: Synonyme, Beispielwerte, Feldbeschreibungen, Verhaltenshinweise und Beispielabfragen.
- Ein automatisierter Loop aus Evals, Clustering von Fehlschlägen, entworfenen Korrekturen und von Experten geprüften Merge Requests hält den Kontext aktuell.
- Ein Operations-Lead sagte, Arbeit, die Stunden gedauert hätte, sei in Minuten erledigt gewesen.
- Ein Praktiker von OutSchool warnte, dass breiter, unfokussierter Kontext die Antworten verlangsamte und die Token-Kosten ungefähr verdoppelte.
Das Problem: Jedes Mal eine andere falsche Antwort
Fischbach arbeitet mit einem kleinen zentralen Analytics-Engineering-Team und rund 50 Analysten, die im gesamten Unternehmen verteilt sind. Checkrs Snowflake-Instanz und das dbt-Projekt umfassen mehr als 6.000 Modelle. Als sie einen KI-Agenten über einen MCP direkt mit Snowflake verband und dieselbe Frage mehrfach stellte, erhielt sie jedes Mal eine andere falsche Antwort. Dieses Muster nannte sie Metric Drift.
Sie veranschaulichte das am Beispiel FRT (First Reply Time), dem zentralen SLA, an dem das Operations-Team von Checkr gemessen wird. Auf die Frage „Welche Queues haben FRT unter 90 % gedrückt?“ wusste der Agent weder, was FRT bedeutet, noch was eine Queue ist oder worauf sich die 90-Prozent-Schwelle bezieht. Er sah nur Feldnamen und Tabellenstrukturen, nicht aber die dahinterliegende Geschäftslogik.
Drei Ebenen der KI-Tauglichkeit
Fischbachs Framework unterteilt die KI-Tauglichkeit in drei Ebenen:
- Das Data Warehouse: das Wörterbuch aller vorhandenen Datenpunkte.
- Die Semantic Layer: die Grammatik, die gültige Joins, Berechnungen und Metriken definiert und Metric Drift verhindert.
- KI-Kontext: die Brücke zur natürlichen Sprache, die ihrer Ansicht nach die meisten Teams komplett überspringen.
Omnis Umsetzung der dritten Ebene besteht aus fünf strukturierten Feldern: Synonyme, die Geschäftssprache auf Feldnamen abbilden, Beispielwerte, mit denen ein Agent natürliche Sprache in gültige Filter übersetzen kann, Feldbeschreibungen (oft bereits im dbt-Projekt hinterlegt), frei formulierte Verhaltenshinweise für Sonderfälle sowie vorgefertigte Beispielabfragen für komplexe, mehrstufige Fragen.
Ihr Grundprinzip: Kontext wiederverwenden, der bereits in Confluence-Seiten, Meeting-Transkripten, PRDs und Slack-Threads existiert, statt neue Dokumentation von Grund auf zu schreiben.
Ein automatisierter Feedback-Loop
Um diesen Kontext in großem Maßstab zu befüllen, hat Checkr einen automatisierten Loop gebaut. Ein Golden Set an Evals, bestehend aus echten Fragen von Stakeholdern und dem jeweils korrekten Abfrageplan, läuft gegen Omni. Ein Claude-basierter Agent clustert die Fehlschläge. Ein zweiter Skill holt relevanten Kontext aus einem Vektorspeicher mit Unternehmenswissen und entwirft eine Korrektur. Ein dritter Skill führt die fehlgeschlagenen Evals erneut aus, um zu prüfen, ob die Korrektur wirkt, und öffnet anschließend einen Merge Request, den ein Fachexperte prüft.
Es gibt auch eine einfachere manuelle Variante. Ein Team kann eine Confluence-Seite oder ein Meeting-Transkript zusammen mit dem Code des relevanten dbt-Modells in einen KI-Assistenten kopieren, Synonyme und Verhaltenshinweise extrahieren lassen, das Ergebnis prüfen und von Hand in Omni eintragen.
Das Ergebnis und eine Warnung vor zu viel Kontext
Der Nutzen zeigte sich, als Christian, einer der Operations-Leads bei Checkr, den Agenten fragte, welche Queues FRT unter 90 % gedrückt haben. Da Synonyme, kanalspezifische SLA-Ziele und Regeln für Sonderfälle bereits hinterlegt waren, identifizierte der Agent die schwache Woche und schlüsselte sie nach Queue und Kanal auf. Die Queue mit dem hohen Volumen, die alle für den Verursacher gehalten hatten, schloss er aus und verwies stattdessen auf internationale Queues. Christian sagte dazu: „Was früher Stunden gedauert hätte, war in Minuten erledigt, und zwar mit genug Orientierung, um unsere Reaktion tatsächlich zu verändern.“
Ein Data-Profi von OutSchool äußerte aus dem Publikum eine Warnung. Wer KI-Kontext breit hinzufügt, ohne einen konkreten Fehler beheben zu wollen, macht die Antworten des Agenten langsamer und verdoppelt die Token-Kosten ungefähr, ohne die Genauigkeit zu verbessern. Fischbach und Merrick empfahlen im Einklang mit Checkrs Erfahrung: die Korrektur auf den Fehler abstimmen, Felder entfernen, die niemand abfragt, und Kontext gezielt dort ergänzen, wo ein messbares Problem bei Precision oder Recall besteht, statt pauschal alle Modelle zu überarbeiten.
Was das für Datenteams bedeutet
Die Session legt nahe, dass es nicht genügt, einen Agenten an ein Warehouse anzubinden, selbst wenn eine Semantic Layer vorhanden ist. Laut dem Bericht fehlten Geschäftssprache, Schwellenwerte und Regeln für Sonderfälle, die zu großen Teilen bereits in internen Dokumenten standen. Zudem zeigt sie eine praktische Methode: jeden Baustein Kontext an einen fehlschlagenden Eval koppeln und Änderungen von einem Experten prüfen lassen, bevor sie live gehen.
