Manuel des sorties structurées pour les LLM

• Guide pratique pour les développeurs visant à résoudre l’instabilité qui survient lorsque les grands modèles de langage (LLM) génèrent des formats structurés comme JSON, XML ou du code
• En raison de leur nature probabiliste, les sorties peuvent se dégrader de manière non déterministe ; le guide traite donc des techniques de structuration déterministe pour y remédier
• Il couvre l’ensemble du processus, notamment le fonctionnement interne, le choix des outils et des techniques, le déploiement, la montée en charge et l’optimisation des coûts, ainsi que l’amélioration de la qualité des sorties
• Il rassemble les informations les plus récentes sur un domaine de la génération structurée qui évolue rapidement, sous la forme d’un document continuellement mis à jour
• Une ressource de référence indispensable pour les développeurs qui utilisent les LLM de manière programmatique pour l’extraction de données, la génération de code et l’appel d’outils

---

Pourquoi des sorties LLM structurées sont nécessaires

• Les LLM produisent la plupart du temps des sorties syntaxiquement valides en JSON, XML, code, etc., mais leur nature probabiliste peut entraîner des erreurs de format ou des résultats incomplets
  • Cela pose problème dans les processus automatisés comme l’extraction de données, la génération de code ou l’appel d’outils
• Pour résoudre ces problèmes, une méthode de sortie structurée déterministe est nécessaire
• Le manuel couvre l’ensemble des outils et techniques afin d’aider les développeurs à mettre en œuvre des sorties structurées de façon fiable

Principaux contenus du manuel

• Il inclut des sujets orientés pratique comme le fonctionnement interne, les meilleurs outils et techniques, les critères de choix des outils, les méthodes de construction, déploiement et montée en charge d’un système, l’optimisation de la latence et des coûts, ainsi que l’amélioration de la qualité des sorties
• Chaque section est structurée selon une approche pas à pas directement applicable par les développeurs
• Les recherches récentes et les outils open source liés aux sorties structurées sont rassemblés et organisés dans un seul document

Actualité et mises à jour

• Les technologies de génération structurée évoluent très rapidement, ce qui rend les ressources existantes vite dépassées
• Ce manuel est maintenu comme un document vivant (living document) régulièrement mis à jour
• Les développeurs peuvent accéder aux informations les plus récentes en un seul endroit, sans avoir à parcourir de multiples articles de recherche, blogs et dépôts GitHub

Comment l’utiliser

• Il peut être lu intégralement dans l’ordre ou utilisé comme ouvrage de référence permettant d’aller directement au sujet nécessaire
• Conçu avant tout pour les développeurs en production, il permet une consultation rapide pour résoudre un problème précis

Créateurs et communauté

• Le manuel a été créé par l’équipe Nanonets
  • Elle maintient le modèle Nanonets-OCR et la bibliothèque open source de traitement documentaire docstrange
• Une newsletter pour la communauté des développeurs LLM fournit toutes les deux semaines les dernières analyses, avancées, ainsi que des outils et techniques utiles

[GN⁺]

Avis Hacker News

• C’est vraiment un guide magnifique. J’ai particulièrement aimé les animations de transition entre onglets sur plusieurs pages
  Je pensais déjà assez bien comprendre la generation contrainte par grammaire (j’ai même contribué à l’implémentation des grammaires dans llama.cpp), mais j’ai quand même tiré de nouveaux enseignements de ce guide
  Je pense que les sorties structurées sont l’une des fonctionnalités les plus sous-estimées des moteurs LLM. Grâce aux contraintes grammaticales, on peut utiliser un LLM de façon fiable comme composant d’un pipeline plus large, par exemple un agent avec tool-calling
  La sortie peut être sémantiquement fausse, mais elle est toujours correcte du point de vue grammatical. C’est particulièrement important quand on utilise des modèles locaux
  Par exemple, comme dans l’exemple de filtre anti-spam sur Raspberry Pi de Jart, si on applique une grammaire au modèle TinyLlama pour qu’il ne produise que "yes" ou "no", cela fonctionne de manière fiable même sur du petit matériel

  • Je me demande ce qui se passe quand le modèle veut produire autre chose, et s’il vaut mieux gérer ça à l’intérieur de llamafile ou dans un wrapper externe. J’aimerais aussi savoir comment configurer les retries ou le bornage JSON

• C’est vraiment un excellent guide. J’ai travaillé sur la génération structurée pendant mon doctorat, donc je partage quelques ressources pour les personnes intéressées
  Côté bibliothèques, il y a Outlines, Guidance, XGrammar
  Côté articles, je recommande Efficient Guided Generation for Large Language Models, Automata-based constraints for language model decoding, Pitfalls, Subtleties, and Techniques in Automata-Based Subword-Level Constrained Generation
  Et côté billets de blog, LLM Decoding with Regex Constraints et Coalescence: making LLM inference 5x faster

  • Je ne comprends pas très bien quel est exactement le rôle d’Outlines dans la stack. Est-ce comparable aux API de sortie structurée proposées par les grands fournisseurs de modèles, ou à des projets comme BAML ?
  • Sur l’article DFybOGeGDS, la partie sur le canonical filtering semble ne pas prendre en compte la prétokenisation. J’aimerais savoir s’il existe des travaux sur la génération canonique qui intègrent réellement les regex de prétokenisation
  • Tu disais “d’autres références”, mais on dirait surtout que tu as relisté les bibliothèques déjà présentes dans le guide
  • C’est une vraie mine d’or. Les contraintes basées sur les automates sont un sujet passionnant

• Guide très bien organisé. Si vous voulez en savoir plus sur les optimisations de Guidance & llguidance, vous pouvez consulter notre court article

  • Je suis l’un des auteurs de l’article. J’ai été particulièrement impressionné par l’implémentation du slicing pour le dense token mask

• Ce guide couvre bien les deux approches que les gens utilisent le plus souvent. Cela dit, la génération contrainte peut s’écarter de la distribution native du LLM
  Par exemple, quand un LLM génère un long objet structuré, il peut préférer des motifs comme « … », et la génération contrainte va le corriger de force avec un guillemet fermant ou autre, ce qui peut au final produire un mauvais résultat
  À l’inverse, le resampling est plus robuste, puisqu’il recommence jusqu’à obtenir un résultat valide
  Je pense aussi qu’au lieu d’allonger le contexte en y ajoutant des erreurs de schéma, il vaut mieux simplement réessayer, à la fois pour la qualité et pour le coût

  • Une approche hybride est aussi possible : tenter d’abord une génération non contrainte (unconstrained), puis n’appliquer la génération contrainte (constrained) qu’en cas d’échec

• Je me demande si les modèles SoTA (Opus, Gemini, etc.) ont encore besoin d’une enforcement du schéma de sortie
  Aujourd’hui, les modèles font presque plus d’erreurs de syntaxe en JSON ou en génération de code, donc j’aimerais savoir s’ils continuent malgré tout à faire une validation de schéma en interne
  Je comprends qu’on ait besoin de génération structurée pour les petits modèles

  • Plus le schéma est complexe, plus cela reste utile, car les LLM sont faibles en comptage. Même si les modèles se sont améliorés, leur nature probabiliste les empêche d’être parfaits
  • Même les modèles récents ajoutent encore parfois des tokens inutiles comme json\n, donc il reste plus sûr de spécifier un schéma de réponse JSON

• Forcer des sorties structurées entraîne une baisse de performances. Dans certains cas, cela peut être 2 à 3 fois plus lent. Il faut juger selon le contexte si ce coût est acceptable

• C’est un guide vraiment impressionnant. J’aurais aimé avoir ce genre de ressource il y a un an. Je vais absolument le partager autour de moi

• Bon guide. J’ai particulièrement aimé le diagramme de masked decoding

  • Je suis l’un des auteurs. Je vais vérifier le problème de lien. Comme tous les fournisseurs de modèles commerciaux ajoutent des fonctions de sortie structurée, nous continuerons à mettre le guide à jour

• Je me demande s’il existe un format de sortie plus fiable et plus facile à parser que JSON. YAML et TOML ont chacun leurs défauts, mais ils pourraient être meilleurs en nombre de tokens ou en coût

  • J’utilise le format TOON pour ça
  • De la même manière que les humains trouvent JSON pénible à écrire, il peut être préférable pour un LLM de produire le résultat sous forme de code de type TypeScript. En revanche, côté sécurité, il faut du sandboxing et des limites de ressources
  • Nous développons un pipeline de transformation de contenu basé sur Markdown + YAML front matter. L’outillage JSON n’est pas idéal, mais la validation n’est pas difficile
  • J’impose un schéma XML avec des regex, puis je décode avec un parseur XML. Pour les blocs de code en particulier, je les entoure de CDATA pour donner plus de liberté. La sortie structurée par regex de l’API OpenAI est plus adaptée au code que JSON
  • Le mieux est de faire une évaluation soi-même. Dans mes expériences, XML a toujours donné de meilleurs résultats que JSON sur les tâches out-of-distribution

• Je suis curieux de connaître la stack technique de la page de documentation / cookbook. Ça ne ressemble ni à MkDocs ni à GitBook ; j’aimerais savoir ce qui a été utilisé

  • Ils ont utilisé Docusaurus