Transcript
Sven Johann Hallo und herzlich willkommen zu einer neuen Folge des INNOQ Podcasts. Heute mit Marco Steinke zur Suche mit Vektor-Datenbanken. Also so eine Suche bei einem Webshop, E-Commerce oder Inhalte aus irgendeinem CMS auf einer Firmenwebseite und so weiter. Also diese Suche, die uns alle was angeht und nicht jetzt unbedingt ChatGPT oder Google-Style-Suche. Marco, erzähl doch mal kurz was über dich. Oh, herzlich willkommen übrigens noch. Wer bist du?
Marco Steinke Ja, hallo, also ich bin Marco und ich arbeite bei INNOQ eher im Bereich Schnittstelle zwischen Softwarearchitektur und Data und AI und beschäftige mich da aktuell hauptsächlich wirklich damit, wie man AI-Modelle in bestehende Softwarearchitekturen integrieren kann und wie man da drum herum diese ganzen Word2Vec-Modelle Ops Strukturen und Prozesse implementieren kann, also wie man Pipelines aufsetzt, was es dafür Alternativen gibt, wie man die ganzen Sachen scheduled und testet und wie man generell diese Komponenten und Bausteine in bestehende Softwarearchitekturen einbauen kann. Damit beschäftige ich mich eigentlich aktuell die ganze Zeit.
Sven Johann Okay. Sehr schön, sehr schön. Also wir versuchen auch schon ziemlich lange diesen Podcast zu machen. Es kam immer was dazwischen, aber heute klappt es endlich. Wir streifen, also wir versuchen alles Mögliche abzudecken. Allerdings natürlich ja nicht in besonderer Tiefe. Einen Tag nach unserem Podcast, da werden Ole und Robert einen anderen Podcast publizieren. Auch hier selber Podcast Kanal, wo Sie noch mal ins Detail gehen oder ein bisschen mehr ins Detail gehen, aber dann natürlich ein bisschen enger geschnallt. Okay, wenn ich sage Suche, ich bin ja alt und langweilig so ungefähr. Und ich kenne ja die Suche nur als indexbasierte Suche. Also sowas wie Elasticsearch oder SOLR auf Basis von Lucene. Und ich würde vielleicht einmal ganz kurz noch was zu indexbasierter Suche sagen, damit man dann vielleicht später auch einfacher auf die Suche mit Vektor-Datenbanken referenzieren kann. Also was ist eigentlich der Vorteil von so einer indexbasierten Suche auf Basis von Lucene? Also zum einen kann man natürlich so eine Volltextsuche machen. Also ich kann, so wie ihr das kennt, ich gebe einfach irgendwo Begriffe ein und dann kann ich relativ einfach nach diesen Begriffen suchen. Da kann man natürlich sagen, in einer relationalen Datenbank kann man das mit entsprechenden Queries auch, aber wenn man natürlich mehrere Wörter hat, dann ist einfach so eine Search Engine da eher geeignet. Eine Search Engine kann auch gut mit Unschärfe umgehen. Also wenn ich mich mal vertippe, dann findet die auch alternative Eingaben. Das kann man auch einstellen. Also man muss natürlich immer aufpassen, wenn man zu viel Unschärfe eingibt, dann hat man natürlich auch keine Schärfe mehr. Ich kann Inhalte boosten. Also meinetwegen, wenn ich zum Beispiel bei einem Webshop eine Produktseite indiziere, dann kann ich sagen, wenn der Begriff in der Headline oder in irgendeiner Unterüberschrift vorkommt, dann ist das irgendwie mehr wert, also dann soll der höher gerankt werden als Begriffe, die jetzt im normalen Text sind. Also ich habe auch Zugriff auf das oder ich habe Einfluss auf das Ranking. Nennt sich Boosting. Ich kann auch filtern, also das ist dann keine Suche nach Begriffen, die irgendwo vorkommen, sondern das ist praktisch ein harter Filter, meinetwegen auf Preis. Also ich will nur Sachen sehen, die zwischen 35 und 65 Euro kosten, zum Beispiel. Das kann ich auch ganz gut mit einer indexbasierten Suche machen. Die Produkte wie Elasticsearch, die können wirklich sehr gut mit großen Datenmengen umgehen. Also Elasticsearch, schon vor 10 Jahren oder 12 Jahren hat Facebook Elasticsearch eingesetzt. Facebook-Search an sich, das weiß ich nicht ganz genau, aber ich will nur sagen, Elasticsearch kommt auch mit großen Datenmengen gut klar, indem einfach diese Indizes, die können aufgeteilt werden in viele kleine Indices, ja, Index-Sharding. Ja, wie kommen eigentlich diese Daten in die Search Engine? Also ich hab die, normalerweise fliegen die irgendwie rum. Ich hab zum Beispiel eine Produktdatenbank oder ich hab irgendwie meine Webseiten in meinem CMS, also meine Daten. Und dann kann ich die einfach aufbereiten und kann die praktisch, kann so ein Insert Statement machen. Und dann wird dann zum Beispiel Elasticsearch, wird die in Lucene indexieren. Ja, so wie wir das einstellen. Und wenn dann sich mein Produktpreis zum Beispiel ändern würde, dann kann ich dieses Dokument updaten. Auf Basis von zum Beispiel einer ID wird dann einfach das alte Element entfernt und das neue wird reingesetzt. Und ich kann natürlich auch Elemente löschen. Wenn mein Produkt zum Beispiel einfach nicht mehr verfügbar ist, dann kann ich es aus der Datenbank, also aus der Search Engine, ist ja nichts anders als der Datenbank, kann ich es halt auch entfernen. So funktioniert in Kürze die indexbasierte Suche. Und dann habe ich mich irgendwie gewundert vor ein paar Jahren, also jetzt vielleicht so drei Jahre her oder so, also vor ChatGPT, so Kollegen von mir von damals, die halt bei Elasticsearch mitgemacht haben oder halt bei der Firma selbst oder viel mit Search gemacht haben, mit Elasticsearch und SOLR, die sind irgendwann weg und sind zu anderen Firmen und da habe ich mir gedacht, gibt es jetzt eine neue, coole, indexbasierte Datenbank? Und dann kam raus, nee, das ist irgendwie eine Vektor-Datenbank. Und da habe ich mir gedacht, das ist ja, was ist denn das? Keine Ahnung, was das jetzt soll. Und dann kam ChatGPT und dann hat jeder, glaube ich, so ein Gefühl bekommen, was das jetzt, also eine Vektor-Datenbank ist keine LLM, wenn ich das richtig verstehe, also Marco wird es gleich erklären, aber das ist alles so im selben Dunstkreis, dass wir halt einfach die Suche ein bisschen anders denken. Das gibt es jetzt schon. Also kommt jetzt nicht aus dem Nichts. Also das gibt es schon relativ lang, gibt es schon ein paar Jahre, also schon vor ChatGPT. Aber ich glaube, jetzt gibt es einen richtigen Boost. Und bei uns gibt es auch Kunden, die das haben wollen. Und der Marco hat es auch implementiert. Und deswegen vielleicht die erste Frage, wenn ich über Vektor-Datenbanken nachdenke. Was ist eigentlich ein Vektor?
Marco Steinke Genau, also wenn man jetzt nochmal an die indexbasierte Suche zurückdenkt, dann sucht man ja wirklich nach exakten Begriffen und man kann mit einer gewissen Unschärfe noch beispielsweise Tippfehler ausgleichen und dann sehr ähnliche Strings oder Zeichenketten dann suchen in der Datenbank. Aber es gibt eben auch Probleme, wenn man vielleicht inhaltlich das gleiche meint, aber andere Wörter verwendet hat. Und man kann nur nach exakten Wörtern suchen. Und das ist eben die Semantik einer Zeichenkette. Und genau diese Semantik wird von einem Vektor, oder es wird versucht, diese Semantik dann zu repräsentieren. Also das ist wirklich der Versuch, nicht mehr nach exakten Zeichen oder Wörtern zu suchen, sondern man versucht nach Bedeutung zu suchen.
Sven Johann Und also der Vektor, wie wird der, wo kommt der her? Wie wird er erstellt?
Marco Steinke Also klassischerweise gibt es da sogenannte Word2Vec-Modelle beispielsweise. Also das ist ein Algorithmus, der 2013 von Google entwickelt wurde und da hat man eben versucht Wörter zu klassifizieren. Also man hat zum Beispiel dann gesagt, man hat jetzt das Wort Baum und das hat dann irgendeinen eine Klasse zugeordnet bekommen, zum Beispiel ist ein Nomen und dann hat man eben das mit ganz vielen verschiedenen Wörtern gemacht aus einer Sprache und den allen versucht irgendwie eine Klasse zuzuordnen. Und diese Modelle hat man dann versucht so zu trainieren, dass sie es eben effektiv schaffen diese Klassen zu erzeugen und dadurch haben die Modelle intern eine Art Repräsentation dieser Wörter entwickelt. Das heißt, intern wurden irgendwelche Werte und Gewichte verändert, damit das Wort am Ende zu der gewünschten Klasse führt. Und wenn man dann später nach dem Training in das Modell reingeschaut hat, konnte man dann an dieser Stelle sehen, dass es intern irgendeine Repräsentation gibt, die später dazu führt, dass die gewünschte Klasse dabei rauskommt. Und diese Repräsentation kann man dann aus dem Modell extrahieren. Das heißt, man kann das Modell aufrufen mit dem Wort Baum und nach der Hälfte des Modells macht man dann einen Cut und nimmt das, was das Modell intern generiert hat. Und das ist dann genau diese Repräsentation. Also es ist eine numerische Repräsentation und das wird deswegen auch Vektor genannt, weil man eben eine Liste von verschiedenen Elementen erhält, die alle dann numerisch sind und die repräsentieren irgendwie die Bedeutung eines Wortes.
Sven Johann Also ich kann mich noch an die Erklärung erinnern, wenn ich z.B. New York oder Boston oder Berlin oder so habe, das kann ich ja auch als Vektor darstellen, also als Höhen- und Breitengrad. Und dann kann man damit auch sozusagen eine Ähnlichkeitssuche machen. Man kann feststellen, Boston liegt näher an New York als an Berlin. Und so ähnlich muss man das bei so einem, bei Word2Vec muss man sich das auch vorstellen, dass ich diese Nähen berechnen kann. Aber ich habe ja, also von ChatGPT kennt man das ja, dass dieses Modell kann an alle möglichen Fragen beantworten. Aber ich will ja im Grunde genommen, wenn ich jetzt so meine Suche habe, will ich Fragen zu meinen Produkten oder zu meinem Webauftritt, zu den Inhalten von meinem CMS oder wie auch immer. Da will ich ja irgendwie diese Suche haben. Wie muss ich mir das vorstellen? Also auf der einen Seite habe ich dieses vortrainierte Modell und auf der anderen Seite habe ich meine eigenen Daten, nach denen ich suchen lassen will. Wie werden diese Sachen in einer Vektordatenbank verheiratet?
Marco Steinke Also die Modelle, die ursprünglich für Wörter verwendet wurden, wurden dann eben dementsprechend weiterentwickelt, dass sie auch für komplette Zeichenketten, die wirklich mehrere Wörter beinhalten, dann auch funktionieren. Und dadurch ist man jetzt eben in der Lage, dann auch größere Datenmengen wirklich dann in der Datenbank abzulegen, indem man nämlich jedes Mal, wenn man etwas persistieren möchte, dieses vortrainierte Modell aufruft. Du hast beispielsweise so einen kompletten Blogartikel geschrieben, würdest den dann in das Modell reinwerfen und kriegst dann für den kompletten Blogartikel einen Vektor zurück, der irgendwie repräsentiert, was dieser Blogartikel beinhaltet.
Sven Johann Der ganze Blockartikel ist ein Vektor.
Marco Steinke Das kann man sich so vorstellen. Man kann natürlich auch dann sagen, dass jeder Blockartikel in seine Abschnitte zerlegt wird und dann jeder Abschnitt einen eigenen Vektor bekommt. Und die würde man dann als Index verwenden. Also man hat dann eine Indexspalte, in der wirklich Vektoren vorkommen. Und da würde man dann den Rest hinterlegen, also die Daten, die ursprünglich zu diesem Vektor geführt haben.
Sven Johann Ah, okay, okay, also im Grunde genommen, okay, okay, also aus meinem, wie auch immer, also ich könnte sagen, ich habe mein Produkt oder mein Artikel, nee, vielleicht Artikel ist vielleicht einfacher, dann sage ich mal ein Vektor sozusagen aus der Überschrift und dann aus den einzelnen Blöcken. Und okay, und dann ist praktisch der Vektor der Index und wie bei der normalen Search Engine ist das ja auch, dann wird ja praktisch auch das ganze Dokument dazu gespeichert. Also ist im Grunde genommen schon ähnlich.
Marco Steinke Genau. Und wenn du dann etwas suchst, wird deine Suchanfrage auch in einen Vektor übersetzt. Und dann sucht man wirklich in der Vektor-Datenbank an der Stelle dieses Vektors in der Umgebung nach ähnlichen Vektoren. Also du kannst zum Beispiel fragen, wovon handelt dieser Blogartikel. Und dann würdest du den Titel mitgeben, beispielsweise von diesem Blogartikel. Und dann würde die Vektor-Datenbank das alles übersetzen und wird dann reinschauen, was liegt denn in diesem Vektorraum, so nennt man das dann in der Datenbank, in der Umgebung meiner Frage. Und alles, was dann in der Umgebung liegt, wird dann ausgelesen und dann als mögliche Antwort gegeben. Das ist auch der Hauptunterschied zur indexbasierten Suche. Da versucht man dann wirklich exakte Ergebnisse auszugeben, mit einer leichten Unschärfe. Und die Vektor-Datenbank, die versucht eben immer nur bestmögliche Ergebnisse zu geben. Also man hat nie eine Garantie, dass wirklich jetzt ein Ergebnis gegeben wird, was exakt auf die Frage passt. Aber das ist ja auch eigentlich gut, weil man muss nicht nach exakten Wörtern suchen, sondern durch diesen Vergleich der Bedeutung, also der umliegenden Einträge in der Datenbank, kann man dann auch wirklich Einträge zurückgeben, die ähnlich sind, aber nicht exakt gleich. Das heißt, wenn du jetzt zum Beispiel in dem Titel ein falsches Wort verwendet hast beim Suchen, dann würdest du den Artikel eventuell trotzdem finden, mit diesem einen gewechselten Wort, weil die Vektor-Datenbank verstanden hat, dass du ja eigentlich die gleiche Bedeutung meinst bei deiner Anfrage.
Sven Johann Die logische Folgefrage wäre jetzt so eine Hybrid-Abfrage, aber ich schiebe das auf den Schluss. Das funktioniert im Grunde genommen so ähnlich wie auch ChatGPT. Also ich kriege Antworten, die sind nicht notwendigerweise super korrekt, aber die helfen mir schon mal ziemlich weiter. Jetzt habe ich bei ChatGPT irgendwie das Problem, dass die Daten, die drin sind, die kriegst du relativ schwer wieder raus. Aber bei einer Vektor-Datenbank ist das anders. Also da kann ich im Prinzip wie bei meiner indexbasierten Suche Textblöcke einfach wieder löschen oder updaten oder wie auch immer.
Marco Steinke Genau, also du kannst dann den Textblock wirklich genau wie bei einer indexbasierten Suche einfach löschen. Und der Unterschied zu ChatGPT ist einfach, dass es dabei ja um ein neuronales Netz handelt oder ein Modell, was wirklich trainiert wird. Also das wird wirklich darauf trainiert, diese Sätze generieren zu können. Das heißt, alles, was das irgendwie mal als Trainingsdaten bekommen hat, das bleibt da auch wirklich drin. Und da kannst du jetzt zum Beispiel, wenn das mal ein Blogartikel gelesen hat, das wurde ja teilweise auch auf ganz viele Blogs trainiert, und in dem Artikel hat sich irgendwas geändert, dann würde in Zukunft diese Änderung auch gar nicht mehr da reinkommen, weil der alte Blogartikel einfach schon in irgendeiner Weise reintrainiert wurde und in deiner Vektor-Datenbank könntest du natürlich einfach den Blogartikel löschen, dann den aktualisierten Artikel wieder neu embedden und wieder einsetzen und dann hättest du ihn halt aktualisiert, weil da kein Training stattfindet. Du benutzt einfach nur ein trainiertes Modell, um deine Einträge dann zu erzeugen.
Sven Johann Und du hattest ja an der Suche für einen Webshop gearbeitet. Ihr habt dann auch eine ganze Menge Produkte gehabt. Der Webshop verkauft Produkte, diese Produkte werden dargestellt als Text und Bilder. Wie habt ihr das aufbereitet und in die Vektor-Datenbank reingeworfen und upgedated? Wie muss ich mir das vorstellen?
Marco Steinke Also da muss man sich erst mal überlegen, wie liegen die Produkte eigentlich vor. Es gibt ja verschiedene Möglichkeiten. Man kann beispielsweise die Website haben, die das Produkt beschreibt, mit Bild, Text und allen möglichen Informationen. Es gibt vielleicht irgendwelche Produkt-PDFs, irgendwelche Datenblätter, die dann irgendwelche Eigenschaften beinhalten. Oder man kann natürlich auch die Produkte aus einer Datenbank dumpen. Das heißt, man erhält wirklich einmal komplett die Produktliste aus der Datenbank und das ist auch das, was wir erhalten haben. Also wir hatten wirklich die Produkte dann so, wie die auch wirklich im Online-Shop verwendet werden, erhalten und haben dann angefangen die Produkte dann aufzubereiten.
Sven Johann Ja, also im Grunde genommen bei der Suche, bei der indexbasierten Besuche ist ja auch so, ich habe irgendwie genau das, Produktdaten und Produktbilder und vielleicht auch PDFs und dann bei dem Index, da generiere ich sozusagen ein Dokument. Was zum Beispiel zum Produkt, keine Ahnung, ich nehme es einfach mal Amazon als Beispiel, wir verkaufen Bücher und dann habe ich ein Dokument, das dieses Buch beschreibt und das wird dann indiziert. Und ihr habt ja, ich kann es jetzt nicht sagen, weil es irgendwie zu offensichtlich aus unserer Kundenliste, was für ein Produkt ist, also welche Firma das ist, aber ihr habt auch diese Daten gehabt und dann habt ihr all diese Daten praktisch in diese Vektor-Datenbank reingeworfen, so wie sie sind oder habt ihr eine besondere Art von Datenaufbereitung gemacht, weil du hast ja auch gesagt, du musstest den ganzen Artikel reinwerfen, du kannst auch Teile von diesem Artikel reinwerfen.
Marco Steinke Also da ist wirklich die Frage, was möchte man denn erreichen? Möchte man jetzt einfach nur eine Produktsuche bereitstellen oder möchte man vielleicht auch eine Art Beratungstool bereitstellen in Zukunft, was mithilfe eines LLMs Fragen über die Produkte beantworten kann? Und wenn man wirklich einfach nur eine Produktsuche haben möchte, die einem ermöglicht, dass man beispielsweise wenn man schon ein Produkt ausgegeben bekommen hat, fragen kann, kannst du mir auch ähnliche Produkte vorschlagen? Dann ist man eben genau in dieser Recommendation Spalte, die man ja auch jetzt in allen möglichen Webshops und Systeme eigentlich immer sieht. Also schlage mir ähnliche Produkte vor, die mich interessieren könnten. Und das ist eigentlich so ein Standard-Use-Case für die Vektor-Datenbank und dafür embedded man wirklich das gesamte Produkt. Also du hast das Produkt beispielsweise als Zeile in einem CSV oder als JSON vorliegen und du nimmst dann wirklich das komplette Produkt als JSON-String und erzeugst dafür einmal einen Vektor. Und was du alternativ auch noch machen kannst, ist dann einmal den Produktnamen zusätzlich einmal in einen Vektor zu verwandeln und die beiden dann in die Datenbank abzulegen, damit man entweder nach Eigenschaften oder nach dem Namen suchen kann.
Sven Johann Wie kriegt er den Match hin zwischen Namen und Eigenschaften? Weil es sind ja zwei unterschiedliche Vektoren. Also der Name vom Produkt passt genau zu den Eigenschaften. Aber weil praktisch die Eigenschaften auch den Namen beinhalten, funktioniert die Ähnlichkeitssuche oder wie muss ich mir das vorstellen?
Marco Steinke Du kannst das theoretisch auch alles um deine indexbasierte Suche herumbauen. Das ist so der eine Ansatz, dass du zum Beispiel ein neues Schema erzeugst und in diesem Schema werden dann eben bestimmte Informationen in Vektoren übersetzt, die bei der Suche nützlich sein können und da reingelegt. Und wenn du dann da ein Match hast, also beispielsweise du gibst den Produktnamen ein und du erhältst dann dort über die Vektorsuche ein Match, dann kannst du natürlich dort einfach eine Spalte einfügen, die dann wieder in einem anderen Schema, also eine Referenz auf das andere Schema enthält, beispielsweise die Produkt-ID. Und dann kannst du darüber wieder auf das eigentliche Produkt zurückführen.
Sven Johann Oh, okay. Das ist natürlich ziemlich cool, weil ich meine, das ist ja gewissermaßen so ein bisschen das Problem, das man bei ChatGPT hat, relativ schwierig zu wissen, wie kommst du überhaupt da drauf. Aber hier kann ich sagen, ich kann mich praktisch mit dem Ding unterhalten. Ich kriege eine Antwort, aber ich kann natürlich auch eine Antwort provozieren, sozusagen mit dem, was du gesagt hast, wo ich praktisch die Links zur Produktseite bekomme und kann dann direkt draufklicken. Nice.
Marco Steinke Genau, das war bei uns dann eigentlich die Lösung, die dafür gesorgt hat, dass die Daten auch ordentlich wieder zurückgegeben werden, weil manchmal hat man auch wirklich dann nach einem Namen des Produkts gesucht und es gab es vielleicht 20 mal in verschiedenen Varianten und damit kann man dann vielleicht erstmal nicht weiter, aber durch die Links konnte man dann eben weiterführend diese Produktauswahl nehmen und dann noch mal zu den Eigenschaften eine Frage stellen, beispielsweise hergestellt ab 2021 und dann wird es eben noch mal weiter beschränkt werden. Das heißt, du hast dann so einen zweistufigen Suchprozess, dann tatsächlich dein Produkt auch gefunden und kommst von da aus dann wieder auf das eigentliche Produkt zurück. Das ist aber alles noch eine Suche und bei ChatGPT ist es ja wirklich so, dass es ja Antworten auf Grundlage von Daten generiert. Also das haben wir jetzt nicht getan. Wir haben wirklich einfach im ersten Schritt versucht, können wir diese Produkte überhaupt unterscheiden und wieder aus der Suche erhalten, wenn wir nach den Namen oder nach einzelnen Eigenschaften fragen. Und wenn es viele ähnliche Produkte gibt, dann muss man eben weitere Schritte überlegen, wie man die jetzt dann doch noch auseinanderhalten kann. Deswegen halt die Unterscheidung zwischen Titel und Eigenschaften, damit man dann einfach in einem zweiten Schritt nochmal eine ergänzende Frage stellen kann oder eine, es ist eigentlich eine Suchanfrage, um dann das eigentlich gesuchte Produkt auch dann finden zu können.
Sven Johann Okay, also würde ich vielleicht mal kurz auf unser Vorfiltern oder unser Filtern, ist eigentlich Nachfiltern zurückkommen. Also ich stelle meine Frage und ich brauche ein Produkt für, ich will ein Buch lesen, das von diesem und jenem handelt. Und dann bekomme ich vielleicht eine Antwort. Die sagt ja das, das, das, aber es gibt noch ganz viele mehr. Und dann würde ich sagen, ah, okay, zeigt mir aber nur die, die 2023 erschienen sind und die, keine Ahnung, auch auf Deutsch und als Hörbuch verfügbar sind. Und das wird praktisch so nachfiltern, dass ich da erreichen kann.
Marco Steinke Genau, also bei den Vektor-Datenbanken hast du auch immer die Option, dass du dann noch Filter anwenden kannst. Das ist dann eigentlich wieder wie bei relationalen Datenbanken wirklich die Produkte, die durch eine Vektorsuche dann gefunden wurden, dann nochmal klassisch nachfiltern.
Sven Johann Bei den Elasticsearchern gibt es immer den Spruch “know your data”. Also man muss seine Daten wirklich gut verstehen, um einen guten Index aufzubauen. Und hier hört sich das im Grunde genommen so ähnlich an. Also ich muss meine Daten gut verstehen. Ich muss wissen, nach was suchen die Leute eigentlich oder wie suchen die Leute. Und dann kann ich entsprechend meine Daten aufbauen. Also es ist nicht einfach so, ich werfe alles da rein, sondern ich muss mir schon Gedanken machen, wie würden die nachfiltern usw.
Marco Steinke Genau, deswegen auch die Anmerkung, dass die Daten nur für eine Suche vorbereitet wurden. Also wenn man beispielsweise dann andere Use Cases hat und die Daten dafür verwendet werden sollen, dann muss man die vielleicht auch vorher in ein ganz anderes Format bringen. Vielleicht muss man die auch noch mit weiteren Quellen dann ergänzen. Vielleicht muss man die PDFs mit dazu holen oder andere Dinge. Und da muss man wirklich immer genau anschauen, was wird eigentlich benötigt, also was macht der Endnutzer jetzt mit diesem System? Und wie kann ich wirklich sicherstellen, dass bei einer Anfrage auch die richtigen Daten gefunden werden? Und da muss man dann wirklich die Daten entsprechend zerschneiden, den Index anpassen, bestimmte Filter nachträglich einfügen, damit man dann wirklich diesen Use-Case irgendwie abbilden kann mit den Daten.
Sven Johann Das hast du eben auch gesagt, man kann nicht nur suchen, sondern ich habe halt auch, ich kann zum Beispiel auch eine Produktberatung machen. Das wären aber dann praktisch zwei unterschiedliche Use Cases, die ich auch unterschiedlich implementieren würde. Also ich hätte jeweils zwar Produktdaten zur Verfügung, um zu indizieren. Aber wenn ich meine Suche habe, dann indiziere ich das anders, als wenn ich eine Produktberatung machen will.
Marco Steinke Genau, also bei der Produktberatung muss man natürlich überlegen, was braucht man jetzt für Eigenschaften? Also mit dem Produktnamen und vielleicht mit dem Gewicht kommt man vielleicht nicht so weit. Vielleicht gibt es dann irgendwelche anderen Eigenschaften. Bei einem Buch gibt es vielleicht dann sowas wie die Kategorien, in die das Buch zählt oder vielleicht noch zusätzliche Informationen zum Autor, damit man das Buch auch besser einordnen könnte. Und dieses Beratungsfeature wäre natürlich jetzt so ein typischer LLM Use Case. Das heißt, man müsste drum herum halt noch viel mehr bauen. Man muss irgendwie diese Datenbank mit dem LLM verbinden und müsste natürlich dann darüber die Beratung stattfinden lassen. Wenn man jetzt einfach ein Beratungstool baut, eine normale Website, die vielleicht dann einem ein paar Informationen zusätzlich ausgibt, dann muss man natürlich dann die Datenquellen benutzen, die man hat, beispielsweise PDFs oder die reinen JSON-Daten, die man vorliegen hat und muss dann schauen, dass man natürlich da für eine Beratung nützliche Informationen rauszieht und die dann auf der Website entsprechend einblendet. Aber das hat noch nicht wirklich was mit Beratung zu tun, sondern man würde ja einfach dann Informationen, die für eine Beratung notwendig sind, beispielsweise Du arbeitest bei einem Kundendienst, der Kunde ruft an wegen eines Vertrags und möchte dazu irgendwas wissen. Dann lädst du natürlich in einem Schritt erst mal den Vertrag des Kunden und du könntest beispielsweise dann noch Ausschnitte aus Dokumenten, die für die Beratungsanfrage notwendig sind, dazuladen. Dann hast du das Dokument auf deiner Website vielleicht angezeigt und daneben Ausschnitte oder andere Dokumente auf derer Grundlage du den Kunden berätst. Und das ist natürlich dann immer noch so, dass die Beratungsleistung dann bei Menschen liegt, der dann mit dem Kunden spricht. Und da kann man die Suche aber trotzdem einsetzen, um dann einfach hilfreiche Dokumente auch zu finden, nicht nur Produktdaten.
Sven Johann Wenn ich auf die Suche zurückkomme, wie müsste ich mir eigentlich die Suche vorstellen? Also ich habe jetzt meinen Webshop und normalerweise hat man dann bei der Webshop hat man bei der Suche halt ein Freitextfeld, wo ich Sachen eingeben kann und vielleicht habe ich links noch so ein paar Filter für die Suche. Wie sieht das User Interface denn aus für so eine Vektor Datenbank Suche?
Marco Steinke Also eigentlich genauso. Man kann so eine Vektorsuche wirklich genauso verwenden wie eine normale Suchanfrage, so eine Suchmaske, die man auch kennt. Nur, dass dann nach dem Abschicken der Anfrage wirklich erstmal so ein Vektor berechnet wird. Also schreibst zum Beispiel in eine Suchanfrage rein, gebe mir alle Gerichtsprozesse aus dem Jahr 2022, wenn du jetzt zum Beispiel in der juristischen Branche unterwegs bist. Und dann würde aus dieser Suchanfrage dann erstmal ein Vektor berechnet werden. Das heißt, dein Text geht gar nicht an die Datenbank, sondern der würde dann im ersten Schritt von dir, weil du vielleicht ein eigenes Modell benutzt oder dann von der Datenbank, wenn du das vorgegebene Modell benutzen möchtest, dann embedded werden. Oft lohnt es sich wirklich ein eigenes Modell zu verwenden, weil natürlich jedes Unternehmen auch eine andere Domäne hat. Und innerhalb der Domäne kann man dann das Modell auch so ein bisschen, das heißt dann feintunen, um dann Repräsentationen zu bekommen, also Embeddings, die wirklich auch in deine Domäne passen, die dann vielleicht so fein geschliffen wurden, dass du bessere Suchergebnisse bekommst, wenn du dann dein eigenes Modell benutzt. Und das würde dann am Ende wieder in die Suchanfrage in der Datenbank geworfen werden. Also wirklich dieser Vektor geht in die Datenbank und liefert dir dann erstmal Vektoren zurück, von denen du dann deine eigentlichen Daten nachladen kannst. Das ist so der Ablauf bei so einer Suche. Das heißt, die Suchmaske selber würde sich erstmal nicht verändern müssen.
Sven Johann Okay, okay, dann macht es eigentlich Sinn, weil Elasticsearch kann das. Daher die Frage, eine indexbasierte Suche und eine Vektorsuche zu kombinieren. Also ich hab nur gesehen, Elasticsearch kann das, aber ich frag mich halt, okay, wie würde sowas aussehen? Also ich hab einfach meine Suchmaske, da kann ich Filtern und Sachen eingeben. Und jetzt hab ich dahinter, hab ich einen Vektor und ich hab einen Index. Also gibt’s da Use Cases, wo das Sinn machen würde? Oder würdest du sagen, ja, entweder machen wir das eine oder das andere?
Marco Steinke Also eine Kombination kann auf jeden Fall Sinn machen. Nehmen wir nochmal das Beispiel von gerade mit der juristischen Branche. Beispielsweise hast du eine relationale Datenbank, die komplett mit Fallakten gefüllt ist. Oder irgendwelche Prozessdokumente. Und es kann ja sein, dass dann diese Kanzlei, die wir uns jetzt gerade anschauen, einen neuen Fall reinbekommt. Und bei der Recherche für diesen Fall kann man sich vielleicht auf die tausend Fälle, die man vorher schon mal gelöst hat, dann berufen. Und du hast vielleicht Schlagworte wie, was ist jetzt wirklich der Anklagepunkt oder vielleicht gab es diesen Mandanten vorher schon einmal, vielleicht vertritt man den ja und da kommt vielleicht, weil es ein Unternehmen ist, was dich mit sensitive Informationen beschäftigt, vielleicht kommen da oft mal irgendwelche Datenschutzklagen rein und man verteidigt die sowieso die ganze Zeit dagegen. Dann kann man beispielsweise Anfragen stellen, die wirklich erstmal nach Dokumenten von diesem Kunden suchen. Oder du kannst Anfragen stellen, die nach ähnlichen Fällen suchen. Das heißt, du könntest sagen, Datenschutzanklagen, die man reinbekommen hat, bitte. Und dann würdest du aus der Vektor-Datenbank eben sämtliche Dokumente bekommen, die irgendwie diesen Anklagepunkt enthalten. Das kannst du natürlich auch mit normalen Filtern machen. Aber vielleicht gibt es ja auch immer irgendwelche verwandten Anklagepunkte, die nicht direkt das Wort Datenschutz beinhalten oder die vielleicht irgendwie in Randgebieten davon vorliegen. Und du könntest dann durch diese Suche wirklich Informationen bekommen, die dir helfen würden, bei diesem Fall erstmal zu recherchieren, indem du wirklich nach ähnlichen Dokumenten suchst und du könntest dann in diesen Dokumenten auch wirklich nach Abschnitten suchen. Also das ist ja der eigentliche Punkt. Du schreibst zum Beispiel rein, Datenschutzanklage in einem Online-Shop und dann würdest du eben nur wegen diesem Satz erstmal Ausschnitte bekommen aus verschiedenen Fallakten, die vorher mal existiert haben und könntest dann, wenn du diese Abschnitte bekommen hast, erstmal natürlich sehen, okay, was steht da jetzt drin, welche Informationen stecken da drin, helfen die mir weiter und wenn du dann einen Abschnitt interessant findest, könntest du den zum Beispiel dann in so einer Ergebnismaske anklicken und würdest dann direkt in den Index wieder rüber gehen, also in deine indexbasierte Suche und wird es dann dort beispielsweise direkt dann im kompletten Fall angezeigt bekommen. Das heißt, die Kombination hier ist, dass du diese Akten wirklich in Abschnitte zerschneiden kannst, die in die Vektor-Datenbank legst und wenn du nach etwas suchst, suchst du eben nur noch kleine Abschnitte und nicht nach dem ganzen Dokument, was eben die Genauigkeit extrem erhöhen kann, wenn du Deinen Punkt, den du suchst, wirklich dann mit einem kleinen Abschnitt vergleichst, ist da eben eine viel höhere Präzision möglich. Wenn es beispielsweise immer nur zwei, drei Sätze sind, die in so einem Abschnitt drin stecken und du kriegst bessere Vorschläge, was denn Ähnlichkeit hat mit deiner Anfrage und kannst dann die vollständige Information nachladen aus dem anderen Index.
Sven Johann Okay, also mein Ursprungsgedanke war, dass praktisch die Queries an beide gehen und dass man die zusammen merged. Aber ja, dein Fall ist eher, also ich gehe erst zu der einen und dann kann ich praktisch die Ergebnisse von der einen nutzen, um sie mit dem, was in der anderen Datenbank drin ist. Also um damit die Suche sozusagen zu beenden. Gib mir alle Ähnlichen und dann kann ich praktisch auf Basis von den Ähnlichen die konkreten Sachen suchen.
Marco Steinke Aber deine Idee, dass man beide gleichzeitig anfragt, könnte zum Beispiel in einem Onlineshop helfen, wenn man jetzt zum Beispiel die Produkt-ID kennt und man möchte dem Nutzer einfach noch so ein paar ähnliche Produkte mitgeben. Dann könntest du natürlich sagen, okay, der Nutzer hat jetzt nach Badeschlappen gesucht. Und da kennst du halt die Ergebnisse und du kannst die mit der indexbasierten Suche ausgeben und vielleicht hast du aber nur drei davon in deiner Datenbank drin. Und du kannst natürlich dann für bessere User Experience vielleicht dann mit der Vektor-Datenbank ähnliche Produkte nachladen, die dem Kunden vielleicht auch gefallen können, die darunter platzieren, damit der Online-Shop vielleicht gefüllter aussieht oder der Kunde vielleicht auch irgendetwas entdeckt, was er eigentlich gar nicht brauchte, aber vielleicht dann doch sich mal anschaut. Also eigentlich der übliche Use-Case. Man kann natürlich Daten dann auch auffüllen, damit man vielleicht einfach für User Experience bessere Inhalte liefern kann.
Sven Johann Ich bin ja Audible-Kunde und bei Audible ist ja so, ich werfe irgendwelche Sachen rein und da gibt es kein Audiobuch, aber dann weiß er schon Leute, die nach X, Y gesucht haben, die interessieren sich vielleicht für die Produkte, die so ähnlich sind. Und das wäre doch mal was hier. Das, das, das, das. Guck dir die doch mal an. Und wenn ich dann da drauf klicke, dann bin ich vielleicht nicht auf dem Suchindex, sondern dann bin ich direkt auf der Produktdetailseite. Genau, okay.
Marco Steinke Aber das wäre so ein Use Case, den man sich auch vorstellen könnte, dass man das mit der Vektordatenbank heutzutage sehr einfach umsetzen kann. Also man kriegt damit wirklich sehr einfach passende Empfehlungen beispielsweise dann generiert mit so einer Vektorsuche.
Sven Johann Hm, könnte ich mir, also wenn ich jetzt gerade an Audible denke, dann stelle ich mir halt vor, ich gebe irgendeinen Autor ein, ich als Kölner hier in meiner Nachbarschaft sozusagen, gebe ich Günter Wallraff ein, will Günter Wallraff Bücher, hat leider keine Audiobücher und dann wird was, also dann will ich eigentlich, dass mir alle Sachen gezeigt werden, die von Günter Wallraff sind, also die Bücher, die man tatsächlich im Index findet. Aber vielleicht nicht unbedingt nur die, sondern ich finde jetzt drei Bücher von Günter Wallraff oder vier. Und dann sage ich, okay, das reicht, ich bekomme vier Stück zurück, jetzt mache ich auch noch mal so eine indexbasierte Suche zum Anreichern. Also, das wäre ja auch so praktisch so kombiniert. Ich würde beide Queries absetzen, würde vielleicht nicht nur nichts zurückbekommen, sondern ich bekomme tatsächlich Treffer aus der Search Engine, die sind konkret, und dann würde ich unten drunter noch mal die aus der Vektorsuche hängen. Ja, interessant, ja.
Marco Steinke Genau, also das ist so ein typischer Use-Case für die Vektorsuche, den man auch wirklich ohne großen Aufwand, weil man ja vortrainierte Modelle benutzt, dann auch wirklich genauso umsetzen könnte. Man würde die Vektor-Datenbank dann wirklich daneben schalten. Und es gibt auch wirklich teilweise Fälle, wo man nicht mal eine separate Datenbank aufsetzen müsste, weil es eben wie Elasticsearch dann Tools gibt, die wirklich beides können. Da gibt es auch noch ein paar andere, da können wir vielleicht gleich noch einmal zukommen.
Sven Johann Genau, genau, also am Schluss können wir noch ein paar Produkte diskutieren.
Sven Johann Ich hätte noch eine Frage zum Thema Infrastruktursicht, so würde ich es mal sagen. Und zwar, wenn ich jetzt an Elasticsearch denke, Elasticsearch kann ja mit sehr großen Datenmengen umgehen. Wir haben fast beliebige Anzahl von Elasticsearch-Instanzen, die jeweils einen kleinen Teil von einem Suchindex beinhalten. Also ich kann meine Suchindizes, die gegebenenfalls gigantisch groß sind, die kann ich in viele kleine Teile zerhacken und hab dann so eine verteilte Datenbank und auch einen verteilten Suchindex. Wie muss ich mir das bei so einer Vektor-Datenbank vorstellen? Kann ich da auch einen verteilten Suchindex haben oder ist es sozusagen monolithisch?
Marco Steinke Also bei Vektor-Datenbanken kann man eigentlich beide Ansätze verfolgen. Und da ist eben der Unterschied, dass die Vektor-Datenbank ja versucht, diese ganzen Einträge in so eine Art Vektorraum zu legen. Das heißt, man kann sich das zum Beispiel mal zweidimensional vorstellen und hat einfach so eine Landkarte und man würde da jetzt wirklich, wie du vorhin meintest, einfach Orte reinwerfen anhand von Längen und Breitengrad. Dann könnte man zum Beispiel, wie man das vielleicht aus Atlanten kennt, dann einfach diese Karte zerschneiden in kleine Kästchen, die dann eine feste Größe haben. Und die Vektor-Datenbank macht eben intern genau so was. Du hast da etwas, das heißt, Locality-Sensitive-Hashes. Das heißt, das sind wirklich Hashes, die entscheiden, in welchen von diesen Kästchen jetzt der Eintrag fällt. Und wenn du eine Suchanfrage stellst, würde es zum Beispiel nur in dem umliegenden Kästchen dann gesucht werden oder vielleicht noch mit Radius 1 in den benachbarten Kästchen. Und dadurch, dass du sowieso von der Implementierung her so eine Aufteilung gegeben hast, könntest du dann auch die Vektor-Datenbank auf Basis dieser Kästen dann auch zerschneiden und auf verschiedene Instanzen verteilen. Das wäre eine Möglichkeit.
Sven Johann Okay, okay. Wenn ich es müsste, dann kann ich es, dann ist es vorgesehen und wenn ich es brauche, dann habe ich einfach meine eigene Instanz. Also die Frage mag vielleicht ein bisschen absurd erscheinen, aber jetzt bewege ich mich auf dünnem Eis. Also Neo4j, also die Graphdatenbank. Ich weiß nicht, ob die das mittlerweile kann, aber als ich mich mal vor einigen Jahren, vielen Jahren damit beschäftigt habe, da war das sozusagen eine Möglichkeit, in der Natur der Sache liegt, dass du sozusagen einen Graph hast und du hast keinen verteilten Graph. Damals haben die halt gesagt, okay, wir arbeiten da dran. Also, daher kommt die Frage, weil es nicht unbedingt immer möglich ist, je nach Datenbank-Typ.
Marco Steinke Also die Vektor-Datenbank versucht wirklich durch ihre Optimierung, dass man den Vektorraum selber nochmal in kleine Würfel zerschneidet oder einfach in kleinere Vektorräume, in denen dann wirklich gesucht wird. Durch diesen Ansatz ist es eben automatisch ermöglicht, dass man dann, wenn man jetzt mit der Implementierung, die man gewählt hat, auch Features hat, um das zu verteilen und dann es auch problemlos dann verteilen kann. Natürlich können das nicht alle Vektor-Datenbanken, manche haben auch noch an dem Feature gespart und arbeiten dann vielleicht mehr an der Optimierung, weil dadurch, dass du auch nur in einem bestimmten Vektor-Raum suchst, hast du eben einen extremen Vorteil gegenüber der indexbasierten Suche. Die benutzt zwar auch Index-Charts und du suchst dann auch nur in einem kleinen Teil des Indexes nach deinen eigentlichen Ergebnissen, aber dann suchst du trotzdem nach exakten Matches innerhalb dieses Charts und in der Vektor-Datenbank willst du immer noch in deinem kleineren Vektor-Raum, der dann ausgewählt wurde, für mögliche Ergebnisse immer noch nur nach bestmöglichen Ergebnissen suchen. Das heißt, du würdest wirklich schauen, welche Vektoren liegen jetzt in meiner nächsten Nähe, nehme die Top 5 und das beschleunigt das Ganze eben nochmal enorm.
Sven Johann Ich finde, guter Übergang zur letzten Frage. Und zwar, welche Produkte gibt es denn überhaupt? Gefährliche Frage: Welche Produkte lohnt es sich anzuschauen, aus deiner Sicht? Also, Elasticsearch haben wir ja schon genannt. Was gibt es noch?
Marco Steinke Also genau Elasticsearch ist so ein Produkt, das ist sowieso schon an ganz vielen Stellen im Einsatz. Und wenn man das schon verwendet, dann kann man sich davon auch mal diese Features anschauen, ob die vielleicht für zukünftige Pläne auch passend sind, ob man sich vielleicht damit noch ein paar Probleme vom Hals schaffen kann. Lohnt sich auf jeden Fall, wenn man sie schon einsetzt. Und abgesehen davon gibt es eben diverse Cloud-Services beispielsweise, die Vektor-Datenbanken anbieten, sei es Azure oder AWS oder die Google Cloud-Plattform. Und da gibt es dann eben auch teilweise Eigenentwicklungen, wie zum Beispiel Amazon mit dem AWS Kendra-Suchindex. Da hat man dann wirklich einen Suchindex, der intern eine Vektor-Datenbank verwendet und dann Ergebnisse erhält und diese Ergebnisse werden dann nochmal mit einem anderen neuronalen Netz dann sortiert. Also die werden dann wirklich gerankt und das ist zum Beispiel so eine Verbesserung an die Amazon auf jeden Fall dann glaubt.
Wir haben das auch mal eingesetzt und ein bisschen damit rumgespielt und haben da auch gemerkt, dass die Vektorsuche an sich funktioniert, aber wenn man wirklich wenige Daten hat, dann ist es auch für Kendra schwierig zu unterscheiden, dann ranked es quasi bei wenigen Ergebnissen, die es sowieso gefunden hat, noch diese wenigen Ergebnisse untereinander und dann kann es sein, dass das eine, was man eigentlich haben wollte, dann weiter unten gerankt wird, weil das einfach ein Machine Learning Modell ist, was dann versucht, das bestmögliche Ergebnis zu erzielen da, aber da muss vielleicht auch nochmal geschaut werden, dass man seine Daten dann dafür passend nochmal umstrukturiert, transformiert, weil man kann nicht einfach Daten, die vielleicht in einer normalen VektorDB mal gut funktionieren, einfach in Kendra werfen und kriegt dann die gleichen Ergebnisse oder bessere, sondern das Ranking kann, wenn man die Daten gar nicht verändert, auch zu schlechteren Ergebnissen führen. Da muss man dann noch mal extra Aufwand investieren.
Und wenn man jetzt nicht auf so einen Cloud-Service setzen möchte, dann könnte man beispielsweise auch PostgreSQL verwenden. PostgreSQL ist ja Open Source und hat jetzt inzwischen auch pgvector. Das ist dann eine Ergänzung für einen Vektor-Index. Und da kann man dann in seine Instanz herein beispielsweise die pgvector-Erweiterung aktivieren und könnte dann eine neue Tabelle anlegen und die verwendet dann auch direkt einen Vektor Index. Das ist sehr einfach aufzusetzen und funktioniert auch gut, führt zu in unseren Augen auch guten Ergebnissen und hat natürlich den Open Source Vorteil. Da kann man natürlich auch reinschauen, was passiert da wirklich, kann vielleicht, wenn man eine gute Idee hat, auch beitragen.
Und das Ganze kann man natürlich auch in diversen Cloud-Services wieder deployen. Also falls man schon eine PostgreSQL-Datenbank hat, kann man die auch gerne weiterverwenden. Und man kann die natürlich auch super einfach lokal aufsetzen, wenn man jetzt wirklich mal mit Vektor-Datenbanken herumspielen möchte.
Und ich glaube als letzte Alternative gibt es dann natürlich diese ganzen in-memory Datenbanken. Also in Python ist es zum Beispiel so, dass es dann eine ChromaDB gibt und wenn man jetzt wirklich sich die ganze Thematik einfach mal anschauen möchte und jetzt nicht viel mit Infrastruktur kämpfen möchte, dann kann man da so eine ChromaDB aufsetzen und die läuft dann wirklich in-memory lokal auf der Maschine und man kann dann da einfach mal Beispieldaten reinwerfen und damit rum experimentieren. Das ist auch gut geeignet für POCs um zu schauen, wie man jetzt wirklich mit der Datenbank sprechen kann. Und die Schnittstelle ist auch sehr ähnlich zu anderen Vektordatenbanken. Das heißt, das kann man dann später wieder, wenn man daran glaubt, dass einem das weiterhilft, sehr gut dann auf andere Datenbanken in Production beispielsweise übertragen.
Sven Johann Okay. Ja, damit also jetzt so mit PostgreSQL oder so hätte ich tatsächlich überhaupt nicht gerechnet, aber das ist natürlich ziemlich cool. Okay, ich habe noch zwei Produkte hier mir notiert, die mir in meiner, ich sag mal, in meiner LinkedIn Timeline immer wieder mal reingespült werden. Und zwar zum einen Weaviate, also da sind zumindest mal zwei von meinen ehemaligen Kollegen, die sind zu Weaviate gewechselt. Das heißt nicht, dass wir hier besonders positiv darüber reden müssen, weil ich lese immer unterschiedliche Dinge, ich lese immer, Weaviate ist das Beste, aber ich lese auf der anderen Seite, man braucht eigentlich keine eigene Datenbank, so wie Weaviate, also behauptet zumindest mal Elasticsearch. Und dann noch Neo4J.
Marco Steinke Also zu Weaviate bin ich noch gar nicht gekommen, damit hab ich mich selber noch nicht beschäftigt. Also Neo4j, da kann ich natürlich jetzt deine vorherige Frage nicht beantworten, ob die das inzwischen auch verteilen, also diesen ganzen Graphen oder nicht. Aber das ist natürlich wieder so eine Sache, du kannst das, wenn man jetzt im LLM-Kontext unterwegs ist, der ja auch sehr verwandt ist mit Vektor-Datenbanken, geht man da inzwischen auch in die Richtung, dass man zwischen den Dokumenten, die man erzeugt hat, also beispielsweise den Absätzen aus Blogartikeln oder anderen Dingen, Verbindungen herstellen möchte. Und das kann man dann wieder sehr gut über Graphen machen. Und dann beispielsweise, wenn man eine Sucheanfrage stellt, dann auch mit Hilfe so einer Graphenstruktur dann die Vektoren in der Datenbank ablegen. Und dann kann man, wenn man einen Vektor erhalten hat, den quasi als Einstiegspunkt in einen Graphen sehen. Also du stellst irgendwie eine Query an die Vektor-Datenbank. Und was du zurückbekommst, ist dann der Einstiegspunkt in einen Graphen, der dann in so einer Neo4j-Instanz zum Beispiel liegt. Und da kann man sich dann eben durch Queries, durch den Graphen arbeiten. Das ist auch so ein Ansatz, den man verfolgen könnte. Und der sich eben auch wieder lohnt für Produktempfehlungen oder um die Daten weiter aufzufüllen.
Sven Johann Okay. Okay, super. Ja, vielen Dank auf jeden Fall, Marco. Ich hoffe, unseren Zuhörern hat das viel gebracht, mir auf jeden Fall. Also ich bin jetzt auf jeden Fall viel schlauer als noch vor einer Stunde, was das Thema angeht, obwohl ich mich ein bisschen darauf vorbereitet habe. Aber so ein paar, wenn man mit jemandem redet, der weiß, was er sagt, ist natürlich immer wieder was anderes. Okay, ja, wie gesagt, vielen Dank. Und vielleicht noch der Hinweis, noch mal, wie habe ich am Anfang gesagt, morgen, also einen Tag nach unserer Veröffentlichung, geht es noch mal ein bisschen tiefer mit Ole und Robert zum Thema RAG. Gut, dann, bis dann. Tschüss.
Marco Steinke Tschüss!