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

So, okay. Herzlich willkommen zum Webinar zum Thema HCL Informix und dem Vector Blade. Mein Name ist Steffen Kleber, ich bin Chief Researcher bei Action, bin mittlerweile seit über neun Jahren bei der Firma und bin verantwortlich für unsere Datenbanksysteme, Strategie und KI-Initiativen in den Systemen.

Worüber wir heute reden wollen, ist zum einen natürlich das Vector Blade, die Extension für HCL Informix, die es ermöglicht, Vektordaten abzufragen und mit Vektordaten zu arbeiten, aber auch ein bisschen das größere Bild: Wie passt Informix in die KI-Landschaft heute? Bevor wir in die Details gehen, möchte ich über Trends reden 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 machen können.

Das heißt, traditionell hat man mit strukturierten Daten gearbeitet. Man hatte Tabellen, feste Schemas, hat das mit relationalen Datenbanken gemacht. KI ermöglicht jetzt aber die Verarbeitung von unstrukturierten Daten, das heißt Texten, Bildern, Videos, Audio und das auch in Kombination.

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

Und das macht es eben sehr attraktiv im Unternehmensumfeld, weil es gibt verschiedene Studien, das hat 1998 schon mit dem ersten Report angefangen, ist aber auch durch aktuelle Berichte von Gartner und IDC bestätigt, dass eigentlich 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 Value aus den Daten auch zu ziehen. Auf der anderen Seite ändert KI natürlich den Weg oder den Umgang mit Daten.

Wir haben natürlich vor dem KI-Zeitalter hauptsächlich manuell damit gearbeitet. Das heißt, wir haben Pipelines verwaltet, Pipelines aufgebaut, wir haben Schema gemanagt, wir haben Daten händisch bereinigt, Datenfehler gesucht, wir haben Systeme administriert, Reporting-Strukturen aufgebaut, all das manuell. Als erster Schritt, der durch KI hinzugekommen ist, ist, dass das Ganze jetzt dialogorientiert passieren kann.

Das heißt, wir können natürlich sprachlich anfragen, 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 es potenziell gibt, welche Optimierungsmöglichkeiten. Und das ermöglicht einfach einen sehr einfachen Zugang zu diesen Systemen, auch für Menschen, die vielleicht wenig oder keinen technischen Hintergrund haben.

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

Wo wir hingehen im KI-Zeitalter, sind autonome Agenten. Das heißt, die sind zielgesteuert. Ich muss also als Mensch nicht mehr wissen, was eigentlich das Ziel oder der Weg dahin ist, sondern ich kann Agenten autonom arbeiten lassen.

Sie entdecken autonom Probleme, sie planen und führen Lösungen dafür aus und das ermöglicht eben eine Wartung von Systemen rund um die Uhr, automatisierte Abfragen, vielleicht entdecken Agenten auch Strukturen oder Probleme in Daten, die man als Mensch gar nicht gefunden hätte. Wir haben eben diese beiden Sachen. Zum einen ermöglicht KI, mehr Daten zu verarbeiten, ermöglicht uns aber auch, einen ganz anderen Umgang mit Daten zu haben.

Da stellt sich dann natürlich die Frage: Sind Datenbanken eigentlich noch relevant? Und das ist eine der Hauptmessages, die wir heute rüberbringen wollen. Relationale Datenbanken sind immer noch sehr wichtig, sind immer noch das verlässliche Fundament, auf dem KI und Agenten aufbauen.

Das sollte man nicht vergessen. Datenbanken sind vertrauenswürdig per Design. Wir kennen alle die ACID-Eigenschaften und das ist gerade im Agenten-Zeitalter wichtig, dass Agenten auf konsistenten Daten arbeiten und als Single Source of Truth.

Das heißt, ich habe ein System, was meinen Datenstand hält, konsistent und mit Qualität und nicht verteilt über verschiedene Ordnerstrukturen und so weiter. Als Anekdote: Ich hatte ein Webinar von Antropic zum Beispiel gesehen, die überlegen, wie Agenten zusammen auf Files arbeiten können. Das sind Probleme, die die Datenbankenwelt schon seit Jahrzehnten gelöst hat.

Concurrency und Multi-User-Anwendung. Besonders eignet sich für so etwas Informix, denn Informix ist multimodal, ist erweiterbar. Das heißt, Informix kann verschiedene Datentypen speichern, nicht nur strukturierte Daten.

Mit dem Vector Blade, worum 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. Und außerdem verändern Agenten ein bisschen den Workload, den wir auf Systeme feuern. Agenten fragen viel mehr repetitive Anfragen mit hoher Concurrency und da zahlt sich eben die Jahrzehnte der Query-Optimierung und der Sicherheit von Datenbanksystemen aus, um solche Agentenabfragen schnell und sicher zu halten.

Also Datenbanken heute immer noch sehr relevant und besonders relevant für Agenten. Als wichtige Erkenntnisse, die wir heute Ihnen mitgeben wollen: HCL Informix wird AI ready. Wir können also KI dort machen, wo die Daten schon leben.

Das wird ermöglicht durch den nativen Vektordatentyp und durch MCP. Außerdem schauen wir uns natürlich sprachliche Schnittstellen an, die es ermöglichen, mit Daten zu reden und wir schauen uns an, wo die Zukunft hingeht. Agentische Werkzeuge, die eben ermöglichen, vereinfacht mit dem System zu arbeiten und Unterstützung zur Administration zu haben.

Okay, kommen wir zuerst einmal auf das Vector Blade. Als Kontext dazu ist dieses Pattern der RAG-Systeme, Retrieval Augmented Generation, eigentlich relativ bekannt. Als kurzer Kontext möchte ich hier noch einmal trotzdem darauf eingehen.

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

Wir zerlegen diese Daten in Chunks mit einem Chunking-Mechanismus und was dann passiert, ist, wir betten die in einen Vector Space ein. Das heißt, wir benutzen ein Embedding-Modell, das mappt im Prinzip diese Chunks auf einen hochdimensionalen Space und jeder dieser Chunks wird ein Punkt in diesem Raum. 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, relevante Chunks wieder abzufragen, die an ein Modell zu geben und damit eben auch Antworten zu kriegen, die in den Daten beruhen, die wir eigentlich nicht speichern.

Also in dem proprietären Wissen von dem Unternehmen. Mit dem HCL Informix Vector Blade kriegen wir das jetzt nativ in Informix. Das heißt, wir haben eine integrierte Komponente des Datenbankservers.

Die liegen direkt neben den relationalen Daten. Ich brauche also kein zusätzliches System, um meine Embeddings und Vektordaten zu verwalten und brauche damit eben auch keine zusätzliche Konnektivität oder Sicherheitskonfiguration. Ich kann das Ganze über das gleiche gewohnte SQL-Interface anfragen, das ich schon habe.

Das Ganze ist isoliert und skalierbar. Wir haben das Informix Vector Blade so gebaut, dass die Routinen da drinnen in einer eigenen VP-Klasse, die heißt LVec, laufen. Das heißt, alle Operationen, alle Threads, die für das Vector Blade benutzt werden, die beeinträchtigen nicht die bestehenden Threads des operationalen Datenbanksystems.

Also die Verlässlichkeit, die wir ja brauchen für so ein Datenbanksystem, 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, wir würden jetzt in der Anwendungsschicht darüber die Pipeline bauen. Dokumente werden in Chunks zerlegt, sie werden mit einem Embedding-Modell eingebettet und zu Vektoren konvertiert und die werden dann zusätzlich in das Blade in der Datenbank geschrieben.

Das ist jetzt ein wichtiges Takeaway, das wir verstehen müssen. Informix und das Vector Blade sind dafür da, diese Chunks oder diese Vektoren abzufragen und zu speichern. Der Rest passiert in der Anwendungsschicht.

Der Rest ist typischerweise anwendungsspezifisch. Also wie chunke ich meine Daten, welche Daten habe ich überhaupt? Informix mit dem Vector Blade kann aber mit der Granularität der Vektoren am Ende umgehen.

Das heißt, ich schreibe meine Vektoren dann in die Datenbank, in das 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 Keywords werden ausgewählt. Die werden wieder durch das gleiche Embedding-Modell geleitet, sodass ich wieder einen Vektor kriege, der meine Fragen beschreibt und dann kann ich eine Ähnlichkeitssuche machen.

Ähnlichkeitssuche bedeutet, ich schaue mir meinen hochdimensionalen Raum an und suche die Punkte in diesem Raum, die zu meinem Vektor, der meiner Frage entspricht, besonders nahe ist. Also ich kann Ähnlichkeitsmaße in dem Vektorraum benutzen, um zu schauen, welche Chunks, welche Vektoren passen denn am besten zu meiner Frage. Ich kriege dann diese relevanten Chunks vom Vector Blade zurückgegeben und kann die dann als Kontext zu meinem LLM geben, um darauf dann eine Antwort zu kriegen auf meine Frage.

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

Wir sehen hier noch mal alle Datenbankaufgaben, die es bisher gibt. Die sind isoliert von dem Vector Blade. Im Blade kann ich Vektoren einfügen, Vektoren abfragen und sogar Vektoren verändern.

Das heißt, wir unterstützen auch Modification Operations. Wie kann ich jetzt damit beginnen? Zunächst mal muss ich das Blade installieren, im Informix Directory, im Extend Directory.

Wir bringen ein Bild, ein Embedding-Modell mit. Das heißt, wir haben schon eine Funktion. Ich komme später bei den wichtigen Funktionen noch mal darauf.

Wir haben eine Funktion, die es erleichtert, Text umzuwandeln in Vector Embeddings. Wir müssen also nicht in der Anwendungsschicht zwangsläufig das Ganze bauen. Wir kommen mit einem Embedding-Modell, was einfach dafür sorgt, dass man einfach starten kann und ausprobieren kann.

Und das Ganze setzt auf OpenAI und um das zu benutzen, kann man über die Umgebungsvariable hier einen OpenAI-Key setzen und der wird dann benutzt, um ein Embedding-Modell aufzurufen. Anschließend kann ich das Blade dann in der Datenbank registrieren und es kommen auch eine ganze Menge Beispiele mitgeliefert, sodass ich direkt anfangen kann, das Ganze zu benutzen. Ich möchte über die wichtigen Funktionen gehen, die schon vordefiniert kommen.

Was man jetzt verstehen muss, ist, dass das Vector Blade im Prinzip dadurch, dass es separat läuft, die Embeddings noch mal separat speichert. Es gibt, was hier notiert ist als Lens Table Name, die Tabellen in dem Vector Blade und es gibt Tabellen im Informix Tabellenformat. Im Informix Tabellenformat werden die Embeddings gespeichert, aber abfragbar werden sie über diese Lens Tabelle.

Das heißt, ich kann hier mit der Funktion L Vector Create Table eine Lens Tabelle anlegen. Was ich angeben muss, ist die Anzahl der Dimensionen für meine Vektoren. Das bestimmt einfach dadurch, welches Embedding Modell ich benutze.

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

Hier ein Beispiel: Ich kann eine einfache Demo-Tabelle anlegen mit drei Dimensionen. Genauso kann ich eine Tabelle natürlich auch wieder löschen mit einem Drop Table durch die Angabe des Tabellennamens. Und um Daten jetzt da reinzukriegen, habe ich zum einen die Möglichkeit, ein sogenanntes Sync Insert auszuführen, gebe die Tabellenname an und dann hat so eine 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 Metadata kann auch jeglicher String sein. Könnte ich zum Beispiel also auch als JSON formatiertes Dokument machen.

Genauso kann ich über die ID solche Tupel auch wieder löschen, also über einen Sync Delete. Und um das Ganze dann richtig flott zu machen im Retrieval, gibt es Indexstrukturen. Indexstrukturen kennt man aus Datenbanken schon immer.

Ich tausche im Prinzip Updatefähigkeit gegen Retrieval oder Anfragegeschwindigkeit. Wenn ich einen Index habe, ist die Anfrage typischerweise schneller. Das gilt schon immer für B-Trees und so weiter.

Wenn ich aber neue Tupel hinzufüge, muss ich den Index eben auch updaten. Was ich hier also machen kann, ich gebe den Tabellenname an, ich gebe den Indextyp an, dazu offen ich später noch mal mehr, und die Anzahl der Partition für den Index. Das ist ein Tuningparameter für die Performance.

Und damit wird der Index automatisch auf der Vektorspalte angelegt. Und dann die wichtigste Funktion, L Vector Search. Das ist die, wo ich dann meinen Retrieval mit umsetzen kann.

Ich gebe wieder den Tabellennamen an und den Suchvektor. Also das ist der Vektor, den ich kriege, wenn ich aus meiner Frage mit einem Embedding Modell einen Vektor generiere, dann ist das praktisch der Punkt in meinem Vektorraum, den ich suche. Und jetzt schaut das Vector Blade durch diese Similarity Search um diesen Punkt: Was sind die nächsten Punkte?

Jetzt kann ich hier angeben, wie viele Nachbarn ich haben will. Auch das ist ein Tuningparameter und ein bisschen applikationsabhängig. Typischerweise sucht man einen Kontext von zwischen drei und zehn Chunks, die man haben will, die man dann als Kontext für sein LLM geben will.

Das ist die Embedding-Funktion, die ich eben angesprochen habe, die es ermöglicht, so ein Embedding relativ einfach zu berechnen, wenn ich einen OpenAI Key mitbringe und den in der Umgebungsvariable gesetzt habe. Ganz einfacher Aufruf: Ich gebe einen String rein und die Prozedur gibt dann einen Vektor zurück. Und das Coole ist jetzt, dass ich das Ganze auch kombinieren kann.

Ich kann also einen Insert machen, gebe die Tabelle an, ich gebe die ID an und ich kann anstelle des Vektors diese Embedding-Funktion aufrufen, um eben direkt das Embedding zu berechnen, ohne dass ich das jetzt per Hand machen muss. Es gibt noch eine andere Gruppe an vordefinierten Funktionen. Es gibt eine Distanzfunktion, das heißt, ich kann händisch Distanzen ausrechnen.

Das ist das, worauf am Ende auch die Search-Funktion basiert. Ich kann Vektoren miteinander vergleichen. Ich kann einen Search mit einem zusätzlichen Filter machen.

Das ist sehr interessant. Das heißt, ich kann auf den Metadaten einfache Primitive noch abfragen. Beispielsweise ein bestimmtes Schlüsselwort ist enthalten oder ein bestimmter Key ist erfüllt.

Ich komme später noch mal auf die Wichtigkeit der eben Suche. Gerade im Unternehmensumfeld ist das wichtig. Typischerweise suche ich unter bestimmten Randbedingungen und nicht über meine gesamte Datenbasis.

Und dann gibt es die Bulk Sync Operation, die ermöglicht es mir, aus meiner Informix Tabelle, wenn ich da Vektoren eingefügt habe oder wenn die Tabelle schon existiert, dann kann ich einmal im großen Bulk, im Paket, alle meine Vektoren synchronisieren mit der Vektortabelle im Vector Blade. Es gibt eine Reihe unterstützter Indextypen. Das sind, wenn man sich Wenn man in dem Vector Space ein bisschen liest, sind das die gängigen Typen.

Es gibt einen Flat Index, der macht eigentlich die exakte Suche. Das heißt, da kriege ich wirklich 100% Präzision. Es gibt Quantisierung, das komprimiert im Prinzip die Vektorrepräsentation.

Damit kriege ich typischerweise relativ ungenaue Ergebnisse, aber sehr schnell. Und es gibt den HNSW, also einen Baumindex, Hierarchical Navigable Small World Index. Wie ein typischer Baum, er geht grob granular rein, sucht den ersten Nachbarn und geht dann von diesem Nachbar aus weiter und schaut feingranularer.

Es gibt verschiedene Indextypen, die man evaluieren kann. Wie immer, ein Index ist im Prinzip ein Trade-off zwischen Geschwindigkeit und Präzision. Wenn ich 100% Präzision brauche, dann sollte ich den Flat Index nehmen.

Wenn ich aber akzeptiere, dass unter meinen zehn Ergebnissen auch ein unrelevantes Ergebnis ist, dann kann ich auch so einen HNSW Index nehmen.

Okay, kommen wir zur Demo. Ich habe zwei Sachen vorbereitet. Zum einen habe ich vorbereitet, dass wir das Ganze einmal wirklich Hands on in der Konsole ausprobieren.

Eine Sekunde. Ich teile meinen Bildschirm wieder. Zoomen wir noch ein bisschen rein.

Ich hoffe, man kann das gut erkennen. Wir gehen jetzt hier wieder in eine Datenbank, wir legen uns eine Testdatenbank ein. Und was wir jetzt tun können: Wir können das mal rumspielen mit den Funktionen, die schon da sind.

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

Hier in dem Fall 15. Und dann gibt es weitere Distanzmaße, zum Beispiel die Kosinusdistanz. Und hier sehen wir jetzt, dass hier die Distanz null ist, denn die Kosinusdistanz geht nicht auf die eigentliche Distanz, sondern auf die Richtung.

Was wichtig ist bei solchen Retrievals, ist, dass eigentlich die Richtung relevant ist und nicht die Länge des Vektors. Wir sehen, 111 und 101010 punkten genau in die gleiche Richtung. Das heißt, sie sagen sehr wahrscheinlich auch nach dem Embedding-Modell oder so wie die Embedding-Modelle gebaut sind, das Gleiche aus.

Das heißt, hier ist die Distanz null. Die sind also sehr ähnlich. Kosinusdistanz benutzt man typischerweise für die Ähnlichkeitssuchen.

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

Das ist einmal null mit der -100, -100, -100. Ein Beispiel-String. Und genauso kann ich jetzt auch zwei weitere Tupel einfügen.

Und was ich jetzt tun kann, ist, ich benutze jetzt diese LVector-Funktion, um eine neue Tabelle in dem Vector Blade anzulegen. Also LVector Create Table, nenne die Table eins, Dimension drei, denn die Vektoren in dieser Tabelle haben die Dimension drei. Sollen nämlich genau die sein, die ich in der Informix-Tabelle schon einmal eingefügt habe.

Und was ich jetzt tue, ist, ich benutze die Bulk Sync-Funktion, wie vorhin eingeführt. 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 jetzt dabei, alle die Vektoren, die schon in der Informix-Tabelle enthalten sind, einmal zu synchronisieren mit meiner Vector-Blade-Tabelle.

Und was ich jetzt tun kann, ist, ich kann eine ganz normale SQL-Anfrage machen und die können wir uns jetzt mal genauer anschauen. Ich habe zwei Tabellen hier drinnen. Ich habe die Informix-Tabelle und ich habe die Vector-Blade-Tabelle.

Benutze jetzt also die Search-Funktion nach einem Search Vektor, 222 in diesem Fall. Das ist der, der aus dem Embedding-Modell meiner Frage kommt. Ich sage, ich möchte drei Nachbarn haben und nach Kosinusdistanz berechnet.

Ich caste das auf den Typ LVector Search Result. Das ist eben genau diese Struktur aus ID, Vektor und Metadatenfeld. Und was ich jetzt tun muss, ist, ich muss diese beiden Tabellen joinen.

Ich nehme also die Vector ID meiner Informix-Tabelle und ich nehme die ID-Spalte meiner Search-Tabelle aus meinem Vector Blade und joine die ganze und ordere das Ganze nach der Distanz, die aus der Ähnlichkeitssuche herauskommt. Wenn ich das Ganze jetzt ausführe, dann sehe ich eben, dass 222 am nächsten am 101010 lag nach der Kosinusdistanz. Das ist genau das Beispiel, was wir vorhin auch hatten.

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, die liegen sich genau gegenüber, die zeigen genau in entgegengesetzte Richtung.

Macht Sinn. Das ist also die Query-Konstruktion, die ich am Ende machen kann, um wirklich über eine einzelne SQL-Anfrage eine Vektordistanz auszurechnen. Und jetzt habe ich natürlich die Möglichkeit, alle Daten, die in meiner Informix-Tabelle drinnen stehen, ich kriege über diese ID die Nachbarn heraus und jetzt kann ich alle Spalten, die ich in meiner Informix-Tabelle habe, egal ob das zusätzliche Stringdaten sind, ob das Integerdaten sind, mitbenutzen, mit als Kontext in meinen LLM geben und kriege damit eben den Kontext, den ich zur Beantwortung meiner Frage brauche.

Das Ganze kann man jetzt, wie ich vorhin schon gesagt habe, viel Logik passiert eigentlich auf der Applikationsebene. Das heißt, wir haben hier auch eine kleine Demoapplikation, in der man das mal Ende zu Ende zeigen kann. Ich teile wieder meinen Bildschirm und bin noch am Suchen.

Das ist eine Demoapplikation, die wir intern für Demozwecke entwickelt haben. Was wir hier tun können, ist, ich kann mit Dokumenten checken. Das heißt, ich kann über „Upload Document“, Dokumente auswählen, die ich dann hochlade.

Und ich habe mir jetzt mal den Informix-Newsletter von letzter Woche genommen, der über den E-Mail-Verteiler kam und kann das Ganze jetzt hochladen. Was die Applikation jetzt macht, ist, sie scannt das Dokument, sie chunkt das automatisch nach sinnvollen Chunks. Wir benutzen hier Semantic Chunking, das heißt, er versucht an guten Dokumentgrenzen zu teilen und benutzt dann ein Embedding-Modell, um das Ganze zu embedden und in Informix einzufügen.

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

Teil des Newsletters war die Nullif-Function. Das heißt, wir können immer fragen, was diese Funktion eigentlich tut. Und was wir jetzt hier sehen, hier drüben, wir sehen in der Log Activity, dass das Ganze angefragt wird und wir können jetzt hier nachvollziehen, welche Chunks wirklich benutzt wurden.

Und wir sehen jetzt hier aus diesem Dokument, den Techtip Funktion Nullif, das ist der Chunk, den er als relevantest herausgefunden hat, eben dadurch, dass das Ganze embedded wurde und dann über die Ähnlichkeitssuche herausgefunden wurde. Den Chunk und weitere Chunks hier hat er jetzt benutzt und hat GPT 4.0 benutzt, hat ihm gesagt, er ist ein Assistant answering questions about documents und hat diese drei Chunks angehängt und hat gefragt, was die Nullif-Function tut. Und was wir jetzt hier eben als Ergebnis kriegen: Overview over the Nullif-Function, die Syntax, verschiedene Argumente und er erklärt im Prinzip auch, was die Funktion tut, nämlich null zurückgeben, wenn die Argumente gleich sind.

Und an das denkt jetzt das erste Argument. Muss man so eine Applikation natürlich so bauen, dass man sie limitiert, wirklich nur darauf zu antworten, was sie aus den Chunks, aus dem Kontext finden kann. LLMs haben ja auch ein bestimmtes Basiswissen.

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

Aber andersherum gibt es natürlich meine ganze Unternehmens-IP, mein ganzes Wissen im Unternehmen, das natürlich nirgendswo öffentlich zugänglich ist, kann ich mit so einer Applikation eben der KI zur Verfügung stellen, auch sicher zur Verfügung stellen, wenn ich beispielsweise selbst gehostete KI-Modelle benutze und habe damit die Möglichkeit, genauso von KI zu profitieren, ohne dass ich meine Daten irgendwo public machen muss. Ich teile meinen Bildschirm wieder. Ist der weg?

Okay, ich würde jetzt hier mal eine ganz kurze Pause machen und würde schon mal durch die Fragen schauen, weil hier im Prinzip der Teil über das spezielle Vector Plate beendet ist. Wir wollen dann danach noch mal ein bisschen schauen, wie das Ganze denn ins größere Bild der KI passt. Herr Dr.

Aspiazu fragt: „Wird durch die KI in Zukunft DBS wie Informix überflüssig?“ Ich denke, nein. Ich glaube, wir werden viel stärker noch die Konsistenz und die Verlässlichkeit von Datenbanksystemen brauchen, aber genauso auch die Möglichkeit, eben unter Asset Properties mit Unter High Concurrency auf Daten zu arbeiten. Also Agenten werden Datenbanken benutzen und wir brauchen genau diese Eigenschaften, die schon über Jahrzehnte optimiert und erforscht sind.

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

Die Richtung eines Vektors zeigt der Vektor selber, also im Prinzip die Kombination aus allen Dimensionen. Die Kosinusdistanz zeigt den Winkel zwischen beiden Vektoren. Also der Kosinus des Winkels ist das Ergebnis der Kosinusdistanz.

Wenn man sich also vorstellt, ein Vektor zeigt nach da und ein Vektor zeigt nach da, dann ist die Kosinusdistanz genau der Kosinus des Winkels dazwischen. Das heißt, ein Vektor, der so zeigt und ein Vektor, der so zeigt, aber viel länger ist, das ist das, was wir eben gesehen haben, hat die Kosinusdistanz null, weil der Winkel dazwischen eben nicht existiert. Wie viel Platz in den Spaces belegt allein dieses Beispiel des Newsletters?

Das kann ich Ihnen aus dem Stand nicht beantworten. Das müsste ich dann auch noch mal nachschauen. Herr Aspeato, Sie haben noch die Hand gehoben.

Möchten Sie noch eine Frage stellen? Okay. Ich würde erst mal weiter im Thema machen.

Wir können gerne am Ende noch mal Fragen beantworten. Wenn Sie jetzt im Unternehmensumfeld planen, solche Anwendungen zu bauen oder einzusetzen, ist natürlich immer die Frage: Kann ich die Datenbank nehmen, die ich schon habe oder brauche ich eine extra Vektordatenbank? Und ich finde immer, den Unterschied hier ist wichtig zu machen.

Eine multimodale Datenbank, so wie HCL Informix, ist eben gut geeignet, wenn man bereits eine relationale Datenbank hat und man möchte das ausprobieren, man möchte solche Anwendungen bauen, hat natürlich den Footprint oder den Fußabdruck eines vollwertigen Datenbanksystems. Das Ganze ist optimiert für relationale Workloads. Das heißt, man wird nicht die super Millisecond Retrieval Performance kriegen.

Man kommt nah heran, aber als großer Vorteil, man speichert das Ganze einheitlich mit Asset-Eigenschaften. Das heißt, man hat seine Vektordaten und seine relationalen Daten zusammengespeichert und man hat natürlich den Vorteil, dass es ein System ist, das man zu warten hat. Würde man jetzt noch eine separate Vektordatenbank daneben stellen – es gibt verschiedene Datenbanken auf dem Markt – dann hat diese Datenbank natürlich einen relativ kleinen Footprint.

Ich kann das auch gut auf irgendeinem Edge Device deployen und ich kriege die optimale Geschwindigkeit für die Vektorsuche, muss aber dann beim Betreiben berücksichtigen, dass ich eine verteilte Konsistenz 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 das unter Asset Properties geht, also ganz oder gar nicht. Ansonsten ist eins der beiden Systeme out of sync.

Und ich muss natürlich auch die Wartung und die Administration von so einem dann verteilten Deployment beachten. Das ist weitaus komplexer als ein einheitliches System. Und was ich vorhin schon mal angerissen habe, ist die hybride Suche, die eben sehr wichtig ist, weil das in Praxisanwendungen gebraucht wird.

Das ist nämlich die Kombination aus Ähnlichkeitssuche und schlüsselwortbasierter Suche oder relationalen Filtern, die man schon kennt. Ein einfaches Beispiel ist hier: Ich habe zwei Dokumente, Maschine A und Maschine B. Eine kann ich herunterfahren, indem ich den Stecker ziehe, eine sollte ich ordnungsgemäß über die Schnittstelle herunterfahren.

Wenn ich jetzt als Nutzer die Frage stelle: „Wie fährt man die Maschine B herunter?“, dann kann es durchaus passieren, je nachdem, wie meine Applikation gebaut ist, dass ich beide Chunks kriege, weil die natürlich beide matchen und die KI sagt mir dann, man kann den Stecker ziehen oder die Schnittstelle nutzen, weil die natürlich nur die Antwort aus dem Kontext generieren kann, die sie bekommt. Wenn ich jetzt hybride Suche anwende, dann kann ich natürlich durch die Stichwortsuche das Dokument für Maschine A disqualifizieren, kriege 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 von solchen Systemen wie eben Informix mit dem Vector Blade.

Ich kann weiterhin die relationale Suche benutzen und kann das eben erweitern durch die Ähnlichkeitssuche. In unserer Anfrage vorhin hätte ich eben auch sagen können, ich möchte nur die IDs, die kleiner als drei sind oder kleiner als zwei sind, in meiner Ergebnismenge haben. Okay, wie passt das Ganze jetzt in das Gesamtbild und was tun wir bei HCL und Actian dafür, dass wir das Ganze in einem größeren Kontext denken?

Der erste Punkt, den ich anreißen will, ist das Model Context Protocol, was sicherlich vielen von Ihnen auch ein Begriff ist. Die Motivation davon ist einfach: LLMs haben ein begrenztes Wissen. LLMs haben einen Trainingszeitpunkt.

Ab diesem Zeitpunkt haben sie im Prinzip kein neues Wissen mehr. Natürlich, die Modelle, die wir jetzt über Services bei OpenAI oder so benutzen, die haben natürlich Zugriff auf neue Daten, auf Internet, Live-Zugriff, aber wir möchten dem System natürlich Zugriff auf unsere Live-Daten geben im Unternehmen und wir möchten auch ihnen die Möglichkeit geben, Aktionen auszuführen. Und das grundlegende Problem ist jetzt: Wie kann ich solche isolierten LLMs mit der Außenwelt verbinden und wie kann ich den Kontext verwalten?

Und was ich jetzt natürlich einfach tun könnte, ist: Ich könnte eine Applikation bauen und ich könnte in meine Applikation dann für jedes Tool, was ich einbinden will, den Treiber einbinden. Das heißt, den JDBC-Client von meiner Datenbank, eine API von meinem E-Mail-Server. Oder solche Sachen.

Das heißt, jede meiner Anwendungen müsste jedes meiner Tool APIs kennen. Ich baue also n mal m Integrationen. Das kann man eigentlich nicht verwalten, nicht skalieren.

Die Lösung dafür ist eine gemeinsame Sprache für diese Schicht und das ist eben genau die Motivation für das Model Context Protocol. Man sagt, das ist der USB-C-Anschluss für KI-Anwendungen. Das ist ein Open-Source-Standard, der ist jetzt von Anthropic an die Linux Foundation übergeben worden, ist also wirklich der De-facto-Standard und der mappt eben tool-spezifische APIs auf die generische API von MCP.

Dadurch, dass jeder Vendor einen MCP-Server bereitstellt, kann ich eben beliebige Agenten, beliebige LLMs damit verbinden. Die Agenten haben dabei die Möglichkeit, das ist Teil des MCP-Standards, die Tools, die über den Server bereitgestellt werden, dynamisch zu entdecken. Das heißt, ich kann einen Agenten starten, der Agent kann schauen, welche Tools sind verfügbar im MCP-Server und dann für eine bestimmte Aufgabe die richtigen Tools heraussuchen, zum Beispiel eine SQL-Anfrage ausführen oder einen Konfigurationsparameter ändern.

Wir haben auch einen MCP-Server für HCL Informix bereitgestellt. Der ermöglicht eben Agenten, Entscheidungen auf den echten Daten im System zu machen und reduziert damit Halluzinationen. Er gibt Zugriff auf die Daten und auf die Metadaten.

Das heißt, wir ermöglichen damit einen feinkgranularen Zugriff auf das Schema, die Geschäftslogik, also auch die Prozeduren und die Daten selbst. Es gibt Funktionen, gibt Schema, es gibt Read SQL, was eine einfache Leseanfrage auf die Daten darstellt. Der Weg, den wir gehen, ist, wir wollen damit auch passive Agenten zu aktiven Benutzern machen.

Das heißt, wir werden Schreib- und Admin-Werkzeuge in diesen MCP-Server integrieren, der es eben erlaubt, dass Agenten auch Daten einfügen können, Daten verändern können und administrative Aufgaben am Datenbanksystem ausführen können. Dazu kommen wir später noch einmal, wenn wir auf die Agenten-Roadmap schauen. 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 erlaubt, durch feinkranulare Zugriffsmechanismen und Governance-Mechanismen und sogenannten Guard Rails zu beschneiden, was der Agent wirklich tun kann und wirklich sicher zu sein, dass man die Systeme im operativen Betrieb nicht beeinflusst. Das zweite, was wir vorhin angerissen haben in der Introduction, sind dialogorientierte Analysen.

Ein ganz einfaches Statement: Jede Zahl im Unternehmen hat eine Geschichte und das ist nämlich das, worauf es am Ende ankommt. Wenn ich eine Frage stelle oder ein Dashboard anschaue, dann bringe ich selber einen bestimmten Kontext mit, um diese Zahl einordnen zu können. Kommt die Anzahl der Customers, kommt das hin mit dem, was ich vermute oder so.

Ein Agent hat diesen Kontext natürlich nicht. Das heißt, wenn ich einen Agenten frage: „Wie viel haben wir letztes Quartal verdient?“, dann kann der Agent alle diese vier Antworten machen und jede dieser Antworten wäre eigentlich richtig. Nur halt für die bestimmten Personen im Unternehmen.

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

Das heißt, ich kann die gleiche Anfrage auch zweimal stellen und bekomme zwei unterschiedliche Antworten, weil eben der Agent anhand meines Datenbankschemas entschieden hat, eine andere Anfrage zu stellen. Die kann genauso richtig sein, aber eben nicht in dem Kontext, in dem ich sie abfrage, weil ich beispielsweise aus der Finanzabteilung bin. Das Problem ist, große Sprachmodelle sind sehr flexibel, aber wie gesagt unvorhersehbar.

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

Die Antwort kriege ich vielleicht am Ende der Woche. Die Lösung, die wir dafür entwickelt haben, ist der Actian AI Analyst. Der kombiniert die Vorteile von beiden Seiten.

Der ist flexibel und verlässlich. Das ist im Prinzip ein natürlich sprachlicher Agent, der mir verlässliche und wiederholbare Antworten gibt, weil er eben im Business-Kontext fundiert ist. Kurze Übersicht über diese Lösung, die wir gebaut haben.

Wir können Geschäftsanfragen in natürlicher Sprache machen und wir kriegen sofortige Analysen. Keine Dashboards, niemand muss SQL-Anfragen schreiben. Das heißt, jeder, auch nicht technische Personen, können das Ganze benutzen, um Insights in HCL, Informix Daten beispielsweise zu kriegen.

Der AI Analyst antwortet dabei auf einem semantischen Modell. Dieses Modell beinhaltet alle Business-Definitionen, alle Metriken, die ich freigegeben oder die jemand freigegeben hat. Das heißt, dieses semantische Modell beschreibt im Prinzip meinen Datensatz und meine Datenbasis.

Jede Antwort zeigt auch klar, wie das Ergebnis zustande kommt. Das heißt, man sieht alle Reasoning-Schritte, die der Agent gemacht hat, um das Ganze abzufragen. Man sieht die Anfrage, die gestellt wurde und er lässt sich einfach integrieren in die Tools, in denen die Teams einfach arbeiten: in Slack, in Teams, im Webbrowser.

Das Interessante daran ist, ich kann das wirklich in wenigen Stunden ausrollen und ich kriege Antworten auf meine Ergebnisse in unter einer Minute. Ein kurzer Einblick, wie das Ganze funktioniert. Wie kriegt man das hin, dass solche Anfragen wirklich wiederholbar und korrekt sind?

Wir nehmen die Geschäftsanfrage, die wir kriegen. Wir lassen den Agenten loslaufen. Der Agent erkennt die Absicht, der beschreibt oder erstellt ein Template einer Anfrage und ist aber nicht erlaubt, eine finale SQL-Anfrage zu stellen.

Dieses Template wird dann durch diese semantische Schicht, die alle Business-Informationen enthält, geleitet und dort werden die Platzhalter dann durch die wirklichen Definitionen ersetzt. Das heißt, wenn ich nachfrage: „Wie viele aktive Kunden haben wir?“, dann wird dieser aktive Kunde-Platzhalter durch die wirkliche Definition ersetzt. Die Anfrage wird dann lesend ausgeführt.

Die Daten bleiben also in der Datenbank. Ich kriege nur das Ergebnis und kriege am Ende eine verlässliche Antwort. Was man jetzt natürlich sagen kann, das verlagert das Problem im Prinzip auf das Erstellen dieser semantischen Schicht als wirkliche Wahrheitsquelle.

Und auch dafür haben wir einen Agenten, der Steward Agent, der baut, pflegt und überwacht diese semantische Schicht. Der nimmt also Dokumentationen, Confluence-Seiten, überall da, wo meine Business-Logik erklärt ist, der baut die in die semantische Schicht ein und der hat eine Feedbackschleife, sodass jedes Mal, wenn ich eine Anfrage ausführe und ich eine Unterhaltung mit dem Agenten habe, dann extrahiert er daraus Informationen und verbessert diese semantische Schicht auch über die Zeit. Der AI Analyst ist eine Möglichkeit, um mit Informix am Ende wirklich natürlich sprachlich zu reden.

Und als letzten Punkt für heute, wenn wir noch mal schauen, wo es hingeht im Bereich agentische KI. Einmal ganz kurz den Unterschied von agentischer KI zu regulären Anwendungen. Was ich bereits am Anfang gesagt habe: Einer der wichtigsten Punkte bei agentischer KI ist, dass das Ganze zielorientiert ist.

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

Agenten haben eine Planungsphase. Das heißt, sie zerlegen die Aufgaben, sie planen selbstständig und sie haben eine Feedbackschleife, um während der Ausführung dann das Ganze noch einmal anzupassen, je nachdem, wie erfolgreich die ersten Schritte waren. Sie haben einen Kontext und ein Gedächtnis.

Das heißt, wenn ich bestimmte Aufgaben schon einmal erledigt habe, dann können die sich das Ganze auch merken in einem Kurzzeit- und in einem Langzeitgedächtnis für fortlaufende Verbesserungen. Das heißt, ein Agent kann über die Zeit auch mein persönlicher Assistent werden, indem er weiß, was ich bevorzuge, wie ich meine Aufgaben erledige und so weiter. Und hier kommt MCP ins Spiel.

Agenten können Werkzeuge nutzen. Das heißt, ein Agent kann selbstständig auf externe Systeme zugreifen über MCP mit den Sicherheitsmechanismen im MCP-Server und den Einschränkungen und Security-Mechanismen. Und jetzt kann man sich das überlegen.

Das ist so ein bisschen eine Inspiration, wenn Sie im Unternehmen verschiedene Agenten bauen wollen mit dem MCP-Server und mit Informix. Solche Anwendungsfälle existieren eigentlich über den kompletten Datenlebenszyklus. In der Datenaufnahme kann man sagen, Agenten agieren eigentlich als Operatoren.

Das heißt, ich kann Agenten für Datenaufnahme haben. Ich kann meinen Agenten per Telefon anrufen, kann sagen, ich komme aus einem Kundenmeeting. Das sind die Informationen, die ich mitgenommen habe.

Bitte füge das mal in meiner Lead-Datenbank ein. Ich kann einen Agent für Datenmigration erstellen, was automatisiert von einer Datenbank in meine In-House-Datenbank Daten überführt. Für Datenmanagement kann man sagen, Agenten agieren eigentlich als Kuratoren.

Das heißt, ich kann Datenqualität überprüfen und automatisch anreichern. Ich kann Datenherkunft tracken. Das heißt, gerade im KI-Zeitalter ist es sehr wichtig: Wo kommen meine Messungen her?

Wo kommen meine Daten her? Für die Datennutzung, wie eben gesehen, agieren Agenten eigentlich als Analysten. Das heißt, ich kann natürlich sprachliche Anfragen stellen.

Ich kann aber auch einen Agent für Dashboard-Erstellung machen oder sogar multimodale Anfragen. Das heißt, mein Agent könnte die Kombination aus Dokumenten, E-Mails, Bildern und relationalen Daten abfragen und damit eine Antwort bilden. Da ist viel möglich.

Und einer der großen Pain Points natürlich: Datenbankadministration. Agenten agieren als Administratoren. Sie können helfen oder sogar bestimmte Aufgaben übernehmen, zum Beispiel ein System Health Agent, der 24 Stunden am Tag mein System überprüft und schon proaktiv auf Probleme hinweist oder die sogar schon löst.

Oder Datenbank-Tuning. Wissen wir alle, ein System hat hunderte Tuning Nobs. Das Schema, die Konfiguration, all das kann getunt werden und ein Agent kann helfen, das Ganze an den Workload anzupassen.

Das Ganze als Inspiration, was man da umsetzen kann. Wie kann so etwas aussehen, was man typischerweise macht? Man hat hier seine User-Datenbank.

Man hat natürlich für die User-Datenbank einen MCP-Server, sodass der Agent da auch sicher darauf zugreifen kann. Und ich habe in irgendeiner Weise Telemetrie oder Logs, die ich aus dem System abführe. Und was ich tun sollte, wenn ich so eine Applikation baue: Ich sollte das Ganze in einer Metrik-Datenbank schreiben, damit ich den operativen Betrieb des Systems eben nicht störe, wenn ich mit Agenten diese Metriken abfrage.

Der Agent hat jetzt Zugriff auf die Daten und auf die Logs oder auf die Telemetriedaten. Das heißt, er weiß zum Beispiel auch, wie hoch der Speicherverbrauch ist und kann dadurch jetzt Entscheidungen treffen. Was so ein Agent braucht, ist für das Reasoning ein Large Language Modell.

Das kann ich jetzt relativ naiv bauen, indem ich das Ganze einfach an OpenAI oder an Tropic sende mit einem öffentlich gehosteten Modell. Oder ich möchte es unter Kontrolle halten mit einem privaten Modell, das ich bei mir in-house hoste. In jedem Fall, was man tun sollte, ist, man sollte einen Proxy Layer dazwischen schalten, der das Ganze eben weg abstrahiert und außerdem noch weitere Guard Rails implementiert.

Mal aufgeschlüsselt: Das ist auch das, was wir planen zu tun, wenn wir Agenten vorgefertigt bauen, jetzt für all unsere Datenbanksysteme. Wir werden so einen Proxy Layer dazwischen schalten. Das hat eine Runtime für lokale Modelle, kann optional an ein öffentliches Modell geschaltet werden und hat eben alle diese Guard Rails, 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, jeder Request muss geloggt werden. Ich möchte sehen, wie viel Token verbraucht werden.

Ich kann budgetieren und personenbezogene Daten erkennen und maskieren, bevor die wirklich an die öffentlichen Modelle gehen. Und als kurzer Zeitplan: Was wir im April schon veröffentlicht haben, ist die Version 1 des MCP Servers. Das war der sichere Einstieg mit Authentifizierung und lesendem Zugriff.

Wir haben vor anderthalb oder zwei Wochen die Version 1.1 released. Damit kann man das Ganze schon mal operativ einsetzen. Das heißt, hier gibt es schon die ersten Guard Rails.

Wir haben Logging dabei und wir erlauben Schreiboperationen mit Human in the Loop und das Ganze wird dann durch Admin-Werkzeuge und verschiedenen Orchestrierungsfeatures noch weiter erweitert in der nächsten Version. Parallel dazu arbeiten wir an Agenten. Das heißt, Agenten zur Datenbankadministrierung kommen gegen Jahresende in den Early Access.

Was uns dabei wichtig ist, und ich habe es vorhin kurz angerissen: Wir reden hier über die Systeme, die im Prinzip das Herz all unserer Unternehmen sind. Da sollte man nicht leichtfertig mit Agenten darauf arbeiten und riskieren, dass da Daten verloren gehen, dass Systeme kompromittiert werden und so weiter. Das heißt, wir setzen Verlässlichkeit über den Hype.

Wir möchten sicher wachsen. Das heißt, wir möchten schrittweise Use Cases ermöglichen mit der Sicherheit, die wir brauchen, um das wirklich verlässlich zu tun. Wir wollen volle Kontrolle über die KI-Nutzung 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, das Ganze so minimal wie möglich in die Produktionsumgebung einzugreifen. Habe ich eben gesagt, eigentlich ist es nicht akzeptabel, dass diese Anwendungen den operativen Betrieb stören und die Autonomie wird konfigurierbar sein.

Das heißt, so ein Agent kann Vorschläge machen, die ich als Nutzer selber umsetze. Über Human in the Loop kann der Vorschläge machen, die ich nur noch absegnen muss oder Systeme können auch künstlich autonom arbeiten. Das ist so ein bisschen die Roadmap, wo es hingeht und wo wir vorsichtig, aber sicher hinwachsen wollen.

Okay, also als Zusammenfassung die wichtigsten Erkenntnisse von heute: HCL Informix wird AI ready. KI lebt dort, wo die Daten schon leben, denn wir haben den nativen Vektordatentyp und wir haben MCP. Wir haben gesehen, dass man mit seinen Daten reden kann, dass man Lösungen haben kann, um natürlichsprachlichen Zugriff zu ermöglichen.

Und wir haben gesehen, was die Zukunft bringen wird. Agentische Werkzeuge werden die Arbeit vereinfachen und verbessern, wie wir mit unseren Systemen arbeiten, wie wir sie konfigurieren, wie wir sie administrieren. Okay, und damit das Abschlussstatement: HCL Informix ist bereit für Ihre KI-Anwendungsfälle und wir können gerne noch diskutieren und Fragen beantworten.

Okay. Könnten unterschiedliche Personen mit ihren natürlichsprachlichen und vergleichbaren Anfragen unterschiedliche Ergebnisse bekommen? Genau, das kann passieren.

Das ist genau der Punkt, den ich auf der Folie mit den unterschiedlichen Antworten gegeben habe. Dieser AI Analyst kennt meine Rolle als Nutzer. Ich kann verschiedene Nutzer anlegen, die verschiedene Rollen haben.

Das System weiß also, dass ich aus der Finanzabteilung bin, wie ich in meiner Abteilung einen aktiven Kunden beispielsweise definiere und mit der gleichen Anfrage kann jemand anderes ein anderes Ergebnis kriegen nach der Metrikdefinition, die in dem Kontext richtig ist. Das Ganze ist rollenbasiert und damit kriege ich immer den richtigen Kontext. Werden Kurz- und Langzeitgedächtnis zwischen unterschiedlichen Nutzern geteilt?

Nein, ganz wichtig, denn das kann natürlich auch für Caching-Mechanismen, Anfragen-Caching, das ist natürlich ein ganz wichtiges Einfallstor für Leaks oder für Security-Probleme. Nein, das Ganze wird nicht geteilt. Kurzzeitgedächtnis und Langzeitwissen austauschbar?

Was wird bei dem Auditing geloggt und wie hoch ist der Datenbedarf? Wo liegen die Auditdaten außerhalb der Instanz oder im Filesystem? Gibt jetzt zwei Kontexte dafür.

Also Kurzzeitgedächtnis und Langzeitwissen kann ich konfigurieren. Ich kann einen System Prompt im Kontext von dem AI Analyst anpassen. Ich kann damit das Verhalten meines Agenten auch konfigurieren und ich kann einsehen, was er aktuell in seinem Memory gespeichert hat und kann das auch konfigurieren.

Was wird beim Auditing geloggt und wie hoch ist der Datenbedarf? Aktuell wird das Ganze in eine Datenbank geloggt bei uns. Wenn man natürlich jetzt einen generischen Agenten baut, wie mit dieser Referenzarchitektur, die ich eben gezeigt habe, kann man da ein beliebiges System anbinden.

Typischerweise ein operationales Datenbanksystem oder ein NoSQL-System, wo man dann diese Logs sehr hochfrequent reindumpt. Und wie hoch der Datenbedarf dafür ist, richtet sich natürlich danach, wie lange ich per Regularium vielleicht eine Data Retention haben muss. Also wenn ich ein System baue und ich muss 30 Tage lang alles auditierbar halten, dann muss ich das eben so lange aufheben.

Anschließend kann ich das wahrscheinlich archivieren. Und noch eine Zusatzfrage: auch bei gleichen Rollen? Nein, wenn ich die gleiche Rolle habe, kann ich durch dieses System designen.

Das ist genau der Unterschied zwischen einem puren LLM, was mir eben für die gleiche Anfrage verschiedene Antworten geben kann, löst unser System, das durch diese schrittweise Übersetzung, durch diese zweistufige Übersetzung eben. Okay, wir sind am Ende der Zeit. 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 noch mal ins Gespräch kommen zu irgendeinem Event oder gerne auch per E-Mail, wenn es Follow-up-Fragen gibt. Und dann bedanke ich mich und wünsche Ihnen einen schönen Abend. Danke für das Feedback.