{
  "video_id": "fAfuQN0WwFE",
  "channel_slug": "deeplearningai",
  "channel_handle": "deeplearningai",
  "title": "AI Dev 26 x SF | Ara Khan: Evals Are Broken Use Them Anyway",
  "duration_seconds": 1477.0,
  "url": "https://www.youtube.com/watch?v=fAfuQN0WwFE",
  "upload_date": "",
  "transcript": "Ich bin Era.  Ich werde über\nEvaluierung sprechen, äh, speziell über KI-Evaluierungen wie\nEvaluierungen von Programmieragenten und so weiter.  Und ich werde darüber\nsprechen, wie sie kaputt sind\nund wie man sie trotzdem noch verwenden kann.\nAlso, bevor ich anfange, möchte ich nur eines\nsagen.  Es ist einfach unglaublich, wenn man an\netwas arbeitet und so\nlange in einem Raum eingesperrt ist und\ndenkt, dass es\nniemanden interessiert, und dann, wenn man darüber spricht, sind so\nviele Leute\nda.  Das macht mich sehr glücklich.  Ich bin sehr\ndankbar, dass ihr alle gekommen seid.  Es gibt einem das Gefühl, dass es einem\netwas bedeutet, und ich bin sehr dankbar, dass ihr vorbeigekommen seid\n.  Vielen Dank.  Also\ngut, wenn wir schon von Evaluierungen sprechen,\nmeine grundlegende These in diesem\nganzen Gespräch ist, dass die\nLeute sich in Bezug auf Evaluierungen irren. Die\nmeisten Leute wissen viel über\nEvaluierungen, behaupten Dinge, aber\nsie liegen falsch. Wie schafft man es,\nrichtig in Bezug auf Evaluierungen zu sein?\nWie kommen wir\nvon falschen zu richtigen in Bezug auf Evaluierungen? Im\nGrunde\nmöchte ich, dass Sie in der Lage sind,\nsie zu erstellen.  Ich möchte, dass Sie\nsie interpretieren können und dass Sie\nsie in Ihren Agentenabläufen verwenden können.\nIhre Agentenabläufe können beliebig sein.  Es\nkönnte sich um einen Codierungsagenten handeln.  Es könnte so etwas wie\nein Einkaufsagent sein.  Es könnte ein\nAgent für alles Mögliche sein.  Es könnte\netwas ganz Triviales sein oder\netwas super Komplexes, wie zum Beispiel ein\nProduktionsablauf, der von\nMillionen von Menschen genutzt wird.  Und in all diesen\nFällen kann man von EVLs lernen.  Und\nunabhängig davon, welchen Weg\nman beim Aufbau von Agententeams tendenziell einschlägt, halte\nich Ewells für einen der wichtigsten\nAspekte meiner\njahrelangen Arbeit mit KI-\nAgenten.  Drehen wir es also einfach mal um,\nja?  Drehen wir es um.  Wie können wir\nwissen, ob die Leute sich in Bezug auf\nsie irren?  Warum zum Teufel\nbehaupte ich, dass die Leute sich in Bezug auf sie irren?\nUnd es gibt zwei Wege.  Erstens gibt es\nzwei Lager, die im Unrecht sind.  Und die erste Gruppe, die\nfalsch liegt, ist die Gruppe derjenigen, die objektive Kennzahlen vertreten.\nWas bedeutet das?  Das Lager der objektiven Kennzahlen\nist im Grunde genommen so, dass es im\nGrunde Leute sind, die glauben, dass man\nalles einfach für bare Münze nehmen sollte\n.  Wenn man sich also das Ende des Lebenszyklus (EOL) ansieht,\nkünstliche Intelligenz,\nEpoch AI, all diese\nUnternehmen – sie alle leisten großartige\nArbeit und präsentieren\nobjektive Zahlen, sobald ein neues\nModell erscheint. Man veröffentlicht einfach diese\nBenchmark-Ergebnisse, und der gesamte Twitter-\nFeed ist voll von solchen Bewertungswerten, einer\nMenge Informationen, die auf einen einprasseln,\nund es sollen echte\nZahlen sein, also soll man ihnen glauben,\nund das ist eben das Ergebnis – aber\nich glaube nicht, dass das die\nLösung ist.  Ich glaube nicht, dass es da\ngenaue Zahlen gibt oder dass man präzise sagen kann, welches\nModell besser ist als das andere.  Um es\nganz genau zu sagen: Wenn Sie bemerken, dass\nda etwas ist, dann bemerken Sie vielleicht Sonett 4.6\nbei 52 und dann bemerken Sie vielleicht noch ein paar\nandere Modelle, die ziemlich nah dran sind.  Und es ist\nsehr schwierig zu behaupten, dass\ndie Modelle, die\nhier in der Punktzahl nahe beieinander liegen, tatsächlich\ngleich gut sind, denn das sind sie nicht.  Und\nwenn Sie sich etwa eine halbe Stunde lang mit einem\ndieser Modelle beschäftigt haben, werden Sie sehr\nschnell feststellen, dass diese Ergebnisse nicht\nunbedingt viel aussagen.  Ähm, also das war so\nein Tweet von Francis, in dem er\nbehauptete, Meta hätte ein neues\nModell herausgebracht.  Es war eine riesige\nEnttäuschung, denn es war der Maßstab\nschlechthin.  Unzählige Modelle und\nLabore heutzutage\nmachen genau das – wie in einem Spiel, bei dem es nur darum geht,\ndie höchste Punktzahl bei der Bewertung zu erreichen.\nEgal wie gut das Modell ist, es wird\nTweets generieren,\nAufmerksamkeit erregen und dann zieht es Leute an,\nund wer weiß, vielleicht ist das Modell\ngut, vielleicht auch nicht.  Das ist also das eine Ende des\nSpektrums.  Aber wie sieht es an den anderen Enden\ndes Spektrums aus?  Das andere Ende des\nSpektrums ist der Geschmack.  Die Leute, die „Geschmack ist König“ sagen,\nglauben im Grunde überhaupt nicht an Zahlen.  Diejenigen, die der Meinung sind,\ndass diese Zahlen völlig\nsinnlos sind.  Sie glauben an gar\nnichts.  Es ist einfach nur äh erfunden\n.  Das ist also im Grunde so etwas wie die Geschmacks-\nund Königsfamilie.  Aber im Grunde genommen, so nach dem\nMotto „Geschmack ist König“, geht es doch nur um die Stimmung\n.  Es dreht sich alles um Stimmung.\nSo ist es nun mal, egal was die\nZahlen sagen.  Wenn man sie anspricht,\nsagen sie zum Beispiel: „Warum mag\nich Wolkenmodelle? Warum magst du sie?“\nUnd sie werden sagen: „Oh, ich unterhalte mich gern mit\nihr.“  Sie klingt nett.  Sie werden\nüber ein KI-Modell sprechen, als wäre es\nein echter Mensch.  Und\nan diesem Punkt weiß ich einfach\nnicht mehr, wo ich anfangen soll.  Und ich\nglaube, dass beide\nGruppen falsch liegen.  Und ich glaube, die\nWahrheit liegt irgendwo dazwischen, dass\nAale nicht das Ende aller Dinge sind\n.  Sie sind nicht völlig nutzlos.   Es\ngibt richtige und\nfalsche Wege, sie zu benutzen.  Der\nZweck dieses Gesprächs ist also, dass ich Sie\ndurch einige Ebenen führen möchte,\nund während ich Sie durch diese\nEbenen leite, werden Sie ein viel\nbesseres Verständnis dafür entwickeln, wie man mit\nE-Mails arbeitet.  Die erste Frage, und die ist sehr\ngrundlegend, lautet:\nWie kann man die Bewertungen anderer Leute nutzen\n?  Wie kann man eval-Ausgaben verwenden,\nwenn sie beispielsweise aus den\nModelllaboren, dem Cursor, dem\nCloud-Code oder Ähnlichem stammen? Wie\ninterpretiert man diese?  Auf der zweiten Ebene geht es beispielsweise darum,\nwie man Evaluierung nutzt, um die eigenen\nAgenten zu verbessern.  Und auf Stufe drei, wenn Sie\nviel Geld und viel Zeit haben, können Sie\nsogar Ihre eigene Bewertung erstellen.  Ähm, ja,\nalso das ist im Grunde der\nKern dieser Unterhaltung\nheute.  Anstatt\nIhnen also einfach nur\nfeste Regeln für die Interpretation von Evaluierungen vorzugeben, werde\nich Ihnen einige\nHeruristiken geben, und wenn Sie diese\nHeruristiken befolgen, werden Sie meiner Meinung nach ein viel\nbesseres Verständnis für die\nEvaluierung anderer haben.  Wenn Sie diese Zahlen erhalten, werden\nSie viel\nsicherer sein und wissen, was es ist und was\nes für Sie bedeutet.  Also,\ndie erste Regel, Nummer eins:\nGlaube niemals den Bewertungen von Model Labs. Immer\nwenn die Zahlen veröffentlicht werden, egal welche\nBewertungszahlen für\nMythos Preview oder GB 5.5 oder was auch immer veröffentlicht werden, sind\nsie großartig und wahrscheinlich\ngenau, und diese Modelle sind mit Sicherheit\nsehr anständig.  Ich sage nur, man sollte diese\nZahlen nicht für bare Münze nehmen\n.  Sie müssen Ihr eigenes\nUrteilsvermögen einsetzen.  Sie sind annähernd genau,\naber nicht perfekt.   Also,\ndas ist so ein Tweet,\nder ziemlich tiefgründig ist. Darin\nbehauptet jemand, dass noch nie ein\nIngenieur eine Entscheidung auf der Grundlage\neines Benchmark-Ergebnisses getroffen hat. Im Grunde genommen\nbehauptet er, dass viele Leute\nEvaluierungsergebnisse routinemäßig ablehnen.\nSie sagen zwar, sie führen\nEvaluierungen durch, erhalten\ndie Zahlen, bekommen diese Dinge, aber sie\nignorieren sie trotzdem. Und oft nehmen\nechte KI-Forscher sie\nmit Vorsicht zur Kenntnis,\nund ich denke, das ist der\nrichtige Ansatz, um über Evaluierungen nachzudenken.\nDie Schwierigkeit bei der Interpretation von\nEvaluierungen besteht darin, dass man zwar auf dem Laufenden bleiben muss, aber nicht unbedingt\nder erste\nAnwender sein muss. Und viele von Ihnen, die für\nsehr große Unternehmen arbeiten, für die ist\ndas natürlich wichtiger als\nfür den Rest von uns.  Was genau meine ich\ndamit?  Dies ist also eine Grafik von EPO\nAI, die zeigt, wie gut die Modelle\nin den letzten paar Jahren abgeschnitten haben\n.  Äh, also, ich schätze, von 2024 bis\nheute sind es ungefähr 2 Jahre, aber in der KI sind das\netwa 27 Jahre.  Es bewegt sich so schnell.\nWas Ihnen auffallen wird, ist, dass sich das Modell ändert, wenn Sie sich die\nBewertung der Limonaden alle paar Monate ansehen,\nund zwar\nsehr schnell.  Wenn ich zum Beispiel ein\npaar Monate zurückreisen könnte, wäre das Sonnet 4.6\noder Oppus das beste Modell gewesen.  Nicht mehr so ​​sehr,\noder?  Und wenn du\ndieses Spiel immer weiterspielst, nach dem Motto: „Hey, ich will immer nur\ndas Beste“, dann ist das auch schon wieder vorbei.  Genau wie du\nwirst du feststellen, dass der mentale Aufwand, den\ndu betreiben müsstest, um immer an der\nSpitze zu stehen, es einfach nicht wert ist.  Ich glaube, was\nSie wollen, ist, dass neue Modelle auf den Markt\nkommen.  Du willst, dass neue Dinge herauskommen\n.  Man muss ein paar\nWochen abwarten und dann sagen:\n„Okay, lasst die Sache sich beruhigen.“  Und genau dann\nversuchst du dein eigenes Ding.  Es gibt\nLeute wie mich, die ihre ganze\nZeit damit verbringen, herauszufinden, was gerade angesagt\nist, was\nzu jedem Zeitpunkt das Beste ist, was gerade im Trend liegt.  Und das ist es, womit ich meinen\nLebensunterhalt verdiene.  Na klar, das werde ich tun.\nAber ich glaube nicht, dass du das tun solltest.  Ich\ndenke, Sie sollten auf dem Laufenden bleiben, aber Sie müssen\nnicht unbedingt das Dringendste auswählen\n.  Und die dritte und\nsehr wichtige Häresie ist die, dass,\nwenn man an einem Problem arbeitet – ich\npersönlich arbeite ja bei einem Kunden –, ich\narbeite an dem Problem der Codierung von Agenten.\nCodierungsagenten haben eine ganz spezifische Art\nder Evaluierung.  Diese werden also als Terminalbank bezeichnet\n.  Ähm, einige Weiterentwicklungen wie\nFrontier SWE, ähm, einige andere Arten von\nProgrammier-Benchmarks.  Das sind sehr\nspezifische Dinge, die mich betreffen.  Ich glaube,\nSie arbeiten vielleicht an einem anderen Problem.\nVielleicht arbeiten Sie für ein Einzelhandelsunternehmen\n.  Vielleicht arbeiten Sie für ein\nInfrastrukturunternehmen und vielleicht\ngelten für Sie ganz\nandere Bewertungskriterien.  Wenn viele dieser Modell-\nApps eine Bewertung abgeben, handelt es sich dabei lediglich um\ngenerische, allgemeine Bewertungsfunktionen.  Sie\ntreffen möglicherweise nicht auf Sie zu.  Ich\ndenke, als Problemlöser sollte man\nimmer nach einer Lösung\nfür sein Problem suchen oder dieser so nahe wie möglich\nkommen.  Ich denke, das ist ein wesentlich besseres\nMessinstrument.  Um ein ganz konkretes Beispiel zu nennen: Der\nS SWB Benchmark war so lange ein\nStandard-Evaluierungsmarker für Coding Agents,\nund dann kam OpenAI\nund sagte: „Dieser Benchmark\nist so gesättigt, dass wir ihn nicht\nmehr verwenden können.“  Wenn Sie in diesem Bereich tätig wären,\nwüssten Sie, dass dieser\nBewertungsmarkt so stark gesättigt ist, dass selbst\naktuelle Modell-Apps\ndie Bewertung gar nicht mehr erwähnen,\nweil manche\ndieser Bewertungen so übersättigt sind und daher\nfür Ihre Probleme nicht mehr relevant sind.\nOkay, das war also der erste Teil.  Der\nerste Teil bestand darin, herauszufinden, welche\nHuristics man verwenden kann, um das\nVerständnis und die Interpretation von\nE-Mails anderer Leute zu verbessern, aber auch, wie man\nEvaluierungen nutzt, um seinen Agenten anhand dieser E-Mails zu optimieren.\nUnd hier komme ich mit meiner\neigenen Erfahrung ins Spiel, die ich\nbei einem Kunden gesammelt habe, und zwar bei diesem sehr, sehr schwierigen\nProblem, das sowohl ein\ntechnisches als auch ein philosophisches Problem darstellt. Man muss sich das so vorstellen,\nweil KI eine so\nhohe Varianz in ihren Reaktionen aufweist.  Es könnte Ihnen so ähnlich sein, als ob es\nIhnen eine Antwort geben könnte.  Äh, das ist nicht\nsehr deterministisch.  Der Antwortraum ist\nim Grunde unendlich, richtig?  Und wenn man\neinen Agenten einfach machen lässt, wenn man ihn beispielsweise\nbei jedem Schritt 10 Minuten lang machen lässt,\nkönnte die Sache eine\nandere Wendung nehmen.  Und wenn man den\nBaum dann so weiterlaufen lässt, ist es, als ob es ein\nunendlicher Raum wäre, was ein\nAgent alles tun könnte.  Wenn man also ein solches\nProblem lösen möchte,\nist es sehr schwierig zu messen, ob ein\nAgent tatsächlich das tut, was man von ihm\nerwartet. Deshalb betrachte ich\nEvaluierungen als eine Art\ntechnisches, aber\nauch philosophisches Problem. Als wir uns\nein paar Jahre lang mit der Entwicklung von Coding Agents beschäftigten, stellten\nwir letztes Jahr fest, dass es zwar\nall diese Evaluierungen gab, diese aber so\nunterschiedlich von alltäglichen\nProblemen waren, dass wir\nsie gar nicht erst nutzten.  Ich habe\nletztes Jahr mit Enthropic gesprochen, und die meinten im\nGrunde: Ja, Bewertungen sind super,\naber Mann, es geht nur um die Stimmung, es geht nur um\ndie Stimmung. Und damals\nwar ein Teil des Grundes, dass\ndie Bewertungen einfach\netwas völlig Falsches maßen.  Um\nein ganz konkretes\nBeispiel zu nennen: Viele Evaluierungsaufgaben beinhalten Dinge\nwie die Fibonacci-Folge, also die Implementierung\nder Fibonacci-Folge, die Implementierung des\nUnit-Tests, richtig? Sie beinhalten solche\nAlgorithmenprobleme, die man\nim zweiten Studienjahr gelöst hat, und die überhaupt\nnichts mit der\nrealen Programmiererfahrung zu tun haben.  Also, im Laufe der Zeit\nwollte der Kunde\nunsere eigenen Evaluierungen entwickeln, die\nanwendbarer, genauer und stärker\nauf reale Softwareprobleme bezogen waren.\nWährend wir daran arbeiteten, stießen\nwir auf diese unglaubliche Gruppe vom\nStanford University Institute, die\nzeitgleich mit diesem Benchmark\nnamens Terminal Bench herauskam. Das Beste an\nTerminal Bench war, dass er nur eine\nkleine Anzahl von Problemen enthielt – genauer gesagt 89\nProbleme –, die sehr gut auf\nreale Softwareentwicklungsaufgaben anwendbar waren.\nDazu gehören beispielsweise Datenbankprobleme,\nRace Conditions, Frontend-Bugs, also ganz\nnormale Probleme, mit denen\nSoftwareentwickler wie Sie\ntagtäglich konfrontiert werden.  Und mitten in der\nArbeit an unserer Evaluierung wurde uns klar:\nHey, die haben da ein\ngroßartiges Ökosystem mit einer Reihe guter\nProblemstellungen geschaffen.  Sie lassen sich leicht bedienen.  Sie lassen sich\nleicht nachbilden.\nDiese Evaluierungstools lassen sich problemlos mit allen\nCodierungsagenten verwenden, egal ob Codex Cloud\nCode Client oder ähnliches.\nAlso haben wir\nu adoptiert, wir haben ähm ihre Bewertungen übernommen\n.  Das\nSchwierigste daran war, wenn man\nwie\nein KI-System misst, wenn man etwas\nsehr Triviales misst.  Wenn man also\netwas misst, wie zum Beispiel die Anzahl der Rs in\neiner Erdbeere oder die Anzahl der Zehen\neiner Katze, dann hat man eine gewisse\ndeterministische Antwort. Oder man weiß, wie\ndas Wetter irgendwo ist, das sind Dinge, die man mit einer\neinzigen Methode bestimmen kann. Ich denke, das Problem mit den Agenten\nist, dass, wenn man einen Agenten bittet: „\nHey, schreib einen MCP-Server, der sich mit\nmeiner App über dieses O verbindet“, der\nAgent dann\neine Menge verschiedener Dinge tun wird.  Es wird wahrscheinlich\nein Web-Suchmaschinentool verwenden.  Möglicherweise wird\neine Python-Bibliothek installiert.  Vielleicht wird es so etwas wie eine\nSandbox sein.  Vielleicht\nliest es ein paar Dateien.  Vielleicht werden\nein paar Dateien bearbeitet.  Der gesamte Vorgang\nkönnte etwa 5 bis 10 Minuten dauern.\nBei einer solchen\nEvaluierung sollte man also in der Lage sein, all diese Schritte durchzuführen.\nSie haben den Agenten tatsächlich 5, 10, 20, 30 oder\n40 Minuten lang laufen lassen.  Lass es den ganzen Vorgang durchführen\n.  Und wenn es dann fertig ist, gibt es so\ndeterministische Unit-Tests,\ndie beispielsweise überprüfen, ob ich die Datei erstellt habe?\nLäuft es?  Besteht es den Test?  Und genau das\nist die Funktion einer Terminalbank\n.  Es ist wie eine agentenbasierte Bewertung, die\neine Weile dauert.  Manche dieser\nProbleme brauchen etwa 30 bis 45\nMinuten, in denen der Agent ununterbrochen\nläuft und verschiedene Lösungsversuche unternimmt. Sobald das\nerledigt ist, wird das Problem bewertet.  Ähm,\ndas ist die Bank und ich bin\ndem Team sehr dankbar.  Ein großes Lob an\nsie!  Ähm, ja.\nWenn man also so etwas wie einen Bewertungsbogen hat\n, richtig? Dann möchte man ja in der Lage sein,\nein Problem zu definieren.  Wie\ngefällt es Ihnen und was lernen Sie daraus?\nIch rede hier nur über meine Sache,\naber wie könnt ihr das interpretieren?  Es gibt also\nein paar Dinge, die man bei der\nArbeit an agentenbasierten\nEvaluierungen im Auge behalten sollte, richtig?  Als Erstes sollte man\nerfassen, wie viele\nKurven das Fahrzeug benötigt.  Wie viele Werkzeugaufrufe\nsind nötig?  Wie viele Tokens werden\nverwendet?  Wie lange dauert der gesamte Lauf?\nDer Durchlauf kann dauern, manchmal gibt es\nModelle, die sehr, sehr gut\nperformen, aber die brauchen etwa 45\nMinuten, weil die Inferenz so\nlangsam ist, richtig?  Wenn Sie diese\nParameter anpassen, also genau festlegen, was Sie\nsuchen, und das Ganze auf verschiedenen\nModellen ausprobieren, kommen Sie meiner Meinung nach dem, was Sie\nwirklich wollen, dem, womit Sie einverstanden sind, und dem,\nwie viel Geld Sie\nfür diese Qualität ausgeben möchten, viel näher.\nUnd wenn man all diese Dinge erfasst hat, dann ist das meiner\nMeinung nach genau das, was man\nbraucht, denn so sehr ich mir auch wünschen würde, dass\njeder\nfür jedes Problem das teuerste Spitzenmodell verwendet\n, ich glaube nicht, dass die\nWelt so funktioniert.  Als hätten wir nicht unendlich viel\nGeld.  Manchmal ist es einfach\nsinnvoller, beispielsweise Deep Seek V4 für Flash zu verwenden\n, das nur etwa ein Fünfzigstel des Preises eines\nanderen Modells kostet.  Und ich denke,\nwenn man diese Dinge in EVAL verfolgt, dann\nzeigen sie einem, wie man herausfindet,\nwas man auswählen soll\n.  Also speziell für Terminal\nBench, die Funktionsweise der Auswertung ist die, von der ich\nIhnen erzählt habe, dass es etwa 89 Aufgaben gibt,\nrichtig?  Bei diesen 89 Aufgaben könnte es sich beispielsweise um\nCaching-Bugs, Latenzprobleme,\nReg-X-Bugs, Frontend-Bugs, Race\nConditions oder ähnliches handeln – also um Implementierungsaspekte\n.  Terminal Bench\nmacht mit Harbor Folgendes: Wenn Sie\nProbleme haben, die Sie lösen möchten,\nerstellen Sie isolierte\nContainerumgebungen, in denen Sie\ndas Ganze einrichten.  Sie richten die\nMaschine ein, Sie richten die Umgebung ein, Sie\ninstallieren die Abhängigkeiten, Sie installieren\nalles, was Sie auf dieser\nspezifischen Maschine benötigen, in einem isolierten\nContainer und dann führen Sie den Agenten darauf aus\n, richtig?  Wenn Sie also einen Agenten mit dem\ngleichen Ausgangspunkt starten, also mit der\nVersion\nvon Python und JavaScript, die Sie\nbenötigen, dann\nfunktioniert alles, und ab diesem Zeitpunkt\nstartet der Agent.  Der Vorteil der Nutzung des\nHafens bestand also auch darin, dass er mit dem\nTerminal Bench Team verbunden war.  Der Vorteil dieser Vorgehensweise liegt darin, dass die\nAuswertungsoperationen, wie früher üblich,\nsequenziell durchgeführt werden.  Sie werden also nacheinander\nausgeführt, und es wird\netwa sechs bis sieben Stunden dauern, bis die Auswertung\nabgeschlossen ist, da die Probleme\nsequenziell ablaufen und sich\ngegenseitig im Code beeinträchtigen.  Sie\nwerden sich gegenseitig in ihren jeweiligen\nUmgebungen und Systemen beeinträchtigen.  Harbor ermöglicht es\nIhnen,\nalle Elemente in unterschiedliche\nUmgebungen aufzuteilen, und dann könnten Sie beispielsweise\nEwells darauf ausführen.  Wenn Sie also\nIhre eigenen E-Mails verwalten oder Ihre\neigenen Elektrofahrzeuge bauen, würde ich Ihnen dringend raten,\ndiese wirklich zu containerisieren und\nvoneinander zu isolieren.\nDeshalb mischen sie sich nicht\ngegenseitig in ihre Probleme ein.  Und wir\nverwenden ein Modell.  Das Modell ist wie die\nInfrastrukturschicht, die uns hilft,\ndiese parallelisierten, containerisierten\nUmgebungen zu erstellen, sodass unsere\nEvaluierungsaufgaben immer in\nverschiedenen Containern ausgeführt werden, so wie\nich es\nhier gezeigt habe. Ein großes Dankeschön an das Modell! Okay, wie sieht\nder Prozess aus?\nWas macht man hier? Der\nProzess ist sehr einfach: Man führt die\nUL mit dem eigenen Agenten (Codierungsagent oder einem\nanderen Agententyp) aus, erhält eine ursprüngliche\nPunktzahl und findet heraus, was\nschiefgelaufen ist.  Um Ihnen ein ganz\ngenaues Beispiel zu geben:  Haben Sie jemals beispielsweise `\nclock\ncode` oder `\ncodeex` verwendet? Dann versucht das Programm,\neine Datei zu lesen oder\netwas zu installieren, und gerät dabei in eine Endlosschleife mit Fehlermeldungen wie „Kann dies\nnicht\ninstallieren“, „Kann dies nicht lesen“ oder ähnlichem. Es wiederholt sich immer wieder\nderselbe Fehler.\nIch bin sicher, Sie kennen das Problem.\nWenn man\nEvaluierungen in größerem Umfang durchführt,\nwerden diese Probleme sehr deutlich.\nWenn es beispielsweise\n89 Aufgaben gibt, dreht sich das Modell bei 20 Aufgaben im\nKreis und\ntut nichts, so als ob es versucht hätte,\neine Datei zu lesen, aber nicht lesen konnte, oder als ob es versucht hätte,\neine Datei zu bearbeiten, aber nicht bearbeiten konnte, oder als ob es\nInstallationsprobleme gäbe.  Wenn\nSie die Auswertung durchführen, erhalten Sie eine Art\nPortfolioaufteilung Ihrer Fehlschläge.\nWenn Sie also beispielsweise Probleme beim\nLesen von Dateien haben, wenn Sie bei der\nInferenz scheitern, wenn Sie bei\netwas anderem scheitern, können Sie herausfinden,\nin welche groben Kategorien sich\nIhre Erfolge und Misserfolge einordnen lassen.\nUnd wenn man das erst einmal herausgefunden hat, wenn man\ndiese kleinen, großen Eimer voller\nErfolge und Misserfolge durchschaut hat, kann man\niterativ\ndie genaue Problemstellung erkennen und darauf hinweisen.\nEines der Beispiele, die wir bei\nunseren Tests gefunden haben, war, dass es manchmal\nModelle gab, die einfach nicht\ngut mit der Bearbeitung bestimmter Dateien funktionierten.\nWir würden also das Dateibearbeitungswerkzeug ändern.\nManchmal funktionierte der Webbrowser nicht richtig\n.  Wir werden also\ndieses Werkzeug ändern.  Und ich denke, dass die Betrachtung der\nManifestation Ihrer\nProbleme in aggregierter Form\neine viel einfachere Möglichkeit ist,\ndie Benutzererfahrung zu simulieren,\ndenn wie sonst wollen Sie\nherausfinden, was schiefgelaufen ist?  Also, es gibt\neigentlich drei Dinge, die Sie\ntesten.  Welche drei Dinge\ntesten Sie?  Du testest das\nModell.  Natürlich testet man das\nModell auf seine Qualität, aber\nman testet auch den Kabelbaum.  Das\nGurtzeug ist Ihr Gerüst als Agent.\nWenn man also den Agenten so schreibt, ist es\nmöglich, dass es ein\nwirklich sehr gutes Modell gibt, man es aber einfach\nfalsch geschrieben hat.  Die beste\nErklärung ist folgende: Wenn ein neues Modell von\nAnthropic herauskommt, würden Sie garantiert\nbemerken, dass es\nim Cloud-Code besser funktioniert als beispielsweise Droid oder\nCursor. Und wenn\nes sich um dasselbe Modell handelt, warum ist es dann\nim Cloud-Code so viel besser als bei\nanderen Agenten?  Warum ist das so?  Und genau das\ntesten Sie hier im Grunde.\nManchmal ist es so, dass das Modell an sich großartig ist, aber das\nGeschirr einfach nicht so ausgelegt ist, dass es\ndem Modell gerecht wird und\nes verständlich macht.  Und dann\ntestet man als Letztes das\ngleiche Problem, denn man könnte ja ein\ndummes Problem lösen, das einfach\nnicht auf die eigene Auswertung zutrifft.   Es ist\nalso wichtig, dass alle drei Faktoren aufeinander abgestimmt sind\nund dass man ganz ehrlich zu sich\nselbst ist, so nach dem Motto: „Hey, das\nversuche ich zu tun, und das funktioniert für\nmich.“  In unserem Fall lief es ungefähr so ​​ab:\nWir haben die Evaluierung zum ersten\nMal durchgeführt und dabei\nein erstes Ergebnis erhalten.\nDann haben wir einige Änderungen an der CPU-\nSpeicherschicht vorgenommen, z. B. die Timeouts erhöht\nund das Denkverhalten verbessert. Durch\ndiese iterativen Änderungen\nverbesserten sich unsere Ergebnisse stetig, und schließlich konnten\nwir den Clock-Code\nfür Oppus 4.5 Eels schlagen. Im Laufe der\nZeit stellten wir fest, dass wir den\nClock-Code auch in anderen E-Mails schlagen können.\nÄhm, weil wir einfach ein paar\nkleine Stellschrauben entdeckt haben, die sie nicht\nentdecken konnten oder für die sie nicht optimiert haben.\nAlso, ich denke, wenn man\nan einem interessanten Problem arbeitet,\nkann man sich einfach sagen: „Hey, lasst mich herausfinden,\nwas ich tue. Lasst mich herausfinden,\nwas meine Konkurrenten tun, lasst mich\nein paar großartige Evaluatoren entwickeln\n, ich werde sie einfach schlagen. Ich werde\nes einfach so viel besser machen als\nsie.“  Es gibt also drei Bereiche mit\nVerbesserungspotenzial.  Der erste ist doch der\noffensichtlichste Mangel, oder?  Zum Beispiel die\noffensichtlichen Mängel, also was ist denn\noffensichtlich falsch an Ihrem\nAgenten?  Es könnte also sein, dass Ihr\nDateileseprogramm fehlerhaft ist.  Es könnte sein, dass\nIhre Agenten-Apps nicht richtig funktionieren.\nVielleicht sind deine Checkpoints defekt.  Vielleicht\nist etwas Offensichtliches kaputt.  Rechts?\nDas bedeutet im Grunde,\ndass Ihr Agent\nauf einer fundamentalen Ebene defekt ist.  Sobald man\ndiese grundlegenden\nDinge behoben hat, fängt der Agent an zu funktionieren, es sieht so aus, als ob er\ntatsächlich\nfunktioniert, und das ist ein guter erster Schritt bei der\nArbeit mit Evaluierungen,\ndenn man möchte ja die offensichtlichen\nFehler beheben.  Die zweite Zone – und ich glaube, hier beginnt\ndie eigentliche\nHerausforderung – ist, dass man sich an diesem Punkt fragt:\nWie können wir\ndie philosophischen\nAspekte herausfinden, wie wir unseren Agenten\nverbessern können?  Oftmals stellt man fest, dass\nes so ist, als ob man alle möglichen\nDinge in der Eingabeaufforderung, im\nToolaufruf, in den Toolaufrufdefinitionen,\nin der Logik der Wiederholungsversuche oder was auch immer hat, und dass der\nAgent einfach\nnicht gut funktioniert.  Und ich denke, dass\nes zum Teil Ihre Schuld ist, weil Sie so schnell die\nTechnik vorangetrieben haben.  Vielleicht liegt es daran, dass ich zu\nviele Werkzeuge benutze.  Vielleicht nutzen Sie\nzu wenige Werkzeuge.  Vielleicht verwenden Sie die\nfalschen Werkzeuge.  Und ich glaube, das ist die eigentliche Stärke\nvon Eals:\nAnstatt herumzusitzen und\nphilosophisch darüber zu dozieren, ob der\nAgent gut ist oder nicht, kann man\nsehr differenzierte Urteile darüber fällen, ob der\nAgent tatsächlich gut ist oder nicht, indem man\nihm echte Probleme zum Lösen gibt.  Und\ndann gibt es noch die Zone 3, die so etwas wie die Gefahrenzone ist.   Der\nGrund, warum ich Zone 3 als\nGefahrenzone bezeichne, ist, dass manche\nLeute die Angewohnheit haben,\nsobald man ihnen eine Kennzahl oder\neine Zahl zum Optimieren gibt, nichts anderes mehr zu tun, als diese\nZahl zu optimieren.  Es ist ihnen also im Grunde egal,\nworin das Problem besteht, richtig?\nWenn man jemandem eine Zahl gibt,\noptimieren sie einfach für diese\nZahl.  Sie werden\ndas Modell also quasi überanpassen.  Sie werden\ndie Aufgabenstellung so ändern,\ndass sie nur diese eine\nAufgabe bestehen.  Die fügen dann so komische\nFähigkeiten und so was hinzu.  Das ist also nicht\nschön.  Man sollte also darauf achten, dass man sich zwar\nverbessert, aber nicht zu\nviel trainiert oder etwas falsch macht.\nWenn ich Ihnen also zum Schluss noch einen\nRat geben dürfte, dann wäre es dieser: Finden Sie einen Benchmark,\nder für Sie funktioniert.  Erstellen Sie nach\nMöglichkeit eine Evaluierungsumgebung.  Du solltest Bergsteigen.  Ehrlich gesagt\nbedeutet Bergauffahren genau das Gleiche wie die Verbesserung der\neigenen Punktzahl bei der Bewertung.  Und selbst wenn\nman eine gute Punktzahl erreicht, muss man immer\nsicherstellen, dass man auch den Vibe-Check besteht.\nMan muss auf einer gewissen emotionalen\nEbene wissen, dass die Entscheidung meines Agenten Sinn ergibt\n.  Es geht eben nicht nur\num Benchmarks.  Ist das ein\nvernünftiger Agent?  Ist das verständlich?\nLöst es tatsächlich unsere Probleme?  Man\nmuss ja irgendwo anfangen.  Man muss ja\nirgendwo anfangen.  Ich finde, das ist eine großartige\nDisziplin.  Äh, wir haben ein paar Monate\nbeim Kunden daran gearbeitet.  Wir\narbeiten noch daran.  Jedes Mal, wenn ein neues Modell auf den Markt\nkommt, versuchen wir es zu evaluieren.  Wir verbessern\ndamit die Benutzererfahrung des neuen Modells.  Äh, wir\nverwenden jetzt viele Open-Source-Modelle\n.  Wir versuchen also, die Evaluierung zu unterstützen\nund zu verbessern.  Ähm, und ich glaube,\nwir hätten all\ndiese schönen Nuancen dieser\nOpen-Source-Modelle, die\nunglaublich viel günstiger sind, nie entdeckt, wenn wir nicht\nEvaluierungstests durchgeführt hätten, weil wir\nsie einfach komplett ignoriert und uns nur\nauf Wibbes konzentriert hätten.",
  "transcript_chars": 28459,
  "ingested_at": "2026-05-23T04:31:04.198468+00:00",
  "source": "channel",
  "yt_meta": {
    "view_count": 269,
    "like_count": 14,
    "channel_id": "UCcIXc5mJsHVYTZR1maL5l9w",
    "categories": [
      "Education"
    ],
    "tags": []
  }
}