Hallo und herzlich willkommen zu einer neuen Folge vom Podcast Software Testing. Ich bin euer Host Ritchie und diesmal habe ich wieder mal eine Folge aus dem KI-Umfeld. Wer den Podcast von Anfang an hörte, hat vielleicht noch die Folge mit David Farago in Erinnerung, wo es um die Qualitätssicherung mit und von Prompt Engineering ging. Und jetzt ist er wieder da mit dem Thema
Acceptance Test Driven LLM Development. Er plaudert aus dem Nähkästchen, wie er und sein Team ein Large Language Model umsetzen, welche Tests sie machen, welche sie nicht machen und wie die Teststruktur und die Teststrategie bei ihnen aussieht. Sehr spannend. Viel Spaß bei der Folge. Hallo David, schön, dass du wieder mal hier im Podcast bist. Dankeschön Ritchie. Ja, freut mich, dass ich wieder hier sein kann.
Ja, wir hatten ja das letzte Mal über Prompt Engineering gesprochen und Qualitätssicherung von mit Prompts. Das war schon sehr spannend und ich kenne dich als richtiger Crack für diese ganzen LLM Themen, KI Themen. Da bist du echt einer meiner Pop-Experten. Wenn ich eine Frage habe, dann schicke ich die immer dir und dann gibst du mir auch und das finde ich immer super, weil ich da weiß, du setzt dich echt intensiv darin. Danke schön. Danke schön. Danke schön.
mit auseinander. Es gibt ja jetzt gerade so unheimlich viele KI-Experten, aber bei dir merke ich schon, du hast da echt auch schon den Deep Dive gemacht und kannst und kennst das Thema einfach super und darum freue ich mich, dass wir heute wieder zusammen sind. Ein bisschen anderes Thema
und da würde ich gleich mal den Ball rüberspielen. Was hast du uns denn mitgebracht? Also letztes Mal ging es eben um das Prompt-Engineering, das heißt, dass man eben nur die Prompts abändert, also die Eingabe abändert, um das LLM zum richtigen Verhalten zu bringen und wenn man damit nicht weiterkommt, kann man dann das Fine-Tuning betreiben und das ist das Thema heute, dass man eben so ein Basis-LLM nimmt, so ein Foundational-Model und Prompt-Engineering spielt immer noch mit rein,
aber dass man dann tatsächlich die Gewichte nochmal fein justiert, hin zu genau der Aufgabe, die das LLM eben erfüllen soll. In meinem Kontext bei Mediform geht es eben darum, dass das Language-Model eingesetzt wird, um einen Telefon-Bot für Arztpraxen anzubieten. Ah ja, wie sieht das dann in der Praxis aus, ist dann dieser Bot?
Der sieht so aus, dass wenn man bei seinem Hausarzt, wenn er dann eben diesen Bot einsetzt, endlich mal wieder durchkommt, also keine besetzte LLM, dann ist das dann so, dass man dann auch die LLM-Modelle einsetzt, die man dann auch in der Praxis einsetzt, die man dann auch in der Praxis einsetzt, die man dann auch in der Praxis einsetzt, die man dann auch in der Praxis einsetzt, die man dann auch in der Praxis einsetzt,
und dann wird die besetzte Leitung mehr da ist. Und dann meldet sich direkt dieser Telefonassistent, sagt: "Hallo, die Praxis sowieso hier. Ich bin Luca, der Telefonassistent. Was für ein Anliegen haben Sie?" Oder erklärt tatsächlich noch: "Sie können in ganz natürlicher Sprache mit mir sprechen." Und das ist im Prinzip der Gag, dass man nicht eben diese abgelutschten, furchtbaren UIs benutzt.
Wenn Sie einen Termin haben wollen, drücken Sie die 1. Wenn Sie ein Rezept haben wollen, drücken Sie die 2. Und die Option, die man braucht, ist natürlich nicht vorhanden. Und man muss sich die ganze Menüführung durchhören. Und also ganz furchtbar. Bei uns funktioniert das in ganz natürlicher Sprache. Ah, ist ja sehr spannend. Erzähl mal, wie könnt ihr denn sowas denn gut entwickeln und mit guter Qualität? Wie geht ihr denn da rein?
Ja, das ist relativ anspruchsvoll. Also letzten Endes haben wir ein paar Komponenten. Wir machen zuerst eben Speech-to-Text. Und dann auf reiner Textbasis benutzen wir eben so ein Language-Model. Machen immer noch, wie gesagt, relativ viel Prompt Engineering. Passen aber dann auch das Foundational-Model an. Da haben wir zum Teil eben ein GPT-Gefine-Tuned. Das ist die eine Variante. Zum anderen wirklich, dass wir ein Open-Source-Modell wie Mistral nehmen und das dann weiter fine-tune.
Und eben auf passenden Dialogen, die dann eben nicht mehr Audio sind, sondern rein Textbasiert. Aber man muss da schon berücksichtigen, dass die Texte, die wir dann dann auf den Textbasis nehmen, dass die Texte durch Speech-to-Text kommen und manchmal gibt es auch Transkriptionsfehler. Genau. Und bei diesem Fine-Tuning, Datensammeln, haben wir dann eben so einen relativ soliden Prozess gewählt und auch solides Test-Framework entwickelt, um dann eben eine hohe Qualität gewährleisten zu können.
Ja, uns interessiert natürlich auch ganz besonders ja das Thema, wie testen und wie nähert man sich denn so ein Ding an? Und ja, vielleicht kannst du es da noch ein bisschen mehr reinholen. Ja, gerne. Also letzten Endes ist es eine relativ große Herausforderung und auch ziemlich Neuland. Es gibt so einen schönen Artikel: "LLM's technology gifted by aliens". Und so ist es auch. Man hat dann da eben so ein mächtiges Modell, das irgendwie super mit natürlicher Sprache umgehen kann.
Schlüsse ziehen kann für unheimlich viele Downstream-Tasks, also unheimlich viele verschiedene Aufgaben angewendet werden kann.
Aber wenn es dann darum geht, irgendwie das einzubetten und weiterzuentwickeln mit einem soliden Prozess, also die LLM-Entwicklung selber, die ist halt irgendwie noch in der Steinzeit, weil es halt irgendwie ein ganz junges Gebiet ist und sich rasant weiterentwickelt, die LLM's, kommt man eben mit den Prozessen und den Tools, wenn es überhaupt, welche Größen, welche Anwendungen es gibt, nicht hinterher. Und die Anwendung ist ja auch super schwierig.
Also es ist jetzt das erste Mal, wo es richtig natürlich sprachlich möglich ist, Anwendungen zu entwickeln. Das ist Neuland. Das LLM ist nicht deterministisch, eine ziemliche Black Box. Das heißt, die Verifikation ist unheimlich schwierig. Und genau, das sind so irgendwie die Ursachen dafür, dass es da Herausforderungen gibt.
Und das ist auch, was wir jetzt auch schon in der LLM-Entwicklung gesehen haben, dass wir das auch in der LLM-Entwicklung sehen, dass wir das auch in der LLM-Entwicklung sehen, dass wir das auch in der LLM-Entwicklung sehen, dass wir das auch in der LLM-Entwicklung sehen, dass wir das auch in der LLM-Entwicklung sehen, dass wir das auch in der LLM-Entwicklung sehen, dass wir das auch in der LLM-Entwicklung sehen, dass wir das auch in der LLM-Entwicklung sehen,
dass wir das auch in der LLM-Entwicklung sehen, dass wir das auch in der LLM-Entwicklung sehen, dass wir das auch in der LLM-Entwicklung sehen, dass wir das auch in der LLM-Entwicklung sehen, dass wir das auch in der LLM-Entwicklung sehen, dass wir das auch in der LLM-Entwicklung sehen, dass wir das auch in der LLM-Entwicklung sehen, dass wir das auch in der LLM-Entwicklung sehen, dass wir das auch in der LLM-Entwicklung sehen, dass wir das auch in der LLM-Entwicklung sehen,
Und der dritte Angriffspunkt war dann eben eine solide Verifikation. Das heißt, dass man, obwohl so ein LLM eben nicht deterministisch ist und eine Blackbox, dass man dann da irgendwie trotzdem vernünftig testet. Es gibt diesen Language Model Evaluation Harness von Eloytha, der ist allgemein nicht so bekannt, aber das LLM Leaderboard bei Huggingface ist relativ bekannt. Und da steckt tatsächlich dieses LLM Evaluation Harness von Eloytha dahinter. Ah ja, okay.
Und das lässt sich auch relativ gut anpassen. Das haben wir dann kräftig aufgebohrt, direkt in Bezug auf eben unser Anliegen. Und die Business zugeschnitten auf eben die Business Requirements, die wir haben, um überhaupt erstmal vernünftig messen zu können. Es ist immer noch nicht irgendwie perfekt. Es ist halt enorme Herausforderung. Da tut sich auch im Moment in der Forschungscommunity viel, wie man eben diese natürlichsprachlichen Aufgaben gut messen kann.
Und ich meine, es gibt Aufgaben, wo dann irgendwie relativ... Oder wo es dann eindeutig ist, was das Language Model antworten muss. Dann kann man einfach irgendwie einen String-Vergleich auf Identität machen. Dann gibt es das andere Extrem, das ist dann eben irgendwie, so wie du es mal gemacht hast, irgendwie ein Gedicht schreiben lassen. Da liest man dann als Mensch drüber. Und wenn dann irgendwie die eine Zeile ein bisschen anders ist als bei der nächsten Generation, dann kratzt es eigentlich.
Ja, das ist das Problem. Und mit unserer Anwendung, der Terminus Technicus ist Task-Oriented Dialog, ist man genau in der Mitte. Das heißt, es geht schon darum, irgendwie eine spezielle Aufgabe zu lösen. Aber ob der Bot jetzt sagt, hallo Ritchie, habe ich richtig verstanden, Sie wollen einen Termin buchen? Oder ob er sagt, Sie wollen also einen Termin buchen, Ritchie? Ist halt nicht identischer Style. Das ist ein bisschen wie ein String, aber semantisch identisch.
Das heißt, da muss man dann eben so eine semantische Prüfung machen. Ah ja, okay. Das ist bei euch ein Bereich der Verifikation, wo ihr quasi da versucht, Tests zu entwickeln, die dann dann einfach auch dieses Zwischenspiel dann einfach abdecken können. Genau. Also letzten Endes haben wir so einen sogenannten Tool-Former-Ansatz. Also Tool-Former war ein Papier. Also agentenbasierter Ansatz könnte man es auch nennen.
Das heißt, unser Language-Model erzeugt dann Ausgaben, die teilweise direkt an den Patienten gehen. Das ist dann so natürlichsprachlicher Text. Aber zum Teil auch eher so Funktionsaufrufe, die dann entweder vorgefertigte Nachrichten sind. Also der Telefonbot meldet sich halt jedes Mal mit einem relativ ausführlichen Text. Da gibt es keinen Grund, dass das Language-Model jedes Mal so viele Tokens generiert. Stattdessen gibt es Handelsformen. Also vorgefertigte Nachrichten.
Und die werden dann eben in Form von einem Funktionsaufruf erzeugt. Und das Language-Model kann auch andere Funktionsaufrufe, Datenbankabfragen oder so erzeugen. Und die müssen natürlich ganz korrekt sein. Das heißt, wir haben dann unser Verifikationswerkzeug, unterscheidet dann eben, in welcher Situation es gerade ist. Ist dann entsprechend kulander oder ganz streng. Und wie viel Automatisierung steckt dann drin?
Sind eure Tests, die ihr hier entwickelt, sind die quasi alle auch so automatisiert? Du hast ja gesagt, ihr macht viele Iterationen auch. Wie kann ich mir denn das vorstellen? Also letzten Endes gehen wir dann in diesem Cognolitica-Zyklus hin und machen am Ende eben so ein Provisioning, dass man... Tatsächlich irgendwie dem Pilotkunden das aktuelle Modell gibt. Und der setzt das ein und sammelt dann... Und da sammeln wir dann anonymisierte Dialoge, also die wirklich stattgefunden haben.
Dann gehen wir eben in eine neue Iteration, in dem wir zuerst eben so ein Business Understanding und Data Understanding machen. Das heißt, diese Dialoge analysieren. Da haben wir zum Teil so Business Intelligent Tools, wo wir dann messen, wie viel Prozent dieser Dialoge waren vorhanden. Vollständig autonom. Sind zum Ziel gekommen, vollständig autonom. Wurden nicht dann doch an die Assistentin weitergeleitet, weil es ein Notfall ist oder sonst was.
Das Language Model sich nicht sicher war, sondern wirklich komplett bis zum Ziel abgehandelt. Das ist irgendwie eine wichtige Metrik, die wir haben. Wir haben aber noch einiges anderes. Dann erkennen wir, welche Dialoge eben suboptimal waren, analysieren die, leiten dann neue Business Requirements ab, machen dann eine solide Fehleranalysierung.
Dann können wir dann auch noch eine neue Analyse und gehen dann über in die Phase des Data Generation ist das oder Data Preparation, um neue Dialoge zu erzeugen. Da haben wir eben auch, das ist dann im Prinzip schon das Format, das dann auch unser Testwerkzeug liest. Also wir probieren auch tatsächlich irgendwie ein, die Dialoge sind im Zentrum und dieses eine Dialogformat möglichst durchgängig in dem ganzen Prozess. Deswegen haben wir unser Test Tool auch angepasst auf dieses Format.
Da kann man auch relativ mächtig dann eben Template basiert Dialoge schreiben. Und das machen wir dann zum einen fürs Training Set und so fürs Testing Set. Und dieses Test Set sind im Prinzip Akzeptanz Tests. Die sehen dann halt ein bisschen anders aus, sind Dialog basiert, aber letzten Endes sind es Akzeptanz Tests, die dann, wenn wir schreiben, weil sie eben herkommen aus der Analyse, die wir dann machen.
Diese fehlerhaften Dialogen, die tatsächlich stattgefunden haben, schlagen die dann natürlich auch fehl. Das heißt, unser Language Model kann die nicht bewältigen, aber wir erzeugen auch eben relativ viele Trainings Dialoge. Entsprechende trainieren dann das Modell neu, um dann hinterher zu schauen, ob das Modell was dazugelernt hat und nicht irgendwelche Regressionen, hat. Das heißt, wir lassen dann natürlich auch die alten Tests drauf laufen.
Und da haben wir dann im Prinzip so eine Verbindung zwischen diesem Menschen Learning Ansatz, wo man dann eben so ein Training Set hat zum trainieren und ein Test Set zum evaluieren und machen das eben dann Business orientiert mit diesen Dialogen. Und es ist dann im Prinzip so ein Akzeptanz Test Driven Development eingebettet in das Machine Learning. Na ja, okay, also spannend. Das ist das, das das verwebt sich ja dann da total mit dem mit dem mit dem Lernen, mit dem Neulernen des Modells auch.
Das ist das und genau verwebt finde ich schöner Begriff. Genau das ist es nämlich, dass man dann wirklich dieses diese modernen Vorgehensweisen von Akzeptanz Test Driven Development oder agilen Methoden allgemein nutzen kann, aber um auf dieses Machine Learning und kann da auch relativ gute Vergleiche ziehen, wie man eben so dann fehlschlagende Testfälle schreibt. Also letzten Endes beim Akzeptanz Test Driven Development und dem, was wir machen.
Ich habe es Akzeptanz Test Driven LLM Development genannt. Das ist dann doch relativ ähnlich. Also man nimmt eben so Präzedenzfälle oder hübsche Beispiele. Specification by Example könnte man es nennen. Spezifiziert damit dann tatsächlich die neuen Herausforderungen oder Requirements. Hat dann damit eben so eine Messmöglichkeit oder gar ein Sicherheitsnetz, um um dann eben.
Entweder im ATDD Fall eben ein regelbasiertes System und im Machine Learning Fall dann eben so ein statistisches Modell weiterzuentwickeln und hinterher halt wirklich messbar zu haben, ob man es verbessert hat. Sehr spannend. Wie wie wie lang sind denn? So eure typischen Zyklen, in dem ihr da so so agiert? Ja, also wir haben zwar tatsächlich irgendwie so vorgefertigte zwei Wochen Sprints, aber es ist tatsächlich so, dass wir diese. Diesen. Durchlauf in dem.
CPM AI nicht direkt zur Deckung bringen mit diesen zwei Wochen. Teilweise haben wir tatsächlich also mehrere Iterationen innerhalb von so einem zwei Wochen Sprint. Also im Idealfall ist es vielleicht. In der Deckung. Aber wenn dann was dazwischen kommt, wir hatten auch schon mal ein Sprint, wo wir dann nicht irgendwie einen kompletten CPM AI Zyklus durchgelaufen haben. Aber häufig ist es so, dass wir es häufiger machen. Hängt natürlich auch ab von den Kunden.
Also wir kriegen gerade ziemlich die Bude eingerannt und wenn man dann eben irgendwie einen neuen Anwendungsball haben oder neuen Pilot Kunden, der eine jetzt, der es auf Französisch haben will. Dann haben wir das dann halt zwischen Reihen und machen es zuerst mal eben mit dem Modell, was wir haben. Das ist dieses Mistral Modell Mistral kommt ja aus Frankreich und haben das tatsächlich mit dem bisherigen Feintuning ohne französische Dialoge.
Ist es auch schon relativ gut, trifft aber auch manchmal aus Versehen ab und antwortet dann irgendwie in einem französischen Dialekt auf Deutsch. Ja, weil es halt auf deutschen Daten gefeindet ist. Wenn es dann gefeint tuned wurde, tendiert es halt mehr zum Deutschen, als es dann lieb wäre. Also es versteht Französisch hervorragend, aber antwortet dann halt ganz gerne auf Deutsch.
Und deswegen haben wir eben eine schnelle Zwischeniteration gemacht, praktisch einfach mit dem deutsch gefeint tunten Modell und erzeugen jetzt dann halt französische Trainingsdaten. Und eben auch Testdaten. Ja, du hast jetzt schon ein paar Mal dieses. CPM AI erwähnt. Das ist jetzt für viele wahrscheinlich so. Also für mich zumindest. Was unterscheidet das denn oder was nimmt sich das denn zusammen? Was ist denn so das Gruppkonzept davon? Gut, dass du nachhakt.
Also war bei mir tatsächlich auch so, dass ich das, bevor ich mich auf die Suche gemacht habe, nicht kannte. In den USA ist es wohl populärer, aber hier im europäischen Raum nicht so sehr. Was eigentlich schade ist, weil tatsächlich dieses Cognolitica auch bei dem. Die haben auch die. Patterns of AI entwickelt. Das heißt eine Kategorisierung von KI in sieben verschiedene Muster. Und es wurde auch von der EU unter anderem im AI Act aufgegriffen.
Also die sind da schon relativ bekannt in den Gremien, aber in der Praxis im EU Bereich tatsächlich noch nicht so sehr. Also ich habe, ich habe praktisch mich auf die Suche gemacht nach eben einem modernen Prozess, wo wir das Ganze dann so. Wieder einbetten können und es gibt den. Wie heißt denn nochmal Chris DM?
Prozess. Das ist Cross Industry Standard Prozess und DM steht für Data Mining und ist vom letzten Jahrtausend und diese CPI hat sich davon zwar groß inspirieren lassen, aber ist halt moderner und integriert eben noch Agilität und. Geht auch dann noch also dieser CPI Kurs geht auch noch da unter die Haube und bietet nicht nur den Prozess an, sondern dann halt auch für jede dieser. Text Stages. Wie eben Business Understanding, Data Understanding und so weiter.
Noch Details, wie man das dann eben in verschiedenen Menschen Learning Domänen oder oder eben diesen sieben verschiedenen Patterns einsetzen kann. Das heißt, ich hab ich hab mich da einfach auf die Suche gemacht, als ich. Diese. Diese CPI noch nicht kannte. Es gibt auch Weiterentwicklung von diesem Chris DM, die direkt auch irgendwie Chris Python Chris ML. Das dann sehr in Richtung Automotive ausgelegt ist und auch noch nicht Agil.
Und das einzige, was ich gefunden habe, was dann eben modern ist, Agil mit Data Centric Machine Learning verbindet, war diese CPI. Da gibt es auch einen freien Kurs, der dann eben nur auf dieser abstrakten Ebene diesen diesen reinen Prozess behandelt. Und dann eben so einen bezahlten Kurs inklusive Zertifizierung, wo dann eben auch diese Best Practices im Machine Learning Bereich dann mit angeboten werden. Und das ist ja spannend. Und ich hab jetzt eben diese sechs Stufen erwähnt.
Dann dann gehe ich die vielleicht nochmal durch. Das heißt, man fängt an mit eben Business Understanding. Dann geht man über zu Data Understanding und das iterativ ist, kann man natürlich immer hin und her springen, auch mal rückwärts gehen. Und tatsächlich. Haben wir in unserem Bereich dieses Business Understanding und Data Understanding vereint. Also das sind.
Ich sehe das für unseren Anwendungsfall tatsächlich nicht als zwei getrennte Stufen, sondern sondern eine, weil wir eben so Dialog zentrische immer auf den gleichen Daten arbeiten. Analysieren wir die für das Business Understanding auch. Insofern sind diese beiden Stufen bei uns eins. Die nächste Stufe ist dann Data Preparation, wo wir dann eben auch unsere Acceptance Tests schreiben. Und. Die den Training Set erstellen.
Und wenn man, wenn man dann die die Daten aufbereitet hat, geht man in das Training von dem Language Model Model. Das heißt nicht Model Training, sondern Model Development oder so diese Stufe. Die das ist dann also die vierte Stufe. Die fünfte Stufe ist dann eine Evaluation, wo man dann eben.
Die. Dieses Test Werkzeug, von dem ich gesprochen habe, führen wir dort aus und macht dann da eben auch diese klassischen Machine Learning Evaluation, dass man dann eben so Akku Rezi oder F1 Score oder welche Metrik man immer benutzt. Wir haben dann eben etwas Business orientiertere Metrik, wo man die dann errechnet. Naja. Und die letzte Stufe und die ist tatsächlich in diesen Zyklus neu integriert. Die ist bei CP die bei ist bei Chris DM noch nicht enthalten.
Ist das mal das Ganze dann wirklich deployed? Ja, das ist das. Also so eine Art Staging macht und entweder als Demo oder bei einem Pilotkunden oder direkt in Produktion einsetzt, um dann auch wirklich neue Daten, die direkt vom Business kommen. Business orientierte Daten neue sammelt, um dann eben die nächste Iteration und das nächste Business und Data Understanding zu füttern. Sehr spannend. Also da habt ihr ja auch den kompletten Prozess bedacht und erdacht anhand dieses Modells für euch.
Mhm. Das. Das finde ich. Schon. Also für mich total viel gelernt. Schon. Und das sind also im Prinzip in diesem Prozess kann man dann eben dieses ATT relativ gut ein einbetten und vergleichen mit eben diesem Machine Learning Prozess und dann eben unser acceptance Test. LLM Development recht gut einbettet. Ja, ja, ja. Also sehr sehr gut. Also das ist der Prozess zu diesem Prozess. Gibt eben auch einen kostenfreien Kurs und dann relativ nützlich.
Es gibt auch einen Podcast von diesem Prognolithiker. Relativ nützlich, denke ich, ist auch dann, wenn man unter die Haube schaut und in jeden dieser Stufen reinschaut, wie man da mit den Machine Learning Best Practices gut vorankommt. Ich habe da auch einen Affiliate Link, dass es 10% Rabatt gibt für die, die dieser Kurs interessiert. Kann ich dann vielleicht in die Show Notes mit rein? Ja, packen wir mit rein. Auf jeden Fall. Das Angebot nehmen wir gerne auf.
Ja. Ich möchte noch einmal so ein bisschen zu dieser zu dieser. Also viel acceptance Test driven gemacht. Wie wie sieht es denn mit anderen Tests auf anderen Stufen aus? Wie agiert ihr denn da? Ja, also letzten Endes so diese klassischen Stufen. Also Unit Tests wüsste ich jetzt gar nicht, wie man das dann auf dem Language Model anwenden kann. Natürlich haben wir auch noch Code drum herum. Um das Language Model.
Und da setzen wir klassisch die Testing in verschiedenen Stufen ein und haben natürlich auch Unit Tests. Aber jetzt, worüber ich primär erzählt habe, war dann eben dieses Neuland des LLM zu testen. Da haben wir tatsächlich neben diesen Acceptance Tests auch noch verschiedene andere Tests. Also wir haben dann auch noch macht ein Kollege von mir ganz, ganz toll so Stress Tests.
Bevor wir, bevor wir tatsächlich das Modell deployen, dass wir dann tatsächlich den Patienten auch automatisieren mit eben auch einem natürlich einer KI in einem Language Model. Und das wird dann eben unser neu gefallen tun des Language Model gegen dieses Patient Language Model laufen lassen. Und die Dialoge, die da entstehen, kann man natürlich auch auswerten. Dann dadurch, dass wir eben so Template basierte Acceptance Tests und auch.
Template basierte Trainings Datensatz haben, können wir so Metamorphic Testing relativ einfach machen, indem wir einfach dann irgendwie einen Dialog, der jetzt gerade relevant ist, hernehmen und die. Template Variablen, die drinstecken durch noch wesentlich mehr Werte ersetzen und dann da auch irgendwie kombinatorial Testing betreiben und dann eben zu einem Aspekt. Direkt ganz viele Messungen durchführen können.
Das wäre dann eben so eine Art Metamorphic Testing, was im KI Bereich ganz, ganz beliebt ist. Also wir machen dann natürlich noch mehr, aber letzten Endes der der das Haupt. Sicherheitsnetz, das wir haben, würde ich sagen, sind diese Acceptance Test Driven LLM Tests. Ja, super. Also wow. Ja, ich bin total geflasht. Ich bin fand das mega, mega spannenden Input mal, wie man so sich auch praktisch dem Ganzen nähert. Und ich meine, ihr seid ja da jetzt auch schon echt tief drinnen.
Das finde ich, finde ich ganz toll. Macht auch total Spaß. Ja, das glaube ich. Es ist ja auch dein Element, glaube ich. Geht auch voll auf. Ja, ja. Und was ich also ich finde eben diesen Prozess und wie man dann bei LLM Entwicklungen rangeht und die LLM. Es entwickeln sich weiter und es ist alles komplett Neuland und im Prinzip auch hier dieses Acceptance Test Driven Vorgehen bei LLM Entwicklung habe ich sonst noch nicht gesehen.
Also das haben wir praktisch da entwickelt und ist komplett Neuland. Für die Kunden ist alles komplett Neuland und die das. Die Kombination dann von diesem Prompt Engineering, dann LLM Development und dann dieses Agentik Behaviour. Was macht man jetzt tatsächlich? Was übernimmt das LLM? Und was ist dann eher irgendwie so ein Funktionsaufruf und wird dann irgendwie von einer Kalender Funktion oder Datenbank oder so extern abgehandelt? Das ist alles super spannend und Neuland.
Also da gibt es natürlich auch dann andere, die in dem Bereich forschen. Und das finde ich dann auch super. Ich lese mir dann auch diese Research Paper, die eben diesen Agenten Ansatz weiter voranbringen. Durch genau. Es ist alles super spannend und bewegt sich echt viel. Und da kann man heute echt viel machen, was von einem Jahr noch überhaupt nicht möglich war. Und ich glaube auch, das sind einfach jetzt eine ganz neue Welt, wo man jetzt tief eintauchen kann und die man auch nutzen sollte.
Und jeder sich damit auch beschäftigen soll. Weil das ist. Ich glaube, das wird auch nicht mehr so weggehen. Das geht nicht mehr weg. Und wenn wir das unseren Kunden zeigen, sind die auch total baff. Und da sind Ärzte dabei, die dann total Feuer und Flamme sind. Und am liebsten auch dann KI machen würden, statt ihren Ärzteberuf auswählen. Oder eine Kombination oder so. Also das hat extrem, extrem Reiz. Nicht nicht nur für mich, sondern scheinbar für extrem viele. Ist ja auch verständlich.
Auf jeden Fall. Ja, super. David, vielen lieben Dank, dass du wieder hier Rede und Antwort gestanden hast. Ich fand es sehr spannend, sehr inspirierend auch. Und ich kann mir vorstellen, dass wir vielleicht sogar eine dritte Folge machen. Gerne. Alle guten Dinge sind drei. Genau. Also vielen Dank dafür und ich wünsche dir alles Gute und toi toi toi für die weiteren Projekte. Vielen Dank werde ich haben und vielen Dank für die Einladung. Und ich freue mich dann aufs dritte Mal. Genau. Danke.
Danke. Ja, danke. Untertitelung des ZDF, 2020