Deep Dive 203 –

AI in Production mit Maximilian Hudlberger

17.03.2026

// Podcast
// Deep Dive 203

Shownotes

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.

Download

/transkript/programmierbar/deep-dive-203-ai-in-production-mit-maximilian-hudlberger

Fabi: Hallo und herzlich willkommen zu einem neuen Deep Dive hier in der programmier.bar. Mein Name ist Fabi Fink und mit mir im Studio ist der liebe
Jan: Jan. Moin moin.
Fabi: Hi Jan. Wir wollen heute über AI in Production reden und ist ja ein weit gefasstes Himmel. Wir haben uns jemand eingeladen, der da ganz genau weiß, worum's da geht. Wir haben den lieben Max Nudelberger bei OpenAI, also im Grunde genommen kümmert er sich darum und redet mit den kleinen Start ups als auch den großen Enterprises und er redet darüber, wie die OpenAI API integriert wird, also wie AI in diesem Fall dann eingesetzt wird. War vorher Lead Data Scientist bei Data Robot, war bei der Allianz und PwC und Max, wir sind sehr froh, dass Du heute hier bist. Hallo, herzlich willkommen in der programmier.bar.
Maximilian: Hi Fabi, hi Jan, freu mich, hier zu sein.
Fabi: Wir freuen uns auch. Wenn wir über AI in Production reden, ich hab grad vorhin schon mit dem Jan im Vorgespräch 'n bisschen drüber geredet, eigentlich glaub ich so für die unsere Hörer da draußen, das ist glaub ich am greifbarsten, wenn wir erst mal, bevor wir irgendwie über die Probleme reden und auf was man irgendwie achten muss, ich kann's uns erst mal son bisschen erzählen, was sind denn so AI in Use Cases, mit denen die Leute so zu dir, zu euch, zu kommen so? Würdest Du sagen, da gibt's schon zu pattern, ist das superunterschiedlich so? Was was sind die, gibt es typische Use Cases? Vielleicht auch Unterschiede nach, was machen die kleinen, was machen die großen so? Was sind, über was unterhält man sich da, wenn man zu dir kommt?
Maximilian: Ja. Da gibt's auf jeden Fall Patterns. Du hast ja eingangs schon erwähnt, wir arbeiten mit Large Enterprise zusammen, aber auch Start ups oder. Ich darf von allem so ein bisschen sehen. Und die unterscheiden sich da manchmal, aber oftmals sind's auch dieselben. Wenn wir jetzt über AI Use Cases sprechen, dann muss man erst mal sagen, AI Use Cases nach ChatGPT schauen ja teilweise auch 'n bisschen anders aus, als sie davor ausgesehen haben. Also ich komm ja noch aus 'ner Zeit, ich hab son bisschen im klassischen angefangen. Da waren AI Use Cases in der Regel ja noch für iOS oft, ne. Also da kamen dann zum Beispiel die Banken, Versicherer, Hedgefonds und haben dann Prognosemodelle erstellt oder Modelle heutzutage. Und vor allem jetzt bei sind natürlich viele der, 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 fang 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, ne. So haben dann viele Unternehmen angefangen vor, ja, 3 Jahren, 2, 3 Jahren. Da hat man sich gesagt, super, wir haben jetzt einen Chatbot. Wir müssen das Ganze jetzt mit unseren Unternehmensdaten anreichern und wollen dahin gute Antworten bekommen. Ist so der erste sehr klassische Use Case, würd ich sagen. Die zweite Kategorie würd ich immer noch sehen als klassische oder LLM Anwendungen für eigentlich klassische m l use Cases. Da geht's dann oft so Themen wie Klassifizierung, eine Einteilung von verschiedenen Kategorien. Das gibt's schon auch noch. Und dann aber der 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 sprech, können wir wahrscheinlich auch später noch mehr drüber sprechen, dann sind das eben vor allem Use Cases, in denen Multiturnen und Multitstep reasoning erfolgt. Das bedeutet, ich hab vielleicht einen Agenten, ich chatte oftmals gar nicht mehr mit dem Agenten, sondern geborene eine Aufgabe an den Agenten. Und der Agent fängt dann vielleicht mal mit 'nem an, dann gibt's mal einen Tool Call, dann gibt's vielleicht noch 'n weites, 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, glaub ich, so 3 Anwendungen, die man einfach momentan sehr häufig sieht.
Fabi: Cool, ich glaub, das ist 'n sehr guter Eindruck. Und ich glaube, also glaub ich, kann sich da draußen jeder was drunter vorstellen, so den ersten Use Case, denk auch Klassifizierung. Vielleicht bei, kannst Du noch 2 Sätze zu dem Agent Use Case verlieren? Weil ich glaube jetzt, wenn man unsere Developer Brille auch setzt, ich glaub, wenn hier auch unsere Zuhörer irgendwie über nachdenken, sind es meistens irgendwie im Coding Kontext, heißt die Aufgabe ist meistens Ja. So. Und wie ist das jetzt bei dir, die Kunden, die da kommen? So was was sind diese? Vielleicht also hast Du Beispiele außerhalb von Coding oder ist Coding sogar gar kein Thema bei den Unternehmen, die zu dir kommen? Also was kannst Du da Beispiele nennen?
Maximilian: 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, ne. Also die dieser Welt, die verwenden natürlich Gentic Coding vor allem. Wir machen's natürlich auch selber mit Kodex, habt ihr wahrscheinlich auch schon davon gehört. Aber andere klassische, vielleicht ein Beispiel wär jetzt ein AI Trip Planner. Also wenn man sich jetzt zum Beispiel Booking dot com anschaut, dann gibt's da eben die Möglichkeit, dass man vielleicht einen Trip plant. Und jetzt kann's ja 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 Problem haben mit 1 Reise. Ich möcht gern vielleicht eine neue Reise buchen. Ich will vielleicht 'n bestimmten Sitzblatt. Also ich kann ganz viel verschiedene Probleme haben. Und je nach Problem können dann eben verschiedene Workflows auch getriggert werden, ja. Oder jetzt zum Beispiel bei Telekommunikationsunternehmen, wenn man da jetzt zum Beispiel Customer Service Use Cases hat, kann's eben auch sein, dass eben der eine Kunde vielleicht 'n Problem mit der Rechnung hat, der andere Kunde vielleicht Probleme oder 'n neuen Vertrag abschließen will. Das heißt, bei solchen Useric 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 chatnah 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 superviele Workflows gibt, die man komplett mit Agenten abbilden kann. Oder zum Beispiel im Knowledge Work. Also ich kann zum Beispiel, ich bin vielleicht ein ein Unternehmen oder ein Research Unternehmen und ich will zum Beispiel für jetzt hab 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, die dann zwischendrin mal kurz innehalten, gucken, okay, wo lieg ich denn jetzt eigentlich grad? Welches Tool muss ich als Nächstes Call oder muss ich vielleicht direkt an einen anderen Agenten abgeben?
Jan: Und wenn die Leute zu euch kommen, egal ob jetzt großes Enterprise oder kleines Start-up, 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 son bisschen Expectation Management betreiben und sagen so, ja, das da sind wir jetzt vielleicht noch nicht oder lass mal hier im mit 'nem MBP 2 Schritte kleiner starten oder ist das meistens schon so Blueprint fertig und ihr seid da eigentlich eher dann nur noch son Implementierungspartner?
Maximilian: Ja, sehr gute Frage. Das kann tatsächlich sehr unterschiedlich sein. Ich fang mal mit Large Enterprise an. Da ist, denk 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. Grade im Bereich ist es ja oftmals vielleicht auch gar nicht so leicht, mal einen Use Case live zu bringen. Da gibt's eben noch verschiedene Abteilungen, die da vielleicht dranhängen. Wenn ich jetzt aber mal Richtung Start ups geh und, dann haben die eigentlich einen sehr genauen Plan von Use Cases, die sie umsetzen wollen. Also die Arbeit mit Start ups ist oftmals sehr unterschiedlich. Da muss ich jetzt nicht ankommen und denen erklären, was für Use Cases Sie da gern machen wollen, sondern son Start-up, 'n AI Start-up, mit denen wir dann eben vor allen Dingen verarbeiten, die kennen ihren Use Case sehr genau und die wollen dann unsere Hilfe, dann wirklich deren Use Case so skalierbar wie möglich zu machen. Also für son Start-up, da können wir später auch über 'n paar Beispiele sprechen, aber wenn's jetzt, wenn man jetzt zum Beispiel mal deutsche Start ups ansieht wie zum Beispiel im Customer Service, da muss ich denen ja nicht erklären, wie Service funktioniert, sondern dann wollen die natürlich wirklich so effizient und so gut wie möglich auf unsere API den bauen. Und wir, glaub, sprechen nachher auch noch mal vielleicht so bissel, was denn jetzt so gut und so effizient wie möglich heißt.
Jan: Als ich früher im Consulting gearbeitet hab, war ja so 1 der oder die die meisten Projekte, die ankommen, sind immer so, ja, wir haben hier was, das ist irgendwie in 'nem Excel Sheet oder in irgend 'ner Access Datenbank, wir würden das gerne in eigene Software gießen, ja. Ich stell 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, 2 Mitarbeitern vielleicht irgendwie lebt. Wie viel Kontext, Aufarbeitung müsst ihr da betreiben, bevor ihr wirklich an die Entwicklung gehen könnt?
Maximilian: Ja. Also das Problem, das Du beschreibst, ist real, öfter auch wieder im Enterprise Kontext gesehen. Wenn wir jetzt mit und Start ups 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 Bereich gibt's 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 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 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 glaub, das war ja auch son bissel der Grund, ich weiß nicht, wie ihr das seht, dass ja grad die diese Rolle des ist ja noch mal sehr im letzten Jahr und ich glaub, das Problem, das Du beschrieben hast, hatte da einen großen Anteil.
Fabi: Und wenn Du, Du hast ja grad so bisschen eingeteilt, dass Du sagst, Du bist ja Solutions Architekt für den API Teil so. Das heißt, ich würd jetzt mal sagen, wenn Leute mit eurer API sprechen, dann haben sie vielleicht schon Teile von, okay, wie wo krieg ich überhaupt die Informationen her? Das, was das die den Part den Jan grade aufgemacht hat, klingt für mich erst mal auf 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, ich bin schon dabei, mit der API zu interagieren, hab da vielleicht auch schon 'n 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 in Produktion wirklich, weil da muss ich erst mal im Schritt hinaus sein, irgendwoher kommen Informationen so. Irgendwie hab ich schon was gebaut, was funktioniert. Ich will das in Produktion bringen. Was sind denn die Dimensionen, die die Problemdimensionen, auf denen die Leute dann treffen, wo ihr unterstützt?
Maximilian: Ich würde sagen, wenn jemand mit einem Use Case anfängt, dann ist das in der Regel erst mal. Das bedeutet, ich hab einen Chatbot, ich stell ein paar Fragen und ich denk 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. Das heißt, wenn wir an einem neuen Use Case arbeiten, dann ist die erste Frage eigentlich, die ich immer stell, okay, was sind die jeweils? Wie sehen die aus? Und was bedeutet gut für euch? Was heißt das Ganze jetzt? Ich hab einen Chatbot. Ich hab vielleicht schon Daten angezapft. Ich
Jan: muss
Maximilian: mir jetzt als Unternehmen überlegen, was für mich denn jetzt eine gute ist. Zum Beispiel, wie soll der Gesamtoutput aussehen? Was für ein Format, was für ein Stil hätt ich gern im Output? Was darf auf keinen Fall fehlen? Ist jetzt mal so ein Thema, ist jetzt so allgemeine Outputqualität. Ich muss mir aber auch Gedanken machen, inwieweit mein Modell zur jeweiligen Zeit auch die richtigen Inputdaten für den Output nimmt. Also Du hast ja grad gesagt, Fabi, das wär zum Beispiel ein, in dem man Daten anzapfen muss. Wie stell ich denn sicher, dass bei der richtigen Frage die richtigen Daten angezapft werden? Da gibt's dann auch wieder andere dazu zum, ne, also, ich kann auch gerne in den Erdauf eingehen, wenn ihr wollt. Aber wie stell ich ihm sicher, dass wenn ich jetzt frage, was sind jetzt irgendwie meine Unternehmenszahlen ausm 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 oder, wo ich mir einfach als Unternehmen Gedanken mach, wie soll dieser diese Applikation genutzt werden und was bedeutet gut für mich?
Jan: Das das ist eigentlich 'n ganz interessanter Punkt, weil so aus der deterministischen Software kommt, haben ja Kunden ganz oft sehr konkrete Vorstellungen, wie so 'n gutes Ergebnis aussieht, ja. Und da kann man dann testgetrieben gegen entwickeln und irgendwann, weiß ich nicht, hat man halt 1 zu 1 dieses Ergebnis dann, ne. Wie einfach oder schwierig sind denn diese Gespräche mit den Kunden, wenn man denen dann erklären muss, na ja, diese hundertprozentige Sicherheit, die's ja de facto früher auch nicht gab, ne. Wir haben alle irgendwie wachsende Software gebaut, aber diese gefühlte hundertprozentige Sicherheit, die's früher gab, wenn man jetzt Buchhaltungssoftware entwickelt hat vielleicht, ja, wo man einfach Zahlen aufverliert und dann sieht man, ob das irgendwie stimmt oder nicht. Die gibt es ja so nicht in diesem Feld, ja. Und dann muss man, wie Du schon gesagt hast, son bisschen flexibler für sich ausdefinieren, was ist denn gut und womit können wir denn leben? Welche Abweichungen ist da für uns okay? Wie wird das aufgenommen?
Fabi: Vor allem ja, diese, vielleicht nur 1 eine Umschulung, ich hab eigentlich dieselbe Frage gestellt. Meine Frage wär ja gewesen, antwortet nicht jeder darauf, ich möcht die richtige Antwort haben? Also sie soll die richtige Antwort geben oder also das ist wahrscheinlich wie, ich stell mir vor Ort, das ist erst mal die erste Antwort, da da soll halt keine falsche Antwort rauskommt. Die sollen die richtigen Informationen holen.
Jan: Und Ja, manchmal kann ich doch einfach. Das kann ich doch einfach das Richtige sein. Ja,
Fabi: aber wie kann wie, also ich hab, mir fehlt grad noch 'n bisschen die Vorstellungskraft dafür, wie definiere ich denn, wo Abweichungen okay sind und welche Abweichungen, wenn der Ergebnisraum so groß ist?
Maximilian: Ja, genau. Also meine Rückfrage wär direkt, na ja, also was ist die richtige Antwort? Ich glaub, wenn wir 'n Output
Fabi: haben Fabian
Maximilian: Fabian Fabian und ich und vielleicht haben wir da andere Definition von richtiger Antwort, ne. Also
Fabi: Na ja, aber die wird so dein unter dein Beispiel war die Unternehmenszahlen aus 25, die sollten halt schon richtig kommen, so.
Maximilian: Das das ist in dem Fall 'n relativ einfaches Beispiel, weil's da eben eine richtige Antwort gibt. Aber wenn's jetzt zum Beispiel, wenn's einen Learningassistenten geht und ich zum Beispiel da eine bestimmte Sprache lernen will, dann geht's ja mehr diese Experience. Also zu deiner Frage, Jan, wie nehmen Unternehmen so was auf? Es kommt wieder sehr stark auf den Use Case an. Ich komm auch wieder aus 'ner Welt, aus 'ner, also ich hab Mathematik studiert. Ich komm aus 'ner Welt, mehr aus der Welt. Das bedeutet für mich, wenn ich früher Machine Learning Use Cases gemacht hab, dann waren Metriken für mich natürlich immer ein Bestandteil, ne. Also man guckt sich da einen Fehler an, man schaut sich eine an, das ist dann relativ klar greifbar. Die Modelle waren natürlich auch nicht perfekt damals, Klammer auf, Klammer zu. Aber es ist einfach deutlich greifbarer. Jetzt heutzutage mit LLM Applikation ist es schwieriger, aber die Ambition sollte sein, dass man es doch wieder so eine Art implementiert. Und es gibt, die dann immer noch deterministisch sind. Es gibt aber auch, die es nicht sind. Beispiel, wenn ich jetzt ein, sagen wir mal, ich sprech jetzt über 'n Use Case, ich arbeite mit 'nem Kunden, die sind im Learning Space. Also die verbinden zum Beispiel AI Tutoren mit Schülern und die sprechen dann miteinander. Und nach der Lessen gibt's dann vielleicht Lessen Insights, wo dann der Schüler noch mal die Schülerin für sich selbst nachher lernen kann und gewisse Übungen macht. Und da kann man jetzt eben sagen, okay, wie iwer liegt jetzt das Ganze? Einmal soll die Übung natürlich sinnvoll sein, wird schon schwieriger, aber vielleicht gibt's auch gewisse Rahmenbedingungen, die die Übung behalten sollen, ne. Also die Übung sollte vielleicht 4 Wörter beinhalten. Die Übung sollte dann vielleicht nicht länger als 5 Minuten dauern. Also es gibt zu jedem Use Case gewisse jeweils, die sehr deterministisch sind. Beispielsweise auch wieder wird das richtige Tool an der richtigen Stelle gekreuzt. Das sind alles jeweils, die man sehr machen kann. Es gibt aber in aller Regel auch immer noch 'n paar, dies nicht sind. Und das wird dann in der Regel mit Model Graders gemacht, also mit beispielsweise. Und da kommt's dann wirklich drauf an, dass ich für mich selber entscheide, welchen Stil und welchen Ton ich denn für richtig empfinde, ne. Und das sind meistens dann die schwierigsten und das sind die, wo dann auch die meisten Diskussion erfordert ist. In der Regel fängt man eigentlich aber auch nicht damit an. In der Regel fängt erst mal der Mensch wieder an, also. Da hat man dann oft zum Beispiel jetzt in diesem Fall Linguits, die sich dann diesen Output anschauen und gucken, okay, hab ich jetzt eigentlich hier das Richtige gelernt? Ist das das richtige Wort? Und basierend auf diesen kann man dann beispielsweise auch automatisiert diese erstellen. Das heißt, es ist schon noch so, dass ich als Mensch da anfangs sehr genau draufschauen muss und für mich definieren muss, was ist richtig und was nicht? Was ist vielleicht auch 'n Sonderfall? Und basierend darauf werden dann oftmals solche erstellt und dann eben die die wieder angepasst. Am Ende ist das Ganze ja sone kleine. Das bedeutet, okay, ich hab jetzt einen, der sagt mir jetzt, stil ist jetzt vielleicht bissel zu professionell, zu wenig professionell, zu zu wenig. Und basierend darauf kann der wieder angepasst werden. Ich hab den Eindruck, dass so was auf jeden Fall immer mehr verstanden wird, weil's auch immer mehr theoretische Ressourcen dafür gibt und und und Bücher beispielsweise. Die Schnellsten sind wie immer oder wie oft, die Start ups und. Da wird dann meistens, wenn 'n neues Feature erstellt wird, neuer, geht's direkt los mit AB-Testing und dann sieht man das Ganze auch relativ schnell. Aber auch bei ist es so, dass dort ja auch sehr wichtig ist, genau zu definieren, was was denn gut ist und was nicht. Das heißt, da bin 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's tatsächlich relativ einfach ist. Also wenn wir, wenn wir zurückgehen zu meinen 3 Use Case Kategorien und dann zur Nummer 2 gehen, zu LLNM Classifications zum Beispiel, Da gibt's einen Use Case, wo man auch wieder zum Beispiel ein Gespräch hat zwischen einem Tutor und einem Schüler. Und dann will man wissen, ob denn neue Wörter gelernt wurden. Und dann gibt's Infos zu diesen neuen Wörtern. Also das sone, eine Klassifizierung am Ende. Und bei Klassifizierung kennen wir wieder ausm klassischen m l Bereich, kann man sich dann relativ einfach wieder son berechnen. Ja, also manchmal ist noch deterministisch, in den allermeisten Fällen ist es son bisschen eine Kombination.
Fabi: Und ich will da, ich muss noch mal eine Verständnisfrage nachschauen. Ich glaube, ich hab's jetzt in der Theorie verstanden. Ich würd's aber gern noch mal 'n bisschen probieren, praktischer zu machen, was das jetzt genau wirklich bedeutet bei diesem Use Case. Wir hatten, Du hast es grad gemeint, es war ja eine Chatapplikation, die am Ende noch mal ein ein wie was Lerninhalte, Recall am Ende macht, wo man sagt, verstehe 'n paar Fragen. Du hast jetzt gesagt, es gibt bestimmte jeweils, wie es sollen eine bestimmte Wörter drin, nur eine bestimmte Wortanzahl oder irgendwie Länge sein. Wenn ich mir das jetzt vorstelle, dieser dieses am Ende wird noch mal 5 Minuten so, wir das Ganze noch mal im Grunde genommen, wenn ich's mir jetzt forsche, ist das Ganze eigentlich erst mal nur ein Prompt, der irgendwie durch von vorher irgendwie jetzt definiert, wie soll das Ganze funktionieren. Und der kann entweder der Output danach wird evaluiert nach so was wie Output Länge oder so was. Das kann ja dann codegesteuert wirklich einfach überprüft werden, wie bei der Output des LLMs so, das da dafür ist Code da. Und dann gibt's den LLM Grader, der eher so was wie, wie ist der Ton, wie ist die Qualität so? Und da ist 'n anderer Prompt, dem ich diesem LLM Grader mitgebe und sag, hier achte auf folgende Dinge so. Und Genau. So wie wie wird oder in welchem Prozess wird werden, also erst mal war das ungefähr richtig oder wo lag ich komplett falsch? Und dann wie wird, wie ist das in der Realität dann wirklich? Heißt das, ich hab diesen Prompt für, erzeug mir mal bitte das das Quiz für das für das Ende. Das schick ich x-mal in die und lass dann sowohl die jeweils als auch den LLM Greader durchlaufen und guck dann einfach nur, stimmen alle? Und wenn nicht, probier ich den wieder so anzupassen, dass sowohl Ewais als auch LLM Greader irgendwann happy damit sind.
Jan: Also die Frage ist eigentlich, passiert das zur Laufzeit oder guck ich mir das im Nachhinein an?
Fabi: Nee, also erst mal, wie funktioniert es? Und dann wär die nächste Frage, passiert das zur Laufzeit? Mach ich das nur vorher während der Laufzeit oder beides?
Maximilian: Ja. Ist ungefähr richtig. Ich würde das nur noch
Fabi: Ja. Also ich bin, ja, genau. Ich war
Jan: Ich will doch nicht Ich korrigiere mich
Fabi: gerne und warum wenig, als würde ich grad sagen, es ist richtig. Korrigiere mich sehr gerne bei allem, was komplett falsch war. Teil, Ich muss dazu sagen, ich hab's, also wir nutzen, wir haben's ja bisher in Produktions Wir haben diese Use Cases bei uns nicht so. Deswegen würd's mich schon interessieren so. Wir wir nutzen's ja schon, korrigieren
Jan: das so zumindest nicht, ne. Ja.
Maximilian: Ja. Also in diesem Fall jetzt, wenn wir bei diesem Use Case mal bleiben, find ich nämlich ganz interessant, weil das eigentlich jetzt schon direkt so ein Multistap Use Case ist.
Jan: Mhm. Wenn
Maximilian: ich jetzt über E-Mails nachdenke, muss ich eigentlich schon mal viel weiter vorne anfangen. Ich muss zum Beispiel erst mal gucken, das war ja eine Konversation. Und der erste Schritt ist ja, ist mein Transkript denn eigentlich richtig von der Konversation, ne? Also ich muss ja eigentlich schon mal diese Konversation richtig auffangen. Könnt ihr euch vorstellen, wenn jetzt jemand eine neue Sprache lernt, sagen wir mal, auf a 1 oder a 2 Level, dann können vielleicht solche Transkripte auch schon 'n bisschen Messi sein, ne. Ich muss, wie guck ich überhaupt? Wer ist Schüler? Wer ist Tutor? Und also die erste E-Welle ist schon mal die, dass überhaupt das Transkript richtig ist, ne. Also und da gibt's dann eben schon mal Input E-Mails, das ist ja dann noch mal bissel komplizierter, weil es da einen Text to Text Anteil auch gibt. Aber das ist mal so Schritt Aber
Fabi: der weil der AI Tutor ist auch ein, also ist kein textbasierter Tutor.
Maximilian: Genau, das ist jetzt in dem Fall Okay. Genau. Schritt 1. Schritt 2 ist, dass man wirklich auch guckt, dass man die richtigen Learnings aus der Session dann auch aufnimmt, ne. Das ist dann eben oft so, dass ich sag, hey, ich hab ein paar Transkripte und ich frag das LLM, was denkst Du jetzt, welche Wörter sind jetzt die wichtigen? Und dann wird dann oftmals das Ganze erst mal von einem Human Annotator von dem Linguist gegengecheckt. Ist das richtig oder falsch, ne? So so fängt man dann oft an. Da kann das LLN dann immer drauf basierend lernen. Also wir haben einmal das Transkript, wir haben die, hab hab ich die richtige Learnings? Und dann noch die Übungsgenerierung. Und Und da kann natürlich auch wieder superviel mit reinspielen, ne. Also wie soll so eine Übung ausschauen? Soll ich beispielsweise, geht's kommt sie dann auch noch drauf an, wie viel weiß ich denn über den Schüler, die Schülerin? Hat die Schülerin diese Übung schon mal in der Form vielleicht vor 2 Tagen gehabt? Ja, also da spielen dann solche Sachen wieder rein wie zum Beispiel, dass ich das Ganze noch mal mehr personalisiere. Also alleine die Übungserstellung kann dann auch schon mal superkompliziert sein. Ist die denn pädagogisch wertvoll? Ist, wenn ich jetzt ein neues Wort erkläre, die das Erklären von diesem Wort, macht die überhaupt Sinn? Also das sind ganz viel verschiedene Teile. Also einmal Transkripte, Content, dann gucken, dass ich die richtigen hab, dass ich die richtige Session erstelle. Und dann am Ende auch noch superwichtig, was hab ich denn jetzt aus Geschäftssicht überhaupt für eine Idee, was am Ende aus diesem Use Case rauskommen soll. Also am Ende will ich ja vielleicht auch noch evaluieren, hey, ist jetzt denn die Schülerin drangeblieben? Oder waren jetzt zum Beispiel meine meine, meine so langweilig, dass die Leute das Ganze schon wieder weggeklickt haben. Wie oft bin ich da drin? Wie oft verwend ich's noch mal? Also jetzt allein bei diesem Use Case ist es dann am doch 'n bisschen komplizierter, weil da wieder sehr viel verschiedene Unterpunkte sind, die man alle wieder einzeln evaluieren kann. Und jetzt noch, ich ich merk, ich gebe immer recht lange Antworten, also stopp mich da gern zwischendrin, aber ich wollt auf deine Frage, Jan, eingehen, wo oder auf beide, wo ihr sagt, okay, macht man's dann live oder macht man's davor? Die Antwort ist, beides. Wenn ich jetzt über jeweils gesprochen hab, hab ich erst mal über jeweils in der Entwicklung gesprochen. Also auf jeden Fall bevor ein Use Case live geht, muss ich schon mal mir sehr viel Gedanken machen, jeweils aufsetzen, aufsetzen und gucken, ob jetzt ein, ob's eben passt. Dann kommt der nächste Schritt, der ist in aller Regel oder oft jetzt zum Beispiel bei ein Test, wo man das Ganze dann mit 'ner gewissen Usergruppe eben testet. Und jetzt wird's spannend, weil Live EVs sind in der Regel natürlich noch bisschen komplizierter. Denn ich kann natürlich nicht jede jede Session dann live mit einem Linguist bewerten, ne. Das funktioniert ja gar nicht. Also Human En Notation ist es schon mal irgendwie per Definition schwierig, live zu machen. Das bedeutet, live sprech ich dann gern so von 2 verschiedenen Arten von von oder Monitoring. Ich rate dazu, da schon immer son kleinen Testsatz noch zu haben, der sone Art von Dataset, dass man immer wieder live testet und sich anschaut und zu gucken, ob sich da irgendwas tut, ob's da irgend einen Drift gibt, ne. Aber das kann man immer nur mit 'nem kleinen Satz machen. Also man kann das einfach nicht für alles machen. Und dann eben einige der sind zum Glück relativ automatisiert, deterministische kann ich immer machen, dass ich die dann trotzdem noch für alle Livedaten dann auch mache, dann eben auch schnell zu monitoren, wenn dann irgendwas in Produktion nicht mehr klappt.
Jan: Jetzt hast Du angesprochen jeweils am allerwichtigsten auch schon während der Entwicklung. Das ist ja auch wieder son sehr nicht deterministischer Teil im Sinne von, wenn dich dein Projektmanager fragt, wie lang dauert's denn? So, was sagt man denen denn da, ja? Also ich mein, es war früher schon schwer genug zu schätzen, wie viel Zeit man braucht, Code zu schreiben. Jetzt musst ich auch noch schätzen lernen, wie viel Zeit mein LLM braucht, zu lernen, dass da das Richtige rauskommt. Wie nähert ihr euch so Fragen?
Maximilian: Ja. Da kommt's auch wieder sehr stark drauf an, was es denn für ein Use Case ist. Ich hab auch sehr viele Konversationen mit mit Developmentn, die dann sagen, gib mir mal Best Practices. Also wir müssen aussehen. Und dann gibt's ja, da gibt's ja mittlerweile auch sehr viele Content dazu und da gibt's dann super Themen wie, ja, ihr braucht vielleicht ihr braucht Hunderte an Datensätzen und dann braucht ihr Training, Validierung und und Testing und 5. Und da bin ich dann mittlerweile auch bisschen vorsichtig, weil ja, das ist best practice generell. Aber ist es für jeden Use Case nötig? Meiner Meinung nach nein. Ich schau mir das Ganze immer son bissel an, natürlich erst mal nach Komplexität des Use Cases und auch nach Risiko des Use Cases, ne. Also wenn ich jetzt natürlich 'n Start-up bin und ich hab 'n Core AI Produkt und das ist an alle Kunden ausgerollt, dann muss ich mir natürlich natürlich mehr Gedanken machen und so viel wie möglich. Wenn ich jetzt aber so einen internen Chatbot mir baue, der dann eben von ein von ein paar Usern genutzt wird, dann muss ich da nicht auch noch irgendwie 20 nebenbei laufen lassen, ne. Und ich hab auch das Beispiel der Klassifikation genannt vorher, da reizt dann am Ende oft auch, wenn ich einfach dann meine oder meinen hab. Und da muss ich mir gar keine Gedanken über machen. Das heißt, ist immer bisschen son schwieriges Thema, kommt sehr stark auf den Use Case an. Ich hab aber auch den Eindruck, dass grad die Lernkurve bei immer mehr steigt und die Leute das auch mithilfe von Tools dann doch immer schneller machen können.
Jan: Jetzt haben wir schon gehört so, Du hast ja deinen LLM Use Case am Laufen. Und zu gucken, ob das wirklich paar LLMs neben dran, die das Ganze so überwachen können. Böse Zungen würden behaupten, das ist ja son son, immer mehr Tokens zu verkaufen, ja. Also grade von, also wenn jetzt jemand hier von Open Air sitzt, sagst Du, ja, LLM, kein Problem, schmeiß noch mehr LLM dazu, das gegen Öl für Geld machen wir alles, ja. Wie welche Rolle spielen denn Kosten in dieser Diskussion? Weil auch das ist ja sone, wenn man da am Anfang draufguckt, sone große Unbekannte, ja, zu schauen Ja. Ne, wie viel Kontext brauch ich da? Wie groß ist mein meinen prompt? Welche anderen nachgelagerten LLMs brauch ich vielleicht auch noch? Wie Wie viel chatten die Leute wirklich? Wie viel Ja, wie viel wird angenommen? Am Ende, das ist ja der allergrößte Hebel so, ne. Ja. Wie versucht ihr da am Anfang son son Näherungswert zu finden oder überhaupt erst mal son Verständnis dafür zu entwickeln?
Maximilian: Ja, sehr guter Punkt. Ich hab jetzt vor allem bei jeweils erst mal sag ich mal, gesprochen, ne, also wie man guckt, ob der gut genug ist. Wenn ich aber mit Development sprech, dann ist eigentlich immer nur eine von 3 Dimensionen, die anderen 2 sind Kosten und oft auch Latenz. Mhm. Also Ja, gut, das ist man sich vorstellt grad in im Service Bereich, wenn ich da wirklich eine Konversation mit jemandem haben will, dann will ich keine 2 Sekunden Latenz, da könnten wir auch irgendwie keine gute Folge jetzt haben, wenn ihr euch das mal vorstellt. Bei anderen User Cases natürlich ist Latenz wieder weniger ein Problem. Also manchmal, wenn ich so einen, nennen es hab, ich hatte letztens 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 'n großer Teil. Kosten absolut immer Teil, vor allem auch wieder in der Arbeit mit Start ups und, 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 bring da mal gern das Beispiel, ich weiß nicht, ob man sich noch erinnern kann, aber 2 2 23 hatten wir erstmals GPD 4 released. Das war so wirklich 'n relativ eine relativ große Sache, war 'n supermodell, war aber super-, superteuer. Also war, wenn wenn ich mich richtig erinner, für 1000000 Output Token irgendwie 60 Dollar, 30 Dollar Input. Wir sind seitdem für manche Modelle, zum Beispiel GPD 5 Nano auf 5 Cent für 1000000 Input. Also teilweise wirklich ein 99 Prozent Reduktion in Kosten von Modellen, die ähnlich gut sind. Wir haben's aber jetzt nicht an Revue eingebüßt. Weil natürlich, was wir bisher immer so gesehen haben, ist, wenn wir's schaffen, die Modelle günstiger skalierterbarer anzubieten, dann werden sie auch mehr genutzt. Und das heißt, wenn man über Kosten nachdenkt, ist immer ein Punkt, dann dann sagen wir immer, okay, wie was sind jeweils die wichtigen Punkte? Bin ich schon zufrieden mit der Performance? So geht's mir jetzt drum, das skalierbar zu machen. Dann würden wir da anders reingehen. Da würd ich sagen, hey, okay, Du nimmst jetzt vielleicht hast mal überlegt mini zu nehmen, hast mal überlegt, vielleicht runterzustellen, weniger Output Token zu haben. Wie sieht euer aus? Schafft ihr's schon, dass ihr viel cashed? Also da gibt's dann einige andere Hebel, die man da auch auf Kostenseite betätigen
Fabi: kann. Gleich, weil Du grade Caching angesprochen hast, kannst Du mal probieren, dann in dem in dem zu kosten so caching für prompt son bisschen zu erklären, was genau Ja. Was genau wird da gecashed?
Maximilian: Genau. Also Caching find ich persönlich immer superspannend, aber ich glaub, viele sehen's dann irgendwie doch so, als passiert und muss ich mir nicht viele Gedanken machen an. Vielleicht, 'n bisschen Hintergrund zu geben, wir haben bei beispielsweise, ich glaub momentan, wenn ich mich noch richtig erinner, sind wir da so bei Input Token kosten irgendwie so 2 50 auf 1000000. Und oder Casing Discount ist da 50 Prozent. Das heißt, wenn Token gecashed ist, kostet 50 Prozent weniger. Wenn man das jetzt mit GPT 5 1 oder 5 2 vergleicht oder allgemein mit neuen, 1 neuen Generation von Modellen, dann hat man da Casing Discounts von 90 Prozent. Das heißt, Cashing wird meines Erachtens immer, immer wichtiger, weil das natürlich ein Riesenhebel ist, Kosten zu sparen und übrigens auch die Latenz zu verbessern, weil die Cachete Token auch schneller funktionieren. Das heißt, wir haben wirklich Kunden, die da sehr, also technisch, also versiert sind, auch oft Coding Start ups, für die ist Caching 1 der Hauptthemen. Weil wenn man's schafft, generell vielleicht sone irgendwie 80, 90 Prozent Cash Hits zu haben, dann ist es natürlich ein riesen Riesenhebel für die Kosten, ja. Und wie's funktioniert am Ende, also am Ende geht's drum, wie funktionieren LLMs? Also man hat eben diesen Attentionlayer und man schafft's dann eben, dass man gewisse Teile in speichert und das deswegen für das LLM am Ende einfacher ist, wiederzuverwenden. Da spricht man dann eben so von 'n paar Minuten, wo diese Token dann gespeichert werden. Und dadurch hat man eben diese und die müssen nicht neu gerechnet werden. Und das merkt man teilweise eben schon sehr stark an den Kosten bei bestimmten Use Cases.
Fabi: Das heißt, weil aber
Jan: Sorry, ich muss nur zum Verständnis noch mal nachfragen.
Fabi: Ja, auch Verständnis.
Jan: Was ist denn aber dann also oder oder wie kann ich denn da Cache optimieren? Heißt das, ich muss mir das so ähnlich vorstellen wie in 'nem Multistap Bild Prozess, dass einfach von meinem Prompt immer nur der letzte Teil variieren darf und alles davor kann gecascht werden, bis der variable Teil kommt. Heißt das, ich kann, heißt das, es ist egal, wie sehr sich mein ändert, Hauptsache 'n bestimmter Teil ist immer gleich. Also was, ja, wie wie kann ich das denn nutzen?
Fabi: Und 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 1 Kontextes?
Maximilian: Genau. Also Fabi zu Viele,
Fabi: viele Verständnisfragen.
Maximilian: Genau. Fabi über beides. Mhm. Und jetzt Jan, wie schau ich mir das an? Du hast genau recht. Also im Prinzip geht's bei Caching drum, dass die ersten Teile des Inputs potenziell die gleichen sind und dann wird Caching aktiviert. Und Fabi, das bedeutet eben bei 'nem Multiturnen, klar, ist es so, weil natürlich der erste Teil immer wieder gleich ist. Wenn ich jetzt aber auch 2 User hab, die eine ähnliche Frage stellen, kann auch aktiviert werden? Und jetzt geht's eben drum, erst mal ist automatisch aktiviert. Aber dann gibt's noch son paar technische Details, sag ich's mal. Beispielsweise gibt's potenziell die Möglichkeit, eine Cache ID zu verwenden und die macht's dem LLM dann oft leichter, direkt mal User schon mal zu gruppieren. Und das ist dann eben farbig genau bei sonem Use Case, wo Du sagst, hey, Du hast jetzt vielleicht einen Chatbot ausgerollt an sehr viele Nutzer. Mhm. Dann ist es immer noch nicht sichergestellt, dass jetzt Nutzer genau grad in dieselbe Memory kommen und der Cashhit 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, noch mal in der Praxis zu mehr Cashhits führen.
Fabi: Okay, verstanden. Das heißt, das wär halt einfach mal drüber. Das heißt, weil Du grade das das Beispiel meintest mit 2 Userstellen eine ähnliche Frage, dann ist mein Hebel, den Cash Hits zu optimieren, eher sone Cash Gruppierung, als irgendwie zu sagen, okay, ich muss gucken, dass ich die Frage, vielleicht vorher noch mal durch 'n kleines NLM schieben und die Frage genau gleich formuliere, damit er prompt 1 zu 1, also dass ich das umschreibe, das ist das ist jetzt nicht die Art, sondern eher zu sagen, ich probiere sie semantisch zu kopieren und dann an die an die Instanzen zu kommen, wo wahrscheinlich der der noch da ist und da dadurch einen Cachehit generieren kann.
Maximilian: Richtig. Sollen wir in dem Zuge auch mal kurz allgemein über vielleicht sprechen? Das wär, also
Jan: da das wär jetzt nämlich meine Anschlussfrage, weil also das klingt ja so, als würden grade die Workflows davon profitieren, die halt mit sonem maximal großen Kontext auch schon anfangen, ja. Also wenn ich jetzt hier mein mein kleines Podcasting Tool Fabi kennt, das hat's in der Demo gesehen letzte Woche, was uns hier in der Research son bisschen helfen soll, ja. Das 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, ja. Und das bleibt ja immer dieser Unterhaltung vorangestellt, so. Und wenn ich dafür jetzt schon mal, weiß ich nicht, 50000 Tokens immer voranstell, 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 'n bisschen kleine Unterhaltung dazukommt.
Maximilian: Genau, so ist es. Ja. Ich hab tatsächlich auch schon mal 'n Kunden, die haben früher viel gemacht, also. Ich hol mir etwas aus 'ner Knowledge Base. Und die haben dann gesagt, lohnt sich eigentlich gar nicht mehr, ich pack einfach
Fabi: direkt alles rein.
Jan: So, hat's auch gemacht.
Fabi: Ja, genau.
Maximilian: Genau. Genau, richtig. Und wenn man vielleicht in in der Richtung, ich glaube, ihr habt sie mich vorher Anfang schon genannt, dieses ganze Thema Kontext Engineering ist natürlich momentan 1 der Hauptthemen, weil's 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 ja schon erwähnt, der System prompt ist ja das, was zum Beispiel immer gleich ist. Da hab ich meine Tool Definition auch drin, alles immer gleich. Und dann hast Du eben aber dynamischen Kontext. Und der sammelt sich an innerhalb des Gesprächs. Das bedeutet, ich hab entweder ein Multitorengespräch, dann kommt was dazu oder ich hab superviele Tool Calls, die dann auch den Kontext füllen. Und das ist jetzt auch wieder ganz interessant, weil das eben wieder verschiedene Arten von Use Cases sind. Und je nach Use Case geht's jetzt nämlich wieder drum, wie schaff ich's jetzt, dass ich den Kontext nicht überlade? Oder dass ich teilweise wieder Kontext lösche, wenn das Kontextfenster voll ist. Und da ist jetzt eben nämlich so, dass je nach verschiedene Möglichkeiten gegeben sind. Ich geh einmal nur ganz kurz drauf ein. Also Beispiel, ich hab einen Chatbot, ich merk, der Kontext wird voll, was mach ich? Oder ich hab einen, passier ganz oft bei Codingagenten, Kontext wird voll, was mach ich? Die einfachste Möglichkeit oder eine der Einfachen ist, okay, ich schneid einfach die ersten ab. Das macht Sinn, wenn Du jetzt einen Chatbot hast, der wirklich, wo ich superviele hab. Eine andere Möglichkeit ist, das ist vor allem bei, sag ich mal, Workflow Automations, wo viele Tools getriggert werden. Da hab 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's noch die Möglichkeit, das sind vor allem so bei, sag ich mal, dass ich, wenn ich am Ende bin, das Ganze zusammenfasse und dann weitermache, ja. Und für alle diese Möglichkeiten gibt's für und wieder, ja. Und je nach Use Case würd ich mich dann für eine der 3 beispielsweise jetzt entscheiden.
Fabi: Und ich hab mir nur grad, ich bin, glaub ich, zurück gedanklich zu dem Beispiel, mit dem wir gestartet sind, also der der Lernapp mit dem Voice Agent, wo jetzt irgendwie meine Vorstellung wäre, dass der allgemeine Teil des Proms, also ich gebe Kontext, der sozusagen für alle User gleich ist, wahrscheinlich im Verhältnis sehr viel weniger ausmacht, weil's son Multiturnen ist. Ich rede viel mit einem spezifischen Agent, dass es wirklich eher darum geht, so den Kontext möglichst lang gleichzuhalten, dass halt immer nur Inkremente dazukommen. Und ich mach eher 'n Caching auf User Session Ebene und dass ich gar nicht so viel davon profitiere, dass alle User mit dem gleichen anfangen, wie jetzt das Learning aufgebaut wird. So, also da würd ich mir vorstellen, die cachen eher dahingehend so, was wahrscheinlich aber so, halt den prompt gleich und hängen nur hinten dran. Das wär erst mal, ist das richtig? Und dann für mich so die Frage, es würde jetzt erst mal 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 hochzuhalten und und Caching einen kleineren Teil der Kostenoptimierung ausmacht, als wenn ich's hinbekomme, über mehrere Session hinweg zu optimieren. Darf ich ganz kurz
Jan: eine Gegenfrage stellen? Also wenn wir jetzt bei deinem Agent Beispiel, Support Agent Beispiel bleiben, macht das ja vielleicht mehr Sinn, die User so zu gruppieren nach Anfrage, mit der sie zu dir gekommen sind, ne? 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 gepimet ist zu, was kosten Retouren, will ist der Ablauf, bla bla bla. User, die Fragen zu Produkten haben, landen vielleicht in 'nem anderen Cache. Also Du musst dir ja gar nicht vielleicht im Laufe Gesprächs irgendwie wieder einsortieren, aber vielleicht kannst Du den Startpunkt schon son bisschen aufteilen, indem Du so ein, 2 schlaue Anfangsfragen stellst und dann quasi erst in den Flow startest.
Maximilian: Richtig. Genau. Das ist auf jeden Fall eine super Möglichkeit, das zu machen. Und auch zu 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 es ist immer wieder der zwischen, okay, bin ich der Meinung, dass die Kosten stark reduziert. Brauch ich das überhaupt? Wenn ich jetzt zum Beispiel sonen LLM hab, sind die ja eben oft schon relativ günstig, da ist es vielleicht dann gar nicht so wichtig. Also es kommt wieder immer sehr stark auf den an, wie wie viel Arbeit ich da reinstecken will oder wie viel ich dann zum Beispiel eher dann in andere Themen reinsteck. Zum Beispiel will ich vielleicht irgendwie 'n kleineres Modell, das dann mit dem Ganzen besser oder schneller klarkommt und auch günstiger klarkommt. Oder ich kann mir eben noch ein, 2 andere Stellschrauben dann anschauen.
Jan: Vielleicht den den Bogen wieder zu schließen. Wir haben ja angefangen, eigentlich weil über Kosten sprechen wollten, dann sind wir bei Cashing gelandet. Und die Frage eingangs war ja eher so, wie nähert ihr euch halt diesem Kostenthema? Wie versucht ihr Ja. Am Anfang von sonem Projekt rauszufinden, was es ungefähr kosten könnte vielleicht. Mhm. Ja, und dann sind wir son bisschen abgerutscht. Ja. Deswegen noch mal die Frage, wie wie wie versucht ihr das rauszufinden?
Maximilian: Ja, das rauszufinden. Da gibt's natürlich son paar Standardfragen. Und die erste ist natürlich immer, was denkt denn der Anwender, wie viel Produkt haben wird, ne? Also wenn ich jetzt zum Beispiel eine Learning App bin und so was ausrollen will an alle User, dann hab ich ja beispielsweise x am Tag, dann weiß ich schon mal, das würde, da weiß ich's eigentlich supergenau, wie oft das Ganze getriggert wird. Also einmal Volumen und dann natürlich am Ende, ja. Also da schau ich mir dann an, okay, wenn ich jetzt, ich fang meistens mal mit 'nem Flagship Modell an, also beispielsweise wär jetzt jetzt bei Open AI 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 überleg ich mir noch so ein, 2 Themen wie, okay, brauch ich in dem Fall jetzt zum Beispiel ja oder nein? Weil in den Fällen, in denen ich verwende, wird's natürlich schon auch direkt teurer, weil ja Tokens am Ende Output Tokens sind, die das Ganze teurer machen. In vielen Fällen, jetzt grad bei Chatboards, brauch ich aber möglicherweise gar kein. 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 Price, Input Token Price plus, was ist jetzt 'n Outcome? Wie oft wird der getriggert? Mal Output Price. Und dann kommt man, sag ich mal, schon relativ genau auf auf eine eine gute erste Schätzung. Plus, sorry vergessen, wie viel denk ich zu cachen? Natürlich. Haben wir grad drüber gesprochen.
Jan: Jetzt hast Du schon den den zweiten Schritt für mich vor dem ersten gemacht, weil, was Du, na ja, ich kann hier mal Tokens und dann komm ich irgendwie schon auf meine Kosten. Ich muss ja überhaupt erst mal verstehen, wie viel Tokens ich überhaupt brauch, oder? Also das meint ich so mit, wenn ich jetzt son son Quiz da erstellen will oder so verstehen will, wie viel Tokens mein mein Tutor so irgendwie in soner Session irgendwie verbraucht, erzeugt, wie auch immer. Wie wie findet sich so was raus? Oder ergibt sich das einfach immer erst durch einen Prototyp und die Erfahrung aus der Praxis? Oder findet ihr trotzdem irgendwie son Näherungswert vorher?
Maximilian: Ja. Also jetzt in diesem Beispiel hab ich ja schon mal sehr viel Transkripte. Ne, also ich weiß ja zum Beispiel schon mal, ich hab jetzt hier eine Session, die hat jetzt vielleicht 5 Minuten gedauert. Ich hab da ein Transkript und ich weiß ja, wie viel Token beispielsweise alleine in diesem Transkript sind, ne. Und dann hab ich ja, da muss ich erst mal gar nicht viel machen. Also wenn ich dann einfach mal son Transkript schon mal in ein Pack, mir das analysieren lasse, das ist dann wirklich nur son erster Durchstich, der sagt mir ja eigentlich ja schon sehr genau, was ich da an Input Tokens und Output Tokens erwarten kann. Also wirklich in vielen Fällen hab ich den Eindruck, ist so was eigentlich relativ schnell klar.
Fabi: Weil weil's dann doch so ist, dass man irgendwie dann die die Unternehmen schon damit rumprobiert haben und irgendwie so was wie mal 'n Transkript und irgendwie sone Session schon mal ausprobiert haben. Ist 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, oh, ich könnt jetzt 'n Chatbot bauen so. Aber jetzt muss ich erst mal wissen, was das kostet, bevor ich überhaupt einen mache.
Maximilian: Genau. Und ich glaube grad an der an der Kostenschraube kann man auf jeden Fall dann auch noch drehen. Also ich hab's ja schon erwähnt, es gibt dann oft die Möglichkeit, Mini Modelle zu nutzen beispielsweise. In manchen Fällen kann's dann so sein, dass die Mini Modelle nicht gut genug sind. Ja, das sind wir wieder in dem Fall, wir brauchen jeweils, das auch zu sehen. Aber es kann dann ja beispielsweise manchmal so sein, dass vielleicht die Mini Modelle 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 'n ein Model Routing, dass ich zum Beispiel gewisse Anliegen von einem Mini Modell machen lassen kann, die dann wirklich Faktor günstiger sind und die schwieriger an Anfragen dann an das schlauere LLM oder vielleicht an ein LLM mit mehr schicke. Also da gibt's dann wirklich auch später noch sehr viel Möglichkeiten, wenn wenn die Kosten das Problem sind, das Ganze anzupassen. Ich würde auf ein Thema noch eingehen, Jan, weil Du's vor 'n paar Minuten schon gefragt hast oder eingangs, als wir auf das Kostenthema gekommen sind, wo Du meintest, ja, wir sagen ja, nutz LLMs und dann nutz LLMs fürs Grading und nutz noch mehr LLMs und Ja, dann Dann dein
Jan: dein LLM muss auch entscheiden, welcher Router da irgendwie genommen wird so, ja. Mehr Leute sind immer Also
Maximilian: jetzt aus der Praxis ist meiner Meinung, dass LLM User jetzt im im oder in den meistens sehr gut genutzte Kosten sind und in der Regel auch nur einen Minimalteil der Gesamtkosten ausmachen. Also an den zu sparen, da jetzt mal einen Call weniger zu machen, bin ich bin ich kein Advokanter.
Jan: So so war das auch gar nicht gemeint. Also und auch, ne, auch wenn's eben mal Spaß da hat, auch im Router kann ja 'n LLM durchaus sinnvoll sein. So. Also Kann ja auch 'n kleines sein. Ja, also muss ja wahrscheinlich auch, damit's einfach performant ist am Ende des Tages auch, ne. Und ich meinte das auch gar nicht so so ketzerisch, sondern einfach eher so, ich glaub, man muss sich darüber bewusst sein, dass der LLM Einsatz halt nicht mit dem einen prompt irgendwie anfängt und aufhört so, sondern da muss halt noch mehr drumherum passieren, damit es vom Ergebnis her am Ende schlüssig sein kann.
Fabi: Die auch das LLM das den Code überhaupt schreibt.
Jan: Ja, das das auch, ja. Aber aber vielleicht, weil
Fabi: wir sind ja, also wir sind ja auch schon sehr weit im in der Zeit irgendwie drin. Es sind ja schon noch 'n paar Themen, die wir wahrscheinlich angehen wollen. Wir hatten, Du hast ja die 3 Dimensionen aufgemacht, ne, accuracy und Cost, so, was denn da Also klar, das hat schon erklärt, man will natürlich, dass die Antwortzeiten möglichst kurz sind, zumindest bei 'nem Chatbot, je nach Use Case. Aber was sind die Dimensionen, wie ich das optimieren kann? Weil ich würd danach gern schon noch mal auch aufs Thema so vielleicht Prompt engineering versus Feintuning, also wie viel wie viel Arbeit steckt da drin, mein mein Prompt für meine Use Cases zu designen? Aber lass uns gerne erst einmal vielleicht das Trimpirat aus acceracy, Cost und komplett machen.
Maximilian: Ja, auf jeden Fall. Also ist oftmals sehr stark korreliert mit Kosten auch.
Fabi: Mhm.
Maximilian: Also in der Regel ist es so, dass wenn ich zum Beispiel ein Mini Modell verwende, das dann auch schneller ist, ne. Ich kann mir aber auch, also bei der ist es so, dass ich mir oft generelle Fragen über die Modellarchitektur stellen muss. Beispiel, ich hab eine eine LLM für eine Konversation. Da gibt's momentan so 2 unterschiedliche Wege, das zu machen. Es gibt so den traditionellen Ansatz, der früher oft gemacht wurde, der sogenannte. Ich hab ein speech to Text, LLM, Text to Speech, ne. Mhm. Der neuere Ansatz ist quasi eine native speech to Speech Experience. Das sind sogenannte, wo wir auch extra APIs dafür haben. Also Modelle, haben nicht mehr diesen verketteten Ansatz, sondern da kommt Sprache rein, Sprache raus, ist viel schneller, ne. Ist viel schneller.
Jan: Mhm.
Maximilian: Kost in der Regel aber meistens mehr. Da ist dann nicht korreliert, aber es gibt eben diese diese Ansatzpunkte. Einmal Modellarchitektur, kleinere Modelle, weniger, 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, Engineering. Also je weniger ich reinlade in den Kontext, desto schneller geht's dann auch wieder. Bei ist es oft so, also wenn ich's jetzt mal vergleiche mit und Kosten, man will's immer so gut wie möglich, Kosten so niedrig wie möglich. Ist am Ende eher son, sag ich mal, son son Grenzwert, dass man sagt, es darf nicht länger dauern als x. Mhm. Also es
Jan: ist
Maximilian: meistens dann eher noch sone Randbedingung, die aber nicht oder oft nicht optimiert
Fabi: wird. Verstanden, okay. Und hast Du aber vorhin zumindest, meint so, Caching kann auch in bestimmten Fällen, bei bestimmten Modellen irgendwie bis zu 90 Prozent Kostenreduktion bedeuten? So hast Du 'n Punkt bei Laatency, was da was da, Caching irgendwie? Also irgendwie nur so vom vom vom Bauchgefühl her so, was was wir da an Latenzoptimierung haben?
Maximilian: Da da spricht man über deutlich weniger. Also Caching ist für für für die Latenz jetzt nicht der der größte Faktor. Okay. Das ist ja Also
Fabi: Caching bleibt eher Kostenthema als Kosten. Latenzhema.
Jan: Okay.
Fabi: Hui, hast Du noch Fragen zu dem Dreyer Triamriaden und mit mich schon noch mal prompt Engineering und Weil wir ja, genau, vielleicht kommen wir am Ende damit auch wieder zum Thema son bisschen zurück so, weil ich mich jetzt, wir haben uns viel darüber unterhalten, okay, Kontext, ich muss irgendwie, hab irgendwie, ich hab meine Unternehmensinformationen da irgendwie drin, ich segmentiere vielleicht vor meine User, je nach Use Case so. Und aber ich frag mich jetzt den Teil, wo jetzt wirklich die Instruktion, was das was das machen soll. So wie viel, also vielleicht einerseits so, wie viel ist da zu tun? Wie ist so der typische Prozess von dem? Ist es dann doch eher Feintuning? Und auf wie wie wie versiert sind die Leute da draußen? Wie viel wird wirklich daran dann rumgedoktert? Also so wie dieses das Prompt engineering bei diesen Liveapplikationen, das würd mich schon interessieren so, wie wie vielleicht, wie viel müsst ihr da auch unterstützen? So wie viel macht ihr da? Wie viel ist da Standardset? Wie viel passt man das noch mal an, nachdem man einmal seinen Prompt definiert hat?
Maximilian: Also ich würde sagen, wir unterstützen schon immer noch sehr viel im. Also ich glaub, jetzt auch nach 3 Jahren ist das immer noch son Thema, wo sich Leute oft schwertun. Und man man fängt dann meistens an, man fragt ChatGPT, hey, was ist 'n guter Prompt? Und dann, ja, knall man den in eine System Prompt und dann guckt man, was dabei rauskommt. Ist natürlich oft nicht optimal, aber bei Prompt Engineering ist es ist es selbst für mich noch teilweise hart, weil ich komm 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 schwertun. Was mir da sehr geholfen hat, sind wieder wirklich sehr klar definierte, weil die einen schon sehr viel über den prompt sagen. Jetzt gibt's da momentan sehr viele Trends zum. Beispiel, automatisiertes. Also ihr kennt vielleicht irgendwie DS Pi, da gibt's viele solche Packages, die optimieren das, basierend auf den jeweils und haben da verschiedene. Dann gibt's sogar noch Bestrebungen, vielleicht so was automatisiert in Produktion zu machen. Da bin ich jetzt persönlich nicht der größte Fan davon.
Fabi: Die Optimierung, die Optimierung des Prompt in Produktion live.
Maximilian: Ja, wenn wenn irgendwas gesehen wird. Wenn irgendwas gesehen wird, was jetzt wirklich komisch aussieht, kommt wieder auf den Use Case an. Ich bin grad da beim am Anfang auch immer noch ein Fan, das manuell zu machen. Es gibt da son paar Standardsachen, die man eben immer beachten sollte. Also ich würd immer eben versuchen, die Tool Calls so gut wie möglich zu erklären, viele Beispiele mit reinzubringen, wie man sich in gewissen Situationen verhalten soll. Beispiel Outputs reinzugeben, das ist schon mal so, wo ich auf jeden Fall damit anfangen würde. Und dann geht's eben wirklich auch drum, sich jeweils anzuschauen. Am Ende ist wirklich, glaub ich, der Hauptteil der Arbeit im oder ich nenn's mal ich nenn's mal lieber, weil eben dann ein Teil davon ist. Also wirklich richtigen Zeit die richtige Information, großer Teil ist der prompt oder der System prompt und dann eben auch die richtigen Infos aus den Tool Calls oder oder den Knowledge Bases.
Fabi: Ja, und aber hab ich denn ein Eindruck, wo Du meintest, so, ich würd erst mal über die E-Bikes nachdenken? Heißt das so, Du würdest, ich hab jetzt, mir kam direkt in den Sinn so. Also es fasst eher auch beim so, ich muss mir erst überlegen, was rauskommt, schreib vielleicht dafür dann ein paar jeweils und erst dann würde ich meinen schreiben, dann zu gucken, dass ich dahin optimiere. Das heißt, ich würde nicht so, ich hätt mir, ich hätt's mir auch 'n bisschen kreativer vorstellen können, mit sagen, okay, ich, ich sag's, ich probier's meinen Prompt 'n bisschen aus, schau mal, mach mal zehnmal, guck mal, was so rauskommt und
Maximilian: Das ist voll okay. Also genau. Am Anfang mal auszuprobieren und mit einem Prompt zu starten, ist voll okay. Ich würd aber schon versuchen, relativ früh dann wirklich auf das zu wechseln. Aber am Anfang mal Tests zu machen, verschiedene Proms zu probieren, ist in den allermeisten Fällen natürlich gar kein Problem.
Fabi: Okay. Und vielleicht, wenn wir in meinem Kopf da was, was das angeht, irgendwie noch den den Begriff mal Feintuning auch noch mal mit reinwerfen. Wenn Du bei euren Kunden, wie ist denn so das, also gibt es da 'n gutes Verständnis dafür, wann ich für einen Use Case einfach nur den richtigen Kontext und gutes brauche und wann ich vielleicht auch in Richtung Feintuning gehen muss. Also ist ja erst 'n gutes Verständnis dafür da. Zweitens, wie ist so das Verhältnis und wie betrachtet oder wie sprecht Ihr Empfehlung aus, welche Use Cases für was das Richtige sind?
Jan: Ja.
Maximilian: Feintuning ist ein spannendes Thema.
Jan: Mhm.
Maximilian: Wir haben, ich schätze ungefähr vor 2, 3 Jahren, das war, glaub ich, als GPD Four rausgekommen ist und sehr teuer war. Hatten damals viele Kunden überlegt, brauch ich wirklich vor oder reicht mir 3 Punkt 5? Oft war die Antwort, performt irgendwie nicht so gut. Und dann war die Idee, ah, lass es doch mal auf unseren Daten. Das heißt, vor 2, 3 Jahren haben wir in der Tat sehr viel mit unseren Kunden gefeintunet.
Fabi: Mhm.
Maximilian: Die vorrangigen Feintuning Methoden damals waren, hieß damals super weiß Feintuning. Das bedeutet, ich ich bring da Beispiele, wie sollte etwas aussehen? Ich hab da eben solche Frage Antwort Pärchen. Und mein LLM lernt dann basierend darauf. Wir haben immer noch viele Kunden, die so was auch noch heute in Produktion haben, jetzt nicht nicht mit GBD 3 5, aber diese diese Art von Feintuning, die kann immer noch sinnvoll sein für, sag ich mal, Klassifikation, weil Du einfach wie in 'nem Machine Learning Problem die Beispiele mitgibst. Also es es gibt sie noch. Jetzt ist aber das Problem, dass ja dann 2 24, Ende 2 24, glaub ich, eben Modelle in den Markt gekommen sind, angefangen mit unserem O-Ton Modell. Super weiß Feintuning funktioniert nicht mit Modellen. Das heißt, man hat dann eine neue Art von Feintuning gebraucht. Es waren jetzt in diesem Fall funktioniert mit mit Modellen, weil man da eben einen definiert. Der sieht sich dann eben für einen Output diese an, die er eben son Modell immer hat und gibt dann eben Noten und kann dann so das verbessern. Das heißt, dann war ein Thema. Jetzt gab's aber noch ein Problem letztes Jahr, dass alle, also nachdem alles wurde, wurde auf einmal alles. Das bedeutet, Du hast nicht mehr nur dein Modell, sondern Du hast ein Modell, das vielleicht erst mal, dann macht's einen Toolcall, dann gibt's vielleicht wieder ein, dann gibt's 'n Toolcall oder keinen, dann gibt's vielleicht irgendwie Knowledge Retreval, wieder 'n. So was ist superschwer zu fine, weil ja diese Toolcalls, die müssen ja auch irgendwie evaluiert werden, aber Toolcalls, die können ja alles Mögliche sein heutzutage, ne. Also man kann ja entweder irgendwie, man hat eine Websearch oder man hat irgendwie ein Retrieval oder man man hat eine Aufgabe, die ausgeführt wird. Das heißt, eigentlich war reinforcement Feintuning da auch superschwierig. Das heißt, die neueste Art von Feintuning jetzt in diesem Fall war, das dann die Möglichkeit hat, eben solche und auch Tool Calls richtig zu fine tunen. Das war jetzt mal kurz, sorry, jetzt hab ich bisschen ausgeholt, aber zur Geschichte von fineuning. So, und jetzt zur zur Frage, soll man denn fineunen oder nicht? Mein Eindruck ist, fineuning ist ein sexy Thema, jeder will fineunen, jeder fragt die Also ich werd sehr oft über Feintuning gefragt in 20 26. Oh, ist jetzt vielleicht, ich bin mir nicht sicher, aber ich glaub, 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, gefeintunende Modell. Und das Problem am Feintuning ist ja, man muss es ja dann auch immer wieder neu feintunen. Ja. Ja. Das heißt, ich seh neue fine tuning, use cases immer weniger jetzt von verglichen von vor 2 Jahren, sag ich mal.
Fabi: Und kannst Du eine, also, wir haben ja immer am Ende des Jahres mal 'n kleinen Recap, können wir mal schauen, ob das dann funktioniert immer da zu fragen, ob dein ob dein Take stimmt, übrigens immer am Ende des Jahres, unsere Anfang des Jahres, noch mal zu rekapitillieren und zu schauen, haben die zu getroffen? Dann fragen wir dich vielleicht auch noch mal und lassen wir gleich 'n Gastbeitrag einspielen in unserem AI Recap. Kannst Du mir nur noch mal den, also ich hab konnte allen also den Feintuning auch verstehen. So kannst Du noch mal 2 Sätze zu diesem Agent Reforcement Feintuning erzählen? So, weil da hab ich nicht ganz verstanden, was das was das genau bedeuten wird, auch wenn es in diesem Jahr, am Ende des Jahres kein Thema mehr sein wird.
Maximilian: Genau, also das das Hauptproblem von war, dass jetzt die die neuen Modelle oder die neuen Use Cases einfach sehr komplizierte Prozesse sein können. Das bedeutet eben, ich hab ein Model. Dieses Model hat aber die Möglichkeit, sehr viel verschiedene Tools zu, die dann außerhalb dieser sein können, ne. Also die die Tools können ja alles Mögliche machen, die können einen Prozess triggern, die können jemanden anrufen. Also die können eben sehr viel verschiedene Dinge tun. Und, so wie es anfangs immer rausgebracht wurde, hat er einfach keine Möglichkeit, so was zu machen. Also es gab gar nicht diese diese Umgebung, verschiedene Szenarien zu testen und dann auch zu. Also das war eben vor allem dieses Problem, dass Du eben so viele Tools hast und die nicht konntest. Und ist jetzt eben am Ende einfach eine Erweiterung von, die es eben ermöglicht, auch solche Szenarien, solche verschiedenen Toolcalls dann auch zu evaluieren. Und das Ganze kann unter Umständen vorteilhaft sein, weil beispielsweise kann's dazu führen, dass ich das Ganze so gut, dass ich das Ganze so gut mach, dass es am Ende vielleicht dazu führt, dass in Produktion mit diesem Model vielleicht für gewisse, vielleicht im Durchschnitt gar nicht mehr 8 Tools gecallt werden müssen, sondern 4.
Jan: Mhm.
Maximilian: Ja. Und dadurch kann's eben wieder sein, dass es günstiger wird, schneller wird vor allem in die in diesem Fall. Und das kann mir dann da eben son paar Vorteile geben. Ich kann mal ein Beispiel, Use Case, vielleicht noch sagen, wo man's, wo wo wo ich's grad gesehen hab, wenn es hilft. In in einem Text to SQL Fall, wo man vielleicht eine Datenbank hat. Ich ich möchte Infos aus dieser Datenbank holen. Je nach Frage muss ich vielleicht, braucht eine Info von der Tabelle, muss wieder nachdenken, braucht eine Info von 'ner anderen Tabelle, muss wieder nachdenken, muss das Ganze zusammenfassen. Und da hatt ich jetzt zum Beispiel mal einen Fall gesehen, das war jetzt aber auch 'n sehr, also technisch versierter Kunde, die dann in diesem Fall das Agent gemacht haben und dadurch noch mal einfach die erhöhen konnten, also bessere Ergebnisse erzielen konnten. Ich sag jetzt noch, einen großen Nachteil, also einen der mehreren großen Nachteile. Das Ganze fällt natürlich son bisschen in sich zusammen, wann immer man zum Beispiel einfach neue Tools hinzufügt, ja, weil das Feintuning passiert natürlich auch immer auf der momentanen Modellarchitektur. Mhm. Und oftmals 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 'n neues starten.
Fabi: Okay. Ja. Verstanden. Jetzt, wenn wir auf die Zeit blicken, erst mal Jan, hast Du noch Themen, die Du auf jeden Fall gerne noch durch Ich bleibe. Backen würdest. Dann würd ich vielleicht gern noch mal, weil wir uns am Anfang über die, ich sag mal 3, ja son 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 die Dinge, die wir jetzt besprochen haben. Welche zusätzlichen Probleme bringen bringen Agents in production irgendwie noch mit? Irgendwas, was wir gar nicht jetzt beackert haben, weil's ja schon am Ende 'n bisschen andere Anwendungsfälle sind, als wir jetzt oftmals beispielhaft besprochen haben, möchtest Du sagen, da ist noch irgendwie ein ein Bereich, den wir jetzt da in dem Zuge noch gar nicht betrachtet haben. Sind's noch mal andere Probleme, die eure Kunden haben, die dann Agents in Production entwickeln? Habt ihr eher 'n bisschen offen gefragt.
Maximilian: 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.
Fabi: Das Gleiche so bei dem sozusagen hat die gleiche Problem.
Maximilian: Genau, sondern wieder Workflow Automation. Das heißt, ich muss irgendwie sicherstellen, dass das Ganze dann noch gut funktioniert. Und hab da vielleicht auch wieder eine bestimmte Umgebung, in der das Ganze gemacht wird. Also grad dieses ganze Thema, hab ich Gefühl, wurde jetzt recht gut verstanden im klassischen Chatbot Kontext. Ja. Aber also die nächste Welle, die auf uns zurollt mit den ganzen Agents, die da munter in Produktion gebracht werden, teilweise geht das ja auch superschnell, ist wirklich, wie wie stellen wir sicher, dass wir solche Agenten dann auch in Produktion gut evaluieren? Und da ist es, glaub ich, auch schwieriger, Standards zu finden, weil auch jeder Agent natürlich eigentlich eine komplett andere Aufgabe haben kann.
Fabi: Mhm. Okay, verstanden. Und vielleicht noch mal eine letzte Frage hin zur Umsetzung, wenn wir uns über jeweils und unterhalten haben. Wie ist es denn in der Realität, wenn man jetzt das Ganze mit mit euch, mit Open AI und eurer API machen will? Ist das am Ende was, diese jeweils und 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 übernimmt? So wie wie ist das wirklich jetzt in Ja. Wie wie mach ich das?
Maximilian: Wir haben eine API Plattform. Das heißt, wir haben natürlich eine gewisse Anzahl an Modellen und man kann auch auf unserer Plattform fine tunen und unsere eigene nutzen.
Jan: Wir haben auch eine
Maximilian: jeweils Plattform. Uns ist es aber tatsächlich relativ, also egal, wo die gemacht werden. Man kann genauso andere Tools für, also es gibt ja da, es gibt auch andere Möglichkeiten, zu machen. Uns ist immer nur wichtig, dass sie gemacht werden. Und der, ich glaub so, der der Grund, warum wir auch unsere jeweils Plattform released haben, ist, weil wir immer noch gesehen haben, dass es einfach oftmals noch ein Problem ist und das ist. Das heißt, wir wollten eben auch eine Möglichkeit, dass man auf unserer Plattform jeweils machen kann. Aber wie gesagt, ob man's jetzt, wo man's jetzt macht, ist jetzt eigentlich zweitrangig, weil am Ende ist es dann auch technisch nicht nicht superkompliziert, son LLM Creator zu erstellen.
Fabi: Okay, vielen Dank. Dann haben wir jetzt noch für unsere Folge 2 Housekeeping Sachen, sag ich mal, zu tun. Das sind nicht Housekeeping, aber Dinge, die wir immer tun. Zuerst die letzte Frage mit, haben wir irgendeine Frage, die wo Du dachtest so, warum haben Jan und Fabi die nicht gestellt, wenn wir uns über a unterhalten? Das das wäre doch eine Frage gewesen, bei die hätten wir uns jetzt noch gut austauschen können. So also gibt es irgendeine Frage, die Du gerne hättest, dass wir sie dir gestellt hätten?
Maximilian: Also ich würde sagen, technisch haben wir, glaub ich, das wichtigste Mal behandelt. Ich will vielleicht noch eine Sache sagen zum zum Standort Deutschland und und so, wie technisch die Leute auch sind. Ich hab den Eindruck, dass wir momentan wirklich sehr viel gute Sachen machen. Also man man sieht das wirklich, ich bin sehr oft auf Hackathons, wo ich dann viel mit mit mit Studierenden mach, die dann unsere API verwenden. Deutschland ist 1 der größten Developer Märkte. Ich sag das, weil ich tatsächlich oft die Frage gestellt bekomm, wie wie läuft's mit mit mit Deutschland und sind wir denn da alle so hinterher? Und es ist ja alles katastrophal. Ich hab den Eindruck jetzt vor allem in den letzten Monaten und jetzt wirklich im AI Bereich, Start ups Bereich, Developer Bereich machen wir da wirklich, wirklich superviel gute Sachen, haben das haben da super Start ups auch und sind da, müssen uns da technisch auf jeden Fall gar nicht verstecken.
Fabi: Das ist doch schön, also son schönes Statement fürs Ende. So, damit hören wir gerne. Ich dachte schon alles gemacht, auch mit Deutschland, oh jetzt will, am Ende würd uns wirklich noch mal alle in die Pfanne hauen so, aber ist doch nicht. So so rum so rum sehr viel besser. Cool, dann kommen wir zu unserem letzten Thema und zwar den. Haben wir denn Einspieler, Jan? Ich hab schon lange nicht mehr gemacht. Die 3 Personen Podcast, 3. Jan, hast Du uns das mitgebracht?
Jan: Ich hab einen Pick und eine kleine Anekdote, die hier auch irgendwie gut reinpasst. Deswegen hau ich die jetzt noch einmal kurz raus, weil wir auch über Realtime Chatbots und Agents so was alles gesprochen haben. Ich hab letzte Woche mit dem Callcenter der Lufthansa telefoniert. Ich hab letzte Woche Woche mit dem Callcenter der Lufthansa telefoniert. Mhm. Und hab nach 10 Sekunden gemerkt, dass ich nicht mit einem Menschen rede, sondern eben mit 'nem mit 'nem Boyspot. Und weil Max ja auch das Thema Latenz angesprochen hat, der muss natürlich immer son bisschen nachdenken, wenn dann so meine Antwort kam. Und was sie dann in der Zeit gemacht hat, war ultracool und 'n bisschen. Sie hat nämlich immer so gesagt so, ja, Moment, ich schau das im System da und dann hast Du son Tastaturklacker gehört. Ja, ja. Also das ist so, das das ist so das von so, ja, Du Du armst irgendwie menschliches Verhalten nach, irgendwie so was zu überbrücken und was zu implizieren. Fand ich megalustig. Nach 5 Loops hat sie mich 'n bisschen genervt so, ja. Weil es halt auch immer genau dasselbe Tastaturklackein war. Also wenn Du mal dieses dieses Audio Loop dann so einmal gehört hast, dann war's auch irgendwie 'n bisschen witzlos. Aber ich fand die
Maximilian: Darf ich dir kurz einhaken?
Jan: Ja, gerne kurz,
Maximilian: weil ich find's superspannend, weil also der Grund oder das technisch wieder sehr spannend, die Modelle haben natürlich eine superniedrige Latenz. Das Problem ist nur, dass ja manchmal eben ein Toolcoi gemacht werden muss.
Jan: Ja, ja, natürlich. Und dann muss da eben was
Maximilian: geholt werden. Und dann, aber das Ding ist, dass der Kunde, die Kundin 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 sone Voice Supervisor Architecture, wo man dann etwas, ein anderes LLM gibt, aber dann währenddessen eben sagt, so und dann diese Kimper rein macht's.
Fabi: Manchmal würde man sogar einbauen, auch wenn man direkt eine Antwort geben könnte, weil die Leute es erwarten. Ich muss jetzt jetzt gewartet und so, ich muss es verzögern.
Jan: Ja. Okay, also das nur die die kleinen Ja. AI Anekd gut am Rand. Meine Fix, die ich mitgebracht hab, sind, ich hab mich ja letzte Woche hier bei unserem Fortbildungstag viel mit lokaler AI beschäftigt und was da so geht. Und hab jetzt einfach mal sone Kombi mit am Start. Und zwar hab ich ja für unser Projekt einmal Local Transkripion 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 ja 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, hab ich das auch lokal gemacht mit Olama. Da kann man mit 'n paar verschiedenen Modellen rumexperimentieren. Ich hab Lama, Gwen und T-o-SS genommen. Alle im Prinzip gleichermaßen wertvoll. Latenz auch in dem Fall eher so, weil ich die 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, VWM 4, Max Pro Ultra, schieß mich tot. Aber das läuft ja auch alles bei uns okay ganz gut.
Maximilian: Könnt 'n GPT Name sein.
Fabi: Ja. Schieß mich tot, ne? Was bei welcher Teile?
Jan: Ja, deswegen das nur mal, schaut euch das mal an. Das ist ganz cool, da kann man coole Sachen mitmachen. Vielleicht erzählen wir irgendwann mal noch 'n bisschen mehr, was wir da mitgemacht haben.
Fabi: Ja, cool. Das also, das, für mich waren das sehr viele und noch eine Anekdote so. Ich hab jetzt nicht mitgezählt, aber
Jan: Das egal, ich muss am Ende ins CMF meisten, von daher darf das
Fabi: Dann, ich halt's 'n bisschen ich halt's 'n bisschen simpler mit meinem so. Vielleicht auch 'n Tool draußen, was schon viele von euch nutzen, aber ich nehm's mal als, weil ich's jetzt in letzter Zeit sehr viel aktiver genutzt habe. Und zwar sind es wie wie AI als auch, was son bisschen ja 'n node basiertes Tool ist, mit zu arbeiten. Und ich einfach ganz interessant fand, weil ich vorher, also klar, ich kannte die Tools, hab sie selbst noch nicht so viel eingesetzt, aber so grade, wir nutzen's viel für Imagegeneration und Imagegeneration Pipelines aufzubauen, die wir sozusagen nicht dann in Produktion on the fly generieren, sondern eher in 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 ein bisschen technischer, vielleicht ein bisschen besser hin zur Automatisierung, bisschen mehr bisschen mehr verschiedene und man kann einfachere verschiedene Modelle anbinden. Ist dann 'n bisschen mehr Enduser- und auch designerfokussiert, aber trotzdem für mich als Developer, als auch Productmanager auch 'n sehr, sehr gutes Tool, was 'n guten Grundstock an möglichen Notes, was man so für Imagegenerierung als auch Videogenerierung braucht. Beides sehr coole Tools. Ich denk nicht, das Nischen Thema, Dinge, die ihr noch nie gehört habt, aber noch mal die Empfehlung so grad, wenn ihr in Richtung Imagegeneration und das sozusagen nicht eskaliert, sondern nur vereinzelt nutzen wollt. Sehr coole Tools. Dann, Max, hast Du uns auch einen mitgebracht?
Maximilian: Ja, ich hab den, ich hab's gesagt kurz im im Vorgespräch. Ich hab den noch mal spontan umgeändert, weil ich gestern noch die neueste Episode über Coding Agents mit Julia Cordik gehört hab.
Jan: Mhm.
Maximilian: Und ich hab Jetzt weiß
Jan: jeder, wann wir die Folgen aufnehmen. Jetzt ist es absolut gedehnt. Nein, ist voll okay, ist voll okay, aber ich muss die Hörer, mal gucken, ob's die Hörer checken.
Maximilian: Jan Fabi, wer wer hatte das Book als
Jan: Ich hab das mitgenommen.
Maximilian: Genau. Und das fand ich so gut. Ich kenn das Buch auch und ich kenn vor allem, also die die Autoren und den der Steve Jergy. Also ich ich rate allen, die sich, wenn man sich den noch nicht angesehen hat, guckt euch mal 'n paar Youtube Videos an oder auch, der war also im Mail Space Podcast vor Kurzem, ein ein wirklich, also ich ich find ein ein superwitziger Typ und hat eine sehr starke Meinung auch. Aber also ich ich find ihn einfach superwitzig und supercooles Buch. Und das hab ich jetzt dazu inspiriert, einfach mal noch 'n paar Bücher zum ganzen Thema jeweils zu nennen. Also White Coding ist gut. Es gibt im jeweils Bereich noch nicht so viel tatsächlich. Aber ich glaub, 2 gute, die man auf jeden Fall nennen kann, ist einmal jeweils for AI Engineers. Das heißt, ich hab ja schon gelesen, stell ja schon kein. Und dann gibt's noch 1, das hab ich noch nicht gelesen, aber hab gutes Dank davon gehört. Das ist heißt das. Das ist vor, und jetzt muss ich noch mal gucken, von wem war denn das? Die 2 sind auf jeden Fall sehr gut. Und dann generell ein ein Buch, das mir sehr Spaß gemacht hat, zu LLMs generell, ich weiß, sie kennt ja vielleicht auch, das ist Bild an LLM from Scratch und jetzt neuerdings dann auch bald LLM von dem Deutschen tatsächlich, Sebastian Raschka, der dann da mit den USA lebt. Die die fand ich sehr gut und das sind wirklich auch Bücher, die sind nicht superkompliziert und wird eben sehr gut einmal Basics zu LLMs erklärt und dann eben natürlich auch das ganze Thema.
Fabi: Ja, sehr cool. Das sind doch viele coole. Ja, und Du wirst Spaß haben die alle ins CMS Ich hab auch damit
Jan: gespielt grade. Sehr gut.
Fabi: Ja. Kriegen 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 glaub, das war eine sehr, sehr wertvolle Folge. Hat viel Spaß gemacht. Vielen, vielen Dank, dass Du da warst.
Maximilian: 1000 Dank. Gerne.
Fabi: Und dann auch euch vielen Dank fürs Zuhören, wie immer gerne Feedback an Podcast at programmier.bar oder über unseren Discord Channel und bis zum nächsten Mal.
Jan: Macht's gut. Tschau. Bis dann. Tschau.