{
  "video_id": "YYH0DMQr30A",
  "channel_slug": "aidotengineer",
  "channel_handle": "aidotengineer",
  "title": "Same compute, 5x better results — Kobie Crawdord, Snorkel",
  "duration_seconds": 1240.0,
  "url": "https://www.youtube.com/watch?v=YYH0DMQr30A",
  "upload_date": "",
  "transcript": "Mein Name ist Kobe Crawford.  Ich bin\nDeveloper Advocate bei\nSnorkel.\nWir sind das führende KI-Datenlabor.\nDas bedeutet, dass wir\nDatensätze für Basismodelle erstellen, auf denen diese aufbauen können\n.  Unser Forschungsteam ist daher\neng mit\nunserer Produktionsarbeit verknüpft.  Und\nwir legen großen Wert darauf, wie wir\nForschung dabei integrieren.  Die\nUrsprünge dieses Unternehmens liegen tatsächlich in einem\nKI-Forschungslabor der Stanford University, und die\ndort geleistete Arbeit\nwar Teil der\nDoktorarbeit eines der CEOs. Daraus entwickelte sich dann eine\nBibliothek, die eine Zeit lang als Open Source genutzt wurde, und\nschließlich haben wir uns darauf spezialisiert,\nunseren Kunden Datensätze bereitzustellen.\nEines der Dinge, die sich\nbei Snorkel\nseit der Gründung des\nUnternehmens im Jahr 2019 wie ein roter Faden durchgezogen haben, ist die\nKernthese, dass die Qualität der\nDaten von entscheidender Bedeutung ist und dass man sicherstellen möchte, dass die Daten, die man\nbetrachtet, von\nhöchster Qualität sind\n.  Wir schauen uns also an, wie sich das auf\ndie von uns bereitgestellten Datensätze auswirkt, und wenn sich die\nDinge in Richtung agentenbasierter Prozesse bewegen,\nwie sich das auf agentenbasierte Aufgaben auswirkt.\nUnd was wir in diesem Zusammenhang zeigen wollten,\nist,\nwie sich die Datenqualität auf die\nAufgabenqualität auswirkt, und\ndie Aufgabenqualität und die Datenqualität\nsind im Wesentlichen dasselbe\n.\nWir werden also über das\nspezielle Forschungsziel sprechen, nämlich die Frage,\nwie sich die\nAufgabenqualität auf die Trainingsergebnisse auswirkt,\ndie man bei der\nVerbesserung von Modellen erzielt.\nUnd dann werden wir\nüber die\nTechniken und den Weg sprechen, den wir\ngewählt haben, um zu überprüfen, ob diese\nVerhaltensweisen tatsächlich bei\nuns auftraten.\nÄh, also, spielt die Qualität der Aufgabe tatsächlich eine\nRolle? Äh, das\nkann man aus\nunserer These darüber ablesen, dass wir tatsächlich der Meinung sind, dass sie das\nnatürlich tut.  Und äh, um das Ganze\naufzuschlüsseln, müssen wir sicherstellen, dass\nSie\nverstehen, wie wir an die Sache herangehen.\nWir sprechen hier speziell im\nKontext von Agentic-Terminal-Bench-\nAufgaben.  Äh, also, wir arbeiten mit\neinem Ablauf, der eine\ncontainerisierte Umgebung sein wird, und darin befindet sich eine\nAufgabendefinition.\nWir möchten zeigen, dass, wenn man sich ansieht,\nwie\ndie Aufgaben selbst und wie\nsie aufgebaut sind, das, was wir\nim Agentic-Kontext tun, immer noch\nvon denselben Datenqualitätsgrundsätzen bestimmt wird\n.  Das gilt also sowohl für die\nQualität von Aufgaben als auch für die\nQualität von Daten.  Wenn sich also Ihre\nArchitektur ändert, wenn sich das von\nIhnen verwendete System ändert,\nall diese Dinge haben\nnatürlich auch Auswirkungen, aber im\nKern steht immer noch die\nDatenqualität.\nWir wenden hier also ganz\nbestimmte Methoden an, um\nempirische Beweise zu liefern und zu\nbestätigen, dass dies wahr ist.  Wir wollen nicht einfach nur so tun, als ob\nwir\ndas akzeptieren, als wäre es etwas, von dem wir gerne\nbehaupten, es sei wahr.  Wir möchten tatsächlich\nüberprüfen, ob das der Fall ist.\nBei der Definition von Aufgabenqualität\nsprechen wir im Wesentlichen über vier\nKernpunkte.  Wenn Sie schon einmal mit solchen\nUmgebungen gearbeitet haben, dem Harbor-\nFramework, OpenEnv, wenn Sie\nAufgaben für Agentic-Zwecke erstellt haben, dann geht es\nim Kontext der\nEvaluierung, des Benchmarking von RL darum, dass wir\neine Umgebung schaffen, in der das\nausgeführt werden kann.  Wir haben es in einem\nContainer untergebracht, um Reproduzierbarkeit und\nIsolation zu gewährleisten.  Und das ermöglicht es Ihnen auch, die\nEinführung solcher\npraktischer Elemente, wie das funktioniert, zu parallelisieren.\nInnerhalb dessen muss man sich die\nLogik der Aufgabe ansehen.  Sie\nmöchten darüber sprechen, dass die Aufgabe\nerreichbar ist,\ndass sie nicht trivial ist, dass sie\nfunktional korrekt ist, dass\ndie Logik wie erwartet funktioniert\nund dass die Umgebung selbst\nzuverlässig ist.  Und dass diese\nZuverlässigkeit der Umgebung ebenfalls ein Schlüsselfaktor ist.\nDiese vier Kriterien sind für uns bei unserer\nArbeit an diesem Projekt wichtig. Das Snorkel-Team hat\nin seine Forschungsmethoden, also seine Forschungseinrichtungen,\neinen Aufbau entwickelt, mit dem wir\nalle vier Kriterien überprüfen können.  Und in unseren\nTests zur Überprüfung dieser Kriterien\nverwenden wir die folgenden Tests:  Wenn eine\nAufgabe alle diese Tests besteht,\nbetrachten wir sie als akzeptierte Aufgabe\nund sie wird dann zu etwas, das wir\nfür unsere Ausbildung, Forschung und\nZwecke verwenden können.  Und wenn es dann nicht akzeptiert wird,\ndann würde es in den Ablehnungsordner wandern\n.  Und wir verwenden diese beiden Kategorien als\nGrundlage, um darüber zu sprechen, wie wir qualitativ\nhochwertige\nAufgaben, die akzeptierten Aufgaben, mit Aufgaben von\ngeringer Qualität vergleichen werden.\nWerfen wir also einen kurzen Blick auf diese Vergleiche\nund stellen wir sicher, dass, wenn wir sie uns\ntatsächlich ansehen und eine\nNiveaufestlegung vornehmen, die Akzeptanzkriterien, die\nwir verwenden, tendenziell mit den tatsächlichen\nLeistungsverhaltensweisen korrelieren, die wir\nsehen wollen, und wie sie sich unterscheiden.\nUnd so haben wir das gemacht: Wir haben\nSign bei 4.5 verwendet, das war also\nvor einigen Monaten, und Codex, der\nGPT 52, 51 und manchmal 40\nin die durchgeführten Tests einbezogen hatte.  Aber\nwir haben\ndiese beiden äh für die Durchführung dieser äh\nTests verwendet.  Und wir haben verglichen, wie diese\nAufgaben\nerledigt wurden.  Und bei der\nAuswertung der abgeschlossenen Aufgaben stellten wir fest, dass\nunsere akzeptierten Aufgaben im Durchschnitt doppelt so\nviele Tool-Aufrufe erforderten, was auf einen\nhöheren Schwierigkeitsgrad, mehr\nnotwendige Schritte und eine intensivere\nNutzung der externen Tools hindeutet.  Eine\nniedrigere Erfolgsquote, also ein höherer Schwierigkeitsgrad,\näh, naturgemäß.  Und dann, äh, wurden auch\nmehr Ausgabetoken benötigt, daher mussten\ndie Modelle weitere Schlussfolgerungen ziehen, um dies\ntatsächlich zu erreichen.\nÄhm,\ndie Fehlerarten jedoch... Also, kommen wir für\neinen Moment zurück zur Erfolgsquote\n.\nIm Kontext einer niedrigeren Erfolgsquote ist es möglich,\ndass\nFehlermodi auftreten, die keine\naussagekräftigen Signale liefern.  Wir wollen uns also auch\nein wenig mit den Fehlerursachen auseinandersetzen\n.  Der nächste Schritt wäre also, einfach\nzu fragen: „Okay, was\nbedeutet es, über diese\nMisserfolge zu sprechen?“   Um\ndas zu erreichen, haben wir die\nFehler in Kategorien unterteilt, um\ndie Arten von Fehlern zu identifizieren,\ndie etwas\nSinnvolles darstellen, wie zum Beispiel, dass dieses Modell\ndie Aufgabe nicht vollständig erfüllt,\nweil das Modell nicht zu\neiner logischen Schlussfolgerung gelangt, die es erreichen muss, im\nGegensatz zu einem Fehler, der eher ein Extremfall ist, bei dem\nein Problem vorliegt, das ein\nUmweltproblem ist, etwas, das\nbuchstäblich dazu führt, dass kein Modell in der Lage wäre,\ndieses Problem zu lösen und\ndiese Aufgabe in diesem\nspeziellen Ablauf zu erledigen.  Wir haben also eine Aufschlüsselung\ndavon, und dann wollten wir, ausgehend von diesen, die\nakzeptierten mit den\nabgelehnten Aufgaben vergleichen, um zu sehen, wo die\nFehler bei diesen Aufgaben auftreten\nund was wir daraus lernen können.\nÄhm, hier ist eine Zusammenfassung der Aufschlüsselung der einzelnen Punkte, äh\n,\ndes Prozentsatzes der Fehler, die wir\nin den verschiedenen Kategorien festgestellt haben.\nIch möchte insbesondere die Balken für\nLogikfehler und unvollständige Aufgaben hervorheben.\nMan\nkann sehen, dass sich die Reihenfolge umkehrt, je nachdem, welcher Fehler den\nhöheren Prozentsatz aufwies\n.  Und dann diese Aufschlüsselung, ähm,\nselbst mit dieser, äh, mit einer\nvergleichenden äh Analyse auf der Grundlage\nvon Fehlerprozentsätzen, kann man sehen,\ndass man den Unterschied in Bezug darauf sehen kann,\nwo man die\nÜber- oder\nUnterrepräsentation dieser Arten von\nFehlern bei den Arten von Fehlern sieht,\ndie wir äh kategorisiert haben, und wiederum zwischen\nden abgelehnten Aufgaben und den\nakzeptierten Aufgaben, die\nFehler aufwiesen.  Die allgemeine Tendenz, die\nwir daraus mitnehmen, ist, dass die\nakzeptierten Aufgaben zu saubereren\nFehlschlägen führen.  Hierbei handelt es sich um Fehlschläge, die darauf zurückzuführen sind, dass die\nAufgabe selbst schwieriger ist, tatsächlich\nschwieriger als die Schritte, die zu ihrer Bewältigung notwendig sind. Das bedeutet, dass dieser\nTest\nfür das Modell sehr nützlich wäre, um es zu verbessern und\nDatenbeispiele zu liefern, die dazu\nbeitragen könnten, seine\nLeistungsmuster zu optimieren, im\nGegensatz zu\neinem Fehlschlag, der nicht besonders\naussagekräftig ist, da es sich lediglich um eine\ntaktische Sache handelt, die innerhalb\ndes Kontextes passiert und nicht funktioniert.   Ähm,\nunter Berücksichtigung dessen gehen\nwir davon aus,\ndass\nwir genügend\nAnalysen durchgeführt haben, um den Eindruck zu erwecken,\ndass die akzeptierten Aufgaben im Allgemeinen auch qualitativ hochwertigere Aufgaben sind. Und da\nwir nun\nzwischen den\nqualitativ hochwertigeren und den qualitativ minderwertigeren\nAufgaben unterscheiden können, wollen wir untersuchen, ob sich dies\nauf die Modellleistung auswirkt\n.  Im Anschluss daran führen\nwir einfach einen\nTrainingslauf durch, einen RL-Trainingslauf mit\ndemselben Modell,\ndemselben Rechenbudget und derselben Anzahl\nvon Aufgaben in jedem Fall,\nund schauen uns dann den Unterschied an\n.\nWir haben also festgelegt, dass wir eine Reihe\nvon Testaufgaben haben, die wir als qualitativ hochwertig betrachten, und eine Reihe\nvon Aufgaben, die wir als\nqualitativ minderwertig betrachten. Diese Analyse wird\nuns helfen, etwas darüber auszusagen\n.\nWir haben es also zweimal trainiert\nund wollten sehen, was dabei herauskommt.\nUnd die Leistungssteigerung ist\ntatsächlich sehr bedeutsam.\nÄh, wir sprechen hier von einer Verbesserung von etwa 1 %\ndurch die Verwendung der Aufgaben mit geringer Qualität\n.  Nach Abschluss des RL-\nTrainings verbesserten die Aufgaben niedriger Qualität\ndas Basismodell nur um etwa 1 %\n, während die Verbesserung\nbei den\nAufgaben höherer Qualität etwa 6 % betrug.  Dieser\nfünffache Leistungszuwachs, der allein auf\nQualität beruht,\nist aus unserer Sicht wirklich bemerkenswert\n.  Wir glauben, dass dies die\nIntuition bestärkt,\ndass eine hohe Datenqualität wirklich wichtig ist\n.\nDie Art und Weise, wie Snorkel Datensätze generiert,\nund die Art und Weise, wie wir\nRL-Umgebungen zusammenstellen, nutzen menschliches\nFachwissen\nund beziehen Experten in den Prozess der\nDatengenerierung ein.\nWir sind der festen Überzeugung, dass die Einbindung von Experten\nein wichtiges Element für die\nGewährleistung der Datenqualität ist.\nUnd das alles zusammen ergibt letztendlich, dass\nwir genauer darüber sprechen können, wie unsere Plattform funktioniert,\nwie wir sie nutzen, damit\nunsere Experten damit arbeiten und\nwir skalieren und Qualität\nin großem Umfang liefern können.  Aber der entscheidende Punkt ist, dass\nwir den Schwerpunkt darauf legen wollen,\nsicherzustellen, dass Qualität das Erste ist, woran die\nLeute denken, wenn es darum geht, was sie\nvon ihren Daten erwarten, um sicherzustellen, dass sie\ngute Ergebnisse erzielen.   Das war also das Ergebnis dieser Aktion\n.\nHoffentlich haben Sie noch\nein paar\nMinuten Zeit für weitere Fragen, aber\nhier sind ein\npaar Links zur\nForschungsseite des Snorkels, die zusammenfassen,\nwie unser Forschungsteam arbeitet,\nwas wir tun und worauf wir unseren\nSchwerpunkt legen.  Und dann\nverweist die Rangliste auf ein paar\nBenchmarks, die Snorkel selbst erstellt und\nkuratiert hat und die denen\nähneln,\ndie Sie bereits gesehen haben.  Wir haben eine Methode namens\ngenetische Codierung, die sich\nspeziell auf diese Aufgaben im Terminal-Bench-\nStil konzentriert.\nWir führen zwar die gleichen\nEvaluierungen durch, wenden dabei aber eine gewisse\nStrenge an, um\nsicherzustellen, dass die\nMenschen den Unterschied erkennen können.\nVielen Dank, dann beantworte ich die\nnächste Frage.\nDarf ich noch Anschlussfragen beantworten?  Ich fange\nhier an.\nIch frage mich nur, ob Sie sich eine\nandere Art von ABC ansehen könnten, also\nalle Aufgaben, die voraussichtlich angenommen wurden, um zu sehen,\nob es einen\nEffekt der\nabgelehnten Aufgaben gibt, der das Ergebnis wieder nach unten zieht, oder ob\ndas Modell das kompensieren kann,\nsolange alle Aufgaben vorhanden sind.\nÄhm,\neine gute Frage.\nDas\nInteressante daran ist, dass\nich aufgrund der\nAnalyse,\ndie wir in diesem speziellen Fall durchgeführt haben, keine konkrete, schnelle und direkte Antwort darauf habe.  Ähm, aber\neine der Dinge, die wir\nbei der Untersuchung und der Arbeit mit\nbeispielsweise dem Terminal Bench\nTeam gesehen haben, und beim Betrachten der Aufgaben\nin Terminal Bench 1 im Vergleich zu dem, was\nwir für Terminal Bench 2\nund in einigen anderen Kontexten im Zusammenhang mit einigen\ndieser Bench-Varianten getan haben, haben\nwir intern Analysen durchgeführt, um\ndie verschiedenen öffentlichen Benchmarks zu vergleichen\nund zu sehen, was\nwir dabei feststellen. Und\nwenn wir uns das ansehen,\nsieht man sicherlich, dass sich die\nAusfallraten und ähnliches im Laufe der\nZeit verbessert haben, egal ob die Modelle\nschneller die Sättigung erreichen oder\ndie Benchmarks selbst\nschneller die Sättigung erreichen.\nManchmal kommt es vor, dass wir solche Störungen erleben,\nweil am Ende\neine bestimmte Anzahl von Aufgaben\nnie erledigt wird.  Dann\nsehen wir also, dass diese Aufgaben\nbuchstäblich nie erledigt werden können, weil sie es schlichtweg\nnicht können, richtig?  Ja, und deshalb stellten\nwir fest, dass dies\ntatsächlich eine Art\nStörfaktor bei der\nBewertung war, ob\ndie Modellverbesserung tatsächlich\nstattfand.  Insofern kann ich nicht sagen, ob sich\ndie Modelle tatsächlich verbessert haben oder nicht. Es ist eher\netwas, das durch\ndie Qualität der Aufgabenprobleme verschleiert wurde, als etwas, woran\nwir erkennen konnten, ob sich die\nModelle\ntrotz der Probleme tatsächlich verbessert haben oder nicht\n.  Es entpuppte sich letztendlich eher als\nLärmquelle.\nÄhm, ich habe hier noch ein paar andere Fragen gesehen\n.\nWissen Sie, haben Sie eine Ahnung, wie sich\ndie Eingaben auf diese Aufgabe auswirken? Wissen Sie,\nes gibt manchmal einen Zusammenhang: Wenn die\nEingaben etwas weniger\ndetailliert sind,\nkann das die Aufgabe erschweren, oder wenn sie sehr\ndetailliert sind, kann das die Aufgabe erleichtern.  Ich\nweiß es nicht, aber ich frage mich nur, ob\nIhnen so etwas wie „Ja,\nabsolut“ begegnet ist.  Tatsächlich ist es so, dass\neine Aufgabe oft dann abgelehnt wird, wenn sie unzureichend spezifiziert ist. Das heißt, wenn\ndie Aufgabe so definiert ist, dass\ndas gewünschte testbare\nErgebnis nicht\nklar in der Testdefinition\nim Voraus angegeben ist, die Tests im Backend aber\nerwarten, dass bestimmte Dinge erfolgreich sind,\ndie nie\nangefordert wurden.  Solche Diskrepanzen sind genau\ndie Stellen, an denen\nman erkennen kann, wo die Aufgabe schwieriger wird\noder zumindest schwieriger erscheint, weil\ndie Tests nicht mit dem\nangeforderten Aufgabenaufbau übereinstimmen.\nManchmal gibt es auch implizite\nAbhängigkeiten im Test,\ndie in der Aufgabe nicht explizit angegeben sind. Wenn man\ndann\nnicht weiß, dass überhaupt eine Abhängigkeit\nerforderlich ist und was\nnicht in den Kontext des Modells eingespeist wurde,\nhat das Modell nicht einmal\nden richtigen Kontext, um auf\ndiese Abhängigkeiten zugreifen zu können.\nNur eine Nachfrage oder Korrektur.\nIch meine, es\nkönnte problematisch sein, sie als Fehlschlag zu klassifizieren, da\nnicht jede Aufgabe vollständig abgeschlossen sein muss.\nWissen Sie, es gibt Wiederholungen, es ist ein\nProzess.\nWenn wir Probleme lösen, ist das in der Regel\nkeine einmalige Angelegenheit, und das gilt für die meisten\nProbleme auf der Welt.  Also,\nja, äh, die Unterscheidung zwischen\ndem undefinierten\nkönnte\nvielleicht, ich weiß nicht, aber\nsicherlich, sicherlich.  Äh, ich stimme dem vollkommen zu, dass\nsolche Dinge, also das, was\nwir letztendlich von den Modellen erwarten,\ntendenziell so ablaufen.  Im\nRahmen der Erstellung von Benchmarking-Aufgaben\narbeiten wir daran,\netwas zu schaffen, das im Backend überprüfbar ist\n.  Und dass die erlernten Fähigkeiten im Prinzip, wenn\nwir es richtig machen, umso\nanwendbarer sind im Kontext von\nnicht überprüfbaren Ergebnissen oder bei Dingen, bei denen\nnach dem jeweiligen Arbeitsschritt eine Iteration erforderlich ist\n.  Ja,\nja, also.  Danke schön.  Ja, ja.  Ja.\nÄhm, was\nzukünftige Herausforderungen und nächste\nSchritte angeht, arbeiten Sie beispielsweise an Aufgaben,\ndie nicht so einfach\nüberprüfbar sind und eher auf einen\nsehr langen Zeithorizont abzielen?\nWir schauen uns das selbstverständlich alles an\n.  Und verschiedene Projekte von\nuns arbeiten in diesen unterschiedlichen Bereichen,\ninsbesondere wenn man die\nBereiche verlässt, in denen die Verifizierung nicht einfach ist und\nCodierung und Mathematik die Sache\nunkompliziert machen, und dann sind die Dinge, die\nunschärfer sind, anders.  Wir\nhaben ein offenes Benchmark-Förderprogramm, mit dem\nwir zusammenarbeiten, und zwar\nmit Partnern, die\nBenchmarks und Evaluierungen in eher schwer\nüberprüfbaren Bereichen entwickeln.  Und äh, es gibt\neine Menge sehr interessanter\nDinge, die wir tun, die\nmit äh einer davon zu tun haben, äh, es gibt eine\ninteressante Organisation, äh, die daran\narbeitet, ähm, ich\nversuche mich an den Namen zu erinnern,\naber es ging darum, sich\nDinge anzusehen, die so etwas wie\nemotionale\nDinge beinhalten.  Es ist\nsehr viel menschenzentriertes\nDenken.  Und so geht es\nsogar um die Frage, was richtig und was falsch ist.\nWir wollen eigentlich\nmehrere mögliche Ergebnisse haben und\ndiese dann unterschiedlich bewerten.  Aber, wissen Sie,\nirgendwie lassen sie sich alle irgendwo auf dem\nSpektrum einordnen.  Und so\nversuchen wir eine Menge Dinge\nin vielen\nverschiedenen Dimensionen zu tun.\nÄhm, ja, also es ist ein sehr interessanter\nRaum.\nEine letzte Frage am Ende.\nJa, ich wollte gerade\ndie Diskussion über\ndieses Gespräch anstoßen.  Mhm.\nWie handhabt Ihr System das\nund die Inter-Annotator-Kommunikation?\nIch nehme an, es handelt sich um eine mehrstufige\nAufgabe.\nJa.  Im Moment ist es vielleicht zuverlässiger,\nwie Sie sagten,\ndie Antwort ist etwas subjektiv,\naber demnach gibt es in der\nWelt der Annotatoren viele\nmögliche\nMöglichkeiten.\nIch spreche von der\nÜbereinstimmung zwischen den Annotatoren, sozusagen\nzentral, und dann ist da noch die Komplexität, von der Sie\nsprechen, die zu 100 %\netwas ist, das mit zunehmendem\nZeithorizont und den vielen Schritten in\nden verschiedenen Dimensionen ein\nProblem darstellt.  Das ist die letzte Frage, ja?\nOder haben wir das Zeitlimit erreicht?  Ähm, habe\nich noch 1 Minute übrig?  Du\nhast nur 1. Okay, genial.  Ähm, also\nunsere Plattform funktioniert so:\nWir setzen verschiedene Maßnahmen ein, um\nmenschliche Annotatoren zusammenzubringen und LLM-\nJuroren einzusetzen.  Und das dient zum Teil dazu, uns zu helfen, die Arbeit\nunserer menschlichen Annotatoren zu replizieren und zu skalieren,\naber auch diese\nArt von Übereinkunft, ähm, wir haben das Gefühl, dass die Art und Weise, wie\nwir heutzutage\nmit Rubriken arbeiten und eine Art\nlängere Liste von\nDatenpunkten und Kriterien bereitstellen,\ndie erfüllt werden müssen, während wir eine Reihe\nvon Rubriken erstellen, die dann\nsowohl von LLM-Richtern als auch von Personen verwendet werden können, die sich mit\nqualitativen Aspekten auf hoher Ebene sowie mit individuellen, eher\nquantitativen\nVergleichen befassen.  Und so\nentsteht anhand einer langen Liste von Kriterien ein Bewertungsraster, wobei\nmenschliche Annotatoren und Experten\nuns helfen, die Informationen – die\nFakten – zu ermitteln, die wir den\nLLM-Richtern zur Kenntnis bringen können.  Wir\nwollen\nbeispielsweise sicherstellen, dass wir eine\nsehr hohe Übereinstimmung zwischen den\neinzelnen Annotatoren erzielen, sowohl zwischen\nden LLM-Juroren als auch zwischen den menschlichen Annotatoren, und\ndiese Vergleiche dann zur\nQualitätsbewertung nutzen.  Es ist also Teil\nunseres Bewertungsprozesses und\nwir verwenden es für jede dieser\nTestarten.  In diesem Kontext, in dem\nexplizit überprüfbar ist, ob Tests erfolgreich sind\noder fehlschlagen, ist\nes natürlich immer noch ein einfacherer Bereich\nals andere, aber wir verwenden trotzdem weiterhin dieses\nLeitprinzip, das für\nalle diese Bereiche gilt.   Okay\n, vielen Dank.\nVielen Dank für Ihre Zeit.  Schön, dass\ndu da bist.",
  "transcript_chars": 20363,
  "ingested_at": "2026-06-02T22:30:29.017057+00:00",
  "source": "channel",
  "yt_meta": {
    "view_count": 477,
    "like_count": 17,
    "channel_id": "UCLKPca3kwwd-B59HNr-_lvA",
    "categories": [
      "Science & Technology"
    ],
    "tags": [
      "ai",
      "ai engineer",
      "ai engineering",
      "software development",
      "tech",
      "startups",
      "software architecture",
      "machine learning"
    ]
  }
}