Technical Tutorials

La création d'applications robustes avec les grands modèles de langage (LLM) implique souvent un défi majeur : extraire des données propres et exploitables à partir de réponses en langage naturel. Bien que les LLM soient excellents pour générer du texte, ils peuvent être imprévisibles lorsqu'un formatage strict est requis. C'est là que le mode JSON devient un outil indispensable pour les développeurs. En contraignant le modèle à ne produire que du JSON valide, vous pouvez intégrer les LLM de manière transparente dans les services backend, les API et les pipelines de données sans logique d'analyse fragile.

Qu'est-ce que le mode JSON ?

Le mode JSON est une fonctionnalité prise en charge par de nombreuses API LLM modernes (telles que celles d'OpenAI, d'Anthropic et de Google) qui oblige le modèle à générer une réponse strictement valide en JSON. Contrairement à la dépendance à des prompts système qui ne font que demandeur une sortie JSON, le mode JSON est une contrainte stricte. Le modèle est techniquement empêché d'inclure des blocs de code markdown, du texte explicatif ou tout autre caractère non-JSON dans sa réponse finale.

Ce déterminisme est crucial pour les environnements de production. Si votre application tente d'exécuter JSON.parse() sur une réponse contenant des espaces supplémentaires ou un texte d'introduction comme « Voici les données que vous avez demandées : », le processus échouera. Le mode JSON élimine entièrement cette classe d'erreurs.

Comment activer le mode JSON

L'activation du mode JSON est généralement simple via les paramètres de l'API. Voici un exemple pratique utilisant Python avec la bibliothèque OpenAI.

import openai
import json

client = openai.OpenAI()

completion = client.chat.completions.create(
    model="gpt-4o",
    response_format={"type": "json_object"},
    messages=[
        {
            "role": "system",
            "content": "You are a helpful assistant that extracts structured data."
        },
        {
            "role": "user",
            "content": "Extract the name, age, and occupation from this text: 'My name is John Doe, I am 30 years old, and I work as a Software Engineer.'"
        }
    ]
)

print(json.dumps(json.loads(completion.choices[0].message.content), indent=2))

Dans cet exemple, le paramètre response_format est défini sur {"type": "json_object"}. Cette instruction indique à l'API de s'assurer que la sortie est un objet JSON valide.

Définition du schéma avec des prompts système

Bien que le mode JSON garantisse la validité, il ne garantit pas automatiquement que la structure corresponde aux besoins de votre application. Vous devez définir explicitement les clés attendues et les types de valeurs dans votre prompt système.

Meilleures pratiques pour la définition du schéma

Soyez explicite : Énumérez tous les champs requis.
Précisez les types : Clarifiez si un champ est une chaîne de caractères, un entier, un booléen ou un tableau.
Fournissez des exemples : Incluez une sortie JSON d'exemple dans le prompt système pour guider le modèle.

system_prompt = """
You are a data extraction engine. Extract user information from the provided text.
Return a JSON object with the following structure:
{
    "name": "string",
    "age": "integer",
    "occupation": "string"
}
If a field is missing, use null.
"""

Gestion de la validation et des cas limites

Même avec le mode JSON, vous devriez toujours implémenter une validation côté client en utilisant des bibliothèques comme Pydantic (Python) ou Zod (JavaScript). Cela agit comme un filet de sécurité contre les cas limites où le modèle pourrait générer du JSON structurellement valide mais sémantiquement incorrect (par exemple, un âge de 200 ans ou une clé inexistante).

from pydantic import BaseModel, ValidationError

class UserData(BaseModel):
    name: str
    age: int
    occupation: str

try:
    user_data = UserData(**json.loads(completion.choices[0].message.content))
    print("Validation passed:", user_data)
except ValidationError as e:
    print("Validation failed:", e)

Erreurs courantes et solutions

1. Le piège du « Null »

Les LLM hésitent parfois à utiliser null lorsque des données sont manquantes, renvoyant à la place des chaînes vides "" ou la chaîne `"null"`. Soyez explicite dans votre prompt : « Utilisez null JSON si l'information n'est pas disponible. »

2. Complexité imbriquée

À mesure que les structures JSON deviennent profondément imbriquées, l'adhésion du modèle à la précision du schéma peut diminuer. Pour les schémas très complexes, envisagez de diviser la tâche en plusieurs appels LLM ou d'utiliser des outils de sortie structurée spécialisés qui prennent en charge directement les contraintes de schéma JSON.

Conclusion

Le mode JSON n'est pas seulement une fonctionnalité de commodité ; c'est un pilier de l'intégration fiable des LLM. En combinant le mode JSON avec des définitions de schéma explicites dans les prompts système et une validation rigoureuse côté client, vous pouvez construire des applications robustes qui exploitent l'intelligence des LLM sans sacrifier l'intégrité des données. Que vous construisiez un bot de support client IA, un pipeline d'extraction de données ou un moteur de recherche sémantique, la sortie structurée est la clé pour mettre à l'échelle efficacement vos fonctionnalités IA.