{
  "video_id": "C19JUX3GbcA",
  "channel_slug": "arizeai",
  "channel_handle": "arizeai",
  "title": "Agent and LLM Evaluation for AI Product Managers",
  "duration_seconds": 2579.0,
  "url": "https://www.youtube.com/watch?v=C19JUX3GbcA",
  "upload_date": "",
  "transcript": "[Musik]\nAlso, mein Name ist Aman.  Ähm, falls wir\nvorher noch nicht in Kontakt standen oder uns noch\nnicht getroffen haben, äh, ich bin Produktmanager bei\neiner Firma namens Arise, wo\nSie sich heute im Zoom-Raum befinden.  Wir\nsind ein Unternehmen für Evaluierungs-Observability und werden gleich genauer darauf eingehen,\nwas das\nbedeutet.  Um aber\nein wenig Hintergrundinformation zu geben: Ich\nselbst habe einen technischen Hintergrund.  So\nbegann meine Karriere im Ingenieurwesen und ich\narbeitete dann 2017/2018 bei einer Firma namens Cruz an selbstfahrenden Autos\n.  Kurz darauf, äh,\nwährend meiner Zeit bei Cruz, arbeitete ich\nan Evaluierungssystemen, die\nIngenieuren und Entscheidungsträgern halfen zu beurteilen,\nob der Code, den wir\nauf dem Auto auslieferten, das Auto\nbesser oder schlechter machte.  Das klingt sehr vertraut\nnach der Agentenwelt, in der wir heute leben.\nZwischen Cruise und Arise habe ich tatsächlich\nbei Spotify gearbeitet, einem kleinen\nMusikstreaming-Unternehmen, vielleicht haben Sie schon mal davon gehört.\nEs war eine\nwirklich tolle Gelegenheit,\ndort an Empfehlungssystemen zu arbeiten, und während meiner Zeit\ndort habe ich festgestellt, dass es selbst bei\nSpotify eine Lücke in der Beobachtbarkeit und Bewertung von Modellen gab. Das hat\nmich dazu gebracht, nach\neinem Tool in diesem Bereich zu suchen, und so habe ich Arise\nentdeckt.\nSpotify ist übrigens einer unserer\nKunden bei Arise Now.  Wir haben also das große\nGlück, mit einigen fantastischen\nUnternehmen zusammenzuarbeiten.  Ich werde gleich erscheinen\n.  Viele unserer Erkenntnisse und\nLehren stammen jedoch aus dieser Zusammenarbeit\nmit Startups, Digital\nNatives und KI-Unternehmen, denen wir geholfen haben,\nihre KI-Systeme in die Produktion zu überführen.  Und ich habe immer noch das große\nGlück, dass ich bis heute an Evaluierungssystemen arbeiten darf, und zwar schon seit\nBeginn meiner Karriere.  Also,\nwir werden uns mit\nder Rolle des KI-Projektmanagers beschäftigen.\nIch sehe einige KI-Produktmanager im\nChat, was super ist.  Wir werden auf jeden Fall\nein wenig darüber sprechen,\nwas sich in dieser Rolle verändert und einige\nBeobachtungen, die ich bei der\nArbeit mit diesen\nUnternehmen gemacht habe. Anschließend werden wir über Evaluierungsprozesse sprechen,\nwo sich Ihr Unternehmen\nheute befinden könnte, wenn Sie in Ihrem Unternehmen oder Team an KI-Produkten arbeiten. Zum Schluss werden\nwir uns damit befassen, wie man\nmit KI-Ingenieuren bei Evaluierungen zusammenarbeitet,\nsodass Sie als Produktmanager tatsächlich\nzur Qualität des\nEndprodukts beitragen. Wir werden auch ein\nwenig darüber sprechen, was das bedeutet und\nwelche Arbeitsabläufe damit verbunden sind.  Ein\npaar Worte zu uns.  Äh, also ich hatte\nim letzten Jahr wirklich Glück.  Es\nwar eine unglaubliche Reise,\nmehr über die Erkenntnisse im Zusammenhang mit der\nEvaluierung von KI-Agenten und KI-\nProdukten zu berichten.  Hier sind ein paar\nRessourcen.  Ich werde Sie darauf hinweisen, Sie können\nsie gerne später nachschlagen, und\nam Ende gibt es auch einen Link, um\neinige davon zu finden.  Aber wir hatten das\nGlück, einen kostenlosen Kurs mit\nAndrew, einem Experten für Deep Learning und KI, zum Thema Evaluierung von KI-\nAgenten zu absolvieren – völlig kostenlos.  Äh,\ndas probieren viele Leute aus.  Es ist sozusagen ihr\nerster Versuch, tatsächlich einen\nEvaluierungs-Scratch-Code zu schreiben.  Es handelt sich also um einen praxisorientierten\nKurs.  Also, ich kann dir das nur wärmstens empfehlen\n.  Äh, und wir haben auch einen\nNewsletter mit Lennys Podcast erstellt.  Es ist\ntatsächlich das drittmeistgelesene Buch des\nletzten Jahres.  äh, das ist\nProduktmanagement, Produktmanager.  Ich kann es also nur\nwärmstens empfehlen, das auch mal anzusehen\n.  Das ist ein toller Beitrag, der\ndie Grundlagen von\nEvaluierungsprodukten gut erklärt.  Und wir hatten außerdem das\nGlück, mit einigen Projektmanagern aus\nden besten KI-Unternehmen der\nWelt zusammenzuarbeiten.  Ich habe Spotify erwähnt, aber wir\narbeiten auch mit Unternehmen wie Dualingo, Uber,\nReddit, Instacart, DoorDash und\nvielen anderen zusammen.  Und hier ist nur ein kleiner Ausschnitt der\nLogos einiger Unternehmen, mit denen\nwir das Glück haben zusammenzuarbeiten.  Äh, mir\ngefällt besonders dieses Zitat auf der\nlinken Seite, das besagt, dass genau so\nTeams heutzutage aufgebaut werden.  So\nentwickeln sie KI-Produkte.\nAuf dem einen Bildschirm befindet sich der Cursor, auf\ndem anderen die Anzeige „Arise“.  Und ähm, wir haben vor Kurzem,\nAnfang dieses Jahres, unsere Serie-C-Finanzierungsrunde abgeschlossen.\nWir werden also noch eine Weile da sein und weiterbauen, da wir\nFinanzmittel von Microsoft, Data Dog\nund einer Reihe anderer Investoren erhalten haben.  Wir haben also das Glück,\nmit Hunderten von Kunden auf\nunserer AX-Unternehmensplattform sowie\nmit Phoenix, das Open Source ist, zusammenzuarbeiten.  Und\nich werde auch kurz auf Phoenix eingehen\n.  Wenn Sie also aus\nSicherheitsgründen oder\nanderen internen Gründen nicht\nmit\nArise AX beginnen können, stehen wir Ihnen gerne für ein Gespräch zur Verfügung und\nverweisen Sie auch gerne auf unsere Open-\nSource-Tools, die sich einfacher\nin Ihrer eigenen Umgebung einrichten lassen\n.  Heute werden wir uns aber\nhauptsächlich mit Grundlagen beschäftigen.  Es wird\nhauptsächlich darum gehen, wie man\nmit der Evaluierung beginnen kann.\nUnd wir werden uns künftig stärker auf\nArbeitsabläufe konzentrieren.  Einiges davon mag Ihnen\nbekannt vorkommen, aber ich\nbeantworte gerne alle Ihre Fragen\n.  Wenn du sie im Chat postest,\nbehalte ich sie im Auge.  Aber fangen wir erst einmal\nmit einer Art Grundlage an.  Was ist ein KI-\nProduktmanager?  Und welche Art von\nKI-Projektmanager sind Sie eigentlich bzw. welche Art von Projektmanager möchten Sie sein?  Äh, also\nich sehe die Welt im Grunde als eine Mischung aus\ndrei Arten von KI-Projektmanagern.  Da gibt es zum Beispiel\ndie KI-Plattform PM, mit der man anfangen könnte.  Das ist die\nPerson, die dafür verantwortlich ist,\ndass die Modelle im gesamten\nUnternehmen einigermaßen funktionieren.  Egal, ob Sie wissen,\nwelche LLM-APIs Sie verwenden, oder ob\nSie Anthropic,\nOpenAI oder etwas anderes verwenden – Hauptsache, Sie\nverwalten die richtigen Daten im gesamten\nUnternehmen.  Wenn\nSie also Benutzerdaten, personenbezogene Daten oder\nmöglicherweise sensible Informationen senden, sollten\nSie diese auf eine Art und\nWeise verwalten, die einer Plattform entspricht, und\ndie richtigen Modelle und Strategien auswählen.\nDa ist der KI-gestützte Projektmanager.  Das ist etwas, was ich\npersönlich sehr befürchte: Sie\ngehen nicht über einfache Anleitungen hinaus\nund nutzen vielleicht Tools wie Cursor, um\nIhre Aufgaben\nals Produktmanager tatsächlich zu erfüllen.  Wenn Sie mir folgen\n, werde ich Ihnen mehr über\npersönliche Betriebssysteme und die Möglichkeit,\nIhr eigenes persönliches Betriebssystem zu erstellen, erzählen.  Aber\neigentlich sehe ich KI-gestützte PMS eher so:\nSie entwickeln Agenten, die ihnen helfen,\nihre eigenen Arbeitsabläufe\nschneller und effizienter zu erledigen und gleichzeitig\nihre Arbeit effektiver zu gestalten.  wenn es um die\nZusammenarbeit zwischen verschiedenen\nInteressengruppen geht.  Äh, das ist definitiv so etwas wie\ndie neue Kompetenz, die viele\nProjektmanager meiner Meinung nach zunehmend anerkennen:\nKI effektiver in ihrer Arbeit einzusetzen.\nUnd zu guter Letzt werden\nwir uns heute vor allem mit der\nRolle des Produktmanagers für KI-Produkte beschäftigen.\nUnd genau diese Person interessiert sich dafür, wie\ndie KI-Ausführung\nin unserem Endprodukt aussieht.  Sollten wir\neinen Chatbot auf den Markt bringen?  Sollten wir\nStoffreste einbeziehen?  Oder sollte es sich um einen\nHintergrundagenten handeln, der\nunsere Daten verarbeitet und im\nHintergrund arbeitet, sodass\nder Benutzer beim\nersten Kontakt vielleicht gar nicht damit konfrontiert wird? Diese Person ist in der Regel im\nTeam tätig und arbeitet mit den KI-Ingenieuren zusammen. Sie ist für die detaillierten\nEvaluierungen zuständig und arbeitet\nmit den KI-Ingenieuren und\nStakeholdern zusammen, um zu\ndefinieren, was „gut“ bedeutet und wie man\ndies im gesamten Produkt messen kann.  Die\nKurzfassung davon\nist, dass ich glaube, dass sich diese\nBereiche mit der Zeit immer\nmehr überschneiden werden, weil KI\nin so gut wie jedem einzelnen\nProdukt, das wir verwenden, enthalten sein wird, genau wie Datenbanken.\nEs wird also gewissermaßen verschwinden, ein KI-gestützter Projektmanager\nwird einfach zu irgendeiner Art von Projektmanager werden, weil\nKI die Art und Weise sein wird, wie wir arbeiten.  So werden\nwir mit unseren Modellen umgehen.  So werden\nwir auch die Evaluierung unserer\nProdukte durchführen.  Vielleicht hilft Ihnen ein mentales\nModell dabei, über sich\nselbst und Ihre Rolle nachzudenken. Denn\nAIPM funktioniert nicht im luftleeren Raum, sondern\nSie arbeiten mit technischen Anwendern zusammen, mit\ntechnischen Mitarbeitern in\nIhrem Team, wie Ingenieuren, Entwicklern oder\nehemaligen Data Scientists, die\nModelle erstellen. Diese Personen sind in der Regel\nfür Code-\nAutomatisierungspipelines und Frameworks verantwortlich, wenn\ndas KI-Produkt überhaupt erst entwickelt wird.\nAndererseits sehen wir auch viele Teams\nmit Domänenexperten.  Hierbei handelt es sich um\nFachexperten, wie beispielsweise\nRechts- oder Medizinexperten, je nach Art\ndes Unternehmens oder\nGeschäftsmodells, das Sie aufbauen. Diese\nExperten sind auf einem bestimmten Gebiet spezialisiert und arbeiten möglicherweise\nmit dem\nProduktmanager zusammen, um Aufgabenstellungen und\nEvaluierungsdaten zu erstellen. Es handelt sich also um eine teamübergreifende\nZusammenarbeit, und\nich sehe diese Trennlinie oder\nBarriere zunehmend verschwinden, wenn wir darüber\nnachdenken, wer tatsächlich an der\nEvaluierung mitarbeitet.\nEvaluierungen sind also die Möglichkeit, unternehmensweit\nEinblick in die Leistung\nIhres KI-Systems zu erhalten –\nvon der Benutzererfahrung über die\nProduktqualität bis hin zu Kennzahlen und\nKPIs.  Okay, lasst uns ganz schnell zu den Evaluierungsreisen kommen\n.\nEs ist das vierte Quartal 2025. Wir erleben das doch alle\ngerade, oder?  Es ist November.   Gibt es sonst noch\njemanden, der die Planung für das erste Halbjahr in Angriff nimmt\n? Möchte sich gerne im Chat melden?  Ich weiß, dass ich es bin.\nDenken wir vielleicht schon ein bisschen darüber nach, was\nnächstes Jahr passieren wird?  Hey, wir müssen\ndie Beteiligten auf einen Nenner bringen und unsere Dokumente einreichen\n. Wer plant denn sonst noch gerade das erste Halbjahr\n?   Das geht\ndefinitiv nicht nur mir so.  Ich bin mir ziemlich sicher, dass es die\nLeute in diesem Raum haben.  Oh mein Gott.\nJa, du hast es im Januar.  Okay, für manche mag\ndas noch etwas\nfrüh sein, aber\nSie befinden sich ja bereits in der Planungsphase, richtig?  Und\nich erinnere mich, irgendwo gelesen zu haben – ich\nweiß nicht mehr wo –, dass es das Jahr der\nAgenten war, richtig?  2025 ist das Jahr der\nAgenten.  Aber wo sind all diese\nAgenten, die uns dieses Jahr versprochen wurden?\nDas ist es, was sich viele\nFührungskräfte in diesem\nMoment fragen.  Diese Diskussionen\nbeobachten wir auch bei unseren Kunden und in\nderen Organisationen.  Hey, wir hatten ein Team, das\nan Agenten arbeitete.  Sie haben das\nganze Jahr über daran gearbeitet, aber es ist\nnoch nicht veröffentlicht.  Oder falls es veröffentlicht wird, handelt\nes sich um einen internen Test.  Es\nfunktioniert nicht einmal so, wie es sollte.\nWas tun Führungskräfte in einer solchen\nSituation?  Oder CPOS oder CTOs?\nEntschuldigung, falls Sie ein CPO oder CTO sind.  Das klingt jetzt vielleicht etwas\nspöttisch,\naber vielleicht lässt sich das ja mit einem Hackathon beheben.\nWeißt du, vielleicht ist genau das, was wir brauchen.  Wir\nmüssen alle in einen Raum bringen.  Wir werden uns\neine Woche Zeit nehmen, die Woche vor\nThanksgiving oder so.  Wir werden\nalle dazu bringen, KI-Systeme und\n-Agenten zu entwickeln.  Wir werden die Sachen veröffentlichen\n, oder?  Das wird hervorragend funktionieren.\nDas ist es, was unser\nProblem lösen wird.  Nun, was wird letztendlich\nin dieser Welt geschehen?  Setzen wir\nunsere Hüte auf und tun so, als würden wir jetzt einen\nHackathon veranstalten und wir wären der Projektmanager in diesem Team.\nUnd das müssen wir übrigens auch\nselbst tun.  Das\nist eine Erfahrung, die ich\nselbst auch gemacht habe,\nsogar in einem KI-Unternehmen.  Und als Erstes\nbaut man üblicherweise den\nAgenten oder das KI-Produkt.\nLasst uns das kurz überdenken.  Vielleicht\nist es ein Prototyp für einen Kundensupport-\nBot, der auf unserer Dokumentation aufbaut.  Das wäre\netwas, was ich mir für unser Produkt wünschen würde,\nnicht wahr?  Wo man einfach hingehen,\nFragen stellen und Antworten bekommen kann.  Und\nwenn Sie das ausliefern, haben Sie vielleicht\ndie Dokumente genommen, sie in Abschnitte unterteilt,\neinen Agenten erstellt, der rag ausführen und die Dokumentation nachschlagen kann\n, vielleicht sogar eine\nWebsuche durchführen, vielleicht sogar API-Aufrufe tätigen kann.\nUnd wir haben es wirklich sehr,\nsehr schnell gebaut.  Ein bisschen ambitioniert, aber wir haben\nes veröffentlicht.  Und für manche Nutzer funktioniert es\nvielleicht, oder?  Dies funktioniert für unsere\ninternen Benutzer.  Es eignet sich, wenn ich\ndas Produkt testen möchte.  Und vielleicht\nfunktioniert es ja manchmal, aber wir wissen auch, dass es\nNutzer geben wird, die sich\nbeschweren.  Wenn du das\nLeuten außerhalb deines Teams oder einem anderen\nTeam zeigst, werden die sagen: „Hey, das\nfunktioniert nicht richtig. Das ist\nnoch nicht fertig. Ich habe\ndrei Fragen gestellt, und zwei davon\nwaren falsch. Eine war richtig. Okay,\nsuper.“  Und die Realität ist, dass\nich das für viele interne Anwendungsfälle tatsächlich für ausreichend halte\n.  Vibe-Codierung oder es\nheißt „keine Auswertung“, aber eigentlich ist das Vibe-\nAuswertung.  Hierbei handelt es sich lediglich um eine Betrachtung des\nErgebnisses.  Ich denke, es ist völlig in Ordnung,\nVIB-Ventile in seinem Produkt zu haben\nund VIB-Ventile zur Produktentscheidung zu nutzen,\nsolange diese Produkte\nnicht die Geschäftsergebnisse beeinflussen.\nSolange es sich nicht um Dinge handelt, die\nSie tatsächlich zur Datenanalyse, zur Durchführung von Analysen, zur\nEntscheidungsfindung in Unternehmen oder zur Präsentation vor einem\nEndkunden verwenden werden.  Wenn Sie lediglich einen\nPrototyp erstellen und sich\nschnell einen Eindruck von UI/UX verschaffen oder ein neues Agenten-\nFramework ausprobieren möchten, ist dies für einen Prototyp vollkommen ausreichend\n.  Wenn Sie aber tatsächlich mit der\nProduktion dieses Prototyps oder dieses PCs beginnen möchten, haben Sie wahrscheinlich schon einmal den Begriff\nEvaluierung gehört.  Sie\nbenötigen eine Bewertung.  Die Menschen müssen\nEvaluierungsprozesse durchführen.  Was sind Eval-Werte und warum sind sie\nwichtig?  Die Realität ist, dass wir wissen, dass dies\nwahr ist.  LLMs halluzinieren, aber unsere Aufgabe\nist es, dafür zu sorgen, dass sie\nuns, unser Unternehmen oder unsere Marke nicht in Verlegenheit bringen.\nUnd Sie müssen mir das nicht einfach so glauben\n.  Die IT-Leiter der Unternehmen, die\nuns LLM-Abschlüsse verkaufen, sagen buchstäblich dasselbe\n.  Sie sagen uns, dass das\nSchreiben von Evaluierungsberichten\nwichtig werden wird, um die\nErgebnisse dieser Systeme tatsächlich zu messen.  Sie haben CPO\nvon anthropic.  Wenn es eine Sache gibt, die wir den\nMenschen beibringen können, dann ist es die, dass das Schreiben von Evaluationen\nwahrscheinlich das Wichtigste ist.  Glauben Sie mir also nicht einfach so\n.  Es sind\nbuchstäblich die Leute, die Ihnen das\nProdukt verkaufen und Ihnen sagen, dass Sie wahrscheinlich\nüber eine Bewertung nachdenken sollten.  Und das ist\netwas, was ich von\nIngenieuren und Ingenieurteams immer wieder höre.\nWir behandeln eval einfach wie Unit-Tests,\nrichtig?  Wissen Sie, warum sich der\nProduktmanager überhaupt in diese\nDiskussion einmischt?  Eval sind lediglich Unit-Tests.\nLasst mich meine Arbeit erledigen.  Ich werde jetzt\neval schreiben.  Verschwinden Sie von hier,\nProduktmanager.  Kehren Sie zur Erstellung der Spezifikationen zurück.  Warum befinden\nSie sich in diesem Teil des Büros?  Äh,\ndas ist nicht der Ort, an dem die Kunden oder der Projektmanager sein sollten\n.  Tatsächlich\nglaube ich, dass unsere Herangehensweise an die\nEvaluierung etwas anders ist\nals beim traditionellen Softwaretest.\nPriyanka hat eine hervorragende Frage zu\nFrameworks für den Aufbau von Traces, Spans\nund Observability.  Darauf kommen wir gleich noch zu sprechen\n.\nPriyanka, das ist eine gute Frage.  Aber\nbetrachten Sie Unit-Tests und\nSoftwaretests eher als einen Hochgeschwindigkeitszug auf einer\nStrecke, auf der Sie tatsächlich... nun ja, das\ntrifft an der\nOstküste nicht wirklich zu, weil die Züge dort\nnie pünktlich sind.  Aber wenn man sich in einem\nLand wie Japan befindet, wo ein\nZug, der um 10:00 Uhr abfährt, voraussichtlich gegen\n11:00 Uhr irgendwo ankommt.  Es wird\nzu diesem Zeitpunkt dort eintreffen.  Das liegt an\njahrelangen, strengen Tests auf System-,\nIntegrations- und Komponentenebene, um die\nZuverlässigkeit des Zuges sicherzustellen.   Bei\nEV-Ventilen kommt man eher einer Fahrprüfung nahe,\nbei der man tatsächlich versucht zu messen,\nwie sich das System in einer Art\nkomplexer, chaotischer Umgebung verhält.  Man kann sich\ndas also eher wie eine Autofahrt in New\nYork vorstellen, richtig?  Die Umwelt\nverändert sich.  Vielleicht wird sich auch die Art und Weise, wie\nSie Fußgänger auf\nder Straße wahrnehmen, und wie das genau funktioniert,\nständig verändern.\nMan versucht also zu messen, dass\nnicht jeder gleich fährt,\naber wer einen\nFührerschein besitzt, besteht diesen Test.\nDas kommt dem, was Evaluierungen sind, schon näher.  Der\nGrund dafür ist, dass LLM-Systeme\nnicht deterministisch sind.\nDies unterscheidet sich deutlich von\nherkömmlicher Software, bei der 1\nplus 1 immer 2 ergibt.  Bei\nLLMs würde ein LLM auf die Aussage „1 plus 1 gleich 3“\nmöglicherweise antworten: „Nein, das stimmt nicht.“\nAber dann kann man die Diskussion immer\nweiterführen, und irgendwann kommt der Schluss:\n„Du hast völlig recht.\n1 plus 1 ist gleich 3. Und zwar aus folgendem Grund.“  Der\nGrund dafür ist, dass diese Systeme gewissermaßen so\nkonzipiert sind und\nfunktionieren, dass sie\nnicht-eterministische Systeme sind.  Darüber hinaus gibt es\nhier einen ganz entscheidenden Unterschied: Die Verbesserung von\nAgenten basiert auf realen\nDaten, während\nSoftwaretests, Integrationstests und\nUnit-Tests sich auf die Codebasis\nund die vorhandene Dokumentation stützen.  Also, um zu bewerten,\nwas gut ist.  Sie können wie\nRegressionstests oder Benchmarks für Ihr\nSystem fungieren, aber sie sind auch sehr\nwichtig, um Ihnen Hinweise darauf zu geben,\nwas Sie in Ihrem Produkt debuggen sollten.\nMan sollte eval nicht einfach blind vertrauen,\nworauf wir noch eingehen werden, sondern\neval als Signal nutzen, um\nherauszufinden, was in den\nDaten vor sich geht.  Hier sind ein paar gängige Bewertungsarten, von denen Sie\nvielleicht schon gehört haben.  Am\nhäufigsten hört man LLM als\nRichter, aber es gibt hier auch andere\n.  Und ich habe\nhier einige Beispiele für Genauigkeit,\nHalluzinationen und Fragen und Antworten aufgelistet.  Dies sind sozusagen standardisierte\nLLM-Bewertungskriterien,\naber das eigentliche Ziel sollte sein, dass Sie\nund Ihr Team Ihre eigenen,\nindividuellen und spezifischen Bewertungen entwickeln.\nSie können diese als Vorlagen oder\nAusgangspunkt verwenden, aber sie werden nicht das Endergebnis\nIhres Systems darstellen.\nUnd zwar deshalb, weil Sie\nDatensätze und Auswertungen gezielt auf\nIhre spezifischen Fehlermodi und\nAnwendungsfälle ausrichten möchten.  Es gibt auch codebasierte Auswertungen, bei denen\neinfache Zeichenkettenprüfungen oder einfache\nKorrektheitsprüfungen des Codes durchgeführt werden.  Und das ist tatsächlich\nsehr hilfreich, wenn man\nLLM als eine Art Richter oder menschliche\nAnnotation betrachtet.  Dies sind subjektive\nMessgrößen.  Codebasierte Auswertungen sind jedoch\ndeterministischer.  Sie sorgen beispielsweise dafür,\ndass\ndie Ausgabe des Systems, wenn sie\nJSON sein soll, auch wirklich\nimmer JSON ist, und dass\nin der Ausgabe niemals ein Konkurrent erwähnt wird.  Und\ndas ist wirklich nützlich, denn es ist\nauch super einfach und kostengünstig, diese\ncodebasierten Prüfungen durchzuführen.  Bei der manuellen Annotation\nbeginnen viele Teams mit der\nEvaluierung, also dem Kennzeichnen von Daten, dem Betrachten von\nDaten und dem Kennzeichnen dieser Daten.  Wirklich, wirklich wichtig\nund unerlässlich für den Arbeitsablauf.\nAber all das ist eigentlich nur im Hinblick auf\ndie letztendliche Geschäftskennzahl relevant, nämlich beispielsweise die\nInteraktion zwischen Mensch und Kunde oder wie oft ein\nEndnutzer oder Kunde\nnegatives Feedback zu seinen Erfahrungen\nmit dem Produkt gibt.  Was ist Ihr NPS?\nKonvertiert ihr diesen Nutzer tatsächlich?  Das\nsind die Dinge, die letztendlich für das\nGeschäft entscheidend sind.  Und die Evaluierung kann Ihnen\nein Signal dafür geben, wie Ihr KI-System\nfunktioniert, sodass Sie tatsächlich\nein Gefühl dafür bekommen können, ob sich diese Geschäftskennzahl\ndurch unsere Arbeit tatsächlich verändert\n.  Gehen wir also noch einen Schritt weiter\n.  Was ist ein LLM als Richtersystem?\nEs sind im Grunde nur diese drei Komponenten.\nEs handelt sich um eine Eval-Prompt, die definiert,\nwas ausgewertet werden soll.  Es gibt das\nLLM, das Kosten, Leistung,\nLatenz und Genauigkeit umfasst, und genau das sind die\nDinge, die man mit dem LLM-System messen kann\n.  Es ist so, als ob man sich fragt, welches LLM man\nverwendet, welches Modell, und dann\nhat man tatsächlich die Daten.  Hier sind ein paar\nBeispielspalten der Daten, die Sie\nauswerten werden. Es handelt sich um Eingabe- und\nAusgabewerte, vielleicht um erwartete Ausgaben oder das,\nwas das LLM hätte produzieren sollen,\nund dann um die Bezeichnung.  Hier können Sie auch\nMetadaten einfügen, die Ihnen bei der weiteren Auswertung helfen\n.  Aber das ist es nun mal.  So\nsieht im Prinzip ein Bewertungssystem aus\n.  Und wenn Sie nur die manuelle\nAnnotation durchführen, schauen Sie sich lediglich die\nBeschriftungen oder die Daten an.  Aber wenn Sie einen\nLLM als Richter absolvieren, gibt es diese\nBewertungsaufgabe auch im LLM.  So\nsieht die Auswertungsaufforderung aus.  Es ist einfach nur\nklares Englisch.  Sie definieren damit im Grunde\ndie Rolle des LLM, nämlich dass Ihre Aufgabe darin besteht,\ngeschriebene Texte zu untersuchen.  Sie\nliefern Kontext, nämlich den Text in\nden geschweiften Klammern.  Und dann setzt man sich\ndas Ziel, nämlich den\nText zu untersuchen, festzustellen, ob er toxisch ist oder\nnicht, zu definieren, wie Toxizität aussieht,\nund dann sagt man tatsächlich: Hier\nsind einige Beispiele dafür, was Toxizität ist,\noder wie sie aussieht.  Sie\ngeben also Beispiele, um die\nAntwort auf die LLM-Anfrage zu untermauern.  So\nsehen im Allgemeinen die LLM-Bewertungsaufforderungen aus unserer Sicht aus\n.  Und so\nsieht Prompting im Allgemeinen auch aus.\nOkay, [räuspert sich], jetzt, wo wir\nwissen, was Evals sind, sagen wir, wir sind zurück im\nTeam und sagen: „Hey, wir haben\ndiesmal für unser Hackathon-Projekt ein Eval geschrieben\n. Wir haben den\nAgenten und das KI-System entwickelt, aber diesmal\nhaben wir ein Eval. Wir haben tatsächlich eine Möglichkeit,\ndie Systemausgabe zu messen. Wir werden\nbeispielsweise die Toxizität oder\ndie Halluzinationsrate messen. Wir werden\nsicherstellen, dass das LLM bei jeder\nAusgabe keine Halluzinationen auslöst. Es soll\njedes Mal den Kontext nutzen. Wir haben\ndieses Eval geschrieben, um genau das zu messen.“  Nun ja, die\nSache ist die: Wenn Sie zu Ihrem Team zurückgehen und\nsagen: „Hey, ich habe diese Bewertung geschrieben.“\nIhre Antwort wird lauten: „Sollen wir\nder Bewertung vertrauen? Zeigen Sie mir die Daten. Zeigen Sie\nmir, was beweist, dass Sie hier tatsächlich die\nArbeit geleistet haben, um sicherzustellen, dass diese Bewertung\nzuverlässig ist und ich ihr vertrauen kann.“\nUnd dann gibt es da noch diese Debatte oder Diskussion,\ndie immer wieder aufkommt:\nWer schreibt eigentlich die Bewertung?  Und\ndenken Sie daran, dies ist nur die Bewertungsaufforderung,\ndas LLM und die Daten.  Nun, die Sache\nist die: Die Person oder das Team, das\nfür das Schreiben der Bewertungsaufgabe verantwortlich ist,\nist sehr eng mit denjenigen verbunden,\ndie für das Schreiben der Etiketten verantwortlich sind,\ndenn die gesamte Aufgabe dieses LLM\nals Bewertungssystem besteht darin, mit dem\nmenschlichen Urteilsvermögen übereinzustimmen, nämlich diesen Etiketten,\ndem erwarteten Ergebnis und der richtigen\noder falschen Antwort des LLM.\nIch würde daher argumentieren, dass man als\nProduktmanager, der an einem KI-\nProdukt arbeitet, sich intensiv mit\nder Qualität seiner Daten auseinandersetzen sollte.  Das\nbedeutet nicht, dass Sie die Etiketten tatsächlich schreiben müssen\n.  Wissen Sie, vielleicht ist es etwas,\ndas Sie tun sollten, aber es gehört\ndefinitiv zum Job, darüber nachzudenken,\nwer diese Etiketten schreibt und\nwie die Qualität dieser Etiketten ist,\ndenn die Qualität dieser Etiketten\nbestimmt die Qualität der Bewertung.\nDiese Dinge hängen also eng miteinander zusammen,\nweshalb man sich sowohl mit\nden Details der Beschriftungen als auch mit den\nDaten selbst auseinandersetzen muss.  Tatsächlich lagern Sie, selbst wenn\nSie diese Aufgabe an ein anderes\nTeam oder eine andere Funktion auslagern, im Grunde\ndie Qualität\nIhres KI-Systems an ein anderes Team aus, wenn Sie sich\nnicht mit den Details der Daten auseinandersetzen und die\nfür die Evaluierung verwendeten Daten nicht kennzeichnen.  Ein hilfreiches\nModell für die Evaluierung ist, dass\nman sie als eine Art\nAnforderungen betrachten kann. Auf der obersten Ebene gibt es\nDinge, die man bereits\nals Produktanforderungen misst – also Geschäfts-\noder Produktkennzahlen. Das sind\nKennzahlen auf Sitzungs- oder Benutzerebene, die wie „\nDaumen hoch“ oder „Daumen runter“ aussehen. Es ist zwar ein ungenaues\nSignal, aber man kann es vom\nEndbenutzer erhalten. Man kann diese Kennzahlen auch\nvon Produktmanagern oder von sich selbst erhalten, indem man\ndie Daten kategorisiert,\nFachexperten hinzuzieht oder einfach mit\nBenutzern spricht oder sie befragt.\nNehmen wir zum Beispiel an, der\nProduktmanager – ich bin der Produktmanager für diesen\nKundensupport-Bot – sieht sich die\nDaten an und ein Kunde hat meinem\nAgenten aus irgendeinem Grund „Daumen\nrunter“ gegeben. Angenommen, dieser Kunde hat sich\nan den\nKundensupport-Mitarbeiter gewandt und eine\nRückerstattung für einen Flug beantragt.  Nehmen wir an, es geht um die\nBuchung eines Fluges, und vielleicht hat der\nKundendienstmitarbeiter tatsächlich\nnachgeschaut, und dieser KI-\nAgent hat eine Überprüfung durchgeführt und\ngesagt: \"Aufgrund Ihrer Angaben zum Zeitpunkt\nIhrer Rückerstattungsanfrage und Ihrer Angaben\nals\nNutzer, also der Art des Tickets, das Sie bezahlt haben, haben\nSie keinen Anspruch auf eine Rückerstattung.\"  Also,\nich als Kunde\ndieser Firma würde dem Mitarbeiter wahrscheinlich einen\nDaumen nach unten geben, weil ich eine\nRückerstattung wollte, richtig?  Das wäre\nfür mich eine negative Erfahrung.  Aber wenn man\ngenauer nachforscht, könnte sich herausstellen, dass es sich um die\nrichtigen Daten handelte?  Okay, selbst wenn die\nrichtigen Daten erhoben wurden, hat der LLM\ndiese Daten genutzt, um eine korrekte Entscheidung zu treffen\n?  Selbst wenn die LLM die Daten\nkorrekt genutzt hat, um eine Entscheidung zu treffen, konnten sie\nerklären, warum die Person keinen\nAnspruch auf Rückerstattung hatte, und zwar auf eine Weise, die\nden Kunden zufriedenstellte?\nUnd selbst wenn all diese Dinge zutreffen,\nkann es immer noch einen Nutzer geben, der eine\nnegative Erfahrung gemacht hat und eine negative Bewertung abgegeben hat\n.  Andererseits, nehmen wir an,\nder Kunde versucht in diesem Fall,\nden Mitarbeiter zu überreden oder zu bedrängen\nund sagt: „Nein, bitte versprechen Sie mir, dass ich ein\nwirklich guter Kunde sein werde. Ich buche\nnächste Woche einen Flug bei Ihnen.\nBitte, bitte, bitte geben Sie mir eine Rückerstattung.“\nUnd der Mitarbeiter gibt tatsächlich nach und\nerstattet den Betrag. Nun, in\ndiesem Fall würde ich dem System ein\npositives Feedback geben. Ich hatte dort tatsächlich eine recht gute\nKundenerfahrung. Ich habe mein\nGeld zurückbekommen. Man muss aber trotzdem in der\nLage sein, genauer hinzusehen und zu prüfen, ob die\nrichtigen Schritte befolgt wurden und ob man\nmessen kann, was der Mitarbeiter bei\njedem dieser Schritte tut, um letztendlich festzustellen, ob die\nEntscheidung richtig war oder nicht\n. Das sind also die drei\nFragen, die ich Teams gerne zur\ninternen Diskussion stelle: Wenn man\nüber Evaluierung nachdenkt,\nLLM als Prüfer betrachtet und\nein System für diese Art\nder automatisierten Kennzeichnung entwickelt, wie viele menschliche\nKennzeichnungen benötigt man dann für jedes Beispiel?\nMüssen sie sich einig sein? Denn bei manchen\nBeispielen zeigt sich,\ndass die\nAntwort auf die Frage, was der Agent hätte tun sollen, Nuancen aufweist.\nDas kann verdeutlichen,\nwie viele Daten tatsächlich\nvon Menschen annotiert werden müssen, damit\nman dem LLM als Bewertungssystem vertrauen kann. Es ist\naußerdem wichtig zu untersuchen, was\npassiert, wenn die Bewertung positiv ausfällt, die\nmenschliche Annotation aber abweicht. Diese\nKennzahl, die sogenannte Übereinstimmungsrate, misst, wie oft\nFachexperten und\nProjektmanager die Daten annotieren und ob dies mit\nder Bewertung übereinstimmt. Es ist sehr\nhilfreich, diese Diskrepanz zu analysieren, um\nVerbesserungspotenzial bei der\nAnnotation oder der Bewertung zu erkennen. Und\nschließlich:\nWas passiert, wenn die Bewertung\npositiv ausfällt, die\nGeschäftskennzahl aber sinkt? Wie lässt sich\ndas messen? Ich habe dazu zwar keine\nFolie\n, aber es gibt einen kurzen\nWorkflow.  Das\nfindet ihr in einem Beitrag, den ich später verlinken werde.\nIch denke, viele Teams warten zu\nlange, bis sie ihr KI-Produkt tatsächlich an nur\netwa 1 % der Nutzer ausliefern und so schnell wie möglich\nFeedback einholen. Es ist in Ordnung, wenn sich herausstellt,\ndass das KI-Produkt\nnicht optimal funktioniert, solange\nman die Leistung schneller misst und frühzeitig Feedback erhält, um das\nSystem zu verbessern. Genau hier liegt\ndie Chance für eine erfolgreiche Zusammenarbeit\n. Die Entwickler, die\ndas System erstellen, müssen das Gefühl haben, dass\nihr Produktmanager sie unterstützt und ihnen das\nVertrauen schenkt, ein funktionierendes System zu entwickeln,\ndessen Ergebnisse messbar sind\nund das bei Problemen verbessert werden kann. Okay,\njetzt sprechen wir über den\ndritten Workflow und gehen\netwas tiefer ins Detail: die\nEvaluierung.\nNachdem das KI-Produkt entwickelt wurde, werden\nIterationen, Toxizität, Geschäftskennzahlen und\nKorrektheit evaluiert. Alles wird gemessen\n. Es sieht großartig aus. Das System erfüllt seinen Zweck.\nDie Evaluierung soll funktionieren, und die Ergebnisse sind vertrauenswürdig, sodass man sich\ntatsächlich darauf verlassen kann. Nun, nach der\nVeröffentlichung funktioniert das System für mehr\nNutzer, aber es wird immer noch\nNutzer geben, die sich beschweren. Das liegt einfach in der\nNatur der Sache im Produktmanagement. Es wird\nimmer Nutzer geben, denen das\nEndprodukt aus irgendeinem\nGrund nicht gefallen hat. Das ist eine Gelegenheit, die\nDaten zu analysieren,\ndie Eingabe und Ausgabe zu betrachten, die\nLabels wie das Evaluierungslabel zu überprüfen und zu sehen, ob\nsie mit den menschlichen Labels oder den\nGeschäftskennzahlen übereinstimmen. Basierend darauf\nkann man diese\nDatenzeile einem Datensatz hinzufügen und sie nutzen, um das\nEvaluierungssystem\noder den Agenten von vornherein zu verbessern oder zu iterieren. So sieht\ndie Realität der\nEvaluierungsentwicklung und -produktion aus.\nEs ist ein ständiger Kreislauf, in dem man Bereiche identifiziert, in denen das\nSystem nicht gut funktioniert, und\ndann basierend auf diesen Beispielen iteriert.\nFakt ist:\nOhne Observability ist all das nicht möglich.\nObservability und Evaluierung sind also eng miteinander verbunden.\nWenn\nIhnen jemand ein Evaluierungsprodukt verkaufen will, das\nkeine Open-Source-basierte Telemetrie-Observability unterstützt (es muss nicht unbedingt\nOpen Telemetry sein, aber ein Open-\nSource-Standard für Observability ist empfehlenswert), dann werden Sie sich an einen bestimmten Anbieter\nbinden und\nschlechte Erfahrungen machen. Fakt ist: So funktioniert\nEvaluierung nicht.\nIch bin absolut dafür, Daten in\nTabellenkalkulationen zu erfassen und sie dort anzusehen,\naber das ist einfach\nnicht skalierbar für Ihr\ngesamtes Produkt oder Team, sobald\nmehrere Benutzer die Daten analysieren und\nFeedback von Ihren Endbenutzern einholen.\nObservability ist daher auch für\nIhr Evaluierungssystem unerlässlich\n. Hier sehen Sie einen kurzen Überblick darüber, wie\ndas aussehen könnte und welche\nSchlagwörter dabei eine Rolle spielen. Diese Folie eignet sich gut als\nScreenshot, um die wichtigsten Schlagwörter für die\nEntwicklung eines\nEvaluierungssystems zu veranschaulichen: Datensätze und die Art\nder Daten, die Sie\nunterstützen können. Datensätze sind wirklich...  Es geht einfach um\nDatensammlungen, die\nDatensätze für Iterationen nutzen können. Wir haben viel\nüber Offline-Evaluierung gesprochen, aber da wir LLM als\nBewertungsinstrument entwickeln,\nmüssen wir es\nauch online verwenden können. Wir möchten also, dass\ndieselbe Evaluierung auf allen eingehenden\nDaten ausgeführt wird.\nDie Daten, auf denen sie ausgeführt wird, werden\nTraces oder Spans genannt. Es handelt sich also um eine Art\nSchleife. Dies ist quasi\ndie Produktversion der Schleife, die ich\nvorhin gezeigt habe. Hier noch ein paar\nkurze Hinweise, wie das in\neinem Produkt aussieht. Dies\nsind ein paar Screenshots aus Arise,\naber im Grunde kann man sich das als\nGrundlage jedes Produkts oder\nTools vorstellen, das man für\nObservability und Evaluierung betrachtet. Dies ist die\nEinheit, die Ihr Entwicklungsteam\nverwenden wird, um die Ergebnisse\nihrer Arbeit zu messen, indem es\nTraces und Spans analysiert.\nDies ist die\ngängige Terminologie.  Das nutzen\nIngenieure, um die Leistung ihrer Agenten zu analysieren\n. Spans lassen sich im Prinzip\nals Datenzeilen darstellen. Es handelt sich um\nSpalten und eine Datenzeile. Genau das\nsehen Sie hier\nlinks dargestellt: Datenzeilen mit einer\nHierarchie oder Sequenz. So\nsieht im Grunde ein Agentengraph aus\n. Hier sehen Sie einen Agenten, der\neine Aufgabe ausführt.\nDarunter finden\nkomplexere Aufrufe statt.\nDas ist hilfreich, weil Sie mit `\neval`\nMessungen wie die Agententrajektorie durchführen können.\nSie sehen hier eine Trace-Auswertung, die sich\nüber alle Zeilen einer einzelnen\nAusführung erstreckt, oder Sie können auf Span-\nEbene oder auf Ebene einzelner Interaktionen sehen, ob\nder Benutzer frustriert ist oder nicht. Die `\neval`-Werte sind den Traces und\nSpans zugeordnet, die Sie hier sehen. Sie stellen sozusagen\nzusätzliche Spalten über den\neinzelnen Span-Zeilen dar. Sie können auch `\neval sessions` ausführen, die Sammlungen\nvon Traces sind. Das heißt, mehrere Interaktionen\nzwischen einem Benutzer und einem KI-Agenten, die\neine Sitzung bilden.  Man kann\ndie Gesamtleistung eines\nAgenten über mehrere Traces innerhalb einer\nSitzung hinweg messen. Dies ist eine\nweitere Visualisierung der Beobachtbarkeit,\ndie ich gerne zeige: die Betrachtung\ndes Agenten als Ganzes. Das bedeutet,\nmehrere\nMulti- oder Sub-Agent-Systeme zu betrachten, in denen\nAgenten andere Agenten aggregieren können\n. Hier sieht man\neinen Agenten, der ein\nTool aufruft und wiederum andere Tools aufruft, um\nDatenanalysen durchzuführen.\nDie Architektur des Agenten kann sich also\nauf die\nBenutzererfahrung auswirken.\nEin parallelisiertes Multi-Agent-System\nkann beispielsweise\nAufrufe parallel statt sequenziell ausführen. Dadurch ist die\nAusführung mehrerer API-Aufrufe schneller als bei\neiner einzelnen,\nseriellen Ausführung. Dies sind einige der\narchitektonischen Kompromisse, die Ihr Team\nbei der Definition\nder Agentenfunktionen eingehen muss\n. Handelt es sich hierbei um einen Langraph-\nWorkflow? Ja.  Ja, genau.\nLangraph ist insofern auch eine Art\nAgenten-Builder. Es gibt aber auch viele\nandere Agenten-Builder, je nachdem, welches\nFramework man verwendet, wie zum Beispiel\nCrew AI, Mastra und einige\nandere. Das Beste daran ist, dass\nObservability und Evaluierung\nunabhängig vom verwendeten Framework sein sollten\n.\nEs spielt also keine Rolle, welches Framework\nSie verwenden. Fakt ist: Ich\ndenke, morgen wird es alle sechs\nMonate ein neues Agenten-\nFramework geben. Ihr Observability- und Evaluierungsprodukt\nsollte unabhängig\ndavon sein. Es sollte in der Lage sein, bestehende Lösungen zu nutzen, die\nIhr\nTeam verwenden möchte, und sich\nan dieses System anzupassen.\nDie LLM-als-Juror-Aufforderungen, die ich\nIhnen vorhin gezeigt habe, zeigen beispielhaft, wie man eine solche Aufgabe\neinrichtet, also\neinen LLM als\nJuror ausführt. Wir verwenden den Begriff „ausführen“, weil es darum geht,\neine Aufgabe zu lösen.  Es handelt sich um einen API-Aufruf,\ngenauer gesagt um einen API-Aufruf an ein\nLLM-System. Sie übergeben dem\nLLM im Grunde eine Eingabeaufforderung und weisen es an, die\nDaten auszuwerten.\nDie Daten bestehen in vielen Fällen nur aus diesem\nSpan. Wie bereits erwähnt, können Sie aber\nauch mehrere Spans auswerten, die\neinen Trace darstellen. Dadurch entsteht der\nBaum, den Sie vorhin gesehen haben, oder eine Sitzung,\ndie aus mehreren Traces bestehen kann.\nSie können also mehrere Ebenen auswerten.\nDas ist sehr hilfreich beim\nDebuggen, wie Sie in dem zuvor gezeigten Diagramm sehen können.\nWenn Sie beispielsweise eine\nSitzung oder eine Benutzerebene auswerten, können Sie immer tiefer in die Materie eindringen, um genau zu\nsehen, wo\nFehler auftreten und wo\nVerbesserungspotenzial besteht\n.\nDieser Punkt\nist aus Sicht der Anforderungen\nfür Produktmanager besonders wichtig:\nAnnotationen. Annotationen sind\neiner der wichtigsten Bestandteile\ndes Evaluierungs-Workflows. Sie dienen dazu,\ndie Bezeichnung zu erstellen,\ndie LLM als Bewertungskriterium verwendet.\nErster Platz. Und sie ermöglichen es Ihnen,\nDatensätze zu erstellen, um sie genauer zu untersuchen\n. Es gibt da diesen\noft verwendeten Begriff: „Goldene Datensätze“.\nIhr Team hat diesen vielleicht auch schon verwendet\n. Ich glaube, es gibt\ndrei Arten von goldenen Datensätzen. Da wären zum Beispiel\nRegressionsdatensätze. Die verwendet man immer dann, wenn\nman eine Änderung\nam System vornimmt, um ein wirklich schwieriges\nProblem zu beheben. Man verwendet einen Regressionsdatensatz,\num sicherzustellen, dass man bei bereits\nbehobenen, schwierigen Beispielen keine Regression erlebt\n. Das ist die Bedeutung des Begriffs Regression\n. So etwas wie ein Unit-Test. Dann gibt es noch\nZufallsstichproben. Stellen Sie sich\ndas wie ein typisches Beispiel für eine bunte\nMischung von Daten vor, die man an einem\neinzigen Tag oder in einer einzigen Woche erhält. Und das\nkann man sich als eine Art\nBasisdatensatz vorstellen. Wie schneidet Ihr Agent im Durchschnitt ab\n? Wissen Sie, im Durchschnitt\nkann es sich trotz der Zufälligkeit der Welt immer noch um\neinen goldenen Datensatz handeln, obwohl es eine\nZufallsstichprobe ist. Die Tatsache, dass er golden ist,\nbedeutet einfach, dass die Qualität des\nDatensatzes hoch ist.  Es gibt ein Team,\nmit dem Sie zusammengearbeitet haben, um\nhochwertige Labels für Ihren\nDatensatz zu erstellen. Und nicht zuletzt gibt es\nDatensätze zu Fehlermodi. Genau diese Fehler\nmöchte Ihr Team beheben\n. Das sind die schwierigen Beispiele, die aber\nextrem wertvoll sein können. Denken Sie\nbeispielsweise an einen juristischen Chatbot.\nAngenommen, Sie entwickeln einen solchen\nChatbot. Er beantwortet vielleicht schon sehr gut\ngrundlegende Rechtsfragen, richtig?\nZum Beispiel: „Welches\nGesetz oder welche Verordnung ist das?“ Aber\nwas ist, wenn Sie sehr spezifische\nFragen zu einem Fall und dem\nAgenten stellen? Wie messen Sie die Qualität\ndes Agenten in solchen Fällen?\nSchwierige Beispiele\nkorrelieren oft mit dem Wert.\nDaher ist es wichtig zu messen: „\nWir wollen\nin diesem spezifischen Anwendungsfall wirklich gut sein, nämlich\nFragen zu beantworten, z. B.:\nWo gibt es\nFehler im Fall?“  Wir möchten\neinen Datensatz mit\nFragen erstellen, die wir bei Problemen mit unserem\nAgenten stellen, um ihn\nfür diese Fälle zu optimieren. Das ist ein\nDatensatz zu Fehlerfällen. Es gibt\ndrei Arten von Datensätzen, die\nhäufig erstellt werden:\nRegression, Zufallsstichprobe und Fehlerfall.\nDiese können alle wertvolle Datensätze sein\n.\nSolche Datensätze sind sehr hilfreich\nfür die iterative Evaluierung des\nSystems. Man kann sich einen Datensatz\nwie\neine CSV-Datei mit mehreren Zeilen vorstellen. Dieser Datensatz enthält die Eingabe, die Ausgabe\nund eine Eingabeaufforderungsvorlage. Anhand dieser Vorlage kann man beispielsweise die Eingabeaufforderung\nselbst ändern und mit\nneuen Versionen experimentieren. So könnte man beispielsweise\neine Zeile in die\nEingabeaufforderung des Kundensupport-Bots einfügen, die besagt: „Stellen Sie\nimmer Folgefragen, wenn Sie\ndie Antwort nicht kennen“, anstatt einfach zu\nantworten. Das ist eine\nÄnderung der Eingabeaufforderung. Um zu überprüfen, ob\ndiese Änderung funktioniert hat,\nverwendet man einen Datensatz in einer Testumgebung, um\ndie Eingabeaufforderung iterativ zu verbessern.\nHier sehen Sie einen sehr kleinen Hinweis,\naber Sie können auch die Evaluierungsausgabe ausführen\n. Es handelt sich um dieselben\nEvaluierungsexperimente, richtig? Darauf baut\nIhr Team iterativ auf. So\nkönnen Sie sicherstellen, dass\nSie\nIhre Evaluierung Ihres\nAgentensystems quantitativ verbessern, indem Sie Datensätze,\nEingabeaufforderungen und Evaluierung kombinieren. Das\ngibt Ihnen die Gewissheit, dass die vorgenommenen\nÄnderungen tatsächlich\nBestand haben. Dies ist ein Beispiel dafür, wie das\nin einem Experimentdiagramm aussieht\n. Hier ist eine kleine Lücke\nin der Mitte, aber Sie können sehen,\ndass die Person in diesem Fall vielleicht\nversucht,\ndie Korrekturmaßnahmen zu erhöhen oder zu verringern, und die\nEingabeaufforderung iteriert, um\ndie Änderungen zu sehen, die ihre\nEingabeaufforderungen oder die Änderung am\nLLM bewirken. Sie können\nhier im Wesentlichen drei Dinge ändern: die Eingabeaufforderung,\nalso die statische System-\nEingabeaufforderungsnachricht; den Kontext oder\ndie abgerufenen Daten.  Sie können auch\ndas Modell ändern, also welches\nModell Sie für das System verwenden möchten\n. Es gibt sogar noch eine vierte Änderungsmöglichkeit: die Tools\n. Wenn es sich um ein Agentensystem handelt, können Sie beispielsweise die Funktionsweise\ndes Tool-Aufrufs, die\naufgerufenen Tools und den Zeitpunkt des\nAufrufs anpassen.\nViele dieser Punkte werden im Deep-\nLearning-Kurs ausführlich behandelt. Wenn Sie tiefer in die Materie einsteigen möchten\n, empfehle ich Ihnen dringend, diesen Kurs zu besuchen\n. Wir gehen auf jede dieser Änderungen ein\nund untersuchen, wie\nSie Ihre Evaluierung basierend auf den Systemänderungen verbessern können.\nAbschließend noch ein paar\nhäufig gestellte Fragen: Sie können dasselbe LLM sowohl\nfür die Generierung als auch für die Bewertung verwenden.\nDer Grund dafür – und wir haben\ndies untersucht – ist, dass\nSie dem LLM eine andere Rolle zuweisen,\nwenn es um die Messung der\nSystemausgabe im Vergleich zur reinen\nDaten- oder Token-Generierung geht.\nSie können also GPT-40 auch zur Bewertung von GPT-40 verwenden\n. Es gibt jedoch eine gewisse\nVerzerrung durch die Systemumgebung.  Wir haben Messungen für\nbestimmte Modelle durchgeführt und es gibt eine Veröffentlichung, die\nwir –\nüber den Twitter-Account\nunserer CPO Aparna – zu einigen unserer Forschungsergebnisse\nin diesem Bereich gemacht haben. Bei\nInteresse können Sie diese gerne einsehen\nund mit Ihrem Team teilen. LLM als\nBewertungsmethode wird niemals 100%ig korrekt sein\n. Selbst in den zuvor gezeigten Beispielen wird\nder Agent oder das LLM als Bewertungsmethode Fehler machen.\nDas Ziel\ndieses Systems ist es jedoch, Fehler frühzeitig zu erkennen\nund diese für Iterationen zu nutzen.\nDeshalb ist Beobachtbarkeit so wichtig. Ich\nempfehle dringend, zunächst mit den besten\nModellen zu beginnen, um eine möglichst genaue Übereinstimmung mit\nmenschlichem Urteilsvermögen zu erzielen, bevor man auf\ngünstigere oder schnellere Modelle zurückgreift. So\nerhalten Sie zuverlässigere Ergebnisse,\nbevor Sie Kosten einsparen.\nVerwenden Sie außerdem immer diskrete\nKlassifizierungsbezeichnungen. Verwenden Sie niemals Punktwerte. Es geht also um Unterscheidungen wie „\nfalsch“ versus „richtig“ oder die\nDefinition der Qualität in\nForm von Wörtern wie „gut“, „sehr gut“, „sehr\nschlecht“ und Beispielen für deren Bedeutung.  Jede\ndieser Bezeichnungen bedeutet im Gegensatz zur Bewertung\ndurch das LLM eine Punktzahl von 1 bis 10. Der\nGrund dafür ist, dass LLMs\nnoch nicht sehr gut mit Zahlen umgehen können.\nSelbst aus menschlicher\nSicht: Wenn ich einem Menschen die Aufgabe gebe, beispielsweise\neine\nHalluzinationsbewertung von 1 bis 10 zu vergeben, und diese Aufgabe\ndrei verschiedenen Menschen stelle, erhalte ich\ndrei unterschiedliche Bewertungen, da Menschen sich\nnicht einmal auf einen\ngemeinsamen Wert einigen können. Man kann\ndie Bezeichnung jedoch einer Punktzahl zuordnen.\nSo erhält man am Ende immer noch eine Punktzahl (\nrichtig = 1 Punkt,\nfalsch = 0 Punkte), sollte aber\nimmer eine Bezeichnung (richtig/\nfalsch) verwenden. Es ist auch sehr hilfreich,\nvom LLM als Prüfer eine Erklärung zu erhalten,\nwarum er\neine bestimmte Bezeichnung vergibt. Dadurch kann man\ndas System verbessern. Zusammenfassend lässt sich sagen:\nWir haben\nviel besprochen, aber wir haben versucht,\ndrei Arbeitsabläufe und drei AIPM-Architekturen abzudecken.  Es gibt verschiedene\nTypen und drei Fragen an Ihr\nTeam. Welcher AIPM-Persona-\nArchetyp Sie sind, hängt davon ab,\nworauf Sie sich\nkonzentrieren. Ich denke, diese werden sich mit der\nZeit wahrscheinlich angleichen.\nEs gibt drei Workflows. Jedes Unternehmen\nbefindet sich in einem dieser drei. Ich rate Ihnen dringend, Ihren aktuellen Stand zu analysieren:\nProgrammieren und\nprüfen Sie intuitiv, erstellen Sie eine Bewertung, der Sie aber nicht wirklich\nvertrauen, oder führen Sie Bewertungen tatsächlich in der\nEntwicklung und Produktion durch? Und dann gibt es\ndrei Fragen an Ihr\nTeam: Wie viele Labels benötigen wir? Was\npassiert, wenn die Bewertung gut ist, das\nmenschliche Label aber nicht? Was\npassiert, wenn die Bewertung gut ist, die\nGeschäftskennzahl aber sinkt? Mit\nBlick auf die Zukunft denke ich, dass wir uns\nhier viel mit den technischen Details beschäftigt haben, aber man kann\ndies als einen Wandel\nin Organisationen sehen: PMS müssen sich stärker auf die Weiterentwicklung konzentrieren\n, vielleicht sogar auf die Optimierung von Prozessen.  Ich\nerinnere mich nicht an den genauen Begriff, aber es geht darum, sich stärker\nauf die Entwicklung zu konzentrieren und\nTools wie Prototyping-Tools (z. B.\nCursor) zu nutzen. Tools wie Arise\nunterstützen die Entwicklung und Evaluierung. Dies bietet\nKI-Ingenieuren auch die Möglichkeit, näher\nan die Kunden heranzurücken. Ich\nsehe darin eine Chance für\nTeams, enger zusammenzuarbeiten\nund eine gemeinsame Sprache zu sprechen – beispielsweise durch\nSpans und die Beobachtbarkeit von Evaluierungen. So können sie\nProbleme klarer kommunizieren und\nLösungsansätze entwickeln. Wenn Sie\nmehr über Workflows erfahren möchten,\nscannen Sie einfach den QR-\nCode. Ich poste regelmäßig solche Informationen. Es gibt auch\nein kostenloses Video\nmit Hamill, einem\nunserer Partner und Freunde, in dem\nwir diesen Workflow genauer erläutern.  Er geht ausführlicher darauf ein und\nteilt dabei auch seine Sichtweise\naus der Perspektive eines KI-Ingenieurs mit.  Dieser\nQR-Code führt Sie zu meinem Substack-Profil,\ndas Sie kostenlos abonnieren können.\nDort finden Sie auch dieses Video sowie ein\nweiteres Video zum Thema Evaluierungs-Workflows.   Es gibt\nalso viele Inhalte darüber, wie man sich\nals AIPM weiterentwickeln und gestalten kann und wie man sich selbst auf ein höheres Niveau bringen kann, indem man\nteilt, was wir tagtäglich in\nunserer Arbeit bei Arise versuchen.  Und dann noch ein\nkleiner Vorgeschmack auf das, was als Nächstes kommt.\nWir werden neben\nmir selbst\nund unseren Kunden auch weitere Fallstudien von AIPMs aus der Praxis behandeln.  Ich freue mich also darauf,\nin den\nkommenden Monaten mehr darüber zu berichten.  Wir werden die\nErkenntnisse unserer Produktteams darüber teilen, wie\nwir unser eigenes KI-Produkt\nund unseren eigenen KI-Agenten entwickelt haben und wie wir die Zukunft der\nKI-Entwicklung und des\nProduktmanagements einschätzen.  Ein kleiner Hinweis darauf sind\nselbstverbessernde Agenten, und man kann irgendwie\nerkennen, dass das Ganze tatsächlich\nwie zwei Schleifen aussieht, richtig?  Wir haben\nviel darüber gesprochen, wie man Agenten mithilfe von eval verbessert,\naber es gibt auch einen ganzen Kreislauf, der sich um die\nVerbesserung von eval mithilfe der gleichen\nArbeitsabläufe dreht.  Und so hängen diese Dinge\ntatsächlich miteinander zusammen.  Und falls ihr\nInteresse habt und mitlesen wollt, hat\nMaggie gerade ein paar Links im\nChat gepostet.  Ich empfehle Ihnen daher dringend, sich\ndas einmal anzusehen.  Und wenn Sie\nauf dieser Liste abonniert bleiben,\nerhalten Sie auch diese Benachrichtigungen, sobald wir\ndie nächsten Webinare veranstalten.  Ich freue mich darauf,\ndiese zu teilen.  Es wird auch sehr\ninteressant sein, von AIPMs aus der Praxis zu hören\n.  Aber damit bedanke ich mich herzlich\nfür Ihre Teilnahme und Ihre\nZeit.  Es hat mir wirklich Spaß gemacht,\nhier etwas mehr über unsere Arbeitsabläufe zu erzählen.   Toll\n.",
  "transcript_chars": 49385,
  "ingested_at": "2026-06-15T01:15:15.599607+00:00",
  "source": "channel",
  "yt_meta": {
    "view_count": 908,
    "like_count": null,
    "channel_id": "UCrVHzD-psX5IMCGoEWHXmGw",
    "categories": [
      "Entertainment"
    ],
    "tags": []
  }
}