Technical Tutorials

Dans les premiers jours des grands modèles de langage (LLM), l'interaction avec l'IA était principalement conversationnelle. Vous posiez une question et le modèle fournissait une réponse textuelle. Bien que puissant pour le brainstorming ou l'écriture créative, cette approche non structurée montre ses limites dans les environnements de production. Lors de la création d'applications nécessitant une extraction de données précise, des intégrations API ou des mises à jour de base de données, l'aléatoire est un passif, et non une fonctionnalité.

C'est là que les Sorties Structurées deviennent critiques. En contraignant le modèle à renvoyer des données dans un format spécifique — généralement du JSON — les développeurs peuvent construire des workflows robustes et déterministes. Dans cet article, nous explorerons comment imposer une structure à l'aide de schémas JSON, pourquoi cela est crucial pour l'évolutivité, et comment mettre cela en œuvre efficacement.

Le passage du texte libre à l'interaction pilotée par schéma

Traditionnellement, l'extraction de données à partir des LLM nécessitait des étapes de post-traitement. Vous pouviez demander au modèle de décrire le profil d'un utilisateur, puis utiliser des expressions régulières ou la manipulation de chaînes pour extraire le nom, l'e-mail et l'âge. Cette méthode est fragile. Si le modèle varie légèrement sa sortie (par exemple, en utilisant « Âge : » au lieu de « L'âge est : »), votre analyseur échoue.

Les sorties structurées résolvent ce problème en définissant la forme attendue de la réponse avant même que le modèle ne la génère. Considérez cela comme une signature de fonction fortement typée en programmation. Au lieu d'un type de retour générique string, vous définissez un objet avec des champs et des types spécifiques. La plupart des fournisseurs de LLM modernes prennent désormais en charge l'application native des schémas JSON, ce qui signifie que le modèle est mathématiquement contraint de respecter la structure que vous fournissez.

Mise en œuvre des contraintes de schéma JSON

Pour tirer parti des sorties structurées, vous devez définir un schéma JSON qui décrit la sortie souhaitée. Ce schéma agit comme un contrat entre votre application et le modèle d'IA. Voici un exemple pratique de la manière de définir un schéma pour un système d'analyse des tickets de support client.


{
  "type": "object",
  "properties": {
    "sentiment": {
      "type": "string",
      "enum": ["positive", "neutral", "negative"]
    },
    "priority_score": {
      "type": "integer",
      "minimum": 1,
      "maximum": 10
    },
    "summary": {
      "type": "string",
      "maxLength": 280
    },
    "tags": {
      "type": "array",
      "items": {
        "type": "string"
      }
    }
  },
  "required": ["sentiment", "priority_score", "summary", "tags"],
  "additionalProperties": false
}

Remarquez les définitions strictes. Nous utilisons enum pour le sentiment afin d'empêcher le modèle de renvoyer « bon », « sympathique » ou « positif ». Nous définissons des contraintes minimum et maximum pour le score de priorité afin d'assurer l'intégrité des données. La directive additionalProperties: false est cruciale ; elle indique au modèle de ne pas inclure de champs supplémentaires non définis dans le schéma, gardant ainsi la réponse propre et prévisible.

Mise en œuvre pratique dans le code

Lors de l'intégration de cela dans votre application, l'appel API change légèrement. Vous transmettez le schéma en tant que paramètre aux côtés de votre prompt. Ci-dessous se trouve un exemple de pseudo-code illustrant à quoi cela ressemble dans une implémentation SDK typique.


import anthropic

client = anthropic.Anthropic()

message = client.messages.create(
    model="claude-3-sonnet-20240229",
    max_tokens=1024,
    messages=[
        {"role": "user", "content": "Analysez ce ticket : 'Mon internet est coupé depuis 3 jours et je suis furieux.'"}
    ],
    # Transmettez le schéma directement à l'API
    response_format={
        "type": "json_schema",
        "json_schema": {
            "name": "ticket_analysis",
            "schema": { ... # Insérez le schéma ci-dessus ... }
        }
    }
)

# La sortie est garantie d'être un JSON valide correspondant au schéma
parsed_response = json.loads(message.content[0].text)
print(parsed_response['priority_score'])

En imposant cette structure au niveau de l'API, vous éliminez le besoin de boucles complexes de gestion des erreurs. Si le modèle ne se conforme pas, l'API génère une erreur de validation, permettant à votre application de gérer l'exception de manière élégante plutôt que de planter lors du traitement en aval.

Conclusion

Les sorties structurées ne sont plus un luxe ; elles sont une nécessité pour tout développeur sérieux quant à l'intégration de l'IA dans des applications de production. En s'éloignant du texte libre et en adoptant des interactions pilotées par schéma, vous gagnez en fiabilité, en facilité de débogage et en intégration transparente avec les systèmes backend. À mesure que l'écosystème évolue, nous verrons probablement des contraintes de type encore plus sophistiquées et des sorties structurées multimodales, comblant davantage le fossé entre l'IA conversationnelle et les paradigmes traditionnels de l'ingénierie logicielle.