Handbuch für strukturierte LLM-Ausgaben

• Praxisleitfaden für Entwickler, der die Instabilität beheben soll, die auftritt, wenn Large Language Models (LLMs) strukturierte Formate wie JSON, XML oder Code erzeugen
• Behandelt deterministische Techniken für strukturierte Ausgaben, um zu kompensieren, dass Ergebnisse aufgrund ihrer probabilistischen Eigenschaften nicht deterministisch beschädigt sein können
• Umfasst den gesamten Prozess, darunter interne Funktionsweise, Auswahl von Tools und Techniken, Deployment, Skalierung und Kostenoptimierung sowie Verbesserung der Ausgabequalität
• Stellt die neuesten Informationen im sich schnell wandelnden Bereich der strukturierten Generierung in Form eines fortlaufend aktualisierten Dokuments gebündelt bereit
• Unverzichtbare Referenz für Entwickler, die LLMs programmatisch für Datenextraktion, Codegenerierung und Tool-Aufrufe einsetzen

---

Warum strukturierte LLM-Ausgaben nötig sind

• LLMs erzeugen meist syntaktisch gültige Ausgaben wie JSON, XML oder Code, doch aufgrund ihrer probabilistischen Eigenschaften können Formatfehler oder unvollständige Ergebnisse auftreten
  • Das verursacht Probleme in automatisierten Prozessen wie Datenextraktion, Codegenerierung oder Tool-Aufrufen
• Um diese Probleme zu lösen, sind deterministische Verfahren für strukturierte Ausgaben erforderlich
• Das Handbuch behandelt Tools und Techniken im gesamten Spektrum, damit Entwickler strukturierte Ausgaben zuverlässig implementieren können

Die wichtigsten Inhalte des Handbuchs

• Enthält praxisorientierte Themen wie interne Funktionsweise, optimale Tools und Techniken, Kriterien für die Tool-Auswahl, Methoden zum Aufbau, Deployment und zur Skalierung von Systemen, Optimierung von Latenz und Kosten sowie Verbesserung der Ausgabequalität
• Jeder Abschnitt ist als schrittweiser Ansatz, den Entwickler direkt anwenden können, aufgebaut
• Führt aktuelle Forschung und Open-Source-Tools zu strukturierten Ausgaben in einem einzigen Dokument zusammen

Aktualität und Updates

• Da sich Techniken für strukturierte Generierung extrem schnell weiterentwickeln, sind bestehende Materialien schnell veraltet
• Dieses Handbuch wird als regelmäßig aktualisiertes Living Document gepflegt
• Entwickler können an einem Ort auf aktuelle Informationen zugreifen, statt zahlreiche Papers, Blogs und GitHub-Repositories durchsuchen zu müssen

Einsatzmöglichkeiten

• Kann vollständig der Reihe nach gelesen oder als Nachschlagewerk genutzt werden, um benötigte Themen sofort zu finden
• Auf praktische Entwicklerbedürfnisse ausgerichtet, sodass es bei der Lösung konkreter Probleme schnell referenziert werden kann

Urheber und Community

• Das Handbuch wurde vom Nanonets-Team erstellt
  • Sie betreuen das Nanonets-OCR-Modell und die Open-Source-Bibliothek zur Dokumentverarbeitung docstrange
• Über den Newsletter für die LLM-Entwickler-Community werden im Zwei-Wochen-Rhythmus aktuelle Insights, Durchbrüche sowie nützliche Tools und Techniken bereitgestellt

[GN⁺]

Hacker-News-Kommentare

• Wirklich ein wunderschöner Leitfaden. Besonders gut gefallen haben mir die Tab-Wechsel-Animationen über mehrere Seiten hinweg
  Ich dachte, ich hätte grammar-constrained generation ziemlich gut verstanden (ich habe auch ein paar Beiträge zur Grammar-Implementierung in llama.cpp geleistet), aber trotzdem habe ich aus diesem Leitfaden neue Einsichten gewonnen
  Strukturierte Ausgaben sind meiner Meinung nach eine der am stärksten unterschätzten Funktionen von LLM-Engines. Dank Grammar-Constraints kann man LLMs zuverlässig als Teil größerer Pipelines verwenden, etwa als tool-calling agent
  Die Ausgabe kann semantisch falsch sein, ist aber grammatikalisch immer korrekt. Das ist besonders wichtig, wenn man lokale Modelle verwendet
  Zum Beispiel funktioniert es selbst auf kleiner Hardware stabil, wenn man wie in Jarts Raspberry-Pi-basiertem Spamfilter-Beispiel auf das TinyLlama-Modell eine Grammar anwendet, die nur "yes" oder "no" ausgeben darf

  • Ich frage mich, was passiert, wenn das Modell etwas anderes ausgeben will, und ob man das besser innerhalb von llamafile oder in einem externen Wrapper behandelt. Ich würde auch gern wissen, wie man Retry-Konfigurationen oder JSON-Bereichsbegrenzungen umsetzt

• Wirklich ein hervorragender Leitfaden. Ich habe während meiner Promotion zu structured generation geforscht und teile für Interessierte ein paar Materialien
  Als Bibliotheken gibt es Outlines, Guidance und XGrammar
  Bei den Papers empfehle ich Efficient Guided Generation for Large Language Models, Automata-based constraints for language model decoding und Pitfalls, Subtleties, and Techniques in Automata-Based Subword-Level Constrained Generation
  Als Blogposts gibt es LLM Decoding with Regex Constraints und Coalescence: making LLM inference 5x faster

  • Ich verstehe nicht ganz, welche Rolle Outlines genau im Stack spielt. Ist es vergleichbar mit den structured output APIs, die große Modellanbieter bereitstellen, oder eher mit Projekten wie BAML?
  • Beim Paper DFybOGeGDS scheint der Teil zum canonical filtering keine Pretokenization zu berücksichtigen. Ich würde gern wissen, ob es Forschung zu canonical generation gibt, die Pretokenization-Regex tatsächlich einbezieht
  • Es hieß zwar „andere Referenzen“, aber es wirkt so, als würde einfach noch einmal die Liste der Bibliotheken wiederholt, die im Leitfaden ohnehin schon stehen
  • Das ist wirklich eine Schatzkammer. Automata-basierte Constraints sind ein spannendes Thema

• Ein gut aufbereiteter Leitfaden. Wenn man mehr über Guidance- & llguidance-Optimierungen erfahren möchte, lohnt sich unser kurzes Paper

  • Ich bin einer der Autoren des Papers. Besonders die Slicing-Implementierung für dense token masks fand ich beeindruckend

• Dieser Leitfaden behandelt die zwei Methoden, die die meisten Leute hauptsächlich verwenden, sehr gut. Allerdings kann constrained generation von der ursprünglichen Verteilung des LLM abweichen
  Wenn ein LLM zum Beispiel lange strukturierte Objekte erzeugt, bevorzugt es oft Muster wie „…“, und constrained generation kann das durch erzwungene schließende Anführungszeichen oder Ähnliches korrigieren und dadurch sogar schlechtere Ergebnisse produzieren
  Resampling hingegen wiederholt den Vorgang, bis ein gültiges Ergebnis entsteht, und ist dadurch stabiler
  Außerdem halte ich es qualitativ und kostenseitig für besser, einfach erneut zu versuchen, statt Schemafehler immer weiter in den Kontext zu schreiben und ihn dadurch zu verlängern

  • Ein hybrider Ansatz ist auch möglich: zuerst unbeschränkte Generierung versuchen und nur bei Fehlschlag constrained generation anwenden

• Ich frage mich, ob SoTA-Modelle wie Opus oder Gemini weiterhin output schema enforcement brauchen
  Heutige Modelle machen bei JSON oder Codegenerierung kaum noch Syntaxfehler, daher würde mich interessieren, ob intern trotzdem noch Schema-Validierung verwendet wird
  Dass strukturierte Generierung für kleine Modelle nötig ist, verstehe ich

  • Je komplexer das Schema ist, desto nützlicher bleibt das, weil LLMs bei Zählaufgaben schwach sind. Auch wenn die Modelle besser geworden sind, sind sie wegen ihrer probabilistischen Natur nicht perfekt
  • Selbst aktuelle Modelle hängen gelegentlich unnötige Tokens wie json\n an, daher ist es weiterhin sicherer, ein JSON-Antwortschema vorzugeben

• Das Erzwingen strukturierter Ausgaben führt zu einem Leistungsverlust. Je nach Fall kann es zwei- bis dreimal langsamer werden. Man muss je nach Situation abwägen, ob diese Kosten akzeptabel sind

• Ein wirklich erstaunlicher Leitfaden. Ich wünschte, es hätte vor einem Jahr schon so ein Material gegeben. Ich werde es auf jeden Fall mit Leuten in meinem Umfeld teilen

• Ein guter Leitfaden. Besonders das Diagramm zum masked decoding gefällt mir

  • Ich bin einer der Autoren. Ich schaue mir das Link-Problem an. Da kommerzielle Modellanbieter alle structured output-Funktionen hinzufügen, werden wir den Leitfaden weiter aktualisieren

• Ich frage mich, ob es ein Ausgabeformat gibt, das zuverlässiger und leichter zu parsen ist als JSON. YAML und TOML haben jeweils ihre Nachteile, könnten aber bei Tokenzahl oder Kosten günstiger sein

  • Dafür verwende ich das TOON-Format
  • So wie Menschen es lästig finden, JSON zu schreiben, könnte es für LLMs besser sein, Ergebnisse in einer codeartigen Form wie TypeScript zu erzeugen. Aus Sicherheitsgründen braucht man dann aber Sandboxing und Ressourcenlimits
  • Wir entwickeln derzeit eine Content-Transformation-Pipeline auf Basis von Markdown + YAML-Front-Matter. Das JSON-Tooling ist zwar schwach, aber die Validierung ist nicht schwer
  • Ich erzwinge direkt per Regex ein XML-Schema und dekodiere dann mit einem XML-Parser. Gerade Codeblöcke umschließe ich mit CDATA, um mehr Freiheit zu erlauben. Das regex-basierte structured output der OpenAI API eignet sich für Code besser als JSON
  • Am besten führt man selbst eine Evaluation durch. In meinen Experimenten hat XML bei Out-of-Distribution-Aufgaben durchgehend besser abgeschnitten als JSON

• Mich interessiert der Tech-Stack hinter den Dokumentations-/Cookbook-Seiten. Es sieht weder nach MkDocs noch nach GitBook aus; ich würde gern wissen, womit es gebaut wurde

  • Es wurde Docusaurus verwendet