HCL Informix modernisieren: Mit VectorBlade vorhandene Daten für KI nutzen

Also gut. Herzlich willkommen zum Webinar zum Thema HCL Informix und Vector Blade. Mein Name ist Steffen Kleber, ich bin Chief Researcher bei Action, arbeite mittlerweile seit über neun Jahren in diesem Unternehmen und bin verantwortlich für unsere Datenbanksysteme, die Strategie sowie KI-Initiativen in den Systemen.

Worüber wir heute sprechen möchten, ist zum einen natürlich das Vector Blade, die Erweiterung für HCL Informix, die es ermöglicht, Vektordaten abzufragen und mit Vektordaten zu arbeiten, aber auch ein wenig das größere Ganze: Wie fügt sich Informix heute in die KI-Landschaft ein? Bevor wir ins Detail gehen, möchte ich über Trends sprechen und das Ganze einordnen. Zum einen ist es natürlich so, dass KI generell unser Verständnis davon verändert, was wir mit Daten überhaupt alles machen können.

Das heißt, traditionell hat man mit strukturierten Daten gearbeitet. Man hatte Tabellen, feste Schemata und nutzte dafür relationale Datenbanken. KI ermöglicht nun jedoch die Verarbeitung unstrukturierter Daten, also von Texten, Bildern, Videos und Audiodateien – und das auch in Kombination.

Auch strukturierte und unstrukturierte Daten können gemeinsam verarbeitet werden. Ermöglicht wird dies durch den Vektordatentyp und die Ähnlichkeitssuche. Das heißt, wir können nicht mehr nur mit relationalen Abfragen, also SQL-Abfragen, arbeiten, sondern wir können Daten auch nach ihrer Bedeutung abfragen, statt nur nach exakten Schlüsselwörtern.

Und genau das macht es im Unternehmensumfeld so attraktiv, denn es gibt verschiedene Studien – das begann bereits 1998 mit dem ersten Bericht, wurde aber auch durch aktuelle Berichte von Gartner und IDC bestätigt –, wonach tatsächlich 80 % der Unternehmensdaten unstrukturiert sind. Das heißt, das sind die E-Mails, das sind die Confluence-Seiten, die PDF-Dokumentationen, die irgendwo liegen und die eben so viel Wert enthalten, dass es wichtig ist, Nutzen und Wert aus den Daten zu ziehen. Auf der anderen Seite verändert KI natürlich den Umgang mit Daten.

Vor dem KI-Zeitalter haben wir natürlich hauptsächlich manuell damit gearbeitet. Das heißt, wir haben Pipelines verwaltet, Pipelines aufgebaut, Schemata verwaltet, Daten manuell bereinigt, nach Datenfehlern gesucht, Systeme administriert und Berichtsstrukturen aufgebaut – all das manuell. Der erste Schritt, der durch KI hinzugekommen ist, besteht darin, dass das Ganze nun dialogorientiert ablaufen kann.

Das heißt, wir können natürlich sprachgesteuerte Anfragen stellen, um unsere Daten zu analysieren. Wir können aber auch Anweisungen oder Fragen in natürlicher Sprache stellen, wie wir mit dem System umgehen müssen, welche Fehler möglicherweise auftreten können und welche Optimierungsmöglichkeiten es gibt. Und das ermöglicht einfach einen sehr einfachen Zugang zu diesen Systemen, auch für Menschen, die vielleicht wenig oder gar keinen technischen Hintergrund haben.

Wichtig ist: Das wird natürlich noch vom Menschen gesteuert. Das heißt, ich muss aktiv Fragen in mein System eingeben. Das heißt, ich muss im Prinzip die Probleme bereits erkennen und muss nur fragen, wie das Ganze gelöst werden kann.

Im KI-Zeitalter setzen wir auf autonome Agenten. Das heißt, sie sind zielgesteuert. Ich als Mensch muss also nicht mehr wissen, was eigentlich das Ziel oder der Weg dorthin ist, sondern kann die Agenten autonom arbeiten lassen.

Sie erkennen Probleme eigenständig, planen und setzen Lösungen dafür um – und genau das ermöglicht eine Wartung der Systeme rund um die Uhr sowie automatisierte Abfragen. Vielleicht entdecken die Agenten auch Strukturen oder Probleme in den Daten, die man als Mensch gar nicht gefunden hätte. Wir haben eben diese beiden Aspekte. Zum einen ermöglicht KI die Verarbeitung größerer Datenmengen, zum anderen ermöglicht sie uns aber auch einen ganz anderen Umgang mit Daten.

Da stellt sich natürlich die Frage: Sind Datenbanken eigentlich noch relevant? Und das ist eine der Kernbotschaften, die wir heute vermitteln wollen. Relationale Datenbanken sind nach wie vor sehr wichtig und bilden nach wie vor das verlässliche Fundament, auf dem KI und Agenten aufbauen.

Das sollte man nicht vergessen. Datenbanken sind von ihrer Konzeption her vertrauenswürdig. Wir alle kennen die ACID-Eigenschaften, und gerade im Zeitalter der Agenten ist es wichtig, dass Agenten mit konsistenten Daten arbeiten und diese als „Single Source of Truth“ dienen.

Das heißt, ich habe ein System, das meinen Datenbestand konsistent und in hoher Qualität verwaltet und nicht über verschiedene Ordnerstrukturen und so weiter verteilt ist. Als Anekdote: Ich habe zum Beispiel ein Webinar von Antropic gesehen, in dem darüber nachgedacht wurde, wie Agenten gemeinsam an Dateien arbeiten können. Das sind Probleme, die die Datenbankwelt bereits seit Jahrzehnten gelöst hat.

Zustimmung und MultiNutzer-Anwendung. Besonders gut eignet sich hierfür Informix, da Informix multimodal und erweiterbar ist. Das bedeutet, dass Informix verschiedene Datentypen speichern kann, nicht nur strukturierte Daten.

Mit dem Vector Blade, um das es heute gehen soll, erweitern wir das Ganze noch um Vektoren, und damit können wir HCL Informix so erweitern, dass es auch für KI-Anwendungen bereit ist. Außerdem verändern Agenten ein wenig den Workload, den wir auf Systeme abfeuern. Agenten stellen viel mehr repetitive Abfragen mit hoher Zustimmung , und hier zahlen sich eben die Jahrzehnte der Abfrageoptimierung und der Sicherheit von Datenbanksystemen aus, um solche Agentenabfragen schnell und sicher zu halten.

Auch Datenbanken sind heute noch sehr relevant, insbesondere für Agenten. Als wichtige Erkenntnisse, die wir Ihnen heute mit auf den Weg geben möchten: HCL Informix wird KI-fähig. Wir können also KI dort einsetzen, wo sich die Daten bereits befinden.

Möglich wird dies durch den nativen Vektordatentyp und durch MCP. Außerdem befassen wir uns natürlich mit sprachlichen Schnittstellen, die es ermöglichen, mit Daten zu kommunizieren, und wir werfen einen Blick darauf, wohin die Zukunft führt. Agentbasierte Werkzeuge, die es ermöglichen, vereinfacht mit dem System zu arbeiten und Unterstützung bei der Administration zu erhalten.

Okay, kommen wir zunächst einmal zum Vector Blade. Als Hintergrund dazu ist dieses Muster der RAG-Systeme (Retrieval Augmented Generation) eigentlich relativ bekannt. Als kurze Einordnung möchte ich hier dennoch noch einmal darauf eingehen.

Was haben wir? Wir haben eine ganze Menge unstrukturierter Daten. Das können Texte, Bilder oder Videos sein.

Wir zerlegen diese Daten mithilfe eines Chunking-Mechanismus in Chunks, und anschließend betten wir diese in einen Vektorraum ein. Das heißt, wir verwenden ein Embedding-Modell, das diese Chunks im Prinzip auf einen hochdimensionalen Raum abbildet, wobei jeder dieser Chunks zu einem Punkt in diesem Raum wird. Wir speichern dann diese Vektoren, die eben diese Punkte beschreiben, in der Datenbank – in unserem Fall HCL Informix Vector Blade –, und das ermöglicht es uns dann, durch eine Ähnlichkeitssuche relevante Dokumente und relevante Chunks wieder abzurufen, diese an ein Modell zu übergeben und damit eben auch Antworten zu erhalten, die auf den Daten beruhen, die wir eigentlich nicht speichern.

Auch im proprietären Wissen des Unternehmens. Mit dem HCL Informix Vector Blade erhalten wir das nun nativ in Informix. Das heißt, wir verfügen über eine integrierte Komponente des Datenbankservers.

Diese befinden sich direkt neben den relationalen Daten. Ich benötige also kein zusätzliches System zur Verwaltung meiner Embeddings und Vektordaten und brauche somit auch keine zusätzliche Konnektivität oder Sicherheitskonfiguration. Ich kann das Ganze über dieselbe vertraute SQL-Schnittstelle abfragen, die ich bereits habe.

Das Ganze ist isoliert und skalierbar. Wir haben das Informix Vector Blade so konzipiert, dass die darin enthaltenen Routinen in einer eigenen VP-Klasse namens LVec ausgeführt werden. Das bedeutet, dass alle Operationen und alle Threads, die für das Vector Blade verwendet werden, die bestehenden Threads des operativen Datenbanksystems nicht beeinträchtigen.

Auch die Zuverlässigkeit, die wir ja für ein solches Datenbanksystem benötigen, wird dadurch nicht beeinträchtigt. Es läuft isoliert. Schauen wir uns kurz an, wie das funktioniert.

Wir haben also Dokumente und Bilddaten. Zum Beispiel würden wir nun in der darüber liegenden Anwendungsschicht die Pipeline aufbauen. Dokumente werden in Chunks zerlegt, mit einem Embedding-Modell eingebettet und in Vektoren umgewandelt, die dann zusätzlich in den Blade in der Datenbank geschrieben werden.

Das ist nun eine wichtige Erkenntnis, die wir verstehen müssen. Informix und das Vector Blade dienen dazu, diese Chunks oder diese Vektoren abzufragen und zu speichern. Der Rest geschieht in der Anwendungsschicht.

Der Rest ist in der Regel anwendungsspezifisch. Also: Wie teile ich meine Daten in Blöcke auf, welche Daten habe ich überhaupt? Informix mit dem Vector Blade kann jedoch letztendlich mit der Granularität der Vektoren umgehen.

Das heißt, ich speichere meine Vektoren dann in der Datenbank, im „Vector Blade“, und kann dann, wenn ich eine Abfrage habe – hier mal als Beispiel: Wie waren die Verkaufszahlen im letzten Jahr? Dann wird die Frage potenziell in Chunks zerlegt oder es werden Schlüsselwörter ausgewählt. Diese werden wiederum durch dasselbe Embedding-Modell geleitet, sodass ich wieder einen Vektor erhalte, der meine Fragen beschreibt, und dann kann ich eine Ähnlichkeitssuche durchführen.

Bei der Ähnlichkeitssuche betrachte ich meinen hochdimensionalen Raum und suche die Punkte in diesem Raum, die meinem Vektor, der meiner Frage entspricht, besonders nahe liegen. Ich kann also Ähnlichkeitsmaße im Vektorraum verwenden, um zu prüfen, welche Chunks, welche Vektoren am besten zu meiner Frage passen. Ich erhalte dann diese relevanten Chunks vom Vector Blade zurück und kann sie dann als Kontext an mein LLM übergeben, um daraufhin eine Antwort auf meine Frage zu erhalten.

Und diese Antwort bezieht sich dann natürlich auf den Kontext, den ich aus dem Vector Blade entnommen habe. Ich hatte eben kurz die Isolierung angesprochen. Das ist relativ wichtig.

Hier sehen wir noch einmal alle Datenbankaufgaben, die es bisher gibt. Diese sind vom Vector Blade getrennt. Im Blade kann ich Vektoren einfügen, abfragen und sogar ändern.

Das heißt, wir unterstützen auch Modifikationsvorgänge. Wie kann ich nun damit beginnen? Zunächst muss ich das Blade installieren, und zwar im Informix-Verzeichnis, im Extend-Verzeichnis.

Wir bringen ein Bild, ein Embedding-Modell, mit. Das heißt, wir haben bereits eine Funktion. Darauf werde ich später bei den wichtigen Funktionen noch einmal zurückkommen.

Wir verfügen über eine Funktion, die die Umwandlung von Text in Vektor-Embeddings vereinfacht. Wir müssen also nicht zwangsläufig in der Anwendungsschicht das Ganze selbst entwickeln. Wir stellen ein Embedding-Modell zur Verfügung, das dafür sorgt, dass man einfach loslegen und damit experimentieren kann.

Das Ganze basiert auf OpenAI, und um es zu nutzen, kann man hier über die Umgebungsvariable einen OpenAI-Schlüssel festlegen, der dann verwendet wird, um ein Embedding-Modell aufzurufen. Anschließend kann ich das Blade in der Datenbank registrieren, und es werden auch eine ganze Reihe von Beispielen mitgeliefert, sodass ich direkt damit beginnen kann, das Ganze zu nutzen. Ich möchte nun auf die wichtigen Funktionen eingehen, die bereits vordefiniert sind.

Man muss nun verstehen, dass das Vector Blade im Prinzip dadurch, dass es separat läuft, die Embeddings noch einmal separat speichert. Es gibt – wie hier als „Lens Table Name“ vermerkt – die Tabellen im Vector Blade und es gibt Tabellen im Informix-Tabellenformat. Im Informix-Tabellenformat werden die Embeddings gespeichert, aber abrufbar sind sie über diese Lens-Tabelle.

Das heißt, ich kann hier mit der Funktion „L Vector Create Table“ eine L-Tabelle anlegen. Ich muss lediglich die Anzahl der Dimensionen für meine Vektoren angeben. Das hängt ganz einfach davon ab, welches Embedding-Modell ich verwende.

Embedding-Modelle haben unterschiedliche Ausgabedimensionen, typischerweise 384, 768 oder 1534. Das sind sozusagen die gängigen Modelle, die es gibt. Je größer die Dimensionen natürlich sind, desto genauer kann ich letztendlich meine Abfragen durchführen und desto mehr verschiedene Daten kann ich abbilden, aber desto länger ist auch die Laufzeit für Embedding und Retrieval.

Hier ein Beispiel: Ich kann eine einfache „ Demo “-Tabelle mit drei Dimensionen anlegen. Genauso kann ich eine Tabelle natürlich auch wieder löschen, indem ich mit dem Befehl „Drop Table“ den Tabellennamen angebe. Und um nun Daten dort hineinzubekommen, habe ich zum einen die Möglichkeit, ein sogenanntes „Sync Insert“ auszuführen, gebe den Tabellennamen an und dann hat eine solche Vektortabelle immer das gleiche Schema.

Es gibt eine ID, es gibt eine Vektorspalte und es gibt eine Metadatenspalte. Am Beispiel hier sieht man es ganz gut: ID eins für dieses Tupel, dann den Vektor als String und Metadaten kann auch ein beliebiger String sein. Ich könnte das also zum Beispiel auch als JSON-formatiertes Dokument erstellen.

Genauso kann ich solche Tupel über die ID wieder löschen, also über einen „Sync Delete“. Und um das Ganze beim Abrufen dann richtig zügig zu gestalten, gibt es Indexstrukturen. Indexstrukturen kennt man aus Datenbanken schon seit jeher.

Im Prinzip tausche ich die Aktualisierbarkeit gegen die Abrufgeschwindigkeit oder die Abfragegeschwindigkeit ein. Wenn ich einen Index habe, ist die Abfrage in der Regel schneller. Das gilt schon seit jeher für B-Bäume und so weiter.

Wenn ich jedoch neue Tupel hinzufüge, muss ich den Index natürlich auch aktualisieren. Was ich hier also tun kann: Ich gebe den Tabellennamen an, ich gebe den Indextyp an – darauf werde ich später noch näher eingehen – und die Anzahl der Partitionen für den Index. Das ist ein Tuning-Parameter für die Leistung.

Und damit wird der Index automatisch auf der Vektorspalte angelegt. Und dann die wichtigste Funktion: „L Vector Search“. Das ist die Funktion, mit der ich dann meine Abfrage umsetzen kann.

Ich gebe erneut den Tabellennamen und den Suchvektor an. Das ist also der Vektor, den ich erhalte, wenn ich aus meiner Frage mit einem Embedding-Modell einen Vektor generiere – das ist praktisch der Punkt in meinem Vektorraum, den ich suche. Und nun durchsucht das Vector Blade mithilfe dieser Ähnlichkeitssuche den Bereich um diesen Punkt herum: Was sind die nächsten Punkte?

Jetzt kann ich hier angeben, wie viele Nachbarn ich haben möchte. Auch das ist ein Tuning-Parameter und hängt ein wenig von der jeweiligen Anwendung ab. In der Regel sucht man einen Kontext aus drei bis zehn Chunks, die man dann als Kontext für sein LLM bereitstellen möchte.

Das ist die Embedding-Funktion, die ich gerade angesprochen habe und die es ermöglicht, ein solches Embedding relativ einfach zu berechnen, wenn ich einen OpenAI-Schlüssel habe und diesen in der Umgebungsvariable festgelegt habe. Der Aufruf ist ganz einfach: Ich gebe eine Zeichenkette ein und die Prozedur gibt dann einen Vektor zurück. Und das Coole daran ist, dass ich das Ganze auch kombinieren kann.

Ich kann also einen INSERT-Befehl ausführen, die Tabelle angeben, die ID angeben und anstelle des Vektors diese Embedding-Funktion aufrufen, um das Embedding direkt zu berechnen, ohne dass ich das jetzt von Hand machen muss. Es gibt noch eine weitere Gruppe vordefinierter Funktionen. Es gibt eine Distanzfunktion, das heißt, ich kann Distanzen manuell berechnen.

Das ist es, worauf letztendlich auch die Suchfunktion basiert. Ich kann Vektoren miteinander vergleichen. Ich kann eine Suche mit einem zusätzlichen Filter durchführen.

Das ist sehr interessant. Das bedeutet, dass ich anhand der Metadaten noch einfache Kriterien abfragen kann. Zum Beispiel, ob ein bestimmtes Schlüsselwort enthalten ist oder eine bestimmte Bedingung erfüllt ist.

Ich werde später noch einmal auf die Bedeutung der Suche eingehen. Gerade im Unternehmensumfeld ist das wichtig. In der Regel suche ich unter bestimmten Rahmenbedingungen und nicht in meiner gesamten Datenbank.

Und dann gibt es noch die Bulk-Sync-Operation, die es mir ermöglicht, aus meiner Informix-Tabelle – wenn ich dort Vektoren eingefügt habe oder wenn die Tabelle bereits existiert – alle meine Vektoren auf einmal in einem großen Stapel, also gebündelt, mit der Vektortabelle im Vector Blade zu synchronisieren. Es gibt eine Reihe unterstützter Indextypen. Das sind – wenn man sich ein wenig in den Vector-Space einliest – die gängigen Typen.

Es gibt einen Flat-Index, der eigentlich die exakte Suche ermöglicht. Das heißt, damit erhalte ich wirklich 100 % Genauigkeit. Es gibt die Quantisierung, die im Prinzip die Vektordarstellung komprimiert.

Damit erhalte ich in der Regel relativ ungenaue Ergebnisse, dafür aber sehr schnell. Und es gibt den HNSW, also einen Baumindex, den „Hierarchical Navigable Small World Index“. Wie bei einem typischen Baum geht er zunächst grob granulär vor, sucht den nächsten Nachbarn und geht dann von diesem Nachbarn aus weiter, wobei er feingranularer vorgeht.

Es gibt verschiedene Indextypen, die man auswerten kann. Wie immer ist ein Index im Prinzip ein Kompromiss zwischen Geschwindigkeit und Präzision. Wenn ich 100 % Präzision benötige, sollte ich den Flat-Index wählen.

Wenn ich jedoch akzeptiere, dass unter meinen zehn Ergebnissen auch ein irrelevantes Ergebnis ist, dann kann ich auch einen solchen HNSW-Index verwenden.

Okay, kommen wir zur „ Demo “. Ich habe zwei Dinge vorbereitet. Zum einen habe ich dafür gesorgt, dass wir das Ganze einmal ganz praktisch in der Konsole ausprobieren können.

Einen Moment. Ich teile meinen Bildschirm wieder. Zoomen wir noch ein bisschen näher heran.

Ich hoffe, das ist gut zu erkennen. Wir wechseln nun wieder in eine Datenbank und richten eine Testdatenbank ein. Und was wir jetzt tun können: Wir können ein wenig mit den Funktionen herumprobieren, die bereits vorhanden sind.

Wir können mal eine Distanzfunktion zwischen zwei Vektoren ausprobieren, 111 und Und hier kann man im Prinzip die Art der Distanzfunktion angeben. Eine L2-Distanz ist eine einfache räumliche Distanz. Das heißt, sie berechnet aus jeder Komponente die Differenz, quadriert das Ganze, summiert es und zieht am Ende die Wurzel daraus – das gibt mir also einen Eindruck davon, wie weit die Punkte im Raum wirklich voneinander entfernt sind.

In diesem Fall 15. Und dann gibt es noch weitere Abstandsmaße, zum Beispiel den Kosinusabstand. Und hier sehen wir nun, dass der Abstand hier null ist, denn der Kosinusabstand bezieht sich nicht auf den eigentlichen Abstand, sondern auf die Richtung.

Wichtig bei solchen Abrufen ist, dass eigentlich die Richtung relevant ist und nicht die Länge des Vektors. Wir sehen, dass 111 und 101010 genau in dieselbe Richtung weisen. Das heißt, sie drücken – sehr wahrscheinlich auch nach dem Embedding-Modell oder so, wie die Embedding-Modelle aufgebaut sind – dasselbe aus.

Das heißt, hier beträgt die Distanz null. Sie sind also sehr ähnlich. Die Kosinusdistanz wird typischerweise für Ähnlichkeitssuchen verwendet.

L2-Distanz wird eigentlich nur für mathematische Berechnungen verwendet und weniger für diese Ähnlichkeitssuche. Was ich jetzt als Beispiel machen kann: Ich erstelle mal eine Informix-Tabelle. Das ist eine ganz normale Create-Table-Anweisung, und ich habe eine ID, ich habe ein Embedding und ich habe Metadaten, und ich kann nun eine Reihe von Werten einfügen.

Das ist zum einen null mit den Werten -100, -100, -100. Ein Beispielstring. Und genauso kann ich nun auch zwei weitere Tupel einfügen.

Und was ich jetzt tun kann, ist, diese LVector-Funktion zu verwenden, um eine neue Tabelle im Vector Blade anzulegen. Also „LVector Create Table“, die Tabelle „eins“ nennen, Dimension drei, denn die Vektoren in dieser Tabelle haben die Dimension drei. Es sollen nämlich genau diejenigen sein, die ich bereits in die Informix-Tabelle eingefügt habe.

Und was ich jetzt mache, ist, dass ich die Bulk-Sync-Funktion nutze, wie zuvor vorgestellt. Ich gebe die Informix-Tabelle an, ich gebe die Vector-Blade-Tabelle an, die ID-Spalte und die Vektor-Spalte. Und die Routine hilft mir nun dabei, alle Vektoren, die bereits in der Informix-Tabelle enthalten sind, einmal mit meiner Vector-Blade-Tabelle zu synchronisieren.

Und was ich jetzt tun kann, ist, eine ganz normale SQL-Abfrage auszuführen, und die können wir uns nun einmal genauer ansehen. Ich habe hier zwei Tabellen. Ich habe die Informix-Tabelle und ich habe die Vector-Blade-Tabelle.

Nutze nun also die Suchfunktion nach einem Suchvektor, in diesem Fall 222. Das ist der Vektor, der aus dem Einbettungsmodell meiner Frage stammt. Ich gebe an, dass ich drei Nachbarn haben möchte, und zwar berechnet nach dem Kosinusabstand.

Ich habe das auf den Typ „LVector Search Result“ umgewandelt. Das ist genau diese Struktur aus ID, Vektor und Metadatenfeld. Und was ich jetzt tun muss, ist, diese beiden Tabellen zu verknüpfen.

Ich nehme also die Vector-ID meiner Informix-Tabelle und die ID-Spalte meiner Such-Tabelle aus meinem Vector Blade, führe ein Join durch und sortiere das Ganze nach der Distanz, die sich aus der Ähnlichkeitssuche ergibt. Wenn ich das Ganze nun ausführe, sehe ich, dass 222 nach der Kosinusdistanz am nächsten an 101010 lag. Das ist genau das Beispiel, das wir vorhin auch hatten.

Die Distanz ist null. Zu 004 haben wir eine Distanz von 0,42 und zu -100,-100,-100 haben wir die maximale Distanz in der Kosinusdistanz von zwei. Das bedeutet, dass sie sich genau gegenüberliegen und genau in entgegengesetzte Richtungen zeigen.

Das leuchtet ein. Das ist also die Abfragekonstruktion, die ich letztendlich verwenden kann, um wirklich mit einer einzigen SQL-Abfrage eine Vektordistanz zu berechnen. Und jetzt habe ich natürlich die Möglichkeit, alle Daten, die in meiner Informix-Tabelle enthalten sind, über diese ID die Nachbarn zu ermitteln, und nun kann ich alle Spalten, die ich in meiner Informix-Tabelle habe – egal, ob es sich um zusätzliche Zeichenfolgendaten oder um Ganzzahldaten handelt – mitzuverwenden, sie als Kontext in mein LLM einzubringen und erhalte damit eben den Kontext, den ich zur Beantwortung meiner Frage brauche.

Das Ganze lässt sich nun, wie ich bereits erwähnt habe, weitgehend logisch auf der Anwendungsebene umsetzen. Das heißt, wir haben hier auch eine kleine Demo-Anwendung, in der man das einmal von Anfang bis Ende zeigen kann. Ich teile wieder meinen Bildschirm und bin noch dabei, danach zu suchen.

Dies ist eine Demo-Anwendung, die wir intern zu Demonstrationszwecken entwickelt haben. Was wir hier tun können, ist, dass ich Dokumente überprüfen kann. Das heißt, ich kann über „Dokument hochladen“ Dokumente auswählen, die ich dann hochlade.

Und ich habe mir jetzt mal den Informix-Newsletter von letzter Woche vorgenommen, der über den E-Mail-Verteiler kam, und kann das Ganze nun hochladen. Die Anwendung scannt nun das Dokument und unterteilt es automatisch in sinnvolle Abschnitte. Wir verwenden hier „Semantic Chunking“, das heißt, das System versucht, das Dokument an sinnvollen Stellen zu teilen, und nutzt dann ein Embedding-Modell, um das Ganze zu verarbeiten und in Informix einzufügen.

Wir sehen jetzt hier, dass das Ganze funktioniert hat. Wir haben 29 Chunks generiert, und ich sehe auch, dass das Dokument geladen ist. Was ich jetzt tun kann, ist, hier Fragen zu stellen, die sich speziell auf dieses Dokument beziehen.

Ein Teil des Newsletters war die Nullif-Funktion. Das heißt, wir können jederzeit nachfragen, was diese Funktion eigentlich macht. Und was wir jetzt hier sehen, hier drüben, sehen wir im Log „Activity“, dass das Ganze abgefragt wird, und wir können hier nun nachvollziehen, welche Chunks tatsächlich verwendet wurden.

Und wir sehen hier nun aus diesem Dokument den Techtip „Funktion Nullif“ – das ist der Chunk, den er als relevantesten identifiziert hat, und zwar dadurch, dass das Ganze eingebettet wurde und dann über die Ähnlichkeitssuche ermittelt wurde. Den Chunk und weitere Chunks hier hat er nun verwendet und GPT 4.0 eingesetzt, ihm mitgeteilt, dass er ein Assistent ist, der Fragen zu Dokumenten beantwortet, und diese drei Chunks angehängt sowie gefragt, was die Nullif-Funktion tut. Und was wir nun hier als Ergebnis erhalten: einen Überblick über die Nullif-Funktion, die Syntax, verschiedene Argumente, und er erklärt im Prinzip auch, was die Funktion tut, nämlich null zurückzugeben, wenn die Argumente gleich sind.

Und genau darauf zielt nun das erste Argument ab. Muss man eine solche Anwendung natürlich so gestalten, dass sie darauf beschränkt ist, wirklich nur auf das zu antworten, was sie aus den Chunks, aus dem Kontext herausfinden kann? LLMs verfügen ja auch über ein bestimmtes Basiswissen.

Das heißt, wenn ich jetzt etwas fragen würde, was nicht in dem Dokument steht, könnte es trotzdem sein, dass ich eine Antwort bekomme.

Andererseits gibt es natürlich mein gesamtes unternehmensinternes Wissen, mein gesamtes Wissen im Unternehmen, das natürlich nirgendwo öffentlich zugänglich ist – das kann ich mit einer solchen Anwendung eben der KI zur Verfügung stellen, und zwar sicher, wenn ich beispielsweise selbst gehostete KI-Modelle nutze und damit die Möglichkeit habe, genauso von der KI zu profitieren, ohne dass ich meine Daten irgendwo veröffentlichen muss. Ich teile wieder meinen Bildschirm. Ist der weg?

Okay, ich würde jetzt hier mal eine ganz kurze Pause einlegen und mir schon mal die Fragen ansehen, denn hier ist im Prinzip der Teil über die spezielle Vector Plate abgeschlossen. Danach wollen wir uns dann noch einmal ein wenig anschauen, wie das Ganze denn in das Gesamtbild der KI passt. Herr Dr.

Aspiazu fragt: „Werden DBS wie Informix durch die KI in Zukunft überflüssig?“ Ich denke, nein. Ich glaube, wir werden die Konsistenz und die Zuverlässigkeit von Datenbanksystemen noch viel stärker benötigen, aber ebenso die Möglichkeit, unter „Asset Properties“ mit dem Untermenü „High Zustimmung “ mit Daten zu arbeiten. Das heißt, Agenten werden Datenbanken nutzen, und wir brauchen genau diese Eigenschaften, die bereits über Jahrzehnte hinweg optimiert und erforscht wurden.

Genau die werden wir brauchen. Ich glaube, diese Rolle wird noch viel wichtiger werden, und es bleibt die zuverlässige Datenbasis. Zeigt der Kosinusabstand die Richtung eines Vektors an?

Die Richtung eines Vektors wird durch den Vektor selbst angegeben, also im Prinzip durch die Kombination aller Dimensionen. Der Kosinusabstand gibt den Winkel zwischen den beiden Vektoren an. Der Kosinus des Winkels ist also das Ergebnis des Kosinusabstands.

Wenn man sich also vorstellt, ein Vektor zeigt in diese Richtung und ein Vektor zeigt in jene Richtung, dann ist der Kosinusabstand genau der Kosinus des Winkels zwischen beiden. Das heißt, ein Vektor, der so zeigt, und ein Vektor, der so zeigt, aber viel länger ist – das haben wir eben gesehen –, hat den Kosinusabstand Null, weil der Winkel dazwischen einfach nicht existiert. Wie viel Platz nimmt allein dieses Beispiel aus dem Newsletter in den Spaces ein?

Das kann ich Ihnen so aus dem Stegreif nicht beantworten. Das müsste ich dann noch einmal nachschlagen. Herr Aspeato, Sie haben noch die Hand gehoben.

Möchten Sie noch eine Frage stellen? Okay. Ich würde erst einmal beim Thema bleiben.

Wir können am Ende gerne noch einmal Fragen beantworten. Wenn Sie derzeit im Unternehmensumfeld planen, solche Anwendungen zu entwickeln oder einzusetzen, stellt sich natürlich immer die Frage: Kann ich die Datenbank nutzen, die ich bereits habe, oder benötige ich eine separate Vektordatenbank? Und ich finde immer, dass es wichtig ist, diesen Unterschied deutlich zu machen.

Eine multimodale Datenbank wie HCL Informix eignet sich besonders gut, wenn man bereits über eine relationale Datenbank verfügt und diese ausprobieren möchte, um solche Anwendungen zu entwickeln; sie hat natürlich den Footprint oder die Größe eines vollwertigen Datenbanksystems. Das Ganze ist für relationale Workloads optimiert. Das bedeutet, dass man keine Abrufleistung im Bereich von wenigen Millisekunden erzielen wird.

Man kommt dem schon sehr nahe, aber ein großer Vorteil ist, dass man das Ganze einheitlich mit Asset-Eigenschaften speichert. Das heißt, man hat seine Vektordaten und seine relationalen Daten zusammen gespeichert und hat natürlich den Vorteil, dass es sich um ein einziges System handelt, das man warten muss. Würde man nun noch eine separate Vektordatenbank daneben stellen – es gibt verschiedene Datenbanken auf dem Markt –, dann hat diese Datenbank natürlich einen relativ geringen Speicherbedarf.

Ich kann das auch problemlos auf einem beliebigen Edge-Gerät bereitstellen und erhalte die optimale Geschwindigkeit für die Vektorsuche, muss beim Betrieb jedoch berücksichtigen, dass ich es mit verteilter Konsistenz zu tun habe. Das heißt, wenn ich davon ausgehe, dass ich ein Tupel in meine relationale Datenbank einfüge und gleichzeitig das Embedding in die Vektordatenbank einfüge, dann muss ich natürlich sicherstellen, dass dies unter „Asset Properties“ erfolgt, also entweder ganz oder gar nicht. Andernfalls ist eines der beiden Systeme nicht synchron.

Und ich muss natürlich auch die Wartung und die Verwaltung eines solchen verteilten Deployment s berücksichtigen. Das ist weitaus komplexer als ein einheitliches System. Und was ich vorhin bereits angesprochen habe, ist die hybride Suche, die eben sehr wichtig ist, weil sie in praktischen Anwendungen benötigt wird.

Das ist nämlich die Kombination aus Ähnlichkeitssuche und schlagwortbasierter Suche bzw. relationalen Filtern, die man bereits kennt. Ein einfaches Beispiel hierfür: Ich habe zwei Dokumente, Maschine A und Maschine B. Die eine kann ich ausschalten, indem ich den Stecker ziehe, die andere sollte ich ordnungsgemäß über die Schnittstelle herunterfahren.

Wenn ich nun als Nutzer die Frage stelle: „Wie fährt man die Maschine B herunter?“, dann kann es durchaus vorkommen – je nachdem, wie meine Anwendung aufgebaut ist –, dass ich beide Chunks erhalte, da diese natürlich beide passen, und die KI sagt mir dann, man könne den Stecker ziehen oder die Schnittstelle nutzen, da sie natürlich nur die Antwort aus dem Kontext generieren kann, die sie erhält. Wenn ich nun die hybride Suche verwende, kann ich natürlich durch die Stichwortsuche das Dokument für Maschine A ausschließen, erhalte nur das Dokument für Maschine B als Kontext, und damit kann mein LLM natürlich auch korrekt antworten. Das heißt, das ist ein großer Vorteil solcher Systeme wie eben Informix mit dem Vector Blade.

Ich kann weiterhin die relationale Suche nutzen und diese zusätzlich durch die Ähnlichkeitssuche erweitern. In unserer vorangegangenen Abfrage hätte ich auch sagen können, dass ich nur die IDs, die kleiner als drei oder kleiner als zwei sind, in meiner Ergebnismenge haben möchte. Okay, wie fügt sich das Ganze nun in das Gesamtbild ein und was tun wir bei HCL und Actian, damit wir das Ganze in einem größeren Kontext betrachten?

Der erste Punkt, auf den ich eingehen möchte, ist das Model Context Protocol, das sicherlich vielen von Ihnen bereits bekannt ist. Der Grund dafür ist einfach: LLMs verfügen nur über begrenztes Wissen. LLMs wurden zu einem bestimmten Zeitpunkt trainiert.

Ab diesem Zeitpunkt verfügen sie im Prinzip über kein neues Wissen mehr. Natürlich haben die Modelle, die wir derzeit über Dienste wie OpenAI nutzen, Zugriff auf neue Daten, auf das Internet und auf Live-Daten – aber wir möchten dem System natürlich Zugriff auf unsere Live-Daten im Unternehmen gewähren und ihm zudem die Möglichkeit geben, Aktionen auszuführen. Und das grundlegende Problem ist nun: Wie kann ich solche isolierten LLMs mit der Außenwelt verbinden und wie kann ich den Kontext verwalten?

Und was ich jetzt natürlich ganz einfach tun könnte, ist: Ich könnte eine Anwendung entwickeln und dann in diese Anwendung für jedes Tool, das ich einbinden möchte, den entsprechenden Treiber integrieren. Das heißt, den JDBC-Client meiner Datenbank, eine API meines E-Mail-Servers. Oder solche Dinge.

Das heißt, jede meiner Anwendungen müsste jede meiner Tool-APIs kennen. Ich erstelle also n mal m Integrationen. Das lässt sich eigentlich weder verwalten noch skalieren.

Die Lösung hierfür ist eine gemeinsame Sprache für diese Ebene, und genau das ist die Motivation für das Model Context Protocol. Man sagt, das sei der USB-C-Anschluss für KI-Anwendungen. Es handelt sich um einen Open-Source-Standard, der nun von Anthropic an die Linux Foundation übergeben wurde und somit wirklich der De-facto-Standard ist, der tool-spezifische APIs auf die generische API von MCP abbildet.

Da jeder Anbieter einen MCP-Server bereitstellt, kann ich damit beliebige Agenten und beliebige LLMs verbinden. Die Agenten haben dabei die Möglichkeit – das ist Teil des MCP-Standards –, die über den Server bereitgestellten Tools dynamisch zu erkennen. Das heißt, ich kann einen Agenten starten, der dann prüfen kann, welche Tools auf dem MCP-Server verfügbar sind, und anschließend für eine bestimmte Aufgabe die richtigen Tools auswählen, zum Beispiel eine SQL-Abfrage ausführen oder einen Konfigurationsparameter ändern.

Wir haben außerdem einen MCP-Server für HCL Informix bereitgestellt. Dieser ermöglicht es den Agenten, Entscheidungen auf der Grundlage der tatsächlichen Daten im System zu treffen, und reduziert so Fehlinterpretationen. Er gewährt Zugriff auf die Daten und auf die Metadaten.

Das heißt, wir ermöglichen damit einen sehr detaillierten Zugriff auf das Schema, die Geschäftslogik, also auch auf die Prozeduren und die Daten selbst. Es gibt Funktionen, es gibt Schemata, es gibt „Read SQL“, was eine einfache Leseabfrage der Daten darstellt. Unser Ansatz ist es, damit auch passive Agenten zu aktiven Nutzern zu machen.

Das heißt, wir werden Schreib- und Verwaltungswerkzeuge in diesen MCP-Server integrieren, der es den Agenten ermöglicht, Daten einzufügen, zu ändern und administrative Aufgaben am Datenbanksystem auszuführen. Darauf kommen wir später noch einmal zurück, wenn wir uns die Agenten-Roadmap ansehen. Das ist natürlich mit Vorsicht zu genießen.

Da muss man sehr vorsichtig sein, und da ist es eben auch wichtig, MCP als sichere Schicht zwischen der Agentenwelt und der Datenbankwelt zu haben. Denn nur das ist die Abstraktionsebene, die es wirklich ermöglicht, durch feinkörnige Zugriffs- und Governance-Mechanismen sowie sogenannte Guard Rails einzuschränken, was der Agent tatsächlich tun kann, und wirklich sicher zu sein, dass man die Systeme im operativen Betrieb nicht beeinträchtigt. Der zweite Punkt, den wir vorhin in der Einleitung angesprochen haben, sind dialogorientierte Analysen.

Eine ganz einfache Feststellung: Jede Zahl im Unternehmen hat eine Geschichte, und genau darauf kommt es letztendlich an. Wenn ich eine Frage stelle oder mir ein Dashboard e anschaue, bringe ich selbst einen bestimmten Kontext mit, um diese Zahl einordnen zu können. Stimmt die Anzahl der Kunden mit dem überein, was ich vermute, oder so?

Ein Mitarbeiter verfügt natürlich nicht über diesen Kontext. Das heißt, wenn ich einen Mitarbeiter frage: „Wie viel haben wir im letzten Quartal verdient?“, dann kann der Mitarbeiter alle vier Antworten geben, und jede dieser Antworten wäre eigentlich richtig. Nur eben für die jeweiligen Personen im Unternehmen.

Es ist also wichtig, einem Agenten für solche Analysen einen Kontext zu geben. Und genau hier liegt das Problem. LLMs sind nämlich probabilistisch.

Das heißt, ich kann dieselbe Anfrage auch zweimal stellen und erhalte zwei unterschiedliche Antworten, weil der Agent anhand meines Datenbankschemas entschieden hat, eine andere Anfrage zu stellen. Diese Antwort kann genauso richtig sein, passt aber eben nicht in den Kontext, in dem ich sie abfrage, weil ich beispielsweise aus der Finanzabteilung komme. Das Problem ist, dass große Sprachmodelle zwar sehr flexibel, aber – wie gesagt – unvorhersehbar sind.

Und die klassische Analytik ist natürlich zuverlässig. Wir kennen Dashboards und klassische BI, aber die sind sehr starr. Das heißt, wenn ich heute eine Anfrage stelle und wissen möchte, wie unsere Geschäftszahlen aussahen, muss ich möglicherweise erst das BI-Team fragen, das dann erst ein Dashboard erstellen muss.

Die Antwort erhalte ich vielleicht Ende der Woche. Die Lösung, die wir dafür entwickelt haben, ist der Actian AI Analyst. Er vereint die Vorteile beider Seiten.

Er ist flexibel und zuverlässig. Im Grunde handelt es sich um einen natürlich sprachlichen Agenten, der mir zuverlässige und reproduzierbare Antworten liefert, da er eben im geschäftlichen Kontext fundiert ist. Ein kurzer Überblick über diese Lösung, die wir entwickelt haben.

Wir können Geschäftsanfragen in natürlicher Sprache stellen und erhalten sofortige Analysen. Keine Dashboards, niemand muss SQL-Abfragen schreiben. Das bedeutet, dass jeder – auch technisch nicht versierte Personen – das System nutzen kann, um beispielsweise Einblicke in HCL- und Informix-Daten zu gewinnen.

Der KI-Analyst stützt sich dabei auf ein semantisches Modell. Dieses Modell umfasst alle Geschäftsdefinitionen sowie alle Kennzahlen, die ich freigegeben habe oder die jemand anderes freigegeben hat. Das heißt, dieses semantische Modell beschreibt im Grunde genommen meinen Datensatz und meine Datenbank.

Jede Antwort zeigt zudem deutlich, wie das Ergebnis zustande kommt. Das heißt, man sieht alle Schlussfolgerungsschritte, die der Agent unternommen hat, um die Anfrage zu bearbeiten. Man sieht die gestellte Anfrage, und der Agent lässt sich problemlos in die Tools integrieren, mit denen die Teams täglich arbeiten: in Slack, in Teams, im Webbrowser.

Das Interessante daran ist, dass ich das wirklich in wenigen Stunden umsetzen kann und in weniger als einer Minute Antworten auf meine Ergebnisse erhalte. Ein kurzer Einblick, wie das Ganze funktioniert. Wie schafft man es, dass solche Abfragen wirklich wiederholbar und korrekt sind?

Wir nehmen die Geschäftsanfrage entgegen, die wir erhalten. Wir lassen den Agenten loslegen. Der Agent erkennt die Absicht, beschreibt oder erstellt eine Vorlage für eine Anfrage, darf jedoch keine endgültige SQL-Abfrage stellen.

Diese Vorlage wird dann durch diese semantische Ebene geleitet, die alle Geschäftsinformationen enthält, und dort werden die Platzhalter durch die tatsächlichen Definitionen ersetzt. Das heißt, wenn ich frage: „Wie viele aktive Kunden haben wir?“, dann wird dieser Platzhalter für „aktive Kunden“ durch die tatsächliche Definition ersetzt. Die Abfrage wird dann im Lesemodus ausgeführt.

Die Daten bleiben also in der Datenbank. Ich erhalte nur das Ergebnis und bekomme am Ende eine verlässliche Antwort. Man könnte nun natürlich einwenden, dass dies das Problem im Grunde genommen auf die Erstellung dieser semantischen Ebene als eigentliche Wahrheitsquelle verlagert.

Und auch dafür haben wir einen Agenten, den Steward-Agenten, der diese semantische Schicht aufbaut, pflegt und überwacht. Dieser Agent nimmt also Dokumentationen, Confluence-Seiten und alles, wo meine Geschäftslogik erklärt ist, integriert diese in die semantische Schicht und verfügt über eine Rückkopplungsschleife, sodass er jedes Mal, wenn ich eine Anfrage stelle und mit dem Agenten interagiere, Informationen daraus extrahiert und diese semantische Schicht im Laufe der Zeit verbessert. Der AI Analyst ist eine Möglichkeit, um mit Informix letztendlich wirklich in natürlicher Sprache zu kommunizieren.

Und als letzten Punkt für heute: Schauen wir uns noch einmal an, wohin die Entwicklung im Bereich der agentenbasierten KI geht. Zunächst ganz kurz zum Unterschied zwischen agentenbasierter KI und herkömmlichen Anwendungen. Wie ich bereits zu Beginn gesagt habe: Einer der wichtigsten Punkte bei der agentenbasierten KI ist, dass das Ganze zielorientiert ist.

Der Nutzer kann zwar noch das Ziel vorgeben, muss aber nicht mehr wissen, wie der Weg funktioniert. Wie gerade im Beispiel: Ich kann eine Frage stellen, ich kann das Ziel vorgeben und angeben, welche Antwort ich haben möchte. Ich muss aber nicht mehr in der Lage sein, die entsprechende SQL-Abfrage zu stellen.

Agenten durchlaufen eine Planungsphase. Das heißt, sie gliedern die Aufgaben auf, planen eigenständig und verfügen über eine Rückkopplungsschleife, um das Ganze während der Ausführung noch einmal anzupassen, je nachdem, wie erfolgreich die ersten Schritte waren. Sie verfügen über einen Kontext und ein Gedächtnis.

Das heißt, wenn ich bestimmte Aufgaben bereits einmal erledigt habe, kann er sich das Ganze auch im Kurzzeit- und im Langzeitgedächtnis merken, um sich kontinuierlich zu verbessern. Das heißt, ein Agent kann im Laufe der Zeit auch zu meinem persönlichen Assistenten werden, indem er weiß, was ich bevorzuge, wie ich meine Aufgaben erledige und so weiter. Und hier kommt MCP ins Spiel.

Agenten können Tools nutzen. Das heißt, ein Agent kann über MCP eigenständig auf externe Systeme zugreifen, wobei die Sicherheitsmechanismen des MCP-Servers sowie die Einschränkungen und Sicherheitsmechanismen zum Tragen kommen. Und nun kann man sich das einmal überlegen.

Das ist sozusagen eine Inspiration, wenn Sie im Unternehmen verschiedene Agenten mit dem MCP-Server und mit Informix erstellen möchten. Solche Anwendungsfälle gibt es eigentlich über den gesamten Datenlebenszyklus hinweg. Bei der Datenerfassung kann man sagen, dass Agenten eigentlich als Operatoren fungieren.

Das heißt, ich kann Mitarbeiter für die Datenerfassung einsetzen. Ich kann meinen Mitarbeiter telefonisch anrufen und sagen, dass ich gerade von einem Kundengespräch komme. Das sind die Informationen, die ich mitgebracht habe.

Bitte füge das mal in meine Lead-Datenbank ein. Ich kann einen Agenten für die Datenmigration erstellen, der Daten automatisch aus einer Datenbank in meine interne Datenbank überträgt. Im Hinblick auf das Datenmanagement kann man sagen, dass Agenten eigentlich als Kuratoren fungieren.

Das heißt, ich kann die Datenqualität überprüfen und die Daten automatisch anreichern. Ich kann die Herkunft der Daten nachverfolgen. Das heißt, gerade im Zeitalter der KI ist es sehr wichtig: Woher stammen meine Messdaten?

Woher stammen meine Daten? Wie wir gerade gesehen haben, fungieren die Agenten bei der Datennutzung eigentlich als Analysten. Das heißt, ich kann natürlich sprachliche Anfragen stellen.

Ich kann aber auch einen Agenten für die Erstellung von „ Dashboard “ oder sogar für multimodale Anfragen entwickeln. Das heißt, mein Agent könnte eine Kombination aus Dokumenten, E-Mails, Bildern und relationalen Daten abfragen und daraus eine Antwort erstellen. Da sind viele Möglichkeiten gegeben.

Und einer der größten Schwachpunkte ist natürlich die Datenbankadministration. Agenten fungieren als Administratoren. Sie können helfen oder sogar bestimmte Aufgaben übernehmen, zum Beispiel ein System Health Agent, der mein System rund um die Uhr überprüft und bereits proaktiv auf Probleme hinweist oder diese sogar schon behebt.

Oder Datenbank-Tuning. Wir wissen alle, dass ein System Hunderte von Tuning-Einstellungen hat. Das Schema, die Konfiguration – all das lässt sich optimieren, und ein Agent kann dabei helfen, das Ganze an den Workload , anzupassen.

Das Ganze als Inspiration dafür, was man daraus umsetzen kann. Wie könnte so etwas aussehen, was man normalerweise macht? Man hat hier seine Nutzer-Datenbank.

Natürlich gibt es für die „ Nutzer “-Datenbank einen MCP-Server, sodass der Agent dort auch sicher darauf zugreifen kann. Und ich habe in irgendeiner Form Telemetriedaten oder Protokolle, die ich aus dem System auslese. Und was ich tun sollte, wenn ich eine solche Anwendung entwickle: Ich sollte das Ganze in eine Metrik-Datenbank schreiben, damit ich den laufenden Betrieb des Systems eben nicht störe, wenn ich diese Metriken mit Agenten abfrage.

Der Agent hat nun Zugriff auf die Daten, die Protokolle oder die Telemetriedaten. Das bedeutet, dass er beispielsweise auch weiß, wie hoch der Speicherverbrauch ist, und dadurch nun Entscheidungen treffen kann. Was ein solcher Agent für das Reasoning benötigt, ist ein Large Language Model.

Das kann ich jetzt relativ naiv umsetzen, indem ich das Ganze einfach an OpenAI oder an Tropic sende und dabei ein öffentlich gehostetes Modell verwende. Oder ich möchte die Kontrolle behalten und ein privates Modell nutzen, das ich bei mir in-house hoste. In jedem Fall sollte man eine Proxy-Schicht dazwischen schalten, die das Ganze abstrahiert und darüber hinaus weitere Sicherheitsvorkehrungen implementiert.

Einfach ausgedrückt: Genau das haben wir auch vor, wenn wir vorgefertigte Agenten entwickeln – und zwar für alle unsere Datenbanksysteme. Wir werden eine solche Proxy-Schicht dazwischen schalten. Diese verfügt über eine Laufzeitumgebung für lokale Modelle, kann optional mit einem öffentlichen Modell verbunden werden und bietet all die Sicherheitsvorkehrungen, die für Unternehmen wichtig sind.

Das ist also die Kontrollschicht zwischen meinem Agenten und den öffentlichen Modellen, zum Beispiel Sicherheit und Verschlüsselung, aber auch Auditing. Das heißt, jede Anfrage muss protokolliert werden. Ich möchte sehen, wie viele Token verbraucht werden.

Ich kann ein Budget erstellen und personenbezogene Daten erkennen und maskieren, bevor diese tatsächlich an die öffentlichen Modelle weitergeleitet werden. Und kurz zum Zeitplan: Was wir bereits im April veröffentlicht haben, ist die Version 1 des MCP-Servers. Das war der sichere Einstieg mit Authentifizierung und Lesezugriff.

Wir haben vor anderthalb oder zwei Wochen die Version 1.1 veröffentlicht. Damit lässt sich das Ganze bereits im operativen Einsatz nutzen. Das heißt, es gibt hier bereits die ersten Sicherheitsvorkehrungen.

Wir haben die Protokollierung integriert und ermöglichen Schreibvorgänge mit „Human in the Loop“, und das Ganze wird in der nächsten Version durch Admin-Tools und verschiedene Orchestrierungsfunktionen noch weiter ausgebaut. Parallel dazu arbeiten wir an Agenten. Das heißt, Agenten für die Datenbankverwaltung werden gegen Jahresende im Early Access verfügbar sein.

Was uns dabei wichtig ist – und ich habe es vorhin bereits kurz angesprochen: Wir sprechen hier über die Systeme, die im Grunde das Herzstück all unserer Unternehmen bilden. Da sollte man nicht leichtfertig mit Agenten darauf arbeiten und riskieren, dass Daten verloren gehen, dass Systeme kompromittiert werden und so weiter. Das heißt, wir stellen Zuverlässigkeit über den Hype.

Wir möchten sicher wachsen. Das heißt, wir möchten schrittweise Anwendungsfälle ermöglichen – mit der Sicherheit, die wir benötigen, um dies wirklich zuverlässig zu tun. Wir wollen die volle Kontrolle über die Nutzung der KI und vor allem Souveränität.

Das heißt, es ist immer möglich, eigene Modelle zu hosten und die volle Kontrolle zu behalten – für jeden, der unabhängig von globalen Modellen sein möchte. Wir versuchen, so wenig wie möglich in die Produktionsumgebung einzugreifen. Wie ich gerade gesagt habe: Eigentlich ist es nicht akzeptabel, dass diese Anwendungen den laufenden Betrieb stören, und die Autonomie wird konfigurierbar sein.

Das heißt, ein solcher Agent kann Vorschläge unterbreiten, die ich als Nutzer selbst umsetze. Über „Human in the Loop“ kann er Vorschläge machen, die ich nur noch genehmigen muss, oder Systeme können auch künstlich autonom arbeiten. Das ist sozusagen die Roadmap, die zeigt, wohin es geht und wohin wir uns vorsichtig, aber sicher entwickeln wollen.

Okay, hier noch einmal als Zusammenfassung die wichtigsten Erkenntnisse von heute: HCL Informix wird KI-fähig. KI ist dort zu Hause, wo bereits die Daten sind, denn wir verfügen über den nativen Vektordatentyp und über MCP. Wir haben gesehen, dass man mit seinen Daten „sprechen“ kann und dass es Lösungen gibt, um den Zugriff in natürlicher Sprache zu ermöglichen.

Und wir haben gesehen, was die Zukunft bringen wird. Agentbasierte Tools werden die Arbeit vereinfachen und verbessern – wie wir mit unseren Systemen arbeiten, wie wir sie konfigurieren und wie wir sie verwalten. Okay, und damit kommen wir zum Schlusswort: HCL Informix ist bereit für Ihre KI-Anwendungsfälle, und wir stehen gerne für weitere Diskussionen und Fragen zur Verfügung.

Okay. Könnten verschiedene Personen mit ihren natürlichsprachlichen und ähnlichen Anfragen unterschiedliche Ergebnisse erhalten? Genau, das kann passieren.

Genau das habe ich auf der Folie mit den verschiedenen Antworten verdeutlicht. Dieser KI-Analyst kennt meine Rolle als Nutzer. Ich kann verschiedene Nutzer anlegen, die unterschiedliche Rollen haben.

Das System weiß also, dass ich aus der Finanzabteilung komme, wie ich in meiner Abteilung beispielsweise einen aktiven Kunden definiere, und mit derselben Anfrage kann jemand anderes ein anderes Ergebnis erhalten, je nach der Metrikdefinition, die in diesem Kontext richtig ist. Das Ganze ist rollenbasiert, und dadurch erhalte ich immer den richtigen Kontext. Werden Kurz- und Langzeitgedächtnis zwischen verschiedenen Benutzern geteilt?

Nein, das ist sehr wichtig, denn das kann natürlich auch für Caching-Mechanismen, also das Zwischenspeichern von Anfragen, gelten – das ist natürlich ein sehr wichtiger Einfallstor für Datenlecks oder Sicherheitsprobleme. Nein, das Ganze wird nicht aufgeteilt. Sind Kurzzeitgedächtnis und Langzeitwissen austauschbar?

Was wird beim Auditing protokolliert und wie hoch ist der Datenbedarf? Wo werden die Auditdaten außerhalb der Instanz oder im Dateisystem gespeichert? Dafür gibt es nun zwei Kontexte.

Außerdem kann ich das Kurzzeitgedächtnis und das Langzeitwissen konfigurieren. Ich kann eine Systemabfrage im Kontext des AI Analyst anpassen. Damit kann ich auch das Verhalten meines Agenten konfigurieren und einsehen, was er derzeit in seinem Speicher gespeichert hat, und dies ebenfalls konfigurieren.

Was wird beim Auditing protokolliert und wie hoch ist der Datenbedarf? Derzeit wird das Ganze bei uns in einer Datenbank protokolliert. Wenn man nun natürlich einen generischen Agenten entwickelt, wie bei dieser Referenzarchitektur, die ich gerade gezeigt habe, kann man dort ein beliebiges System anbinden.

In der Regel handelt es sich dabei um ein operatives Datenbanksystem oder ein NoSQL-System, in das diese Protokolle dann sehr häufig eingelesen werden. Und wie hoch der Datenbedarf dafür ist, hängt natürlich davon ab, wie lange ich gemäß den gesetzlichen Vorschriften möglicherweise eine Aufbewahrungspflicht habe. Wenn ich also ein System aufbaue und alles 30 Tage lang auditierbar aufbewahren muss, dann muss ich die Daten eben so lange speichern.

Danach kann ich das wahrscheinlich archivieren. Und noch eine Zusatzfrage: Gilt das auch bei gleichen Rollen? Nein, wenn ich dieselbe Rolle habe, kann ich über dieses System entwerfen.

Genau das ist der Unterschied zwischen einem reinen LLM, das mir auf dieselbe Anfrage verschiedene Antworten geben kann, und unserem System, das durch diese schrittweise Übersetzung, durch diese zweistufige Übersetzung, genau dieses Problem löst. Okay, unsere Zeit ist um. Ich weiß nicht, warum ich kurz draußen war.

Ich bedanke mich auf jeden Fall für Ihre Aufmerksamkeit und würde mich auch freuen, wenn wir uns bei einer Veranstaltung noch einmal unterhalten könnten – oder gerne auch per E-Mail, falls noch Fragen offen sind. Und damit verabschiede ich mich und wünsche Ihnen einen schönen Abend. Vielen Dank für das Feedback.