Les optimisations qui valent la peine d'être faites et celles qui semblent impressionnantes

Le travail d’optimisation a une attraction gravitationnelle vers ce qui est techniquement intéressant. Les techniques de niveau inférence sont véritablement intelligentes, bien documentées et satisfaisantes à mettre en œuvre.

Ils se situent également, dans la plupart des déploiements, quelque part en dessous du cinquième rang sur la liste des éléments qui pourraient aider.

L'ordre dans lequel nous travaillerions réellement

Tout d’abord, supprimez le travail qui n’a pas besoin d’être effectué. Définitions d'outils inutilisées occupant le contexte à chaque appel. Sections d'invite ajoutées pour un cas limite il y a deux ans. Récupération renvoyant dix passages là où trois suffiraient. Il s’agit d’un pur déchet, et son élimination ne coûte rien en qualité car cela n’apporte rien.

Deuxièmement, corrigez les tentatives. Une exécution qui échoue et redémarre paie deux fois pour un résultat. Les tentatives constituent généralement la plus grande inefficacité réparable et elles sont invisibles à moins d’être mesurées indépendamment des succès.

Troisièmement, parallélisez ce qui est séquentiel mais indépendant. La plupart du code d'agent exécute les étapes en série parce que c'est ainsi qu'il se lit, et non parce qu'il le doit.

Quatrièmement, dimensionnez correctement le modèle par étape. Les étapes de classification et d’extraction nécessitent rarement des capacités de pointe, et leur exécution représente un coût permanent sans aucun avantage.

Cinquièmement, et seulement maintenant, les techniques de niveau inférence.

Pourquoi l'ordre compte plus que les techniques

Les quatre premiers sont bon marché, à faible risque et souvent importants. Le cinquième est sophistiqué et son impact est limité par la durée de votre temps écoulé qui a été inférée en premier lieu.

Si l'inférence représente un tiers de votre temps d'exécution, une amélioration d'inférence de vingt pour cent équivaut à une amélioration d'exécution de sept pour cent. Cela en vaut la peine, et cela ne vaut pas la peine avant les tentatives qui vous coûtent cent pour cent sur une part de votre trafic.

Mesurer avant de choisir

Tout ce qui précède suppose que vous connaissez la panne. La plupart des équipes ne le font pas, car l'instrumentation standard génère des rapports par exécution plutôt que par étape.

La mesure par étape est la condition préalable à chaque décision de cette liste. Sans cela, l'optimisation est une question de goût, et le goût sélectionne de manière fiable l'option intéressante.

Chaque optimisation est une hypothèse sur la qualité

La raison pour laquelle nous insistons sur l’évaluation avant l’optimisation est que tous ces changements peuvent réduire la qualité et que la plupart des réductions ne sont pas visibles immédiatement.

Un modèle plus petit sur une marche qui s'est avéré nécessiter des capacités. Une invite tronquée qui a supprimé le paragraphe traitant d'un véritable cas limite. Moins de passages récupérés, ce qui est bien jusqu'à ce que la question ait besoin du quatrième.

La notation de chaque changement par rapport aux critères que vous avez définis au préalable est ce qui différencie une économie d'un report. C'est exactement ce que fait l'Optimizer, et c'est pourquoi il refuse de présenter un changement comme une amélioration du seul coût.

La conclusion peu glamour

Le travail d'optimisation le plus rentable dans la plupart des systèmes d'agents consiste à supprimer des éléments : outils inutilisés, texte d'invite accumulé, récupération inutile, étapes qui n'auraient pas dû être séquentielles.

Rien de tout cela n’est intéressant à écrire, ce qui explique probablement pourquoi on écrit tant d’autres choses sur les alternatives.

Suivant

Les pages Optimiseur et Surveillance des jetons couvrent la mesure par étape et l'optimisation mesurée par évaluation. Les pages d'observabilité de l'IA couvrent l'instrumentation au sein d'une exécution.