Comment obtenir du JSON d'un modèle ouvert ?

Dans une requête chat completions, passez `response_format` avec `type: "json_schema"`, un `name`, votre JSON Schema et `strict: true`. La réponse dans `message.content` est alors un JSON conforme au schéma. Pour une garantie plus souple, utilisez `type: "json_object"` et décrivez les champs dans le prompt.

Est-ce compatible avec les sorties structurées d'OpenAI ?

Oui. `response_format` avec `json_schema` et `json_object` suit l'API chat completions d'OpenAI, et `text.format` suit l'API Responses. Les aides des SDK qui construisent le schéma à partir d'un modèle Pydantic ou Zod, comme `client.chat.completions.parse` en Python, fonctionnent avec inference.eu.

Quelle différence entre le mode JSON et les sorties structurées ?

Le mode JSON garantit un JSON valide, sans préciser les clés qu'il contient. Les sorties structurées avec `json_schema` garantissent le respect de votre schéma : champs obligatoires présents, types corrects, aucune propriété en trop. Utilisez-les dès que vous connaissez la forme attendue.

Quelles fonctionnalités de JSON Schema sont prises en charge ?

Objets, tableaux, chaînes, nombres, entiers, booléens, `null`, `enum`, `required`, objets imbriqués, `additionalProperties: false` et descriptions fonctionnent. Des constructions très complexes peuvent être refusées avec une erreur 400 qui explique le problème. Des schémas plats et explicites donnent les résultats les plus fiables.

Puis-je utiliser des modèles Pydantic ?

Oui. En Python, définissez un modèle Pydantic et passez-le comme `response_format` à `client.chat.completions.parse`. Le SDK le convertit en JSON Schema, l'envoie et renvoie un objet analysé dans `message.parsed`. Zod fait de même en TypeScript avec l'aide du SDK.

Pourquoi mon JSON est-il tronqué ?

Le modèle a atteint `max_tokens` avant d'avoir fini, et `finish_reason` vaut `length`. Augmentez `max_tokens`, raccourcissez les champs texte longs du schéma ou extrayez moins d'éléments par requête. Les modèles de raisonnement ont besoin de marge, car leur réflexion compte aussi dans la limite.

Peut-on combiner sorties structurées et appel d'outils ?

Oui. Les outils peuvent utiliser `strict: true` dans leur définition pour que leurs arguments suivent le schéma des paramètres, et la réponse finale peut utiliser `response_format`. Un montage fréquent laisse le modèle appeler d'abord des outils de recherche, puis rendre un résumé structuré.

Les sorties structurées rendent-elles la réponse exacte ?

Non. Elles garantissent la forme de la réponse, pas la véracité de chaque valeur. Un modèle peut mal lire un document ou deviner une valeur. Autorisez `null` pour les données manquantes, validez les champs importants dans le code et relisez un échantillon de résultats à la main.

Sorties structurées et JSON Schema · compatible OpenAI, UE

extract_invoice.py

import json, os
from openai import OpenAI

client = OpenAI(base_url="https://api.inference.eu/v1", api_key=os.environ["INFERENCE_EU_API_KEY"])

schema = {
    "type": "object",
    "properties": {
        "supplier": {"type": "string"},
        "invoice_number": {"type": "string"},
        "issue_date": {"type": "string", "description": "ISO 8601 date"},
        "currency": {"type": "string", "enum": ["EUR", "GBP", "CHF", "PLN", "SEK"]},
        "total": {"type": "number"},
        "vat_id": {"type": ["string", "null"]},
    },
    "required": ["supplier", "invoice_number", "issue_date", "currency", "total", "vat_id"],
    "additionalProperties": False,
}

reply = client.chat.completions.create(
    model="gpt-oss-120b",
    messages=[
        {"role": "system", "content": "Extract invoice fields. Use null when a field is missing."},
        {"role": "user", "content": open("invoice.md").read()},
    ],
    response_format={
        "type": "json_schema",
        "json_schema": {"name": "invoice", "schema": schema, "strict": True},
    },
)
invoice = json.loads(reply.choices[0].message.content)

Comment fonctionnent les sorties structurées

Ajoutez response_format avec type: "json_schema" et un objet json_schema contenant un name, votre schema en JSON Schema et strict: true. Pendant la génération, l'API n'autorise que les tokens qui gardent la sortie valide au regard du schéma. Le résultat dans message.content est une chaîne JSON que vous analysez directement.

C'est plus fiable que de réclamer du JSON dans le prompt. Le modèle ne peut ni glisser une phrase avant l'accolade ouvrante, ni omettre un champ obligatoire, ni inventer une propriété non définie. Vous décrivez toujours la tâche dans le prompt : le schéma fixe la forme, le prompt le contenu.

Mode JSON et conception du schéma

response_format: {"type": "json_object"} est l'option plus souple, appelée mode JSON. La sortie est un JSON valide garanti, mais sans structure imposée : citez donc les champs attendus dans le prompt. Préférez json_schema dès que vous connaissez la forme.

Gardez des schémas simples et explicites. Listez chaque propriété dans required et réglez additionalProperties sur false, comme l'attend le mode strict. Représentez les valeurs facultatives par un type qui accepte null, comme vat_id dans l'exemple, pour que le modèle puisse signaler une absence au lieu de deviner. Utilisez enum pour les catégories fixes et ajoutez une description aux champs dont le nom ne suffit pas.

Un pipeline d'extraction éprouvé

Un schéma courant transforme des documents en données. Convertissez chaque PDF en Markdown avec l'outil de conversion de documents, envoyez le texte avec un court prompt système et votre schéma, puis analysez le résultat. Validez l'objet obtenu avec le même schéma dans votre code, puis vérifiez les règles métier que le schéma ne peut exprimer, comme la cohérence des totaux.

Pour des milliers de documents, regroupez les mêmes requêtes dans un traitement par lots. Prévoyez un champ de confiance ou une courte chaîne notes si les relecteurs doivent comprendre un choix. Avec l'API Responses, le même schéma se place dans text.format au lieu de response_format.

Erreurs et cas particuliers

Les schémas très volumineux ou très imbriqués, et certains mots-clés inhabituels comme des expressions pattern complexes ou des oneOf aux branches qui se recoupent, peuvent être refusés avec une erreur 400 qui désigne la partie non prise en charge. Scindez ou simplifiez ces schémas.

Le schéma garantit le format, pas l'exactitude. Un modèle peut écrire une mauvaise date dans un champ de date valide : vérifiez les valeurs importantes. Si la génération s'arrête à max_tokens, le JSON est tronqué et ne s'analyse pas ; contrôlez finish_reason et augmentez la limite. Les modèles de raisonnement réfléchissent avant d'écrire le JSON, prévoyez de la place pour les deux. Les refus sont renvoyés en texte.

Sorties structurées : un JSON conforme à votre schéma

Comment fonctionnent les sorties structurées

Mode JSON et conception du schéma

Un pipeline d'extraction éprouvé

Erreurs et cas particuliers

Structured outputs : questions fréquentes

Pages liées

Faites passer vos charges IA sur une infrastructure européenne