Recruit Holdings bringt seinem Text-to-SQL-Agenten bei, den verborgenen Kontext einer Website zu lesen
Recruit Holdings, die in Tokio ansässige Muttergesellschaft von Indeed, hat einen Text-to-SQL-Agenten repariert, der Eventnamen immer wieder falsch deutete: Der fehlende Kontext wurde in einer geprüften YAML-Datei festgehalten. Junya Morita aus der Datenmanagement-Gruppe des Unternehmens stellte den Ansatz beim dbt Summit 2026 vor, wie aus einem Blogbeitrag von dbt Labs hervorgeht.
- Recruit Holdings, die Muttergesellschaft von Indeed, entwickelte für seinen Automobil-Marktplatz Car Sensor den Slack-basierten Analyse-Agenten Goro.
- Der Agent lieferte bei UX-Fragen falsche Antworten, weil das Event-Log nahezu identische Eventnamen enthielt.
- Das Team erfasste Nutzeraktionen, UI-Elemente und Log-Einträge in einer prüfbaren YAML-Datei namens „Web Domain Context“.
- Die Datei muss vor dem Release von Features geschrieben und geprüft werden, Frontend-Logging-Code und QA-Tests entstehen auf ihrer Basis.
- Als Nächstes testet das Team, die Absicht hinter User Journeys in die Datei zu schreiben, damit der Agent Abbrüche erkennen kann.
Das Problem: richtige Daten, falsche Antworten
Recruit Holdings betreibt in Japan Vermittlungsplattformen für Jobs, Wohnen, Autos, Beauty und Hochzeiten. Moritas Team arbeitet am Automobil-Marktplatz, einem Fahrzeugportal namens Car Sensor, das dbt Labs mit CarGurus in den USA vergleicht.
Das Team hatte einen Slack-basierten Analyse-Agenten entwickelt, intern Goro genannt. Produktmanager und Analysten können ihm Fragen in natürlicher Sprache stellen und erhalten SQL, Ergebnisse und Erkenntnisse, ohne auf ein Datenteam warten zu müssen. Der Agent hatte Zugriff auf Tabellendefinitionen, Golden Queries und mit dbt erzeugte dimensionale Modelle sowie auf eine Semantic Layer für gängige Kennzahlen.
Einfache Fragen beantwortete dieses Setup problemlos. Bei UX-spezifischen Fragen scheiterte es, etwa danach, wie viele Nutzer auf einen Button „Reservierung vornehmen“ getippt haben. Im Event-Log fand sich eine Gruppe nahezu identischer Eventnamen (tap reserve, tap reserve icon, show render, complete reservation), die laut dem Beitrag kein Modell allein anhand der Daten zuverlässig auseinanderhalten konnte.
Ein problemgetriebener Fix statt einer allgemeinen Ontologie
Moritas Team erwog, eine allgemeine System-Ontologie aufzubauen, um solches implizites Wissen zu erfassen. Die Idee wurde verworfen, weil es dafür keine konkreten, belegbaren Beispiele aus dem Produktivbetrieb gab.
Stattdessen entschied sich das Team für einen, wie Morita es nannte, problemgetriebenen Ansatz: einen konkreten Fehlerfall herausgreifen, den genauen verborgenen Kontext zu seiner Lösung bestimmen und ihn in eine YAML-Datei schreiben, statt ihn undokumentiert in den Köpfen der Beteiligten zu belassen.
Das Ergebnis ist ein Schema namens „Web Domain Context“. Es beschreibt Nutzeraktionen wie Seitenaufrufe, Klicks, Checkouts und Conversions, die UI-Elemente, auf die sich diese Aktionen beziehen, sowie die dabei erzeugten Log-Einträge. Alles steckt in einer einzigen, prüfbaren Datei, die der Analyse-Agent zusätzlich zum dbt-generierten Schema abfragen kann.
Wie der Kontext aktuell bleibt
Der Kontext veraltete immer wieder. Das Automobil-Team von Recruit führt monatlich dutzende A/B-Tests durch, die Oberfläche ändert sich also ständig. Außerdem können zwei Produktteams unbeabsichtigt widersprüchliche Bedeutungen für dasselbe Event festlegen, ohne dass ein Versionskontrollwerkzeug dies bemerkt.
Moritas Antwort war ebenso prozessual wie technisch:
- Die YAML-Datei zum Log-Design muss geschrieben und geprüft sein, bevor ein zugehöriges Feature live geht.
- Der Frontend-Logging-Code wird aus dieser Datei generiert statt von Hand geschrieben.
- QA-Testfälle werden gegen dieselbe Datei erstellt, sodass Abweichungen zwischen Design und Implementierung vor dem Release auffallen.
In einem Live-Beispiel wurde der Agent nach der Zahl der eindeutigen Nutzer auf einem Nischenbildschirm zum „Restwertkredit“ gefragt. Ohne die Domain-Context-Datei lässt sich ein solcher Abfragename nicht verlässlich einer Event-ID zuordnen. Mit ihr durchsuchte der Agent die Log-Design-Tabelle, ordnete den String dem richtigen Event zu und lieferte die korrekte Zahl.
Wie es weitergeht
Moritas Team experimentiert nun damit, nicht nur Implementierung und Design, sondern auch die Absicht hinter User Journeys in eine ähnlich strukturierte Datei zu schreiben. Ziel ist, dass der Agent künftig beurteilen kann, ob eine Abfolge von Aktionen einem Abbruch gleicht, statt nur Events zu zählen.
Für Teams, die Text-to-SQL-Agenten bauen, ergibt sich laut Quelle eine praktische Lehre: Zugriff auf die richtigen Tabellen reicht nicht, wenn die Bedeutung von Eventnamen nur in den Köpfen der Mitarbeitenden existiert. Diese Bedeutung in einer versionierten Datei festzuhalten und an die Erzeugung von Logging-Code und Tests zu koppeln, hat bei Recruit die Antworten des Agenten präzise gehalten. dbt Labs zufolge sind alle Keynotes und Breakout-Sessions des dbt Summit 2026 auf Abruf verfügbar.
