Mein bisher komplexester Anwendungsfall ist ein hybrides RAG-System. Es ermöglicht Fragen zu Geschäftsdaten in natürlicher Sprache, ausgehend von importierten Lieferdokumenten. Im Kern ist es „Chat mit Ihren Daten“ – mit einer Anforderung, die alles verändert: präzise Ergebnisse. Das Projekt befindet sich derzeit in der Entwicklungs- und Testphase.
Wenn Sie nach den meistverkauften Produkten eines Zeitraums fragen, muss das Ergebnis mit den Zahlen des Verwaltungssystems übereinstimmen.
Eine klassische Vektordatenbank mit semantischer Suche allein kann diese Genauigkeit nicht garantieren. Benötigt werden sowohl ein Vektorindex als auch eine relationale Datenbank, in die die Dokumente strukturiert importiert wurden. Die Anwendung verarbeitet die Frage dann mit einem hybriden Verfahren: teils durch deterministischen Code, teils durch ein Sprachmodell, je nach Art der Anfrage.
Der Aufwand wächst weit schneller als die Präzision, die Sie gewinnen. Das Ergebnis ist ein komplexer Verarbeitungsfluss, wie der unten.
Das Sprachmodell kommt an höchstens drei Stellen zum Einsatz. Zählungen, Summen, Filter und Quellenangaben werden durch deterministischen Code verarbeitet.
Codedeterministischer SchrittModellAufruf eines Sprachmodells
Die natürlichsprachliche Frage mit allen ausdrücklich genannten Filtern.
Sucht in der Frage nach Werten, die tatsächlich in den Daten existieren, wie Namen und Codes, und nach Mengenangaben.
Die häufigsten Fragen werden durch deterministische Regeln erkannt, ohne ein Modell aufzurufen.
Wird die gesamte Frage erklärt? Wenn ein Teil davon unberücksichtigt bleibt, wird der Schnellpfad verworfen, anstatt eine teilweise Antwort zu geben.
Nur wenn kein Schnellpfad ausreicht: Das Modell entscheidet, ob die Frage eine Analyse oder eine Suche verlangt.
Abhängig von der Klassifizierung, einer von zwei Pfaden:
Für Analysen wandelt ein deterministischer Compiler die Frage in einen Plan um.
Bei Suchanfragen schlägt das Modell ein bis drei Schritte als typisiertes JSON vor. Der Code prüft Schema und Filter sowie Begriffe, die in der Frage nicht vorkommen.
Jeder Wert im Plan wird gegen die tatsächlichen Daten überprüft. Wenn er unbekannt oder mehrdeutig ist, wird eine Klärung angefordert.
Wenn sich die Daten in der Zwischenzeit geändert haben, wird die Vorbereitung wiederholt: ein veralteter Plan wird niemals ausgeführt.
Abhängig von der Art des Plans, einer von zwei Pfaden:
Zählungen, Summen und Analysen werden von der Datenbank berechnet; Texte und Zitate werden durch Code generiert. Kein Modell beteiligt.
Exakte Suche in der Datenbank oder semantische Suche im Vektorindex; anschließend werden die Treffer mit den aktiven Daten abgeglichen. Höchstens 40 Belege.
Nur für Suchen: Das Modell schreibt die Antwort und zitiert die Identifikatoren der Beweise, die es erhalten hat.
Der Server überprüft jeden Identifikator und baut die Zitate neu auf. Eine unbekannte Referenz führt zum Scheitern der Anfrage.
Text, Status, ausgeführter Plan und Zitate, mit Hinweisen auf die angewendeten Grenzen.
Ein solcher Ablauf muss Schritt für Schritt von Anfang an analysiert und überprüft werden. Andernfalls verbringen Sie Tage damit, Code zu schreiben, und beim ersten Test ist das Ergebnis falsch, ohne zu wissen, wo das Problem beginnt.
Jeder Schritt hat seine eigene Prüfung, basierend auf importierten Daten mit einer präzisen Bedeutung: Sie wissen immer, an welcher Stelle ein Ergebnis aufhört, korrekt zu sein.
Die Entwicklung orientiert sich an realistischen Fragen, die ich gemeinsam mit dem Kunden sammle. Für dieses Szenario wäre das Versprechen „Fragen Sie einfach alles“ nicht seriös.
Die Methode ist auch wichtig, weil das Ergebnis stark vom verwendeten Modell abhängt, und keine der Optionen ist kostenlos.
In den Tests des beschriebenen Projekts bieten Online-Dienste bessere Leistung als die lokale Konfiguration; folgende Aspekte bleiben zu berücksichtigen:
Ein offenes Modell auf einem GPU-Server vermeidet die Gebühr eines Anbieters pro Aufruf und hält die Daten im Haus. Es kann sich lohnen bei hohen, gleichmäßigen Volumina oder erforderlich sein, wenn Daten nicht an externe Dienste gesendet werden können. Dabei sind jedoch Kosten und Grenzen zu berücksichtigen:
Aus meiner direkten Erfahrung erfordert all dies eine sehr präzise Analyse und Entwicklung mit sorgfältiger Berücksichtigung der Kundenbedürfnisse: das Gegenteil von dem, was man oft online liest.
Seit etwa 2020 beschäftige ich mich mit maschinellem Lernen, später mit Deep Learning, generativer KI und Sprachmodellen, durch Kurse, Dokumentation und praktische Versuche. Meine direkte Erfahrung mit großen GenAI-Plattformen im Produktivbetrieb ist noch begrenzt.
Diese Beobachtungen verbinden das Studium mit rund dreißig Jahren praktischer Softwareentwicklung. Mein Schwerpunkt ist die Tragfähigkeit: Ein System muss genügend Nutzen bieten, um Entwicklung, Prüfung und laufenden Betrieb zu rechtfertigen.
Unter den oben beschriebenen Einschränkungen der lokalen Konfiguration halte ich Abläufe mit vielen Modellaufrufen für aufwendig zu betreiben. In diesem Kontext sehe ich eher Möglichkeiten bei wenigen Anfragen mit hohem Nutzen oder bei schnelleren Diensten, deren Kosten zur geleisteten Arbeit passen.
Diese Einschätzung betrifft die getestete Konfiguration und muss bei anderen Modellen, anderer Hardware oder veränderten Anforderungen überprüft werden. Günstigere Modelle, Routing zwischen Modellen und klarer begrenzte Abläufe können die Wirtschaftlichkeit verändern. Die unten genannten Databricks-Daten zeigen die Nutzung offener Modelle und agentischer Systeme bei dessen Kunden, repräsentieren aber nicht den gesamten Markt.
Entscheidungen benötigen aufgabenbezogene Tests, Kosten des gesamten Ablaufs und Ergebnisprüfungen.
Diese Quellen stützen die allgemeinen technischen Kriterien. Messungen auf meiner Hardware beschreiben genau diese Konfiguration und lassen sich nicht ohne Weiteres übertragen.