Le WordPress d'aujourd'hui, décodé pour les développeurs

IA & MCP

Sorties JSON structurées d’un LLM pour peupler un catalogue Algolia

Snippet pour contraindre un modèle à renvoyer un schéma JSON directement exploitable par un pipeline d'indexation Algolia, sans validation manuelle systématique.

Par Clément Hadrot • 25 juillet 2024 • 4 min de lecture • Aucun commentaire
Sorties JSON structurées d'un LLM pour peupler un catalogue Algolia

{"type": "object", "required": ["titre", "categorie", "attributs"]} : ce fragment de schéma JSON conditionne tout un pipeline d’indexation Algolia construit pour peupler automatiquement un catalogue de composants électroniques à partir de fiches techniques fournisseurs peu structurées. Sans contrainte de sortie stricte, le LLM produisait un texte libre difficile à parser de façon fiable ; avec un schéma structuré, le taux de conformité dès le premier appel a atteint 98,4 %. Le coût de ces appels, sujet distinct, n’est pas traité ici.

Ce snippet décrit la mise en place de sorties structurées pour ce cas précis, du prompt de contrainte jusqu’à la validation du schéma avant indexation.

Le problème du texte libre

Avant la mise en place de ce schéma, le prompt demandait simplement au modèle de « structurer les informations de cette fiche technique en JSON ». Le résultat variait d’un appel à l’autre : parfois un tableau de propriétés, parfois un objet imbriqué différemment, parfois du texte explicatif ajouté avant ou après le JSON lui-même, rendant le parsing automatique peu fiable sans traitement d’exception coûteux à maintenir.

Le passage à un mode de sortie structurée, disponible auprès de plusieurs fournisseurs de LLM depuis peu, a permis d’imposer un schéma JSON strict directement au niveau de l’appel API, plutôt que de compter sur la seule formulation du prompt pour obtenir un format cohérent.

Le schéma imposé à l’appel

L'essentiel à retenir : Un schéma JSON strict évite le texte libre difficile à parser ; La validation de schéma reste indispensable même sans relecture manuelle ; Le pipeline rejette automatiquement toute sortie non conforme
$schema_composant = array(
    'type' => 'object',
    'properties' => array(
        'titre'      => array( 'type' => 'string' ),
        'categorie'  => array(
            'type' => 'string',
            'enum' => array( 'resistance', 'condensateur', 'circuit_integre', 'connecteur' ),
        ),
        'attributs'  => array(
            'type' => 'array',
            'items' => array(
                'type' => 'object',
                'properties' => array(
                    'nom'    => array( 'type' => 'string' ),
                    'valeur' => array( 'type' => 'string' ),
                ),
                'required' => array( 'nom', 'valeur' ),
            ),
        ),
    ),
    'required' => array( 'titre', 'categorie', 'attributs' ),
);

Ce schéma, transmis à chaque appel via le paramètre dédié aux sorties structurées de l’API, garantit que le modèle renvoie exclusivement un objet conforme à cette forme, sans texte d’accompagnement ni variation de structure d’un appel à l’autre.

La validation avant indexation

Malgré un taux de conformité élevé, le pipeline conserve une étape de validation de schéma côté serveur avant tout envoi à Algolia, plutôt que de faire confiance aveuglément à la garantie du fournisseur de LLM :

function valider_et_indexer( $json_genere, $schema ) {
    $validateur = new JsonSchema\Validator();
    $donnees = json_decode( $json_genere );

    $validateur->validate( $donnees, $schema );

    if ( ! $validateur->isValid() ) {
        error_log( 'Sortie LLM non conforme, rejetee avant indexation.' );
        return false;
    }

    return $index_algolia->saveObject( (array) $donnees );
}

Sur le lot de test de 500 fiches techniques traitées, 8 sorties ont été rejetées par cette validation malgré la contrainte de schéma imposée à l’appel, confirmant qu’aucune garantie de sortie structurée ne dispense totalement d’une vérification indépendante avant indexation.

Les limites de l’approche

  • Le schéma garantit la forme des données, jamais leur exactitude factuelle : une valeur d’attribut peut être bien formée mais techniquement incorrecte.
  • Les sorties structurées ne sont pas disponibles avec la même maturité chez tous les fournisseurs de LLM à cette date.
  • Un schéma trop rigide peut forcer le modèle à inventer une valeur plutôt que d’indiquer une absence d’information, un risque à surveiller sur les champs non obligatoires.

Une sortie JSON parfaitement conforme au schéma reste une sortie de LLM comme une autre : la validation de forme protège le pipeline, elle ne protège jamais contre une erreur de contenu bien formée.

En résumé

Contraindre un LLM à une sortie JSON structurée a considérablement fiabilisé ce pipeline d’indexation Algolia, réduisant à presque rien les échecs de parsing qui rendaient l’automatisation précédente fragile. Cette fiabilité de forme ne remplace cependant jamais une validation de schéma indépendante avant indexation, ni une vigilance sur l’exactitude du contenu généré à l’intérieur de cette structure.

Partager :

À propos de l'auteur

Clément Hadrot

Développeur WordPress, passionné par Elementor, le FSE et l’automatisation par IA.

Voir tous ses articles

Dans la même veine

À lire aussi