Où va réellement le temps de l'agent et pourquoi il est rarement fait l'objet d'inférences

Le travail de performance suit l'attention, et l'attention se porte sur le modèle. C’est l’élément visible, auquel est attaché un prix par jeton, et c’est ce que tout le monde lit.

Lorsque vous instrumentez correctement le fonctionnement d'un agent, l'image est suffisamment différente pour changer ce sur quoi vous travaillez.

La forme brute

Dans les exécutions que nous avons examinées, le temps écoulé se divise grosso modo en quatre parties.

Inférence de modèle, qui est réelle mais généralement minoritaire.

Récupération, y compris tout ce que fait l'index et ce que fait l'étape de reclassement si elle existe.

Les appels d'outils, qui dépassent votre système et sont donc soumis à la latence de quelqu'un d'autre.

Structure séquentielle, qui correspond au temps perdu pour des étapes qui se sont succédées et qui n'étaient pas nécessaires.

Les proportions varient selon la charge de travail. La surprise est constante : les deux derniers sont généralement plus grands que ce à quoi les équipes s’attendent, et ce sont ceux que personne n’optimise.

La structure séquentielle est la victoire la moins chère

Un agent qui récupère, puis vérifie un calendrier, puis recherche un enregistrement, puis appelle le modèle a payé quatre latences en série. Souvent, les trois premiers sont indépendants et auraient pu se présenter en même temps.

Cela ressemble à du code correct plutôt qu'à un problème de performances, c'est pourquoi il survit à l'examen. Il s’agit également généralement de la plus grande amélioration disponible et ne nécessite aucune modification des modèles, des invites ou de l’infrastructure.

Les appels d'outils sont le problème de quelqu'un d'autre, ce qui en fait le vôtre

Un outil qui atteint un système interne hérite du comportement de ce système, y compris de ses mauvais après-midi. Un agent sans délai d'attente lors d'un appel d'outil est confronté à un pire cas illimité qui finira par se produire.

Deux choses aident. Délais d'attente avec un repli défini, donc une dépendance lente dégrade l'exécution plutôt que de la suspendre. Et mesurer la latence des outils séparément par outil, de sorte que celui qui prend occasionnellement onze secondes soit visible plutôt que moyenné.

Les tentatives représentent du temps et de l'argent

Nous écrivons assez souvent sur les tentatives en termes de coût. Ils constituent également le plus grand multiplicateur de latence dans la plupart des systèmes, car une exécution ratée qui redémarre paie deux fois la totalité du temps écoulé pour un résultat.

Tout chiffre de latence qui fait la moyenne des tentatives réussies décrit quelque chose qui n'arrive pas à un utilisateur.

Mesurez les centiles, pas les moyens

Les durées d’exécution des agents sont fortement asymétriques. Une petite proportion d'exécutions prend beaucoup plus de temps que les autres, généralement en raison d'un outil lent, d'une nouvelle tentative ou d'un agent qui parcourt plus d'étapes que prévu.

La moyenne de cette distribution est un nombre qui ne décrit aucune exécution réelle. Les percentiles élevés correspondent à ce qu'un utilisateur expérimente lors d'une mauvaise journée et à ceux-ci doivent être comparés un budget de latence.

Par où commencer

Instrumentez les quatre catégories séparément. Regardez les centiles. Trouvez les étapes séquentielles et indépendantes. Mettez des délais d'attente sur les outils. Comptez les tentatives en dehors des réussites.

Ce travail n’est pas glamour et rapporte généralement plus qu’un changement de modèle, ce qui est le thème récurrent de presque tout ce que nous écrivons.

Suivant

Les pages d'observabilité de l'IA couvrent l'instrumentation au sein d'une exécution. Les pages du système d'orchestration d'agent couvrent l'évaluation, où la latence est évaluée en même temps que le coût et l'exactitude plutôt que surveillée séparément.