Knowledge Science - Alles über KI, ML und NLP

Episode 96 - Language Model Programming

Sigurd Schacht, Carsten Lanquillon Season 1 Episode 96

Send us a text

Eigentlich, was wäre, wenn wir die Grenzen von traditioneller Programmierung und KI-Sprachmodellen durchbrechen könnten? Stellen Sie sich vor, wir könnten kognitive Leistungen und Prozessautomatisierung auf ein ganz neues Niveau heben. In dieser Folge haben wir uns eingehend mit dem aufstrebenden Feld des Language Model Programming (LMP) beschäftigt und darüber diskutiert, wie die Integration dieser mächtigen Technologie in bestehende Prozesse und Systeme unsere Arbeitsweise revolutionieren kann.

Wir haben uns auf den Weg gemacht, zu erforschen, wie wir programmbezogene Fragmente in ein nativ geschriebenes Programm einbinden können. Dies ermöglicht es uns, Texte mit eingebetteten Funktionsaufrufen zu erstellen. Zudem haben wir die Vorzüge der LMQL Sprache hervorgehoben, die der SQL-Analogie ähnelt.

Hören Sie rein.

Der Podcast ist gesponsert von XL2:
XL2 ist ein Joint Venture zwischen dem Premium-Automobilhersteller Audi und dem globalen IT-Beratungsunternehmen Capgemini. Das Unternehmen wurde im Jahr 2020 gegründet und treibt die digitale Transformation für Audi, die Volkswagen-Gruppe und Automotive Leaders voran. XL2 konzipiert und implementiert maßgeschneiderte Lösungen für Logistik- und Produktionsprozesse mit den neuesten Technologien aus den Bereichen SAP, Cloud und Analytics. 

Support the show

Sigurd Schacht:

Hallo und herzlich willkommen. In der heutigen Sendung schauen wir uns mit LMQL ein Beispiel für eine Language Model Programming Umsetzung an. Bleiben Sie dran. Auch diese Sendung wird von Excel 2 gesponsert. Excel 2 ist ein joint venture von Audi und CapGammy, das die digitale Transformation in der Automobilindustrie vorantreibt. Das Unternehmen erarbeitet innovative end-to-end Prozesse und implementiert maßgeschneiderte IT-Lösungen für seine Kunden. Hallo Carsten, hallo Siegurt. So, diese Woche steigen wir mal ein mit einem zwar kein neuen Thema wir haben es letzte Woche schon angekündigt, dass wir LMQL anschauen wollen, aber doch irgendwie auch in einer gewissen Weise vielleicht ein Paradigmus zu weit gekriegt haben aber schon eine neue Fokussierung in Bezug auf den Nutzen von Sprachmodellen.

Carsten Lanquillon:

Ja man, das gibt Leute, die bezeichnet, dass es tatsächlich als neuer aufstrebende Disziplin Language Model Programming kurz. LMP, und ich glaube tatsächlich, das wird ein Riesending. Am Ende geht es ja darum, die Möglichkeiten vom klassischen Programmieren und die Fähigkeiten und Möglichkeiten von Sprachmodellen zu integrieren.

Sigurd Schacht:

Also es bräumt, engineering eigentlich jetzt schon wieder out.

Carsten Lanquillon:

Nicht wirklich. Das ist ein Teil davon.

Sigurd Schacht:

Wir haben ja letzte Woche darüber gesprochen wegen Prompt Design, prompt Engineering und so weiter. Aber auch wenn das jetzt ein bisschen eine ketzeltische Frage ist, es gibt tatsächlich erhältliche Papers und auch Diskussionen, die wirklich darüber diskutieren, ob auf Dauer nicht Prompt Engineering sozusagen sich wieder reduziert und das Thema Feintuning in den Vordergrund rügt. Aber das ist ein anderes Thema. Jetzt fokussieren wir uns erst mal auf das Thema Language Model Programming. Ja, du hast es gesagt. Also, ich finde auch, dass das definitiv ein wichtiger Aspekt ist, weil klar, chat, gpt und die ganzen Chatmodelle, die haben uns ein einfaches Interface gegeben und haben damit eine Möglichkeit geschaffen, dass wirklich jeder Mann eigentlich mit AI super einfach interagieren kann.

Carsten Lanquillon:

Und jede Frau.

Sigurd Schacht:

Und jede Frau absolut, und dementsprechend hat man natürlich das Gefühl, dass das sozusagen die einzige Applikation ist. Aber das Spannende ist ja und das merken wir ja bei dem Bau von vielen Demonstrator dass die Einbettung des Sprachmodells in einer Applikation ja eigentlich erst den großen Hebeln in Gänze erzeugt, weil wir ja auf der einen Seite die Abläufe automatisieren über Programmabläufe und über das Sprachmodell dann in einer gewissen Weise durch Reasoning, durch Agenten oder Ähnliches eigentlich die kognitive Leistung automatisieren.

Carsten Lanquillon:

Genau, und bei komplexeren Aufgaben sehen wir ja sehr schnell dass das. Sagen wir mal, Fall mir ad hoc zwei Dinge ein, die ganz, ganz wichtig sind dabei. Das eine hat sich schon angewähnt das Einbauen in Prozesse. Da muss ich natürlich sicherstellen, dass die Sachen, die ich da einbauer, auch gewissen Vorgaben sprechen, also irgendwelche Constraints, Bedingungen, die ich an die Ausgabe stelle, und aber auch ein gewisser Kontrollfluss, wenn ich nicht nur eine Antwort irgendwo generiere, sondern sie, die vielleicht irgendwie komplexer ist, Fallunterscheidungen, Abhängigkeit von Zwischenergebnissen irgendwo sich ergeben.

Sigurd Schacht:

Ja, und die Beschränkung, die kann man natürlich jetzt unterschiedlich sehen. Einerseits natürlich, was das Modell überhaupt machen darf, also ich sage mal, um die verschiedenen Problematiken wie Halluzination und ja, ich sage mal, auch Beschimpfung mit uns weiter oder halt negative Sachen einzugrenzen, aber natürlich auch und das sind wir dann wieder in diesem programmatischen Bereich drin auch, wie der Output überhaupt aussieht. Weil wenn man genau nimmt, ich sage mal, wenn wir einen zum Beispiel haben wollen, dass er uns eine Liste in Form einer Peißenliste zurückgibt mit den Aufzählungen der fünf wichtigsten Befehle einer Programmiersprache, der ähnliches, dann können wir im Endeffekt das in einem Programm sehr gut händeln, sofern das immer die Struktur an der Liste hat, auch wenn er dann vielleicht von den fünf Themen was Falsches rausgibt. Aber wenn die Struktur nicht passt, dann führt es halt immer zu einem Totalabbruch im Programm, außer wir haben den Catchall oder einen Eventhändler, also einen Fehlerhändling, aber ansonsten haben wir immer sofort einen Zuberechao. Deswegen ist eigentlich auch die Art und Weise, wie wir die Struktur definieren, ein ganz wichtiger Part.

Carsten Lanquillon:

Genau, und du hast das letzte angesprochen es ist leichter, das elementweise irgendwo zu haben oder aufzubauen, eine Struktur zu haben. Und ein typischer Weg, den viele Ansätze gehen, ist halt, dass ich nicht mich auf den Weg mache, dass ich sage, ich formuliere einen Prom, der mir genau das Ergebnis so formuliert, wie es gern hätte. Das ist so, dieser klassische Ansatz, durch entsprechende Beispiele, die ich mit integriere. Sie sagen, so soll mein Ergebnis ausgehen. Dann hoffe ich, dass es stimmt, und das ist das eine Extrem, dass ich einen Promt habe, ein Ergebnis, und das dann rausziehe, hoffentlich passend. Und der andere extremer Ansatz wäre zu sagen naja, ich baue meinen, ich nutze die Fähigkeit an, sprachmodells und meine Antworten ganz, ganz kleinteilig aufzubauen, und habe dann ganz feine Kontrolle darüber, was ich an welcher Stelle eigentlich zuläs und reinsetze als ja, als nächste Tokens oder Wörter in meinem Ergebnis.

Sigurd Schacht:

Ja, wir hatten ja letzte Woche ein paar dieser ich nenn es jetzt mal Frameworks genannt. Die hat diesen Output kontrollieren, hat mir die Sendung gemacht, wie man ein Output von Sprachmodellen kontrollieren kann, und ein, zwei ja, guidance, und ein anderes ist LMQL, und LMQL ist an der ETH Zürich entwickelt worden von Luca Boerra-Kellner und Marc Fischer und dem Professor Martin Wechef ich hoffe, ich spreche den Namen richtig aus, und das ist schön in dem Paper dargestellt worden, helfen sich ja die iguous.

Carsten Lanquillon:

Ja, und dieser Ansatz wir hatten ja gesagt, dass das programmieren meine Perspektive auf die Sache ist, dass diese beiden Aspekte, das Programmieren und das Prompting, nie oder selten gleichberechtig nebeneinander stehen. Ich würde sagen, es heißt entweder ein Programming first oder ein Prompting first, das heißt, hängst du das Ganze eher als Prompt auf und schaffst es irgendwie, programmfragmente mit zu integrieren, oder es ist eher ein Programm, und es werden nebenher irgendwie so ein Prompt erstellt, was man dann zwischendurch durch ganz normalen Funktionsaufrufe in dem nativen Programm, was ich selbst schreibe, wieder irgendwie in ein Sprachmodell übergeben. Natürlich ist, wenn ich so ein Prompt basiert, das ganze Aufbau auch. Da wird ein zum Beispiel mit Interpreter im Hintergrund, der das ganze Skript einliest und entsprechend die Aufrufe macht. Das ist klar. Aber es ist gefühlt doch eher so ein Text, den ich da zusammenstelle, mit diesen ganzen eingebetteten Funktionsaufrufen. Bei dem, was wir letzte Woche hatten, beim Guidance, da hatten wir gesagt, das ist ein bisschen komisch, weil es ist so eine eigene Sündags, wo ich vielleicht auch Schleifen definieren kann und so was.

Carsten Lanquillon:

Das gefiel mir nicht so richtig, weil da muss man die neu wieder lernen. Jetzt haben wir es im LMQL der Name ist so kurierte, schon so Query Language. Das ist so ein bisschen in Analogie zu SQL aufgebaut und hat auch ein paar typische Schlüsselwörter, die wir da wieder finden. Warum das so ist, können wir gleich nochmal drauf eingehen. Das Entscheidende, das ist aber das Entscheidende, dass ich jetzt hier nicht mehr so eine neue Sündags und Sprache und Schlüsselwörter habe, die ich integrieren muss, sondern das, was ich als Code einbette, echt peisen ist, und das ist für mich schon mal ein Riesenvorteil, den ich da habe. Jetzt muss ich mich natürlich trotzdem das ist ein bisschen Geschmackssache mag ich diese Form, dass es so ein bisschen in SQL angelehnte Sprachsündags ist. Wie sagt man vor und nach Teilen vielleicht. Aber es ist zwischendurch echter Peisenkurze, dass ich da nicht um wie umlernen muss. Das finde ich schon mal ein Riesenmehrwert.

Sigurd Schacht:

Ja, da hast du recht, wenn man Guidance im Vergleich sieht. Guidance ist ein bisschen, ich würde sagen, einfach von der Entwicklung, weiter einfach von den, weil man im Endeffekt manche Funktionalitäten wie das Token-Sealing, das wir letzte Woche angesprochen haben, schon implementiert hat, was hier noch kommen soll, aber was natürlich schon angenehmer ist, dass man diese Template Language nicht lernen muss Und im Endeffekt eigentlich die Struktur eines SQLs zumindest für Personen, die aus der Programmierung kommen, kein wirkliches Problem darstellt Und man, dass man sich nicht neu dran gewöhnen muss. Und ich, ehrlich gesagt, finde es gar nicht so schlecht, weil ich also es ist eine eigene Interpretation jetzt gerade weil, wie gesagt, ich weiß nicht, warum man diese Sprache gewählt hat, aber meine Interpretation ist eigentlich folgende warum ich das sehr angenehm empfinde, ist die Tatsache, dass ich ja im Endeffekt das Sprachmodell in dem Moment, wo ich es als Agenten und Riesenmehrern benutze, ja eigentlich möchte das auch sein Weltwissen benutzt. Also ich benutze es eigentlich so ein Mix aus Geistes, also Kognitiverleistung und Datenbank, und damit passt diese Analogie, dass es eine SQL-Abfrage auf eine Datenquelle ist, eigentlich ziemlich gut in meinen Augen Und macht natürlich dann auch das Schreiben sehr angenehm.

Sigurd Schacht:

Ich finde ehrlich gesagt auch, dass es so vom, wenn man keins anschaut ist, ja relativ häufig, dass ich die wiederkehrenden Aufrufe und so weiter in die Sintagskreien, also in das eigentliche Template mit rein Bauer oder Fremel. Das ist jetzt hier ein bisschen klarer. Führt aber auch dazu, dass im Endeffekt, wenn man ein großer Statement baut, dass natürlich eine gewisse Struktur da ist und dass ich dann im Endeffekt durch dieses Statement ein bisschen durchschauen muss und schauen muss okay, da ist eine Variable, welche Einschränkungen gibt es? die bei, die Einschränkungen halt dann am Ende, wie bei einem SQL-State, wo man sagt, im Select von einer Tabelle oder von einer spezifischen Tabelle, wo die und die Werte sind Und dieses, wo dieser Wear-Klausel, die ist auch bei dem QL am Ende, sozusagen da, wo dann die Constrains also bei durch das Steuern des Outputs eigentlich stattfindet.

Carsten Lanquillon:

Genau. also daran war schon wieder diese Analogie, das Wear, die Constraint, dass ich einfach einschränke, wie mein Ergebnis aussehen soll. Ich meine, diese Sichtweise verschleiert natürlich etwas, dass ich sage, wenn ich eine SQL-Satment habe das ist ja deklarativ Ich sage halt, was ich haben will, das Select, wo es herkommt. das ist quasi mein Modell. Insofern finde ich die Analogie auch ganz passend.

Carsten Lanquillon:

Und das Wear ist, dass ich einschränke, welche Art meine Ausgabe, welche Bedingungen erfüllt sein sollen. Das Pass ist verschleiert natürlich, dass diese Ausgabe eigentlich jetzt durch einen entsprechenden Interpreter sagen wir mal wirklich auch Token-to-for-Token generiert wird, und dass ich durch diese Tokenweise generieren nur dadurch die Möglichkeit habe, mit einem beliebigen Sprachmodell das ist entscheidend. Ich soll ja prinzipiell beliebige Sprachmodelle da reinklinken können. das ist auf der Meta-Ebene dass ich dann wirklich, weil ich das Tokenweise verarbeitet, ganz fein granular kontrollieren kann, ob meine Bedingungen im Wear-Stapement auch tatsächlich erfüllt sind oder auch nicht. Und wenn sie nicht erfüllt sind, dann ist es für mich, dass sie dafür sorgen kann, je nach dem, und deshalb gebe ich ja zuwärtslich noch an so einen Decoding, dass ich da so verschiedene Strategien noch angeben kann, wie ich die Tokens generiere.

Sigurd Schacht:

Ja, und das heißt eigentlich, und das meine ich jetzt schon in zumindest für mich, in dem ganzen spannenden Bereich wie funktionieren diese Einschränkungen im Detail? Weil im Endeffekt kriegen wir ja den Output aus dem Sprachmodell und rein. Wenn man sich das so vorstellt, würde man sagen ich sage jetzt mal, vielleicht gib mir die fünf wichtigsten Befehle im Vorfall, nehmt Chasen raus.

Sigurd Schacht:

Jeder Befehl soll maximal fünf Zeichen lang sein oder irgendwie in der Art Ja, dann würde ich im ersten Moment eigentlich mir das so vorstellen ich geb das an das Sprachmodell, das Sprachmodell gibt mir dann was durch die Antwort, und die Antwort prüfen wir dann, Und dann stellen wir in der Prüfung fest oh, ist nicht so, und dann mach mal was damit. So in der Art Aber so ist es ja eigentlich nicht.

Carsten Lanquillon:

Nein, weil es halt wirklich Schritt für Schritt aufgebaut wird.

Sigurd Schacht:

das Ergebnis Ja, das heißt, wir arbeiten eigentlich nicht auf den Texten, wenn man es genau nimmt, sondern auf den Tokens, und es geht um die Wahrscheinlichkeiten, also die Probabilitie der Tokens in dem gesamten Vokabular.

Carsten Lanquillon:

Ja, und ich lasse also immer, wenn ich in meinem sagen wir mal innerhalb dieses Select Statements sozusagen oder wo ich halt angebe, was ich haben will das ist ja quasi mein Promt und wenn ich da auf bestimmte Anweisungen stoße, wie zum Beispiel hier muss ich jetzt mein Sprachmodell aufrufen, weil ich das Template damit befüllen muss dann wird das Sprachmodell aufgerufen, und dann werden Token für Token, also es wird für jedes Token so wie ich es verstanden habe, muss es aufgerufen werden. das ist natürlich noch eine Sache, die wir diskutieren können, wie das ja effizientes Ganze ist. Ich rufe es also für jedes neue Token separat auf, um halt, weil ja die Sprachmodelle unterschiedliche Werte über die APIs unterschiedliche Wehigkeiten anbieten, wie ich es nutzen kann, und wenn ich halt Kontrolle haben will darüber, was ich da erzeuge, muss ich das auf Tokenbasis machen, und ich ziehe das dann diesen Constraints dieser Prüfung Entweder. ist es uneingeschränkt, dann kann das halt einfach weitere Tokens generieren, oder aber du hast ja schon gesagt, was kann da stehen?

Carsten Lanquillon:

das können einfach sein, dass ich sage, es soll eine Zahl sein und Integer meinetwegen, oder es soll eine gewisse Länge nicht überschreiten, oder wenn ich auf ein bestimmtes Token stoße, dann soll ich aufhören, abbrechen, ne, eine neue Zeile oder so, was zum Beispiel Die gewisse Länge hatten wir schon. ich kann reguläre Ausdrücke angeben, ich kann sogar so eine Verteilung, ja, aber eigentlich eine Menge definieren. Hier ist ne, ich mach zum Beispiel eine Sentimentanalyse und sage naja, die Klassen, die du jetzt identifizierst, soll eine von positiv, negativ oder neutral sein, und dann ist es klar, dass das das Ergebnis aus dieser Menge kommen soll.

Sigurd Schacht:

Du hast jetzt gesagt, abhieß. Ich würde das, glaube ich, erstmal bezogen auf die Sprachmodelle selber und nicht noch diese Komplexität mit einer abhiatz mit reinnehmen. Weil eigentlich geht es ja, wenn man das sich besser vorstellen möchte die Sprachmodelle sind ja Autoregressionsmodelle, das heißt, wir haben ja sozusagen den gegebenen Input, und dann wird genau ein einziger Token prognostiziert, und dieser eine Token wird beim Indieser Autoregression ja solange, bis ein Stoptoken erzeugt wird, also bis er dann sein definiertes Ende bekommt, wird er wieder angehängt und wieder in das Modell eingeben, und das wird so lange gemacht, wie der Text sozusagen, oder bis wir halt zu dem Stoptoten kommen. Und genau in diesen Autoregressionsschritten, da setzt man eigentlich an und beschränkt dann eigentlich über die Constraints, was man hat definiert, den Raum oder den Rahmen der nächsten Togens, die erlaubt sind. Und damit kann ich in einer gewissen Weise ziemlich scharf so würde ich es zumindest verstehen ziemlich scharf definieren, wie so ein Output auch sehen kann, und kann dann damit und da kommen wir dann in dieses Thema Language Model Programming und kann dann sozusagen mal wirklich sicher definieren, dass immer mit hinten aufruf genau diese Struktur, diese Themen, die halt in diesen Constraints festgelegt sind, rauskommen.

Sigurd Schacht:

Also, wenn du den integer definierst, dass halt immer eine Zahl rauskommt und keine Variation eigentlich möglich ist, wenn man das so sieht.

Carsten Lanquillon:

Ja, ich meine, zu kläre, wäre dann dann mal an der Stelle. Zum Beispiel, wenn jetzt ich weiß halt, was als nächstes Token erlaubt ist, dann nehme ich einfach das erste erlaubte Token mit der höchsten Wahrscheinlichkeit, aber die kann ja ziemlich gering sein. Also sozusagen akzeptiere ich das, oder aber das wäre jetzt wieder die Wahl, wie man sowas umsetzen kann. Wenn das einfach zu unwahrscheinlich ist, könnte ich natürlich das Sprachmodell wieder erneut aufrufen, bis irgendwann mal eine Variante kommt, die irgendwie sinnvoller erscheint. Potenzial würde man einfach sagen. Ich habe ja jedes Token bewertet. Wenn ich da rankomme an die Ergebnisse mit den Lockets und den Wahrscheinlichkeiten, dass sie jetzt gewählt werden, nur gut, und wenn ich die einfach wegblende, die nicht zu, dass sie sind, die Bedingungen nicht erfüllen, bleibt aber trotzdem eins über mit der größten Wahrscheinlichkeit, was die Bedingungen erfüllt, und dann kann ich das entsprechend heranziehen.

Sigurd Schacht:

Da kommen wir so ein bisschen dann in die Überlegereien. LMQL, so vom Prinzip her super. Also das gefällt mir wahnsinnig gut. Aber es hat halt eine gewisse Restriktion, jetzt nicht von den Constrains, was es selber kann, sondern Restriktionen, wo ich es in Gänse anwenden kann. Und wenn man überlegt, wir brauchen eigentlich, um so eine Einschränke vornehmen zu können, brauchen wir im Output die Lockets, also durch die Wahrscheinlichkeitsverteilungen in dem Vokabular oder in den Topens, und die müssen im Endeffekt komplett für jeden Autoregressionsschritt gegeben werden.

Sigurd Schacht:

Sind die nicht da, dann kann ich manche Dinge von diesen Constrains nicht durchführen. Und wenn man jetzt die Chatmodelle von Open AI anschaut, da werden die Lockets momentan noch nicht übermittelt. Es gibt zwar irgendeine Diskussion, dass Open AI und die haben das angekündigt, dass es irgendwann auch so sein wird wie bei den GPT-3-Modellen, dass man im Endeffekt für jeden Token auch die Wahrscheinlichkeitsverteilung bekommt und auch weiß, welche anderen Tokens oder welche anderen Wörter aus dem Dictionary welchen Werte bekommen haben. Und damit kann ich natürlich so einen Ansatz ziemlich extrem durchführen. Aber eben den Chatmodellen ist das momentan noch nicht so, und das merkt man dann auch in der LMQL-Sparke, dass manche Befehle, manche Strukturen halt mit den Chatmodellen nicht funktionieren.

Carsten Lanquillon:

Dass du über die API sagst, so wird es nicht ausgegeben, weil man es ja über das Webfrontend sich diese Wahrscheinlichkeiten durchaus anzeigen lassen kann.

Sigurd Schacht:

Nein, in der API wird schon auch ausgegeben, aber nicht für die Chatmodelle. Also praktisch für die Completion-Modelle, da ist es kein Problem. da kannst du einfach sagen bitte die Wahrscheinlichkeiten mit ausgeben, und dann kriegst du die auch, Und dann hast du im Endeffekt auch in der API Response hast du dann auch deinen eigentlichen Text, den er generiert hat, und unten runter hast du dann im Endeffekt in so einer weiteren Dictionary Section dann die Verteilung der Wahrscheinlichkeiten.

Carsten Lanquillon:

Genau weil das habe ich gesehen, dass das sehr verwendet wird. Ja, das sieht man ja auch wenn im Chatmodell nicht.

Sigurd Schacht:

Wenn du es dann im Playground oder auch in anderen Oberflächen an die Joss, sieht man ja so häufig dann so farbliche Verteilungen, wo man sagt, also rote sind niedrige waren eigentlich, und grün und dann kann man schön sehen, wie dann über den Text sozusagen sich die Wahrscheinlichkeiten über die Dekodierungsstrategie verteilen.

Sigurd Schacht:

Und das ist aber im Endeffekt halt die Notwendigkeit, um auf Token-Level Einfluss nehmen zu können. Ander wenn es nicht geht, dann sind wir eigentlich auf einer Ebene, wie jetzt auch in GodRays, als Andress-Famework das macht, dass man sagt, wenn der Output nicht da ist und das hat so ja auch schon angedeutet dann mache ich den neuen Brompt zurück an das Modell und sage dann also wie so ein Output-Parser, der dann hinterher prüft, ob der Output richtig ist, und wenn nicht, kriegt das Modell halt einen neuen Brompt mit dem neuen Hinweis Achtung, so nicht bitte nochmal machen. Und das hat so lang, bis der Output, der erst den man wünscht Ist, auch eine Möglichkeit hat aber den Nachteil, dass ich natürlich nicht effizient bin, und das ist ja, dass, was LMQL auch sich auf die Fahne schreibt, also einmal modellagnostisch zu sein, also das ist für alle Modelle, die es gibt, irgendwie anwendbar ist. Also sie versuchen, diese Einschränkungen von OpenAI mit den Chatmodellen mit etlichen Tricks ist vielleicht der falsche Ausdruck aber mit viel Aufwand so umgehen, so dass man damit auch was machen kann.

Sigurd Schacht:

Aber das Ziel ist halt, dass es einfach für alle Modelle funktioniert, was im Endeffekt bei diesen also das der eine Punkt, und der andere Punkt ist natürlich auch, eine gewisse Effizienz reinzubringen. Also es gibt auch so schön schön Partien im Paper, wo sie aufzeigen, dass man bis zu 80% der verwendeten Tokens reduzieren kann im Vergleich zu halt klassischen Aufruf der Sprachmodells durch die Verwendung von LMQL.

Carsten Lanquillon:

Kann man so viel reduzieren. Was mich wundert, ist ich meine, dadurch, dass ich für jeden token einen neuen Aufruf habe, muss ich ja den gesamten oder Großteil des bis langerzeugten Promtes zumindest wieder mit übergeben. Das ist auch schon jede Menge an Token Traffic, den ich erzeugt oder nicht.

Sigurd Schacht:

Ja, ehrlich gesagt, ich bin mir da auch nicht ganz sicher.

Sigurd Schacht:

Deswegen es wäre mal spannend ich bin noch nicht dazugekommen direkt in den Quellcode von LMQL direkt reinzuschauen und da sich das herauszuarbeiten, wie das genau gemacht wird, oder auch mit einem der Autoren oder Projektinitiatoren mal zu sprechen, wie genau das denn aufgesetzt ist, weil ich glaube, dass die Einsparung halt daherkommt. Wenn ich halt direkt Einfluss nehmen kann auf den Output über die Token-Level, also betrisch, token Decoding Mask oder wie auch immer, wenn man das bezeichnen möchte, dann habe ich den Vorteil, dass ich nicht so oft das Sprachmodell wieder aufrufen muss. Ich hatte zwar in der Autoregression immer das Thema, dass ich mein Promt, also mein Input, immer wieder neu eingebiesen hat. Eigentlich auch in der Autoregression läuft und bei einer App die das halt dann immer voll gezählt wird, was ja sonst, wenn ich den Call einfach absetzt, immer nur einmal gezählt wird. Aber in dem Fall würde ich sagen, es ist halt eher das Thema, wenn der Output hinterher gepasst wird und der dann falsch ist, dann muss ich einen komplett neuen Promt abrufen, und es halt so lange, bis das Modell endlich mal sich bequemnt, um das so auszudrücken.

Carsten Lanquillon:

Ich bin in der Erzeugung des Outputs wesentlich effizienter, weil ich nur das generiere, was ich brauchen kann.

Carsten Lanquillon:

Das ist klar. Aber ich muss halt jedes Mal beim Aufruf, wenn der Aufruf teuer ist als solches, dem, was ich immer als Promt als Kontext mitgebe, kann das ein Problem sein, und da sehen wir. Aber das ist ja einfach die Herausforderung, die sich dadurch ergibt, dass ich Modellagnostisch hast du schon gesagt, ich möchte beliebige Modelle nutzen können hätte ich jetzt ein lokales Modell und kann da in diesen autoregressiven Kontext direkt selbst eingreifen, dass ich quasi immer da jetzt neue Fragmente von meinem Promt einfach injiziere, wenn ich weiß, ich habe ja diesen Promt. Ich will ja gar nicht Wort für Wort kompletter Antwort aufbauen, sondern ich möchte eigentlich ist es ja ein Lückenfüllen dass ich weiß, ich habe jetzt Komma in eine Stelle in meinem Promt, ich baue das iterativ auf.

Carsten Lanquillon:

Dann muss ich jetzt, jetzt muss ich was generieren, denn lasse ich das Modell das generieren, dann kommen wieder Passagen, die ich schon vorgefertigt habe in meinem Promt. Das heißt, es ist ja viel mehr ein Lückenfüllen, und eigentlich brauche ich ein Kontrollmechanismus, der mir genau steuert, wann brauche ich das Modell zum Füllen, und wann habe ich schon vorgefertigt ein Text und kann das anders eingehen. Und so lange ich diesen das ist ja das, was LQL letztendlich mit der Grundmacht oder alle anderen Modelle auch und die, die auf der Basis arbeiten, und so lange ich das getrennt habe von meinem Modell, muss ich es halt irgendwie so regeln. Wenn ich mein eigenes Modell im Hintergrund hätte, könnte ich das direkt da einbauen und langfristig klar. Wenn es darum geht, so was jetzt.

Carsten Lanquillon:

Für mich ist es noch mehr so eine Ebene, so ein Proof of Concept. Ich zeige mal, was man damit alles Gutes Toiles machen kann. Wenn es dann in Jahren mal dahingeht, das zu optimieren, wie was bei SQL, was ich Datenbanken ja auch haben, wo ich war, okay ist es desktriptiv, ich sag, was ich haben will, und die Optimierer wissen, wie sie das irgendwie gut hinkriegen kann. Das nativ, direkt irgendwie oder, wenn die APs das entsprechend zulassen, das ein Sprachmodell hast, da kannst du nur mal wegen Funktion mit übergeben, die, der genau sagt, wann hat was irgendwo noch zu ergänzt werden in meinem generierten Ausgabe, dann kann ich, habe ich da später vielleicht mal viel, viel mehr Optimierungsmöglichkeiten.

Sigurd Schacht:

Ja, man muss ja auch ganz ehrlich sagen das Projekt ist jetzt wie alt? ein halbes dreiviertel Jahr. Und von wann waren das Paper? weißt du das zufällig?

Carsten Lanquillon:

Um 20.00 das.

Sigurd Schacht:

Jahr ist oder ich weiß gar nicht ne, 30.

Sigurd Schacht:

Mai, ich habe es gerade dachschauen können, 30. Mai. Also es ist jetzt ja auch nicht so, dass das total reif ist in dem Sinne, sondern man merkt ja, da passiert viel. Das ist ein sehr kleines Team, das daran arbeitet, aber halt wirklich super effizient, würde ich zumindest gefühlt sagen, was die da schon bewegt haben in den letzten halben Jahr oder Jahr, wobei ich gehört habe, dass ich schon länger daran arbeite, also nicht nur erst seit ChatchiPT, sondern schon länger, aber natürlich jetzt, dass immer mehr in die Präsenz kommt mit dem kontrollierendes Outputs.

Carsten Lanquillon:

Was sehr spannend, Ja, ich würde gerade sagen also noch ein bisschen Spannung, außer ob ich jetzt bin gespannt, ob du das Gleiche sagen wolltest.

Carsten Lanquillon:

Nein, also ich hatte das ja gesehen mit dem, mit der Entwicklung von ChatchiPT und anderen Sprachmodellen. Das erste, was mir in Sinn kam, gerade in einer Analogie zum SQL, was, was mir fehlte oder was ich noch nicht gesehen habe. Ich gebe ja ein Sprachmodell an, und ja, ich habe mir sofort gedacht, ja, warum nicht from? und dann einfach mehrere Sprachmodelle angeben können, sodass ich beim bei der Erzeugung auch noch wählen kann, nämlich das eine, nämlich das andere, kann verschiedene Antworten oder bestimmte Fähigkeiten zusammenführen und habe letztendlich sowieso ein Multiagentensystem.

Sigurd Schacht:

Ja, das braucht es, glaube ich, irgendwann, gerade unter dem Gesichtspunkt, dass ja die großen Modelle GBT4 und so weiter MixedShop Experts sind, und damit können wir natürlich auch mit so einer Programming Language, also large Language Models, dann im Endeffekt auch solche MixedShop Expert.

Carsten Lanquillon:

Systeme eigentlich zusammen basteln, Wenn man diese SQL-Anologie hat, dass ja direkt das hergibt, weil ich ja da ja auch problemlos beliebige Tabellen angeben kann, aus denen ich meinen meinen Ergebnis zusammenbaue.

Sigurd Schacht:

So ist es, als die Fahrung war auch noch eine Join und so was braucht. Aber das wird dann, glaube ich, zu viel. Also, wir haben nicht ganz das gleich im Kopf gehabt. Was ich noch unbedingt hervorheben möchte, was mich total fasziniert, ist, dass die das Team um LMQL rum, dass die so einen coolen Black Round gemacht haben, wo man im Endeffekt also muss man sich unbedingt anschauen, LMQLai, also LMQLai, und dann gibt es, glaube ich, oben links Playground, und da kann ich im Endeffekt mit dieser Sprache spielen hinterlegenden Key zu OpenAI, der dann lokal im Browser nur gespeichert wird, also nicht übertragen wird, und dann kann ich im Endeffekt diese Sprache ausprobieren und sehe auch den Output und so weiter. Und was echt toll ist, ist, dass man so einen Decoding Passer hat, also man kann das dann anklicken und wirklich Schritt für Schritt sehen, wie die einzelnen Schritte aufgebaut sind und was dann mit diesem Framework passiert und was der Output ist und so weiter. Also total faszinierend.

Carsten Lanquillon:

Ja, und durch viele, viele schöne Beispiele dabei. Kleiner Knackpunkt ist das Hack manchmal ein bisschen beim aktualisieren. Also man muss mal gucken, dass bei meinem Browser zumindest dass die Ausgaben in den verschiedenen Fenstern nicht immer zusammen passen oder aktuell sind, wenn man. Naja, man muss sagen, wir sind noch auf Warten. Aber das ist ja in dem Stadium so mal absolut zu verzeihen, weil es einfach schön ist zu sehen, wie es funktioniert.

Sigurd Schacht:

Ja, es ist echt deutlich transparenter, das muss ich sagen. es ist definitiv ein Framework, wo man hinschauen muss, was sich noch passiert. Es gibt eine schöne Pyson Integration, also die Ernährung an die du hast angedeutet, dass man Pyson wirklich nativ sozusagen als Basis benutzt und sich gar nicht mehr so wechseln muss, ist ganz toll. Und was auch noch ein ganz wichtiger Punkt ist, finde ich, viele vielleicht der Zuhörer oder auch die, die sich jetzt noch auf die Reise begeben werden irgendwann nicht um Langchain rumkommen.

Sigurd Schacht:

Langchain ist ja sozusagen ein Framework, das hilft, sozusagen Renten zu bauen, das ist prompting automatisiert, das Training im Endeffekt. das prompting automatisiert ist falsch ausgedrückt, aber das Bauen von Prompt Chains unterstützt und hat viele der Paradigmen, die in den wissenschaftlichen Papers vorkommen, auch wirklich direkt in den Framework rumsetzen. Und was Langchain aber nicht macht, ist tatsächlich auf Token Level irgendeine Einschränkung oder Ähnliches vornehmen. Das heißt also, da läuft man genau diesen Weg, dass man einen Output Passer hat und hinterher dann schaut, was das Ergebnis und wieder dem Modell gibt zum Korrigieren, also Refine Chains oder sowas. Und was toll ist, ist, dass die Art und Weise, wie dieses LMQL gebaut ist, kann ich das ohne Probleme vor Langchain hängen oder vor jedes andere Framework hängen und dann erst den Langchain reingehen, Also die Integration in die bestehenden ich sag mal Player in der ganzen Framework-Welt ist 100% gegeben, und das heißt, ich kann das als Restriktion vorne dran hängen, oder ich kann den Output von Langchain nehmen und dann den LMQL weiterverarbeiten und so weiter und so fort.

Sigurd Schacht:

Und das ist, glaube ich, schon ein absoluter Mehrwert, das ich da nicht umdenken muss im Sinne von oh, jetzt nehme ich das Framework oder jenes Framework, sondern dass ich für diesen Anwendungsfall, nämlich die Ereingrenzung oder das Programmieren von Sprachmodellen, halt LMQL verwende und dann vielleicht für die Retriever Chains oder für was anderes halt Langchain mit dran hänge. Glaubt, spannender erste Einblick, oder?

Carsten Lanquillon:

Ja absolut. Also, es lohnt sich, da mal drauf zu schauen, und gut, in der Folge, wir werden es vertiefen, wir werden auch natürlich andere Varianten, andere Möglichkeiten, die vielleicht ein bisschen von der Programming First wie ich das nenne Perspektive da draufgehen. Wir haben ja hier gesehen, dass das ein bisschen vielleicht ein Abkehr davon, dass ich das stärker in die Programmiersprache integriere und nicht diese Text-Promptescript-Sicht als erstes habe. Ich meine, am Ende vom Ergebnis mag es vielleicht keine Rolle spielen.

Carsten Lanquillon:

Das ist bei der Entwicklung entscheiden, wie stark ich die Unterstützung von, weil was in der neuen Entwicklung die werden vielleicht nicht sofort mit entsprechenden Entwicklungsungebungen wie für sich Visual Studio Code und Co irgendwie unterstützt werden, und wie stark habe ich dann in dem Kontext eine Unterstützung. Was ich so in der Tagsüberprüfung passt und der sehe ich halt oft, solange der Skript irgendwo dann ran hat, text ist, dann sehe ich, muss ich halt selbst da irgendwie prüfen, ob das stimmt oder auch nicht, wenn da Fehler drin sind, manchmal ein bisschen haarecht zu finden, wie das früher bei SQL Statements war, die man in einer Programmiersprache eingebaut hat, oder es ist halt genau anders rum dann sehe ich vielleicht einen editor, der die syntax überprüfen kann, wenn es ihn schon gibt. Aber dann ist die Frage, wie weiter halt die Python-Fragmente dann da richtig noch entsprechend darstellt.

Sigurd Schacht:

Vielleicht so vorstellig. Es gibt ein Plug-in für Visual Studio Code, dass die syntax Highlighting macht, aber halt nicht so umfänglich, wie man es hat.

Carsten Lanquillon:

Gewohnt ist bei Python Ja, aber es fehlt halt ein bisschen diese Unterstützung, die man sonst gewohnt ist, und das macht es am Ende immer so. Ja, da, jetzt ist ja viel zu latente Unwohlsein bei bestimmten Ansätzen, also jetzt nicht konkret bei dem oder nur da, sondern generell bei diesen Mischformen, weil wir haben hier verschiedene Ansätze, die zusammengeführt werden, und einer davon scheint dann immer führen zu sein. Das ist richtig. Was noch?

Sigurd Schacht:

ganz Lustig ist, weil wie gesagt, ich habe das ein bisschen ausprobiert wenn man Co-Pilot verwendet, dann würde man ja sagen, das Sprachmodell, das hinter Co-Pilot steckt, kann jetzt so eine neue Sprache oder so ein neues Paradigma gar nicht sozusagen unterstützen. Aber wenn man genügend von den Fragmenten sozusagen in seinem Repository oder in seinem Folder hat, dann schafft Co-Pilot es nach kurzer Zeit tatsächlich, auch richtige LMQL-Syntax zu prognostizieren. Es kann es faszinieren, dass das auch ganz gut funktioniert. Also, es ist tatsächlich schon so, dass es nicht komplett losgelöst ist, dass man auf der grünen Wiese dann da sitzt und gar nicht sinken kriegt. Aber es ist schon, wie du sagst, das muss sich alles entwickeln, und ich glaube, das ist ein wirklich spannendes Projekt, wo man sicher noch mehr davon hören wird. Da bin ich mir ziemlich sicher. Von daher würde ich sagen, schließen wir heute die Sendung. Vielen Dank, dass Sie wieder zugehört haben Haben bei uns zu dem Thema Language Model Programming, und ich wünsche Ihnen eine schöne Restwoche.

Carsten Lanquillon:

Bis dahin ciao, Ciao.

Speaker 2:

Das war eine weitere Folge des Knowledge Science Podcasts. Vergessen Sie nicht, nächste Woche wieder dabei zu sein. Vielen Dank fürs Zuhören.