Guide · IA & agents
Guide DSPy 3.3 : construire un programme évaluable
Une méthode de prise en main de DSPy 3.3.x centrée sur les signatures, les métriques, les jeux de cas et la validation progressive, sans confondre expérimentation et garantie.
Pourquoi parler de programme évaluable
DSPy propose de décrire une tâche par une signature, de composer des modules et de mesurer leurs sorties au lieu de traiter un prompt isolé comme une unité immuable. L’intérêt pratique n’est pas de promettre qu’un optimiseur trouvera toujours une meilleure solution. Il est de rendre visibles les entrées, les sorties, les exemples, la métrique et le budget de validation.
La série 3.3 mérite une lecture versionnée. La release 3.3.0 présente Flex et ReActV2 comme des fonctionnalités expérimentales. La release 3.3.1 ajoute notamment des changements autour de PythonInterpreter, de l’isolation et de la compatibilité MCP. Une préversion 3.4.0 existe déjà dans le dépôt consulté ; « DSPy 3.3 » ne doit donc pas être présenté comme la dernière version globale.
Le modèle mental : signature, programme, métrique
Commencez par trois contrats séparés :
- La signature décrit ce qui entre et ce qui doit sortir. Elle doit être assez précise pour qu’un test puisse repérer un champ manquant ou une réponse hors format.
- Le programme assemble les étapes nécessaires : récupération, raisonnement, appel d’outil ou synthèse. Chaque étape doit avoir une responsabilité identifiable et un coût observable.
- La métrique transforme une sortie en décision de test. Elle peut combiner exactitude, format, présence d’une preuve ou jugement humain, mais son résultat dépend toujours du corpus et des règles choisis.
Cette séparation évite de corriger un mauvais dataset en modifiant le prompt, ou de déclarer une amélioration parce qu’une seule réponse paraît plus convaincante.
Construire un premier banc de cas
Réunissez un petit ensemble lisible avant toute optimisation : cas nominal, formulation ambiguë, entrée vide ou incomplète, information contradictoire, refus attendu et sortie nécessitant une preuve. Gardez une partition de validation séparée des exemples utilisés pour ajuster le programme.
Pour chaque cas, consignez l’entrée, la sortie attendue ou les critères acceptables, la version du modèle, la version de DSPy, la configuration des outils et le budget d’appels. Un score sans ces métadonnées est difficile à reproduire et encore plus difficile à comparer.
Tester les fonctionnalités expérimentales
Flex et ReActV2 sont présentés comme expérimentaux dans la release 3.3.0. Isolez donc leur activation derrière un scénario de comparaison. Mesurez au minimum : réussite de la tâche, respect du schéma, nombre d’appels, latence, erreurs d’outils et comportement sur les refus. Conservez un chemin de repli explicite si une API expérimentale change ou si une étape produit une sortie inexploitable.
Pour une intégration MCP, vérifiez la frontière de confiance comme pour n’importe quel outil : serveur et version, opérations de lecture et d’écriture, domaines accessibles, secrets, journaux et procédure de révocation. La mention de compatibilité dans une release ne remplace pas cet audit local.
Interpréteur et isolation
Les changements de la 3.3.1 autour de PythonInterpreter doivent être lus comme un renforcement du composant, pas comme une garantie d’exécution sûre dans tous les environnements. Exécutez les expériences dans un environnement jetable, sans secrets de production, avec des limites de temps, de mémoire et de réseau adaptées à votre runner. Vérifiez ensuite les fichiers produits et les appels sortants au lieu de vous fier au seul statut de réussite.
Critères d’acceptation et régression
Avant de retenir une variante, définissez des seuils et des régressions bloquantes : sortie non conforme, citation absente, action d’écriture non autorisée, boucle d’outil, coût maximal dépassé ou erreur silencieuse. Comparez la nouvelle variante au programme de référence sur le même jeu de validation. Une moyenne meilleure peut cacher une dégradation sur un cas critique ; publiez les résultats par catégorie et gardez les exemples d’échec.
Sources et limites
Sources officielles consultées le 22 septembre 2026 : release DSPy 3.3.0, release DSPy 3.3.1, README du dépôt DSPy et licence MIT. Les fonctionnalités expérimentales, la compatibilité MCP et le comportement d’un interpréteur dépendent de la version, du modèle, du runner et de la configuration. Ce guide ne promet ni score universel, ni isolation parfaite, ni compatibilité durable entre versions.