Format de sortie structuré

Quand tu veux parser la réponse d'un LLM dans un programme, demander un format structuré (JSON, XML, YAML) est indispensable.

1. Pourquoi imposer un format ?

• Automatisation : tu peux parser la sortie sans regex bricolée
• Consistance : toutes les réponses ont la même structure
• Robustesse : facilite la validation
• Intégration : alimente une API, une base, un tableau de bord

2. Demander du JSON

Méthode 1 — Spécifier le schéma :

Extrais les infos de l'email et réponds en JSON avec ce format exact :
{
  "expediteur": string,
  "objet": string,
  "urgence": "haute" | "moyenne" | "basse",
  "actions_requises": [string]
}

Méthode 2 — Donner un exemple :

Format attendu :
{
  "expediteur": "jean@example.com",
  "urgence": "haute",
  "actions_requises": ["répondre avant 18h", "confirmer la réunion"]
}

3. Pièges classiques

• Le modèle ajoute du texte autour du JSON → spécifie « pas d'explication, uniquement le JSON ».
• Il génère un JSON invalide (virgule en trop, guillemets manquants) → valide côté code et redemande si erreur.
• Il invente des champs en plus → liste explicitement les champs autorisés.

4. Modes "structurés" des LLMs modernes

Claude, GPT-4, Gemini supportent un mode où tu fournis un schéma JSON et le modèle garantit une sortie valide :

• OpenAI : response_format = { type: "json_schema", schema: ... }
• Anthropic : tool_use avec input_schema
• Local : grammaires (llama.cpp, vLLM)

À utiliser dès que possible : plus fiable que de demander en texte libre.

5. Autres formats utiles

Markdown — pour de la présentation (titres, listes, gras).

YAML — plus lisible que JSON, bien pour de la config.

XML / tags — pratique pour Claude qui aime structurer avec des balises :

<resume>...</resume>
<actions>...</actions>

6. À retenir

• Spécifier la structure attendue clairement
• Donner un exemple quand c'est complexe
• Valider le format côté code
• Préférer les modes natifs structurés des APIs