Résumé Technique : Quand la Justesse N'est Pas Utilisable

Énoncé du Problème

Les modèles de langage déployés font face à un écart critique de fiabilité : une sortie doit être à la fois mathématiquement correcte et conforme au format (par exemple, un JSON valide avec des champs spécifiques) pour être utilisable en production. Les benchmarks standards mesurent généralement la précision des tâches de manière isolée, ignorant l'« écart de fiabilité de la sortie structurée » où un modèle résout correctement un problème mais échoue à respecter le schéma requis, rendant la réponse inutilisable.

Ce document examine cet écart en utilisant des benchmarks mathématiques (GSM8K et MATH) comme terrain d'essai contrôlé. La vérité terrain est sans équivoque, et le contrat de sortie est strict (objets JSON avec les champs reasoning et answer). La métrique principale est la précision de la sortie, définie comme l'événement conjoint de la correction mathématique et d'une structure JSON valide.

Méthodologie

Configuration Expérimentale

L'étude évalue trois petits modèles de langage à poids ouverts (7–9 milliards de paramètres) : Llama 3.1-8B Instruct, Gemma 2-9B IT, et Qwen 2.5-7B Instruct. De plus, GPT-4o est évalué comme sonde de généralisation sur GSM8K. Les modèles sont testés selon cinq stratégies de prompt :

1. NAIVE : Aucun prompt système ; uniquement l'entrée de la tâche.
2. REFERENCE : Un prompt statique minimal, écrit à la main, avec des instructions JSON de base (sans ajustement itératif).
3. CONSTRAINED : Décodage contraint basé sur la grammaire (vLLM) pour imposer la validité syntaxique.
4. REF+CONSTRAINED : Combinaison du prompt REFERENCE et du décodage contraint.
5. ALOLAB : Un optimiseur de prompt système itératif (décrit ci-dessous).

Le Cadre AloLab

AloLab est un optimiseur de prompt système itératif, boîte noire, conçu pour combler l'écart de précision de la sortie sans fine-tuning du modèle ni accès aux poids.

• Architecture : Il fonctionne comme un pipeline d'agent méta utilisant Claude Sonnet 4.5 comme LLM sous-jacent pour les nœuds Analyseur et Optimiseur.
• Processus :
  1. Résolveur : Interroge le modèle cible via API (boîte noire) sur une partition d'entraînement/validation.
  2. Évaluateur : Calcule de manière déterministe json_valid et is_correct.
  3. Analyseur : Identifie les motifs d'échec récurrents (par exemple, enveloppement par des barres de code markdown, incohérences de champs) et les motifs de succès, en utilisant optionnellement une « carte de modèle » (architecture, nombre de paramètres) pour adapter les résultats.
  4. Optimiseur : Réécrit le prompt système pour corriger les échecs identifiés tout en préservant les comportements réussis.
• Coût : L'optimisation nécessite environ 5 000 à 10 000 appels d'inférence du modèle cible et 30 appels d'agent méta par modèle/ensemble de données. Le déploiement engendre zéro surcharge supplémentaire, n'utilisant que le prompt optimisé final.

Études d'Ablation

• Historique uniquement : Suppression des informations explicites sur le profil du modèle de l'Analyseur/Optimiseur pour tester si le feedback itératif seul suffit.
• Qualité de l'agent méta : Remplacement de Claude Sonnet 4.5 par le plus petit Claude 3 Haiku pour tester si la capacité de l'optimiseur pilote les résultats.

Résultats Clés

1. L'Échec de Format de Base

Un échec systématique de format émerge à la ligne de base :

• Le prompting NAIVE atteint une haute précision de tâche (par exemple, 77–85 % sur GSM8K) mais 0 % de précision de sortie sur tous les modèles. Les modèles résolvent les mathématiques mais échouent à produire un JSON valide.
• Le prompting REFERENCE (prompts statiques écrits à la main) donne de mauvais résultats, avec 0 % de précision de sortie pour Gemma et Qwen sur MATH, et 0 % pour Gemma sur GSM8K en raison d'un enveloppement systématique par des barres de code markdown (```json) qui brise les analyseurs.

2. Performance d'AloLab

AloLab comble substantiellement l'écart :

• GSM8K : Atteint 84–87 % de précision de sortie sur les trois modèles ouverts et 95,2 % sur GPT-4o.
• MATH : Atteint 34–40 % de précision de sortie.
• Significativité Statistique : Dans 29 comparaisons appariées de McNemar sur 30 (5 exécutions × 3 modèles × 2 ensembles de données), AloLab surpasse significativement le meilleur prompt statique (REFERENCE) à $p < 0,05$.
• Latence : AloLab opère à une latence d'inférence proche de la ligne de base (0,71×–1,06× NAIVE sur GSM8K), tandis que le décodage contraint engendre une surcharge de latence de 3,6×–8,2×.

3. Compromis du Décodage Contraint

Bien que le décodage contraint impose une validité syntaxique, il introduit une latence significative et, dans certains cas (par exemple, Gemma sur GSM8K), dégrade les performances de la tâche (52,4 % des sorties deviennent des duplicatas exacts). Il occupe une région de « haute latence, précision de sortie inférieure » par rapport à AloLab.

4. Résultats des Ablations

• Capacité de l'agent méta : Le remplacement de Sonnet 4.5 par Haiku réduit la précision de sortie moyenne de 84,15 % à 61,0 % et augmente la variance d'exécution à d'exécution de <1 point de pourcentage à 21,8 points de pourcentage. Cela confirme que la capacité de l'agent méta est un moteur principal de la qualité de l'optimisation ; la boucle itérative seule est insuffisante sans un optimiseur capable.
• Connaissance du modèle : La suppression des profils de modèle explicites (architecture, etc.) de l'optimiseur a entraîné des baisses de performance négligeables (<1,3 pp), suggérant que les motifs d'exécution observés sont le signal dominant pour l'optimisation, et non la connaissance préalable du modèle.

5. Généralisation

L'échec de format n'est pas limité aux petits modèles ouverts. GPT-4o a également affiché 0 % de précision de sortie sous les prompts NAIVE et REFERENCE en raison d'un enveloppement systématique par des barres de code markdown. AloLab a résolu cela en apprenant à supprimer les barres, atteignant 95,2 % de précision de sortie, confirmant que l'échec est un défaut de génération spécifique au modèle plutôt qu'une limitation liée à la taille.

6. Échecs Résiduels

Un mode d'échec spécifique persiste même avec AloLab : Incohérence Format-Exécution. Dans 1,5–1,8 % des échecs, le JSON est valide et le champ de raisonnement contient la logique correcte, mais le champ answer contient la mauvaise valeur. Un juge LLM indépendant a vérifié ce découplage, suggérant qu'il s'agit d'une propriété de génération intrinsèque qui devient plus visible à mesure que les erreurs de format plus simples sont éliminées.

Importance et Revendications

Le document revendique que les limites pratiques des petits modèles de langage sous des contrats de sortie stricts ne sont pas des limites de raisonnement (comme en témoigne la haute précision de tâche NAIVE) mais des limites de communication structurée.

• AloLab démontre que l'optimisation itérative de prompts en boîte noire peut efficacement combler l'écart entre la justesse de la tâche et la conformité au format sans fine-tuning.
• Il offre une solution plus précise et plus rentable au moment de l'inférence par rapport au décodage contraint, qui souffre d'une latence élevée et d'une dégradation potentielle de la tâche.
• Le travail met en évidence que les prompts statiques sont souvent insuffisants pour des contraintes de format complexes et que les défauts de génération spécifiques au modèle (comme l'enveloppement par des barres de code markdown) doivent être dynamiquement identifiés et supprimés.

Les auteurs concluent que, bien qu'AloLab améliore considérablement la fiabilité, le « désaccord format-exécution » restant (raisonnement correct, champ de réponse erroné) représente une direction concrète pour la recherche future.