Choisir un modèle pour votre agent : capacité, latence et coût
La question posée est souvent : quel modèle est le meilleur pour les agents ? Celle qui produit un bon système est : quel modèle est le meilleur pour cette étape, sur nos données, dans notre budget de latence — et la réponse comporte généralement plus d'un modèle.
Une exécution n'est pas homogène. Décider de l'action suivante demande du raisonnement. Extraire trois champs d'un document, non. Résumer un résultat pour l'utilisateur, non plus. Traiter tout cela comme un seul achat, c'est ainsi qu'on paie un prix de pointe pour reformater du JSON.
Découpez l'exécution avant de choisir#
| Étape | Ce qu'elle exige | Niveau de modèle sensé |
|---|---|---|
| Planifier ou choisir l'action | Raisonnement, respect des consignes | Le plus fort que vous pouvez payer |
| Appeler un outil avec arguments | Sortie structurée fiable | Milieu de gamme, schémas stricts |
| Extraire des champs | Justesse sur texte court | Petit et rapide |
| Classer ou router | Cohérence | Petit, ou classifieur affiné |
| Rédiger la réponse utilisateur | Ton et clarté | Milieu de gamme |
Les benchmarks font la liste courte, pas la décision#
Les benchmarks publics disent quels modèles sont plausibles. Ils ne disent pas lequel gère vos schémas, vos formats de documents et vos clients difficiles, car rien de tout cela n'y figure. Construisez trente cas réels issus de vos journaux — dont les cinq qui vous gênent — et faites tourner la liste courte dessus. L'écart d'ordre avec le benchmark suffit régulièrement à changer la décision.
Incluez des cas où la bonne conduite est de refuser ou de poser une question. Les modèles diffèrent bien plus sur le fait de savoir s'arrêter que sur quoi dire.
Les trois contraintes qui mordent#
- Plancher de latence : chaque appel en a un, et un agent en fait plusieurs. Mesurez toute l'exécution.
- Fiabilité de la sortie structurée : 97 % d'arguments valides casse une exécution sur dix avec trois appels.
- Gestion du contexte : le contexte long coûte et dilue l'attention ; mesurez à la longueur réelle.
Le routage sans projet de recherche#
Le routage de modèles a l'air sophistiqué et tient souvent dans un fichier de configuration. Un modèle par défaut par type d'étape, une surcharge par outil, et un journal indiquant quel modèle a produit quelle décision. Commencez par descendre d'un cran l'extraction et la classification ; cela suffit souvent à retirer un tiers à la moitié de la facture sans toucher à ce que l'utilisateur voit.
Anticipez les retraits de version#
Les versions sont retirées selon le calendrier du fournisseur. Deux habitudes en font un non-événement : épingler une version explicite plutôt qu'un alias mouvant, et garder le jeu d'évaluation exécutable par une seule commande pour que requalifier prenne un après-midi et non un projet.
Questions fréquentes
Faut-il le plus gros modèle partout ?
Seulement si vous n'avez pas mesuré. L'étape de décision en profite souvent ; extraction, classification et mise en forme rarement. Découper par étape est la réduction de coût la plus simple sans toucher au visible.
Les modèles ouverts conviennent-ils ?
Pour des étapes étroites avec schémas stricts, souvent oui, et l'économie est convaincante à volume. Pour la planification ouverte, ils demandent plus d'échafaudage. Testez sur vos trente cas.
À quelle fréquence réévaluer ?
À chaque version que vous pourriez adopter, et sinon tous les deux trimestres environ. Ce n'est tenable que si l'évaluation tient en une commande.
choisir un llmsélection de modèle agentsroutage de modèleslatence agentssortie structurée
