Deep Dive 203 – AI in Production mit Maximilian Hudlberger

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

Wir sprechen mit Maximilian Hudlberger, Solution Architect bei OpenAI, über Best Practices für AI in Production. Max erklärt, wie Unternehmen verschiedenster Größe Large Language Models in ihre Anwendungen integrieren – von klassischen Chatbots über Klassifizierungsaufgaben bis hin zu komplexen Multi-Step-Agenten, die Workflows automatisieren. Dabei geht es um typische Patterns, häufige Herausforderungen sowie die Unterschiede zwischen Start-ups und großen Enterprises bei der Umsetzung.

Ein wichtiges Thema ist die Evaluation und Qualitätssicherung von AI-Anwendungen. Max erläutert, wie Output-Qualität gemessen wird und welche Rolle Human Annotation, LLM-Graders und automatisierte Eval-Mechanismen spielen. Anhand konkreter Beispiele aus Lern-Apps und Customer-Service-Anwendungen wird deutlich, wie komplex die Abstimmung von Output, Stil, Genauigkeit und Workflow in der Praxis sein kann.

Zudem besprechen wir Kosten, Latenz und Caching. Max erläutert, wie Unternehmen die Kosten kalkulieren, den Tokenverbrauch abschätzen und Caching nutzen können, um die Performance und Effizienz zu verbessern. Außerdem beleuchten wir die Themen Context Engineering, Prompt Engineering und Fine-Tuning.

Abschließend gibt Max Einblicke in aktuelle Trends wie Agent Reinforcement Fine-Tuning und zeigt, wie komplexe Multi-Step-Agenten evaluiert werden können.

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_00 0:08

Hallo und herzlich willkommen zu einem neuen Deep Dive hier in der Programmierbar. Mein Name ist Fabi Fink und mit mir im Studio ist der liebe Jan. Moin Moin. Hi Jan. Wir wollen heute über AI in Production reden. Und es ist ja ein weitgefasstes Thema. Wir haben uns jemand eingeladen, der da ganz genau weiß, worum es da geht. Wir haben den lieben Max Hudelberger bei uns. Max ist Solution Architect bei OpenAI. Also im Grunde genommen kümmert er sich darum und redet mit den kleinen Startups, also auch den großen Enterprises und redet darüber, wie die OpenAI-API integriert wird, also wie AI in diesem Fall dann in Production eingesetzt wird. War vorher Lead Data Scientist bei Data Robot, war bei der Allianz und der PWC und Max, wir sind sehr froh, dass du heute hier bist. Hallo, herzlich willkommen in der Programmierbar.

SPEAKER_03 0:52

Hi Fabi, hi Jan, freue dich hier zu sein.

SPEAKER_00 0:56

Wir freuen uns auch. Wenn wir über AI in Production reden, ich habe gerade vorhin schon mit dem Jan im Vorgespräch ein bisschen drüber geredet, eigentlich, glaube ich, so für die unsere Hörer da draußen, ist es glaube ich am greifbarsten, wenn wir erstmal, bevor wir irgendwie über die Probleme reden und auf was man irgendwie achten muss, vielleicht kannst du uns erstmal so ein bisschen erzählen, was sind denn so AI in Production Use Cases, mit denen die Leute so zu dir, zu euch, zu OpenAI kommen. Würdest du sagen, da gibt es bestimmte Pattern, ist das super unterschiedlich? Was sind die, gibt es typische Use Cases? Vielleicht auch unterschieden nach, was machen die kleinen, was machen die Großen? Über was unterhält man sich da, wenn man zu dir kommt?

SPEAKER_03 1:31

Da gibt es auf jeden Fall Patterns. Du hast es ja eingangs schon erwähnt, we arbeiten with large enterprises, but auch startups oder digital natives. I do for all so a bit. And the patterns unter manchmal, but often the same. When we are AI Use Cases spread, then muss man erst mal AI Use Cases nach JGPT show teilwise a bit and they before. I'm now in a side, I've been in a classical machine learning engineering angefangen. There are AI Use Cases in der Regel ja noch predictive AI Use Cases often. Also da kamen zum Beispiel die Banken, Versicherer, Hedgeforce and haben dann Prognosemodelle erstellt oder Time-Series Modelle. Heutzutage, und vor allem jetzt bei OpenAI, sind natürlich viele der AI-Us Cases dann eben klassische LLM-Use Cases in dem Fall. Und da muss man auf jeden Fall sagen, dass es da schon gewisse Patterns gibt. Ich fange mal an mit dem einfachsten Pattern oder dem Pattern, das jetzt doch schon seit einigen Jahren sehr oft verwendet wird. Das ist dann eben der klassische Chatbot, zum Beispiel für ein Knowledge Retrieval. So haben dann viele Unternehmen angefangen vor drei Jahren, zwei, drei Jahren. Da hat man sich gesagt, super, wir haben jetzt ein Chatbot, wir müssen das Ganze jetzt mit unseren Unternehmensdaten anreichern und wollen da eben gute Antworten bekommen. Das ist der erste sehr klassische Use Case, würde ich sagen. Die zweite Kategorie würde ich immer noch sehen als klassische oder LLM-Anwendung für eigentlich klassische ML-Use Cases. Da geht es dann oft um so Themen wie Klassifizierung, eine Einteilung von verschiedenen Kategorien. Das gibt es schon auch noch. Und dann aber der dritte oder das dritte Use Case-Pattern, das vor allem dann im letzten Jahr auch deutlich populärer wurde, sind dann Agenten. Und wenn ich jetzt von Agenten spreche, können wir wahrscheinlich auch später noch mehr drüber sprechen. Dann sind das eben vor allem Use Cases, in denen Multi-Turn und Multi-Step-Reasoning erfolgt. Das bedeutet, ich habe vielleicht einen Agenten, ich chatte oftmals gar nicht mehr mit dem Agenten, sondern gebe eine Aufgabe an den Agenten. Und der Agent fängt dann vielleicht mal mit einem Reasoning an, dann gibt es mal einen Tool Call, dann gibt es vielleicht noch ein weiteres Reasoning. Vielleicht muss der Agent auch an andere Agenten weitergeben und irgendwann kommt dann eine Antwort zurück oder vielleicht wird auch nur ein Workflow getriggert. Das sind jetzt mal, glaube ich, so drei Anwendungen, die man einfach momentan sehr häufig sieht.

SPEAKER_00 4:14

Cool, ich glaube, das sind eine sehr gute Einladung. Ich glaube, also Chatbot, glaube ich, kann sich da draußen jeder was drunter vorstellen, so den ersten Use Case, denke auch Klassifizierung. Vielleicht bei, kannst du noch zwei Sätze zu dem Agent-Use Case verlieren, weil ich glaube, jetzt, wenn man unsere Developer-Brille aufsetzt, ich glaube, wenn hier auch unsere Zuhörer irgendwie über Agents nachdenken, sind es meistens irgendwie im Coding-Kontext, heißt die Aufgabe ist meistens Coding-related so. Und wie ist es jetzt bei dir, die Kunden, die da kommen, so was sind diese Agent-Use Cases? Vielleicht, also hast du Beispiele außerhalb von Coding oder ist Coding sogar gar kein Thema bei den Unternehmen, die zu dir kommen? Was kannst du da Beispiele nennen?

SPEAKER_03 4:49

Ja, also Coding ist auf jeden Fall ein Thema. Und natürlich haben wir auch viele Kunden, die im Coding Space sind und die dort viel machen. Also die Lovable Cursors dieser Welt. Die verwenden natürlich Atlantic Coding vor allem. Wir machen es natürlich auch selber mit Codex. Habt ihr wahrscheinlich auch schon davon gehört? Aber andere klassische Atlantic Use Cases, vielleicht ein Beispiel wäre jetzt ein AI-Trip Planner. Also wenn man sich jetzt zum Beispiel Booking.com anschaut, dann gibt es da eben die Möglichkeit, dass man vielleicht einen Trip plant. Und jetzt kann es eben sein, dass man eine Frage an den Agenten hat, aber die kann dann eben sehr vielfältig sein. Ich kann zum Beispiel ein Problem haben mit einer Reise. Ich möchte gern vielleicht eine neue Reise buchen. Ich will vielleicht einen bestimmten Sitzplatz. Also ich kann ganz viele verschiedene Probleme haben. Und je nach Problem können dann eben verschiedene Workflows auch getriggert werden. Oder zum Beispiel bei Telekommunikationsunternehmen, wenn man da zum Beispiel Customer Service Use Cases hat, kann es eben auch sein, dass der eine Kunde vielleicht ein Problem mit der Rechnung hat, der andere Kunde vielleicht Probleme oder einen neuen Vertrag abschließen will. Das heißt, bei solchen Agentic Use Cases ist es oft so, dass es verschiedene Agenten für verschiedene Problemstellungen im gleichen Use Case gibt. Das sind jetzt so Anwendungen, die sind immer noch relativ chat-nah, oft, weil man ja oft noch selbst interagiert. Aber ihr könnt euch auch vorstellen, dass zum Beispiel im Unternehmenskontext, wenn man jetzt mal Richtung Manufacturing geht, dass es da eben auch super viele Workflows gibt, die man komplett mit Agenten abbilden kann. Oder zum Beispiel im Knowledge Work. Also ich kann zum Beispiel, ich bin vielleicht ein Pharmaunternehmen oder ein Researchunternehmen und ich will zum Beispiel für ein Clinical Trial habe ich einen gewissen Workflow, der muss dann abgedeckt werden und in diesem Workflow, der ist nicht deterministisch, also je nach Outcome muss ich eben in verschiedene Richtungen abbiegen. Und das sind dann eben solche Agentic Use Cases, die dann zwischendrin mal kurz innehalten, gucken, okay, wo liege ich denn jetzt eigentlich gerade? Welches Tool muss ich als nächstes callen oder muss ich vielleicht direkt an einen anderen Agenten abgeben?

SPEAKER_01 6:55

Und wenn die Leute zu euch kommen, egal ob jetzt großes Enterprise oder kleines Startup, wie ausgereift und realistisch ist denn da die Idee, was die so vorhaben und wie viel Händchenhalten müsst ihr da am Ende noch? Oder manchmal auch so ein bisschen Expectation Management betreiben und sagen so, ja, da sind wir jetzt vielleicht noch nicht oder lassen wir hier mit einem MVP zwei Schritte kleiner starten oder ist das meistens schon so Blueprint fertig und ihr seid da eigentlich eher dann nur noch so ein Implementierungspartner?

SPEAKER_03 7:26

Ja, sehr gute Frage. Das kann tatsächlich sehr unterschiedlich sein. Ich fange mal mit Large Enterprise an. Da ist, denke ich, schon noch ein Großteil unserer Arbeit, auch die, dass wir uns mal zusammensetzen und dann auch mal gucken, welche Use Cases denn vielleicht jetzt gute Use Cases sind, mit denen wir starten können. Gerade im Large Enterprise Bereich ist es ja oftmals vielleicht auch gar nicht so leicht, mal einen Use Case live zu bringen. Da gibt es eben noch verschiedene Abteilungen, die da vielleicht dranhängen. When I just startups go and digital natives, then have they a very genuine plan for use cases, died umsetzen wollen. So the arbeit with startups is often. They can their use case so and they wanna help their use case so scalier as most to make. Und wir, ich glaube, sprechen nachher auch nochmal vielleicht so ein bisschen, was denn jetzt so gut und so effizient wie möglich heißt.

SPEAKER_01 8:50

Als ich früher im Consulting gearbeitet habe, war ja so einer der, oder die meisten Projekte, die ankommen, sind immer so, ja, wir haben hier was, das ist irgendwie in einem Excel-Sheet oder in irgendeiner Extras-Datenbank, wir würden das gerne in eine eigene Software gießen. Ich stelle mir das bei diesen ganzen AI-Use Cases ähnlich vor. Wir haben hier schon einen existierenden Workflow und wir würden den jetzt eben gerne automatisieren und AI-geschützt laufen lassen. Und dann fällt ja das erste Mal ganz häufig auf, dass irgendwie keine Dokumentation da ist, der Prozess vielleicht gar nicht so sauber beschrieben ist, sondern nur in den Köpfen von ein, zwei Mitarbeitern vielleicht irgendwie lebt. Wie viel Kontextaufarbeitung müsst ihr da betreiben, bevor ihr wirklich an die Entwicklung gehen könnt? Ja.

SPEAKER_03 9:32

Also das Problem, das du beschreibst, ist real. Öfter auch wieder im Large Enterprise Kontext gesehen. Wenn wir jetzt mit Digital Natives und Startups wieder arbeiten, liegt ja in der Natur der Sache, dass da die Daten immer schon in relativ guter Form eigentlich vorliegen. Aber ja, tatsächlich, im Large Enterprise-Bereich gibt es oft noch dieses Problem, dass man einfach die Daten erst noch verstehen muss oder auch auf gute Art und Weise anbinden muss. Manchmal ist es ja vielleicht so, dass sie noch gar nicht in der Cloud verfügbar sind, beispielsweise. Das heißt, das ist ein reales Problem. Wir haben auch, kann ich vielleicht auch kurz sagen, ich bin ja Solutions Architect, das heißt, ich arbeite vor allem auf API-Seite und optimiere API-Calls. Wir haben aber zum Beispiel auch noch die Rolle des Forward Deployed Engineers bei OpenAI, die dann wirklich vor allem für Large Enterprises, die dann vor Ort sind und wirklich auch bei der Implementierung helfen und genau an solchen Fragen arbeiten, weil das eben auch noch oft das Bottleneck bei großen Unternehmen ist. Und ich glaube, das war ja auch so ein bisschen der Grund, ich weiß nicht, wie ihr das seht, dass ja gerade diese Rolle des Forward Deployed Engineers ist ja nochmal sehr aufgeflammt im letzten Jahr. Und ich glaube, das Problem, das du beschrieben hast, hatte da einen großen Anteil.

SPEAKER_00 10:48

Und wenn du, du hast ja gerade so ein bisschen eingeteilt, dass du sagst, du bist ja Solutions Architect für den API-Teil. Das heißt, ich würde jetzt mal sagen, wenn Leute mit eurer API sprechen, dann haben sie vielleicht schon Teile von, okay, Rack, wo kriege ich überhaupt die Informationen her? Das, was den Part, den Jan gerade aufgemacht hat, klingt nämlich erstmal noch so, sie sind noch einige Schritte zurück. Sagen wir mal, wir sind jetzt bei dem Use Case zu sagen, okay, irgendwie meine Daten, vielleicht auch noch nicht alles optimal, aber irgendwie bin schon dabei, mit der API zu interagieren, habt ihr vielleicht auch schon einen ersten Proof of Concept irgendwie so. Und wenn man jetzt sagt, man will mit dem Chatbot, wenn wir jetzt mal das einfachste Beispiel irgendwie nehmen, irgendwie in Produktion gehen, was sind denn so typische Problemstellungen, mit dem dann vielleicht dann in Produktion wirklich, weil da muss ja erstmal über einen Schritt hinaus sein, irgendwo herkommen Informationen so, irgendwie habe ich schon was gebaut, was funktioniert, ich will das in Produktion bringen, was sind denn die Dimensionen, die Problemdimensionen, auf die die Leute dann treffen, wo ihr unterstützt.

SPEAKER_03 11:44

Ich würde sagen, wenn jemand mit einem Use Case anfängt, dann ist es in der Regel erstmal Vibes-Based. Das bedeutet, ich habe einen Chatbot, ich stelle ein paar Fragen und ich denke mir dann am Ende, sieht gut aus. Und der Unterschied zwischen sieht gut aus und funktioniert verlässlich jeden Tag, sind am Ende des Tages Evals. Das heißt, wenn wir an einem neuen Use Case arbeiten, dann ist die erste Frage, die ich immer stelle, okay, was sind die Evals, wie sehen die aus und was bedeutet gut für euch? Was heißt das Ganze jetzt? Ich habe einen Chatbot, ich habe vielleicht schon Daten angezapft. Ich muss mir jetzt als Unternehmen überlegen, was für mich denn jetzt eine gute Experience ist. Zum Beispiel, wie soll der Gesamtoutput aussehen? Was für ein Format, was für einen Stil hätte ich gerne im Output? Was darf auf keinen Fall fehlen? Das ist jetzt mal so ein Thema. So allgemeine Output-Qualität. Ich muss mir aber auch Gedanken machen, inwieweit mein Modell zur jeweiligen Zeit auch die richtigen Input-Daten für den Output nimmt. Also du hast ja gerade gesagt, Fabi, that wäre zum Beispiel ein Use Case, in dem man Daten anzapfen muss. Wie stelle ich denn sicher, dass bei der richtigen Frage die richtigen Daten angezapft werden? Da gibt es dann auch wieder andere Evalues dazu zum groundedness, also recall precision. Können wir auch gerne näher drauf eingehen, wenn ihr wollt, aber wie stelle ich ihm sicher, dass when ich jetzt frage, was sind jetzt irgendwie meine Unternehmenszahlen aus dem Jahresbericht 24, dass dann da auch die richtige Zahl kommt. Das heißt, am Ende ist es so, ich muss mir ganz klar Gedanken machen, was bedeutet gut für mich? Was sind die Fragen, die ich erwarte, und was sind dann die Antworten, die ich erwarte. Also man spricht dann auch oft von golden Datasets oder Golden Answers, wo ich mir einfach als Unternehmen Gedanken mache, wie soll diese Applikation genutzt werden und was bedeutet gut für mich?

SPEAKER_01 14:00

Das ist eigentlich ein ganz interessanter Punkt, weil so aus der deterministischen Software kommt, haben ja Kunden ganz oft sehr konkrete Vorstellungen, wie so ein gutes Ergebnis aussieht. Und da kann man dann Testgetrieben gegen entwickeln und irgendwann, weiß ich nicht, hat man halt eins zu eins dieses Ergebnis dann, ne? Wie einfach oder schwierig sind denn diese Gespräche mit den Kunden, wenn man denen dann erklären muss, naja, diese hundertprozentige Sicherheit, die es ja de facto früher auch nicht gab, ne, wir haben alle irgendwie wachsende Software gebaut, aber diese gefühlte hundertprozentige Sicherheit, die es früher gab, wenn man jetzt Buchhaltungssoftware entwickelt hat vielleicht, wo man einfach Zahlen aufverliert und dann sieht man, ob das irgendwie stimmt oder nicht, die gibt es ja so nicht in diesem Feld. Und dann muss man, wie du schon gesagt hast, so ein bisschen flexibler für sich ausdefinieren, was ist denn gut und womit können wir denn leben? Welche Abweichung ist da für uns okay? Wie wird das aufgenommen?

SPEAKER_00 14:55

Vor allem ja, vielleicht noch eins, eine Umfamilie, ich habe eigentlich dieselbe Frage gestellt, meine Frage wäre gewesen, antwortet nicht jeder darauf, ich möchte die richtige Antwort haben. Also sie soll die richtige Antwort geben. Ich fälle mir vor, das ist erstmal die erste Antwort, da soll halt keine falsche Antwort rauskommen. Die sollen die richtigen Informationen holen. Und es ist doch einfach.

SPEAKER_01 15:13

Das soll doch einfach das Richtige sagen.

SPEAKER_00 15:14

Aber wie kann, also ich habe, mir fehlt gerade noch ein bisschen die Vorstellungskraft dafür, wie definiere ich denn, wo Abweichungen okay sind und welche Abweichungen, wenn der Ergebnisraum so groß ist?

SPEAKER_03 15:24

Ja, genau, also meine Rückfrage wäre direkt, naja, also was ist die richtige Antwort? Ich glaube, wenn wir ein Output haben, Fabian und ich und vielleicht haben wir eine andere Definition von richtiger Antwort.

SPEAKER_00 15:35

Ja, aber dein Beispiel war die Unternehmenszahlen aus 2025, die sollten halt schon richtig kommen.

SPEAKER_03 15:41

Das ist in dem Fall ein relativ einfaches Beispiel, weil es da eben eine richtige Antwort gibt. Aber wenn es jetzt zum Beispiel, wenn es um einen Learning Assistenten gibt und ich zum Beispiel da eine bestimmte Sprache lernen will, dann geht es ja mehr um diese Experience. Also zu deiner Frage, Jan. Wie nehmen Unternehmen sowas auf? Es kommt wieder sehr stark auf den Use Case an. Ich komme auch wieder aus einer Welt, aus einer, also ich habe Mathematik studiert, ich komme aus einer Welt, mehr aus der Data Science Welt. Das bedeutet, for mich, wenn ich früher Machine Learning Use Cases gemacht habe, dann waren Metriken für mich natürlich immer ein Bestandteil. Man guckt sich dann einen Fehler an, man showed sich an accuracy an, das ist dann relativ klar greifbar. The modelle were not perfect damals, Klammer auf, Klammer zu. But it is einfach deutlich greifbar. Heutzutage with LLM-Application is it schwieriger, aber die Ambition sollte sein, dass man doch wieder so eine Art E-Wail-driven system design implementiert. And it's Evals, die dann immer noch deterministisch sind. Es gibt aber auch Evals, die es nicht sind. Beispiel wenn ich jetzt ein, sagen wir mal, ich spreche jetzt über einen Use Case, ich arbeite mit einem Kunden, die sind im Learning Space, also die verbinden zum Beispiel AI-Tutoren mit Schülern und die sprechen dann miteinander. Und nach der Lesson gibt es dann vielleicht Lesson Insights, wo dann der Schüler nochmal, die Schülerin für sich selbst danach erlernen kann and gewisse Übungen macht. Und da kann man jetzt eben sagen, okay, wie ewig jetzt das Ganze? Einmal soll die Übung natürlich sinnvoll sein, wird schon schwieriger, aber vielleicht gibt es auch gewisse Rahmenbedingungen, die die Übung behalten sollen. Also die Übung sollte vielleicht vier Wörter beinhalten. Die Übung sollte dann vielleicht nicht länger als fünf Minuten dauern. Also es gibt zu jedem Use Case gewisse Evals, die sehr deterministisch sind. Beispielsweise auch wieder wird das richtige Tool an der richtigen Stelle gecalled. Das sind alles Evals, die man sehr deterministisch machen kann. Es gibt aber in aller Regel auch immer noch ein paar, die es nicht sind. And this is then in the regard with Model Graders gemacht, also with LLM as a judge, beispiels. And that comes on that for me to enter welcome and welcome I then for rich empfinde. In the regime fängt man. In the regel fängt erstmal the menschic, also human annotation. That man of this fall linguists that output anschauen and gucken, okay, have you here the rich gelernt? Is this the rich word? And based on these human annotations, can man be all automatically these grader erstellen. That's shown so that I as many the anfang very genau draw schauen muss and for me definitely, what is rich and what is, what is a sonderfall. And based on dark, then often sold LLM Graders erstelled and then the prompts angepasted. Basierend darauf kann der Prompt wieder angepasst werden. Ich habe den Eindruck, dass sowas auf jeden Fall immer mehr verstanden wird, weil es auch immer mehr theoretische Ressourcen dafür gibt und Bücher beispielsweise. Die schnellsten sind wie immer, oder wie oft, die Startups und Digital Natives. Da wird dann meistens, wenn ein neues Feature erstellt wird, ein neuer Use Case, geht es direkt los mit A-B-Testing und dann sieht man das Ganze auch relativ schnell. Aber auch bei Large Enterprises is so, dass dort ja auch sehr wichtig ist, genau zu definieren, was denn gut ist und was nicht. Das heißt, da werden jeweils auch sehr gut aufgenommen. Jetzt noch ein Punkt zu deiner Fabi, zu deinem Thema. Es muss doch einfach sein, was ist richtig und was ist falsch. Es gibt auch use cases, wo es tatsächlich relativ einfach is. Also when we, when we use case categories, and then to number two gehen, to LLM Classifications zum Beispiel. Da gibt es ein Use Case, where many had between a tutor and a computer, and then will many new Wörter gelernt wurden, and then gives Infos zu diesen neuen Wörtern. Also there's a classifizierung am Ende. And by classifizierung, kennen wir wieder aus dem klassischen ML-Bereich, kann man sich dann relativ einfach wieder so ein Accuracy, Recall, Precision, F-1-Scores berechnen. Also manchmal ist es noch deterministisch, in den allermeisten Fällen ist es so ein bisschen eine Kombination.

SPEAKER_00 20:36

Und ich muss nochmal eine Verständnisfrage nachstellen. Ich glaube, ich habe es jetzt in der Theorie verstanden. Ich würde es aber gerne nochmal ein bisschen probieren, praktischer zu machen, was das jetzt genau wirklich bedeutet. Bei diesem Use Case, wir hatten, du hast jetzt gerade gemeint, es war ja eine Chat-Applikation, die am Ende nochmal ein, wie war es Lerninhalte, Recall am Ende macht, wo man sagt, wir stellen ein paar Fragen. Du hast jetzt gesagt, es gibt bestimmte jeweils, wie es sollen bestimmte Wörter drin, nur eine bestimmte Wortanzahl oder irgendwie Länge sein. Wenn ich mir das jetzt vorstelle, dieses am Ende wird nochmal fünf Minuten so, wir recappen das Ganze nochmal im Grunde genommen, wenn ich es mir jetzt vorstelle, ist das Ganze eigentlich erstmal nur ein Prompt, der irgendwie durch Input von vorher irgendwie jetzt definiert, wie soll das Ganze funktionieren. Und der kann entweder, der Output danach wird evaluiert nach sowas wie Output-Wortlänge oder sowas. Das kann ja dann Code gesteuert, wirklich einfach überprüft werden, wie war der Output des LLM so, dafür ist Code da und dann gibt es den LLM-Grader, der eher sowas wie, wie ist der Tone, wie ist die Qualität so, und da ist ein anderer Prompt, dem ich diesen LLM-Grader mitgebe und sage, hier achte auf folgende Dinge. So und so wie wird oder in welchem Prozess wird werden, also erstmal war das ungefähr richtig oder wo lag ich komplett falsch? Und dann, wie ist das in der Realität dann wirklich? Heißt das, ich habe diesen Prompt für erzeugt mir mal bitte das Quiz für das Ende, das schicke ich x mal in die OpenAI-API und lasse dann sowohl die Evals als auch den LLM-Grader durchlaufen und gucke dann einfach nur Nur stimmen alle und wenn nicht, probiere ich den Baseprompt wieder so anzupassen, dass sowohl Ewals als auch LLM Grader irgendwann happy damit sind. Also die Frage ist eigentlich, passiert das zur Laufzeit oder gucke ich mir das im Nachhinein an? Also erstmal, wie funktioniert das und dann wäre die nächste Frage, passiert das zur Laufzeit, mache ich das nur vorher, während der Laufzeit oder beides? Ja.

SPEAKER_03 22:20

Ist ungefähr richtig. Ich würde noch. Also ich will mir, ja genau.

SPEAKER_00 22:26

Ich korrigiere mich gerne, warum ähnlich als Öffentlichkeit zu sagen, ist das richtig. Korrigiere mich sehr gerne bei allem, was komplett falsch war. Teilweise. Ich muss dazu sagen, ich habe es, also wir nutzen, wir haben es ja bisher in Produktion, wir haben diese Use Cases bei uns nicht so. Deswegen würde es mich schon interessieren. Wir nutzen es ja schon. Korrigieren das so zumindest nicht.

SPEAKER_03 22:45

Also in diesem Fall, jetzt wenn wir bei diesem Use Case mal bleiben, finde ich nämlich ganz interessant, weil das eigentlich jetzt schon direkt so ein Multi-Step-Use Case ist. Wenn ich jetzt über Evales nachdenke, muss ich eigentlich schon mal viel weiter vorne anfangen. Ich muss zum Beispiel erstmal gucken, das war ja eine Konversation, und der erste Schritt ist ja, is my Transkript denn eigentlich richtig von der Konversation? Also ich muss ja eigentlich schon mal diese Konversation richtig auffangen. Ihr könnt euch vorstellen, wenn jetzt jemand eine neue Sprache lernt, sagen wir mal auf A1 oder A2 Level, dann können vielleicht solche Transkripte auch schon ein bisschen messy sein. Wie gucke ich überhaupt, wer ist Schüler, wer ist Tutor? Und also die erste E-Val ist schon mal die, dass überhaupt das Transkript richtig ist. Also und da gibt es dann eben schon mal Input-Evales, das ist ja dann nochmal ein bisschen komplizierter, weil es da einen Speech-to-Text-Anteil auch gibt. Aber das ist mal so Schritt 3.

SPEAKER_00 23:37

Aber weil der AI-Tutor ist auch ein Voice-Agent, also es ist kein textbasierter Tutor.

SPEAKER_03 23:41

Genau, das ist jetzt in dem Fall ein Voice Agent, genau. Schritt eins, Schritt zwei ist, dass man wirklich auch guckt, dass man die richtigen Learnings aus der Session dann auch aufnimmt. Das ist dann eben oft so, dass ich sag, hey, ich habe ein paar Transcripte und ich frage das LLM, was denkst du jetzt, welche Wörters sind jetzt die wichtigen, und dann wird dann oftmals das Ganze erstmal von einem Human Annotator von einem Linguist gegengecheckt. Is this rich oder falsch? So fängt man dann oft an. Da kann das LLM dann immer drauf passieren lernen. Also wir haben einmal das Transcript, we have the uh Have the rich learnings und dann noch die Übungsgenerierung. Und da kann natürlich auch wieder super viel mit reinspielen. Also wie soll so eine Übung ausschauen? Soll ich beispielsweise kommt auch noch drauf an, wie viel weiß ich denn über den Schuler, die Schülerin? Hat the schulerin diese Übung schon mal in their form, vielleicht vor zwei Tagen gehabt. Also da spielen dann solche Sachen wieder rein, wie zum Beispiel Memory, that ich das Ganze nochmal mehr personalisiere. Also alleine die Übungserstellung kann dann auch schon mal super kompliziert sein. Is die then pädagogisch wertvoll? Is when I just a new erkläre, das Erklären von diesem Wort macht überhaupt Sinn. Also das sind ganz viele verschiedene Teile. Also einmal Transcription Content, then gucken, dass ich die richtigen Learnings habe, dass ich die richtige Session erstelle, and then am Ende, auch noch super wichtig, was habe ich denn jetzt aus Geschäftssicht überhaupt für eine Idee, was am Ende aus diesem Use Case herauskommen soll? Also at evaluieren, hey, is jetzt denn the Schulerin dran geblieben? Oder waren jetzt zum Beispiel my lesson insights, my exercises so langweilig that the leute this show weggeklickt haben? We often, we often verwende ich es nochmal. Also jetzt allein by this use case is it doch a bit komplizier, weil there we are so viele, die man all einzeln evaluieren kann. And jetzt noch ich merke, ich give immer recht lange Antworten, also stopp mich dazwischen, aber ich wollte auf deine Frage eingehen, or auf beide, where you say, okay, mach man's dive or macht man. The answer is beides. When I just about evals have erstmal with evals in the entwickling. So before a use case live, I'm just gonna make sure evals offset, quality gates offset, and guess what even passed. Then we got the next shit, there's in other reasons, or often by Digital Natives an A B test, where we can with a user group tested. And that's funny, but live evals are in the reason not a bit complicated. Then I can actually not have this session then live with a linguist. This function is not. So, human annotation is per definition live to make it. That's live, I give two arts of events or monitoring. Ob es da irgendein Drift gibt. But this can many kleinen Satz machen. Also man kann das einfach nicht für alles machen. Und dann eben, einige der Grader sind zum Glück relativ automatisiert, deterministische Grader kann ich immer machen, dass ich die dann trotzdem noch für alle Live-Daten dann auch mache, um dann eben auch schnell zu monitoren, wenn dann irgendwas in Produktion nicht mehr klappt.

SPEAKER_01 27:32

Jetzt hast du angesprochen, Evales am allerwichtigsten auch schon während der Entwicklung. Das ist ja auch wieder so ein sehr nicht deterministischer Teil im Sinne von, wenn dich dein Projektmanager fragt, wie lange dauert es denn? So, was sagt man denen denn da? Also ich meine, es war früher schon schwer genug zu schätzen, wie viel Zeit man braucht, um Code zu schreiben. Jetzt muss ich auch noch schätzen lernen, wie viel Zeit mein LLM braucht, um zu lernen, dass da das Richtige rauskommt. Wie nähert ihr euch so Fragen?

SPEAKER_03 27:58

Ja, da kommt es auch wieder sehr stark drauf an, was es denn für ein Use Case ist. Ich habe auch sehr viele Konversationen mit Developern, die dann sagen, gib mir mal E-Wice Best Practices. Also wie müssen Evals aussehen? Und dann gibt es ja mittlerweile auch sehr viel Content dazu und da gibt es dann super Themen wie, ja, ihr braucht vielleicht, ihr braucht Hunderte an Datensätzen und da braucht ihr Training, Validierung und Testing und fünf LLMs as a charge. Und da bin ich dann mittlerweile auch ein bisschen vorsichtig, weil ja, das ist Best Practice, generell, aber ist es für jeden Use Case nötig? Meiner Meinung nach nein. Ich schaue mir das Ganze immer so ein bisschen an, natürlich erstmal nach Komplexität des Use Cases und auch nach Risiko des Use Cases. Also wenn ich jetzt natürlich ein Startup bin und ich habe ein Core AI-Produkt and das ist an alle Kunden ausgerollt, dann muss ich mir natürlich mehr Gedanken um E-Walles machen und so viel wie möglich E-Wailen. Wenn ich jetzt aber so einen internen Chatbot baue, der dann eben von ein paar Usern genutzt wird, dann muss ich da nicht auch noch irgendwie 20 Model Graders nebenbei laufen lassen. Und ich habe auch das Beispiel der Klassifikation genannt vorher. Der reizt dann am Ende oft auch, wenn ich einfach dann meine Accuracy oder meinen F1-Score habe und da muss ich mir gar keine Gedanken über Model Graders machen. Das heißt, es ist immer ein bisschen so ein schwieriges Thema, kommt sehr stark auf den Use Case an. Ich habe aber auch den Eindruck, dass gerade die Lernkurve bei Ivals immer mehr steigt und die Leute das auch mit Hilfe von Tools dann doch immer schneller machen können.

SPEAKER_01 29:38

Jetzt haben wir schon gehört, so, du hast ja dein LLM-Use Case am Laufen und um zu gucken, ob das wirklich richtig funktioniert, setzt doch noch ein paar LLMs nebendran, die das Ganze so überwachen können. Böse Zungen würden behaupten, das ist ja so ein vicious Cycle, um immer mehr Tokens zu verkaufen. Also gerade von, also wenn jetzt jemand hier von OpenAI sitzt und sagt, so ja, LLM, kein Problem, schmeißen noch mehr LLM dazu, für Geld machen wir alles, ja. Welche Rolle spielen denn Kosten in dieser Diskussion? Weil auch das ist ja so eine, wenn man da am Anfang drauf guckt, so eine große Unbekannte, ja, zu schauen, wie viel Kontext brauche ich da, wie groß ist mein Prompt, welche anderen nachgelagerten LLMs brauche ich vielleicht auch noch? Wie viel chatten die Leute wirklich? Ja, wie viel wird das angenommen? Im Ende ist das ja der allergrößte Hebel so, ne? Wie versucht ihr da am Anfang so einen so einen Näherungswert zu finden oder überhaupt erstmal so ein Verständnis dafür zu entwickeln?

SPEAKER_03 30:37

Ja, sehr guter Punkt. Ich habe jetzt vor allem bei Evals erstmal um, sag ich mal, Accuracy Evals gesprochen, also wie man guckt, ob der Use Case gut genug ist. Wenn ich aber mit Developern spreche, dann ist Accuracy eigentlich immer nur eine von drei Dimensionen. Die anderen zwei sind Kosten und oft auch Latenz. Also wenn man sich vorstellt, gerade im Customer Service Bereich, wenn ich da wirklich eine Konversation mit jemandem haben will, dann will ich keine zwei Sekunden Latenz, da könnten wir auch irgendwie keine gute Folge haben, wenn ihr euch das mal vorstellt. Bei anderen Use Cases natürlich ist Latenz wieder weniger ein Problem. Also manchmal, wenn ich so einen Long Running Agent habe, ich hatte letztes Mal einen Agenten laufen für eine Stunde, da ist mir das jetzt relativ egal, ob das jetzt irgendwie nur 50 Minuten dauert, aber Latenz ist auch noch ein großer Teil. Kosten absolut immer Teil, vor allem auch wieder in der Arbeit mit Startups and Digital Natives, weil die natürlich dieses Produkt an alle User ausrollen. Und wir sprechen da sehr oft über Skalierung. Das heißt, wenn wir es schaffen, unsere Modelle günstiger anzubieten, dann resultiert das eigentlich in den allermeisten Fällen wieder zu mehr Distribution. Also ich bringe da mal gerne das Beispiel, ich weiß nicht, ob man sich noch erinnern kann, aber 2023 hatten wir erstmals GPT-4 released. Das war wirklich eine relativ große Sache, war ein super Modell. War aber super, super teuer. Also war, wenn ich mich richtig erinnere, for 1 Million Output-Token, irgendwie 60 Dollar, 30 Dollar Input. We are seitdem for manche Modelle, zum Beispiel GPT5 Nano, auf 5 Cent for 1 Million Input Tokens. Also teilweise 99% reduction in cost of modellens, died. We have not an revenue eingeboot. And that's when we're costing, it is a punch. So geht es mirror, skalierbar zu machen. Dann wouldn't we anders reingehen? Dann würde ich sagen, hey, okay, du nimmst jetzt vielleicht GPD 5, hast du mal überlegt, GPD 5 Mini zu nehmen, hast mal überlegt, vielleicht Reasoning runterzustellen, um weniger Output-Token zu haben. Wie sieht euer Prompt-Caching aus? Schafft ihr es schon, dass ihr viel cached? Also da gibt es dann einige andere Hebel, die man da auch auf Kostenseite betätigen kann.

SPEAKER_00 33:16

Weil du gerade Caching angesprochen hast, kannst du mal probieren, dann in dem Zuge Kosten so Caching für Prompt so ein bisschen zu erklären, was genau wird da gecached.

SPEAKER_03 33:26

Genau. Also Caching finde ich persönlich immer super spannend, aber ich glaube, viele sehen es dann irgendwie doch so, als passiert eh und muss sich mir nicht viele Gedanken machen an. Vielleicht um ein bisschen Hintergrund zu geben. Wir haben bei GPT 4.0 beispielsweise. Ich glaube momentan, wenn ich mich noch richtig erinnere, sind wir da so bei Input-Token kostet irgendwie so 2,50 auf eine Million. Und Caching Rate oder Caching Discount ist da 50%. Das heißt, wenn ein Token gecached ist, kostet es 50% weniger. Wenn man das jetzt mit GPT-5.1 oder 5.2 vergleicht oder allgemein mit einer neuen Generation von Modellen, dann hat man da Caching-Discounts von 90%. Das heißt, Caching wird meines Erachtens immer wichtiger, weil das natürlich ein riesen Hebel ist, um Kosten zu sparen und übrigens auch die Latenz zu verbessern, weil gecached Token auch schneller funktionieren. Das heißt, wir haben wirklich Kunden, die da sehr technisch versiert sind, auch oft coding-startups. Die is caching eins der haupt themes. Weil wenn man es schafft, generell vielleicht so eine 80, 90% Cache-Hits zu haben, then is it a riesen Hebel for the kosten. And wie es funktioniert am Ende, also wie funktionieren LLMs, also man hat eben diesen Attention Layer und man schafft es dann eben, dass man gewisse Teile in Memory speichert und das deswegen für das LLM am Ende einfacher ist, wieder zu verwenden. Da spricht man dann eben so von ein paar Minuten, wo diese Token dann gespeichert werden. Und dadurch hat man eben diese Cache-Hits und die müssen nicht neu gerechnet werden. Und das merkt man teilweise eben schon sehr stark in den Kosten bei bestimmten Use Cases.

SPEAKER_01 35:13

Das heißt, sorry, ich muss nur zum Verständnis nochmal nachhalten. Ja, auch Verständnis, was ist denn aber dann, oder wie kann ich denn da Cache optimieren? Heißt das, ich muss mir das so ähnlich vorstellen wie in einem Multistep-Bild-Prozess, dass einfach von meinem Prompt immer nur der letzte Teil variieren darf und alles davor kann gecached werden, bis der Variable Teil kommt. Heißt das, ich kann das, es ist egal, wie sehr sich mein Prompt ändert, Hauptsache ein bestimmter Teil ist immer gleich. Also was wie kann ich das denn nutzen?

SPEAKER_00 35:43

Und auch, also ich ergänze da nur kurz, weil mir gar nicht ganz klar war, kriege ich Caching hin über verschiedene Kontexte, also im Endeffekt über verschiedene User oder ist Caching innerhalb eines Kontextes?

SPEAKER_03 35:54

Genau, also Fabi zu lange. Fabi, über beides. Und jetzt Jan, wie schaue ich mir das an? Du hast genau recht, also im Prinzip geht es bei Caching darum, dass die ersten Teile des Inputs potenziell die gleichen sind und dann wird Caching aktiviert. Und Fabi, das bedeutet eben bei einem Multiturn, klar, ist es so, weil natürlich der erste Teil immer wieder gleich ist. Wenn ich jetzt aber auch zwei User habe, die eine ähnliche Frage stellen, kann auch Caching aktiviert werden. Und jetzt geht es eben darum, erstmal ist Caching automatisch aktiviert, aber dann gibt es noch so ein paar technische Details, sage ich es mal. Beispielsweise gibt es potenziell die Möglichkeit, eine Cache-ID zu verwenden. Und die macht es dem LLM dann oft leichter, direkt mal User schon mal zu gruppieren. Und das ist dann eben, Fabi, genau bei so einem Use Case, wo du sagst, hey, du hast jetzt vielleicht ein Chatbot ausgerollt an sehr viele Nutzer, dann ist es immer noch nicht sichergestellt, dass jetzt Nutzer genau gerade in dieselbe Memory kommen und der Cache-Hit dann auch wirklich passiert. Und wenn ich da schon selber mit ein bisschen Vorwissen reingehe und das Ganze über IDs dann auch spezifiziere, kann das Beispiel, das ist jetzt ein Beispiel, nochmal in der Praxis zu mehr Cache-Hits führen.

SPEAKER_00 37:13

Okay, verstanden. Das heißt, das wäre einfach das heißt, weil du gerade das Beispiel meintest, mit zwei User stellen eine ähnliche Frage, dann ist man Hebel, um den Cache-Hits zu optimieren, eher so eine Cache-Gruppierung, als irgendwie zu sagen, okay, ich muss gucken, dass ich die Frage, vielleicht vorher nochmal durch ein kleines LLM-Schieber und die Frage genau gleich formuliere, damit der Prompt 1 zu 1, also dass ich das umschreibe, das ist jetzt nicht die Art, sondern eher zu sagen, ich probiere sie semantisch zu gruppieren und dann an die Instanzen zu kommen, wo wahrscheinlich der Memory noch da ist und dadurch ein Cache-Hit generieren kann. Richtig.

SPEAKER_03 37:44

Sollen wir in dem Zuge auch mal kurz allgemein über Kontext Engineering vielleicht sprechen?

SPEAKER_01 37:50

Das wäre jetzt nämlich meine Anschlussfrage, weil das klingt ja so, als würden gerade die Workflows davon profitieren, die halt mit so einem maximal großen Kontext auch schon anfangen. Also wenn ich jetzt hier mein kleines Podcasting-Tool, Fabi kennt, das hat es in der Demo gesehen letzte Woche, was uns hier in der Research so ein bisschen helfen soll, das fängt ja an mit allen unseren Dokumenten, die wir hier so in der Research irgendwie zusammensammeln, bevor überhaupt der erste Dialog sozusagen losgeht. Und das bleibt ja immer dieser Unterhaltung vorangestellt. Und wenn ich dafür jetzt schon mal, weiß ich nicht, 50.000 Tokens immer voranstelle, dann ist das ja das Paradebeispiel für Caching, oder? Weil das steht immer vorne und das ändert sich nicht mehr, auch wenn dann unten drunter noch ein bisschen kleine Unterhaltung dazukommt. Genau so ist es.

SPEAKER_03 38:34

Ja. Ich habe tatsächlich auch schon mal einen Kunden, die haben früher viel Rack gemacht, also Retrieval Augmented Generation. Ich hole mir etwas aus einer Knowledge Base und die haben dann gesagt, lohnt sich eigentlich gar nicht mehr, ich packe einfach direkt alles rein. Genau, richtig. Und wenn man vielleicht in der Richtung, ich glaube, ihr habt sie mich vorher anfangs schon genannt, dieses ganze Thema Kontext Engineering ist natürlich momentan eins der Hauptthemen, weil es da eben genau darum geht, dass ich ja zur richtigen Zeit die richtigen Informationen an das LLM geben will. Und da ist eben auch so, du hast es ja schon erwähnt, the system prompt is this, was immer gleich. Da habe ich meine Tool Definitions auch drin, alles immer gleich. And then hast du eben dynamischen Context. And that samels in the world. It's a multitude, then we have to go, or I have super few tool calls that context fill. And this is interesting, but there are a couple of arts of use cases. And you know Use Case, when I the context not überlade, or that I have a context lösche when the contextfenster voll is. Ich gehe einmal nur ganz kurz darauf ein. Also Beispiel, ich habe einen Chatbot, ich merke, der Kontext wird voll, was mache ich? Oder ich habe einen Longrunning Agent, passiert ganz oft beim Coding-Agenten, Kontext wird voll, was mache ich? Die einfachste Möglichkeit oder eine der einfachen ist, okay, ich schneide einfach die ersten Turns ab. Das macht Sinn, wenn du jetzt einen Chatbot hast, wo ich super viele Turns habe. Eine andere Möglichkeit ist, das ist vor allem bei, sag ich mal, Workflow Automations, wo viele Tools getriggert werden. Da spricht man momentan oft von Compaction. Das bedeutet, dass ich teilweise die Tool Calls oder den Output da deutlich kürze, weil der oftmals gar nicht gebraucht wird. Und das dann in diesen Fällen aber den Hauptteil des Kontexts ausmacht. Und dann gibt es noch die Möglichkeit, das sind vor allem so bei, sag ich mal, Concierge, Long Running Agents, dass ich, wenn ich am Ende bin, das Ganze zusammenfasse und dann weitermache. Und für alle diese Möglichkeiten gibt es für und wieder. Und je nach Use Case würde ich mich dann für eine der drei beispielsweise jetzt entscheiden.

SPEAKER_00 41:04

Und ich habe mir so gerade, ich bin gerade wieder zurück gedanklich zu dem Beispiel, mit dem wir gestartet sind. Also der Lern-App mit dem Voice-Agent, wo jetzt irgendwie meine Vorstellung wäre, dass der allgemeine Teil des Prompts, also ich gebe Kontext, der sozusagen für alle User gleich ist, wahrscheinlich im Verhältnis sehr viel weniger ausmacht, weil es so ein Multiturn ist, ich rede viel mit einem spezifischen Agent, dass es wirklich eher darum geht, so den Kontext möglichst lang gleich zu halten, dass halt immer nur Inkremente dazukommen und ich mache eher ein Caching auf User-Session-Ebene und dass ich gar nicht so viel davon profitiere, dass alle User mit dem gleichen Instruction anfangen, wie jetzt das Learning aufgebaut wird. Also da würde ich mir vorstellen, die cachen eher dahingehend, was wahrscheinlich aber so halt dem Prompt gleich und hängen nur hinten dran. Das vielleicht erstmal ist das richtig und dann für mich so die Frage, es würde jetzt erstmal in meinem Kopf aber trotzdem ein Use Case sein, der natürlich vielleicht in meinem Kopf schwieriger zu skalieren ist, weil halt mit mehr Usern dann trotzdem es schwieriger ist, die Casherate hochzuhalten und Caching einen kleineren Teil der Kostenoptimierung ausmacht, als wenn ich es hinbekomme, Caches über mehrere Sessions hinweg zu optimieren.

SPEAKER_01 42:09

Darf ich ganz kurz eine Gegenfrage stellen? Also wenn wir jetzt bei deinem Agent-Beispiel, äh, Support-Agent-Beispiel bleiben, macht es ja vielleicht mehr Sinn, die User so zu gruppieren nach Anfrage, mit der sie zu dir gekommen sind. Du hast, wenn du jetzt alle User, die zum Thema weiß nicht, Umtausch, Retouren, bla was fragen, die lässt du mit demselben Cache irgendwie starten, der halt schon geprimed ist zu was kosten Retouren, wie ist der Ablauf, bla bla bla. User, die Fragen zu Produkten haben, landen vielleicht in einem anderen Cache. Also du musst ja gar nicht vielleicht im Laufe des Gesprächs irgendwie da einsortieren, aber vielleicht kannst du den Startpunkt schon so ein bisschen aufteilen, indem du so ein, zwei schlaue Anfangsfragen stellst und dann quasi erst in den Flow startest. Richtig, genau.

SPEAKER_03 42:50

Das ist auf jeden Fall eine super Möglichkeit, das zu machen. Und auch zu deinem Thema, Fabi, das ist jetzt ein Use Case, der wahrscheinlich weniger vom Caching profitiert. Es muss auch nicht jeder Use Case Caching optimieren, das ist vielleicht auch noch ein wichtiges Thema. Also manchmal ist es so, es ist immer wieder der Trade-off zwischen, okay, Accuracy, Cost Latency, bin ich der Meinung, dass Caching die Kosten stark reduziert. Brauche ich das überhaupt? Wenn ich jetzt zum Beispiel so ein Tax-Based LLM habe, sind die ja eben oft schon relativ günstig, das ist vielleicht dann gar nicht so wichtig. Also es kommen wieder immer sehr stark auf den Use Case an, wie viel Arbeit ich da reinstecken will oder wie viel ich dann zum Beispiel eher dann in andere Themen reinstecke. Zum Beispiel will ich vielleicht irgendwie ein kleineres Modell, das dann mit dem Ganzen besser oder schneller klarkommt und auch günstiger klarkommt. Oder ich kann mir eben noch ein, zwei andere Stellschrauben dann anschauen.

SPEAKER_01 43:46

Um vielleicht den Bogen wieder zu schließen, wir haben ja angefangen, eigentlich, weil wir über Kosten sprechen wollten, dann sind wir bei Caching gelandet. Und die Frage eigentlich war ja eher so: wie nähert ihr euch ja diesem Kostenthema? Wie versucht ihr am Anfang von so einem Projekt rauszufinden, was. Das ungefähr kosten könnte, vielleicht. Und dann sind wir so ein bisschen abgerutscht. Deswegen nochmal die Frage: Wie versucht ihr das rauszufinden?

SPEAKER_03 44:08

Ja, das rauszufinden. Da gibt es natürlich so ein paar Standardfragen. Und die erste ist natürlich immer, was denkt denn der Anwender, wie viel Usage das Produkt haben wird? Also wenn ich jetzt zum Beispiel eine Learning App bin und sowas ausrollen will an alle User, dann habe ich ja beispielsweise X Lessons am Tag, dann weiß ich schon mal, das würde, da weiß ich es eigentlich super genau, wie oft das Ganze getriggert wird. Also einmal Volumen und dann natürlich Times Unit Costs am Ende. Also da schaue ich mir dann an, okay, wenn ich jetzt, ich fange meistens mal mit einem Flagship-Modell an. Also beispielsweise wäre es jetzt bei OpenAI heute dann oft GPT-5.2, das ja momentan so das Standardmodell ist für uns. Da weiß ich ja dann sehr genau, was das kostet. Und dann überlege ich mir noch so ein, zwei Themen wie, okay, brauche ich in dem Fall jetzt zum Beispiel Reasoning, ja oder nein. Weil in den Fällen, in denen ich Reasoning verwende, wird es natürlich schon auch direkt teurer, weil ja Reasoning Tokens am Ende Output-Tokens sind, die das Ganze teurer machen. In vielen Fällen, jetzt gerade bei Chatbots, Learning Apps, brauche ich aber möglicherweise gar kein Reasoning. Das heißt, da kann ich dann eigentlich relativ genau reingehen wie, hey, was sind jetzt Beispielfragen? Wie oft wird das Ganze getriggert? Mal Input Preis, Input-Token Preis, plus was ist jetzt ein Outcome, wie oft wird der getriggert, mal Output-Token Preis. Und dann kommt man, sag ich mal, schon relativ genau auf eine gute erste Schätzung. Plus, sorry, vergessen, wie viel denke ich zu cachen, natürlich. Haben wir gerade drüber gesprochen.

SPEAKER_01 45:51

Jetzt hast du schon den zweiten Schritt für mich vor dem ersten gemacht, weil du hast, naja, ich kann hier Usage mal Tokens und dann komme ich irgendwie schon auf meine Kosten. Aber ich muss ja überhaupt erstmal verstehen, wie viele Tokens ich überhaupt brauche, oder? Also das meinte ich so mit, wenn ich jetzt so einen Quiz da erstellen will oder so verstehen will, wie viele Tokens mein mein Tutor so irgendwie in so einer Session irgendwie verbraucht, erzeugt, wie auch immer. Wie findet sich sowas raus? Oder ergibt sich das einfach immer erst durch einen Prototyp und die Erfahrung aus der Praxis? Oder findet ihr trotzdem irgendwie so einen Näherungswert vorher?

SPEAKER_03 46:26

Ja. Also jetzt in diesem Beispiel habe ich ja schon mal sehr viele Transkripte. Also ich weiß ja zum Beispiel schon mal, ich habe jetzt hier eine Session, die hat jetzt vielleicht fünf Minuten gedauert, ich habe da ein Transkript, und ich weiß ja, wie viele Token beispielsweise alleine in diesem Transkript sind. Und dann habe ich ja, da muss ich erstmal gar nicht viel machen. Also wenn ich dann einfach mal so ein Transkript schon mal in ein LLM packe, mir das analysieren lasse, das ist dann wirklich nur so ein erster Durchstich, der sagt mir eigentlich ja schon sehr genau, was ich da an Input-Tokens und Output-Tokens erwarten kann. Also wirklich in vielen Fällen habe ich den Eindruck, ist sowas eigentlich relativ schnell klar.

SPEAKER_00 47:10

Weil dann doch so ist, dass man irgendwie dann die Unternehmen schon damit rumprobiert haben und irgendwie sowas wie mal ein Transkript und irgendwie so eine Session schon mal ausprobiert haben, ist es eigentlich eher so, dass Kostenfrage dann gestellt wird, wenn man mal probiert hat, funktioniert der Prototyp? Ist der mehrwertig? Sehen wir da drin was und dann kommt die Kostenfrage danach. Man stellt sie sich nicht an der Stelle, wo man denkt, ich könnte jetzt ein Chatbot bauen und so, aber jetzt muss ich erstmal wissen, was das kostet, bevor ich überhaupt ein Proof of Concept mache.

SPEAKER_03 47:33

Genau, und ich glaube gerade an der Kostenschraube kann man auf jeden Fall dann auch noch drehen. Also ich habe es ja schon erwähnt, es gibt dann oft die Möglichkeit, Minimodelle zu nutzen, beispielsweise. In manchen Fällen kann es dann so sein, dass die Minimodelle nicht gut genug sind. Da sind wir wieder in dem Fall, wir brauchen Evals, um das auch zu sehen. Aber es kann dann ja beispielsweise manchmal so sein, dass vielleicht die Minimodelle gut genug für gewisse Anwendungsfälle innerhalb des Use Cases sind. Ich kann zum Beispiel relativ einfache Anliegen haben und dann kann ich mir zum Beispiel solche Themen überlegen wie ein Model Routing, dass ich zum Beispiel gewisse Anliegen von einem Minimodell machen lassen kann, die dann wirklich um Faktor günstiger sind und die schwierigeren Anfragen dann an das schlauere LLM oder vielleicht an ein LLM mit mehr Reasoning schicke. Also da gibt es dann wirklich auch später noch sehr viele Möglichkeiten, wenn die Kosten des Problems sind, das Ganze anzupassen. Ich will auf ein Thema noch eingehen, Jan, weil du es vor ein paar Minuten schon gefragt hast, oder eingangs, als wir auf das Kostenthema gekommen sind, wo du meintest, ja, wir sagen ja, nutze LLMs und dann nutzt LLMs fürs Grading, sondern nutze noch mehr LLMs und dein LLM muss auch entscheiden, welcher Router da irgendwie genommen wird. Matrocken sind immer Land. Also jetzt aus der Praxis ist meine Meinung, dass LLM-Usage, jetzt im Grading oder in den E-Walls, meistens sehr gut genutzte Kosten sind und in der Regel auch nur ein Minimalteil der Gesamtkosten ausmachen. Also an den Evals zu sparen, da jetzt mal einen Call weniger zu machen, bin ich kein Advokat dafür.

SPEAKER_01 49:18

So war das auch gar nicht gemeint. Also und auch, auch wenn ich eben aus Spaß gedacht habe, auch im Router kann ja ein LLM durchaus sinnvoll sein. Kann ja auch ein kleines sein. Ja, also muss ja wahrscheinlich auch, damit es einfach performant ist am Ende des Tages auch. Und ich meinte das auch gar nicht so ketzerisch, sondern einfach eher so, ich glaube, man muss sich darüber bewusst sein, dass der LLM-Einsatz halt nicht mit dem einen Prompt irgendwie anfängt und aufhört, sondern da muss halt noch mehr drumherum passieren, damit es vom Ergebnis her am Ende schlüssig sein kann. Ja, und das LLM, das den Code überhaupt schreibt. Ja, das auch.

SPEAKER_00 49:51

Aber vielleicht, wir sind ja schon sehr weit in der Zeit irgendwie drin. Es sind ja schon ein paar Themen, die wir wahrscheinlich angehen wollen. Wir hatten, du hast ja die drei Dimensionen aufgemacht, ne, Accuracy und Costs, da sind wir jetzt so ein bisschen durch. Vielleicht kannst du trotzdem als dritten Punkt nochmal Latency aufmachen und uns erzählen, was sind denn da? Also klar, hast du ja schon erklärt, man will natürlich, dass die Antwortzeiten möglichst kurz sind, zumindest bei einem Chatbot, je nach Use Case, so aber was sind die Dimensionen, wie ich das optimieren kann, weil ich würde danach gerne schon nochmal auch aufs Thema so vielleicht Prompt Engineering versus Feintuning, also wie viel Arbeit steckt da drin, mein Prompt für meine Use Cases zu designen. Aber lass uns gerne erst nochmal vielleicht das Triumpirat aus Accuracy, Cost und Latency komplett machen.

SPEAKER_03 50:30

Ja, auf jeden Fall. Also Latency ist oftmals sehr stark korreliert mit Kosten auch. Also in der Regel ist es so, dass wenn ich zum Beispiel ein Minimodell verwende, das dann auch schneller ist. Ich kann mir aber auch, also bei der Latency ist es so, dass ich mir oft generelle Fragen über die Modellarchitektur stellen muss. Beispiel, ich habe ein LLM für eine Konversation. Da gibt es momentan so zwei unterschiedliche Wege, das zu machen. Es gibt so den traditionellen Ansatz, der früher oft gemacht wurde, der sogenannte Chained Approach. Ich habe ein Speech-to-Text, LLM, Text-to-Speech. Der neuere Ansatz ist quasi eine native Speech-to-Speech Experience. Das sind sogenannte Real-Time-Models, wo wir auch extra APIs dafür haben. Also Realtime-Modelle, die haben nicht mehr diesen verketteten Ansatz, sondern da kommt Sprache rein, Sprache raus. Ist viel schneller. Ist viel schneller, kostet in der Regel aber meistens mehr. Da ist dann nicht korreliert. Aber es gibt eben diese Ansatzpunkte. Einmal Modellarchitektur, kleinere Modelle, weniger Reasoning, weniger Output natürlich auch am Ende. Und auch wieder das Thema Caching ist natürlich da ein großer Teil. Und auch wieder das Thema Kontext Engineering. Also je weniger ich reinlade in den Kontext, desto schneller geht es dann auch wieder. Bei Latency ist es oft so, also wenn ich es jetzt mal vergleiche mit Accuracy und Kosten, Accuracy, man will es immer so gut wie möglich, kosten, so niedrig wie möglich. Latency ist am Ende eher so ein, sag ich mal, so ein Grenzwert, dass man sagt, es darf nicht länger dauern als X. Also es ist meistens dann eher noch so eine Randbedingung, die aber nicht oder oft nicht optimiert wird.

SPEAKER_00 52:25

Verstanden, okay. Und hast du, weil du vorhin zumindest meinst du, Caching kann auch in bestimmten Fällen bei bestimmten Modellen irgendwie bis zu 90% Kostenreduktion bedeuten? So hast du einen Punkt bei Latency, was da Caching irgendwie? Also irgendwie nur so vom Bauchgefühl her, so, was wir da an Latenzoptimierung haben? Da spricht man über deutlich weniger.

SPEAKER_03 52:46

Also Caching ist für die Latenz jetzt nicht der größte Faktor.

SPEAKER_00 52:51

Caching bleibt eher Kostenthema als Latenzthema. Cool, hast du noch Fragen zu dem Reatriumreaden, sonst wird mich schon nochmal Prompt Engineering und weil wir, genau, vielleicht kommen wir am Ende damit auch wieder zum Thema Accuracy so ein bisschen zurück, weil ich mich jetzt, wir haben uns viel darüber unterhalten, okay, Kontext, ich muss irgendwie, ab irgendwie Rack, ich habe meine Unternehmensinformationen da irgendwie drin, ich segmentiere vielleicht vor meine User, je nach Use Case so. Aber ich frage mich jetzt den Teil, wo jetzt wirklich die Instruktion, was das LLM machen soll. So wie viel, also vielleicht einerseits so, wie viel Prompt Engineering ist da zu tun? Wie ist so der typische Prozess von einem Prompt Engineering? Ist es dann doch eher Feintuning? Und auch wie versiert sind die Leute da draußen? Wie viel wird wirklich daran dann rumgedoktert? Also so wie dieses, das Prompt Engineering bei diesen Live-Applikationen, das würde mich schon interessieren. Und wie vielleicht, wie viel müsst ihr da auch unterstützen? So wie viel macht ihr da? Wie viel ist da Standard-Zet? Wie viel passt man das nochmal an, nachdem man einmal seinen Prompt definiert hat?

SPEAKER_03 53:48

Also ich würde sagen, wir unterstützen schon immer noch sehr viel im Prompt Engineering. Also ich glaube, jetzt auch nach drei Jahren ist das immer noch so ein Thema, wo sich Leute oft schwer tun. Und man fängt da meistens an, man fragt ChatGPT, hey, was ist ein guter Prompt? Und dann knallt man den in den System-Prompt und dann guckt man, was dabei rauskommt. Ist natürlich oft nicht optimal. Aber bei Prompt Engineering ist es selbst für mich noch teilweise hart, weil ich komme ja wirklich aus dieser so mathematischen, strukturierten Richtung und wirklich, Prompt Engineering ist dann mehr so fast schon so ein kreativer Prozess, wo sich dann selbst, genau, dann Mathematiker manchmal schwer tun. Was mir das sehr geholfen hat, sind wieder wirklich sehr klar definierte Evals, weil die einem schon sehr viel über den Prompt sagen. Jetzt gibt es da momentan sehr viele Trends zum Prompt Engineering. Beispiel automatisiertes Prompt Engineering. Also ihr kennt vielleicht irgendwie DSPi, da gibt es viele solche Packages, die optimieren das, basieren auf den Evals und haben da verschiedene Runs. Dann gibt es sogar noch Bestrebungen, vielleicht sowas automatisiert in Produktion zu machen. Da bin ich jetzt persönlich nicht der größte Fan davon. Optimierung, die Optimierung des Prompt-Produktion live. Ja, wenn irgendwas gesehen wird, wenn irgendwas gesehen wird, was jetzt wirklich komisch aussieht, kommt wieder auf den Use Case an. Ich bin gerade da beim Prompt Engineering am Anfang auch immer noch ein Fan, das manuell zu machen. Es gibt da so ein paar Standardsachen, die man eben immer beachten sollte. Also ich würde immer eben versuchen, die Tool Calls so gut wie möglich zu erklären, viele Beispiele mit reinzubringen, wie man sich in gewissen Situation verhalten soll, Beispiele-Outputs reinzugeben. Das ist schon mal so, wo ich auf jeden Fall damit anfangen würde. Und dann geht es eben wirklich auch darum, sich jeweils anzuschauen. Am Ende ist wirklich, glaube ich, der Hauptteil der Arbeit im Prompt Engineering. Oder ich nenne es mal lieber Kontext Engineering, weil eben Prompting dann ein Teil davon ist. Also wirklich zur richtigen Zeit die richtige Information, großer Teil ist der Prompt oder der System-Prompt, und daneben auch die richtigen Infos aus den Tool-Calls oder den Knowledge Bases.

SPEAKER_00 56:09

Ja, und aber habe ich eine Einland, wo du meintest, ich würde erstmal über die Evales nachdenken. Heißt das so, du würdest, mir kam direkt Test-Driven Development in den Sinn. Also das passt eher auch beim Prompt Engineering so, ich muss mir erst überlegen, was rauskommt, schreibe vielleicht dafür dann ein paar E-Walls und erst dann würde ich meinen Prompt schreiben, um dann zu gucken, dass ich dahin optimiere. Das heißt, ich würde nicht so, ich hätte es mir auch ein bisschen kreativer vorstellen können, zu sagen, ich sag's, ich probiere es meinen Prompt ein bisschen aus, schau mal, mach mal zehnmal, guck mal, was so rauskommt.

SPEAKER_03 56:34

Das ist voll okay. Also genau, am Anfang mal auszuprobieren und mit einem Prompt zu starten, ist voll okay. Ich würde aber schon versuchen, relativ früh dann wirklich auf das E-Wice-Driven-System-Design zu wechseln. Aber am Anfang mal Tests zu machen, verschiedene Prompts zu probieren, ist in den allermeisten Fällen natürlich gar kein Problem.

SPEAKER_00 56:54

Okay. Und vielleicht, wenn wir in meinem Kopf da, was das angeht, irgendwie noch den Begriff mal Feintuning auch nochmal mit reinwerfen, wenn du bei euren Kunden, wie ist denn so das, also gibt es da ein gutes Verständnis dafür, wann ich für ein Use Case einfach nur den richtigen Kontext und ein gutes Prompt Engineering brauche und wann ich vielleicht auch in Richtung Feintuning gehen muss? Also ist da erstens ein gutes Verständnis dafür da. Zweitens, wie ist so das Verhältnis und wie betrachtet ihr, oder wie sprecht ihr Empfehlung aus, welche Use Cases für was das Richtige sind?

SPEAKER_03 57:23

Feintuning ist ein spannendes Thema. Wir haben, ich schätze ungefähr vor zwei, drei Jahren, das war glaube ich, als GPT4 rausgekommen ist und sehr teuer war, hatten damals viele Kunden überlegt, brauche ich wirklich GPD4 oder reicht mir GPT 3.5? Oft war die Antwort, performt irgendwie nicht so gut. Und dann war die Idee, lass es doch mal auf unseren Daten Feintunen. Das heißt, vor zwei, drei Jahren haben wir in der Tat sehr viel mit unseren Kunden gefeintuned. Die vorrangigen Feintuning-Methoden damals waren, ich hieß damals Supervised Feintuning. Das bedeutet, ich bringe da Beispiele, wie sollte etwas aussehen soll. Ich habe da eben so Frage-Antwort-Pärchen, and my LLM lernt dann basierend darauf. We have viele Kunden that sowas he in production have not GBD3. But this art of fine-tuning can immerse sinful sein for classification, where you have in a machine learning problem the Beispiele. Supervised fine-tuning function not with reasoning modellen. That's why we had then a new art of fine-tuning. Reinforcement fine-tuning function with reasoning modellen, while many grader defined. That was that you have not a reasoning model, but you have a reasoning model that violent erstmal reasoned, then you have a tool called, then there's a reasoning, then there's a tool call or one, then there's a knowledge retrieval, so was super share to fine-tune, where these tool calls must be evaluated. But tool calls heutzutage. Das war jetzt mal kurz, sorry, jetzt habe ich ein bisschen ausgeholt, aber zur Geschichte von Feintuning. So, und jetzt zur Frage, soll man denn Feintunen oder nicht? Mein Eindruck ist, Feintuning ist ein sexy Thema, jeder will feintunen, jeder fragt die ganze Zeit. Also ich werde sehr oft über Feintuning gefragt. In 2026, oh, it's jetzt vielleicht eine bold prediction, ich bin mir nicht sicher, aber ich glaube, dass einfach Feintuning immer weniger ein Thema wird, weil es einfach immer mehr Model-Releases gibt, die dann einfach schon besser sind als das alte, gefeintunte Modell. Und das Problem am Feintuning ist ja, man muss es ja dann auch immer wieder neu feintunen. Das heißt, ich sehe neue Feintuning-Use Cases immer weniger jetzt von verglichen von vor zwei Jahren, sage ich mal.

SPEAKER_00 1:01:14

Und kannst du, also Prediction, wir haben ja am Ende des Jahres mal einen kleinen Recap, können wir mal schauen, ob das dann funktioniert, einfach dazu fragen, ob der ein Take stimmt, übrigens immer am Ende des Jahres, unsere Anfangsjahres-Predictions nochmal zu rekapitulieren, zu schauen, haben die zugetroffen. Da fragen wir dich vielleicht auch nochmal und lassen vielleicht einen Gastbeitrag einspielen in unserem AI-Recap. Kannst du mir nur nochmal den, also ich habe, konnte allen den Reinforcement Fine-Tuning auch verstehen. Kannst du nochmal zwei Sätze zu diesem Agent Reinforcement Fine-Tuning erzählen? Weil da habe ich nicht ganz verstanden, was das genau bedeuten wird. Auch wenn es in diesem Jahr, am Ende des Jahres kein Thema mehr sein wird. Jetzt wollen wir es vielleicht nochmal kurz erklären.

SPEAKER_03 1:01:52

Genau, also das Hauptproblem of Reinforcement Fine-Tuning war, dass jetzt die neuen Modelle oder die neuen Use Cases. This reasoning model had also the microphone, so many tools to call, that fine-tuning environment can. They can a process trigger, they can run, they can very much reinforcement fine-tuning, so we anfangs were a message to what to do. It got this scenario to test and then to graden. And Agent RFT is an environment of RFT, which employed such scenarios, then to evaluate. Under ist es ja momentan so, dass natürlich immer mal Tools hinzugefügt werden, Tools wegkommen. Das heißt, da müsste ich eigentlich auch jedes Mal wieder ein neues Feintuning starten.

SPEAKER_00 1:04:47

Okay. Verstanden. Jetzt, wenn wir auf die Zeit blicken. Erstmal Jan, hast du noch Themen, die du auf jeden Fall gerne noch spacken wollen würdest. Dann würde ich vielleicht gerne nochmal, weil wir uns am Anfang über die, ich haben wir drei Use Cases ja so ein bisschen unterhalten haben, ne, Chatbot, über Klassifizierung und Agents. Und wir haben jetzt am Ende gar nicht mehr so viel über Agents gesprochen. Vielleicht deswegen noch so die allgemeine Frage, so die Dinge, die wir jetzt besprochen haben. Welche zusätzlichen Probleme bringen Agents in Production irgendwie noch mit? Irgendwas, was wir gar nicht jetzt beackert haben, weil es ja schon am Ende ein bisschen andere Anwendungsfälle sind, als wir jetzt oftmals beispielhaft besprochen haben. Willst du sagen, da ist noch irgendwie ein Bereich, den wir jetzt da in dem Zuge noch gar nicht betrachtet haben? Sind es nochmal andere Probleme, die eure Kunden haben, die dann Agents in Production entwickeln? Habe ich dich ein bisschen offen gefragt.

SPEAKER_03 1:05:43

Ja, also ich würde auf jeden Fall sagen, dass Agents zum Beispiel deutlich schwerer zu evaluieren sind als Chatbots, weil man eben nicht mehr dieses Frage-Antwort Spiel hat.

SPEAKER_00 1:05:57

Das gleiche bei dem Feintuning. Sozusagen nicht die gleiche Probleme.

SPEAKER_03 1:06:01

Genau, sondern wieder Workflow Automation. Das heißt, ich muss irgendwie sicherstellen, dass das Ganze dann auch gut funktioniert. Und habe da vielleicht auch wieder eine bestimmte Umgebung, in der das Ganze gemacht wird. Also, gerade dieses ganze Evals-Thema, habe ich gefühlt wurde jetzt recht gut verstanden im klassischen Chatbot-Kontext. Aber so die nächste Welle, die auf uns zurollt, mit den ganzen Agents, die da munter in Produktion gebracht werden, teilweise geht das ja auch super schnell, ist wirklich, wie stellen wir sicher, dass wir solche Agenten dann auch in Produktion gut evaluieren. Und da ist es, glaube ich, auch schwieriger, Standards zu finden, weil auch jeder Agent natürlich eigentlich eine komplett andere Aufgabe haben kann.

SPEAKER_00 1:06:45

Okay, verstanden. Und vielleicht nochmal eine letzte Frage hin zur Umsetzung, wenn wir uns über Ewals und Grader unterhalten haben, wie ist es denn in der Realität, wenn man jetzt das Ganze mit euch, mit OpenAI und eurer API machen will? Ist das am Ende was, diese Ewals und Grader, etwas, was wirklich einfach auf meiner Infrastruktur läuft? Oder ist es etwas, was ich auch auf eurer Seite definieren kann, ihr sozusagen das irgendwie für mich übernehmt? Wie ist es wirklich jetzt in mache ich das?

SPEAKER_03 1:07:11

Wir haben eine API-Plattform, das heißt, wir haben natürlich eine gewisse Anzahl an Modellen und man kann auch auf unserer Plattform feintunen und unsere eigene E-Walls-API nutzen, auch eine E-Walls-Plattform. Uns ist es aber tatsächlich relativ, also egal, wo die E-Vals gemacht werden. Man kann genauso andere Tools finden, also es gibt ja da Langsmith, Promptfu, es gibt auch andere Möglichkeiten, E-Walls zu machen. Uns ist immer noch wichtig, dass sie gemacht werden. Und ich glaube so, der Grund, warum wir auch unsere Evals-Plattform released haben, ist, weil wir immer noch gesehen haben, dass es einfach oftmals noch ein Problem ist und das Bottleneck ist. Das heißt, wir wollten eben auch eine Möglichkeit, dass man auf unser Plattform Evales machen kann. Aber wie gesagt, ob man es jetzt, wo man es jetzt macht, ist jetzt eigentlich zweitrangig, weil am Ende ist es dann auch technisch nicht super kompliziert, so einen LLM-Grader zu erstellen.

SPEAKER_00 1:08:10

Okay, vielen Dank. Dann haben wir jetzt noch für unsere Folge zwei Housekeeping-Sachen, sag ich mal, zu tun. Das ist nicht Housekeeping, aber Dinge, die wir immer tun. Zuerst die letzte Frage mit, haben wir irgendeine Frage, wo du dachtest, so warum haben Jan und Fabi die nicht gestellt? Wenn wir uns über AI in Production unterhalten, das wäre doch eine Frage gewesen, bei der hätten wir uns jetzt noch gut austauschen können sollen. Also gibt es irgendeine Frage, die du gerne hättest, dass wir sie dir gestellt hätten?

SPEAKER_03 1:08:37

Also ich würde sagen, technisch haben wir, glaube ich, das Wichtigste mal behandelt. Ich will vielleicht noch eine Sache sagen zum Standort Deutschland und so wie technisch die Leute auch sind. Ich habe den Eindruck, dass wir momentan wirklich sehr viele gute Sachen machen. Also man sieht das wirklich. Ich bin sehr oft auf Hackathons, wo ich dann viel mit Studierenden mache, die dann unsere API verwenden. Deutschland ist einer der größten Developer-Märkte. Ich sag das, weil ich tatsächlich oft die Frage gestellt bekomme, wie läuft es mit Deutschland und sind wir denn da alles so hinterher und es ist ja alles katastrophal. Ich habe den Eindruck jetzt vor allem in den letzten Monaten und jetzt wirklich im AI-Bereich, Startups-Bereich, Developer-Bereich, machen wir da wirklich, wirklich super viele gute Sachen, haben da super Startups auch und müssen uns da technisch auf jeden Fall gar nicht verstecken.

SPEAKER_00 1:09:33

Das ist doch schön, so ein schönes Statement fürs Ende. Damit hören wir gerne. Ich dachte, das schon alles gemacht hat auch mit Deutschland, oh, jetzt will ich am Ende wirklich nochmal alle in die Pfanne hauen, aber ist doch nicht. So rum sehr viel besser. Cool, dann kommen wir zu unserem letzten Thema und zwar den Pick of the Days. Haben wir dann einen Spieler Jan? Schon lange nicht mehr gemacht. Die Pick of the Days, drei persönlichen Podcast, drei Pick of the Days. Jan, hast uns das mitgebracht?

SPEAKER_01 1:10:15

Ich hab einen Pick und eine kleine Anekdote, die ich ja auch irgendwie gut reinpasse, deswegen haue ich jetzt noch einmal kurz raus, weil wir auch über Real-Time-Chatbots und Agents sowas alles gesprochen haben. Ich habe letzte Woche mit dem Callcenter der Lufthansa telefoniert und hab nach zehn Sekunden gemerkt, dass ich nicht mit einem Menschenrede, sondern eben mit einem Voice-Bot. Und weil Max ja auch das Thema Latenz angesprochen hat, der muss natürlich immer so ein bisschen nachdenken, wenn dann so meine Antwort kam. Und was sie dann in der Zeit gemacht hat, war ultra cool und ein bisschen creepy. Sie hat nämlich immer so gesagt, ja, Moment, ich schaue das im System nach und hast du so einen Tastaturklackern gehört. Ja, ja. Also das ist so, das ist so das Human-Behavior-Äquivalent von so Schleomorphism. Du ahmst irgendwie menschliches Verhalten nach, um irgendwie sowas zu überbrücken und was zu implizieren, fand ich mega lustig. Nach fünf Loops hat es mich ein bisschen genervt, weil es halt auch immer genau dasselbe Tastaturklakern war. Also wenn du mal dieses Audio-Loop dann so einmal gehört hast, dann war es auch irgendwie ein bisschen witzlos. Aber ich fand die Karte. Darf ich da kurz einhaken? Ja, gerne.

SPEAKER_03 1:11:23

Ich finde es super spannend, weil der Grund oder das ist technisch wieder sehr spannend. Die Real-Time-Modelle haben natürlich eine super niedrige Latenz. Das Problem ist nur, dass ja manchmal eben ein Toolcoil gemacht wird. Aber das Ding ist, dass der Kunde, die Kunden ja auch das Ganze manchmal erwartet. Das heißt, ich erwarte ja nicht, wenn etwas nachgeguckt wird, dass direkt eine Antwort kommt. Das heißt, oft hat man da so eine Voice-Supervisor-Architecture, wo man dann etwas, ein anderes LLM gibt, aber dann währenddessen sagt: So, let me check for you, let me have a look, and then diese Klimbare einmacht.

SPEAKER_00 1:11:59

Manchmal würde man es sogar einbauen, noch wenn man direkt eine Antwort geben könnte, weil die Leute es erwarten. Ich muss jetzt hier warten. Ich muss es verzögern.

SPEAKER_01 1:12:06

Okay, also das nur die kleine AI-Anekdote am Rand. Meine Fix, die ich mitgebracht habe, sind, ich habe mich ja letzte Woche hier bei unserem Fortbildungstag viel mit lokaler AI beschäftigt und was da so geht. Und habe jetzt einfach mal so eine Kombi mit am Start. Und zwar habe ich ja für unser Projekt einmal Local Transcription mit Apple Intelligence gemacht. Das ist ganz cool, das kann ich nur empfehlen. Das ist auch sehr performant. Und tatsächlich auch für unseren Use Case, wo er doch auch so deutsches und englisches Vokabular öfter mal gemischt hier vorkommt in den Folgen, hat das sehr gut funktioniert. Und für die weitere Verarbeitung, weil das eben auch latenzkritisch war, habe ich das auch lokal gemacht mit O Lama. Da kann man mit ein paar verschiedenen Modellen rumexperimentieren. Ich habe Lama, Gwen und GPT-OSS genommen. Alle im Prinzip gleichermaßen wertvoll. Latenz auch in dem Fall eher so, weil ich die Netzwerklatenz aussparen musste und nicht unbedingt die LLM-Latenz und weil wir hier ja alle so dicke, weiß ich nicht, was du da hast, VWM4, Max Pro Ultra, schieß mich tot. Aber das läuft ja auch alles bei uns sogar ganz gut. Könnte ein GPT-Name sein. Ja, schieß mich tot. Ja, deswegen das Nummer, schaut euch das mal an, das ist ganz cool, da kann man coole Sachen mitmachen. Vielleicht erzählen wir irgendwann mal noch ein bisschen mehr, was wir damit gemacht haben.

SPEAKER_00 1:13:34

Ja, cool. Also für mich waren es sehr viele Picks und noch eine Anekdote. So, ich habe jetzt nicht mitgezählt, aber. Das ist egal, ich muss ja am Ende ins CMS schmeißen, von daher darf ich das. Dann ich halte es ein bisschen simpler mit meinem Pick of the Day. So, vielleicht auch ein Tool draußen, was schon viele von euch nutzen, aber ich nehme es mal als Pick, weil ich es jetzt in letzter Zeit sehr viel aktiver genutzt habe. Und zwar sind es Weavi AI als auch Comfi UI, was so ein bisschen ja ein Node-basiertes Tool ist, um mit Generative AI zu arbeiten. Und ich einfach ganz interessant, weil ich vorher, also klar, ich kannte die Tools, habe sie selbst noch nicht so viel eingesetzt, aber so gerade, wir nutzen es viel für Image Generation und Image Generation Pipelines aufzubauen, die wir sozusagen nicht dann in Produktion on the fly generieren, sondern eher für die Produktions-Apps, für unsere Produktionsgames halt eher etwas kreativer nutzen und dass man wirklich beides Tools, wo ich sagen muss, so Comfi ein bisschen technischer, vielleicht ein bisschen besser hin zur Automatisierung, ein bisschen mehr verschiedene oder man kann einfacher verschiedene Modelle anbinden. Weavy ist da ein bisschen mehr End-User und auch Designer fokussiert, aber trotzdem für mich als Developer, als auch Product Manager Weavy auch ein sehr, sehr gutes Tool, was einen guten Grundstock an möglichen Nodes, was man so für Image-Generierung als auch Videogenerierung braucht. Beides sehr coole Tools. Ich denke nicht das Nischenthema, nie Dinge, die ihr noch nie gehört habt, aber nochmal die Empfehlung, so gerade wenn ihr in Richtung Image Generation und das sozusagen nicht skaliert, sondern nur vereinzelt nutzen wollt. Sehr coole Tools. Dann, Max, hast du uns auch ein Pick of the Day mitgebracht?

SPEAKER_03 1:15:03

Ja, ich hab den, ich hab's gesagt kurz im Vorgespräch, ich hab den nochmal spontan umgeändert, weil ich gestern noch die eure neueste Episode über Coding Agents mit Julia Kordeck gehört habe.

SPEAKER_01 1:15:20

Nein, das war okay, es war okay.

SPEAKER_03 1:15:21

Mal gucken, ob sie die Hörer mal gucken, ob sie die Hörer checken. Jan Fabi, wer hatte das Vibecoding-Book als? Ich hab das mitgenommen. Genau, und das fand ich so gut. Ich kenne das Buch auch und ich kenne vor allem die Autoren und den Steve Jeggi. Also ich rate allen, die sich den, wenn man sich den noch nicht angesehen hat, guckt euch mal ein paar YouTube-Videos an oder auch, der war im Makerspace Podcast vor kurzem. And had a sehr starke Meinung auch, aber ich finde ihn einfach super witzig und super cooles Buch. Und das hat mich jetzt dazu inspiriert, einfach mal noch ein paar Bücher zum ganzen Thema Evals zu nennen. Also, Vibecoding Book is good is good. Es gibt im Evals-Bereich noch nicht so viel, tatsächlich, aber ich glaube zwei gute, die man auf jeden Fall nennen kann. Und dann gibt es noch eins, das habe ich noch nicht gelesen, but I have good gear. This is AI Engineering heißt das. This is von, jetzt muss ich nochmal gucken, von wem this Chipien. Die zwei sind auf jeden Fall sehr gut. And then generell, I'm a book that means zu LLMs generally. This is Build an LLM from Scratch and Neuerdings Build a Reasoning LLM. Von einem Deutschen tatsächlich, Sebastian Raschka, der in den USA lived. Die fand ich sehr gut. And this are Bücher, die sind nicht super kompliziert und wird eben sehr gut einmal Basics zu LLMs erklärt und dann eben natürlich auch das ganze Eva als Thema.

SPEAKER_00 1:17:00

Ja, sehr cool. Das sind doch viele coole Pick of the Days. Hieranwöhnen Spaß haben die alle ins CMS eigentlich schon mal mitgespielt. Sehr gut. Gehen wir hin. Herr Max, dann bleibt uns nur noch. Vielen Dank zu sagen. Danke, dass du dir die Zeit genommen hast und mit uns über AI in Production geredet hast. Ich glaube, das war eine sehr, sehr wertvolle Folge. Hat viel Spaß gemacht. Vielen, vielen Dank, dass du da warst. Tausend Dank. Gerne. Und dann auch euch. Vielen Dank fürs Zuhören. Wie immer gerne Feedback an Podcasts at programmierbar oder über unseren Discord-Channel. Und bis zum nächsten Mal. Macht's gut. Ciao.