Pourquoi le modèle d’IA le plus capable n’est pas toujours le bon choix pour votre application

Il y a un certain confort à sélectionner le modèle le plus puissant. Lorsque vous construisez un produit alimenté par l’IA, il semble logique de choisir le modèle le plus puissant disponible. GPT-4o. Claude Opus. Gemini Ultra. Ce sont des technologies impressionnantes, et personne ne s’est jamais fait licencier pour avoir choisi l’outil le plus intelligent de la salle.

Excepté, bien sûr, qu’il y a une exception. Les projets gonflent. Les coûts s’envolent. La latence s’installe. Et vers le troisième mois, l’équipe commence à poser des questions inconfortables sur pourquoi une fonctionnalité d’autocomplétion simple brûle les crédits API comme une startup avec un financement par actions et sans responsabilité.

Voici l’essentiel : “le plus capable” et “le plus approprié” sont deux normes très différentes. Les fournisseurs de services de développement d’applications d’IA sélectionnent des modèles en fonction d’évaluations, et non de classements de leaderboard.

Plus grand n’est pas automatiquement mieux

Un modèle de frontière fonctionne de manière extraordinaire dans des conditions idéales, mais coûte cher à exploiter, gère mal les entrées imparfaites et dépasse les exigences pour les tâches simples.

GPT-4o peut écrire de la poésie, raisonner à travers des contrats juridiques, déboguer du code et expliquer l’intrication quantique à un enfant de dix ans, parfois dans la même réponse. C’est vraiment remarquable. Mais si votre application résume des tickets de support client ou extrait des données structurées de factures, vous payez pour des capacités qui ne sont pas utilisées.

Des modèles plus petits et spécialisés gèrent des tâches ciblées avec une précision impressionnante :

• GPT-4o mini couvre la plupart des tâches de langage à un coût environ 15 fois inférieur à celui de GPT-4o
• Claude Haiku est conçu pour la vitesse et l’efficacité sur des charges de travail structurées à haute volumétrie
• Mistral 7B et Llama 3.1 8B sont des options open source qui fonctionnent rapidement et se réglent bien

L’écart entre ces modèles et les modèles de frontière se réduit considérablement lorsque la tâche est étroite et que les invites sont bien conçues.

Les mathématiques de coût que personne ne parle lors des réunions de planification

Les tarifs des API pour les modèles de frontière peuvent aller de 10 à 30 fois plus élevés par jeton que leurs homologues plus légers. Cet écart semble abstrait jusqu’à ce que vous le modélisiez à grande échelle.

Supposons que votre application effectue 500 000 appels API par mois :

Même fonctionnalité. Histoire de marge très différente.

Certaines équipes utilisent des architectures hybrides, acheminant des tâches de classification simples vers des modèles légers tout en réservant les modèles plus lourds pour les étapes de génération ou de raisonnement complexes. Des sociétés comme Martian et RouteLLM ont développé des outils spécifiquement pour ce type de routage de modèle. Ce n’est pas une ingénierie glamour, mais c’est le genre de chose qui rend les directeurs financiers nettement plus détendus.

La latence est un problème d’expérience utilisateur

Il y a une raison pour laquelle la restauration rapide existe. Les gens ne veulent pas toujours un repas à cinq plats. Parfois, ils veulent leur réponse maintenant.

Les modèles de frontière sont plus lents. Pas toujours de beaucoup, mais suffisamment pour compter dans les applications en temps réel. Si vos utilisateurs attendent des réponses d’IA dans une interface de conversation, une interface de chat ou un assistant de codage en direct, la latence de réponse façonne directement la façon dont le produit se sent. Un modèle qui prend 4-6 secondes pour répondre commence à sembler peu fiable, même si la sortie est techniquement supérieure.

La règle empirique : si un utilisateur voit un indicateur de chargement, chaque seconde supplémentaire réduit la confiance.

Haiku, Mistral et Llama 3.1 8B fonctionnent nettement plus vite (parfois 3 à 5 fois plus vite) dans des conditions de charge similaires. Pour les fonctionnalités orientées utilisateur où la vitesse perçue compte, ce n’est pas une considération mineure. C’est une décision de produit.

La variable d’ingénierie d’invite (qui change tout)

Voici quelque chose qui est passé sous silence dans les threads de comparaison de modèles : une invite bien conçue sur un modèle plus petit bat souvent une invite paresseuse sur un modèle de frontière.

La qualité de sortie est un produit de la capacité du modèle ET de la qualité de l’invite. Lorsque les équipes investissent dans l’ingénierie d’invite (instructions claires, formats de sortie structurés, exemples à few-shot, contraintes bien définies) les modèles plus petits fonctionnent loin au-dessus de leur plafond apparent.

Quelques outils à connaître ici :

• LangChain et DSPy pour composer et optimiser les pipelines d’invites
• Guidance pour la génération contrainte et les sorties structurées
• PromptFoo pour exécuter des évaluations d’invites systématiques sur des modèles

Certains des fonctionnalités d’IA les plus impressionnantes en production aujourd’hui fonctionnent sur des modèles qui ne figureraient pas dans les cinq premiers de n’importe quel classement de capacité. Ils fonctionnent simplement sur des invites vraiment bonnes.

Le réglage fin change l’équation

La comparaison entre un modèle de frontière général et un modèle open source plus petit change considérablement une fois que le réglage fin entre en jeu. Un modèle Llama 3.1 8B réglé fin sur vos données de domaine spécifiques (votre terminologie, vos cas de bordure, votre format de sortie préféré) peut surperformer GPT-4o sur votre tâche spécifique.

Ceci n’est pas hypothétique. Des sociétés dans les soins de santé, la technologie juridique et le commerce électronique l’ont démontré à plusieurs reprises.

Où commencer avec le réglage fin :

• Hugging Face pour l’hébergement de modèles open source, les jeux de données et l’infrastructure d’entraînement
• Together AI pour des exécutions de réglage fin rapides et abordables sur des modèles open populaires
• Replicate pour déployer des modèles personnalisés sans gérer votre propre infrastructure GPU

Le réglage fin nécessite un investissement initial : curage de données, temps de calcul et travail d’évaluation. Mais pour des tâches à volume élevé et spécifiques au domaine, l’économie fonctionne souvent considérablement en sa faveur.

La sécurité et la résidence des données ne sont pas des considérations secondaires

Certaines applications ne peuvent pas envoyer de données à des API tierces du tout. Considérez :

• Les plateformes de soins de santé opérant sous HIPAA
• Les outils financiers gérant des informations personnelles ou des données de transaction réglementées
• Les logiciels d’entreprise avec des exigences de résidence de données strictes

Ces environnements ont des contraintes que aucun modèle de frontière API ne peut contourner, quelle que soit sa capacité. Les modèles auto-hébergés, que ce soit sur site ou dans un nuage privé, sont la seule voie à suivre. Cela signifie des modèles open source comme Llama 3, Mistral ou Phi-3 fonctionnant sur votre propre infrastructure. Un modèle de frontière que vous ne pouvez pas utiliser légalement en production n’est pas le bon choix, point final.

L’étape d’évaluation que les équipes sautent toujours

La plupart des équipes sélectionnent un modèle en supposant que le plus coûteux est le meilleur sans le tester. Ce qu’ils devraient faire, c’est exécuter des évaluations structurées sur des échantillons représentatifs de leur cas d’utilisation réel.

Voici un processus qui fonctionne :

1. Construire un ensemble d’évaluation de 100 à 200 entrées représentatives avec des sorties attendues
2. Les exécuter sur deux ou trois modèles candidats dans des conditions réalistes
3. Noter contre vos critères réels : précision, conformité de format, ton, latence, coût par appel
4. Décider sur la base de données, et non de feeling ou de classements de leaderboard

Des outils comme Braintrust, PromptFoo et Weights & Biases Prompts rendent ce type d’évaluation systématique accessible sans un background de recherche. Cela prend quelques heures pour le configurer. Le rendement est de ne pas choisir le mauvais modèle pendant six mois.

Quand le modèle de frontière est vraiment le bon choix

Pour être juste : il y a des tâches où les modèles de frontière gagnent vraiment leur prix.

Utilisez un modèle de frontière lorsque :

• La tâche nécessite un raisonnement complexe, à plusieurs étapes sans modèle clair
• La variance de qualité de sortie est coûteuse et le volume est relativement faible
• Vous avez besoin de connaissances mondiales étendues ou de jugement nuancé qui ne peut pas être contourné par une invite
• Vous êtes en phase de prototypage et n’avez pas encore défini les limites de la tâche

Restez avec un modèle plus léger lorsque :

• La tâche est bien définie et répétitive
• La vitesse et le coût comptent au volume que vous exécutez
• Vous pouvez investir dans l’ingénierie d’invite ou le réglage fin
• Les règles de résidence ou de conformité des données écartent les API tierces

Le but n’est pas d’éviter les modèles puissants. Le but est de choisir délibérément, avec preuves, plutôt que de défaut à la plus grande marque du leaderboard parce que cela semblait le choix sûr.

En résumé

Choisir un modèle d’IA pour votre application ne devrait pas ressembler à une compétition de prestige. Le modèle le plus capable sur le papier n’est pas toujours le bon modèle pour votre problème, ou même généralement.

Assurez-vous que le modèle corresponde à la tâche. Exécutez des évaluations sur des données réelles. Prenez en compte la latence, le coût, les exigences de sécurité et la capacité de votre équipe à effectuer l’ingénierie d’invite ou le réglage fin. Les meilleures décisions de produits d’IA sont ancrées dans ces détails, et non dans la société qui a publié les chiffres les plus impressionnants le trimestre dernier.

Les équipes qui livrent de grands produits d’IA ne courent pas nécessairement les modèles les plus puissants. Ils courent les modèles les plus appropriés.