Le pattern Protégé

Un modèle de 7 milliards de paramètres a résolu 42,4 % des tâches SWE-bench Verified. Le précédent record pour un petit modèle était de 17,0 %. Le modèle n’est pas devenu plus intelligent. Le modèle a appris quand demander de l’aide.¹

Kon et al. ont entraîné un modèle Qwen2.5-Coder-7B-Instruct à collaborer avec un modèle frontière en tant qu’expert. L’expert a répondu à environ quatre questions par tâche, consommant 11 % du total des tokens.¹ Les 89 % restants des tokens provenaient du petit modèle exécutant des opérations routinières : lecture de fichiers, exécution de tests, application de correctifs. Le coût est passé de 0,54-1,24 $ par instance (expert seul) à 0,13-0,15 $ (protégé avec expert).¹ Une réduction de coût de 8,2x avec un gain de performance de 25 points par rapport au précédent état de l’art des petits modèles.

Ce résultat valide un pattern vers lequel les praticiens convergent indépendamment : le pattern protégé.

TL;DR

Le pattern protégé répartit le travail de l’agent entre un petit modèle économique (le protégé) qui gère l’exécution routinière et un modèle frontière (l’expert) qui gère les décisions critiques. SWE-Protege a démontré une amélioration de 25,4 points et une réduction de coût de 8,2x.¹ Le propre système de recherche multi-agents d’Anthropic utilise la même répartition par niveaux : Claude Opus pour l’agent principal, Claude Sonnet pour les sous-agents.³ Le pattern fonctionne parce que la majeure partie du travail agentique est mécanique. Orienter ce travail mécanique vers un modèle 5 fois moins cher par token récupère 80 % du budget de coût sans sacrifier la qualité sur les décisions qui comptent.

Le framework expert-protégé

SWE-Protege définit la relation avec précision.¹ Le protégé est le seul décideur. L’expert n’initie jamais. Le protégé choisit quand escalader, quelle question poser, et comment intégrer la réponse. L’apprentissage par renforcement entraîne le protégé à optimiser deux objectifs concurrents : résoudre la tâche ET minimiser le recours à l’expert.

La structure de récompense RL pénalise trois modes de défaillance :

Boucle dégénérative. Le protégé pose la même question de manière répétée. La pénalité décourage l’impuissance apprise.

Collaboration improductive. Le protégé pose une question, ignore la réponse, et poursuit son plan initial. La pénalité décourage l’escalade performative.

Dépendance excessive. Le protégé transmet chaque décision à l’expert. La pénalité décourage le protégé de devenir une simple couche de transmission.

Le résultat est un protégé qui développe un véritable jugement sur ses propres limites. Le modèle 7B a appris à distinguer les tâches qu’il pouvait gérer seul (lectures de fichiers, exécution de tests, correctifs simples) des tâches nécessitant l’intervention de l’expert (décisions architecturales, exigences ambiguës, analyse de dépendances multi-fichiers).¹

Pourquoi le routage fonctionne

Les fondements académiques du routage de modèles sont antérieurs à SWE-Protege. RouteLLM a démontré que le routage entre un modèle fort et un modèle faible permet d’atteindre jusqu’à 3,66x d’économies tout en maintenant 95 % de la qualité du modèle fort.¹¹ Le routeur apprend quelles requêtes nécessitent une capacité frontière et quelles requêtes un modèle plus petit gère tout aussi bien.

IBM Research a obtenu des résultats similaires avec une méthode de routage « frugale » : appeler des modèles plus petits et spécialisés séquentiellement jusqu’à ce que l’un d’eux produise une réponse confiante.¹⁴ Cette approche atteint jusqu’à 85 % de réduction de coût sur les requêtes simples.

L’intuition sous-jacente est distributionnelle. La plupart des opérations agentiques ne sont pas difficiles. Lire un fichier, exécuter un grep, appliquer un correctif bien défini, lancer une suite de tests : ces opérations nécessitent une exécution correcte, pas un raisonnement profond. Un modèle 5 fois moins cher par token les gère de manière identique à un modèle frontière.⁷ Les opérations difficiles (diagnostiquer un bug subtil, choisir entre des approches architecturales, évaluer si une solution est correcte) bénéficient du raisonnement frontière. Le pattern protégé oriente chaque opération vers le niveau approprié.

La propre documentation d’Anthropic rend la répartition par niveaux explicite. Le guide « Choosing the Right Model » recommande Haiku pour les tâches de sous-agents et Opus pour l’ingénierie logicielle professionnelle et les agents avancés.⁸ Cette recommandation n’est pas du marketing. Elle reflète des différences de performance mesurées selon les distributions de complexité des tâches.

Implémentations en production

Trois systèmes en production démontrent le pattern protégé à grande échelle.

Le système de recherche multi-agents d’Anthropic. Claude Opus dirige, Claude Sonnet exécute en tant que sous-agents.³ Le système a surpassé Claude Opus en agent unique de 90,2 % sur l’évaluation interne. L’amélioration ne provenait pas d’un meilleur modèle mais d’une meilleure décomposition des tâches. Les sous-agents Sonnet ont consommé la majeure partie des tokens sur les opérations de recherche tandis qu’Opus concentrait son budget de raisonnement sur la synthèse et le jugement.

Le compilateur C de Carlini. Seize agents Claude en parallèle ont produit un compilateur C de 100 000 lignes basé sur Rust, capable de compiler un Linux 6.9 amorçable.⁴ Coût : 20 000 $ répartis sur environ 2 000 sessions. Bien que tous les agents fonctionnaient au même niveau, le projet a révélé la propriété d’auto-organisation que le pattern protégé formalise : les agents gravitaient naturellement vers « le problème suivant le plus évident ».⁴ Aucun orchestrateur central n’assignait les tâches.

Chris Lattner a examiné le compilateur et identifié la frontière entre ce que les agents IA gèrent bien et où le jugement humain reste essentiel : « Abaisser les barrières à l’implémentation ne réduit pas l’importance des ingénieurs ; au contraire, cela élève l’importance de la vision, du jugement et du goût. »⁵⁶ Les agents excellaient dans l’assemblage de techniques connues. Les agents peinaient face à « la généralisation ouverte requise pour des systèmes de qualité production ».⁵

Le routage de modèles en pratique. L’étude « What Claude Code Chooses » a analysé 2 430 choix d’outils sur trois modèles Claude.⁹ Opus 4.6 a montré des préférences tournées vers l’avenir (Drizzle 100 % vs Prisma 0 %), tandis que Sonnet 4.5 faisait des choix plus conventionnels.⁹ Cette divergence a suscité d’importantes discussions dans la communauté.¹⁰ Différents niveaux apportent différents biais aux décisions ambiguës. Un protégé effectuant des sélections d’outils routinières n’a pas besoin de raisonnement frontière. Un protégé confronté à un choix architectural ambigu bénéficie de l’escalade.

Arithmétique des coûts

L’économie rend le pattern convaincant avant même de considérer les gains de performance.

Aux tarifs actuels d’Anthropic, l’écart entre niveaux est exactement de 5x :⁷

Une session d’agent typique consomme de 50 000 à 200 000 tokens dans chaque direction. En supposant 100K tokens en entrée et 100K en sortie au tarif Opus exclusif, une session coûte 0,50 $ en entrée + 2,50 $ en sortie = 3,00 $. Si le protégé gère 80 % des tokens et l’expert 20 %, la même session coûte :

• Protégé (80K tokens) : 0,08 $ en entrée + 0,40 $ en sortie = 0,48 $
• Expert (20K tokens) : 0,10 $ en entrée + 0,50 $ en sortie = 0,60 $
• Total : 1,08 $ (64 % d’économies)

SWE-Protege a réalisé des économies encore plus agressives car l’expert ne consommait que 11 % des tokens, pas 20 %.¹ Sur 100 sessions d’agents par jour, la différence se cumule : 300 $/jour en mode expert exclusif contre 108 $/jour avec routage protégé. Sur un mois : 9 000 $ contre 3 240 $.

Le classement SWE-bench fournit le contexte de performance.¹² Claude 4.5 Opus en raisonnement élevé atteint un taux de résolution de 76,8 % à 0,754 $ par instance. Une approche routée par protégé à 42,4 % de taux de résolution coûte 0,13-0,15 $ par instance.¹ Pour les tâches dans les capacités du protégé, le coût par tâche résolue favorise le routage. Pour les tâches nécessitant un raisonnement frontière, l’expert reste disponible à la demande.

Le phénomène de collaborativité

Wang et al. ont découvert une propriété qui explique pourquoi le pattern protégé produit de meilleurs résultats que l’un ou l’autre modèle seul.¹³ L’article « Mixture-of-Agents » a montré que les modèles génèrent de meilleures réponses lorsqu’ils reçoivent les sorties d’autres modèles, même lorsque ces autres modèles sont moins performants.¹³

Cette découverte inverse la hiérarchie attendue. Un modèle frontière lisant l’analyse initiale et les lectures de fichiers d’un petit modèle produit une meilleure sortie que le modèle frontière partant de zéro. Le travail du petit modèle n’est pas simplement de la main-d’œuvre bon marché déchargée de l’expert. Le travail du petit modèle fournit un contexte structuré qui améliore le raisonnement de l’expert.

La recherche multi-agents d’Anthropic a confirmé le pattern : passer les sous-agents de Sonnet 3.7 à Sonnet 4 a produit « un gain de performance plus important que le doublement du budget de tokens sur Claude Sonnet 3.7 ».³ La qualité du modèle au niveau protégé compte. Un meilleur protégé produit un meilleur expert.

Ce que vous pouvez construire

Trois patterns d’escalade correspondent à des implémentations progressivement plus autonomes.

Pattern 1 : Routage basé sur la confiance. L’implémentation la plus simple. Le protégé génère une réponse et un score de confiance. En dessous d’un seuil, la requête est routée vers l’expert. RouteLLM fournit un framework open source pour entraîner le routeur.¹¹ Commencez ici.

Pattern 2 : Routage par type de tâche. Classifiez les opérations par type et routez de manière déterministe. Lectures de fichiers, exécution de tests et formatage vers Haiku. Revue de code, décisions architecturales et exigences ambiguës vers Opus. Le guide « Building Effective Agents » d’Anthropic appelle cela le pattern de routage : « classifier les entrées et diriger les questions faciles ou courantes vers des modèles plus petits et économiques ».²

Pattern 3 : Escalade apprise. L’approche SWE-Protege. Entraînez le protégé à décider de ses propres points d’escalade par apprentissage par renforcement.¹ Le protégé développe un véritable jugement sur ses limites. Le pattern le plus sophistiqué et le plus performant, mais il nécessite une infrastructure RL et des données d’entraînement étiquetées par des experts.

Chaque pattern échange de la complexité d’implémentation contre des économies de coût et de l’autonomie. Le pattern 1 nécessite un jeu de données de calibration de confiance. Le pattern 2 nécessite une taxonomie des tâches. Le pattern 3 nécessite des exécutions d’entraînement RL. Les trois surpassent un déploiement mono-niveau en performance ajustée au coût.

Points clés à retenir

• Le pattern protégé n’est pas de la répartition de charge. Le protégé prend des décisions sur ses propres limites. L’expert fournit du jugement, pas du débit.
• La majeure partie du travail agentique est mécanique. Orienter ce travail vers un modèle 5 fois moins cher récupère le budget de coût pour les décisions qui nécessitent un raisonnement frontière.
• De meilleurs protégés produisent de meilleurs experts. Le phénomène de collaborativité signifie que les sorties des petits modèles améliorent le raisonnement des modèles frontières.¹³
• L’observation de Lattner s’applique au pattern lui-même : « À mesure qu’écrire du code devient plus facile, concevoir du logiciel devient plus important que jamais. »⁵ Le protégé gère l’écriture, plus facile. L’expert gère la conception, plus difficile.

Fait partie de la série AI Engineering. Voir aussi : Context Is the New Memory, Claude Code as Infrastructure, et The 10% Wall.