KI-Analyse-Startup: Funktionsfähiger KI-Datenanalyse-Prototyp in 8 Wochen geliefert. Über 80 % SQL-Abfragegenauigkeit erreicht.

Die Herausforderung

Bevor sich das Unternehmen zur vollständigen Produktentwicklung verpflichtete, musste eine grundlegende Frage geklärt werden: War der technische Ansatz überhaupt realisierbar? Zwei spezifische Herausforderungen standen zwischen dem Konzept und einem entwickelbaren Produkt. Die erste war die Datenmodellintegration. ERP-Systeme, die als Datenquelle für den Agenten dienen sollten, enthalten große Datenmengen, die je nach Anbieter und Implementierung in sehr unterschiedlichen Schemata organisiert sind. Der Aufbau eines KI-Agenten, der zuverlässig über diese Schemata hinweg arbeiten konnte, erforderte ein Modellschema-Design, das gleichzeitig strukturiert genug war, damit die KI darauf aufbauen konnte, und flexibel genug, um die realen ERP-Variationen zu berücksichtigen. Tabellenbeschreibungen mussten präzise genug sein, um den Agenten zu leiten, und gleichzeitig modifizierbar bleiben, während sich das Produkt weiterentwickelte. Die zweite Herausforderung war die Genauigkeit. LLMs, die als Übersetzer von natürlicher Sprache in SQL fungieren, bergen standardmäßig das Risiko von Halluzinationen, da sie syntaktisch plausible SQL-Abfragen generieren können, die falsche Ergebnisse liefern, oder Geschäftsterminologien auf subtile Weise falsch interpretieren können. Für ein Produkt, dessen zentrales Wertversprechen eine zuverlässige Datenanalyse ist, war Genauigkeit keine zweitrangige Sorge, sondern das primäre Kriterium. Inkonsistente oder falsche SQL-Ergebnisse würden das Produkt unbrauchbar machen, unabhängig davon, wie intuitiv die Benutzeroberfläche war. Der Kunde benötigte einen Prototyp, der die Solidität des Ansatzes demonstrierte, bevor er in die vollständige Produktentwicklung investierte.

Der Ansatz

Gradion arbeitete mit einem dreiköpfigen Team zusammen, bestehend aus einem Technical Advisor, einem PM/PO und einem AI Engineer, im Rahmen eines achtwöchigen Discovery- und Prototypen-Sprints. Das Team startete mit einer IS-Statusanalyse, um die aktuelle Datenumgebung zu bewerten, die ERP-Schema-Struktur zu verstehen und die kritischsten Risiken hinsichtlich Genauigkeit und Konsistenz zu identifizieren. Die Datenarchitektur kombinierte eine primäre SQL-Datenbank mit einer sekundären Vektordatenbank. Anonymisierte Daten wurden in die Prototypen-SQL-DB migriert. Die Vektordatenbank diente einem spezifischen Zweck: Sie speicherte Beispiele, die der Agent während der Abfragegenerierung abrufen konnte, um die Genauigkeit durch Kontext zu verbessern, anstatt sich ausschließlich auf die generalisierte Logik des LLM zu verlassen. Die Genauigkeit wurde durch einen mehrschichtigen Fine-Tuning-Ansatz sichergestellt: Vektorbeispiele lieferten eine kontextuelle Grundlage, Tabellenbeschreibungen gaben dem Agenten ein präzises Vokabular für das spezifische Schema, und strukturiertes Prompting leitete die schrittweise Argumentation des Agenten bei der Abfragekonstruktion. Diese Kombination wurde entwickelt, um Halluzinationen bei der SQL-Generierung zu reduzieren und die semantischen Unterscheidungen zu berücksichtigen, die für Geschäftsanwender relevant sind – zum Beispiel die korrekte Unterscheidung zwischen „Bestellungen“ und „Einkäufen“ als eigenständige Konzepte im zugrunde liegenden Datenmodell. Der resultierende Prototyp umfasste eine Chat-Oberfläche, die natürliche Sprachabfragen akzeptieren, präzises SQL für das zugrunde liegende Schema erstellen und Ergebnisse – bei Bedarf mit Ergebnisredaktion – in einem zugänglichen Format für nicht-technische Benutzer präsentieren konnte.