Choisir un modèle de fondation

Le domaine précédent vous a déjà appris à choisir un modèle : éliminer sur les contraintes dures, évaluer les survivants sur votre propre tâche, puis optimiser ceux qui passent pour le coût et la latence. Cette méthode est l'ordre des opérations. Cette leçon est la liste de contrôle sur laquelle elle s'applique.

Le guide de l'examen, dans l'objectif 3.1, nomme un ensemble précis de critères pour choisir un modèle de fondation pré-entraîné : « coût, modalité, latence, multilingue, taille du modèle, complexité du modèle, personnalisation, et longueur d'entrée/sortie ». Chacun pose un genre de question différent, et chacun porte une conséquence de conception que vous ressentez plus tard si vous le sautez. Une question sur ce thème cache en général l'un de ces critères dans la formulation du scénario et fait de la réponse tentante le modèle qui gagnerait si cette phrase n'était pas là. La compétence utile est donc de reconnaître quel critère un scénario teste vraiment.

Nous les parcourons dans l'ordre où ils mordent, pas dans l'ordre où le guide les liste.

La modalité : ce qui entre, ce qui sort

La modalité est le genre de données qu'un modèle accepte et produit. Un modèle de texte lit et écrit du texte. Un modèle multimodal accepte images, audio ou vidéo avec le texte. Un modèle d'embedding renvoie des vecteurs plutôt que de la prose. Un modèle de génération d'images produit des images à partir d'une description.

Ces catégories ne sont pas interchangeables, et aucun autre critère ne rattrape un décalage de modalité. Un modèle texte seul ne lit pas une facture scannée, ne transcrit pas un appel et ne décrit pas une photo, et le fine-tuning n'ajoute pas un type d'entrée. C'est pourquoi la modalité est la première chose à vérifier : elle élimine des candidats d'emblée, avant même que la qualité soit sur la table.

C'est aussi le critère que l'examen déguise le plus souvent. Un scénario mentionne des documents scannés, des photos de produit ou des enregistrements audio, puis propose un modèle texte seul comme l'option aux meilleurs scores. Les scores sont une diversion. Lisez le scénario pour ce que l'entrée est réellement avant de lire les capacités du modèle.

La longueur d'entrée et de sortie : deux limites, pas une

Chaque modèle publie deux limites de longueur, et les confondre est un moyen fiable de livrer une fonction cassée.

La fenêtre de contexte est le nombre maximal de tokens que le modèle peut prendre en compte dans une seule requête. Tout y compte : vos instructions, les documents récupérés, la conversation jusqu'ici, et la question de l'utilisateur. La longueur de sortie maximale est un plafond distinct sur le nombre de tokens que le modèle peut générer dans une réponse, et il est en général bien plus petit que la fenêtre de contexte.

L'écart entre les deux est plus grand qu'on ne l'imagine. Un modèle peut publier une fenêtre de contexte de 200 000 tokens avec une sortie maximale de quelques milliers de tokens seulement. Cette combinaison lit confortablement un très long document mais ne peut pas en écrire un. Une équipe qui lit « 200 000 tokens » et prévoit de générer un rapport complet en un appel obtient une réponse qui s'arrête au milieu, et rien dans l'erreur n'explique pourquoi.

La question de conception se scinde donc en deux. Combien une seule requête doit-elle prendre en entrée, ce qui fixe le plancher de fenêtre de contexte, et quelle longueur la réponse doit-elle atteindre, ce qui fixe le plancher de longueur de sortie. Une fonction de résumé est lourde en entrée et légère en sortie. Une fonction de rédaction longue est l'inverse. Alignez le modèle sur le sens vers lequel votre charge de travail penche.

Le support multilingue

Un modèle entraîné surtout en anglais produira quand même de l'espagnol ou de l'arabe quand on le lui demande, mais souvent avec une grammaire plus faible, un vocabulaire plus mince et plus d'erreurs qu'en anglais. La capacité générale ne se transfère pas uniformément d'une langue à l'autre, et c'est pourquoi le guide liste le support multilingue comme critère à part plutôt que de le fondre dans l'exactitude.

La conséquence est pratique. Si vos utilisateurs écrivent en portugais et lisent les réponses en portugais, un modèle qui domine les benchmarks anglais mais trébuche en portugais est le mauvais choix, et vous ne voyez le problème qu'en testant dans la langue que vos utilisateurs emploient réellement. Quand un scénario nomme un public non anglophone ou une exigence multilingue, ce critère passe au premier plan.

La taille et la complexité du modèle

Le guide liste la taille du modèle et la complexité du modèle comme deux critères, et ils désignent le même arbitrage sous deux angles. La taille renvoie au nombre de paramètres. La complexité renvoie à la capacité que cela achète et à ce qu'il en coûte de la faire tourner.

L'instinct que presque tout le monde apporte est qu'un plus gros modèle est un choix plus sûr. Il ne l'est pas, et l'examen récompense de savoir pourquoi. Un modèle plus grand coûte plus au token, génère plus lentement parce qu'il fait plus de travail par token, et n'apporte souvent aucune amélioration mesurable sur une tâche étroite et bien spécifiée. Un classifieur qui trie des tickets de support en huit catégories n'a pas besoin d'un raisonnement de pointe. Payer une capacité que la tâche ne sollicite jamais est un gaspillage qui se répète sur chaque requête, indéfiniment.

Le schéma qui tient en pratique est de commencer par un modèle plus petit et de monter seulement quand votre évaluation révèle un écart réel. Les équipes qui démarrent au sommet redescendent rarement, parce que personne ne se porte volontaire pour rendre l'assistant légèrement moins bon afin d'économiser, donc le surcoût devient permanent. Quand un scénario vous donne un budget de latence serré ou une tâche simple et bornée et propose un grand modèle comme option, le plus petit modèle qui passe encore est en général la réponse attendue.

Le support de personnalisation

Si votre plan dépend d'adapter le modèle, que ce soit en le fine-tunant sur vos exemples ou en l'ancrant dans vos données, vous devez confirmer que le modèle prend ce chemin en charge avant de vous engager sur lui. Tous les modèles ne peuvent pas être fine-tunés, et ceux qui le peuvent diffèrent par les méthodes qu'ils acceptent et le format de données qu'ils attendent.

C'est un critère de sélection précisément parce que découvrir la limite tard coûte cher. Une équipe qui choisit un modèle sur la seule qualité, construit autour de lui, puis apprend qu'il ne peut pas être fine-tuné de la façon dont son cas d'usage a besoin doit recommencer la sélection. Les arbitrages de personnalisation eux-mêmes font l'objet d'une leçon plus loin dans ce thème. Ici, le point est plus étroit : si la personnalisation fait partie du plan, elle fait partie de la sélection.

La latence et le coût

Ce sont les deux critères que vous optimisez une fois qu'un modèle a franchi tout ce qui précède, et les leçons antérieures les ont couverts en profondeur, donc nous restons brefs.

La latence est la vitesse à laquelle le modèle répond. Les modèles plus gros sont plus lents, et la génération est séquentielle, donc une longue réponse d'un grand modèle peut prendre plusieurs secondes. Une expérience de chat en direct a un budget de latence ; un traitement par lots nocturne, en général non. Vérifiez qu'un modèle tient le budget avant de bâtir une fonction en temps réel dessus, plutôt qu'espérer combler l'écart après coup.

Le coût dépend surtout du choix du modèle, plus que de toute optimisation de prompt. La même charge de travail peut varier de plusieurs ordres de grandeur entre deux modèles de la même famille. Parmi les modèles qui passent tous les autres filtres, le plus rapide et le moins cher qui atteint encore votre barre de qualité est le bon choix.

Les critères en un coup d'œil

Conseils pour l'examen

• Mémorisez la liste nommée : coût, modalité, latence, multilingue, taille du modèle, complexité du modèle, personnalisation, longueur d'entrée et de sortie. Puis, pour chaque scénario, trouvez lequel fait le travail de décision.
• La modalité est le filtre caché le plus fréquent. Une entrée non textuelle dans le scénario plus un modèle texte seul dans les options veut dire que cette option est fausse, quels que soient ses scores.
• La longueur d'entrée et la longueur de sortie sont deux limites distinctes. Une grande fenêtre de contexte ne promet pas une réponse longue. Guettez un scénario qui exige une génération longue et un modèle au plafond de sortie petit.
• Le support multilingue surgit quand le public est nommé comme non anglophone. Les scores généraux de benchmark ne tranchent pas la question.
• La complexité du modèle est un arbitrage, pas un objectif. Une latence serrée ou une tâche étroite pointe vers le plus petit modèle qui passe encore.
• Le support de personnalisation se vérifie avant la sélection, pas après. Si le plan dit fine-tuner, confirmez que le modèle peut l'être.

La règle à emporter en question : lisez d'abord pour trouver la contrainte, puis associez-la à l'un des huit critères. La plupart des scénarios de choix de modèle se décident sur une seule phrase. La leçon suivante passe du choix du modèle au contrôle de sa réponse, avec les paramètres d'inférence que vous fixez sur chaque requête.