Une application attend souvent un objet, pas un paragraphe. Les sorties structurées permettent de demander un schéma et de valider la réponse. Elles améliorent la fiabilité du format, mais ne garantissent ni la vérité des valeurs ni leur autorisation métier.
Privilégier les capacités natives
Lorsque le fournisseur propose un schéma JSON ou un appel d’outil contraint, utilisez cette capacité via l’interface structurée du modèle. Elle est généralement plus robuste qu’une instruction demandant « réponds en JSON ». Définissez types, champs obligatoires, descriptions, énumérations et contraintes aussi précisément que nécessaire.
Le rôle des parsers
Un Output Parser transforme une sortie en type applicatif et signale les violations. Il reste utile pour des modèles ou formats non natifs et pour une validation supplémentaire. Évitez les regex fragiles sur un JSON libre. Conservez l’erreur brute dans une trace protégée et retournez au client un message contrôlé.
Réparer sans masquer les erreurs
Une nouvelle tentative peut fournir au modèle le schéma et l’erreur de validation, avec une limite stricte. Ne bouclez pas indéfiniment. Pour une action sensible, n’exécutez jamais un objet partiellement valide ou corrigé silencieusement : demandez confirmation ou passez en revue humaine.
Tester le contrat
Ajoutez champs manquants, types incorrects, valeurs hors enum, texte autour du JSON, très grands tableaux et caractères Unicode. Versionnez le schéma comme une API. Lors d’un changement, prévoyez compatibilité ou migration pour les objets persistés.
FAQ
JSON valide signifie-t-il réponse correcte ?
Non. Seule la structure est validée ; les faits nécessitent sources et règles métier.
Faut-il encore un parser avec un schéma natif ?
Oui pour convertir et appliquer les validations propres à l’application.
Peut-on réessayer automatiquement ?
Oui, avec une limite et seulement si l’opération n’a pas déjà produit un effet externe.
Parser Pydantic dans une chaîne LCEL
~~~python from pydantic import BaseModel, Field from langchain_core.prompts import ChatPromptTemplate from langchain_openai import ChatOpenAI
class Incident(BaseModel): service: str severity: int = Field(ge=1, le=5) action: str
prompt = ChatPromptTemplate.from_messages([ ("system", "Analyse l’incident sans inventer de détail."), ("human", "{description}"), ]) model = ChatOpenAI(model="gpt-4.1-mini") chain = prompt | model.with_structured_output(Incident)
incident = chain.invoke({ "description": "L’API renvoie 503 depuis 14 h." }) print(incident.model_dump()) ~~~
Préférez la sortie structurée native du fournisseur lorsqu’elle existe. Un parser textuel repose sur la bonne volonté du modèle et nécessite davantage de réparations. Encadrez l’appel par une gestion des erreurs de validation, limitez les tentatives et transmettez au modèle uniquement un résumé expurgé de l’échec.