bei einer Funktion, bei der ich 100 unordentliche Compliance-PDFs in strukturierte JSON-Regeln umwandeln musste.
Der Brute-Pressure-Ansatz lag auf der Hand: Geben Sie dem Agenten den Quelltext, erklären Sie die Aufgabe, liefern Sie Beispiele und bitten Sie ihn, die Regeln zu generieren. Da es sich um die am niedrigsten hängende Frucht handelte, probierte ich sie zuerst.
Auf den ersten Blick sah die Ausgabe intestine aus. Der Ausgabe-JSON conflict gültig und entsprach meinen Erwartungen.
Aber als ich die Ergebnisse manuell abtastete, um die Richtigkeit zu überprüfen, traten Risse auf. Einige Regeln waren zu weit gefasst, andere wurden übersehen. Einige Regeln konnten die Nuancen des Originaltextes nicht bewahren. Ich habe versucht, einen anderen Agenten zu verwenden, um die Fehler abzufangen und zu beheben, aber bei einem so großen Korpus conflict es unmöglich, die Ausgabe zuverlässig zu überprüfen.
Das conflict der frustrierende Teil. Die Fehler waren nicht offensichtlich. Diese Implementierung conflict viel zu fragil, um sie skalieren zu können.
Obwohl ich die genauen Implementierungsdetails nicht mitteilen kann, kann ich Ihnen die architektonischen Lektionen mitteilen, die ich gelernt habe, und wie ich sie schließlich implementiert habe. Hoffentlich sind diese Erkenntnisse hilfreich, wenn Sie KI-Systeme aufbauen, die skalierbar, zuverlässig bleiben und mit unübersichtlichen Daten umgehen müssen. Und wenn Sie bessere Möglichkeiten haben, Dinge zu erledigen, Nehmen Sie Kontakt zum Chat auf!
Okay, lasst uns loslegen.
Das Downside
Die 100 PDFs, mit denen ich gearbeitet habe, waren bereits analysiert und in Blöcke aufgeteilt, bevor sie mich erreichten. Aber der Rohinhalt conflict immer noch chaotisch. Es gab Aufzählungspunkte, Tabellen, OCR-Artefakte, übersetzte Abschnitte, halbstrukturierte Überschriften, Fußzeilen, Kopfzeilen, inkonsistente Formatierungen und dokumentspezifische Besonderheiten.
Ich habe mich für den Einsatz eines Agenten entschieden, weil die Entscheidung, worauf es ankommt, semantisches Urteilsvermögen erfordert. Die Dokumente folgten keinem einheitlichen Muster, sodass die Relevanz nicht allein durch einfache Regeln bestimmt werden konnte.
Man musste den umgebenden Kontext verstehen. All dies conflict nicht schwierig, wenn man es mit einem kleinen Datenblock durchführte. Die Herausforderung bestand darin, dies im großen Maßstab zuverlässig durchzuführen.
Diese Regeln wurden dann von einem anderen nachgelagerten System verarbeitet und deterministisch ausgewertet.
Was letztendlich funktionierte
Nach ein paar Experimenten wurde mir klar, dass die größte Verbesserung nicht durch eine bessere Eingabeaufforderung, ein neues Device, einen MCP-Server oder eine ausgefeiltere Agentenumgebung zustande kam.
Es kam daher, dass sich die Type des Issues veränderte.
Anstatt zu versuchen, den Agenten schlauer zu machen, habe ich den Job des Agenten kleiner gemacht.
Die erste Änderung bestand darin, die Quelldaten im Voraus vorzubereiten. Anstatt den Agenten zu bitten, eine Datenbank abzufragen, Datensätze abzurufen, zu entscheiden, ob sie die richtigen Eingaben hatte, und dann die Extraktion durchzuführen, habe ich ihr einen kontrollierteren Ausgangspunkt gegeben.
In meinem Fall bedeutete das, die relevanten Rohdaten vorübergehend lokal zu speichern.
Dies ist möglicherweise nicht immer praktikabel. Das zugrunde liegende Prinzip besteht jedoch darin, die Abrufunsicherheit zu verringern, mit der der Agent umgehen muss. Wenn die Aufgabe des Agenten darin besteht, über Inhalte nachzudenken, sollten Sie ihn nicht auch dafür verantwortlich machen, herauszufinden, ob er den richtigen Inhalt gefunden hat.
Eine andere Möglichkeit wäre, die Abfrage im Voraus vorzubereiten.
Ich habe außerdem ein Skript verwendet, um unnötige Metadaten und Felder zu entfernen, bevor ich den Rohinhalt an den Agenten übergeben habe. Weniger irrelevanter Kontext bedeutete weniger Ablenkungen, weniger Chancen für den Agenten, sich an die falschen Particulars zu erinnern, und eine insgesamt sauberere Argumentationsaufgabe.
Die wichtigste Änderung betraf jedoch die Arbeitseinheit.
Anstatt alles auf einmal zu verarbeiten, habe ich die Dinge iterativ gemacht und ein Dokument nach dem anderen verarbeitet.
Dadurch wurde jeder Job kleiner, einfacher zu prüfen, einfacher zu wiederholen und einfacher zu prüfen. Ich habe fünf Subagenten eingerichtet, um Dokumente parallel zu verarbeiten, wobei jeder Agent seinen Fortschritt in einer Datei protokolliert.
Wenn ein Dokument fehlschlug, konnte ich nur dieses Dokument erneut versuchen. Wenn bei einer Ausgabe Formatierungsprobleme auftraten, konnte ich diesen speziellen Fall beheben, ohne den gesamten Stapel erneut ausführen zu müssen. Wenn die Pipeline auf halbem Weg anhielt, bedeutete der zwischengespeicherte Fortschritt, dass sie am letzten erfolgreichen Prüfpunkt fortgesetzt werden konnte.
Hier wurde auch die Trennung der Verantwortlichkeiten deutlicher.
Der Agent kümmerte sich um die semantische Arbeit: den Inhalt verstehen, die relevanten Teile identifizieren und die JSON-Ausgabe schreiben.
Der umgebende Code kümmerte sich um die mechanischen Teile: Parallelisierung von Jobs, Durchsetzung des Schemas, Generierung von IDs, Schreiben von Dateien, Zwischenspeichern des Fortschritts, Validieren von Referenzen und Überprüfen, ob die Ausgabe auf die Originalquelle zurückgeführt werden konnte.
Ich hatte auch einen Orchestrator, der den Fortschritt des Drehbuchs überwachte.
Die Ausgabe überprüfbar machen
Eine nützliche Entwurfsentscheidung conflict das Hinzufügen von Referenz-IDs zu jeder generierten Regel. Dies bedeutete, dass jedes Ausgabeelement auf eine bestimmte Quelle verwies.
Dies erleichterte die Prüfung der Ausgabe. Anstatt zu fragen: „Sieht diese generierte Regel richtig aus?“, könnte ich präzisere Fragen stellen, wie zum Beispiel: Existiert der referenzierte Quellblock? Ist der zitierte Quelltext tatsächlich in diesem Abschnitt vorhanden?
Ich könnte auch einen anderen Agenten damit beauftragen, selektiv größere und komplexere Dokumente zu prüfen, um sicherzustellen, dass wichtige Nuancen erhalten bleiben.
Darüber hinaus habe ich eine vereinfachte Model von evals erstellt. Ich habe einen kleinen Stapel Rohdokumente durch den Workflow laufen lassen und die Ergebnisse manuell auf Abdeckung und Genauigkeit überprüft. Ein vollständiger Golden-Datensatz conflict für den Umfang dieser Aufgabe nicht praktikabel, aber ich brauchte dennoch eine Möglichkeit, mir selbst zu beweisen, dass der Workflow funktionierte.
Mein Ziel conflict es nicht, einen perfekten Benchmark zu erstellen, sondern das System so überprüfbar zu machen, dass ich die Ausgaben überprüfen, Fehler erkennen und zu einem höheren Genauigkeitsbalken iterieren konnte.
Wenn Sie Ideen haben, wie ich das besser hätte machen können, lassen Sie es mich wissen!
Mein größter Imbiss
Das funktionierende Muster bestand darin, das LLM nicht mehr als Gesamtsystem zu betrachten.
Das System wurde zuverlässiger, nicht weil der Agent perfekt wurde, sondern weil der Workflow die Nachverfolgung, Validierung und Wiederherstellung seiner Ausgaben erleichterte.
Zufälligerweise baute ich dies kurz vor der Teilnahme an der ersten AI Engineer-Konferenz in Singapur, die vom 15. bis 17. Mai 2026 stattfand.
Am letzten Tag teilte JJ Geewax, Direktor für angewandte KI bei Google DeepMind, einen Rahmen, der das auf den Punkt brachte, was ich auf die harte Tour gelernt hatte: Wir müssen aufhören, LLMs wie riesige Problemlöser einzusetzen.
Das hat bei mir Anklang gefunden, weil es so leicht ist, in diese Falle zu tappen. Es ist einfach, dem Modell einfach die Daten, das Schema, die Geschäftsregeln, Randfälle und die Verantwortung zu übertragen, sich selbst zu überprüfen. Dann sind Sie frustriert, wenn das Ergebnis inkonsistent ist.
Für zuverlässige Produktionssysteme ist jedoch in der Regel ein Hybrid das bessere Muster. Lassen Sie den Agenten die Teile verwalten, die eine semantische Beurteilung erfordern, und überlassen Sie den Code die Teile, die Struktur, Validierung und Kontrolle erfordern.
Ich werde weitere Überlegungen von AI Engineer Singapore und den Workshops, an denen ich teilgenommen habe, teilen. Der YouTube-Ausschnitt von JJs Rede hier.
Das ist alles von mir. Ich hoffe, das hat geholfen und wir sehen uns im nächsten Artikel 🙂