Deep Dive 205 – AI Evals mit Martin Seeler

Wie hat dir die Folge gefallen?
Gut 👍
Schlecht 👎
(Keine Anmeldung erforderlich)

Ein Modell-Update bei OpenAI oder Anthropic ist schnell gemacht. Aber wie stellt ihr sicher, dass eure Anwendung danach noch genau das tut, was sie soll?

In dieser Folge, aufgenommen auf der DecompileD in Dresden, sprechen wir mit Martin Seeler, Senior Staff AI Engineer bei Blue Yonder, über die Welt der AI Evals und den Unterschied zwischen einem reinen „Vibe-Check“ und belastbarer Teststrategie für GenAI-Produkte.

Im Fokus stehen die drei Säulen der Evaluation: Code-based Evals, LLM-as-a-Judge und Human-in-the-loop. Außerdem geht es um Error Analysis, Failure Modes und wie ihr aus Logs durch Clustering eine eigene Fehler-Taxonomie entwickelt.

Wir besprechen, warum binäre Bewertungen (True/False) oft hilfreicher sind als Scores, wie ihr Kosten, Latenz und Qualität gegeneinander abwägt und wie Tools wie Langfuse, Phoenix, promptfoo oder Braintrust euch beim Monitoring und Testing unterstützen.

Wenn ihr wissen möchtet, wie ihr eure KI-Anwendung vom Prototypen in einen stabilen Enterprise-Betrieb überführt und Evals gezielt für Fine-Tuning oder Reinforcement Learning nutzt, ist dieser Deep Dive genau richtig für euch.

Vielen Dank an das Team der DecompileD für die Gastfreundschaft und an Vodafone für die Bereitstellung der Räumlichkeiten mit Blick auf die Trainingsfelder von Dynamo Dresden!

Schreibt uns!
Schickt uns eure Themenwünsche und euer Feedback: podcast@programmier.bar

Folgt uns!
Bleibt auf dem Laufenden über zukünftige Folgen und virtuelle Meetups und beteiligt euch an Community-Diskussionen.

Bluesky
Instagram
LinkedIn
Meetup
YouTube

Musik: Hanimo

Transcript

SPEAKER_05 0:08

Hallo und herzlich willkommen zu einer neuen Programmierbar folgerem Deep Dive, wo wir heute über AI Evils sprechen. Das in einem besonderen Setting. Wir sind nämlich nicht in unserem Studio zu Hause, sondern mit einer ganz schönen Aussicht. Und ich habe gehört auf die Trainingsflächen des sag schnell, wie der Dresdner Fußballclub heißt. Dresdner Fußballclub, DFC. Nee, die haben auch so einen Spitznamen. Unser Gast darf noch nicht reden. Oh, der weiß es auch nicht. Okay. Du googelst jetzt parallel. Anyway, wir gucken hier auf dieses Ding, weil wir sind auf der Decompiled, einer coolen Konferenz in Dresden, wo ich letztes Jahr auch schon war und wo ich heute dieses Mal begleitet wurde. Dynamo Dresden. Kennt man doch.

SPEAKER_04 0:53

Dynamo Dresden.

SPEAKER_05 0:54

Ach, Dynamo sieht man doch, da leuchtet doch irgendwas. Wir sitzen hier im Gebäude von Vodafone. Vielen Dank an Vodafone, dass wir diese Räumlichkeiten nutzen dürfen. Ich bin Dennis Becker, neben mir sitzt. Aka Dave Kuschitzki, moin. Genau. Und wir haben heute einen Gast eingeladen, der ist Senior Staff AI Engineer und bei Blue Yonder. Und das ist Martin Seeler. Herzlich willkommen, Martin. Vielen Dank für die Einladung. Schön, dass du da bist. Da ist ja auch schon AI in deinem Titel, den du trägst. Das heißt, es hört sich so an, als würdest du dich schon ein bisschen tiefer damit auseinandersetzen und jetzt nicht gerade erst an den Oberflächen kratzen, was das Ganze angeht. Aber erzähl uns gerne ein bisschen was über dich erstmal. Wer bist du? Wo kommst du her? Was hast du so die letzten Jahre gemacht?

SPEAKER_03 1:46

Ja, also ich bin schon seit über 15 Jahren Softwareentwickler in allen möglichen Bereichen. Und jetzt seit etwas über einem Jahr bin ich bei einer Firma namens Blue Yonder. Die kannte ich übrigens auch vorher nicht, also falls es dir genauso geht. Die machen Supply Chain Management, alles was drumherum gehört, Warehouse Management, Transportation Management und von End-to-End wirklich alles mit dabei. Und meine Rolle ist Senior Staff Engineer, genau, im Bereich AI. Das heißt, ich bin in einem Team, das nennt sich AI Studio. Wir sind so das AI Frontier Lab bei Blue Yonder. Und tatsächlich sind unsere Hauptaufgaben Post-Training von Models. Wir bauen Agents, wir machen Supervised Fine-Tuning, Reinforcement Learning, wir bauen die ganze Infrastruktur. Also wir arbeiten wirklich an den neuesten Agents, die in den nächsten Jahren dann die Autonomous Supply Chain bedienen sollen. Also ich würde schon sagen, cooles Zeug, womit man sich auseinandersetzt. Macht auf jeden Fall eine Menge Spaß. Cool.

SPEAKER_05 2:56

Zwei Fragen. AI Studio, wart ihr vor Google oder danach und habt ihr es benannt?

SPEAKER_03 3:01

Ja, kann ich dir nicht genau beantworten. Stand auf einmal so bei uns auf dem Team auf einmal drauf. Okay.

SPEAKER_05 3:08

Und Supply Chain, denkt man ja irgendwie im Tech-Bereich erstmal an wahrscheinlich was anderes. Also, das irgendwie bedeutet irgendwie das Gleiche, aber es ist ja dann irgendwie Software und wird irgendwie reingepflanzt. Aber bei euch geht es um Hardware, also das heißt Transport von echten Waren, von echten Mitteln, also Sachen, die tatsächlich auf der Welt passieren und nicht nur in einzelnen Nullen ausgedrückt werden.

SPEAKER_03 3:31

Richtig, also bei uns geht es darum, wenn mal wieder ein Tanker im SUAS-Kanal stecken bleibt, wie können wir die ganzen Güter von A nach B durchrouten, wie hilft dir Software dabei bis hin zum Return Management, wenn der Kunde wieder Waren zurückgeben will, genau.

SPEAKER_05 3:48

Wie definierst du AI Evils?

SPEAKER_03 3:54

Sehr breiter Begriff. Also das umfasst erstmal alles. Der Name selber, ist ja nur die Kurzform von Evaluations, was erstmal alles mit dem Thema Absichern bedeuten kann. Es geht eben darum, sicherzustellen, dass du deine Core Value Chain sicherst, dass du beweisen kannst, dass alles so funktioniert, wie du dir das vorstellst. Auf welche Art und Weise das passiert, das ist abhängig vom Kontext, was du gerade machen willst.

SPEAKER_05 4:34

Und jetzt haben wir heute also AI ja davor stehen und ich antizipiere irgendwie eine der großen Schwierigkeiten ist vermutlich, dass es nicht mehr so deterministisch ist, wie vorhin.

SPEAKER_03 4:48

Richtig. Also im klassischen Software-Development-Prozess hast du den Vorteil, dass du einen Test schreiben kannst, 2 plus 2 ist 4. Sobald Probabilistic Output in deiner Anwendung vorkommt, du also, sagen wir mal, ein Stochastic-System hast wie ein Large Language Modell, sehen die Dinge auf einmal etwas komplizierter aus. Du hast den Input, 2 plus 2, aber jetzt hast du den Fall, das LLM antwortet dir mit 4 oder das könnte eine 5 halluzinieren oder es schreibt dir ein Gedicht über die Nummer 4. Das heißt, du hast auf einmal viel mehr Testfälle, die du abdecken musst und das macht es komplizierter.

SPEAKER_05 5:35

Also mein Gefühl ist, wenn man sich damit beschäftigt und das, was ihr wahrscheinlich auch irgendwie schon implementiert, dann hat man sich ja auch schon ein bisschen damit beschäftigt und versucht irgendwie das Ganze unter einen Hut zu bringen. Was hast du für einen Eindruck, wie das aktuell da draußen gehandelt wird, diese Problematik? Also es ist ja in der Regel, sprechen wir jetzt erstmal davon, okay, AI wird in irgendwelchen Produkten eingesetzt. Es ist jetzt nicht nur AI in unserem Entwicklungsprozess irgendwie mit drin, wo wir es ja selbst in einer gewissen Art evaluieren oder Code-Reviews machen oder keine Ahnung was, sondern wir haben auf einmal ein Stück Software, das wir auch ausliefern und das auch Endkunden irgendwie nutzen. Und da ist jetzt ein Part drin, der nicht so steuerbar ist. Und vermutlich ja auch irgendwie halt auch dieses Update-Zeug ein Riesenthema ist, oder? Also ich meine, das, keine Ahnung, es entwickelt sich irgendwie so schnell weiter, dass wir alle X Wochen irgendwie neue Modelle haben. Und das ist auch ein Part davon, dass man irgendwie da vorbereitet ist und das irgendwie abbilden kann.

SPEAKER_03 6:37

Genau, also wenn wir jetzt von E-Wice sprechen und von dem Testen von solchen Gen AI-Produkten, dann geht es immer darum, Wege zu finden, um zum einen die richtigen Tests zu schreiben. Also was genau sind denn die richtigen Tests, das ist nämlich gar nicht so leicht zu beantworten. Und mit Hilfe von diesen Tests dann auch Ableitungen zu machen, zum Beispiel über die Qualität deiner Software, dem Ganzen eine Metrik zu vergeben auf Basis von deinen Tests. Und dann ähnlich wie du gesagt hast, es entwickelt sich alles rasend schnell weiter. Und immer wieder kommt ein neues Model raus. Du brauchst eine Art Test, der dir sagt, okay, es ist gut genug, wir können dieses neue Modell mit unserem Produkt ausliefern, das möglichst schnell, weil Kunden sind dann auch hyped, die wollen dann auch das neue Model sehen und in deinem Produkt mitverwenden. Und das gilt nicht nur für deine Kunden, sondern es gilt auch für deine eigenen Entwickler. Die sind genauso hyped, die lesen, oh, hier gibt es neue Technologien, das will ich ausprobieren, hier gibt es neues Framework, das will ich ausprobieren. Also im besten Fall helfen dir diese Evice dann auch noch den richtigen Weg einzuschlagen, auf was solltest du dich denn aktuell auch konzentrieren? Also das sind alles Themen, wenn man E-Wice richtig umsetzt und da gibt es sehr einfache Prozesse, auf die wir wahrscheinlich dann gleich noch eingehen. Wenn man das richtig umsetzt, dann helfen dir diese Prozesse dabei, all diese Fragen mit einem Schlag zu beantworten. Wohingegen du auf der anderen Seite häufig diesen sogenannten Vibe-Check machst, kommt ein neues Model raus, du änderst vielleicht dein Model mal auf die neue Version, du lässt deine Anwendung laufen und schaust einfach nur, ja, fühlt sich gut an und wir releasen das und dann verschreckst du aber den Kunden und das kostet dich im Endeffekt viel mehr Geld.

SPEAKER_05 8:42

Und ist dann zwangsweise aber damit auch verbunden, dass wir für diesen Schritt dann auch einnutzen oder ist es da irgendwie besser, wenn man da wieder auf deterministische Systeme irgendwie zurückfällt? Oder geht das vielleicht gar nicht? Das geht sehr wohl.

SPEAKER_03 8:58

Schlaue Frage. Es gibt drei Wege, wie man das Ganze testet. Oder man kann das in drei Kategorien unterteilen. Du kannst Code-Based Evaluations machen, du kannst Model-Based Evaluations machen, das, was du angesprochen hast, mit du lässt ein Large Language Model zum Beispiel dir dabei helfen bei der Evaluierung. Und der letzte Schritt, der wird häufig ganz außen vor gelassen, ist Human-Based Evaluations. Du setzt einfach einen Subject-Matter-Expert an dein Output, an deine Anwendung, der das Ganze validiert. Alle Varianten haben ihre Vor- und Nachteile. Also du kannst, sagen wir mal, du hast einen Report und du willst die Qualität testen, dann kannst du mit Code-Based Evaluations sehr leicht einfache Dinge testen, zum Beispiel die Länge deines Reports. Wenn du sicherstellen willst, dass dein Report nicht länger als 500 Zeichen ist, kannst du das ganz einfach testen. Das kannst du mit Code testen. Das lässt sich verifizieren. Willst du, dass deine Zahlen, die du verwendest in deinem Report, immer mit Metriken versehen sind, kannst du das mit einer Regex testen. Das kannst du auch über Code lösen. Wenn du allerdings auf Sachen eingehst, die subjektiv sind, kannst du das nicht mehr über Verifiables abbilden, nicht mehr über Code. Also kannst du entweder über Model-based Evaluations gehen oder über Human-Based Evaluations. Und dann kannst du dort diese Tests durchführen.

SPEAKER_05 10:41

Ist das irgendwie so ein Ding, ich habe es irgendwie gefühlt hier und da gelesen, oder ich weiß nicht, ob das nur für das Code-Review gilt, aber vielleicht gilt das ja vielleicht ähnlich. Nimmt man dann die gleichen Modelle oder ist es irgendwie besonders gut, andere zu nehmen, weil die dann nicht den, weiß ich nicht, gleichen Bias haben oder ist es am Ende eigentlich egal, weil es ein sehr anderer Schritt ist, der passiert?

SPEAKER_03 11:02

Eher letzteres. Also wenn du dir die Aufgabe deiner Anwendung anschaust, die, nehmen wir jetzt als Beispiel ein LLM. Das bekommt irgendeine Aufgabe basierend auf diesem User-Input, bestimmte Schritte zu absolvieren und dann ein Output zu generieren. Das ist im Vergleich zu einem Test ein ganz anderer Task, der dort absolviert werden muss und ist in der Regel kein Problem, wenn du das gleiche Model für deine E-Vice verwendest als für deine normale Anwendung. Es gibt den Fall, der betrifft selten, aber kann vorkommen, Modelle, dass wenn ein Model sich selber judget, dass es das erkennt, dass der Output von dem eigenen Model kommt und einen gewissen Bias aufweist. Das ist aber auch sehr schwer rauszufinden und tritt sehr selten auf. Also ist nichts, was man von Anfang an jetzt mit berücksichtigen muss. Ein guter Ansatz ist immer, fang mit dem mächtigsten Model an, was dir zur Verfügung steht. Und du kannst später immer noch für Kosten optimieren und andere Modelle ausprobieren. Wichtig ist, dass das Model beim Evaluieren dem Human Judgment sehr nahe kommt. Und da sind wir schon in dem Bereich, auch in dem Bereich, in dem Prozess, den wir dann gleich vielleicht genauer beschreiben, wie kann ich denn sicherstellen, dass so ein Model da tatsächlich dem Human Judgment übereinstimmt? Wir hatten. Hast du eingeatmet?

SPEAKER_04 12:51

Ich habe eingeatmet. Okay, vielleicht mal. Sorry, das ist einmal. Vielleicht nochmal hier an der Stelle so ein bisschen zur Abgrenzung, was das Wort Evaluation oder Evals angeht. Und zwar, es gibt ja durchaus einfach diese AI-Benchmarks, also quasi, wie capable is eine AI, gewisse Dinge zu tun. Da geht es ja bei Evals nicht explizit drum, richtig? Sondern das hat nochmal eine zusätzliche Abgrenzung. Also inwiefern würdest du, also ich kann mir einfach anschauen, so oh, das Modell performt so und so, das ist so und so gut in diesen Coding-Task, das ist gut als LLM so. Da gibt es ja verschiedene Benchmarks, wonach man sich richtig hergestellt. Aber wie würdest du da die Evals dann nochmal differenzieren?

SPEAKER_03 13:32

Also Benchmarks sind ein Teil von Eweils. Denn was Benchmarks betrifft, du hast eine Reproduzierbarkeit. Du testest immer wieder auf dem gleichen Input oder du hast immer wieder die gleichen Aufgaben, die einfach von unterschiedlichen Modellen absolviert werden. Das ist ein Teil, eine Subkategorie von diesem Oberbegriff Eweils. Wenn wir jetzt von Evice reden, reden wir ja häufig von LLM as a Judge, einer sehr konkreten Form von Evice, wenn wir Large Language Modelle testen. Das ist die Form, wo du ein anderes Modell zum Testen verwendest. Also ich zeige einem Large Language Model, mein Output, schau dir doch mal meinen Report an und sag mir, ob hier ein gewisser Fehler vorliegt. Oder sag mir, ob ich auch schön in Gedichtform geantwortet habe. Beispielsweise. Das ist nämlich sehr schwer als Test einfach abzubilden. Das ist quasi unmöglich. Also nehme ich mir einfach ein anderes Modell her und gebe ihm diese Aufgabe. Das sind diese, deswegen nennt man das LLM as a Judge. Du lässt ein anderes Large Language Modell über dein Output judgen bewerten. Und wenn wir uns jetzt uns das so vorstellen, dass wir auch da ein Dataset haben und immer wieder die gleichen Inputs gegen unterschiedliche Modelle testen, dann könnte das unser ganz persönlicher Benchmark sein. Wir können aber auch dieses LLM as a Judge so aufsetzen, dass wir Online-Monitoring betreiben. Also jedes Mal, wenn ein User mit unserer Anwendung interagiert, wird dieser Judge ausgelöst und evaluiert diesen neuen Output. Jetzt habe ich kein vordefiniertes Dataset, was immer gleich bleibt, sondern stattdessen ein Judge, der jeden meiner Outputs gradet. Genau, aber Evails sind deswegen dieser Oberbegriff, nehme ich immer wieder den gleichen Input und teste das auf verschiedene Modelle, lasse ich immer wieder die gleichen Tests durchlaufen, dann komme ich zu dieser Reproduzierbarkeit und lande bei Benchmarks.

SPEAKER_05 15:53

Wir haben letztens wahrscheinlich ein bisschen blauäugig, aber irgendwie in die gleiche Richtung. Also wir haben bei uns so eine AI-Week gehabt, wo das ganze Unternehmen einfach Zeit hatte, sich damit zu beschäftigen und dann sind wir auch viel so ein bisschen in die anderen Teams und Bereiche, die nicht nur Dev-Entwicklungsteams waren, gekommen. Und da habe ich mit HR zusammen so einen, sagen wir mal, Prototypen zusammen gehackt mit Cloud Code, wo es darum ging, dass wir für potenzielle KandidatInnen, die wir im Active Sourcing uns angucken, da erstmal eine grundsätzliche Zusammenfassung und Bewertung davon haben müssen und um dann sie personalisiert anschreiben zu können, danach auf welchen Plattformen auch immer. Und das ist, glaube ich, dann so ein bisschen impliziert passiert, was da eigentlich, also was ein bisschen ein Teil davon ist, weil es gab dann so eine AI, die die Recherche gemacht hat und das Ganze irgendwie gesagt hat, hey, das sind die Sourcen. Und dann haben wir gesagt, naja, irgendwie stell mal sicher, dass die auch relevant sind und dass es da wirklich um die Person geht. Und da kam dann AI halt auch einfach und hat gesagt, ja, okay, ich mache jetzt hier so einen Score hin und hat irgendwie schöne Graphen gemalt und gesagt, wie sicher es ist jetzt da, dass es sich um die Person handelt und dass es irgendwie relevanter Inhalt ist dafür. Was irgendwie schon ein Teil dann ist, oder? Da wo dann ein LLM irgendwie sagt hat, ja, was, wie sicher bin ich mir denn? Und da war ich mir total unsicher, ist das, also kann man dem jetzt irgendwie trauen oder ist es auch irgendwie super random, was jetzt da rauskommt und die sagt, ja, ich bin mir mal zu 55 Prozent sicher, dass das richtig ist.

SPEAKER_03 17:28

Ja, es ist sehr schwer. Das kommt davon, kommt darauf an, ob man das als Teil seiner Value Chain mit betrachtet, diese Bewertung von diesem anderen Modell, oder ob man als Teil seines Testings betrachtet. Also wenn du das jetzt als Teil der Core-Einwendung mitziehst, würde ich eher sagen, es handelt sich um ein Multi-Agent-System, wo du mehrere Large Language Models zusammen verwendest, die unterschiedliche Aufgaben machen und die Sache zusammenbringen. Wenn du jetzt aber sagst, okay, das ist nur für uns zum Validieren, dann würde ich schon durchaus sagen, das geht schon in die Richtung Testing. Aber das ist ja das Schwierige, die Frage, was sind denn die richtigen Tests? Das ist sehr schwierig und ja, da scheitern die meisten ran. Denn es gibt sehr viele vordefinierte Evals. Ready-Made, die kann man einfach so installieren. Du hast dann ganz tolle Dashboards und Metriken, die dir dann angezeigt werden. Da steht dann eine Zahl drin, Helpfulness oder Trustworthy und irgendeinen Wert zwischen 1 und 5. So, wenn ich jetzt eine Anwendung schreibe oder ein Produkt entwickle und meinem Boss sage, also wir haben hier ein Produkt und das hat einen Helpfulness-Score von 4,2. Dann guckt er mich mit runzelnder Stirn an und denkt wahrscheinlich, dass ich verrückt bin. Was soll der ihm das jetzt sagen? Also ist das jetzt gut genug? Können wir das jetzt auf 10.000 Kunden losgehen lassen? Ja oder nein? Das sagt dem gar nichts.

SPEAKER_04 19:12

Oder warum ist es nicht fünf? Das wäre eigentlich meine Frage. Alles sollte doch top sein.

SPEAKER_03 19:16

Genau. Ja, also das ist die schwierige Frage und darum ging es ja auch heute hier auf der Konferenz so ein bisschen in dem Talk. Wie schreibt man denn eigentlich richtig gute Eweils? Wie kommt man an den Punkt, dass man das versteht? Und wie nutzt man dann diese Eweils, um die eben in Metriken umzuwandeln?

SPEAKER_05 19:36

Und wie macht man es?

SPEAKER_03 19:37

Ja, guter Übergang. Sehr gute Frage. Es ist eigentlich relativ leicht. Es ist so leicht, dass es schon absurd ist, dass es nicht einfach jeder so macht. Spannend, okay.

SPEAKER_04 19:52

Ich bin wirklich auf die Antwort gespannt.

SPEAKER_03 19:54

Ja, also es ist tatsächlich so, es ist nicht mal was Neues, was sich jetzt jemand ausgedacht hat. Es ist etwas, das schon seit zig Jahren existiert. Ein Begriff, der auch so trivial klingt, nennt sich Error Analysis. Und der besteht aus ganz wenigen Schritten. Schritt Nummer eins, du sammelst dir Daten aus deiner Anwendung. Du richtest irgendeine Art von Monitoring ein, um erstmal die ganzen Daten zu sammeln. Jede Interaktion von deinem Customer mit deinem Produkt. Und Schritt Nummer zwei ist, du schaust dir deine Daten tatsächlich einfach mal an. Also ganz, ganz trivial.

SPEAKER_04 20:35

Wer hätte das gedacht? Bisher wirklich einfach.

SPEAKER_03 20:38

Ja, du schaust dir deine Daten einfach mal an. Und zwar in dem ersten Schritt nimmst du die Rolle eines Customers ein. Du bist im besten Fall jemand, wenn du die Kommentare dran schreibst, der diese Produktidee hat, der bewerten kann, was genau heißt denn gut aus Customer-Sicht. Und du nimmst seine Rolle ein und schaust dir dein Output einfach mal an. Und ich kann ja mal ein Beispiel bringen, bei uns, bei Blyander. Wir haben natürlich viele Projekte. Eins ist auch so ein Report für Warehouse Manager, wo wir alle möglichen Inefficiencies und Probleme aufdecken. Und unser Report enthielt dann Daten, zum Beispiel zu Verspätungen bei Shipments, Late Shipments. Der erste Satz war gleich, wir haben 100% Late Shipments und das basiert auf null Late Shipments. Also wir haben keine Late Shipments, es gibt keine, aber wir reporten irgendwie 100%. Das macht natürlich keinen Sinn. Also hinterlässt man einfach nur den Kommentar, dass es hier eine Diskrepanz gibt. Ganz, ganz trivial. Einfach nur runterschreiben, mehr nichts. In dem gleichen Report haben wir auch noch davon gesprochen, von Severe Inefficiencies. Aber wir hatten ja gar keine Late Chipmen. Also, das ist totale Übertreibung. Dann mache ich mir genauso einen Kommentar. Hier wurde übertrieben und ohne eine konkrete Zahl, das ist ja auch noch mit dabei, was bedeutet denn Severe in dem Kontext, auf ein Missstand hingewiesen. Noch viel schlimmer, wir haben dann Labor Productivity bewertet, wie gibt es Probleme mit den Leuten, die im Warehouse arbeiten? Und dann standen da so Sachen drin wie 25% of your users, uh workers are low performers. Low performers, das ist halt kritisch. Also wenn ich ein Produkt rausgebe an Tausende von Kunden mit jeweils 10.000 Warehouse-Mitarbeitern und ich nenne die Low Performer, dann habe ich wahrscheinlich am nächsten Tag von HR einen Brief in meinem Postfach, dass die mich zum Gespräch einladen. Also hinterlasse ich auch da einen Kommentar, dass wir hier HR-sensitive Sprache in unseren Reports verwenden. Ich schreibe also alle diese Kommentare runter. Ich gehe durch und am besten annotiere ich nur diesen ersten Upstream-Fehler. Denn alle Sachen, die ich danach entdecke, haben wahrscheinlich mit dem Anfang, dem Problem zu tun, ab wo der erste Drift abgegangen ist. Und das reicht aus tatsächlich. Man könnte jetzt meinen, da muss ich ja Tausende solcher Traces angucken. Aber nein.

SPEAKER_04 23:31

Das war mein erster Gedanke, ja.

SPEAKER_03 23:33

Tatsächlich musst du das nicht. Du kannst sehr, sehr leicht anfangen, mit ganz wenigen, beispielsweise 20 Traces. Du gehst einfach dadurch, das dauert vielleicht zwei Stunden, drei Stunden und du hast mindestens 100 Kommentare gesammelt. Und zwar Kommentare, die perfekt auf dein Produkt zugeschnitten sind, die Fehler in deiner Anwendung aufzeigen. Denn es ist sehr leicht für jemanden im Product Management, sich zu überlegen, was möchte ich denn an Output sehen? Aber auf der anderen Seite ist es sehr schwer, im Vornherein darüber nachzudenken, was soll es denn nicht sagen, was möchte ich denn nicht sehen. Und das sehe ich natürlich nur, wenn ich mir die Daten tatsächlich angucke. Also wir haben dann insgesamt über 87 Reports angeguckt, sind da durchgegangen und hatten etwas über 160 Kommentare zusammengesammelt. Dann haben wir aufgehört. Warum haben wir aufgehört? Wir haben einen Punkt erreicht, den nennt man Theoretical Saturation, theoretische Sättigung. Das ist der Punkt, an dem du feststellst, hm, ich schreibe zwar Kommentare, aber das habe ich alles schon mal hingeschrieben. Irgendwie finde ich gerade nichts Neues. Hier ist eigentlich Schluss. Du kannst hier aufhören. Ab hier kostet dich der Prozess einfach nur noch Geld und du hast sowieso schon sehr viel gefunden. Okay, also das waren die zwei Schritte. Wir müssen erstmal sicherstellen, dass wir die Traces sammeln, diese Loks von unserer Anwendung. Und dann gehen wir da durch und kommentieren das. So, Schritt 3 ist, du gruppierst diese ganzen Fehler. Und du sammelst alle. Dafür kannst du dann tatsächlich wieder ein LLM nehmen. Du könntest alle Kommentare nehmen, die in Chat-GPT reinschmeißen und sagen, bitte stell mir mal ein paar Gruppen. Oder du gehst technischer ran und machst das auf Basis von Keywords oder Embeddings, um die zu clustern. Kannst du machen, wie du das für richtig empfindest. Und in unserem Fall gibt es mehrere HR-sensitive Kommentare und wir haben das zusammengefasst zu einer Gruppe Judgmental Language, die umschreibt dieses Problem sehr gut. Und das ist auf einmal ein sehr guter Evaluator für unsere Anwendung im Vergleich zu Helpfulness. Hundertprozentig. Wenn ich das meinem Boss zeige und dem sage, unser Judgmental Language Score ist dies und das, ist das viel, viel hilfreicher. Diese 168 Kommentare, die wir hatten, haben wir auf 19 Kategorien runtergebrochen. Also 19 sogenannte Failure Modes sind dabei rausgekommen. Das sind die Zustände deiner Anwendungen, die du eigentlich nicht sehen möchtest. Also ja, du kommst am Ende auf Tests, die genau das testen, was deine Anwendung nicht mehr machen soll. Und das kannst du auch immer wieder machen. Es ist ausreichend, dass du damit einmal anfängst und das alles aufsetzt. Aber es wird der Punkt kommen, dass deine Nutzer anders mit deiner Anwendung interagieren. Und bestes Beispiel ist ChatGPT. Wenn du mal daran denkst, als ChatGPT rauskam, was hat jeder gemacht, der hat sich irgendwelche lustigen Gedichte erzeugen lassen. Schreib mir mal ein Gedicht über Softwareentwicklung oder was weiß ich. Heutzutage macht das niemand mehr, das ist langweilig geworden. Aber am Anfang haben die Nutzer so mit ChatGPT interagiert. Und das nennt man User Drift. Die Nutzer verändern, wie sie mit deiner Anwendung interagieren. Wenn du das feststellst, dann kannst du diesen Prozess wiederholen. Aber erstmal, das ist tatsächlich eine One-Time-Arbeit und du bist sehr gut abgesichert erstmal. Also unsere 19 Failure-Modes, die bleiben ja echt. Die bleiben ja auch relevant. In zwei Monaten sage ich ja nicht auf einmal, Judgmental Language ist nicht mehr relevant für unsere Anwendung. Das heißt, das kann ich kosteneffizient einfach so umsetzen. Und was du dann machst, ist, du bildest das als Test ab, der die ganze Zeit dann deine Outputs gradet. Also da sind wir wieder bei diesem LLM as a Judge. Da gibt es ja alle mögliche Software. Wir benutzen zum Beispiel Langviews. Und dann schreibst du da eine Prompt. Und in diese Prompt schreibst du rein, hier, das ist ein Report, und bitte teste, ob sich hier drin Judgmental Language befindet, ja oder nein. Und in diese Anfrage kannst du diesem anderen Large Language Modell auch Beispiele reingeben, nämlich die Beispiele, die du in deinen Kommentaren gefunden hast. Das ist also ideal. Wir können also sagen, wenn wir hier von Low-Performern reden, ist das schlecht. Können wir dem direkt so als Beispiel geben. Und dann schmeißen wir dort den Report rein. Und was rauskommt, ist ein ja, was kommt eigentlich raus? Das ist schon das nächste Thema. Häufig wird ein Wert zwischen 1 und 5 erwartet. Wie bei diesen Helpfulness. 1 bis 5. Wenn ich dich jetzt fragen würde, ist das Judgmental Language 3,7 oder 8,5? Ich habe keine Ahnung. Dann würdest du dir wahrscheinlich auch die Frage stellen, ja, wo ist denn der Unterschied? So. Und das zeigt schon das Problem mit solchen sogenannten Leikert-Skalen. Die sind in der Theorie ganz nett, weil du dieses Gefühl hast, dass du eine Metrik hast, die sich verbessert, aber die sagt dir eigentlich nichts.

SPEAKER_04 29:49

Wobei, ich würde sagen, komparativ schon. Also wenn ich weiß, so vorher wurde es auf 8 geschätzt und jetzt habe ich ein paar Änderungen gemacht, also auf 4, dann würde ich sagen, okay, also ich kann nicht, ich kann mit dem Wert per se nichts anfangen, aber ich weiß nicht, es scheint irgendwie weniger judgmental zu sein, was vielleicht gut ist.

SPEAKER_03 30:03

Das stimmt. Auf der anderen Seite, wenn du einen Wert zwischen, sagen wir mal, 0 und 5 hast, dann passiert was Spannendes. Sagen wir mal, wir haben 100 Outputs oder 100 Reports und wir lassen ein LLM as a Judge unsere 100 Reports graden nach Judgmental Language. Null bedeutet absolut kein Judgmental Language enthalten. 5 ist, wir beschimpfen unsere Worker hier von vorne wissen. Und wenn du jetzt über die 100 Reports einen Durchschnittswert von 0 hättest, veränderst du das, okay? Null, also keiner unserer Reports hat Judgmental Language. Wenn du jetzt mein Boss wärst und ich frage dich, können wir das Produkt so rauslassen, würdest du sagen.

SPEAKER_04 30:51

Also es ist schon als Fangfrage formuliert. Ich merke schon, ich laufe eine Falle. Aber ich würde erstmal sagen, weil ich gehe drauf ein. Ja, klar, null. Wir wollen ja gar keine Judgmental Language haben. Perfekt, perfekt.

SPEAKER_03 31:00

Können wir releasen. Können wir releasen. Was ist es denn, wenn unser Durchschnittswert 1 ist?

SPEAKER_04 31:04

Risikoabwägung. Da würde ich auch noch sagen, das können die Leute ab. Okay, und bei 2? Ich glaube, ich würde bei 5 sogar ja sagen. Ich will ein schlechtes Beispiel dafür, glaube ich. Aber stimmt, aber genau, irgendwann würde man sich, glaube ich, selbst aber einen Wert zu schreiben, so was ist noch hinnehmbar. Genau.

SPEAKER_03 31:18

Also du läufst in die Falle, dass du aus diesem Problem von bewerte, das mal zwischen 1 bis 5 oder 0 bis 5, du machst sowieso wieder ein binäres Problem da draus. Denn du musst an irgendeinem Punkt sagen, hier ist der Cut-Off. An diesem Wert fühlen wir uns nicht mehr gut, das zu releasen.

SPEAKER_04 31:34

Ja, was ich auch erstmal sagen würde, was ich okay finde. Also wir arbeiten ja auch schon seit Jahren mit irgendwie statistischen Modellen und sagen so, hey, das ist signifikant, so mit einer Wahrscheinlichkeit von 95%. Also unschärfe P gleich 0,05, so, macht man ja häufiger so. Und dann denke ich mir so, es ist wahrscheinlich dann in Ordnung. Und wenn man das dann da festlegt, fände ich es, glaube ich, auch erstmal irgendwie okay.

SPEAKER_03 31:55

Aber jetzt nehmen wir mal unsere neunsten Failure-Modes und für jeden Failure-Mode müssten wir jetzt definieren, oh, bei Judgmental Language ist 3,82 dann der Schwellenpunkt, an dem wir sagen, oh, hier geht es nicht weiter. Wenn wir aber sowieso wissen, wir machen ein binäres Problem da draus. Und es fällt uns ja persönlich auch schwer zu bewerten, enthält dieser Report Judgmental Language jetzt einen Wert von 3,8, 4,2. Menschen tendieren dazu, sich irgendwo in einer sicheren Mitte anzusiedeln. Die wollen nie konkret werden. Das gleiche passiert bei Large Language Modellen auch. Und in dem Moment, wo du ein binäres Problem da draus machst, wird die Aufgabe leichter. Das heißt, du fragst das LM jetzt nicht mehr für einen Wert zwischen 0 und 5, sondern gib mir 1 oder True zurück, wenn Judgmental Language enthalten ist und 0, wenn es nicht enthalten ist. Einfache binäre Entscheidung. Das macht die Sache leichter. Und dann kannst du auf 100 Reports gesehen eine Metrik berechnen, nämlich die Success Rate. Oder andersrum ist es ja eher die Failure Rate, wie viel Prozent meiner Reports enthält in Judgmental Language. Und das bringt uns auch schon zu dem Schritt, warum das Ganze so nützlich ist. Denn wir hatten ja gesagt, es ist schwer erstmal rauszufinden, was sind denn gute EVs sind. Das haben wir rausgefunden, indem wir uns tatsächlich unsere Outputs angeguckt haben. Das heißt, wir haben jetzt 19 sehr hochspezifische EVs für unser Produkt rauskristallisiert. Und dadurch, dass wir jetzt auch diesen Mechanismus haben, der die immer wieder bewertet, können wir uns ein Datenset nehmen und unsere 19 Kategorien. Und was weiß ich, wir nehmen uns 100 Reports und schauen einfach mal, welcher Fehler tritt denn am häufigsten auf. Du kannst dann also ein schönes Chart dir generieren lassen auf 100 Reports, welcher Fehler kommt denn am häufigsten vor und wie oft. Das gibt dir eine schöne Sichtbarkeit. Es macht die Fehler sichtbar und hilft dir, ein Gefühl dafür zu bekommen, welche Fehler wie oft vorkommen. Und dir als Manager, falls du dann derjenige bist, der entscheiden muss, woran arbeiten wir denn jetzt oder woran arbeiten wir denn als nächstes, hilft das, um die Sachen zu priorisieren. Wir könnten Judgmental Language jetzt einen Wert zuweisen, indem wir sagen, was hat das für einen Impact für uns, für den Customer, was bedeutet das kostentechnisch für uns? Es kann Fehler geben, die sind sehr selten, aber die sind so schlimm, wenn das passiert, dann verlassen uns die Kunden. Das sind also Entscheidungen, die du jetzt auf einmal datengestützt treffen kannst. Weil du siehst, oh, auf 1000 Reports gesehen ist dieser Fehler ja nur zweimal aufgetreten. Aber wenn der passiert, dann rollen hier Köpfe. Andere Sachen sind vielleicht sogar in 80% der Fälle, sagen wir mal, die Metrik fehlt, da würde dir aber vielleicht jetzt keinen Customer unbedingt abspringen. Also kannst du abwägen, da gibt es immer diesen Vergleich mit dem Spülbecken. Wenn du jetzt abwaschen musst, nimmst du den großen Topf zuerst, um erstmal Platz zu machen. Oder fängst du einfach von oben an und gehst so diesen Convenient-Weg dadurch. Genau, und das bringt dir ja auch gleichzeitig dann diese Metrik. Und jetzt kommst du in dieses schöne Data Fly Wheel rein. Das ist dieser Prozess, dass du jetzt immer wieder iterieren kannst. Wir können jetzt unsere Anwendung testen. Wir haben unsere Stats, wie oft welcher Fehler vorkommt. Wir können priorisieren, welche Fehler sind die, die wir als nächstes angehen müssen. Und mit dieser Information können wir jetzt an unsere Entwickler rangehen und sagen, hey, wir müssen Judgmental Language zum Beispiel im nächsten Release angehen. Jetzt hat der Entwickler ein ganz konkretes Ziel. Der kann jetzt sein neues Rack-System ausprobieren, der kann jetzt sein neues Framework ausprobieren, der kann die Prompt umschreiben, worauf der Bock hat. Und dann lässt er einfach die E-Vice nochmal durchlaufen und schaut, welchen Impact hatte dann meine Veränderung. Er kann eine ganz konkrete Zahl in seinem Manager geben und der kann dann entscheiden, ja, das funktioniert. Und du kannst diesen Prozess von diesem Gruppieren, kannst du sogar nochmal eine Stufe wiederholen, denn deine Fehler, die kannst du auch nochmal gruppieren. Und in unserem Beispiel, wir hatten jetzt dieses Beispiel mit der fehlenden Metrik bei einer Zahl, wir hatten dieses Beispiel mit Judgmental Language. Beide Probleme sind in dieser Kategorie von der Darstellung oder wie ich das Ganze reporte, wir haben es genannt Presentational Quality, einzugliedern. Und in dem Moment baut man eine Taxonomie von Fehlern. Und diese 19 Fehler-Modes haben wir in vier Top-Level-Kategorien klassifiziert. Das war Context Clarity, Presentational Quality. Und ich kann jetzt nicht nur sagen, im nächsten Release greifen wir Judgmental Language an, sondern der nächste Release konzentriert sich komplett auf Presentational Quality zum Beispiel. Und das gibt natürlich auch in Scheidern die Möglichkeit, jetzt genau zu planen, woran wollen wir arbeiten. Die können das schon ans Marketing-Team geben. Release Nummer zwei wird sich darum kümmern, Release Nummer drei darum und so weiter. Also es gibt ja Planbarkeit, es gibt ja konkrete Zahlen.

SPEAKER_04 38:08

Und vor allem, ja genau, diese Quantifizierbarkeit finde ich irgendwie interessant. Also was in meinem Kopf für ein Konstrukt entstanden ist, ist irgendwie so, du hast gesagt, du hast diese 19 Evals oder dann diese vier Hauptkategorien und die dann einfach irgendwie nur so ein Teil von so einer riesigen Formel sind. So, und die gewichtest du dann halt einfach anders. So und dann am Ende kommt irgendwie ein Wert raus so und sagst so, okay, wenn es diesen Wert überschreitet, dann können wir nicht releasen, wenn es drunter ist, dann haben wir das erreicht, was wir erreichen wollen. Also irgendwie finde ich es so schön, dass da aus so sehr viel nur Wahrscheinlichkeit irgendwie dann am Ende doch doch was zahlenmäßig rauszuhauen.

SPEAKER_03 38:38

Ja, und das hilft dir natürlich auch. Wir hatten ja am Anfang darüber gesprochen, diese Traces, diese Logs von User-Input bis zu deinem Output, dass man die erstmal collectet und sammelt. Diese Software, die man dafür einsetzt, da gibt es ja viele, Markt, nehmen wir mal Langfuse als Beispiel, hilft dir ja auch dabei zu tracken, wie viele Token hat denn dieser ganze Roundtrip gekostet. Und auf Basis von dem Modell, was du verwendest, also was hat denn das auch in Dollar oder in Euro gekostet, der ganze Roundtrip. Und die Latenz wird gemessen. Wie lange hat denn der Request gedauert? Und wenn du diese Sachen jetzt kombinierst, du hast deinen Error-Wert, die Qualität deiner Anwendung, du hast die Latenz, du weißt, wie lange dein Request gedauert hat und du weißt, was dein Request gekostet hat. Jetzt kannst du auf einmal ganz konkrete Aussagen treffen. Beispielsweise bei uns kam dann raus, es war damals, wir hatten noch GPT-4. Am Laufen, war irgendwann Anfang letzten Jahres. Dann kam GPT 4.1 raus und auch das Nano-Modell. Und ich weiß noch, dass wir dann die E-Wice haben laufen lassen. Und ich konnte dann zu meinem Manager sagen, okay, GPT 4.1 kam gestern Abend raus. Wir haben 6,2% mehr Fehler in Kontext Clarity, aber wir haben 37% schnelleren Output und wir haben 96% weniger Kosten bei dem Request. So, und das sind Zahlen, die kann ich jetzt meinem Boss vorlegen und der kann dann Entscheidungen treffen. Das heißt, wir können innerhalb von 24 Stunden nach Model Release entscheiden, ist es gut genug, dieses Model zu releasen, ja oder nein. Und vorher war das eben dieses Vibe-Getriebene. Ich probiere das einfach mal aus. Ja, das ist natürlich jetzt eine gewisse Sicherheit, die man dadurch erreicht hat. Alles nur, weil du dir mal dein Output angeguckt hast.

SPEAKER_04 40:47

Ja, also vor allem, also den Aspekt finde ich halt besonders gut, weil ich glaube, das ist auch so eine Entscheidung, die bei uns oft irgendwie so im Raum ist, wo wir uns nie sicher sind, so, hey okay, nutzen wir jetzt das Modell, gehen wir jetzt auf Gemini, nutzen wir ChGBT, ist Claude so wirklich das Wahre, sind diese ganzen Models von Mistral irgendwie ganz geil und wir nie wissen, also es ist alles sehr nach Gefühl, um dann wirklich zu sagen, so, hey, okay, es ist vielleicht minimal schlechter in dem Bereich, aber es dafür deutlich schneller in dem Output und kostet deutlich weniger Geld. Ich glaube, diese Sichtbarkeit dadurch zu haben, durch die Vides, also finde ich, ist schon ein ganz guter Vorteil auf jeden Fall.

SPEAKER_03 41:18

Ja, wir haben einen Punkt ausgelassen. Wir haben vorhin drüber gesprochen, wie sehr kann ich denn dem Model trauen, dass es auch wirklich richtig evaluiert? Nehmen wir jetzt 100 Reports, wir haben ja identifiziert, Judgmental Language ist ein Failure-Mode, der für unsere Anwendungen relevant ist. Ich bleibe mal bei dem Beispiel. Dann kann ich natürlich einen Experten aus meiner Domäne an diese 100 Reports heransetzen und dem die vielleicht nicht ganz schöne, aber wichtige Aufgabe geben, geh mal bitte durch diese 100 Reports durch und sag mir, ob das Judgmental Language enthält, ja oder nein. Das heißt, ich habe ein Human Label für ein gewisses Subset und das ist mein golden Data Set für diesen Failure-Mode. Und dann kann ich diese Prompt schreiben für dieses LLM as a Judge und dem die gleichen 100 Reports zeigen. Und was dann relevant ist, ist wieder dieser Data Science getriebene Ansatz. Ich schaue mir einfach an in einer Confusion-Matrix, wie viel Übereinstimmung ist da. Also ich schaue mir an, wie oft wurde wirklich vom Human das Label Judgmental Language vergeben und wie oft wurde das Label vom Agent oder vom LLM vergeben. Und ist es auch an den gleichen. Also man sagt dann, man hat dann diese True Positives, True Negatives und dann gibt es eben die Ausreiser, wo du dann Unstimmigkeiten hast. Und deswegen ist es so wichtig, dass du da einmal ein Human auch mit ransetzt. Denn nur so kannst du dir dann auch sicher sein, dass dieses LLM wirklich mit deinem Human Alignment übereinstimmt, dass der wirklich genau das testest, wie du das auch testen würdest. Also dafür ist dieser Schritt dann relevant.

SPEAKER_05 43:16

Wir mussten irgendwie relativ wenig Nachfragen stellen. Also du hast es einfach sehr. Du hast es einfach sehr klar und stringent uns dargestellt. Das Einzige, und wir haben trotzdem beide Fragen. Wir haben beide Frage.

SPEAKER_04 43:31

Nee, frag du zuerst. Du hast länger nichts gesagt.

SPEAKER_05 43:34

Ich muss darauf achten. Gibt es dafür eine technische Empfehlung? Weil du hast irgendwas gesagt, du hast das mit Lang, wie hieß das? Leng Fuse. Lang Fuse.

SPEAKER_03 43:48

Ja, das ist eine Software, die dir hilft, diese Traces zu sammeln. Also das ist eine Monitoring-Anwendung für Gen EI-Anwendungen.

SPEAKER_05 43:58

Okay, cool, weil das wäre noch so das Dinge gewesen, okay, wie ist so ein bisschen die technische Implementierung, weil ich glaube grundsätzlich das, ne, die Idee kam, glaube ich, sehr klar rüber. Und dann wäre ja jetzt der nächste Schritt, okay, wie kriegt man das konkret irgendwie bei sich eingebaut? Und dann ist es zumindest ja vielleicht eine Lösung, die man sich mal angucken kann.

SPEAKER_03 44:14

Genau, oder Braintre, ich will mich da gar nicht festlegen, Phoenix ist noch eine PromptFoo. Es gibt viele, viele Anbieter. Ich bin da sehr unbiased. Denn alle, alle funktionieren sehr gut und bieten auch sehr viel Funktionalität. Um damit anzufangen mit diesem ganzen Prozess, könntest du dir genauso gut einfach alle in irgendeine TXT-Datei loggen und dann dadurch gehen. Also der Prozess selber, der bedarf ja keiner Software, aber dieser Prozess wird durch so eine Software noch einfacher unterstützt. Genau. Aber es ist auf jeden Fall sehr einfach und man erreicht sehr viel dadurch. Ich hatte vorhin in dem Talk jemanden, der hat mir dann tatsächlich die Frage gestellt: Oh, das ist aber, das klingt aber sehr teuer. Da muss ich ja jemanden da hinsetzen, der da durchgeht. Und der wollte mir dann wirklich sagen, dass dieser Prozess für ihn irgendwie nicht so gut ist, weil er sehr teuer ist. Und dann habe ich ihm vorgerechnet, ja, pass mal auf, also wenn ich jetzt jemanden, ich sag mal einen Tag Setup von Langviews und ich setze einen Tag jemanden hin, der da 100 Traces bei uns durchgeht und sich das Ganze mal anschaut. So, dann habe ich da zwei Mann-Tage investiert und dann schreibe ich mir da ein paar Prompts. Was wäre denn gewesen, wenn ich jetzt diese Software released hätte, wo wir unsere Leute Low Performer nennen? So, das wäre jetzt an 10.000 Kunden ausgeliefert worden. Davon hätten sich dann 500 verabschiedet und das hätte uns dann 20 Millionen gekostet. Ich denke, hier ist schon klar, die Kosten, die amortisieren sich bei diesem Prozess, bei diesem so einfachen Prozess sehr schnell. Also Kosten sind auf jeden Fall gar kein Gegenargument. Und das Spannende ist auch, das ist auch ein Prozess, der macht den Leuten tatsächlich Spaß. Denn wenn man so durchgeht und sich mal durchliest, was ist denn so der Output? Man erkennt manchmal so lustige Dinge auch oder der greift sich an den Kopf. Man sieht es ja auch immer wieder in den Inreddit, selbst die großen Player, Google, Amazon, selbst, die haben ja nicht fehlerlose Software, weil wir reden von stochastischen Systemen.

SPEAKER_04 46:43

Ich musste so lachen bei diesem Seepferdchen-Emoji-Ding. Alter, ich konnte nicht mehr vor Lachen, das war so lustig. Das war so lustig.

SPEAKER_03 46:50

Aber es geht natürlich auch manchmal in eine richtig blöde Richtung. Wir hatten jetzt bei Google ja auch diesen KI-Mode, wo du Fragen stellen kannst. Und manchmal ist dort ja wirklich sehr komischer Output. Beispielsweise wurde ja dort empfohlen, dass du Kleber auf die Pizza machen sollst, weil es tatsächlich ein Reddit-Thread gab, wo das so beschrieben wurde. Oder Google empfiehlt, dass es sinnvoll sein könnte, einen kleinen Stein pro Tag zu essen. Wenn du jetzt Engineer bei Google bist und du kriegst die Aufgabe, schreib doch mal Tests für den neuen KI-Mode. Wäre das wahrscheinlich kein Test, der dir am Anfang in Sinn gekommen wäre, aber dadurch, dass du dir tatsächlich mal deine Daten anguckst, ja, schaffst du das. Ja, und vielleicht um den Burgen auch zu machen zu dem Bereich, wo wir arbeiten, so Model Training. Wenn du diese EVE hast, gibt dir das natürlich aus Produktsicht Sicherheit, ja, und auch diese Metrik. Was du aber auch machen kannst, ist, diese Evice dann später fürs Model Training, fürs Steering einzusetzen. Also wenn man Judgmental Language jetzt als Evaluator hat, kann ich diesen Evaluator benutzen, um Outputs zu validieren, die mir ein Model generiert. Ich judge das und nutze das, um das wieder als Feedback beim Reinforcement Learning reinzubringen und das Model dann automatisiert in die richtige Richtung trainieren zu lassen. Also es hilft mir nicht nur auf Produktebene, sondern eben dann auch später beim Training und überall. Und ja, also es ist wirklich eine sehr, sehr nützliche Sache, kann ich nur empfehlen.

SPEAKER_05 48:39

Hört sich sinnvoll an.

SPEAKER_04 48:42

Vielleicht ein Aspekt, weil du es häufiger erwähnt hast, diese sehr spezifischen, auf euer Produkt zugeschnitten Evals, die 19 Stück, die ihr dort dann irgendwie identifiziert habt und dann auch dann klassifiziert habt, ist, also wie du richtig gesagt hast, ist es auf jeden Fall irgendwie ein Prozess, ein Aufwand, den man machen muss und der sich so nicht eins zu eins auf andere Produkte übertragen lässt. Und da hast du so ein bisschen die Frage, vielleicht gibt es da schon etwas so, was vielleicht ein bisschen generischer ist, so, Schritt eins, oder sagst du, nee, man wird dabei bleiben müssen, sich wirklich sein Produkt anzuschauen, sich wirklich damit auseinanderzusetzen, zu gucken, was sind denn unsere eigenen Benchmarks, was ist uns wichtig und dann halt quasi immer auf eine sehr hochspezifische Lösung am Ende zu kommen.

SPEAKER_03 49:22

Ja, also ich, ja, es gibt solche fertigen Lösungen, aber ich bin kein Freund von. Der einzige Vorteil, den man davon vielleicht haben könnte, wäre es zu verwenden, um dein initiales Dataset zu erstellen. Wir haben ja gesagt, wir gucken uns die ersten 20 Traces an. Das reicht in der Regel aus, um schon mal ein Gefühl dafür zu bekommen. Wenn du jetzt aber tausende von Traces hast, ja, welche 20 nimmst du denn da? Das muss man ja auch erstmal machen. Das könntest jetzt natürlich random sample. Oder du sagst, du nimmst dir die 500 längsten. Oder du nimmst eben solche generischen E-Lives wie Helpfulness, die es eben fertig am Markt gibt, die aber sehr, sehr generisch sind und würdest dann sagen, okay, alle, die unter einem gewissen Score sind, das sind die ersten 20, die ich mir anschaue. Für sowas kann es sinnvoll sein. Aber ansonsten macht es einfach Sinn, dass du hochspezifisch auf dein Produkt diese Failure-Modes anwendest. Jetzt auf so einen Kontext wie Blue Yonder, ein riesen Enterprise-Unternehmen gesehen. Es gibt durchaus den Fall, dass Evals für verschiedene Projekte relevant sind und nicht nur produktspezifisch sind. Jetzt in das Beispiel von diesem Report, Judgmental Language, das ließe sich bestimmt auch auf andere Dinge im gesamten Unternehmen anwenden. Denn überall dort, wo man Customer Facing irgendwie unterwegs ist, möchte man ja kein Judgmental Language haben. Aber es gibt auch andere Dinge, beispielsweise nehmen wir mal den Punkt Bias von Models. Gerade jetzt im internationalen Supply Chain-Kontext kann es durchaus Sinn machen, generische, ich sage jetzt generisch in Anführungszeichen, Levice zu schreiben, die zum Beispiel sicherstellen, dass man keinen geografischen Bias mit drin hat. Wenn ich jetzt Kunde von so einer Software bin und ich frage einen Agent, wie könnten wir denn die, oder welches Land wäre denn das Beste, um meinen Truck dadurch zu schicken? Dann will ich keinen geografischen Bias haben, weil der Präsident irgendwie blöde Sachen tweetet, sondern ich will möglichst unvoreingenommen an die Sache rangehen. Das sind Dinge, die sind natürlich für alle Projekte relevant. Also wenn man so eine Art Dashboard baut mit solchen generischen Sachen, kann es schon Sinn machen, dass man das auf mehrere Sachen ausweitet, aber das ist eher die Ausnahme und sehr schwer zu finden.

SPEAKER_05 52:16

Cool. Können wir nochmal ganz kurz off-Topic gehen? Off-Topic sind. Nicht off record, off-Topic. Weil du hast, äh du hast ja auch gesagt, ihr macht auch viel Feintuning von Modellen und irgendwie da eigene Sachen anzupassen. Ist das noch, also ist das noch ein Ding? Hört sich irgendwie vielleicht falsch an, aber also ich frage das immer mal, also macht das noch Sinn oder entwickeln wir uns irgendwie, sind die so groß und ist es dann ein Kostenfaktor, weil man kleinere Modelle nehmen kann oder ist es wirklich dann, weil man diesen Output aus den großen Modellen nicht rausbekommt. Glaubst du, es wird es lange, längerfristig in Zukunft haben? Wie ist ein bisschen der Take darauf, weil ihr ja anscheinend viel in dem Bereich macht, was jetzt auch nicht jeder macht?

SPEAKER_03 53:04

Also, es gibt diesen schönen Spruch, Models come and go and Eva's are here to stay, um nochmal beim Thema zu bleiben. Du kannst halt immer wieder neue Models testen und die Eva schreibst du in der Regel nur einmal. Ich denke, es wird noch sehr, sehr lange Sinn machen, dass man eigene Model in die richtige Richtung drückt. Auf welche Art und Weise, ob das jetzt Supervised Feintuning ist oder Reinforcement Learning. Das hängt immer vom Anwendungsfall ab. Also der Hauptunterschied zwischen diesen beiden Varianten ist ja der: Beim Supervised Fine-Tuning hast du ein Ground-Thruth-Dataset und du bringst das dem Model bei. Das heißt, du willst dort die Fehlerrate minimieren, dass das von den Vorgaben abweicht. Beim Reinforcement Learning ist es genau andersrum, du hast diesen Grader, der dir einen gewissen Reward gibt und versuchst, diesen Reward zu maximieren. Wenn man das jetzt in einfacher Sprache ausdrücken wollte, könnte man das Beispiel von Omas Rezept nehmen. Wenn du jetzt einen Model beibringen willst, wie Omas leckere Lasagne hergestellt wird, dann wäre der Vergleich beim Supervised Fine-Tuning, dass du jeden einzelnen Schritt vom Model kontrollierst, dass es auch genau das macht, was Oma im Rezept hier gemacht hat. Und immer wenn es leicht abweicht, gibst du einen gewissen Fehlerwert. Beim Reinforcement Learning sagst du, das muss genau so schmecken oder du bewertest den Geschmack und du lässt aber mittendrin das Model machen, was es will und du versuchst es gar nicht einzuschränken. Wenn der am Ende mit der Idee rauskommt, der schmeißt alles in die Luft und es landet random Zeug in der Lasagne drin und du schmeißt das zu einer random Zeit in den Ofen und es ist aber leckerer als Omas Rezept, dann hat es einen höheren Reward und hat einen besseren Weg gefunden. Also so kann man die Sachen vielleicht vergleichen, Fine-Tuning versus Reinforcement Learning. Und ob du nun willst, dass du den Prozess 100% akkurat abbildest oder ob du einen Reward möglichst maximieren willst, das hängt von deiner Domäne ab. Aber die Models, die zur Verfügung stehen, die sind sehr generisch. Die sind mit dem Weltwissen gefüttert und wenn du die in deine Domain reinpressen willst, wird es noch sehr lange Sinn machen, die auch für deine Fälle zu optimieren. Also es ist richtig, dass Models so im Schnitt alle sieben Monate in ihrer Fähigkeit sich verdoppeln, immer besser werden. Und ich weiß auch nicht, wo wir am Ende landen werden, aber noch macht es auf jeden Fall Sinn, das zu trainieren. Auch beim Thema E-Wice. Nehmen wir mal an, die Models werden immer besser. Wir haben jetzt Models, denen gibst du eine Aufgabe, die arbeiten da eine Minute, anderthalb Minuten dran, bis dir Cloud Code oder ChatGPT da eine Antwort gibt. Aber wie sieht das in fünf Jahren aus? Da hast du dann Modelle, denen gibst du eine Aufgabe und die arbeiten dann 16 Stunden daran, bis die dir eine Ausgabe geben. Und beim Testen von solchen Longrunning Agents ist es halt sehr schwierig. Du kannst den Prozess machen, den wir gerade beschrieben haben, dieses Outcome-Based Evaluations, du guckst dir den Output an, Richtung Reinforcement Learning, oder du guckst dir den Process an, den kompletten Schritt, den dein Agent unternommen hat. Und schaust den ersten Punkt an, wo er vielleicht vom Ideal abgewichen ist, Richtung Supervised Feintuning wieder. Und da ist es natürlich super schwer, da die richtigen Entscheidungen zu treffen. Und ja, wo der Weg hingeht, das ist tatsächlich schwer zu sagen.

SPEAKER_05 57:24

Spannend. Spannend. Spannend. Wärst du gerne noch etwas gefragt worden, was wir dich nicht gefragt haben?

SPEAKER_03 57:33

Ach, wir könnten noch so tief in die Thematik einsteigen, aber ich denke, es ist lustig. Ich habe letztens Werbung für einen Film angezeigt bekommen, der nennt sich Mercy. Und die Thematik fand ich super passend, denn es geht in dem Film darum, dass KI, also wir haben ja vorhin über LLM, also Judge gesprochen, dass KI in der Zukunft tatsächlich als Judge im Legal System eingesetzt wird. Und ich habe dann, als ich den Trailer gesehen habe, mir gedacht, oh wow, wenn tatsächlich ein Large Language Model irgendwann rechtliche Entscheidungen trifft, wie würde man das denn testen? Und wie würde man das sicherstellen? Das stelle ich mir auch sehr, sehr schwierig vor. Ja.

SPEAKER_04 58:23

Evils. Ja. Damals. Ich würde mir jetzt sogar rausnehmen und sagen, das könnte man bereits schon machen und hätte eine sehr gute Abdeckung davon, wie ein menschlicher Richter entschieden hätte. Vielleicht Strafrecht ausgeklammert, so ein bisschen. Also ich glaube, Strafrecht ist hoch individuell, aber ich glaube, alles andere wird jetzt.

SPEAKER_05 58:43

Es wird ja auch viel gesagt, dass das so eine der nächsten Branchen ist.

SPEAKER_03 58:48

Sehr deterministischer Prozess.

SPEAKER_05 58:49

Genau, genau. Bis auf Strafrecht, glaube ich. Strafrecht ist, glaube ich, das ist natürlich dann auch hart, wenn man einen Film drüber macht in dieser aktuellen Zeit.

SPEAKER_03 58:55

Ja, das ist, ich meine, das ist irgendwie so dass es aber auch wirklich so ein wirklich ein LLM as a Judge war, war in dem Moment auch so amüsant. Aber es ist auch krass, ich habe auch letztens gelesen, Opus 4.6 kam ja jetzt raus. Und es gibt ja so einen Benchmark, nennt sich SearchComp. Und die testen dort sehr, sehr schwierige Fragen, wo ein LLM die Aufgabe kriegt, wirklich so die Nadel im Heuerhaufen im Internet zu recherchieren. Das sind wirklich, da gibt es nur eine einzige Seite, die die Antwort dafür liefert und ist das LLM in der Lage, das rauszufinden. Das ist so ein sehr, sehr tricky Benchmark.

SPEAKER_04 59:36

Wo ich auch kurz den Sinn hinterfragen würde, so ein bisschen. Weil ich denke, wenn es nur eine einzige Quelle dafür gibt, so ist das Wissen wirklich richtig.

SPEAKER_03 59:44

Ja, weil die Challenge ist, ist es wirklich in der Lage, diese eine Quelle zu identifizieren? Und tatsächlich ist es sehr interessant gewesen. Opus 4.6 ist das erste Model gewesen, das hat identifiziert, dass sich gerade in einer Evaluation befindet. Es hat nämlich gesagt, man kann ja dann den Thinking Step sehen, hat gesehen, Moment, der User hat mich das gefragt, bla bla bla, fing an, dann erstmal so einen Weg zu finden. Und so mittendrin war in dem Thinking Step dann, das ist eine sehr, sehr spezifische Frage, die ist so hochspezifisch, befinde ich mich eventuell gerade in einem Test. Moment, ich recherchiere das kurz. Hat dann angefangen, diese Art von Fragen, die ihm gestellt wurde, im Internet zu suchen, ist in einem GitHub-Repository gelandet, hat herausgefunden, in welchem Benchmark es sich gerade befindet, auf Basis auch der vorangegangenen Fragen, konnte aber die Antwort nicht sehen. Die sind nämlich encoded. Hat sich dann das GitHub-Repository angeguckt, hat das Encoding geknackt und alle 1200 Antworten richtig submitted. So, jetzt könnte man sagen, der Benchmark war bestanden, denn es wurden alle 1200 Fragen richtig beantwortet. Die Frage ist, ist der Test jetzt noch valide? Will man jetzt den Output graden oder will man jetzt den Process graden? Das ist an der Stelle schwierig zu sagen. Ja, ist eine coole Frage. Awareness bin ich gerade in einer Evaluation, ja.

SPEAKER_04 1:01:17

Aber da kam jetzt auch gerade dieses Bild, was du gerade beschrieben hast, so voll im Kopf mit diesen, man wirft random Zutaten und hat irgendwie random in den Rufen und zack, guckt, was dabei rauskommt. Und zufällig ist das geiler als das, was du Oma gemacht hast. Nee, so, ja, okay, aber ist das reproduzierbar gerade? Ist das auf alles anwendbar? Und das ist natürlich die Frage, die man sich stellen muss. Also deswegen, ja, spannend.

SPEAKER_05 1:01:38

Sehr gut. Ja, klar, wir könnten viel weiterreden, aber ist auch der beste Podcast vorbei. Und auch damit unsere heutige Folge. Von daher, liebes Publikum, liebe Hörerinnen und Hörer, wenn ihr Feedback zu dieser Folge habt, dann schreibt uns gerne an podcast.programmier.bar. Vielen Dank an dieser Stelle nochmal an die Decompiled, vielleicht da draußen, dass wir das im Rahmen machen konnten. Vielen, vielen Dank, Martin, dass du heute die Zeit gefunden hast, mit uns beiden zu sprechen. Hat uns sehr viel Spaß gemacht, war sehr informativ und wir machen Hele, Hele, Hele, Helikopter. Du wolltest, glaube ich, auf das Gebäude hinweisen. Nee, gar nicht, das war mir egal. Helikopter, ja. Sehr gut. Und auch nochmal Shoutout an Vodafone, dass sie uns hier in ihrem Dresdner Gebäude untergebracht haben, damit wir in Ruhe einen Podcast aufnehmen, zwei Podcasts aufnehmen konnten. Vielen Dank, viele Grüße. Macht's gut. Bis bald. Danke, bis bald. Tschüssi.