Guide

Statut éditorial : En attente de relecture

Output Parsers et sorties structurées avec LangChain

Transformer les réponses d’un modèle en données fiables avec StrOutputParser, Pydantic et les sorties structurées modernes de LangChain.

Classification du contenu

Types

  • Intelligence artificielle

Technologies

Niveau
Intermédiaire
Prochaine vérification
10 novembre 2026

Une réponse de modèle est souvent un message, pas directement une valeur métier. Les parsers transforment cette réponse, tandis que les sorties structurées demandent au modèle ou au fournisseur de respecter un schéma. Dans LangChain 1.x, il faut distinguer le simple texte, la structure native du modèle et la structure finale d’un agent.

Extraire du texte avec StrOutputParser

Pour un pipeline rédactionnel, StrOutputParser récupère le contenu textuel du message.

from langchain_core.output_parsers import StrOutputParser

chain = prompt | model | StrOutputParser()
texte = chain.invoke({"sujet": "RAG"})

Cette solution convient lorsqu’un humain consomme la réponse. Elle n’est pas suffisante si un programme attend des champs précis.

Valider une structure avec Pydantic

Pour des données métier, définissez un schéma et utilisez la sortie structurée du modèle.

from pydantic import BaseModel, Field

class Technologie(BaseModel):
    nom: str = Field(description="Nom canonique")
    categorie: str
    cas_usage: list[str]

model_structure = model.with_structured_output(Technologie)
resultat = model_structure.invoke("Décris LangChain")
print(resultat.nom)

Pydantic valide les types et les contraintes. Selon le fournisseur, LangChain peut s’appuyer sur un schéma JSON natif ou sur le tool calling. Consultez l’intégration du modèle pour connaître les méthodes disponibles.

Sortie structurée d’un agent

Avec create_agent, passez un type à response_format. LangChain choisit une stratégie compatible et place le résultat validé dans structured_response. Cette approche évite de demander au modèle de « répondre en JSON » puis d’extraire le premier bloc ressemblant à un objet.

Gérer les erreurs sans les masquer

Un schéma peut échouer parce qu’un champ manque, qu’un type est incorrect ou que le modèle produit plusieurs réponses structurées. Journalisez la cause, limitez le nombre de reprises et définissez un comportement de repli. Ne remplacez pas silencieusement une valeur invalide par une valeur plausible : cela rend les erreurs difficiles à détecter.

Choisir la bonne stratégie

Utilisez StrOutputParser pour du texte destiné à être affiché. Utilisez with_structured_output pour un appel de modèle qui doit produire un objet. Utilisez response_format pour la réponse finale d’un agent. Conservez un parser personnalisé seulement si votre format ne peut pas être exprimé par un schéma ou si vous devez traiter un protocole historique.

À retenir

Questions fréquentes

Demander « réponds en JSON » suffit-il ?

Non. Cela peut produire du JSON invalide ou conforme syntaxiquement mais incorrect par rapport au métier. Un schéma et une validation sont plus fiables.

Faut-il conserver la réponse brute ?

Oui pour le diagnostic, dans le respect des règles de confidentialité. Certaines intégrations permettent de retourner à la fois la valeur analysée et le message brut.

Contenus liés

Sources utilisées