Les petits modèles font l'essentiel du travail dans un système bien conçu

Regardez à l’intérieur d’une exécution d’agent unique et comptez ce qui se passe réellement. Décider à quelle catégorie appartient une demande. Extraire trois champs d'un document. Juger si un passage récupéré est pertinent. Formatage d'un résultat. Choisir quel outil appeler ensuite.

Ensuite l’étape du raisonnement, qui en fait généralement partie.

La plupart des systèmes exécutent le même grand modèle sur tout cela, car c'est ainsi que le système a été construit pendant la phase où le faire fonctionner était l'objectif.

L’économie de la capacité uniforme

Un grand modèle sur une étape de classification coûte plusieurs fois ce qu'un petit modèle, produit la même réponse, et ce à chaque exécution pour toujours.

La différence individuelle est insignifiante, c’est précisément pourquoi elle persiste. Personne ne critique une étape qui fonctionne. Le cumul du trafic sur une année n’est pas du tout anodin.

Là où les petits modèles suffisent vraiment

Classification dans un ensemble connu de catégories. Extraction de champs structurés à partir de texte semi-structuré. Jugement de pertinence sur une liste restreinte. Reformatage. Bref résumé où la source est déjà centrée.

Ceux-ci partagent une propriété : l’espace de sortie est contraint. Lorsque la bonne réponse est l’une des cinq catégories ou un champ d’un document, la capacité au-delà d’un seuil n’ajoute rien car elle n’a nulle part où aller.

Là où ce n'est pas le cas

Raisonnement en plusieurs étapes où les erreurs intermédiaires se cumulent. Tâches nécessitant plusieurs contraintes tenues simultanément. Travaillez avec une structure inhabituelle que les petits modèles manipulent mal de manière cohérente plutôt qu'occasionnellement. Génération où la qualité est véritablement illimitée.

La distinction n’est pas une difficulté de tâche au sens humain du terme. Il s'agit de savoir si l'espace de sortie est délimité.

Comment découvrir plutôt que deviner

Instrument par étape, pas par analyse. La plupart des systèmes signalent le coût et la latence pour l'ensemble de l'agent, ce qui représente en moyenne une étape de raisonnement coûteuse avec une douzaine d'étapes triviales et masque les deux.

Une fois les étapes visibles, l'expérience est directe : remplacez une étape par un modèle plus petit et réexécutez votre ensemble d'évaluation. Si les scores se maintiennent, les économies sont réelles et permanentes. S'ils chutent, vous avez appris quelque chose de spécifique sur cette étape plutôt que sur la taille du modèle en général.

C'est exactement ce que fait l'Optimizer : optimisation du modèle et des invites, ajustement des outils et conversion hybride, chacun étant mesuré par rapport à vos propres évaluations avant d'être lancé.

Le modèle hybride

La forme qui en résulte généralement est un petit modèle gérant la majorité des marches, un plus grand sur les deux ou trois qui en ont besoin, et une décision de routage entre elles qui est elle-même bon marché.

Les équipes y parviennent par mesure plutôt que par conception, ce qui est le bon ordre. Concevoir un système hybride avant de savoir quelles étapes nécessitent des capacités produit un système complexe optimisé pour une estimation.

Le piège

Une réduction des coûts sans évaluation n’est pas une économie, c’est un report. Une étape moins coûteuse mais subtilement pire produit des défaillances plus en aval, là où leur diagnostic est plus coûteux que l’argent économisé.

C'est pourquoi chaque optimisation proposée doit être évaluée en fonction des critères que vous avez écrits avant de commencer l'optimisation.

Suivant

Les pages Optimiseur et Surveillance des jetons couvrent l'instrumentation par étape et l'optimisation mesurée par évaluation. La page des versions couvre chaque version d'Oran et ce qu'elle a ajouté.