Ein achtwöchiger Machbarkeitstest für einen KI-gestützten Datenanalyse-Agenten: Über 80 Prozent SQL-Abfragegenauigkeit, bevor procelo in die volle Produktentwicklung investierte.

Die Herausforderung

Bevor procelo in die vollständige Produktentwicklung investierte, musste eine grundlegende Frage geklärt werden: Trägt der technische Ansatz überhaupt? Zwei Hürden standen zwischen der Idee und einem tatsächlich baubaren Produkt. Die erste betraf die Integration des Datenmodells: ERP-Systeme, aus denen der KI-Agent Daten abfragen sollte, enthalten große Datenmengen, die je nach Anbieter und Implementierung in sehr unterschiedlichen Schemata organisiert sind. Ein Agent, der über diese Schemata hinweg zuverlässig arbeiten sollte, brauchte ein Modellschema, das strukturiert genug war, damit die KI darüber schlussfolgern konnte, und zugleich flexibel genug, um die realen Abweichungen zwischen ERP-Systemen aufzufangen. Die Tabellenbeschreibungen mussten den Agenten präzise führen und trotzdem anpassbar bleiben, weil sich das Produkt weiterentwickeln würde. Die zweite Hürde war die Genauigkeit. Große Sprachmodelle, die natürliche Sprache in SQL übersetzen, tragen ein Risiko für Halluzinationen: Sie können syntaktisch plausibles SQL erzeugen, das falsche Ergebnisse liefert, oder Fachbegriffe aus dem Geschäftsalltag auf eine Weise missverstehen, die sich unbemerkt fortsetzt. Für ein Produkt, dessen zentrales Versprechen verlässliche Datenanalyse ist, war Genauigkeit keine Nebensache, sondern die entscheidende Voraussetzung - unabhängig davon, wie intuitiv die Benutzeroberfläche gestaltet war. procelo brauchte einen Prototyp, der die Tragfähigkeit des Ansatzes belegte, bevor die volle Produktentwicklung begann.

Der Ansatz

Gradion setzte ein Team aus drei Personen ein - 1 Technical Advisor, 1 PM/PO und 1 AI Engineer - für einen achtwöchigen Sprint aus Discovery und Prototypenbau. Das Team startete mit einer Ist-Status-Analyse: Es bewertete die vorhandene Datenumgebung, verstand die Struktur der ERP-Schemata und identifizierte, wo die Risiken für Genauigkeit und Konsistenz am größten waren. Die Datenarchitektur kombinierte eine primäre SQL-Datenbank mit einer sekundären Vektordatenbank. Anonymisierte Daten wurden in die SQL-Datenbank des Prototyps überführt. Die Vektordatenbank speicherte Beispiele, auf die der Agent während der Abfrage-Generierung zurückgreifen konnte, um die Genauigkeit durch zusätzlichen Kontext zu verbessern, statt sich allein auf das verallgemeinerte Schlussfolgern des Sprachmodells zu verlassen. Die Genauigkeit selbst wurde über einen mehrschichtigen Feinabstimmungsansatz erreicht: Beispiele aus der Vektordatenbank lieferten kontextuelle Verankerung, Tabellenbeschreibungen gaben dem Agenten ein präzises Vokabular für das jeweilige Schema, und strukturiertes Prompting leitete sein schrittweises Schlussfolgern bei der Konstruktion von Abfragen an. Diese Kombination sollte Halluzinationen bei der SQL-Generierung verringern und die semantischen Unterscheidungen abbilden, auf die es Fachanwendern ankommt - etwa die korrekte Unterscheidung zwischen "Bestellungen" und "Einkäufen" als eigenständige Konzepte im Datenmodell. Der entstandene Prototyp verfügte über eine Chat-Oberfläche, die natürlichsprachliche Anfragen entgegennahm, daraus zutreffendes SQL gegen das zugrundeliegende Schema erzeugte und die Ergebnisse - mit Schwärzung sensibler Inhalte, wo angebracht - für fachfremde Nutzer zugänglich darstellte.