Der Startpunkt jeder Antwort – die Frage verstehen.
Query-Processing im Companion for First
Wie Ihre Frage im Companion for First „verstanden“ wird – bevor die Antwort entsteht.
Der Companion for First ermöglicht Ihnen erstmals, Fragen in natürlicher Sprache an Ihre First Produktivumgebung zu richten:
„Wie haben sich unsere Immobilienfonds im letzten Quartal entwickelt?“
„Wie hoch ist das Gesamtvolumen aller nachhaltigen Investitionen in diesem Jahr?“
„Wie lautet der Marktwert aller Aktien mit ESG-Rating A+ zum Stichtag 31. September?“
und unendlich vieles mehr. Wenige Augenblicke nach der Eingabe erscheint die Antwort auf dem Bildschirm – als Zahl, Tabelle oder aussagekräftige Grafik. Zwischen der Ein- und Ausgabe durchläuft Ihre Anfrage die sogenannte RAG-Pipeline, das Herzstück des Companion for First. In dieser Verarbeitungskette werden die Nutzeranfragen zunächst aufgeschlüsselt und interpretiert. Das ist die Aufgabe des „Query-Processings“, um das es heute gehen soll.
Das Query-Pocessing beschreibt den Weg, wie eine Nutzeranfrage verstanden, optimiert und für die Beantwortung vorbereitet wird. Hier entsteht der Plan, was als Reaktion auf die Anfrage geschehen soll, was also konkret zu tun ist, um die gewünschten Daten und Informationen zu liefern. Ein wesentlicher Teil der Intelligenz des Companion for First ist deshalb im Query-Processing angesiedelt.
Im Anschluss geht es in den nachfolgenden Stufen der RAG-Pipeline weiter: Anhand des Plans aus dem Query-Processing wird die Nutzeranfrage aktiv in Datenzugriffe umgesetzt, mit weiteren relevanten Informationen verknüpft, das Ergebnis schließlich in prägnanter Form aufbereitet und als Antwort auf dem Bildschirm präsentiert. Das alles geschieht innerhalb von Sekunden.
Sie möchten das Whitepaper lieber hören?
Einfach mal fragen
Bislang mussten Nutzer für frei gestaltete Abfragen an ihr First System eine komplexe Syntax erlernen, die Struktur der Datenbank (mehr als 1.500 Tabellen) verstehen, wissen, welche Felder wie verknüpft sind oder besser gleich die Kollegen vom IT-Support hinzuziehen. Doch das war alles gestern.
Heute fragen Sie den Companion for First, wie es Ihnen gerade in den Sinn kommt. Ganz gleich, was Sie in Bezug auf Ihre Daten und Bestände wissen möchten – auf Deutsch, Englisch, Französisch oder gerne auch in Fachchinesisch.
Der Companion zwingt Sie nicht in eine starre Ausdrucksweise oder Form. Er erkennt vielfältige Synonyme und Umschreibungen, kann komplexe Abfragen aus einem einzigen Satz herauslesen und flexibel auf neue Datenquellen (Assets) reagieren. Das System lädt dazu ein, Fragen zu stellen: für alle, die es genau wissen wollen – hier und jetzt.
KI plus klassische Informatik
Wie schafft es der Companion for First, Nutzeranfragen in natürlicher Sprache zu verstehen? Dahinter steckt eine Mischung aus moderner KI-Technik und klassischer Informatik. Dieser Hybridansatz bedient sich des Sprachverständnisses großer externer KI-Modelle (Large-Language-Models bzw. LLMs wie ChatGPT, Claude, Gemini und Co.), erweitert durch das Wissen des Companions über Begriffe, Synonyme, Konstanten und Methoden, die im Zusammenhang mit First gebräuchlich sind.
Die KI-Technik in den LLMs sorgt bei dieser Aufgabenteilung dafür, dass der Companion nicht auf bestimmte Eingaben vortrainiert werden muss, dass er nicht bloß einen endlichen Satz von Anfragen kennt und bei allem, was auch nur einen Hauch darüber hinausgeht, ratlos zurückbleibt. Vielmehr sind nahezu unendlich viele Variations- und Kombinationsmöglichkeiten relevanter Begriffe erlaubt, wie es dem Wesen menschlicher Sprache entspricht. Nicht restlos alles wird die KI auf Anhieb verstehen können, aber das Allermeiste und Gebräuchlichste sehr wohl. Ansonsten hilft bekanntlich nachfragen – ebenfalls durch die KI.
Weiterlesen
Zum Feld der klassischen Informatik im Companion for First gehört die semantische Suche, eine kontextorientierte Ähnlichkeitssuche auf Basis von Vektormodellen. Bevor Nutzeranfragen zum LLM gelangen, werden die zentralen Begrifflichkeiten innerhalb der RAG-Pipeline aufgelöst und normiert. Fragt der Nutzer nach Aktien, Wertpapieren, Equities, Actions (französisch für Aktien) oder Shares? In allen Fällen geht es um den gleichen Typus von Asset!
Mehr als 16.000 Begriffe werden auf diese Weise aufgelöst. Sie stammen aus den sogenannten „First Konstanten“. Das sind vom System vorgegebene Festwerte plus die Systemeinstellungen mit Geschäftslogik und Begriffsübersetzungen, die in jeder Instanz von First kundenindividuell gespeichert sind. Als ProductType zählen dazu beispielsweise Aktien, Anleihen, Immobilien, Fonds etc., als KeyFigure Marktwert, Buchwert, Rendite, Risiko oder als Scenario: Basis, Stress, Worst-Case.
Diese Inhalte stehen auch als Download zur Verfügung.
Wissen, was zu tun ist
Ein Large-Language-Modell ist darauf spezialisiert, Sprache in ihre Bestandteile zu zerlegen, diese in Beziehung zu setzen und daraus Sinnzusammenhänge zu erschließen. Aber wie kann es Depotbestände aggregieren, diese nach Datum gruppieren oder auf Basis von Filterregeln selektieren? Die klare Antwort: Es kann dies gar nicht. Und es soll diese Fähigkeit auch nicht beherrschen, weil alle sensiblen Daten etwa über konkrete Marktwerte in First unter Verschluss bleiben.
Stattdessen erstellt das LLM aus der Analyse der Nutzeranfrage und ggf. Rückfragen beim Companion einen abstrakten Ausführungsplan zur Ermittlung der gewünschten Daten. Dieser wird dann innerhalb des Companions lokal umgesetzt. Das ist die Aufgabe des Tool-Processings, dem nachfolgenden Schritt in der RAG-Pipeline, den wir uns in einem der kommenden Whitepaper genauer anschauen werden.
Weiterlesen
Verbleiben wir an dieser Stelle jedoch erst einmal beim Query-Processing. Das gleicht ein wenig einem Ping-Pong-Spiel zwischen dem externen Sprachmodell und dem Companion.
Es gliedert sich im Wesentlichen in zwei Phasen:
1. Im ersten Schritt geht es darum, die Anwenderfrage zu verstehen.
2. Im zweiten Schritt wird das passende Ziel-Werkzeug für deren Beantwortung ausgewählt und anschließend werden die erforderlichen Parameter aus der Nutzerabfrage abgeleitet, die in den Ausführungsplan des Companions einfließen.
Gute Gründe nicht nur auf die KI zu setzen
Die Vertraulichkeit der in First gespeicherten Daten und Bestände ist nur ein Grund, warum sich der Companion for First nicht exklusiv auf die KI-Funktionen externer Sprachmodelle stützt: Klassische (deterministische) Algorithmen haben zwar einen enger gefassten Wirkungsbereich, arbeiten dafür aber in der Regel schneller, präziser und verbrauchen weniger Ressourcen als vergleichbare KI-Algorithmen. Das beschleunigt die Abläufe, senkt die API-Kosten und erleichtert die Protokollierung aller Verarbeitungsschritte im Sinne einer durchgängigen Compliance-Zugang und ein moderner Web-Browser.
PHASE 1
Anwenderfrage verstehen
Zunächst gilt es, unspezifische Begriffe aus der Anfrage (z.B. „Wie ist der Wert meiner Aktien“) in First-Domänenbegriffe zu übersetzen, damit klar wird, worum es konkret gehen soll. Dies ist ein iterativer Prozess: Der Companion konfrontiert das externe LLM mit der Anwenderfrage und liefert im sogenannten „Kontext“ (Zusatzinformationen an das Sprachmodell) die Namen und Beschreibungen mehrerer Meta-Tools (übergeordnete Werkzeuge) wie search_constants(), search_concepts().
Überall dort, wo das LLM Begriffe aus der Anwenderfrage nicht eindeutig auflösen kann, gibt es in seiner Antwort den Auftrag, das jeweils passende Meta-Tool aufzurufen, damit der Companion diese Begriffsauflösung lokal innerhalb der RAG-Pipeline übernimmt. Die Ergebnisse werden anschließend an das LLM zurückgespielt. So kann es mehrmals zwischen dem LLM und dem Companion hin- und hergehen. Sinnvollerweise wird dabei eine gewisse Obergrenze an Durchläufen vorgegeben, nach deren Erreichen klar ist, dass das LLM die Anfrage nicht vollständig auflösen kann (derzeit 10 Durchläufe). In diesem Fall wird der Anwender informiert und gebeten, seine Frage anders zu formulieren.
Ohne saubermachen geht es nicht
Das Query-Processing bildet das Tor zur Innenwelt des Companion for First. Was hier zur Weiterverarbeitung hineingelangt, muss frei von toxischen Rückständen sein. Böswillig eingebrachte Anfragen und Aufträge scheitern bereits an der strengen Toraufsicht. Speicherüberläufe durch überlange Inputs, unerlaubte Zeichencodes, manipulative SQL-Befehle, betrügerische Anweisungen an die KI u.v.m. werden aus dem Eingabestrom entfernt und dringen nicht bis zu den nachfolgenden Verarbeitungsstufen durch – damit das System jederzeit „sauber“ bleibt.
Diese Inhalte stehen auch als Download zur Verfügung.
PHASE 2
Werkzeug auswählen und Parameter ableiten
Ist die Begriffsauflösung in der Phase 1 erfolgreich abgeschlossen, geht es in der nächsten Phase darum, das passende Werkzeug zu finden. Anschließend müssen die spezifischen Parameter für den Aufruf dieses Werkzeugs aus der Nutzeranfrage abgeleitet werden. Für die konkrete Beantwortung von Nutzeranfragen kennt der Companion Hunderte von Werkzeugen (Daten-Tools), die Inhalte aus der First-Datenbank abrufen oder mit externen Datenlieferanten kommunizieren, jedes mit einer ganz spezifischen Aufgabe. Das LLM gibt die aufgelöste Nutzeranfrage an den Companion zurück und bittet diesen, über das Meta-Tool search_first_tools() passende Werkzeuge für diese Nutzeranfrage vorzuschlagen.
Die Auswahl erfolgt innerhalb der RAG-Pipeline auf Basis einer semantischen Suche über die aufgelöste Nutzerfrage. Die drei potenziell am besten geeigneten Werkzeuge werden mit ihren Namen und Beschreibungen an das LLM zurückgemeldet. Dieses entscheidet sich im Vergleich zwischen der Nutzeranfrage und den Werkzeug-Beschreibungen für eines dieser Werkzeuge, wobei im Falle verbleibender Unsicherheiten immer das erstgenannte gewählt wird. Nun geht es für das LLM darum, die erforderlichen Parameter für den Aufruf des gewählten Werkzeugs in Erfahrung zu bringen. Dafür kann es sich eines weiteren Meta-Tools des Companions bedienen: search_fields() Mittels dieser Informationen bringt das LLM die geforderten Parameter mit den korrespondierenden Angaben aus der Nutzeranfrage zusammen. Teilweise müssen die Daten für diese Parameter selbst wieder mithilfe von Daten-Tools ermittelt werden (Stichwort: „alle Aktien“), wodurch sich ein Tool-Graph ergibt, der innerhalb der RAG-Pipeline aufgelöst und auf Korrektheit überprüft wird. Sobald alles passt, kann dieser Plan in der nächsten Stufe der RAGPipeline ausgeführt und so die gewünschte Antwort für den Nutzer gewonnen werden.Weiterlesen
Die Rolle der Datentools
Die Daten-Tools bilden so etwas wie das Vokabular des Companion for First, jener Datenoperationen, die in seinem Wissensraum möglich sind und aus denen sich alle komplexen Abfragen zusammenfügen lassen. Es existieren mehrere hundert dieser Operationen, die grundsätzlich innerhalb des Companion ausgeführt werden, weil das LLM zu keinem Zeitpunkt an die First-Datenbank herangelassen wird. Hier einige Beispiele:
search_assets(): Suche nach Assets wie Anleihen, Wertpapiere etc.
search_positions(): Suche nach Positionen in den Beständen.
search_results(): Suche nach Ergebnissen wie Marktwerten zu einem gegebenen Datum und anderen Kennzahlen.
search_movements(): Suche nach Bewegungen in den Beständen durch Käufe, Verkäufe und Abgänge.
Ein konkretes Beispiel
Schritt für Schritt
Montagvormittag: Sie möchten gut vorbereitet in das wöchentliche Teammeeting gehen und deshalb noch schnell einige relevante Kennzahlen abrufen. Im Companion for First geben Sie ein: „Wie hoch ist der Marktwert unseres Aktienportfolios zum 31.9.2025?“. Kaum haben Sie an Ihrem Kaffee genippt, erscheint auf dem Bildschirm bereits die Antwort: 178,4 Mio. EUR. Das sieht doch gut aus.
In den wenigen Momenten zwischen Eingabe und Ausgabe hat der Companion im Hintergrund eine ganze Phalanx von Operationen ausgeführt: Er hat Ihre Frage ausgewertet, die zur Beantwortung erforderlichen Daten identifiziert, einen Plan für den Abruf und die Weiterverarbeitung dieser Daten geschmiedet, den Plan auf Vollständigkeit und Plausibilität geprüft und schließlich in Form von Datenbankzugriffen und Ergebnissummationen ausgeführt. Das Resultat sehen Sie vor sich. Doch wie muss man sich die einzelnen Phasen im Detail vorstellen?
Schritt 1 – Worum geht es?
Die semantische Suche und das externe Sprachmodell arbeiten beim Verstehen der Anfrage Hand in Hand. Sie erkennen, dass es in der Benutzeranfrage um folgende zentrale Elemente geht.
• Aktienportfolio: Gemeint sind offensichtlich alle Wertpapiere im Bestand vom Typ Aktien (interner Begriff: shares)
• Marktwert: Das System erkennt eine zugehörige Kennzahl mit dem Titel marketValueLC (für Market Value Local Currency). Darum soll es also gehen.
• 31.9.2025: Dies ist ein Datumsfilter vom Typ dataDate. Auf dieses Datum muss sich die Abfrage also beziehen und auf keinen anderen Zeitpunkt.
Schritt 2 – Welche Daten werden benötigt?
Über die gelernten Datenbeziehungen erkennt das System, dass sich die benötigten Daten für „alle Aktien im Bestand“ aus drei Quellen speisen.
1. Assets-Datenbank: Welche Aktien hatten wir zum Stichtag im Bestand?
2. Positionen-Datenbank: Wie viele Stück jeder dieser Aktien lagen zum Stichtag in welchem Depot?
3. Ergebnisse-Datenbank: Was waren die Marktwerte dieser Aktien zum Stichtag?
Schritt 3 – Wie sieht die optimale Reihenfolge aus?
Nun wird ein Plan gefasst, wie diese Daten abzurufen sind und vor allem, in welcher Reihenfolge, um tatsächlich alle Aktien zu berücksichtigen. Als Ausgangspunkt dafür dient wiederum das Graphenmodell.
1. Finde alle Assets mit dem Produkttyp „Aktien“
2. Hole alle Positionen zu diesen Assets
3. Hole die Marktwerte zum 31.09.2025 für diese Positionen
4. Summiere die Ergebnisse zum Endergebnis auf
Schritt 4 – Passt der Plan?
Weil ein externes LLM in die Planerstellung involviert ist, macht es Sinn, den Plan vor der Ausführung unter verschiedenen Gesichtspunkten auf Vollständigkeit und Plausibilität zu prüfen. Sind alle benötigten Filter vorhanden? Sind alle Datenverknüpfungen korrekt? Fehlt kein Ausführungsschritt? Erst nach erfolgreicher Validierung geht der Plan in die finale Stufe. Das Query-Processing ist damit abgeschlossen.
Schritt 5 – Planausführung und Ergebnisanzeige
Im Rahmen der sogenannten „Tool-Execution“ wird der ausformulierte Plan auf Basis der genannten Werkzeuge (search_assets() etc., siehe oben) abgearbeitet. Die Ergebnisse werden dabei von Stufe zu Stufe weitergereicht und verknüpft. Datenbankabrufe münden in der Regel in korrespondierende SQL-Befehle für die First Datenbank, mathematische Operationen werden, wie im Plan definiert, ausgeführt. Beide Vorgänge, das Tool-Processing und die Ergebnisaufbereitung, werden wir in nachfolgenden Whitepapern noch genauer beleuchten.
Als Resultat der Benutzeranfrage steht schließlich ein Ergebnis, das vor der Ausgabe noch passend als Zahl, Tabelle oder Grafik aufbereitet wird. Die Verarbeitungskette im Companion for First kommt damit erst einmal zum Abschluss. Weitere Anfragen können aufgrund der asynchronen Verarbeitungsmöglichkeiten des Companion jedoch bereits in Arbeit sein. Sie müssen mit der Eingabe der nächsten Anfrage also nicht warten, bis eine vorangehende Abfrage abgeschlossen ist.
Nächste Haltestelle: Tool Execution
Soweit zum Query-Processing im Companion for First. Wir bleiben der RAG-Linie noch für weitere Stationen treu und werden uns in der nächsten Folge mit der Tool-Execution beschäftigen.
Dann wird es darum gehen, wie der Companion den erstellten Plan abarbeitet, um zu eindeutigen, belastbaren und reproduzierbaren Resultaten als Antwort auf die gestellten Fragen zu gelangen.
Fragen zu KI oder RAG-Pipeline? Die FAQ erklären’s einfach.
Weitere Inhalte unserer Companion-Reihe:
Neugierig geworden?
Sie möchten mehr über First Cloud, den Companion for First und den Betrieb in der Fact Cloud erfahren? Dann schreiben Sie uns oder sprechen Sie direkt mit unserem Experten Aleksandar Ivezić. Er freut sich auf Ihre Anfrage:
Aleksandar Ivezić
a.ivezic@fact.de
+49 2131 777 238
