RAG

Robert: Hallo und herzlich willkommen beim INNOQ Podcast. Ich bin Robert und ich habe meinen wunderbaren Kollegen, den Ole, heute zu Gast. Ole, wie geht es dir? Warst du wandern?

Ole: Hallo Robert, mir geht es sehr gut. Das Wetter hier in der Schweiz ist ein bisschen durchwachsen, aber wir hatten ein hervorragendes Wochenende. Ich war tatsächlich wandern, der erste Gipfel des Jahres. Oben hatten wir noch ein paar Schneefelder, aber ansonsten tipptopp Wetter, fast Sonnenbrand. Es geht wieder los.

Robert: Hier liegt auch überall noch Schnee auf den Bergen bei mir. Ich sitze nicht in der Schweiz, ich sitze ganz im Süden von Deutschland. Jetzt kann der Schnee aber wirklich Mitte Mai auch mal verschwinden. Ich habe es satt.

Ole: Ja, die Skisaison ist langsam vorbei, das stimmt schon.

Robert: Ja, genau. Bald fahren wir im August noch Ski. Aber du bist heute zu Gast bei mir, um nicht über Skifahren und Wandern und ganz viele andere tolle Sachen zu reden, sondern über was Technisches Tolles. Und zwar haben wir ja gerade sowas wie eine Mini-Reihe zu AI-Themen bei uns im Podcast. Und heute wollen wir über das Thema RAG sprechen. RAG steht für Retrieval-Augmented Generation.

Für einige von euch oder viele von euch, wir wissen es nicht, die das schon mal gehört haben, ist das vielleicht ein Begriff. Lass uns aber ganz zuvor noch mal bitte klären, was ist RAG, in welchem Kontext spielt das, damit wir so eine Grundlage legen, bevor wir dann gleich tiefer einsteigen können.

Ole: Genau, ich glaube, da kann man am besten hinten fast anfangen. Also, wie du schon sagtest, Retrieval-Augmented Generation. Der Generation-Teil, also die Generierung, da geht es wieder um Large-Language-Models. Die sollen uns was generieren. Im Normalfall Text, da sind die supergut drin. Dann kommen wir zum zweiten Wort, das augmented, das ja eigentlich was die Anreicherung ist. Was wird angereichert? Das ist das Kontext-Window dieses Large-Language-Models. Also wir reichern das Kontext-Window an, damit er uns was Besseres generiert. Und der erste Teil, das Retrieval, ist sowas wie Abfragen oder Bergen. Und es geht um das Abfragen und Bergen von Wissen. Also man kann verschiedene Retriever nutzen und die sammeln dir Wissen zusammen, geben das reich an dein Kontext-Window damit an und dann kann dir dein Large-Language-Model hoffentlich aktuellere oder genauere Dinge generieren, als es so von sich aus könnte. Jetzt gehe ich ein bisschen in die Technik der Large-Language-Models. Die haben ja einmal so ein Langzeitgedächtnis, würde ich das mal nennen. Das ist das, was sie so in ihrer Trainingsphase lernen. Das hat aber auch ein Cut-Off-Date, also bis zu dem Zeitpunkt, wo das Internet gekollt wurde und danach lernen sie ja nichts mehr. Und dann haben sie dieses Arbeits- oder Kurzzeitgedächtnis und das ist das Kontext-Window und das wird halt dann aufgeladen mit den Dokumenten, die sie retrieved haben.

Robert: Das heißt, wenn wir hier von Large-Language-Models reden, reden wir über große, aber auch kleinere. Meistens sind sie alle irgendwie large. Und du sagst vollkommen korrekt, die haben meistens sehr lange Trainingsphasen hinter sich, sogenanntes Pre-Training. Das dauert am längsten. Dann kommen noch andere Stadien, die sich danach anschließen. Aber im Großen und Ganzen nennen wir es einfach mal Training. Wenn das fertig ist, weil das so lange dauert, das kann, glaub ich, bis zum halben Jahr dauern bei den ganz großen Kisten, da muss man natürlich irgendwann sagen, wir fangen jetzt mal an mit dem Training, und ab hier das Wissen fließt natürlich nicht mehr ins Training ein, was sich danach im Internet oder in anderen Quellen, die auch oft Teil dieses Trainings sind, angesammelt haben, eben nicht mehr rein.

Und die Hersteller bezeichnen das als sogenanntes Cut-Off-Date. Aber wovon wir hier reden, sind halt irgendwie schon Weltmodelle. Da ist ganz viel Weltwissen drin. Deswegen sind die auch, je größer die sind oder je öfter sie trainiert wurden, halt sehr, sehr gut da drin, die unterschiedlichsten Arten von Fragen zu beantworten. Und RAG setzt genau da an, an dem Wissen, dass sie eben nicht haben können, weil es nicht öffentlich ist oder nicht in den Trainingsdaten lizenziert wurde. Hast du so ein Beispiel? Man nennt das ja oft Unternehmenswissen.

Ole: Ja, alles, was du eigentlich nicht möchtest, dass man das im Internet lesen kann. Wenn man ein großer Automobilhersteller ist, können das alle Handbücher zu deinem Automobilmodell sein. Nehmen wir den aus Wolfsburg, alle Dokumente zum Golf zum Beispiel. Das können ja schon etliche tausend Seiten an Dokumenten sein, wenn man alle Pläne da zusammennimmt und das ist häufig auch Werkstatt-Spezialwissen, was nicht überall verfügbar sind. Eigentlich alles, was große Datenmengen sind, die du normalerweise, die das Modell nicht im Internet gefunden haben kann. Also sie werden ja mit Internetdaten trainiert.

Robert: Warum ist denn das überhaupt? Also wer hat RAG erfunden und warum hat man das erfunden? Da sollten wir vielleicht noch mal kurz darauf eingehen, weil ich könnte jetzt die ganz naive Frage stellen, wozu brauche ich das denn? Ich kann doch einfach in mein Confluence, wenn ich Confluence einsetze, es gibt auch andere Wikisysteme, einen Suchbegriff eintippen. Und da ist ja viel von meinem Unternehmenswissen drin, oder?

Ole: Ja, theoretisch ist das auch schon so gar nicht ganz weit weg. Kommen wir erstmal zu, wer es erfunden hat. Also das kommt aus dem Jahr 2020 und ein Patrick Lewis von der FAIR, das ist die Facebook AI Research Institute und Eason Parris von der NYU, das ist die New York University, haben das gepublished. Der Link zwischen den beiden ist Yann LeCun, der ist sowohl Professor an der NYU als auch der Head AI Researcher an der FAIR.

Den Namen sollte man sich eh merken, Yann LeCun. Der hat einen richtig guten Podcast bei Lex Friedman. Also es ist schon die zweite oder dritte Session bei Lex Friedman. Aber ich kann eigentlich alle empfehlen. Der Mann hat es verstanden. Es lohnt sich auf jeden Fall, auch ihm immer zuzuhören. Also das ist ein 2-Stunden-Podcast. Da muss man ein bisschen Zeit mitnehmen. Aber man geht auf jeden Fall schlauer raus, als man reingegangen ist und es ist keine verschwendete Zeit.

Robert: Nee, das finde ich auch. Den letzten habe ich auch gehört, waren intensive zweieinhalb Stunden, glaube ich sogar, und ich musste ganz oft zurückspulen, weil der Mann einfach unglaublich smart ist. Da kann man wirklich viel lernen, aber da geht es auch so um die Frontiers, die Grenzen von großen Sprachmodellen und wie überwindet man die, und die machen da ganz viel Grundlagenforschung. Irrsinnig interessant. Kann zu Hirnschmelze führen.

Ole: Ich habe deine Frage nach dem Warum gar nicht beantwortet. Diese Kontextwindows, die sind begrenzt, das Arbeitsgedächtnis, das hängt in dem Attention-Mechanismus. Die können sich einfach nur begrenzt Dinge merken. Also, beim Attention-Mechanismus hat man Speicherbedarf gegen Parallelität getauscht. Man kann mit dem Attention-Mechanismus Dinge parallel trainieren, was man vorher nicht konnte. Dafür haben sie einen quadratischen Speicherverbrauch, was das Kontext-Window angeht. Darum kann man die nicht beliebig groß machen. Und am Anfang war das ein sehr hartes Limit. Da kriegt man gar nicht viele Wörter in so einem Kontext-Window. Oder ehrlich gesagt, das sind Tokens. Aber ich sag hier mal Wörter. Man bekam halt einfach nicht viel rein. Also große Handbücher und so weiter kriegte man nicht in ein Kontext. Wenn nur das ändert sich gerade, ist aber auch noch so Work in Progress. Früher kriegte man da nur ein paar Tausend rein. Mittlerweile geht es Hunderttausende und Google kann jetzt Millionen oder sogar 10 Millionen. Aber das ist halt auch brandneu und auf jeden Fall nicht 2020, als RAG aufkam. Also die Kontextwindows waren einfach begrenzt. Man konnte nicht alle seine Handbücher da reinwerfen oder sein Unternehmenswissen. Und der andere Hauptfaktor war Geld. Also bei den Large Language Models, die von OpenAI oder Anthropic betrieben werden, bezahlt man pro Input-Token und pro Output-Token Geld. Das heißt, je mehr man da reinwerfen muss, desto mehr Geld bezahlt man. Wenn man das jedes Mal mit 10.000 Seiten Dokumenten aufladen muss, wird es halt entsprechend teuer.

Robert: Also ich fasse zusammen, wenn wir hier vom Context-Window reden, das hatten wir schon mal in der Folge zu Prompting kurz besprochen, was das ist. Ich fasse noch mal kurz zusammen, wenn ich mit einem Large-Language-Model rede, was ich ja nicht tue, aber wenn ich da etwas reingebe, dann gibt es dafür eine Maximallänge und die variiert über die verschiedenen Modelle. Mittlerweile könnte man, glaube ich, sogar fast sagen, es ist eine Architekturentscheidung, weil auch kleine Kontextlängen können sinnhaft sein. Ich muss nicht immer mit einem Millionen Tokens wie Gemini 1.5 Pro um mich werfen, ist nicht für alle Anwendungsfälle schlau, ist ja auch eine Kostenfrage.

Aber dieses Kontext-Window ist halt heute noch begrenzt mehr oder weniger klein, mehr oder weniger groß. Wenn wir uns einen längeren Chat mit ChatGPT kennen, sicher viele Hörerinnen und Hörer vorstellen, der über Tage und Tage geht. Auch dort ist das Eingabe-Kontextfenster mittlerweile relativ groß. Aber irgendwann laufe ich da raus, je länger so ein Chat wird. Und ein Chat ist ja nichts anderes als eine Abbildung von Fragen und Antworten. Also eine lange zusammenhängende Menge von Text bzw. Tokens.

Wenn ich da rauslaufe, merke ich das nicht. Dann kommen so merkwürdige Dinge wie, man kann das ganz schön beim Programmieren sehen, wenn man immer wieder ganz große Klassen da reinlädt, Fragen dazu stellt, sich Bugs fixen lässt oder Features, Methoden erweitern lässt. Irgendwann passieren komische Sachen, die sind meistens darin begründet, dass ich aus dem Kontextfenster gelaufen bin, weil meine Infos von vor drei Tagen oder ganz weit oben in diesem Chat einfach dem LLM nicht mehr bekannt sind. Also sie sind aus dem Gedächtnis schon wieder raus.

Da gibt es aber keine Indikation in den meisten Chatbots dafür, die ich da verwende. Und mit RAG hast du jetzt gesagt, das war ein Ansatz, diese damals noch kurzen Kontextfenster quasi zu verlängern, weil ich einen Zufütterungsmechanismus entwickle, richtig?

Ole: Genau. Genau. Also, Kontextwindow und Preis waren so die Hauptfaktoren. Es gibt aber noch weitere Vorteile, die mittlerweile, glaube ich, sogar wichtiger werden über die Zeit, weil diese Kontextwindow und der Preis wird immer günstiger und die Kontextwindows werden immer größer. Darum nimmt die Bedeutung dieser beiden Punkte ab. Aber es geht halt auch um Wissen wie Datenschutz zum Beispiel. Man kann diesem RAG Informationen zur Verfügung stellen, die du nicht ins Internet stellen möchtest. Und es ist aktualisierbar. Das ist ja, wie du schon sagtest, die Pre-Trainings-Läufe sind ja mittlerweile unfassbar teuer und können auch ewig lange dauern.

Ich musste letztens lachen. Ich habe ein Paper gesehen, wo sie ganz stolz darauf waren, dass ihr Pre-Training nur 80.000 Dollar gekostet hat, wo ich dachte, ja eigentlich ist das sehr günstig, aber 80.000 Dollar ist halt auch doch nicht so ganz günstig. Ich weiß nicht, dass du es dauernd machen möchtest. Und die Großen sind halt schon in zweistelligen Millionen-Bereichen. Dann ist 80.000 tatsächlich ein Schnapper, aber wenn du ein Mittelständler bist, würdest du das auch überlegen. Und darum die Aktualisierbarkeit. Man kann Dokumente dort drin aktualisieren, ohne neues Pre-Training zu machen.

Das ist im Punkt Korrektheit, beziehungsweise du kannst das Wissen übersteuern, was sich das Large-Language-Model in seinem Pre-Training angeeignet hat. Es bildet ja eine Abstraktion über das, was es im Internet gelernt hat. Und diese Abstraktion enthält eine Ungenauigkeit mit drin, sonst wäre es keine Abstraktion. Und dort kannst du es halt mit sehr konkreten Zahlen und Fakten nochmal anreichern und nochmal übersteuern. Beziehungsweise auch abweichen von dem Wissen, was er gelernt hat. Also neue Werte, neue Drücke, neue Medikamentendosen, was auch immer ihm beibringen. Und du hast Zugriff darauf. Also du kannst besser auswählen, was er an Wissen überhaupt bekommt. Du kannst ihm so eine gewisse Diät verpassen, dass er, wenn du jetzt Automobilhersteller ist, dass er nicht deine Konkurrenz empfiehlt zum Beispiel. Sag den anderen, die haben solche Probleme mit der Lenkung nicht. Das wäre natürlich auch etwas ungünstig.

Robert: Ja, das ist komplett richtig. Wenn wir uns mal jetzt so einen typischen griffigen Beispielfall ausdenken, den allseits beliebten Kundensupport-Chatbot. Alle sind wir schon geplagt gewesen die letzten zehn Jahre von diesen Dingern, weil die einfach meinten, das ist die totale Holzklasse und jetzt hat man eine Technologie, die wirklich auf echte Sprache gut eingehen kann und versucht hilfreich Informationen zu liefern. Aber wenn die halt auch auf Modellen basiert, die zwar auf ein großes Weltwissen trainiert sind, können die nur von außen auf ein Unternehmen gucken.

Wenn ich zum Beispiel intern Informationen habe, dass mein, weiß ich nicht, meine Limo, ich bin Limo-Hersteller, sage ich jetzt einfach mal, dass meine Gurkenlimo super oft retourniert wird, weil da irgendwie den Leuten zu viele Bitterstoffe drin waren, weil in einer Charge zu viele Gurkenkerne mit vermahlen wurden oder solche Geschichten. Die Informationen kann ein Weltmodell ja gar nicht haben, weil das interne Unternehmensinformationen sind. Wenn ich mein Chatbot, also mein Large Language Model, was in einem Chatbot den Kunden zur Verfügung gestellt wird, um sich schnell Support zu holen, da diese Infos bereitstellen und natürlich entsprechend moderiert, habe ich eine völlig andere Handhabe.

Lass uns mal gucken, wo wir jetzt wissen, was RAG ist, was ich damit so tun kann, vielleicht so ein bisschen tiefer einsteigen. Wir können ja mal bei diesem Limo-Hersteller-Beispiel bleiben. Der Limonade Stand ist ja ein allseits beliebtes Beispiel. Auch im BWL-Studium. Immer ein schöner Businesscase. Jetzt bin ich halt ein Limo-Hersteller. Und ich hab ganz viel Unternehmensdaten. Sagen wir einfach mal, wir haben ein umfangreiches Wiki, wo Dinge drinstehen, die nicht im Internet stehen. Wie zum Beispiel ein Haufen von Architekturentscheidungen, sogenannte ADRs. Ganz vorbildlich haben die zehn Jahre lang die Architekturentscheidung für ihren E-Commerce-Shop dort abgelegt, mehr oder weniger vollständig. Was haben sie noch gemacht? Entscheidungsprotokolle von Management-Sitzungen, aber auch einfach Marketing-Texte noch und nöcher, vielleicht irgendwelche Newsletter oder so was, irgendwelche HR-Dokumente wie über die Einstellungen und Entlassungen und all das, was in so einem Unternehmenswiki drinstehen kann.

Dann hat man typischerweise im Unternehmen nicht nur ein Wiki. Wir kennen das glaube ich alle. Man hat immer viele Datentöpfe in so einem Unternehmen, mal mehr, mal weniger gut bekannt. Wir können aber jetzt erstmal bei diesem bekannten zentralen Beispiel des Wikis bleiben. Wie komme ich da ran, wenn ich jetzt ein Chatbot bauen möchte oder eine andere Software, die mit einem Large-Language-Model dieses Wissen zugreifbar machen soll?

Ole: Genau, man würde sich erstmal die Eingabe des Chats nehmen, dann würde man sie vielleicht auch erstmal, wenn ich zusätzliche Kontextinformationen habe, würde ich die auf jeden Fall damit anreichern. Und das würde ich dann in meinen Retriever stecken. Und mein Retriever sucht mir, ich lasse das jetzt erstmal abstrakt, wir können später noch drüber reden, was genau so ein Retriever ist. Und der durchsucht das Wiki, durchsucht alle Informationen, die er glaubt, zu dem Thema relevant sind.

Erst dann, wenn er alles gefunden hat, gibt er meine Suchanfrage plus alle gefundenen Dokumente in das Kontextfenster des LLM und bittet das LLM, mir die passende Antwort dafür zu generieren. Und genau, dann hat man meistens noch irgendwelche Safeguards vorne und hinten, die sicherstellen, dass man nicht versucht, irgendwas Dobes zu machen. Also es gibt ja immer genügend Leute, die versuchen, irgendwas kaputt zu machen, das sollte man versuchen auszuschließen. Genau, und dann generiert das dir deine Antwort und das, was er gefunden hat, bleibt aber auch in dem Kontextwindow. Das ist jetzt so ein bisschen angewärmt. Und dann kann man halt darauf folgende Fragen stellen und während der Session wird das Wissen des Chatbots immer größer oder die Session tatsächlich und umso besser und prägnanter werden auch eigentlich seine Antworten.

Robert: Dann lass uns doch direkt mal bei dem Kern des Pudels ansetzen, dem sogenannten Retriever, um bei Hunde Metaphern zu bleiben. Also du hast gesagt, ich gebe quasi meinen Nutzerprompt hier rein. Das könnte eine Frage sein, wie welche Limo-Modelle haben wir seit Beginn des Unternehmens hergestellt und verkauft? Ganz einfache Frage, um mal jetzt noch nicht ins Reasoning einzusteigen. Was passiert dann? Was macht der Chatbot dann mit dieser Frage?

Ole: Jetzt kommt es darauf an, was genau man für einen Retriever hat. Also wenn man irgendeinen Amazon-Kendra hat zum Beispiel, der wird eine Suche über, also der hat sich irgendwann vorher die ganzen Wikidaten durchgelesen, hat das wahrscheinlich in einer Vector-Datenbank gespeichert und wird dir versuchen, die besten Dokumente dafür zu geben.

Robert: Also ein Suchindex könnte ein Retriever sein.

Ole: Es ist ein Suchindex. Am Ende könnte man es als Suchindex. Und da fangen die Probleme auch schon an, weil jeder, der ein größeres Projekt gemacht hat, suchen ist nicht trivial. Manchmal, glaube ich, geben wir Google nicht genügend Credit für das, was sie machen, weil die LLMs brauchen ja auch immer einen Kontext, in dem sie suchen. Wenn man doofe Fragen stellt, was ist mein bestes Urlaubsziel, dann weiß auch jeder Mensch, also dein Freund, der weiß das vielleicht, aber der Mitarbeiter vom Reisebüro weiß es halt auch nicht und diese LLMs können viel, aber Gedanken lesen gehört halt dann doch noch nicht dazu. Und da ist des Pudels Kern, suchen ist halt schwierig. Und wenn du ein schlechtes System aufbaust oder das erstmal nur ganz trivial angeht, dann kriegt er auch wahrscheinlich die falschen Dokumente raus oder nicht unbedingt die passendsten Dokumente. Und dann generiert er auch keine guten Antworten. Also was im Kontext-Window nicht drin ist und was er im Internet nicht gesehen hat, darüber kann er halt keine schlauen Antworten finden. Und dann kommt das Problem, dass die LLMs extremst freundlich sind und ein bisschen überzüchtet sind, dir immer eine Antwort zu liefern. Und wenn er nicht weiß, dann fängt er halt an zu fantasieren. Das wird dann halt schlecht.

Und es gibt noch ein zweites Problem. Also erst mal suchen ist schwierig. Und dann das Ergebnis zurückzugeben, ist auch nicht ganz trivial. Also sagen wir, da liegen Zehntausende an Seiten von Dokumenten. Er muss ja dann auch das richtige Dokument mit den richtigen Informationen rausschneiden. Das heißt, wenn ich jetzt eine Überschrift des Absatzes gefunden habe, muss er wissen, dass er möglichst das unter der Überschrift gibt und nicht einfach 200 Zeilen vor der Überschrift und 200 Zeilen unter der Überschrift, weil sonst schneidet er vielleicht was Wichtiges ab. Oder bei Tabellen kann es noch dramatischer sein, wenn du irgendwelche langen Messreihen hast, weil du irgendwas mit Messtechnik machst zum Beispiel. Du hast das so in CSV-Dateien abgespeichert und er entscheidet sich, den Header der CSV-Datei abzuschneiden und dir nicht mitzuliefern. Dann kann da halt auch nur Murks bei rauskommen, weil er überhaupt nicht mehr weiß, was die Spalten für eine Bedeutung haben. Also, du hast zwei Probleme. Das Suchen und das Zurückgeben. Und das sind keine trivialen Probleme. Das heißt, es gibt YouTube-Beispiele, RAG in 20 Minuten implementiert. Schwierig, schwierig.

Robert: Ja, kann ich mir vorstellen. Und lass uns bei dem Case bleiben. Ich bin jetzt neu in diesem Limo-Unternehmen. Ich mache gerade mein Onboarding und ich möchte einfach mal wissen, es ist ein langjähriger Familienkonzern dieser Limo-Hersteller. Was haben die denn in den Seiten, die Firma gibt eigentlich für unterschiedliche Limosorten hergestellt? Noch nicht mal wie waren die Verkaufszahlen dafür? Welche waren die erfolgreichsten? Ich will einfach erstmal eine Übersicht bekommen. Wenn du jetzt sagst, dieses Ausschneiden der relevanten Informationen, dass das der Retriever auch passend vornehmen kann, um es dem LLM zuzufüttern, damit es daraus die Antwort generieren kann, bin ich da nicht auch auf extrem gut strukturierte oder überhaupt eine gute Datenqualität angewiesen?

Ole: Gute Daten sind auf jeden Fall hilfreich, würde ich sagen. Da kommen wir jetzt wieder so ein bisschen in den Bereich der Vector-Datenbanken. Die sind halt extrem gut, wenn du unstrukturierte Daten hast. Wenn du Dokumente hast, PDFs, Wiki-Einträge und so weiter, da schlagen sie, glaube ich, die aktuellen Such-Engines, sei es ein Elasticsearch oder Solar, immer. Wenn ich die Daten wirklich gut im Griff habe und gut strukturiert habe, und darauf Suchen formulieren kann, dann haben solche alten Suchmechanismen überhaupt völlig ihre Berechtigung. Da spricht überhaupt nichts gegen das. Und da kann man auch LLMs für nutzen, dass du SQL-Abfragen formulieren kannst, wenn du ihm vorher beigebracht hast, wie deine Datenstruktur aussieht. Prinzip, wie du die Daten kriegst, ist erstmal dir überlassen. Sie müssen nur halt am Ende im Kontext landen. Und wenn du deine Daten gut im Griff hast, kann noch traditionelle Suchansätze völlig valide sein.

Robert: Okay, du hast gesagt, wenn der Retriever die Sachen zusammengestellt hat, dann müssen die im Kontextfenster landen. Das heißt doch übersetzt, wie landen die da drin? Werden die einfach quasi in ein großes, sehr großes Prompt konkateniert, was dann dem LLM reingegeben wird? Oder wie sieht das aus? Wie landen die im Kontextfenster?

Ole: Im Prinzip kann man sich das so vorstellen. Also kommt ein bisschen davon an, wie du die Daten kriegst. Aber am Ende landen sie eigentlich in deinem Prompt. Manchmal müssen die nochmal durch einen Encoder oder Aufbereiter gehen. Aber ja, eigentlich landen sie erstmal in deinem Prompt und füllen damit dein Kontext-Window auf.

Robert: Das heißt aber auch, wenn ich eine große Menge an Suchergebnissen im Retriever habe, blähe ich ja das Prompt unter anderem auf. Also unter Umständen blähe ich das Prompt auf und ich bin dann auf Gedeih und Verderb an die Größe des Eingabekontextfensters des LLMs gebunden.

Ole: Richtig. Das ist genau das Problem, mit dem das Ergebnis richtig zusammenschneiden. Wenn du einfach viel zu viel nimmst, dann wird es A, wieder teuer und B, läufst du das Risiko ein, dass du in dein Kontext-Window reinläuft. Und das wird auch wieder eine feine Stellschraube, wo man optimieren muss. Man muss wahrscheinlich vergleichen, ab wann kriege ich diminishing returns, also ab wann schreibe ich zu viele Informationen rein und kriege wenig zurück. Und es führt auch noch dazu, diese LLMs können verwirrt werden. Wenn du zu viele Noise-Informationen, zu viele Randfakten da reinstöpselst, versucht er manchmal auch daraus, irgendwelche Zusammenhänge zu erkennen und Muster zu erkennen, was dann eher wieder zu Halluzinationen führt.

Robert: Okay, aber grundsätzlich hilft es natürlich diesen Kontext schon auszureizen, also möglichst viel reinzugeben, damit eben die Transformer-Technologie ist ja darauf gedrillt, Antworten zu geben. Wenn wir Kollegen im Meeting fragen, sag du doch mal was zu folgendem Thema, ist auch nur sehr menschlich, dann sagen die nie null, wenn sie es nicht wissen. Menschen sagen meistens als Antwort irgendwas, ob sie es wissen oder nicht, ist alles so herrlich grau.

Ich glaube, wenn man das ähnlich bei LLMs antizipiert, die sogenannte Nullhypothese, die tritt selten ein, dass da einfach nichts zurückkommt, dann kann man architektonisch schon viel berücksichtigen bei der ganzen Geschichte. Du hast gesagt, es wird halluziniert. Sobald eben kein Wissen in den Trainingsdaten vorhanden ist oder per RAG zurückkommt. Ich glaube, das kann man auch reduzieren, indem man ein möglichst großes Modell nimmt, weil die deutlich weniger zu Halluzinationen neigen, oder?

Ole: Man kann es auch steuern über den Prompt. Also in der Anweisung an das LLM kann man reinschreiben, Dinge wie frag noch mal nach, wenn du es nicht weißt oder wenn du dir sehr unsicher bist über die Informationen. Dann ist es völlig valide und das ist ja auch der große Vorteil von so einem Chat-Interface, dass man wirklich mit ihm reden kann, wie mit einem Menschen und er eventuell nochmal Informationen nachfordert. Das tut er fast ein bisschen zu wenig. Es wäre in solchen Szenarien besser, er würde das häufiger machen und sagen, ich weiß es nicht, anstatt irgendeine Antwort da zu erfinden. Aber ja, du sagst, es ist menschlich. Könnte auch guter Consultant sein. Die sagen nie, dass sie keine Antwort haben.

Robert: Ja, wir haben jetzt auch schon ein paar RAG Cases umgesetzt. Und da haben wir, ich erinnere mich auch an einige Promptschleifereien, dass wir auch gesagt haben, sobald du keine Antwort zu dieser Frage liefern kannst über das Wissen, was dir vorliegt, sage es bitte explizit und biete an, dass man dir weitere Informationen gibt, damit du die Frage beantworten kannst. Und das klappt dann auch ganz gut.

Okay, jetzt haben wir, wir haben ja schon fast diesen Durchstich gemacht, von vorne rein bis hinten ins LLM. Und wie ich finde, man sieht schon, es steht und fällt viel mit dem sogenannten Retriever. Wann würdest du denn sagen, sollte ich einen klassischen Suchindex einsetzen und wann eine Vektordatenbank? Wir setzen jetzt so ein bisschen auf dem Wissen auf, was wir in der Folge zu Vektordatenbanken hatten, die lief vor dieser Folge. Hört mal rein, wir können in dieser Folge nicht ganz tief in das Thema Vektordatenbanken eintauchen, aber du hattest vorhin gesagt, wenn ich unstrukturierte Daten habe, dann sind Vektordatenbanken besser. Was heißt denn unstrukturiert? Sind das vielartige Formate oder einfach schlechte Daten? Was meinst du damit?

Ole: Gar nicht schlecht. Vielartig trifft es eher. Wenn ich von strukturierten Daten rede, meine ich klassisch eher sowas Richtung Datenbank. Ich habe meine Tabellen, ich habe meine Spalten. Ich weiß genau, was in jeder Spalte drin steht. Und unstrukturierte Daten ist immer dann, wenn so ein Fließtext, zum Beispiel Wikipedia, ist eigentlich unstrukturiert. Oder PDFs, Handbücher, alles, was für Menschen gemacht ist, würde ich häufig als unstrukturierte Daten sehen, wo man normalerweise irgendeine Suchmaschine oder einen Suchindex draufbauen würde. Das ist für mich unstrukturiert. Unsere Vektordatenbanken, also der Kniff dahinter ist, diese Vektoren stellen Bedeutung dar. Es gab so ein Word-to-Vect-Paper, wo man herausgefunden hat, dass man die Bedeutung von Dingen innerhalb von Vektoren darstellen kann. Das ist ein ganz berühmtes Beispiel, was viele kennen. Ich habe einen Punkt für König und ich ziehe Mann davon ab und addiere den Vektor für Frau und er zeigt dann in die Nähe von Königin. Also ich abstrahiere von den Wörtern, die auch doppeldeutig sein können. Queen kann auch die Band gemeint sein, es muss jetzt nicht die Königin von England sein. Also ich nehme halt quasi wirklich die Bedeutung und das versuchen sie Vektordatenbanken auch. Also machen aus dem Text Embeddings und versuchen damit die Information zu destillieren, würde ich mal sagen. Und dann nimmt man sich seine Suchabfrage und was alles da mitgegeben wird, versucht auch dort die Bedeutung zu extrahieren und dann vergleicht man diese. Also am Ende kriegt man zwei Vektoren, also mehr sind multidimensionale Vektoren. Aber am Ende kriegt man diese beiden Vektoren, man legt sie übereinander und guckt, wenn sie ähnlich sind, vermutet man, dass meine Suchanfrage wohl gut zu den Ergebnissen passt und dann nehme ich die. Das ist so das klassische Einsatzszenario für Vektordatenbanken und darum sind sie auch gerade dabei, die Suche nicht zu revolutionieren, aber zumindest ein neuer Ansatz, der gerade viel verfolgt ist, darzustellen.

Robert: Das ist also durchaus eine Architekturentscheidung, die ich auf Grundlage meiner Daten und meines Use Cases einfach treffen sollte. Es kann ja auch eine pragmatische Entscheidung sein, um vielleicht einen MVP erstmal zu knacken, sowas wie Kendra einzusetzen und einen fertigen Suchindex, den ich einfach sehr einfach zum Beispiel an Confluence connecten kann. Dann habe ich die Stelle erst mal gelöst und kann möglichst schnell mal einen Durchstich erproben hinbekommen und daraus dann lernen, wie wird das benutzt. Scheitert es vielleicht doch nicht am Retriever. Nutzen die Leute das vielleicht ganz anders, ohne da direkt richtig rein zu buttern, oder?

Ole: Ich würde auch am jeden Fall erstmal mit einem Good Enough Ansatz reingehen. Also man kann mit Suche unendlich viel Zeit verbringen und es muss meistens nicht die 100% Lösung sein. Man kann auch immer einen Prozess-Fallback einführen, dass man zum Beispiel bei seinem Chatbot einen Knopf hat. Ich möchte jetzt doch mit einem echten Mitarbeiter reden, wenn es halt nicht funktioniert und wenn der dann halt zweimal pro Woche gedrückt wird, dann ist ja auch okay. Also ich glaube, man sollte sich davon verabschieden, den 100% Case zu suchen, sondern das, was halt ein gutes Preis-Leistungs-Verhältnis für einen bietet und das erstmal sehen. Und wie du schon sagst, Erfahrung sammeln. Das ist alles sehr neue Technologie, sehr spannende Technologien. Ich glaube auch, dass sich die durchsetzen wird in Zukunft. Aber ja, Augenmaß, Architekturentscheidungen und gut enough sind da glaube ich erstmal gute Richtlinien.

Robert: Wir haben das in einem Fall gesehen, wo wir Kendra auch eingesetzt hatten, um möglichst schnell einen MVP zu kriegen. Da hast du aber wirklich gesehen, die Chat-Eingaben, also die Prompts, wenn man die nicht noch auseinander nimmt, dann landen die eins zu eins natürlich im Retriever und dann hast du da halt auch mal eine längere natürlichsprachliche Frage drin stehen, was wenn wir jetzt auf der Google-Analogie bleiben, natürlich irgendwie komisch ist, weil Suchmaschinen haben die Menschen sich irgendwie antrainiert, bedient man nicht natürlichsprachlich, sondern man hackt irgendwelche möglichst relevanten Stichworte da rein, Keywords, keine zusammenhängenden Sätze und wenn man dann die backt und guckt was kommt denn da im Retriever überhaupt an kommen dann natürlich diese langen Fragen an und man muss da schon groß darauf vertrauen dass in dem Fall Kendra kann auch was anderes einsetzen als Index die natürlich schlau auseinander nimmt.

Vermutlich, wenn man typischen, klassischen Suchindex einsetzt, sind die da drin nicht allzu gut. Also müsste man eigentlich noch mal, wenn man merkt, die Ergebnisse sind nicht berauschend, die Daten sind eigentlich gut, müsste man da noch mal ran und diese Fragen in Keywords zerhacken, oder?

Ole: Man schiebt das Problem so ein bisschen weiter. Erst wollte man, dass das LLM das für einen löst und jetzt schiebt man das Problem an Kendra und hofft, dass Kendra das magisch für einen löst. Aber RAG ist halt auch kein Golden Hammer, aber wieder nicht so. Das Problem muss man dann im Kendra lösen oder was auch immer seine RAG-Implementierung ist. Aber im Prinzip schiebt man das Problem ein bisschen weiter und hofft, dass es besser dafür geeignet ist, was es in vielen Fällen noch ist.

Robert: Wenn ich das jetzt entdecke, wenn ich sowas gerade baue, gibt es einen Weg, möglichst schnell ein Proof of Concept zu kriegen mit einer Vektor-basierten Zufütterung für das LLM? Was kann ich da so einsetzen? Kennst du ein paar Technologien? Was brauche ich denn dafür überhaupt?

Ole: Man kann auf jeden Fall was komplett einkaufen, sowas wie Amazon Kendra, Google bietet von, ich glaube das heißt Vertex AI, RAG Data Services an. Es gibt ganz viele handgebaute, handgestrickte Lösungen von Langchain und Tutorials dazu im Internet. Die Judge ist in der Schweiz hier gerade relativ aktuell, oder vielleicht auch Zürich, was so ein ETH-Spin-Off, die ganz viel in dem Bereich machen. Aber ich würde tatsächlich auch erst mal dazu neigen, was von der Stange zu nehmen, von Amazon oder Google, was jetzt mein Cloud-Anbieter ist, und das erst mal ausprobieren, da die ersten Gehversuche mitmachen. Und ich würde mich, glaube ich, noch nicht hinsetzen, da eine eigene Vector-Datenbank aufzubauen und zu entwickeln.

Robert: Okay. Wenn ich aber erkenne, dass ich vermutlich eine Vektordatenbank brauche, weil das mit einem Suchindex vielleicht einfach nicht gut genug ist und ich weiß, meine Daten sind eigentlich besser als die Ergebnisse, die das LLM mir aus der Zufütterung aufbereiten kann, was brauche ich dafür? Da hört man oft den Punkt Embedding-Modelle. Kannst du erklären, was das ist, wofür man die braucht?

Ole: Das Embedding ist genau diese Umwandlung von deinem Text in semantischen Vektoren. Und gibt es von allen großen Anbietern, sind häufig auch Open Source. Das habe ich den Namen vergessen, also kann man von OpenAPI, OpenAI und Anthropic.

Robert: Cohere ist, glaube ich, noch ein großer Anbieter. Cohere, oder?

Ole: Es gibt hier das Pinecone, die bieten alle diesen Tokenizer und Embedder an und der Tokenizer hackt erstmal deinen ganzen Text in Tokens und der Embedder berechnet dann diese Vektoren und das ist quasi der Index deiner Datenbank, auf den du später suchen kannst.

Robert: Okay, und wenn ich das habe, wie mache ich, wie kommt das dann ans LLM dran? Was ist das Schnüffelstück?

Ole: Das ist ja erstmal, wie du es in deine Vektor-Datenbank lädst. Und dann musst du halt auf deine Vektor, also dann packst du deine Suchanfrage halt auch in einen, also lässt deine Suchanfrage auch in einen Vektor umwandeln und dann machst du eine Ähnlichkeitssuche in dieser Vektor-Datenbank, was ähnlich ist. Frage zu gefunden, also zu hochgeladenen Dokumenten.

Robert: Okay. Und das kann das LLM dann auswerten und in eine natürlichsprachliche Antwort auf meinen Prompt was ganz vorne stand generieren.

Ole: Genau. Das wird dann meistens wieder runterdekodiert. Also dieser Vector hilft ihm nur, die Dokumente zu finden. Er nimmt dann doch wieder die natürlichsprachlichen Dokumente und schreibt das ins Kontextwindow. Da sind jetzt keine Zahlenkolonnen drin.

Robert: Okay. Das war das fehlende Bindeglied, was uns noch fehlt in dem Durchstich hier. Gut. Jetzt gehen wir mal davon aus, ich bin jetzt schon ein bisschen länger in dem Limo-Hersteller-Unternehmen und ich will es wirklich wissen. Ich habe jetzt meine einfachen Abfragen hinter mir, zum Beispiel welche Limo-Modelle hat dieser Hersteller, für den ich jetzt hier neu arbeite in den letzten Jahrzehnten, so auf den Markt gebracht.

Ist gut und schön, ist ein schöner Case, auch dass das in natürlichsprachlicher Frage-Antwort passieren kann. Aber da hören viele Chatbot-Demos eben oft auf, was ich so erschreckend langweilig finde. Weil jetzt hat man diese Large-Language-Models und hat auch eine gewisse Art von Reasoning-Fähigkeiten, je nachdem, wie groß diese Modelle sind.

Und ich habe meine hoch speziellen, nicht im Internet stehenden Unternehmensdaten. Jetzt gebe ich mir aber auch mal was zu tun, denke ich immer, und mache hier nicht einfach nur einen Suchindex als Chatbot. Das ist total langweilig. Ich finde zu Fragen viel interessanter, diesen Beispiel-Chatbot, dem Limo-Chatbot jetzt zu stellen. Wie sieht denn eigentlich die Software-Architektur von unserem E-Commerce-Shop aus und wie kam es dazu? Wer waren denn die Architekturentscheider und was ist da passiert? Wieso ist die Architektur so, wie sie heute ist? Was sind potenzielle Schwachstellen?

Und das finde ich hochinteressant. Da muss nämlich aus diesen ganzen Suchergebnissen dann das LLM auch so ein bisschen Reasoning betreiben, um mir hoffentlich ein Ziel für eine Antwort zu liefern. Daran kann man, glaube ich, dann immer ganz schön messen, okay, wir haben die richtigen Daten. Und das funktioniert, was wir hier gebaut haben. Und das stiftet halt auch einen echten Mehrwert gegenüber so einer blöden Unternehmenssuche. Die gibt’s ja. Das versucht man ja schon seit vielen Jahrzehnten zu lösen.

Ole: Ja, durch das Reasoning kommt halt nochmal richtig der Mehrwert da rein. Es ist zurzeit eine ganz heiße Forschungsfrage. Wie weit können Sie denn überhaupt reasonen? Ich habe gerade jetzt am Wochenende ein total interessantes Paper gefunden, Recite versus Reasoning, wo Sie genau die Frage untersuchen, was hat er in seinen Trainingsdaten eigentlich gelernt und was kann er wirklich abstrahieren und mit welchen Informationen

kann er wirklich abstrakt arbeiten.

Die Antwort ist natürlich wieder, it depends. Typische Consultant-Antwort. Aber sie können reasonen und sie werden besser. Spannend ist, man weiß nicht genau, warum sie das können. Von ihrem Pre-Training sind sie überhaupt nicht daraufhin vorbereitet und dadurch kommt auch das Argument des Statistic Parrots, des statistischen Papageis immer so in alle Munde. Eigentlich sollten sie es nicht können, aber tatsächlich können sie es bis zu gewissen Punkten und sogar abstrakt. Das kam in so einem Paper auch aus. Sie waren ein bisschen enttäuscht, dass sie es nicht komplett abstrakt können, aber vielleicht ist es auch viel zu viel verlangt. Also heißes Thema.

Robert: Dazu geht ja auch so ein bisschen der Podcast, den wir am Anfang erwähnt hatten von Yann LeCun und Lex Friedman. Da geht es eben darum, was braucht man denn, um wirklich die Welt zu verstehen? Und da fehlt eben noch, also sagt Jan Lekun eine ganze Reihe Facetten, die man eben auch noch erschließen muss. Physikalisches Grundverständnis, wobei man auch Effekte in den jetzigen LLMs sieht.

Dass sowas irgendwie eigentlich nicht drin sein sollte, aber scheinbar drin ist. De facto versteht man nicht, warum solche Sachen sichtbar werden. Und da gibt es jetzt viele Leute, auch die NYU, die sich mit Methoden der Neurowissenschaft dem nähern, weil man eben man guckt da in riesiges neuronales Netz und man muss eben wissen welche Neuronen feuern hier ganz oft und warum bei denen und den Fragen das ist irrsinnig komplex aber lasst uns mal zurück zum Thema req kommen.

Kannst du ein paar Tools und Frameworks empfehlen, wenn ich jetzt sage, komm, wir wollen mal so einen internen POC machen, Confluent, sagen wir vielleicht, oder irgendwas anderes? Könnte ja auch eine Postgres-Datenbank mit Wiki-Einträgen sein, über zehn Jahren. So ein Standard-Set, was nimmt man dafür?

Ole: Es kann also klassische Technologien, es kann Solar sein, es kann Elasticsearch sein, wenn man irgendwie mit Newsartikeln arbeitet. Es kann also, wenn man Google sagt, dass ihr aktuelles Modell eigentlich kein Cut-Off-Date mehr hat, hat es schon noch. Sie benutzen nur schnell Google, um das Kontext-Window immer zu erhöhen. Im Prinzip könnte man auch Dinge googeln. Alle Arten von Vektordatenbanken sind geeignet. Da ist man relativ frei. Eigentlich, was man da an Pools verwendet.

Robert: Man könnte ja auch sagen, für so einen ganz, ganz primitiven POC könnte ich mir ein LLM nehmen, was ein gigantisches Kontextfenster hat, alle meine Blogposts aus, weiß ich nicht, fünf Jahren, konkratinieren und mir ein großes Prompt daraus schreiben. Und das in LLM führt dann aktuell, kann, glaube ich, nur Gemini in der in Deutschland noch nicht verfügbaren 1.5 Pro zum Sendetermin hier das Verdauen und dann einfach mal gucken, was bei rausfällt, was ich da für Reasoning überhaupt möglich machen kann und ob die Insights, die ich daraus gewinnen kann, in einem Nutzertest zum Beispiel intern, ob das überhaupt wertstiftet. Das ist vielleicht ein guter Ansatz, kostengünstig zu sowas zu kommen.

Ole: Ich glaube auch, in die Richtung wird es gehen. Zumindest wenn man das Kontext-Window und den Geldfaktor als Treiber sieht. Ich glaube ganz stark, dass es in die Richtung gehen wird. Es sind dann halt eher so Dinge wie Aktualisierbarkeit und Korrektheit der Daten und so weiter, wo das RAG im Hintergrund noch profitieren kann, dass du halt, wenn man so eine Suche hat, muss man ja Dokumente eventuell aktualisieren können, weil man was Neues gelernt hat. Gerade wenn du ein Unternehmen hast mit sehr fluiden Daten, die häufig geupdatet werden, weil da irgendwelche Events drauf laufen, wenn man zum Beispiel eine Spedition hat und das jetzt an neuen Stationen deine Container angekommen sind, dann kann sich so ein RAG schon wieder auszahlen, weil du schnell aktualisieren kannst. Aber um erstmal ein Bauchgefühl dazu zu entwickeln, kann man auch erstmal das Kontextfenster vollpumpen und diese Auswahl von selbst übernehmen.

Robert: Am Ende ist es vielleicht sogar billiger, das teure LLM in einer gewissen Frequenz mit Monsterprompts zu belästigen, als mir erstmal einen riesen Tech Stack hinzustellen, den ich natürlich auch maintainen muss, um dann rauszufinden… Ah, wir müssen eigentlich nochmal an die Daten ran.

Ole: Auf jeden Fall. Und wie gesagt, es ist nicht trivial. Wer in seiner Firma schon eine gut funktionierende Suche hat, der sollte A, seinem Suchteam dankbar sein und das wertschätzen, dass er es hat, das ist wirklich nicht trivial.

Robert: Das glaube ich auch. Kannst du dich noch an diese, ich hatte es vorhin kurz erwähnt, an diese Softwarelösungen erinnern, wie Planet zum Beispiel, da konnte man ganz viele RSS-Feeds reinpluggen und hat dann einen dicken Feed bekommen. Und das war dann vor, weiß ich nicht, 15 Jahren die Lösung, um Unternehmenswissen zusammenzuführen, dass ich einen riesen fetten Feed habe. Das waren wirklich Holzklasse Ansätze, aber wir hatten ja damals nichts. Aber das stellen sich Unternehmen ja schon immer, diese Frage. Das ist einmal die Zusammenführung. Und jetzt hat man eben in der LLMs eine Technologie, die auf der Zusammenführung wirklich natürlich sprachliche Auswertungen machen kann und Antworten liefern kann. Und das ist hier glaube ich das neue zweischneidige Schwert.

Ole: Und das Modell bringt dir halt schon viel Wissen über die Welt mit. Also ich arbeite gerade beim Kunden in der Speditionsbranche und dort kann man halt Dokumente, Transportscheine von unterschiedlichsten Zulieferern und unterschiedlichsten Kunden reingeben. Und es hat ein Grundverständnis, wie Logistik funktioniert. Das Ware von A nach B ist, was eine Anlieferadresse ist. Das wäre ja sonst irgendwas, was man algorithmisch irgendwie ihm beibringen müsste. Und das ist nicht trivial. Und dieses Weltwissen zu nutzen, das ist, glaube ich, eine der Herausforderungen in den nächsten Jahren, die auf uns zukommt, Anwendungsfälle zu finden.

Robert: Ja. Hm.

Ole: Können wir zum Beispiel vorstellen, nimm den Krankenhaus, ein Patient kommt rein und die Medikamente werden erstmal auf Wechselwirkungen untersucht. Dafür könnte man zum Beispiel auch einen RAG gut nutzen. Auch ein bisschen weg von so einem Chatcase, was vielleicht gar nicht so schlecht ist, weil man da die Input-Prompts besser im Griff hat. Da kannst du halt deine eigenen Daten nutzen, um auf das RAG zuzugreifen, was halt irgendwelche Unverträglichkeitslisten von Medikamenten einfach hält. Und du hast auch das Ergebnis besser im Griff. Vielleicht ist das auch sogar noch ein besserer Anwendungsfall für die RAGs, wenn du halt einfach viel und schnell aktualisierende Daten hast und es eher in der Second Tier nutzt, wo es mit nicht den wildesten User-Anfragen bombardiert wird, sondern wo du ihm auch eine Struktur vorgeben kannst, du ihm auch mitteilen kannst, worum es sich eigentlich handelt und dementsprechend einfacher und besser werden deine Suchergebnisse.

Robert: Ja, das glaube ich auch und wir sind jetzt in einer Phase, also wir nehmen den Podcast Anfang Mai auf, am 6. Mai. Das muss man immer dazu sagen, was in zwei Wochen hier alles passiert sein wird, wissen wir nicht, vermutlich wieder viel. Wir denken immer noch zu sehr in Chats. Ich glaube Chats sind aktuell einfach eine Phase.

Ole: Hm.

Robert: Die werden auch immer bleiben, weil sie ganz klare Use Cases haben für die, die einfach das ideale UI sind. Und man hat ja jetzt auch schöne neue UX-Patterns gelernt und sieht ja auch, dass das ankommt bei den Leuten, dass das gut verständlich ist und funktioniert und genutzt wird. Aber wie du sagst, für mal solche Beispiele wie Medikamenten auswählen, was nimmt denn der Patient jetzt hier alles? Das muss ich nicht im Chat machen, das im Klinikalltag behindert mich sowas eher. Da muss ich ganz schnell eine Liste von fünf Medikamenten einhacken, vielleicht noch eine Dosis dazuschreiben, das ist schon relativ strukturiert. Das will ich ja nicht im Freitext in irgendeinem Chatbot hämmern und dann die Antworten auch noch im Klinikalltag parsen, die wahrscheinlich menschensprachlich ist. Ich glaube, das wird Teil des Feature-Teppichs von Anwendungen werden. Einige Features werden RAG und LLMs im Hintergrund haben. Andere werden weiterhin algorithmisch sein. Ganz andere haben ein Machine-Learning-Modell dran. Das werden wir nicht zwangsläufig sehen. Und das wird auch weggehen von diesem, generiere mir jetzt mal eine E-Mail.

Ole: Ich glaube auch, dass das wird ein neues und ein bedeutendes Tool in unserem Werkzeugkasten werden. Und wir sind halt auch noch, das ist ja auch das Spannende an der Phase gerade. Jede Woche kommt irgendjemand auf eine unglaublich gute Idee, wofür man LLMs einsetzen kann.

Robert: Hm.

Ole: Wie du schon sagst, 6. Mai. Irgendwie gestern gab es Videos darüber, wie man Roboterhunde trainiert und wie man die Parameter von dem LLM tunen kann. Unglaublich beeindruckend, was die Leute für Ideen da kommen.

Robert: Ja, es ist eben eine Allzwecktechnologie, die fast alles berührt. Ich nehme das fast jetzt sogar nochmal weg. Deswegen ist es umso schwerer, wenn ich in einer Domäne sitze und das schon viele lange Jahre tue, mir UseCases auszudenken für Tausende von anderen Domänen. Das ist eine Kollaborationsherausforderung. Das wird nur so entstehen. Lass uns doch mal, wo wir gerade bei Anwendungen sind, so ein paar Anwendungsbeispiele durchgehen. Wofür könnte ich den RAG jetzt gut nutzen? Wir hatten zum Beispiel schon mal den Klassiker Chatbot im Kundensupport, haben wir kurz darüber gesprochen. Der Chatbot hat durch RAG eben Supportwissen, vielleicht nicht das gesamte Unternehmenswissen. Das will ich meinen Kunden ja nicht bereitstellen. Sonst können die auch erfahren, was es im Management in den Protokollen für Streitigkeiten gab oder sonst irgendwas. Aber durchaus, wie wurden vergangene Supportfälle behandelt? Was sind bekannte interne Probleme von der Gurkenlimo? Die ist oft zu bitter und so Sachen. Das hatten wir besprochen. Was gibt es denn noch für Anwendungsfälle? Also es sind ja unfassbar viele. Vielleicht greifen wir uns mal ein Paar prägnante raus.

Ole: Ich denke, immer dann greift es, wenn du entweder Umgebungswissen bräuchtest, um das beurteilen zu können. Also jetzt in der Speditionsbranche zum Beispiel, wenn irgendwelche Adressen angegeben werden oder Abholdaten angegeben werden. Wenn das in New York ist, dass das auch New Yorker Zeitzone ist und nicht die deutsche Zeitzone zum Beispiel. Man könnte es für so ein bisschen Sanity-Checks machen. Dafür sind sie auf jeden Fall gut, weil sie einfach viel Wissen beinhalten. Sie wissen auch, dass du nicht mit einem Lastwagen von Frankreich in die USA fahren kannst. Das versteht das System auch. Gewisse physische Zusammenhänge, Größen, Gewichte, Volumina. Dafür hat es einfach ein Verständnis und das kann man nutzen. Vielleicht nicht für die ganz kritische Anwendung. Also ich würde es jetzt nicht für Zieldrohnen verwenden oder so, weil die können sich halt schon nochmal verhauen. Aber man kann halt für alle Arten von Validierungen einsetzen, was zunehmen wird, wenn du große Mengen an Daten hast, verarbeitet werden, wenn du irgendwie einen Containerschiff hast und alle Dokumente einmal durchscannen willst und die Packlisten, die von 100 Zulieferern gekommen sind, in unterschiedlichen Formaten einmal scannen willst. Für sowas ist es wertvoll. Dinge wie, was wir schon erwähnt haben, Medikamenten zum Beispiel, News-Artikel, Sentiments rausfinden. Also sind das jetzt irgendwelche Pro-Artikel oder Anti-Artikel? Also Artikel jetzt im Sinne von News. Das kann man auf jeden Fall nutzen.

Robert: Die halt nicht öffentlich sind, diese News. Das heißt, wenn ich ein Publisher bin und ich habe schon seit vielen Jahren eine Paywall an meiner Zeitung oder was auch immer, dann wäre das wahrscheinlich ein nettes Feature für Abonnentinnen und Abonnenten, dass ich denen neben einem klassischen Suchindex vielleicht auch Antworten anbiete zu Fragen auf Basis von vielen Jahrzehnten meiner Presseartikel, die eben bei mir intern schlummern. Ich meine, die meisten sind ja dann doch irgendwie öffentlich zumindest in Anrissen. Aber so Archivzugänge über Wissen, das auf vielen Jahren sich aufgestaut hat. Das bietet sich dann natürlich an. Was würdest du sagen?

Bei so Rechtsthemen, also Gesetzestexte sind ja meistens öffentlich, damit oft auch in Weltmodellen irgendwie schon verdaut. Aber auch da haben wir natürlich einen Cutoff. Das ist wahrscheinlich, weil die ja oft auch Opendata mäßig bereitliegen, schon ein interessanter RAG-Fall, oder?

Ole: Ja, da funktionieren die auch schon, da funktionieren sie sogar schon ohne RAG erstaunlich gut. Also es gibt ja dieses Bar Exam in den USA, was einfach ein Zulassungstest für alle möglichen Legal Jobs sind, also Richter, Staatsanwalt, Rechtsanwalt und da kann GPT-4 schon ohne RAG bestehen. Easy, also nicht mal, es liegt irgendwo in der Nähe des 90%-Falls.

Robert: Hätte das Saul Goodman schon gehabt?

Ole: Ja, genau. Aber klar, man könnte ihnen dann halt über RAG die neuesten Fälle oder vor allen Dingen wahrscheinlich die Daten deines Clients reinspielen. Dass das halt die Daten sind, die er hoffentlich noch nicht gelesen hat, es sei denn, was? Einen ganz wilden Fall an den Hacken. Aber diese ganzen langweiligen Papierkram, Bücher, Einträge, Firmendokumente und so weiter, die könnte man dann natürlich reinstellen oder Überprüfung, ob Verträge Compliance-korrekt sind. Da hatte Google jetzt auch ein Showcase letztens, dass du mehrere Angebote auf Compliance-Korrektheit mit deinen eigenen Richtlinien verglichen hast. Also, dass ihr einen Job, den macht keiner gerne. 100 Seiten lesen und das dann mit einem staubtrocknen juristischen Graben zu vergriffen. Ich glaube, ich mache mich jetzt unbeliebt aus einigen Gründen.

Robert: Es ist immer eine Frage der Domäne, wo man gerade sitzt. Aber lass uns, ich habe nämlich von einem Modell gehört, was sich ein großer Legal-Dienstleister, also ein LLM, was sich ein großer Legal-Dienstleister feingetunt hat, mit eigenen Daten. Da sollten wir nochmal kurz zu sprechen. Würdest du sagen, dass RAG in den meisten Fällen, das ist jetzt eine Hypothese von mir, viel sinnvoller und kostengünstiger ist als ein Finetuning?

Ole: Als ein Feintuning ja, gerade wegen der Fähigkeit der Aktualisierung. Also Feintunings dauern jetzt auch nicht so lange. Das sind auch ein paar Tage, aber nicht die Monate von dem Pre-Training. Aber ja, ich glaube gerade für die Anpassbarkeit. Ich weiß jetzt nicht, wie häufig sich, also wenn es eine richtig große Anwaltskanzlei ist, die 100 Cases gleichzeitig hat, werden sich in den einzelnen Fällen ja auch täglich irgendwelche Aktualisierungen geben.

Robert: Ich glaube, es war eine sehr große. Wir suchen das nochmal für die Shownotes raus.

Ole: Und da wird es sich, glaube ich, lohnen, weil halt auch die Kunden sind ja ungeduldig. Sie wollen die Aktualisierung sofort haben und nicht erst, wenn du sonntags dein Pre-Training durchführst. Und da werden sich die RAGs, glaube ich, schon deutlich lohnen.

Robert: Wir sollen kurz erwähnen, was Feintuning ist. Ich nehme quasi ein Large-Language-Model von der Stange. OpenAI bietet sowas zum Beispiel mittlerweile auch als API Service an, ein Feintuning zu machen. Leider nicht auf GPT-4, das ist wahrscheinlich zu teuer, aber auf GPT-3.5. Ich kann das aber auch mit Open-Source-Modellen machen. Ich kann das andere bieten, sowas an.

Ich nehme quasi ein fertig trainiertes Weltmodell und mache im sogenannten Finetuning noch mal ein Nachtraining mit meinen internen Daten, dass die auch noch in dem Weltmodell mit verdaut werden. Das kostet natürlich Zeit und Geld. Es ist mit Sicherheit nicht so umfangreich wie ein Pre-Training, aber es ist nicht zu unterschätzen, je nachdem, wie oft ich das denn eben machen muss. Wenn sich der Datenpool oft ändert, ist das vermutlich eine Architekturentscheidung letzten Endes. Ist es zu teuer, sich das ganz selten ändert und die Ergebnisse dann auch sichtbar besser sind als beispielsweise bei einem RAG-Ansatz und ich vielleicht sogar Architektur einsparen kann, Infrastruktur ist es vielleicht wieder eine Option. Wie immer.

Ole: Ich habe es selber noch nicht gemacht, aber es würde mich auch kribbeln, mal so ein Feintuning zu machen. Das ist auf jeden Fall spannend, sich die Ergebnisse da anzuschauen. Das denke ich auch. Aber ja, Architekturentscheidungen und Tradeoffs. Je häufiger deine Daten aktualisieren, desto schwieriger wird es. Je statischer deine Daten sind, desto besser.

Robert: Ich glaube, wir haben die Stunde gerade gesprengt. Wir sehen quasi bei diesem ganzen RAG-Thema und generell in der AI-Thematik steckt eine ganze Menge simples Engineering to do drin. Da sind unsere klassischen Engineering Skills als Softwareentwicklerinnen und Softwareentwickler und Architektinnen und Architekten gefragt. Ich muss ganz viele Architekturentscheidungen treffen. Welches Modell verwende ich? Welche Daten habe ich überhaupt in meinem Unternehmen? Wie bereinigen wir die? Wie bereiten wir die auf? Wie indizieren wir die? Wie füttern wir zu? Es ist eine ganze Menge Glue-Code und Glue-Material dazwischen. Das ist einfach Engineering. Das ist in dem Sinne für uns nichts Neues. Nur, dass eine sogenannte Blackbox jetzt dazu kommt in die Architektur.

Ole: Das wird auch nicht so schnell verschwinden. Man braucht immer jemanden, der seine Daten organisiert, zusammensucht. Wenn das RAG die falschen Daten findet, dann wird es eventuell schlimmer als besser.

Robert: Ja, da gab’s auch eine Studie zu, ne? Also, wenn meine Daten, die ich per RAG eben zugebe, zufüttere, im großen Maßstab schlecht sind, dann sinken natürlich auch die Antwortqualität des LLMs. Weil man geht natürlich implizit davon aus. Also, ich sag das ja im Groben, ne? Bitte achte darauf, dass du deine Antworten mit Quellen untermauern kannst und die Quellen ziehst du bitte aus den Suchergebnissen, wenn da aber nur Kokolores drinsteht.

Ole: Ja.

Robert: Nur halt mit ein bisschen menschensprachlichem Zucker. Ole, danke für deine Zeit. Ich glaube, wir haben einen ganz guten Überflug gemacht zum Thema RAG. Lasst uns wissen, wie ihr die Folge fandet. Wir haben noch einige andere AI-Themen auf der Agenda. Es werden jetzt immer wieder Folgen dazu kommen. Lasst uns mal wissen, wie ihr die Folge fandet. Waren wir zu lang? Waren wir zu kurz? Hätten wir mehr ausholen sollen? Wo habt ihr noch Fragen? Offen. Welche Themen bewegen euch gerade? Macht ihr vielleicht was mit RAG? Irgendwelche PoCs? Meldet euch mal bei uns an [email protected]. Wir freuen uns immer, von Hörern und Hörerinnen zu hören. Und wenn es nur ein einfacher Daumen hoch oder Daumen runter ist. So Ole, ich entlasse dich wieder in die Schweizer Bergwelt, wenn das Wetter noch schön ist. Danke für deine Zeit und bis bald.

Ole: Vielen Dank. Ja, ich freue mich. Tschüss.

Robert: Tschüss!