Sélection de modèle : le bon modèle pour le bon travail

Gains :

• Peut comparer la famille de modèles (rapide/équilibrée/puissante) en termes de capacité, de vitesse et de coût
• Conçoit des stratégies de sélection de modèles et de routage en fonction de la complexité des tâches
• Base la sélection du modèle sur des preuves avec un petit ensemble d'évaluations

La seule décision qui détermine le meilleur rapport qualité-prix et la qualité de l'intégration LLM est le modèle que vous utilisez. Le réflexe commun est de « choisir le modèle le plus solide » ; Cependant, cela entraîne souvent des coûts et des retards inutiles. La bonne approche consiste à choisir le modèle le plus léger qui accomplit chaque tâche et à fonder ce choix sur des mesures et non sur des conjectures. Dans cette unité, vous comparerez la famille de modèles sur l'axe capacité/vitesse/coût, établirez une stratégie de routage du modèle en fonction de la complexité de la tâche et prouverez la sélection avec un petit ensemble d'évaluations.

Comprendre la famille modèle

Les fournisseurs proposent généralement trois classes : rapide/bon marché, stable et puissant. La relation entre eux se résume sur trois axes : capacité (pouvoir de résoudre des tâches difficiles), rapidité (latence), coût (prix symbolique).

classe

exemple

talent

vitesse

Coût

Tâches disponibles

rapide

Haïku 4.5

moyen

très élevé

faible

Classification, étiquetage, résumé, orientation

équilibré

sonnet 5

haut

haut

moyen

Usage général, codage, flux en plusieurs étapes, la plupart des agents travaillent

fort

Opus 4.8

le plus élevé

moyen

haut

Raisonnement complexe, tâches autonomes à longue portée, analyse difficile

Aperçu critique : le modèle le plus puissant n’est pas plus performant à chaque tâche. Dans un simple étiquetage « urgent ou non », le modèle fort et le modèle rapide donnent la même réponse correcte ; la seule différence est que le puissant est 5 fois plus cher et plus lent. Un talent supplémentaire ne produit de la valeur que lorsque la mission l'exige.

Étape par étape : Comment choisir un modèle ?

1. Classez la tâche. Est-ce une routine/un modèle (étiquetage, inférence) ou une approche ouverte/en plusieurs étapes (analyse, planification, code) ?
2. Commencez par le candidat le plus léger. Essayez-le avec le modèle rapide. Si cela suffit, arrêtez.
3. Si cela ne suffit pas, passez à une classe supérieure. Si la précision est faible, optez pour la précision équilibrée, si cela ne suffit pas, optez pour la précision forte.
4. Mesurez, ne devinez pas. Comparez la précision et le coût de chaque candidat avec un petit ensemble d'évaluations (ci-dessous).
5. Configurez la redirection. Au lieu de vous connecter à un seul modèle, répartissez la tâche sur le bon modèle avec un « routeur ».

Routage du modèle

Les charges de travail réelles sont mixtes : la plupart des demandes entrantes sont simples, certaines sont difficiles. C'est du gaspillage de tous les envoyer vers le modèle puissant ; Les envoyer tous vers le modèle rapide réduit la qualité. Le routage résout ce problème : un modèle bon marché (ou une règle simple) classe d'abord la tâche, puis la tâche est transférée au modèle approprié.

# Invite du routeur (fonctionne avec un modèle bon marché) Classez la requête entrante en fonction de sa difficulté. Renvoie uniquement le JSON suivant :{"difficulty": "simple|complex"}Simple : une seule étape, une formule, une réponse courte. Complexe : nécessitant un raisonnement, une analyse ou une génération longue en plusieurs étapes.Requête : """{{request}}"""

• allez au modèle simple → rapide (pas cher, rapide).
• aller au modèle complexe → puissant (coûteux mais nécessaire).

Ce modèle réduit considérablement le coût moyen car la majeure partie du trafic est généralement simple.

Astuce : Une décision de référence ne nécessite pas toujours un LLM. Des règles simples telles que « Passer au modèle rapide si le texte fait moins de 20 mots » sont également un guide et n'entraînent aucun coût supplémentaire en jeton. Essayez d'abord la règle.

Lier le choix aux données probantes : le petit cluster d'évaluation

Ne choisissez pas un modèle basé sur « ça me semble mieux ». Eval (ensemble d'évaluation) est un petit ensemble d'échantillons pour lesquels la bonne réponse est connue ; vous exécutez chaque modèle sur cet ensemble et mesurez la précision, le coût et la latence.

# Modèle de configuration d'évaluation1) Collectez 20 à 50 exemples réels, écrivez à la main la « bonne réponse » sur chacun.2) Exécutez chaque modèle (rapide/équilibré/fort) sur cet ensemble.3) Pour chaque modèle : nombre de corrections, jetons de débit moyen, coût par requête, temps moyen.4) Choisissez le modèle qui « donne une précision suffisante le moins cher ».

# Tableau de comparaison d'évaluation (remplir)Modèle | Précision | Coût par demande | Durée moyenneHaiku | ...% | ... $ | ... snSonnet | ...% | ... $ | ... snOpus | ...% | ... $ | ...sec

Invite faible/Invite forte (décision de sélection du modèle)

# FAIBLE (aucune base de décision)Utilisons le meilleur modèle, le budget n'est pas important.

# FORT (décision basée sur la mesure) Lors de l'évaluation de 50 échantillons, Haiku a donné une précision de 96 %, Sonnet a donné une précision de 97 % ; La différence est statistiquement insignifiante. Le haïku a été choisi car il est 5 fois moins cher et 2 fois plus rapide. Si la précision descend en dessous de 95 %, la décision de passer à Sonnet sera prise automatiquement.

Version puissante ; lie la sélection à un nombre, un seuil et une règle d'escalade. Cela défend à la fois la décision d’aujourd’hui et gère les changements futurs.

Trois mini-étuis

Cas 1 — Échapper au modèle écrasant. Un centre d'appels produisait tous les résumés des conversations avec Opus ; la facture mensuelle était élevée. Lors d'une évaluation sur 40 échantillons, Sonnet était 1 % derrière Opus en termes de précision, mais coûtait un tiers. Ils transférèrent l'ouvrage de synthèse dans le Sonnet ; le coût mensuel est passé de 9 000 $ à 3 100 $, sans aucune plainte en matière de qualité.

Cas 2 — Trafic mixte avec redirection. 80 % des demandes d'une équipe de technologie juridique concernaient un simple balisage de documents, 20 % étaient des analyses de contrats complexes. Ils les envoyaient tous vers le modèle puissant. Ils ont ajouté un routeur bon marché et distribué des tâches simples sur Haiku et des tâches complexes sur Opus ; le coût moyen des demandes a chuté de 64 %, tandis que la qualité de l'analyse a été maintenue.

Cas 3 — Le coût de la réduction des effectifs sans mesure. Pour réduire les coûts, une équipe a réduit l’extraction de codes médicaux complexes directement au modèle rapide ; Ils n'ont pas évalué. En direct, la précision est passée de 92 % à 78 %, ce qui a entraîné un retour d'inférences incorrectes. Ils devaient d’abord procéder à une évaluation : cette tâche nécessitait un modèle puissant. Leçon : la réduction et l'élévation se font par mesure.

Erreurs courantes

• Le réflexe du « modèle le plus fort » : Gaspillage et retards inutiles dans des tâches simples.
• Changer de modèle sans mesurer : La réduction comme l'agrandissement sont risqués sans évaluation.
• S'en tenir à un modèle unique : l'acheminement dans un trafic mixte est souvent plus efficace.
• Il faut toujours confondre le routeur avec le LLM : des règles simples peuvent fonctionner à un coût nul.
• Ne pas définir de seuil de boost : ce qui se passe si la précision diminue doit être défini à l'avance.
• Ne pas corriger la version du modèle : enregistrez le modèle/version sur lequel vous travaillez en production ; Le changement de version peut modifier le comportement.

Plus profond : perpétuer les essais d'évaluation et d'incrémentation

La sélection d’un modèle n’est pas une décision ponctuelle. Les prestataires introduisent de nouveaux modèles, les prix changent, votre description de poste évolue. Alors configurez le cluster d'évaluation une fois et n'oubliez pas : tenez-le comme un être vivant. Lorsqu'un nouveau modèle sort, vous exécutez les mêmes 20 à 50 échantillons, mettez à jour le tableau et prenez à nouveau votre décision. Cela vous protège du piège de « l’intuition de changement de modèle ».

La deuxième technique avancée est le modèle de repli/cascade. Vous confiez d’abord la tâche au modèle bon marché ; Si la sortie a un faible niveau de confiance ou si la couche de vérification (unité 11) la rejette, vous transmettez la même demande. Ainsi, la majeure partie du trafic est résolue sur le modèle bon marché, seule la minorité restante étant dirigée vers le modèle cher. Cette approche est à la fois moins chère et plus durable que l’approche fixe à modèle unique.

Le troisième point est que l’évaluation inclut non seulement la précision, mais également le coût et la latence. Si un modèle est 1 % plus précis mais 3 fois plus cher et 2 fois plus lent, le compromis n'en vaut pas la peine pour la plupart des travaux. Prenez la décision selon trois axes (précision, coût, latence) et définissez un « seuil de suffisance » : « si la précision est supérieure à 95 %, choisissez le moins cher ».

Enfin, enregistrez le modèle/version que vous avez utilisé en production. Si un jour la qualité de sortie change, la première chose que vous examinerez est de savoir si la version du modèle a changé. La traçabilité des versions permet de trouver plus rapidement la cause première des problèmes de qualité.

Encore une mise en garde : le cluster d'évaluation doit représenter votre charge de travail réelle. Une évaluation composée uniquement d'exemples simples cache les points où le modèle trébuche dans les cas difficiles et vous berce dans une fausse confiance. Une bonne évaluation ; Il comprend des exemples simples courants ainsi que des cas particuliers que vous rencontrez dans la réalité (entrées ambiguës, incomplètes et contradictoires). Cette minorité difficile détermine votre choix de modèle, car chaque modèle réussit de toute façon dans la majorité facile. Gardez votre Eval frais et représentatif en lui fournissant périodiquement de nouveaux exemples réels.

En résumé

Le bon modèle est le modèle le plus léger qui fait le travail ; Plus puissant n’est pas meilleur pour tous les travaux, c’est juste plus cher et plus lent. Classer la tâche et commencer par le candidat le plus léger, répartir le trafic mixte avec routage et justifier la sélection avec un petit ensemble d'évaluations réduit le coût plusieurs fois tout en maintenant la qualité.

Tâche de candidature

Choisissez une charge de travail. (1) Classez la tâche comme simple/complexe. (2) Concevoir un petit ensemble d'évaluation de 20 exemples réels (avec leurs réponses correctes). (3) Élaborer un plan pour remplir le tableau de comparaison précision/coût/délai pour les trois classes de modèles. (4) Si vous avez un trafic mixte, rédigez une règle de routage et définissez un seuil d'escalade.

liste de contrôle

• [ ] Je peux comparer la famille de modèles sur l’axe capacité/vitesse/coût.
• [ ] Je peux appliquer le principe du « modèle le plus léger et réussi ».
• [ ] Je peux configurer le routage des modèles en fonction de la complexité des tâches.
• [ ] Avec un petit ensemble d'évaluations, je peux lier la sélection aux preuves.
• [ ] Je peux définir un seuil de surclassement/rétrogradation.