Agentic AI für Self-Service Analytics: Lektionen aus einem BI-Projekt

Agentic AI lässt sich leicht abstrakt diskutieren. Spannend wird es erst, wenn ein System ein reales Fachproblem Ende zu Ende löst: eine natürlichsprachliche Frage verstehen, in sicheres SQL übersetzen, die Abfrage verlässlich ausführen und das Ergebnis als Tabelle, Visualisierung und geschäftlich verständliche Erklärung zurückgeben.

Genau darum ging es in einem Projekt mit dem King Mongkut's Institute of Technology Ladkrabang (KMITL). Im Agentic-AI-Modul des Management-Information-Systems-Kurses setzten mehrere Teams denselben BI-Use-Case für Global Bike Inc. (GBI) um: ein Python-basiertes System, das natürlichsprachliche Fragen in SQL übersetzt, gegen Microsoft SQL Server ausführt und anschließend Tabelle, passenden Chart und Interpretation liefert.

Die technologische Basis bestand aus Python, Google Gemini, dem Agent Development Kit (ADK), Gradio, SQL Server, GitHub und uv. Für diesen Beitrag habe ich Projektberichte und Foliensätze daraufhin ausgewertet, welche Architekturentscheidungen für Entwicklerteams wirklich relevant sind. Nicht die schönste Demo ist entscheidend, sondern was ein agentisches Analytics-System sicher, schnell und nachvollziehbar macht.

1. Was das Projekt sichtbar gemacht hat

Weil derselbe BI-Use-Case mehrfach unter ähnlichen Randbedingungen umgesetzt wurde, sind die wiederkehrenden Muster interessanter als eine einzelne Lösung. Die besseren Implementierungen hatten eine gemeinsame Grundform: kuratierter Schema-Kontext, explizite SQL-Validierung, deterministischer Code für nichtsprachliche Aufgaben, Oberflächen mit sichtbarer SQL-Abfrage und irgendeine Form von Evaluation, die über "die Demo lief einmal" hinausgeht.

Es gibt keine einzig richtige Agentenarchitektur für BI. Aber es gibt Entscheidungen, die Zuverlässigkeit, Latenz und Vertrauen konsistent verbessern.

2. Pattern 1: Text-to-SQL ist ein Systemproblem

Text-to-SQL ist zuerst ein Systemproblem und erst danach ein Prompting-Problem.

Die stärkeren Teams behandelten SQL-Generierung als ein Modul in einer größeren Architektur. Sie ergänzten explizite Validierungsschichten, ließen nur SELECT-artige Queries zu, blockierten riskante Schlüsselwörter, setzten Zeilenlimits und Timeouts und machten das Ergebnis prüfbar, indem sie die generierte SQL-Abfrage offenlegten.

Eine Multi-Agent-Pipeline mit expliziter Validierung und Retry-Loop vor der eigentlichen Ausführung.

Die robustesten Systeme kombinierten weiche Leitplanken im Prompt mit harten Regeln im Code: Blacklists, Row Caps, Query Timeouts, SELECT-only Enforcement und Validator-Schleifen, die Laufzeitfehler zurückspielen und die SQL-Abfrage gezielt korrigieren. Ein BI-Agent, der eine elegante Antwort formuliert, aber eine unsichere oder irrelevante Query ausführt, ist schlechter als gar kein Agent. Korrektheit hängt davon ab, wie konsequent das System die Aktionen des Modells begrenzt und prüfbar macht.

3. Pattern 2: Context Engineering schlägt längere Prompts

Die besseren Implementierungen schrieben nicht einfach längere Prompts. Sie verbesserten die Art, wie das System das Datenmodell und die Fachfrage versteht: vorab geladene oder komprimierte Schemainformationen, semantische Layer und abgeleitete Kennzahlen, explizite Chart-Taxonomien sowie reduzierte Mehrdeutigkeit, bevor überhaupt SQL generiert wird.

Ein optimierter Ablauf: Das Schema wird beim Start vorgeladen, Visualisierung und Erklärung laufen anschließend parallel.

Wenn ein Modell Tabellenbeziehungen, Naming Conventions, Business-Metriken oder erlaubte Query-Muster nicht versteht, hilft auch ein längerer Prompt nicht verlässlich weiter. Der größte Hebel lag in dichten Schema-Strings, annotierten Geschäftsregeln und dynamisch gefilterten Tabellenkontexten, sodass das Modell nur den relevanten Ausschnitt sieht. In einer dokumentierten Variante sparte allein das Preloading des Schemas rund 1.500 Tokens pro Anfrage.

4. Pattern 3: Hybride Architekturen schlagen oft vollagentische Pipelines

Einige der effektivsten Lösungen fügten nicht immer mehr Agenten hinzu, sondern entfernten sie dort, wo deterministischer Code schneller, günstiger und kontrollierbarer war. Schema-Caching, regelbasierte Weiterleitung, Python-basierte Nachbearbeitung und heuristische Fast Paths erwiesen sich als pragmatische Alternativen zu durchgehend agentischen Ketten.

Eine sequentielle Architektur, in der SQL-Ausführung und Formatierung bewusst in deterministischem Python-Code bleiben.

In einer optimierten Variante sanken die LLM-Aufrufe von vier auf zwei, nachdem zwei unnötige Agentenschritte durch Python ersetzt wurden. In einer anderen sank die Latenz von 32,4 Sekunden auf 10,09 Sekunden, nachdem Hybrid-Orchestrierung, heuristische Fast Paths und schlankere Prompts eingeführt wurden. Die relevante Frage lautet daher selten "Wie viele Agenten können wir bauen?", sondern eher: "Welche Teile sollten bewusst nicht vom Modell gesteuert werden?"

5. Pattern 4: Transparenz schafft Vertrauen

Nutzende brauchen mehr als eine finale Aussage. Sie brauchen Nachvollziehbarkeit. Vertrauen entstand dort, wo die Systeme die generierte SQL-Abfrage zeigten, die zugrunde liegende Tabelle offenlegten, Exportfunktionen anboten und deutlich machten, warum eine bestimmte Visualisierung ausgewählt wurde. Genau dieses Prinzip zeigt bereits das Titelbild des Beitrags: Das System verbirgt seine Arbeit nicht, sondern macht sie sichtbar.

Ein exportfähiger Intelligence Report mit Frage, SQL, Ergebnis und geschäftlicher Einordnung.

Manche Teams optimierten stärker für Management-Lesbarkeit, andere für technische Transparenz oder reichhaltigere Interaktion. Die gemeinsame Erkenntnis: Ein BI-Agent ist nur dann nützlich, wenn seine Ergebnisse verifiziert und sein Vorgehen nachvollzogen werden können.

6. Pattern 5: Evaluation bleibt die schwierigste Aufgabe

Die reiferen Teams versuchten auch, ihre Systeme ernsthaft zu messen: mit Testfällen, Benchmark-Fragen, Referenz-SQL, Judge-artiger Bewertung und expliziter Prüfung der textlichen Erklärungen.

Gerade die Unvollkommenheit dieser Ergebnisse war aufschlussreich. Ein Benchmark berichtete 75 Prozent Execution Accuracy über 40 Fragen und dokumentierte Fehler durch Schema-Mehrdeutigkeit sowie Rundungsdifferenzen. In einem anderen Optimierungspfad stieg ein teaminternes Ground-Truth-Benchmark von 2/10 auf 10/10 nach architektonischen Anpassungen. Es gab außerdem Hinweise, dass Judge-basierte Evaluation strukturiertes Review erleichtert, auch wenn sie das Grundproblem nicht vollständig löst.

Evaluation agentischer Systeme bleibt eine offene Engineering-Aufgabe. Für die Lehre ist das kein Nachteil, sondern ein Vorteil: Der Prototyp ist nur die halbe Arbeit. Die schwierigere Hälfte ist, sauber zu definieren, was "funktioniert" im Betrieb überhaupt bedeutet.

7. Was Entwicklerteams daraus ableiten sollten

Wenn ich das Projekt auf einen Satz reduzieren müsste, dann auf diesen: Agentic AI in Analytics ist vor allem ein Architekturthema. Die stärksten Lösungen funktionierten nicht wegen eines magischen Prompts, sondern weil klar entschieden wurde, was das Modell tun soll, was klassische Software besser übernimmt, welchen Kontext das Modell wirklich braucht und wie das Ergebnis präsentiert werden muss.

Sechs praktische Schlussfolgerungen:

1. Starten Sie mit einem schmalen End-to-End-Pfad und machen Sie ihn verlässlich, bevor Sie architektonisch ausbauen.
2. Halten Sie SQL-Ausführung immer hinter expliziten Validatoren, Limits und Timeouts.
3. Investieren Sie mehr in Schema-Kontext und Geschäftsregeln als in immer längere Prompts.
4. Ziehen Sie deterministische Schritte aus dem LLM-Loop heraus, sobald sie regelbasiert lösbar sind.
5. Zeigen Sie SQL, Rohdaten, Logs und Fehlzustände sichtbar in der Oberfläche, damit Debugging und Vertrauen von Anfang an mitgebaut werden.
6. Behandeln Sie Evaluation als Produktfeature: mit Benchmark-Fragen, Ground-Truth-Queries und Live-Monitoring.

Beeindruckend an dem Projekt war, wie schnell die Arbeit von der allgemeinen Faszination über "AI Agents" in echtes Engineering überging: Validierung, Architektur, Trade-offs, Observability und Nutzervertrauen. Selbst im Lehrkontext entstanden Prototypen, die bereits nah an realen Analytics-Produkten liegen.

Fazit

Self-Service Analytics mit Agentic AI ist machbar, aber nicht als reines Demo-Thema. Sobald natürliche Sprache zu SQL, Visualisierung und Management-Erklärung werden soll, entscheidet die Systemarchitektur über Qualität und Sicherheit.

Das KMITL-Projekt zeigt sehr klar, worauf es ankommt: harte Leitplanken rund um SQL, sauber kuratierter Kontext, hybride Orchestrierung statt Agenten-Overkill, transparente Oberflächen und eine Evaluationslogik, die mehr leistet als ein erfolgreicher Einzelfall. Genau dort liegt der Unterschied zwischen einer eindrucksvollen Demo und einem belastbaren analytischen System.

Mein Dank gilt den Studierendenteams für die durchdachte Arbeit sowie Asst. Prof. Kanokwan Atchariyachanvanich und KMITL für die Zusammenarbeit.