{
  "video_id": "80vV6fGIlWo",
  "channel_slug": "deeplearningai",
  "channel_handle": "deeplearningai",
  "title": "AI Dev 26 x SF | Jerry Liu: My Agent Can't Read a PDF?",
  "duration_seconds": 1861.0,
  "url": "https://www.youtube.com/watch?v=80vV6fGIlWo",
  "upload_date": "",
  "transcript": "Hallo zusammen.  Äh, schön, hier zu sein.  Äh,\nich bin Jerry, Mitbegründer und CEO von Llama\nIndex.  Äh, für diejenigen unter Ihnen, die vielleicht noch\nnie von uns gehört haben, äh, heute\nkonzentrieren wir uns im Grunde alle darauf,\ndie beste agentenbasierte\nDokumenteninfrastruktur aufzubauen.  Falls Sie schon einmal von uns gehört haben:\nWir haben als ein ziemlich\nbeliebtes Open-Source-Framework angefangen.  Äh, wir haben\ntatsächlich schon einige Kurse mit deeplearning.ai durchgeführt, die Sie vielleicht finden können,\nwenn Sie in Ihrem\nGoogle-Verlauf danach suchen.  Ähm, aber im Grunde haben\nwir damit angefangen,\nLMS als\nOpen-Source-Framework mit verschiedenen Datenquellen zu verbinden.   Im\nLaufe dieser Entwicklung wurde uns bewusst,\ndass bestimmte Datentypen, insbesondere\ndokumentenbasierte Daten, nur schwer zu\nerfassen und in das richtige\nFormat zu bringen sind, damit KI-Agenten sie verstehen können.  Und\nso begannen wir, in diesem Bereich wirklich tiefgreifende Technologien zu entwickeln, um\nKI-Agenten,\nRAG-Systeme und Agenten-Tech-\nWorkflows in die Lage zu versetzen, die Vorteile der\nhochwertigen Verarbeitung zu nutzen,\ndie wir anwenden, um aus den\nkomplexesten PDFs, PowerPoints und Word-Dokumenten der Welt einen wirklich hochwertigen Kontext\nin ein Format zu gewinnen, das man dann\nin ein nachgelagertes Adantic-System einspeisen kann.\nUnsere grundlegende\nUnternehmensmission besteht heute also darin, die\nbeste künstlerische\nDokumenteninfrastruktur aufzubauen.  Im Wesentlichen geht es darum, selbst\ndie komplexesten Dokumente per OCR erfassen und\nin ein Format bringen zu können, das Ihre\nArbeitsabläufe verstehen.  Sie wissen ja, dass wir bereits über\neine Milliarde Seiten verarbeitet haben.  Wir\nhaben, wie Sie wissen, 300.000 Nutzer auf unserer\nPlattform.  Und\nOpen Source liegt uns nach wie vor sehr am Herzen.  Dazu später mehr\n, aber im Grunde ging es vor allem darum,\nden richtigen\nDokumentkontext zu schaffen, damit Ihr bevorzugter\nKI-Agent, egal ob Sie ihn\nselbst entwickelt haben oder\nCloud Code oder\nOpenClaw verwenden, Zugriff auf\nden qualitativ hochwertigsten Kontext Ihrer\nDokumente hat.\nAlso, ich denke, damit wird im Grunde\ndie Prämisse geschaffen.  KI-\nAgenten saugen sozusagen riesige\nMengen unstrukturierter Daten auf.  Ähm, der\nKern eines jeden KI-\nAgentensystems heutzutage ist im Grunde der\nKontext, den man ihm gibt.  Ähm, aber ein Großteil\ndieser Daten steckt in riesigen\nPDFs, PowerPoints, Word-Dokumenten, im Grunde\nMicrosoft Office-Dokumenten im gesamten\nUnternehmen fest.  Ob im\nFinanzdienstleistungssektor, im Rechtswesen oder im Versicherungswesen – ein Großteil\nder Arbeitswelt hat immer noch mit\neiner enormen Menge an Papierkram zu tun,\nund es erfordert viel menschliche Anstrengung,\ndiese Dokumente zu lesen,\nInformationen daraus zu extrahieren und daraus\nneue Informationen zu synthetisieren\n.   Um\nIhnen einen Eindruck\nvon unserem Produktportfolio zu vermitteln, haben wir sozusagen\nunseren wichtigsten kommerziellen Service, nämlich\nLlama Parse.  Das ist im Grunde die\nKern-API, auf die ich im\nAbschnitt zur agentenbasierten Dokumentenverarbeitung noch etwas genauer eingehen werde.  Wir werden ein wenig darüber sprechen,\nwarum dies überhaupt ein schwieriges Problem darstellt\n.  Warum weißt du, dass es OCR für Dokumente schon seit\netwa 20 Jahren gibt?  Äh,\naber ich denke, es gab viele\nProbleme mit einigen der historischen\nTechniken, und insbesondere mit einigen\nunserer Fähigkeiten können wir ein sehr\nhohes Maß an\nGenauigkeit zu geringen Kosten erreichen.  Und dann gibt es da noch\ndie Agentenebene, die es einem ermöglicht, die\nDokumentendaten zu nutzen, um\nverschiedene Arbeitsabläufe zu automatisieren, egal ob man\nFinanzanalyst ist oder im\njuristischen Bereich arbeitet und beispielsweise\nVersicherungsansprüche bearbeitet. Man kann das\nrichtige Agentensystem einsetzen, um\ndie gesamte\nDokumentenbearbeitung zu automatisieren.\nIch denke, ein Großteil dieses Vortrags – und\nder Titel dieses Vortrags – dreht sich im Grunde darum,\nwarum das Lesen einer PDF-Datei so schwierig ist. Und genau darauf wird sich\ndieser Abschnitt\njetzt konzentrieren.  Für diejenigen unter Ihnen, die\nmit einigen der nachgelagerten Anwendungsfälle von Docr nicht vertraut sind –\noder besser gesagt, bevor Sie sie kannten –, geht es im Wesentlichen darum, Docr\nsowohl in\nagentenbasierte Workflows als auch in\nallgemeine Agentensysteme einzuspeisen.\nWenn man\nim Jahr 2023 einen einfachen Chatbot entwickeln wollte, dann basierten viele der\nfrühen Anwendungsfälle von Genai im Grunde darauf, dass man\neine PDF-Datei hochlud und sie\nChatbt gab, damit dieser die darin\nenthaltenen Daten verstehen konnte.\nWenn Sie\neinem KI-System eine PDF-Datei übergeben möchten, benötigen Sie definitionsgemäß eine Art\nOCR-Schicht. Das kann beispielsweise durch einen\nScreenshot, die Eingabe in ein VLM-System, die\nVerwendung eines kostenlosen\nOpen-Source-Tools oder eines\nspezialisierten Parsing-Tools erfolgen.  Es gibt eine Menge\nmenschlicher Arbeit, die auch dadurch entsteht, dass ganze\nHeerscharen von Menschen riesige\nDatenmengen lesen, sei es\nKreditanträge,\nOnboarding-Dokumente, Rechnungen oder Quittungen,\nund überprüfen, ob die Daten korrekt sind.\nDarauf hat sich eine ganze Branche aufgebaut, die\nintelligente Dokumentenverarbeitung (Intelligent Document Processing, IDP) genannt wird. Heutzutage\nkonsolidiert und expandiert alles,\ninsbesondere im Bereich der Agenten.\nDiese können nicht nur\nviele der sich wiederholenden operativen Arbeiten\nan Ihren Dokumenten übernehmen, sondern auch allgemein als\ndie neuen Wissensarbeiter\nim Unternehmen fungieren.\nDamit das gelingt, benötigt man im Grunde\ndie richtige Dokumenteninfrastruktur, um\nall diese Dokumente verarbeiten zu können,\ndamit die Mitarbeiter den richtigen\nKontext für ihre Entscheidungen haben.\nOkay, jetzt kommen wir zu der Frage, warum die Texterkennung (\nOCR) von Dokumenten und die Dokumentenverarbeitung so schwierig sind, zum Beispiel\nwarum das Lesen von PDFs so schwer ist.  Ähm, Sie\nwissen ja, dass ein Großteil der weltweiten Daten\nin PDFs gespeichert ist, und das Hauptproblem bei\nPDFs ist, dass das Format nicht wirklich\nfür eine semantische\nInterpretation durch Maschinen ausgelegt ist.  Wenn man sich\ndie interne Struktur einer PDF-Datei ansieht, stellt man fest, dass\nes sich um eine Reihe von Maschinenanweisungen handelt, die beispielsweise dazu dienen,\nZeichen für die Anzeige\nauf einer Seite zu drucken.  Es\nsieht also im Grunde aus wie eine Ansammlung von\nZufallszahlen, die Koordinaten darstellen, plus\nGlyphensymbole, die man dann tatsächlich\nauf die Seite druckt.  und manchmal lassen sich diese\nwieder in Zeichencodes zurückführen.\nDas Postskriptum-Format gibt es übrigens schon seit\nden 1990er Jahren.  Und\nseitdem sich das PDF-Format als Konzept so richtig durchgesetzt hat\n, gab es\nBestrebungen,\ndiese Informationen aus einem PDF wieder in\neine Art digitalisierten Text umzuwandeln.  Das\nProblem ist, dass LLMs offensichtlich nicht in der Lage sind,\ndie native PDF-Binärdatei\nselbstständig zu lesen.  Die Aufgabe eines jeden PDF-\nParsers besteht also darin,\ndieses Format in ein\nsemantisch sauberes, sowohl für Menschen als\nauch für Maschinen lesbares Format umzuwandeln\n.  Wir werden also\ndie Entwicklung verschiedener\nAnsätze nachzeichnen.  Grundsätzlich werde ich aber\neinige Beispiele durchgehen, warum das so\nschwierig ist.  Wenn man sich zum Beispiel eine\nTabelle in einem Dokument ansieht, sagen wir,\ndas hier ist einfach nur so eine Art\nzufällige Tabelle.  Sie wissen ja, dass es sich hier um\nArtikel mit Umsatz handelt, es könnte wie\neine Rechnung sein.  Es könnte sich um eine Art\nSEC-Meldung handeln.  Ähm, als Mensch können Sie\ndies in einem Dokument lesen und es als\nTabelle sehen.  Aber wie Sie wissen,\nist es im Dateiformat selbst im\nGrunde als eine Reihe von Linien,\nRahmen und Werten mit\nKoordinatenpositionen dargestellt.  Das Format selbst nimmt keine\nZuordnung oder\nKennzeichnung des gesamten Ganzen als\nTabelle vor.  Man kann nicht einfach\na priori wissen, dass sich der\nText einer Zelle innerhalb des äußeren Rahmens\nplus der Zeilentrennlinie befindet, ohne\nein wenig Clustering\nund Heritabilitätsanalysen durchzuführen und ein wenig\nMathematik anzuwenden.  Ich denke also, das ist nur ein\nBeispiel.  Wenn man sich\nTabellen in PDFs ansieht, stellt man fest, dass sie oft nur aus\neiner Reihe\nvon Strichen und Zeichenpositionen bestehen.   Die\nLesereihenfolge ist auch eine andere Sache.\nWissen Sie, wenn Sie ein zweispaltiges\nFormat haben, also so ein\nZeitungsformat, wo man\nmehrere Spalten auf einer einzigen Seite haben kann.\nÄhm ja, wissen Sie, als Mensch könnten Sie\ndas auf einer Seite lesen und würden\nwahrscheinlich zuerst die linke Spalte lesen,\ndann die mittlere und dann die rechte.   Wenn\nman sich aber ansieht, wie die Daten in\neinem PDF gespeichert werden, kann die\nReihenfolge der\ngespeicherten Zeichen völlig willkürlich sein.\nWenn man die Koordinaten beispielsweise\nausdruckt, um sie anzuzeigen, wird daraus natürlich\netwas rekonstruiert, das man\nals Mensch lesen kann. Für eine\nMaschine hingegen\nist die Reihenfolge der Anweisungen nicht unbedingt dieselbe wie beim\nLesen\ndes Dokuments.\nDie Kernidee ist also, dass die\nDokumentenverarbeitung ziemlich\nschwierig ist.  Das ist ein Problem, mit dem sich\nviele Wissenschaftler und\nForscher in den\nletzten 20 Jahren auseinandergesetzt haben, und ich denke, es ist\ninsbesondere im Zeitalter der\nKI immer wichtiger geworden, da viele dieser Daten\nin PDFs vorliegen, beispielsweise in\nUnternehmen, die\neine riesige\nWissensdatenbank ihrer Microsoft SharePoint-Daten aufbauen möchten.\nWie konvertiert man das vorhandene Format\nin eine Art\nKlartextdarstellung wie\nMarkdown, die sowohl von\nMenschen als auch von Maschinen gelesen werden kann,\nsodass man sie an Claude Code oder\nOpenClaw weitergeben kann und diese Programme die\ngewünschten Aktionen ausführen können?\nIch denke also, das ist der\nZielzustand.  Wissen Sie, ein Teil der Idee besteht darin,\ndie OCR-Kernschicht wirklich zu innovieren, um\nDokumente in ein Format übersetzen zu können, das\nMaschinen verstehen können.\nUnd so hat man im Allgemeinen\neine Vielzahl\nunterschiedlicher Ansätze verfolgt. Es gab ja schon seit\neinigen Jahrzehnten\nForschung und Arbeit zum Thema\nDokumentenverständnis, also zum\nmaschinellen Lernen, also dazu, wie man diese\nArt von\nKoordinaten in eine Art sauberen\nText umwandeln könnte.  Wenn man sich die Implementierung\neiniger dieser Parser ansieht, wie zum Beispiel\ndie Kern-Engine wie\ntestact oder einen freien Open-\nSource-Parser wie PDF to text oder py pdf, dann\nimplementiert man im Grunde nur eine\nReihe von Huristics.  Man könnte sich\nden Text auf einer Seite ansehen, eine Art\nClustering durchführen, um\nTextabschnitte zusammenzufassen, und dann den\nAbstand zwischen den einzelnen Zeichen\nfür fließende Absätze nutzen. Außerdem\nwürde man OCR-Modelle verwenden, die\nspeziell für das Einlesen von\nBildern in Text entwickelt wurden, und dann einen Weg finden,\nall das miteinander zu kombinieren.\nMan würde also im Grunde den\nText extrahieren, die Tabellen segmentieren und dann\neine Art Heritabilität anwenden, um die einzelnen Teile\nzu einem\ninterpretierbaren Format zusammenzufügen.  Das\nProblem bei jedem heruristischen Ansatz\nist seine offensichtliche Anfälligkeit.  Ähm, das ist\nfest einprogrammiert.  Sobald also das\nDokumentformat von dem abweicht, was das\nSystem verarbeiten kann, dann wird es\nfehlschlagen.\nEs gibt in letzter Zeit einen Trend zu\nBildverarbeitungsmodellen und Pre-Trigger-Modellen.\nEs gibt so kleine,\nfast schon Trainingsmodelle für die\nDokumenten-OCR2, wie Donut und einige\nandere. Ich denke, ein Teil\nder Idee ist, dass man eine Art Dokumentenverteilung hat, ein\nModell trainiert und die Idee ist, dass man es\ndem Modell in einem einzigen Durchgang zuführt\nund es einem die\nrekonstruierte Ausgabe des\nDokuments zurückgibt,\nmit dem Aufkommen von Bildverarbeitungsfunktionen in\ngroßen Sprachmodellen.  Ähm, das begann\nmit GPD4 Vision.  Nun ja,\nBildverarbeitungsfunktionen sind im Grunde in allen\nFrontier-Modellen vorhanden, und\nauch in vielen Open-Source-Modellen.  Sie wissen ja, dass dies\nzu solchen Baselines führt, in die man im\nGrunde genommen beispielsweise eine\nSeite in Opus 4.7 einspeisen kann.  Opus 4.7 macht quasi einen\nScreenshot der gesamten Seite und\nversucht dann, diese als eine Reihe von Tokens zu rekonstruieren,\ndie man lesen kann.\nUnd deshalb denke ich, dass wir, um\nIhnen einen kleinen Eindruck zu vermitteln,\nbeides ein bisschen machen.  Ich denke, es hat\nviele Vorteile, wenn man\nwirklich einfache\nTextseiten ziemlich schnell lesen kann.  Aber\nnatürlich gibt es auch die lange Geschichte von wirklich\nkomplexen Seiten, auf denen alles Mögliche zu finden ist,\nvon sehr komplexen Tabellen über\ndichte Diagramme bis hin zu\nhandgeschriebenen Formularen mit vielen\nKritzeleien.  Es ist hilfreich, einige der\nallgemeinen Fähigkeiten dieser\nBildverarbeitungsmodelle zu nutzen, damit man\nsie tatsächlich in das interpretierbare Textformat übersetzen kann.\nNur ein paar allgemeine Experimente unsererseits\n.  Ähm, wissen Sie, ich denke,\nFrontier-Modelle verfügen zwar über gewisse\nBildverarbeitungsfähigkeiten, aber sie sind nicht\nbesonders gut auf das Verständnis von Dokumenten abgestimmt\n.  Ähm, wissen Sie, da gibt es\nGemini 3.1 Pro, GBD 5.5 und\nOpus 4.7.  An diesem Punkt haben\nwir bei praktisch allen\ndiesen Modellen festgestellt, dass ein verstärktes Denken\nin den Frontier-Modellen, wenn man die\nReasoning-Tokens optimiert, im Allgemeinen\nnicht mit einer erhöhten\nGenauigkeit des visuellen Verständnisses korreliert, da ich denke, dass ein\nGroßteil des Post-Trainings für diese\nModelle auf Codierung, logisches Denken und\nMathematik abzielt und nicht unbedingt auf die\nOptimierung der Fähigkeiten zum visuellen Verständnis.\nIm Allgemeinen ist die Verwendung von Frontier-Modellen\neine gute Grundlage.  Ähm, es ist normalerweise ziemlich\nteuer, wenn man versucht,\nes als eigenständigen OCR-Ansatz einzusetzen.  Wenn\nSie schon einmal in einem Coworking-Space waren – wie viele von Ihnen\nhaben beispielsweise Claude Co-Work genutzt\n?  Okay.  Oder Cloud-Code.  Cloud-\nCode.  Es ist ungefähr zu 90 % okay.  Okay.  Cool.\nIch denke, wenn Sie schon einmal einen der\nnativen Assistenten-Agenten von\nCloud-Co-Work- oder Cloud-Code-Plattformen verwendet haben, dann\nwerden Sie feststellen, dass dieser zunächst eine Art\nfreie und Open-Source-\nTextanalyse des Dokuments durchführt.  Sobald\nes eine Seite identifiziert hat, erstellt es einen Screenshot\nder Seite und speichert diesen dann in sich selbst.\nWenn es sich also um Opus 4.7 handelt, erstellt es einen Screenshot der\nSeite, sobald es gefunden hat, wonach es sucht,\nund verwendet dann das Seitenbild, um\ndie eigentliche\nFrage zu beantworten.  Ich denke, das ist in Ordnung\nfür solche unterstützenden Arbeitslasten, bei denen man mit\neinem Cloud Max-Plan im\nGrunde die\nToken-Nutzung subventioniert, oder,\nEntschuldigung, die API-Nutzer subventionieren die\nToken-Nutzung für einen.  Aber ganz allgemein gilt: Wenn\nSie versuchen, eine\nMillion PDFs in großem Umfang zu verarbeiten und zu analysieren, dann wird das nicht\nfunktionieren.  Das wird einfach viel zu\nteuer.   Es gibt\nviele verschiedene Arten von Daten, die\nman sich ansehen kann.  Ich meine, das Bild könnte etwas\nunscharf sein.  Es gibt da draußen so richtig\nverkommene Tische\n.  Ähm,\nim Finanzbereich gibt es dann all diese Diagramme, zum Beispiel\nLiniendiagramme.  Wenn man sich anschaut,\nwie viele der bestehenden Modelle\ndiese Daten rekonstruieren, kann man sehen, dass\ndie visuelle Verankerung und die Fähigkeit,\nwirklich jedes einzelne\nDetail zu erfassen, selbst bei einigen dieser\nGrenzmodelle, äh, es immer noch\nLücken gibt.  Es ist nicht hundertprozentig\ngenau.\nIch denke, was noch wichtiger ist, insbesondere\nfür das, was Benutzer typischerweise\nals KI-Agenten entwickeln möchten, ist ein gewisses\nMaß an Nachvollziehbarkeit und\nRückverfolgbarkeit zu den Quelldaten.  Ähm,\nund insbesondere aus der\nPerspektive der Benutzererfahrung.  Nehmen wir an, Sie laden beispielsweise\neine Million juristischer Dokumente\noder einfach einen riesigen\nDatenbestand hoch, und die Agenten werten diese Daten\nin einem Datenraum aus und geben Ihnen anschließend eine\nAntwort.  Normalerweise benötigt man\nzumindest eine Art von Zitaten auf Regions- oder Zeilenebene\n.  Deshalb ist ein gutes Layout\nund ein solides Erdungsmodell auch extrem\nwichtig.  Wenn man\nauf einer Seite erkennen kann, ob ein bestimmtes\nElement eine Tabelle ist oder ob es sich um einen\nTextabschnitt handelt, und man tatsächlich\nBegrenzungsrahmen um Textabschnitte zeichnet,\nbedeutet das, dass man, wenn der Agent einem eine Antwort gibt, die bei der\nRecherche oder der Arbeit hilft,\ndirekt auf das Zitat klicken und\nfast direkt zu der\nspezifischen Stelle im Quelldokument zurückverfolgen kann, aus der\nes stammt.\nDies ist also etwas, das nicht automatisch mit\nder VLM-\nAPI funktioniert.  Ähm, aber das ist etwas, was\ntypischerweise erforderlich ist, wenn man versucht, einen\nfunktionierenden Agenten mit den richtigen\nZitaten für eine Reihe von Dokumenten zu erstellen.\nDie andere Komponente, über die ich\nsprechen möchte, ist, dass Benchmarking im Allgemeinen\nfür jedes Modell ziemlich wichtig ist.  Wenn man sich so\nanschaut, wie diese Frontier-\nModelle alle auf Terminal\nBench und Sweet Bench und all das abgestimmt sind\n.  Um v für das Dokumentenverständnis zu\nverstehen, sind die meisten der bestehenden\nBenchmarks in der Regel etwas\nunvollständig.  Ich glaube, es ist tatsächlich teilweise so etwas wie\nein\nlaufendes Projekt.  Ähm, da gibt es Omni Dobbench, das\nmeines Wissens eine beliebte Wahl für viele\nder Anbieter von Frontier-Modellen sowie für\nOpen-Source-Modelle ist.  Es wird langsam etwas\ngesättigt.  Ähm, und im\nGrunde geht es typischerweise um eine Art\nBewertungsmetrik,\ndie die genaue syntaktische Genauigkeit\nIhrer Tabellen misst.  Ähm, und deshalb\nist es oft ein bisschen zu starr für das, was\nAgenten wichtig ist.  Es gibt auch noch OMO\nCRB Bench, das sich typischerweise auf\nwissenschaftliche Arbeiten konzentriert und eher\nbinäre Bewertungsmethoden verwendet.  Also,\nwissen Sie, haben Sie bei einem gegebenen Wert\ntatsächlich die Zelle\nlinks davon nach links oder die\nZelle rechts davon nach\nrechts verschoben?  Und dann ist es im Grunde ein einfacher\nTest, bei dem es nur zwischen Bestehen und Nichtbestehen geht.  Es ist eigentlich gar nicht so schlecht,\naber die Datenverteilung spiegelt noch nicht\nganz die\nArbeitslasten vieler Unternehmensdokumente wider, und die\nbinären Metriken sind oft etwas\nzu grob für ein tieferes\nVerständnis der Dokumente.\nSeitdem wir\nunseren Fokus verstärkt auf dieses\ngesamte Vorhaben gerichtet haben, geht es uns vor allem darum,\ndie Fähigkeiten von Modellen wirklich tiefgründig zu verstehen\nund die\nGrenzen des Dokumentenverständnisses zu erweitern.  Äh,\nwir haben vor Kurzem Parsbench herausgebracht,\neinen umfassenden Dokumenten-\nBenchmark für Unternehmensdokumente.  Es\nenthält über 2.000 von Menschen verifizierte Seiten\naus einer Vielzahl unterschiedlicher Branchen.\nDazu gehören beispielsweise Finanzen,\nVersicherungen und Recht.  Wir versuchen wirklich,\nDokumente aus dem\nöffentlichen Bereich zu finden, die\nBeispiele aus der realen Welt widerspiegeln, und zwar anhand\neiner Vielzahl\nunterschiedlicher Elemente, die den Menschen typischerweise\nwichtig sind.  Dies umfasst lediglich extrem\ndichte Tische.  Äh, dazu gehören Diagramme, Sie\nwissen schon, Liniendiagramme, Balkendiagramme,\nPigraphen.  Dazu gehört die inhaltliche\nTreue, also sicherzustellen, dass Sie\ndas Dokument tatsächlich auf die\nrichtige Weise linearisieren.  Es beinhaltet semantische\nFormatierung.  Oftmals gibt es einfach nur\nseltsame Schriftartfehler oder\nÜbersetzungsprobleme oder so etwas wie z. B.\nDokument C oder Word-Durchstreichungen\n.  Sie möchten also\nsicherstellen, dass der Parser selbst\nfeinste\nstilistische Unterschiede korrekt darstellen kann, und außerdem die\nvisuelle Verankerung gewährleisten, dass\nSie die richtigen Begrenzungsrahmen für\nIhr Dokument haben. Um Ihnen dies zu verdeutlichen, gibt es ein ausführliches\nWhitepaper, das unser Team\nim Archiv veröffentlicht hat. Sie können sich\nparsbench.ai AI ansehen, wenn Sie sich\nselbst ein Bild machen möchten.  Aber ein\nTeil davon ist, dass es sich tatsächlich um einen vollständig\noffenen Benchmark handelt, bei dem wir natürlich nicht nur\nunsere eigenen Sachen testen, sondern auch\nviele der neuesten Modelle und Open-\nSource-Modelle da draußen.  Wenn\nSie also sehen möchten, ob Gemini, GBT oder\nOpus in Bezug auf das\nDokumentenverständnis die Nase vorn hat, insbesondere da sich die Modelle\nverbessern, gibt es eine Art Rangliste,\num diese Dinge zu verfolgen.\nÄhm, also wir haben versucht, so\nunvoreingenommen wie möglich zu sein.  Ähm, weil es eine\noffene Rangliste ist.  Wir akzeptieren grundsätzlich\nalle Beiträge von allen Parsern.  Es\ngibt eine allgemeine Verteilung\nder verschiedenen Lösungen hinsichtlich Genauigkeit und\nKosten.  Vielleicht nur, um Ihnen einen kleinen Einblick\nin das Frontier-Modell im\nSpeziellen zu geben.  Gemini Pro kostet etwa 8\nCent pro Seite.  Es ist also extrem\nteuer.  Äh, das hat kein Opus 4.7,\naber Opus 4.6 sechs hat, wie Sie wissen, eine\nGesamtgenauigkeit von etwa 53%.  Äh,\nbei Tabellen ist er ganz gut, aber bei\nvisuellen Darstellungen oder Diagrammen nicht so.  GBD 5.4 ist,\nnun ja, vielleicht ein bisschen günstiger\n.  Ähm, Gemini\nist eigentlich relativ konkurrenzfähig,\nvor allem wenn man den Denkmodus\nausschaltet, äh, insbesondere die Gemini 3 Flash-\nModelle.\nFalls es euch interessiert,\nwir haben eine Menge Ressourcen dazu zusammengestellt\n.\nAuf Kaggle gibt es einen Leader Award mit einem umarmenden Gesicht.  Ähm, es gibt ein\nArchiv-Whitepaper.  Es gibt auch eine\nWebsite, und wir werden\nauch Erweiterungen des Benchmarks veröffentlichen\nund einfach weitere Daten hinzufügen.  Ähm,\nund es gibt noch viele weitere Aufgaben, die wir\nlösen wollen.  Wir möchten sicherstellen, dass es\ndie gesamte Verbreitung von Unternehmensdokumenten vollständig abdeckt\n.  Wir wollen sicherstellen, dass\nwir die Handschrift messen.  Wir wollen\nsicherstellen, dass wir ähnliche Formulare und\nScans messen.  Ich wollte das nur mal erwähnen,\nals eine der Bemühungen, die\nunser Team meiner Meinung nach unternimmt.   Was\nmich außerdem\nziemlich begeistert, ist dieses Ding\nnamens Light Purse.  Und äh, wir haben\ndas vor etwa einem Monat veröffentlicht, aber\nwissen Sie, im Gegensatz zu unserem kommerziellen Service, mit dem\nwir äh ein bisschen Geld verdienen\n, ähm, ist das hier komplett kostenlos und Open\nSource.  Wenn Sie also\nmit vielen unserer neueren\nOpen-Source-Tools vertraut sind, dann wissen Sie ja, dass wir\nals Open-Source-Projekt mit einem\nsehr breit gefassten Framework begonnen haben.  Ähm, dies\nstellt im Grunde eine Fortsetzung\nunserer Open-Source-Strategie dar, wobei der\nSchwerpunkt aber auf der Bereitstellung der besten\ndokumentenbasierten Werkzeuge für KI-Agenten liegt.  Und\ndeshalb ist es neben der Tatsache, dass es Open\nSource ist, auch sehr schnell.  Es\nkann Text aus Ihren Dokumenten extrahieren\nund verwendet dabei überhaupt keine VLMs\n.  Die Vergleichspunkte sind also im\nGrunde so etwas wie PI PDF, PY PDF,\nPDF zu Text.  Viele dieser kostenlosen Open-Source-\nParser, die typischerweise beim Öffnen von Diensten\nwie CloudCode oder CloudCoWork in\nden Trainingsdaten verwendet werden, versuchen,\ndiese schnellen Parser als ersten\nDurchlauf zu nutzen, bevor ein tiefergehender VLM-\nbasierter Durchlauf erfolgt. Wir wollten daher\netwas entwickeln, das unserer Meinung nach etwas\nbesser abschneidet als diese\nanderen modellfreien Parser. Es muss\nschnell sein. Wir arbeiten derzeit an einer\nRust-basierten Implementierung, die sich\naußerdem mit einem Klick als\nAgenten-Skill mit nativer Unterstützung für OCR\nund Screenshot-Erstellung installieren lässt.  Das\nbedeutet also, dass, wenn Sie\ndies als Agenten-Skill installieren und\nOpenClaw bitten, eine umfassende\nRecherche in einem Datenraum mit\nverschiedenen Dokumententypen durchzuführen, die Sie\nin einem Ordner gespeichert haben,\ndieses Tool in der Lage ist, eine sehr einfache und\nschnelle OCR-Analyse Ihrer Dokumente durchzuführen, sie\nin einem\nlesbaren Format zu rekonstruieren und sie dann zu analysieren\nund\nbei Bedarf eine tiefergehende VLM-basierte Analyse durchzuführen\n.  Ähm, das Video lädt aus irgendeinem Grund\nnicht, sonst zeige ich euch, wie\ndie Ausgaben aussehen.  Ich\nhabe jedoch noch ein anderes Video, bei dem der\nFernsehbildschirm zwar nicht besonders groß ist, das\nIhnen aber im Grunde zeigt, dass wir mit diesem Tool eine Art\nCloud-Code-\nSkill geschaffen haben, der Ihnen ein\nRepository mit Dokumenten zur Verfügung stellt,\nüber die Sie eingehende Recherchen durchführen möchten.  Dadurch wird\nmithilfe von Cloud-Code ein vollständiger HTML-Bericht für Sie generiert\n.  Man geht einfach rein und weiß, dass\nes kostenlos ist, also kann man\nes im Grunde sofort nutzen.  Und es wird ein vollständiger\nBericht mit Zitaten erstellt, und wenn Sie\nauf die Zitate klicken, erhalten Sie\ndie vollständigen zitierten Aussagen mit den\nHervorhebungen im Quelldokument.  So\netwas findet man normalerweise nicht bei so\nnaiven, auf\nRag-basierten Implementierungen, und ehrlich gesagt\nwar ich überrascht, dass\nes das tatsächlich kann.  Es verwendet einige\nder nativen Begrenzungsrahmen von uh\nlight parse, und das Agenten-Harness ist\nintelligent genug, um es dann in\nWort-Level-Zitate und Begrenzungsrahmen umzuwandeln.\nDas ist völlig kostenlos.  Es ist Open\nSource.  Sie können es sich gerne ansehen, wenn Sie\nmöchten. Es ist als eine Art\nerster Überblick für Ihre\nAssistenzagenten gedacht, falls Sie daran interessiert sind, einen Blick darauf zu\nwerfen.\nNatürlich wissen Sie auch, wo die\nGrenzen dieser Methode liegen?  Es verwendet\nkeine Modelle.  Es wird also\neinige Ihrer komplexeren Dokumente nicht lesen können.\nEs wird eine Art Übergabe an OCR durchführen, eine Art\nVLM-basierter Ansatz, aber es ist eigentlich als\nerster Durchgang für\nCloud-Code oder Open Cloud gedacht.\nAuch Simon Willis hat\nletzte Woche darüber berichtet, worüber ich mich persönlich\nsehr freue.  Um\nIhnen einen Eindruck davon zu geben, wie die Ausgabe aussieht:\nWenn Sie beispielsweise ein\nziemlich kompliziertes Format mit mehreren Dokumenten haben, wird dieses einfach als\nTextblock dargestellt.  Wir haben dazu\neinen ganzen Blogbeitrag verfasst, der erklärt, wie es\nfunktioniert.  Stellen Sie sich aber vor, Sie lesen den\nText auf einer Seite.  Wir werden im Grunde\nversuchen, die Darstellung des\nTextes auf der Seite mit einer Reihe von\nTabulatoren und Leerzeichen so nachzubilden, dass er sowohl für\nMenschen als auch für Agenten\ninterpretierbar ist.\nAbgesehen davon, ich glaube, ich habe\ndas schon mal angesprochen, aber ganz\nallgemein gefragt: Wenn man wieder\nin die VLM-basierte Welt zurückkehrt und\nvisuelle Modelle zur Unterstützung des\nDokumentenverständnisses verwendet, welche\nKomponenten benötigt man dann?  Sie benötigen im Grunde genommen\neinige Kernmodelle, um\nverschiedene Arten von Elementen\nauf einer Seite lesen zu können, Tabellen, Diagramme und all das\n.  Und dann möchte man das Ganze im Grunde\nin einer Art Werkzeugkasten zusammenfügen,\nsodass man bestimmte Modelle\nfür bestimmte Aufgaben wie Layoutdiagramme und\nTabellen verwendet, und dann\norchestriert man sozusagen alles zusammen, passt\ndie Modelle selbst an und\nerstellt dann im Grunde eine Art\nEndergebnis für den Benutzer, das\nalle benötigten Metadaten einschließlich\nZitate und Begrenzungsrahmen enthält.   Um\nIhnen einen kurzen Überblick zu geben: Worüber\nwir hauptsächlich gesprochen haben, ist das\nParsen, also die Übersetzung eines Dokuments\nin Markdown.  Das ist im Grunde genommen etwas,\ndas Ihnen eine Art\nDokument oder Darstellung liefert, die\nIhre Agenten intuitiv\nverstehen können.  Da gibt es auch noch\ntieferliegende Ebenen, wie zum Beispiel die Dokumentenextraktion\n.  Wenn Sie also ein\nstrukturiertes Schema haben und beispielsweise\neine Million\nDokumente auf einmal extrahieren und in einem\nstrukturierten JSON-Format ausgeben möchten, das Sie dann in\nSnowflake Databricks usw. importieren können, dann ist das\nauch ein Endpunkt, den wir anbieten. Er stellt im\nGrunde eine zusätzliche Schicht über der\nOCR-Kernfunktion dar.  Sie haben ein Schema, und wir\nhaben einen Agenten, der\ndie Ausgaben\nentsprechend dem von Ihnen\ndefinierten Schema in natürlicher Sprache ausfüllt, ohne dass ein\nTraining erforderlich ist.   Zu\nunseren Kunden gehören unter anderem\nCarlile, die zu unseren\nersten Kunden zählte und uns bei der Durchführung von\nDue-Diligence-Prüfungen\nvon Dokumenten in Datenräumen unterstützte.  Und so geht es im Grunde darum,\nden Prozess des Scannens einer Vielzahl\nvon Dokumenten in einem Datenraum zu automatisieren.  Ähm, und dadurch\nwirklich Zeit für die menschlichen Analysten zu sparen\nund dabei zu helfen, die Finanzdaten\nzusammenzutragen und das Finanzmodell zu erstellen\n.   Ähm,\nSex, wissen Sie, ist ein weiterer\nKunde, und ich glaube, seit\nAnbeginn haben sie eine\nriesige Anzahl spezialisierter Agenten aufgebaut.\nIhr gesamtes Firmenwissen ist in\nMicrosoft SharePoint gespeichert, und so können sie\ndiese Daten extrem\nschnell indexieren, mit LlamaParse analysieren und\ndann in einem\nnachgelagerten Speichersystem speichern. Dadurch können\nihre Endbenutzer, ob\nKundendienst oder interne Teams,\nviel schneller und präzisere Erkenntnisse\naus diesen Daten gewinnen\n.\nWie viel Zeit habe ich?  Ähm, okay, das\nwaren ungefähr 25 Minuten.  Ähm, vielleicht nur kurz ein paar\nAnmerkungen zum allgemeinen makroökonomischen\nMarktgeschehen.  Wissen Sie, ich glaube, ähm, wir haben\nals ein provisorisches Gerüst angefangen.  Ähm, und\nso, wissen Sie, wir haben immer noch einige\nrecht gute Einblicke in\nden allgemeinen Agentenbereich.  Natürlich\nhaben wir unseren Fokus etwas auf\ndie zentrale Dokumenteninfrastruktur gelegt,\ndie in viele\ndieser Agenten integriert ist, aber ich denke, es gibt\neinige interessante Trends, die wir im\nAllgemeinen bei der Entwicklung von Agenten beobachten.  Im Jahr 2023, würde ich sagen,\nbauten die meisten Leute einfach nur so\nsimple Rag-Rechner.  Ähm, ich hatte 2023 einen Kurs bei äh\nAndrew Ang. Es war sehr\nspannend.  Ähm, und es ging im Grunde um\nfortgeschrittene Rag-Techniken, und wir\nhatten einfach eine Menge Zeug im Open\nSource, das den Leuten half,\nfortgeschrittenere Methoden zum Abrufen aus\nihren Dokumenten zu entwickeln.  Im Laufe des Jahres 2024\nbegannen die Menschen, sich für Agenten zu interessieren, und zwar\ninsbesondere für sehr\neinfache Agenten, agentenbasierte Arbeitsabläufe, die\neinige erste Aktionen automatisieren konnten, jedoch mit\nden richtigen Schutzmechanismen und der Einbindung des\nMenschen.  Und dann 2025,\ninsbesondere mit dem Aufstieg vieler\nFähigkeiten von Codierungsagenten,\ndenke ich, dass wir\ndiesen Wandel hin zu im Grunde vollautomatisierten Systemen erleben werden,\ndie von selbst logisch denken, wenn\nman sie auf\nEnglisch anweist, und dann einfach immer\nlängerfristige Aufgaben erledigen.  Und\nich denke, genau das wird uns dahin bringen, dass wir eine\nArbeitsautomatisierung von 50 bis 80 % und mehr erreichen, bei der wir im\nGrunde genommen eine ganze Armee\nvon Mitarbeitern haben, sei es für die Programmierung,\nwas wir ja bereits beobachten, nicht wahr?  Mal ehrlich,\nwie viele von euch\nschreiben heutzutage noch Code von Hand?  Äh, aber\nauch so etwas wie allgemeines Wissen, äh, die\nFähigkeit, eine ganze Armee von\nAgenten auszusenden, die dann einfach Dinge für einen erledigen\n.  Und Sie wissen ja, dass das Modell-Harness im\nGrunde\nalles umfasst, was das Kernmodell umgibt und es\nermöglicht, im Grunde ein Agent zu sein.\nClaude Code ist ein Modell-Harness auf\nBasis von Opus 4.7, und\nOpen Claw ist natürlich auch ein Modell-Harness,\naber die Kernkomponenten sind im\nGrunde MCP-Fähigkeiten, Werkzeuge und\nder eigentliche Agenten-Tech-Loop. Ich\ndenke, für jeden Entwickler, insbesondere für ein\nStartup, werden\ndie allgemeinen Modell-Harnesses immer\nbesser.  Ich\nmeine, viele Leute könnten wahrscheinlich gut damit zurechtkommen,\neinfach Cloud-\nCode einzubinden und\nProgrammierkenntnisse auf Englisch zu besitzen.  Das, was Sie\nbereitstellen und was sozusagen den\nAlpha- oder Burggraben darüber hinaus bildet, ist in Wirklichkeit\ndie Kontext- und Workflow-Ebene.\nDies umfasst also auch die Geschäftslogik Ihrer Organisation\n.  Dies schließt den\nKontext mit ein.  Für uns ist es also\ndokumentenbasierter Kontext.  Ähm, aber man kombiniert\ndas ja auch mit anderen\nKontexten.  ob es sich um strukturierte\nDatenbanken, Websuche oder\netwas anderes handelt.  Und das ist im\nGrunde die Rolle eines jeden\nKI-Ingenieurs heutzutage:\ndie Arbeitsabläufe und den\nKontext zu ermitteln, die man diesen wirklich\nleistungsstarken Agenten-Tools zur Verfügung stellt, um so\nviele Aufgaben wie möglich zu automatisieren, weil diese\nAbstraktion begonnen hat, etwas\nzentralisierter zu werden.\nUnd so denke ich, dass die Art und Weise, wie man\nKontext aufnimmt, natürlich etwas\nausgefeilter geworden ist.\nÄhm, alles von so einfachen Rag-Lösungen\nvor etwa drei Jahren bis hin zu MCP,\nSkills und ganz allgemein dieser\nIdee, einen Agenten in einer Sandbox\nmit einer Menge Dateien zu haben, und man kann eine\nDateisuche darüber durchführen.  Ähm,\nich glaube, auch diese Vorstellung von Orchestrierung hat sich verändert.\nIch denke, es gibt da eine gewisse Kluft\nzwischen der Möglichkeit, einen\ndeterministischen\nRoutine-Workflow zu erstellen, der meiner Meinung nach immer noch sehr\nwertvoll ist, um beispielsweise\nGeschäftsprozesse mit geringer Komplexität zu automatisieren.\nAlles, was sich wiederholen lässt,\nkann man als Workflow\nmit den richtigen Leitplanken und Aufgaben kodifizieren und im\nGrunde wiederholbar ausführen, sodass man\nes auch in großem Umfang für jede neue\nArt von Daten nutzen kann.\nUnd dann wissen Sie natürlich, dass ab 2025, 2026 ein\nzunehmender Anteil\nallgemeiner Aufgaben einfach von automatisierten\nAgenten erledigt wird.  Und das hängt damit zusammen,\nwas ich meine: Anstatt\nCode zu schreiben, um eine Art\nautomatisierten Workflow zu erstellen, schreibt man Englisch.  Ähm,\nSie liefern den richtigen Kontext.\nIhr Ziel ist es im Grunde, auf\nEnglisch zu schreiben und für möglichst viele Aufgaben den richtigen Kontext zu liefern,\ndamit\ndiese allgemeinen Agenten möglichst viele\nAufgaben für Sie lösen können.  Daher bin ich der Meinung, dass wir\nwahrscheinlich eine zunehmende\nVerlagerung hin zum Einsatz von\ngeneralisierten Agenten erleben werden, insbesondere wenn die\nAufgabenhorizonte länger werden.  Sie wissen schon, so die\nZeit, die man braucht, um\nDinge zu erledigen.  Ähm, die Agenten waren in der\nLage, Probleme innerhalb von etwa 30\nMinuten zu lösen.  Jetzt können sie Probleme lösen, die bis zu\nfünf Stunden dauern, und ab diesem\nJahr können sie einfach\nanfangen, Probleme auf eine Art und Weise zu lösen, die unaufhörlich andauert\n.  Ähm, und wissen Sie, es würde mich nicht\nwundern, wenn am\nEnde des Jahres praktisch jeder\neine ganze Armee von Agenten leiten würde, falls\nSie das nicht schon getan haben.",
  "transcript_chars": 35019,
  "ingested_at": "2026-05-22T16:33:31.704511+00:00",
  "source": "channel",
  "yt_meta": {
    "view_count": 55,
    "like_count": 1,
    "channel_id": "UCcIXc5mJsHVYTZR1maL5l9w",
    "categories": [
      "Education"
    ],
    "tags": []
  }
}