Une instruction réglée à la main obtient 91 %. Une instruction compilée obtient 99 %.
Orientez mal une question d'approvisionnement et une demande de stock revient avec une réponse de tournées de véhicules. J'ai remplacé l'instruction de classification écrite à la main par une instruction compilée avec DSPy, puis j'ai passé plus de temps sur la mesure que sur la compilation.
Une instruction réglée à la main a obtenu 91 %. Une instruction écrite par un optimiseur a obtenu 99 %. Les deux mesurées sur des requêtes qu’aucune des deux n’avait vues à l’entraînement.
Pourquoi cela compte
La première décision que prend un système d’IA, c’est de reconnaître quel type de question il a reçu. Orientez-la mal, et un responsable de la chaîne d’approvisionnement qui interroge son stock reçoit une réponse de tournées de véhicules. La recommandation a l’air sérieuse. Les chiffres portent sur un autre problème.
Le point de départ habituel est une instruction écrite à la main qui décrit chaque catégorie. Cela fonctionne jusqu’au jour où un utilisateur formule sa demande d’une façon que l’auteur n’avait pas prévue, et chaque échec appelle une rustine de plus.
Il existe une autre voie. Étiquetez assez d’exemples pour définir ce que « correct » veut dire, puis laissez un optimiseur écrire l’instruction contre cette cible.
J’ai cessé de régler l’instruction et j’ai commencé à définir l’évaluation. Huit points sont venus de ce basculement.
Comment cela fonctionne
Le cadre DSPy de Stanford traite les instructions comme des programmes compilés : vous définissez les entrées, les sorties et une métrique de qualité, puis un optimiseur écrit les consignes et choisit les exemples. Programmez, n’écrivez pas d’instruction.
J’ai appliqué cela au classifieur d’intentions d’un copilote ERP LangGraph pour la chaîne d’approvisionnement, qui oriente les demandes vers 10 catégories bornées. J’ai étiqueté 100 requêtes à la main, 10 par catégorie. L’optimiseur a réécrit les consignes et gardé les démonstrations qui obtenaient les meilleurs scores.
La mesure a demandé plus de conception que la compilation. Une seule séparation entraînement-test sur 100 exemples reste trop bruitée pour qu’on s’y fie : un seul exemple retenu déplace le résultat de 5 points. J’ai donc fait une validation croisée à 5 replis, stratifiée par intention, pour que chaque requête soit notée une fois, par un modèle de repli qui ne s’était jamais entraîné dessus. Référence 91,0 %. Version compilée 99,0 %. Soit 8 points de plus, à 4,5 près, avec un gain sur chaque repli.
Cette exactitude coûte des jetons : l’instruction compilée emporte ses consignes apprises et quatre démonstrations dans chaque appel.
Ce qui m’a surpris, c’est l’étiquetage. Décider ce que « correct » signifie pour 100 questions ambiguës a fait sortir des règles que je n’avais jamais écrites. « Trouve-moi une route moins chère pour 500 unités » relève-t-il du routage réseau ou de l’allocation fournisseur ? Cela dépend de qui contrôle le réseau logistique et de qui contrôle les contrats fournisseurs. Cette distinction vivait dans mon intuition jusqu’à ce que l’étiquetage la rende explicite.
Une limite qu’il faut poser : ces 100 étiquettes sont les miennes seules, donc le chiffre vaut pour les requêtes que j’ai anticipées. Les traces de production sont la prochaine campagne d’étiquetage.
