Constrained Decoding

Le décodage contraint est une technique d'inférence qui restreint un modèle génératif à des sorties valides pendant qu'il génère chaque jeton. Au lieu de permettre au modèle de choisir parmi l'ensemble de son vocabulaire, le décodeur supprime les choix qui enfreindraient une règle, telle qu'une liste d'étiquettes permises, une expression régulière, une grammaire ou un schéma JSON. Cela rend les réponses des modèles plus faciles et plus sûres à analyser pour les logiciels, en particulier lorsqu'un système d'intelligence artificielle doit renvoyer des données structurées ou sélectionner une action autorisée.

Comment fonctionne le décodage contraint#

Un modèle de langage autorégressif génère une séquence un jeton à la fois. À chaque étape, il attribue des scores appelés logits aux jetons suivants possibles et les convertit normalement en probabilités à l'aide de la fonction softmax. Le décodage contraint insère une étape de filtrage supplémentaire :

1. Suivre la partie de la sortie déjà générée.
2. Déterminer quels jetons suivants restent valides sous la contrainte.
3. Masquer les jetons invalides afin que leur probabilité devienne nulle.
4. Sélectionner ou échantillonner parmi les jetons valides restants.
5. Mettre à jour l'état de la contrainte et recommencer.

L'ensemble valide change de manière dynamique. Après avoir généré {"status": ", par exemple, un schéma peut autoriser uniquement les jetons capables de compléter "approved", "rejected" ou "review". Les moteurs proposant des sorties structurées vLLM peuvent imposer des choix, des expressions régulières, des grammaires et des schémas JSON, tandis que la génération JSON Outlines peut dériver des contraintes à partir de schémas ou de modèles Python typés.

Le décodage par contrainte de graphe décrit des implémentations qui représentent des séquences valides sous forme de chemins dans un graphe ou une machine à états. Chaque jeton généré déplace le décodeur vers un autre état, dont les arêtes sortantes définissent les choix valides suivants. Cette approche est utile pour les grammaires, les relations d'entités et d'autres règles dépendantes de l'état.

Concepts connexes et principales différences#

Le décodage contraint est étroitement lié à plusieurs concepts de l'intelligence artificielle, mais ils ne sont pas interchangeables :

• Sorties structurées : Le résultat souhaité, tel qu'un objet doté de champs requis et de types de données. Le décodage contraint est l'un des mécanismes utilisés pour produire ce résultat. Des services incluant les sorties structurées OpenAI, les sorties structurées Claude et les sorties structurées Gemini exposent des contrôles basés sur des schémas.
• Mode JSON : Garantit généralement une syntaxe JSON valide mais peut ne pas imposer de clés, de types ou de valeurs autorisées particuliers. Le décodage contraint par schéma cible une structure spécifique.
• Appel de fonctions et utilisation d'outils : Définit la manière dont un modèle demande une opération externe. Le décodage contraint peut imposer des noms de fonction et des formes d'arguments valides, mais l'application exécute et autorise toujours l'outil.
• Ingénierie de prompt : Demande au modèle de suivre un format par le biais d'instructions. Elle influence le comportement mais n'élimine pas mécaniquement les jetons invalides.
• Décodage spéculatif : Accélère la génération en proposant et en vérifiant des jetons. Son objectif principal est la vitesse, tandis que le décodage contraint contrôle la validité.

Les systèmes typés peuvent définir des schémas par le biais d'outils tels que Pydantic JSON Schema au lieu d'écrire manuellement chaque règle.

Applications concrètes#

Traitement de documents : Un système de traitement de factures peut extraire vendor, invoice_number, total et currency à partir de documents numérisés. Le décodage contraint garantit que la réponse possède les clés et les types de données attendus avant d'entrer dans un logiciel comptable. Il prévient les charges utiles malformées, bien qu'il ne puisse pas garantir que le total extrait est factuellement correct.

Automatisation de la sécurité guidée par la vision : Un système peut utiliser Ultralytics YOLO26 pour détecter les travailleurs et les équipements de protection, puis envoyer les observations pertinentes à un modèle de langage. Le décodeur peut restreindre la décision du modèle à no_action, manual_review ou send_alert. Dans un flux de travail Ultralytics Platform Agents, les modèles de vision, les conditions, les modèles de langage et les actions peuvent être connectés de sorte que seules les images admissibles passent aux étapes ultérieures.

Exemple de flux de travail pratique#

Les prédictions de vision par ordinateur sont déjà structurées plutôt que générées jeton par jeton. Le flux de travail YOLO Predict mode suivant produit du JSON qui peut devenir une entrée pour une décision de modèle de langage contraint en aval :

from ultralytics import YOLO

# Load the recommended object detection model
model = YOLO("yolo26n.pt")

# Run inference and select the first result
results = model("https://ultralytics.com/images/bus.jpg")
result = results[0]

# Serialize detections for a downstream constrained decoder
json_output = result.to_json()
print(json_output)

Ici, to_json() effectue une sérialisation déterministe, et non un décodage contraint. L'étape contrainte se produirait plus tard si un modèle génératif convertissait ces détections en un rapport ou une action limité par un schéma.

Avantages, limites et meilleures pratiques#

Le décodage contraint réduit les échecs d'analyse, les nouvelles tentatives, les champs inattendus et les arguments d'outils invalides. Cependant, la validité structurelle n'élimine pas les hallucinations LLM : une réponse parfaitement formée peut tout de même contenir des faits incorrects ou une action inappropriée.

Utilise des schémas étroits, des descriptions de champs significatives, des énumérations pour les choix fermés et des champs annulables lorsque les informations peuvent être indisponibles. Valide les règles métier après la génération, gère les refus et les réponses tronquées, et teste le sous-ensemble de schémas pris en charge par chaque fournisseur. En production, mesure également la surcharge de compilation des schémas, la latence de décodage et la précision sémantique plutôt que d'évaluer uniquement la conformité du format.