Dispatch cognitif — assigner le bon modèle à la bonne tâche

En bref

Dans une architecture multi-agents, l’orchestrateur ne délègue pas seulement des tâches — il choisit aussi le modèle qui les exécute. Utiliser un modèle puissant pour lire un fichier et extraire dix faits est un gaspillage ; utiliser un modèle léger pour détecter des contradictions entre sources produit des résultats insuffisants. Le dispatch cognitif est la décision d’affecter chaque sous-tâche au modèle dont le niveau de raisonnement correspond exactement à ce qu’elle requiert.

Le problème : un seul modèle ne suffit pas

En clair : utiliser Opus pour 100 % des tâches coûte de l’ordre de 15 $ par million de tokens en sortie [ordre de grandeur estimé] ; utiliser Haiku coûte de l’ordre de 1,25 $ par million de tokens [ordre de grandeur estimé]. Un pipeline qui dispatch 80 % du trafic vers Haiku divise la facture par environ 5× à 10× sans perte mesurable sur les tâches mécaniques.

Un système multi-agents peut facilement déployer des dizaines de sous-agents en parallèle. Si chaque agent tourne sur le modèle le plus puissant disponible, le coût explose sans que la qualité en bénéficie proportionnellement. À l’inverse, uniformiser sur un modèle léger réduit le coût mais introduit des erreurs sur les tâches qui exigent du raisonnement approfondi.

Le problème n’est pas technique — les API permettent de choisir le modèle par appel. Il est conceptuel : l’orchestrateur doit catégoriser chaque tâche selon ce qu’elle demande cognitivement, pas selon ce qu’elle semble importante.

Une tâche d’extraction (lire un document, identifier les dates, les nommer) ne demande pas de raisonnement ; elle demande de la précision et de la vitesse. Une tâche d’analyse (comparer deux positions, détecter une contradiction, formuler une recommandation) demande de la profondeur. La distinction est nette en théorie ; elle est souvent brouillée en pratique parce que l’orchestrateur a tendance à surévaluer la difficulté de ses propres sous-tâches.

Ce biais de surévaluation est systémique : les architectes d’un pipeline ont tendance à dispatcher toutes les tâches sur le modèle qu’ils utilisent eux-mêmes pour concevoir le pipeline, par familiarité. Le résultat est un système coûteux où 80 % des sous-agents font du travail que le modèle le moins cher aurait traité aussi bien.

Le dispatch cognitif : principe et grille

En clair : trois classes de tâches, trois niveaux de modèle. Extraction → léger. Analyse → intermédiaire. Orchestration/contexte long → puissant. Chaque cran coûte de 4× à 12× plus cher que le précédent [ordre de grandeur estimé] — le choix doit donc être justifié, pas automatique.

Le dispatch cognitif repose sur une taxonomie simple : classer chaque sous-tâche selon le type d’opération qu’elle requiert, puis associer ce type à un niveau de modèle.

Cette grille est un point de départ, pas une règle absolue. La frontière entre extraction et analyse est parfois floue : résumer un texte dense est plus proche de l’analyse que de l’extraction. Dans ces cas ambigus, monter d’un niveau est moins risqué que de descendre.

Haiku, Sonnet, Opus : application pratique

En clair : Haiku pour lire et extraire, Sonnet pour analyser et rédiger, Opus pour orchestrer et raisonner sur corpus lourd. La matrice ci-dessous croise contexte et recommandation — c’est la grille opérationnelle à garder sous les yeux quand on conçoit une Pieuvre.

Claude propose trois modèles qui illustrent bien cette hiérarchie. Haiku est le modèle léger : rapide, peu coûteux, adapté aux tâches de traitement répétitif. Sonnet est le modèle intermédiaire : il couvre la grande majorité des tâches analytiques dans un système multi-agents. Opus est le modèle puissant : pertinent pour l’orchestrateur lui-même ou pour des tâches de coordination complexe, notamment quand le contexte actif dépasse 100K tokens.

En pratique, sur des corpus de plusieurs dizaines de sources, Haiku traite efficacement l’extraction (lire, catégoriser, lister) tandis que Sonnet est nécessaire pour la recherche documentaire approfondie — où la profondeur analytique conditionne la qualité de la synthèse finale.

Opus en sous-agent reste rare. Son avantage principal s’exprime dans les contextes très longs, où les modèles plus légers perdent en cohérence. Pour la plupart des architectures actuelles, l’orchestrateur est le seul rôle qui justifie Opus par défaut.

Il existe un cas intermédiaire souvent ignoré : les agents de consolidation. Quand un agent doit agréger les outputs de dix agents Haiku et en produire une synthèse cohérente, il fait de l’analyse — pas de l’extraction. Le dispatcher doit traiter l’agent de consolidation comme un agent analytique, même si techniquement il ne lit que des fichiers Markdown produits par les autres.

Ce que la littérature documente

Les travaux sur l’efficience des systèmes multi-agents convergent sur un principe : la qualité d’un pipeline ne dépend pas du modèle le plus puissant qu’il utilise, mais de l’adéquation entre chaque tâche et le modèle qui la traite [NON VÉRIFIÉ — consensus de pratique non encore formalisé dans un benchmark unique]. Des études de coût-qualité sur GPT-4 vs GPT-3.5 dans des architectures à agents montrent que le remplacement sélectif (et non global) des modèles est l’approche qui minimise la dégradation tout en réduisant les coûts.

La recherche sur les agents hiérarchiques (hierarchical agents) documente également l’importance du modèle dans les rôles d’orchestration : un orchestrateur plus faible que ses sous-agents produit des pipelines incohérents, où les agents locaux font du bon travail mais l’intégration finale échoue. Le niveau du modèle d’orchestration fixe le plafond de cohérence du système entier.

Implémenter le dispatch : décisions pratiques

En clair : trois décisions séquentielles, dans cet ordre. 1. Lister toutes les sous-tâches. 2. Les classer (extraction / analyse / coordination). 3. Affecter un modèle par classe. Pas avant.

Le dispatch cognitif n’est pas un concept à appliquer intuitivement au moment de coder chaque appel d’agent. Il se structure en amont, lors de la décomposition du pipeline.

Classer les tâches avant de choisir les modèles

La séquence utile : d’abord lister toutes les sous-tâches du pipeline, puis les classer selon la grille (extraction / analyse / coordination), enfin affecter un modèle par classe. Ce n’est qu’après cette classification que les modèles sont choisis — pas avant.

Une heuristique rapide : si la tâche peut être décrite par un verbe simple (lire, lister, extraire, compter, trier, catégoriser), c’est de l’extraction. Si elle nécessite deux verbes ou plus avec un lien logique (lire et déduire, comparer et recommander, détecter et expliquer), c’est de l’analyse.

Traiter les agents de consolidation comme des agents analytiques

Les agents qui agrègent les outputs d’autres agents méritent une attention particulière. Leur tâche semble simple (lire des Markdown, écrire un résumé) mais elle est analytique : ils doivent détecter des incohérences entre sources, arbitrer des contradictions, et maintenir la cohérence d’ensemble. Dispatcher un agent de consolidation sur Haiku revient à confier le raisonnement le plus complexe du pipeline au modèle le moins capable.

Définir le contrat d’output avant le dispatch

Chaque sous-tâche doit avoir un format d’output défini avant que le modèle soit choisi. Ce format (liste de N faits, tableau à M colonnes, texte de X paragraphes) contraint le niveau de modèle nécessaire. Un output très structuré avec des contraintes strictes tolère mieux un modèle léger qu’un output libre attendant une synthèse narrative.

Erreurs courantes et leurs conséquences

En clair : six erreurs symétriques. Sous-dispatcher dégrade la qualité ; sur-dispatcher gonfle la facture. Le coût d’une erreur de dispatch se voit rarement sur un agent isolé — il s’accumule à l’échelle du pipeline batch.

Sous-utiliser un modèle puissant. Utiliser Haiku pour une tâche d’analyse croisée produit des outputs superficiels — le sous-agent liste des points sans détecter les tensions. L’erreur n’est pas toujours visible immédiatement ; elle se manifeste dans la consolidation, quand l’orchestrateur reçoit des livrables plats qu’il doit compenser par du travail supplémentaire.

Sur-utiliser un modèle puissant. Utiliser Sonnet ou Opus pour lire cent fichiers et en extraire une date chacun coûte entre 5× et 20× le prix d’un traitement Haiku équivalent, sans amélioration mesurable du résultat. À l’échelle d’un pipeline de production batch (par exemple 1000 extractions par jour), la différence de coût atteint plusieurs dizaines à centaines de dollars par jour [ordre de grandeur estimé], significatif et récurrent.

Dispatcher sur la perception d’importance. L’erreur la plus fréquente : choisir le modèle selon l’importance stratégique de la tâche plutôt que selon sa nature cognitive. Une extraction de données critiques reste une extraction — elle n’a pas besoin de Sonnet parce que les données sont importantes.

Ignorer la longueur de contexte. Les sessions longues dégradent la cohérence des modèles légers avant les modèles puissants. Pour des tâches qui nécessitent de maintenir un contexte actif de plusieurs dizaines de milliers de tokens, descendre d’un niveau de modèle peut produire des outputs incohérents en fin de session.

Ne pas définir le critère d’erreur à l’avance. Sans définir ce qu’est un livrable insuffisant pour chaque type de sous-tâche, l’orchestrateur n’a pas de signal pour détecter une erreur de dispatch. Définir le critère de vérification avant de lancer les agents permet de comparer rapidement les outputs et d’ajuster.

Mélanger les tâches dans un même prompt d’agent. Si un sous-agent reçoit un prompt qui lui demande à la fois d’extraire des faits et d’en déduire des implications, le niveau de modèle est impossible à optimiser : il faut soit sur-dispatcher (Sonnet pour une extraction), soit sous-dispatcher (Haiku pour une inférence). Le dispatch cognitif impose de décomposer les prompts multi-tâches en prompts mono-tâches avant d’assigner le modèle.

Ce qu’il faut retenir

• Le dispatch cognitif consiste à aligner le niveau du modèle avec la nature de la tâche, pas son importance.
• Trois types d’opérations couvrent la majorité des cas : extraction (modèle léger), analyse/synthèse (modèle intermédiaire), coordination/contexte long (modèle puissant).
• La recherche documentaire, même quand elle semble “simple”, relève de l’analyse — un modèle intermédiaire est le minimum.
• Les erreurs de dispatch se voient rarement sur un agent isolé ; elles émergent lors de la consolidation, quand les livrables insuffisants s’accumulent.
• Définir le critère de vérification par type de sous-tâche avant de lancer les agents est la mesure préventive la plus efficace.

Signaux skill

Aucune insuffisance détectée. Le prompt fourni était complet (sujet, T-sources, angle éditorial, classification, guidelines). La contrainte “ne pas mentionner les noms propres de modèles” puis “on peut les mentionner” crée une ambiguïté dans l’angle éditorial — elle a été résolue en faveur de l’usage explicite (Haiku/Sonnet/Opus comme exemples concrets) tout en présentant le concept de façon générique dans la grille.