SPEAR: Code-Augmented Agentic Prompt Optimization

## SPEAR : quand l'optimiseur de prompts s'écrit lui-même du code pour comprendre ses erreurs

### Ce que fait réellement SPEAR

L'optimisation automatique de prompts (APE) repose sur une boucle simple : évaluer un prompt, générer une critique, proposer une réécriture. GEPA et TextGrad, les deux références du domaine, traitent cette boucle comme un pipeline fixe où l'optimiseur ne dispose que de sa fenêtre de contexte pour diagnostiquer les échecs. SPEAR rompt avec ce modèle en portant le paradigme CodeAct (Wang et al., 2024) dans l'espace APE : l'agent dispose de quatre outils — `evaluate`, `python`, `set_prompt`, `finish` — et décide lui-même de l'ordre et de la fréquence d'utilisation.

L'outil distinctif est le sandbox Python. L'agent écrit et exécute du code arbitraire sur le DataFrame d'évaluation courant : matrices de confusion, clustering d'erreurs, métriques par sous-groupe. Ce n'est pas un module pré-câblé ; c'est du code que l'agent *auteur* à chaque itération selon ce qu'il observe. Deux garde-fous transforment cet agent à horizon long en optimiseur monotone : un auto-rollback si la métrique principale régresse, et un plancher optionnel sur une métrique de garde.

### Les chiffres qui justifient le score de signal

Sur les 13 tâches industrielles LLM-as-judge (trois suites : recrutement, mémoire conversationnelle, raffinement de requêtes), SPEAR gagne sur chaque tâche sur la métrique primaire : - **Sélection d'outils** : κ 0,857 vs 0,359 (GEPA) — un écart de +0,498κ sur une tâche à 5 classes - **Filtrage de pertinence** : F1-macro 0,815 vs 0,763 - **Dimension d'extraction la plus difficile** : κ 0,254 vs 0,218 (gain modeste mais sur la tâche la plus résistante)

Sur BBH-7, l'écart est encore plus marqué : accuracy moyenne 0,938 pour SPEAR contre 0,628 pour GEPA et 0,484 pour TextGrad. GSM8K confirme la tendance.

L'ablation est l'élément le plus instructif du papier : retirer le seul outil Python coûte **+0,79κ sur la tâche tool-selection** et **+0,35κ sur la dimension d'extraction**. La raison identifiée est précise : l'agrégation de confusion par paires de classes est une opération que les LLM à longue fenêtre de contexte ne réalisent pas de façon fiable sur un DataFrame brut. Le code n'est pas un gadget — il compense une limite structurelle de l'attention sur des données tabulaires denses.

### Pourquoi c'est important pour les praticiens

La plupart des équipes qui déploient des LLM-as-judge en production font face exactement au problème que SPEAR adresse : un prompt de juge qui performe bien en moyenne mais qui a des angles morts systématiques sur certaines classes ou certains patterns. Diagnostiquer ces angles morts manuellement est coûteux ; les boucles APE existantes les manquent parce qu'elles lisent le DataFrame en contexte sans en extraire la structure.

L'architecture à quatre outils est aussi un signal sur la direction de l'ingénierie de prompts : le prompt n'est plus l'unique levier, l'*analyse* du comportement du prompt devient elle-même automatisable. SPEAR est évalué sur des tâches industrielles réelles (recrutement, CRM conversationnel), pas seulement sur des benchmarks académiques, ce qui renforce la transférabilité.

### Les perdants et les limites à ne pas ignorer

**GEPA et TextGrad** sont les perdants directs : sur BBH-7, TextGrad atteint 0,484 là où SPEAR atteint 0,938. Pour les équipes qui ont intégré ces outils dans leurs pipelines MLOps, la question de migration se pose.

Les limites structurelles de SPEAR méritent attention. L'agent à horizon long avec sandbox Python augmente le coût en tokens et en latence par rapport à une boucle APE classique — le papier ne publie pas de comparaison de coût explicite, ce qui est un manque notable. L'auto-rollback garantit la monotonie mais peut piéger l'optimiseur dans un bassin local si le paysage de performance est multimodal. Enfin, la qualité du code généré par l'agent pour l'analyse d'erreurs n'est pas auditée indépendamment : un agent qui écrit du code de diagnostic incorrect pourrait converger vers un mauvais prompt de façon silencieuse.

Le code n'est pas encore publié au moment de l'annonce arXiv, ce qui limite la reproductibilité immédiate. La dépendance à CodeAct signifie aussi que les performances dépendent du modèle sous-jacent utilisé comme optimiseur — un détail que les équipes devront calibrer selon leur stack.