Ein größeres Modell war nicht die Antwort: was einen Analytics-Agenten wirklich trägt

Kontext

Ein datengetriebenes Unternehmen wollte wissen, ob ein Conversational-Analytics-Agent die immer gleiche Bitte aus den Fachbereichen beantworten kann: „Zeig mir die Zahlen, ohne dass ich SQL kann oder das Reporting-Team blockiere.” Vor einer großen Investition wollte der Kunde aber erst wissen: Trägt das überhaupt auf den eigenen Daten? Dafür holte er mich in einen bewusst kleinen Proof of Concept, mit einer Handvoll Fachexperten als Gutachter.

Herausforderung

Die eigentliche Frage war nie „funktioniert ein LLM?”, sondern „funktioniert es gut genug auf unseren Daten und unserer Fachsprache, um einer Antwort zu vertrauen?”.

Analytische Fragen aus dem Fachbereich sind selten sauber gestellt. Sie sind mehrdeutig, setzen Domänenwissen voraus, und mit denselben Wörtern meint die Fachseite oft etwas anderes als die Datenbank. Ein Agent, der hier eine Zahl liefert, die plausibel aussieht, aber falsch ist, ist schlimmer als gar kein Agent. Er untergräbt Vertrauen, und Vertrauen ist die ganze Währung von Self-Service-Analytics.

Dazu die Randbedingungen: keine großen Vorabinvestitionen, ein nachvollziehbares Kostenmodell pro Analyse, und ein Setup, das in Wochen zu belastbaren Ergebnissen führt, ohne monatelangen Infrastrukturaufbau.

Ansatz

Den Agenten habe ich mit DSPy rund um die OpenAI-API gebaut — bewusst ohne MCP-Server-Zoo. In DSPy genügen native Python-Funktionen, um dem Agenten Tools zu geben. Das spart eine ganze Abhängigkeitsschicht, hält den PoC leicht und verkürzt den Weg von der Idee zur getesteten Fähigkeit auf Minuten statt Tage.

Als Modell fiel die Wahl auf GPT-5-mini. Es hält die Kosten bei rund 0,07 $ pro Analyse, inklusive Tokens, gescannter Daten und Agent-Laufzeit. In einem PoC, durch den hunderte Analysen laufen, ist das der Unterschied zwischen „wir experimentieren frei” und „jeder Testlauf tut weh”.

Der Agent bekam Zugriff auf den Data Catalog und auf SQL, um die Daten selbst abzufragen. Dazu kamen drei Fähigkeiten, die ihn von einem reinen Text-zu-SQL-Übersetzer abheben:

• Rückfragen stellen, statt bei unklaren Anfragen zu raten.
• Datenaktualität bewerten, damit eine Antwort nicht stillschweigend auf veralteten Daten beruht.
• Self-Learning — der Agent kuratiert aus den Gesprächen mit den Fachexperten sein eigenes Domänenwissen.

Dahinter ein zweigeteiltes Memory: kurzfristig pro Session, langfristig als Domänenwissen. Schlank gehalten: das Langzeit-Memory ist zunächst eine YAML-Datei, die ein eigener Sub-Agent lesen und aktualisieren kann. Kein Vektor-Store, keine zusätzliche Datenbank, solange noch nicht klar ist, ob sich der Aufwand überhaupt lohnt.

Der Kern des Projekts war aber nicht der Agent, sondern seine Bewertung.

Evaluation

Auf Basis von promptfoo habe ich ein eigenes Evaluations-Framework gebaut, das den Agenten breit und schnell prüft. Nicht nur „kommt die richtige Zahl raus?”, sondern entlang dreier Dimensionen:

• Fachlich — beantwortet er reale Business-Fragen korrekt?
• Verhalten — fragt er nach, wenn er nachfragen sollte? Oder erfindet er eine Antwort?
• UX — wie entscheidet er, Daten darzustellen: als Zahl, Tabelle, Aggregat?

Damit ließ sich der Agent gegen ein großes Spektrum echter Anfragen reproduzierbar testen. Das Ergebnis war ehrlich ernüchternd — und genau deshalb wertvoll: 46 % Erfolgsquote, wenn man alle Randbedingungen mit einrechnet. Niedrig genug, um nicht in Produktion zu gehen. Präzise genug, um zu verstehen, warum.

Diagnose

Die Root-Cause-Analysis brachte die zwei Engpässe zum Vorschein: zwei Grundursachen, die sich sauber trennen lassen.

1. Die Interpretation der Anfrage. Dem Agenten fehlte Domänenwissen und ein Verständnis des gefragten Themas. Erschwerend kommt ein Modellverhalten hinzu: OpenAI-Modelle neigen dazu, dem Nutzer gefallen zu wollen. Sie beantworten eine Frage mit Nachdruck, auch wenn sie mehrdeutig ist oder unklar bleibt, ob die Antwort stimmt — das genaue Gegenteil von dem, was man bei Analytics braucht.

2. Die Interpretation der Daten. Hier zeigten sich zwei Schwächen. Erstens hatten einzelne Datenbestände kritische, andere kleinere Qualitätsmängel. Zweitens, und schwerwiegender, ist die Datenstruktur heute stärker an der operativen Sicht ausgerichtet als an der Business-Sicht. Der Agent muss die Lücke zwischen der Fachsprache der Frage und der tatsächlichen Datenstruktur also selbst überbrücken. Und das ist genau dort am schwersten, wo es am wichtigsten wäre.

Das Self-Learning funktionierte gut, bis es an eine Decke stieß. Sobald Fachexperten einer Analyse widersprachen, ohne die zugrunde liegende Datenstruktur vollständig zu verstehen, drohte der Agent, falsches „Wissen” zu lernen. Das ist kein Schönheitsfehler, sondern ein echtes Risiko: Wer den Lernprozess unkontrolliert von Nutzern steuern lässt, öffnet die Tür für Verfälschung, auch für gezielte.

Erkenntnis & Ausblick

Der wertvollste Output dieses PoC ist nicht der Agent. Es ist die Gewissheit, wo investiert werden muss und wo nicht.

Der naheliegende Reflex wäre, einfach ein größeres Modell zu nehmen. Habe ich getestet: dasselbe Setup mit GPT-5 kommt auf exakt dieselbe Erfolgsquote, bei 4- bis 5-fachen Kosten. Das Problem liegt also unterhalb des Agenten, in der Foundation aus Daten und Wissen, auf der er arbeitet. Der Hebel für gute Analytics-Agenten ist nicht das Modell, sondern die Foundation.

Dort geht es jetzt weiter. Die nächsten Schritte mit dem Kunden:

• die Daten nach der Business-Sicht modellieren, nicht nach der operativen,
• Datenqualität messen und überwachen, statt sie zu vermuten,
• kuratiertes, validiertes Domänenwissen bereitstellen, das der Agent nicht selbst erraten muss.

Und die vielleicht wichtigste, übertragbare Lehre für jeden, der so etwas plant: Self-Learning ja — aber das Lernen muss aus kuratiertem, validiertem Domänenwissen kommen, nicht aus unkontrolliertem Nutzer-Feedback. Sonst lernt der Agent die Fehler und Missverständnisse seiner Nutzer mit. Und im schlimmsten Fall deren Absichten.

Planen Sie einen Analytics- oder KI-Agenten und wollen wissen, ob er auf Ihren Daten trägt? Das beantworte ich mit einem schlanken, messbaren PoC — bevor das große Budget fließt.