Ich hatte schon länger über dieses Feature nachgedacht, weil wir die meisten Bausteine bereits hatten: Pipelines, eine Query Engine, Scheduling, Run History und einen AI Assistant, der Daten untersuchen kann. Aus diesen Bausteinen wollte ich einen täglichen Check bauen, der mir sagt, ob die Daten noch stimmen.
AI Automations sind zeitgesteuerte oder manuell gestartete Checks in Beetl. Man beschreibt in eigenen Worten, was Beetl abchecken soll. Beetl untersucht daraufhin die aktuellen Daten mit read-only SQL und meldet Healthy, Needs attention oder Failed.
Natürlich geht das bereits deterministisch. Man schreibt eine Query, erwartet, dass sie keine Zeilen zurückgibt, und löst einen Alert aus, sobald sie das doch tut. Für eine klar definierte Invariante ist das oft genau richtig.
Ein deterministischer Check deckt nur die Bedingungen ab, die in seiner Query stehen. Sobald Ausnahmen oder neue Werte aus den Quellsystemen auftauchen, muss die Query angepasst werden. Sonst werden ihre Ergebnisse zunehmend unbrauchbar.
Ich wollte einen Check, der selbstständiger arbeitet und die nächsten Untersuchungsschritte selbst wählen kann. Ich wollte nur das gewünschte Ergebnis beschreiben. Das System sollte sich anschließend das Schema ansehen, Datenstichproben ziehen, Queries schreiben und auffällige Ergebnisse genauer untersuchen. Alle Queries mussten read-only bleiben, und ich wollte jeden Schritt samt Ergebnis nachvollziehen können.
Aufbau der Pipeline für den Lieferantenstamm
In diesem Szenario integriert ein Fertigungskonzern ein gerade übernommenes Unternehmen. Die Zentrale nutzt SAP, das übernommene Unternehmen Dynamics 365. Beide Systeme enthalten Lieferanten und Rechnungen. Eine Zuordnungstabelle soll jede lokale Lieferanten-ID mit einer konzernweiten ID verbinden.
Dadurch entsteht ein überschaubares Stammdatenproblem. Die lokalen Datensätze müssen demselben Konzernlieferanten zugeordnet werden, auch wenn die beiden Systeme diesen Lieferanten unterschiedlich beschreiben.
Ich habe mit Lieferanten- und Rechnungsdaten aus SAP und Dynamics angefangen und eine Zuordnungstabelle zwischen lokalen Lieferanten und Konzernlieferanten ergänzt. Die Pipeline Supplier master review führt diese Quellen zusammen und markiert Lieferanten, die in den letzten 90 Tagen verwendet wurden.
Das Ergebnis enthält 242 Zeilen, obwohl die Quellsysteme nur 240 Lieferantendatensätze enthalten. Zwei Lieferanten sind jeweils zwei Konzern-IDs zugeordnet, deshalb verdoppelt der Join diese beiden Datensätze. Ich habe diesen Widerspruch absichtlich drin gelassen. Genau solche Probleme sollte die Automation finden.
Ein einfacher Check der Standortdaten
Der erste Check war bewusst einfach:
Prüfe in
supplier_master_review, ob Lieferanten, die in den letzten 90 Tagen verwendet wurden, kein Land oder keine Postleitzahl haben.
Das war alles. Ich musste weder eine Query schreiben noch einen Rule Builder konfigurieren. Ich habe beschrieben, was der Check untersuchen sollte, und festgelegt, wann er laufen sollte.
Dann habe ich den Check vor dem Speichern über „Test automation“ gestartet. Beetl untersuchte den Datensatz, führte die nötigen Queries aus und meldete Healthy.
Ich wusste schon, dass die 236 im Bericht zwei doppelte Zeilen enthielten. Beide Duplikate hatten vollständige Standortdaten. Für diesen Check waren sie egal, deshalb ließ ich die Zahl zunächst stehen.
Welche Lieferanten zählen?
Der nächste Check war breiter angelegt. Er sollte kürzlich verwendete Lieferanten finden, denen ein offizieller Firmenname, ein Land, eine Steuer-ID, Zahlungsbedingungen oder eine Einkaufskategorie fehlten. Außerdem wollte ich wissen, ob gesperrte Lieferanten weiterhin aktuelle Rechnungen hatten.
Der Check meldete 17 Lieferanten mit unvollständigen oder widersprüchlichen Stammdaten.
Der Bericht behandelte erneut jede aktive Zeile als eigenen Lieferanten. Damit kam er auf 236 statt auf die korrekten 234.
Zuerst habe ich die Anweisung ergänzt: Jeder Lieferant soll anhand von Quellsystem und Lieferanten-ID genau einmal gezählt werden. Der nächste Run kam trotzdem wieder auf 236.
Statt die Anweisung noch einmal umzuschreiben, habe ich dem nächsten Run die Query für eindeutige Lieferanten als Kontext mitgegeben.
Beetl verwendet die „Starting query“ als festen Ausgangspunkt für die weitere Analyse. Damit bleiben exakte Definitionen in SQL, während die Automation alles Weitere selbst untersucht.
Gelöst! Der nächste Run meldete 234 aktive Lieferanten und dieselben 17 Ausnahmen. Dafür brauchte er nur noch fünf sichtbare Untersuchungsschritte statt zehn.
Lieferantenidentitäten über mehrere Runs vergleichen
Mit dem dritten Check wollte ich feststellen, ob Lieferanten über SAP und Dynamics hinweg einheitlich identifiziert wurden. Dazu gehörten fehlende Konzernzuordnungen, mehrfach zugeordnete Lieferanten, widersprüchliche Steuer-IDs und wahrscheinliche Duplikate.
Der erste Run fand vier nicht zugeordnete Lieferanten, zwei Lieferanten mit mehreren Konzern-IDs, widersprüchliche Steuer-ID-Zuordnungen und acht Duplikatgruppen mit inkonsistenten Zuordnungen.
Der Identitäts-Check sollte auch zeigen, ob die Datenbereinigung vorankommt. Wenn „Use previous runs“ aktiviert ist, kann Beetl abgeschlossene Runs über Tool Calls abrufen. So landet nicht der gesamte Verlauf im Kontext des Modells. Die Automation entscheidet anhand der Anweisungen, welchen Run sie untersucht und welche Informationen sie abruft.
Im nächsten Run hat Beetl zunächst das vorherige Ergebnis untersucht, die aktuellen Daten erneut abgefragt und gemeldet, dass sich nichts verändert hatte.
Damit ist mein kleines Experiment abgeschlossen, und mit dem Ergebnis bin ich sehr zufrieden. Beetl hat die aktuellen Daten anhand meiner Beschreibung untersucht, jeden Schritt nachvollziehbar gemacht, exakte Definitionen aus SQL übernommen und bei späteren Runs frühere Ergebnisse einbezogen.
Natürlich sollte man für präzise Invarianten weiterhin deterministische Checks verwenden. AI Automations helfen bei den offeneren Fragen: vage Anforderungen untersuchen, mit unbekannten Daten umgehen und aus den Ergebnissen eine genauer definierte Regel ableiten. Mit klaren Grenzen und transparenten Untersuchungsschritten sind LLMs meiner Meinung nach genau hier am nützlichsten für die Datenqualität.
Als Nächstes kommen Benachrichtigungen. Automations sollen die richtigen Personen über Slack, E-Mail, WhatsApp, Microsoft Teams oder einen generischen Webhook erreichen. Außerdem prüfen wir, wie wir Automation-Zustände für Prometheus-basiertes Alerting bereitstellen können, damit sie in bestehende Monitoring- und Incident-Response-Prozesse einfließen. Mehr dazu bald.