procelo tosca: Einsatzbereiter KI-Datenanalyse-Prototyp in 8 Wochen. Über 80 % SQL-Abfragegenauigkeit.

Die Herausforderung

Bevor procelo sich 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 umsetzbaren Produkt. Die erste Herausforderung war die Datenmodellintegration. ERP-Systeme – die Datenquelle, die der Agent abfragen sollte – enthalten große Datenmengen, die je nach Anbieter und Implementierung in sehr unterschiedlichen Schemata organisiert sind. Die Entwicklung eines KI-Agenten, der zuverlässig über diese Schemata hinweg agieren kann, erforderte ein Modellschema-Design, das gleichzeitig strukturiert genug für die KI-Logik und flexibel genug war, um die realen ERP-Variationen zu berücksichtigen. Tabellenbeschreibungen mussten präzise genug sein, um den Agenten zu leiten, und gleichzeitig anpassbar 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: Sie können syntaktisch plausible SQL-Abfragen generieren, die falsche Ergebnisse liefern, oder Geschäftsterminologie auf subtile Weise falsch interpretieren. Für ein Produkt, dessen zentrales Wertversprechen eine zuverlässige Datenanalyse ist, war Genauigkeit keine zweitrangige Sorge – sie war das primäre Kriterium. Inkonsistente oder falsche SQL-Ergebnisse würden das Produkt unbrauchbar machen, unabhängig davon, wie intuitiv die Benutzeroberfläche war. procelo benötigte einen Prototyp, der die Tragfähigkeit des Ansatzes demonstrierte, bevor in die vollständige Produktentwicklung investiert wurde.

Der Ansatz

Gradion arbeitete mit einem dreiköpfigen Team – bestehend aus einem Technical Advisor, einem PM/PO und einem AI Engineer – in einem achtwöchigen Discovery- und Prototyping-Sprint. Das Team begann mit einer IS-Status-Analyse: Bewertung der bestehenden Datenumgebung, Verständnis der ERP-Schema-Struktur und Identifizierung der kritischsten Risikobereiche für Datenkonsistenz und -genauigkeit. Die Datenarchitektur kombinierte eine primäre SQL-Datenbank mit einer sekundären Vektordatenbank. Anonymisierte Daten wurden in die Prototyp-SQL-Datenbank 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 optimiert: Vektorbeispiele lieferten kontextuelle Verankerung, 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 sollte Halluzinationen bei der SQL-Generierung reduzieren und semantische Unterscheidungen, die für Geschäftsanwender relevant sind, korrekt behandeln – zum Beispiel die präzise 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 generieren und Ergebnisse – bei Bedarf mit Datenmaskierung – in einem zugänglichen Format für nicht-technische Anwender präsentieren konnte.