Comment choisir un modèle d’IA local à partir de vos propres tâches

La bonne question n’est pas de savoir quel modèle est le meilleur en général

Si vous avez plusieurs modèles locaux parmi lesquels choisir, un score publié ou une démonstration convaincante ne suffit pas pour savoir lequel vous sera utile dans votre flux de travail. La question pertinente est plus précise : lequel de ces modèles accomplit de manière acceptable la tâche que vous voulez réellement lui confier, avec l’équipement et la configuration que vous comptez utiliser ?

Un test d’acceptation répond à cette question à l’aide d’un petit ensemble de tâches réelles ou représentatives, de critères définis avant de voir les réponses et de conditions d’exécution comparables. Par exemple, une équipe qui souhaite classer des demandes peut vérifier si chaque modèle attribue la bonne catégorie et fournit un résultat exploitable par son système. L’évaluation ne consiste pas à choisir la réponse qui semble la mieux formulée, mais à vérifier des exigences observables.

Un petit échantillon ne permet pas d’établir un classement général des modèles. Il peut révéler des incompatibilités pratiques — comme le non-respect d’un format ou des erreurs sur un type d’entrée fréquent —, mais ne démontre pas que le modèle retenu sera fiable pour d’autres tâches, avec d’autres utilisateurs ou sur un autre matériel. La conclusion doit rester limitée à ce qui a été testé.

L’objectif diffère également de celui d’une comparaison des niveaux de quantification : pour ce test, mieux vaut garder la configuration pertinente fixe au lieu de choisir entre 4, 6 ou 8 bits. Ce n’est pas non plus un test de concurrence, qui porte sur le traitement de requêtes simultanées, ni un audit de confidentialité, qui examine le trafic réseau. Si l’une de ces questions est déterminante, elle nécessite une évaluation distincte.

Commencez par définir la tâche et le seuil d’acceptation

Avant de télécharger des modèles candidats, décrivez le travail que vous souhaitez leur confier. Évitez les objectifs vagues comme « bien répondre » ou « être intelligent ». Précisez ce que le modèle reçoit, le résultat attendu et les erreurs qui rendraient ce résultat inutilisable. Plus cette description ressemble à une tâche réelle de votre flux de travail, plus il sera facile de concevoir des exemples qui distinguent les candidats.

Définissez aussi ce que signifie « acceptable ». Un brouillon peut être utile même s’il nécessite une révision ; une extraction de données intégrée automatiquement à une base de données peut, elle, devoir fournir tous les champs et respecter un format valide pour chaque cas critique. Ces choix reviennent à l’équipe : ils ne constituent pas des propriétés universelles d’un modèle. Écrivez-les avant de comparer les réponses afin d’éviter de modifier les critères en faveur d’un candidat.

Distinguez les critères qui décrivent des résultats différents. L’exactitude du contenu, le respect des consignes et la validité du format ne sont pas interchangeables. Une réponse peut être exacte tout en ne respectant pas le schéma demandé ; une autre peut adopter le format parfait tout en contenant une donnée erronée. Les fondre dans une seule note sans explication fait perdre des informations susceptibles de modifier votre décision.

Si plusieurs personnes évaluent les réponses, convenez à l’avance de la façon de trancher les désaccords. Pour les tâches subjectives, il est utile que deux évaluateurs notent séparément au moins une partie des exemples, puis comparent leurs justifications. En cas de désaccord, notez la règle qui manquait de clarté et précisez-la avant d’interpréter de petits écarts entre les modèles. Inutile de faire passer une préférence de style pour une vérité objective.

Choisissez les candidats et fixez les conditions

Comparez des candidats adaptés au même usage. Pour chacun, consignez l’identifiant exact et la version disponible du modèle, ainsi que le moteur d’exécution, l’équipement, l’environnement d’exécution et les paramètres pertinents. Sans ces informations, une différence observée peut venir de l’environnement plutôt que du modèle, et une autre personne aura du mal à reproduire le test.

Gardez identiques les conditions que vous pouvez maîtriser : matériel, moteur d’exécution et version, consignes, exemples d’entrée, limite de contexte, paramètres de génération et traitement de la sortie. Si un modèle nécessite une configuration différente pour démarrer, documentez cette exception et demandez-vous si la comparaison répond toujours à la même question. Ne modifiez pas les paramètres en cours de test pour améliorer les réponses d’un favori sans relancer les autres dans des conditions équivalentes.

Pour les modèles génératifs dont les sorties peuvent varier d’une exécution à l’autre, consignez aussi les paramètres qui influencent la génération et répétez certains cas. Une répétition ne supprime pas toute incertitude, mais elle peut montrer que le résultat repose sur une sortie particulièrement favorable. La documentation d’Ollama, par exemple, décrit des paramètres de génération configurables dans son format Modelfile ; vérifiez dans la documentation actuelle du moteur utilisé quels paramètres sont disponibles et ce qu’ils signifient.

Les relevés de mémoire et de latence doivent décrire la méthode, pas seulement donner un chiffre. Indiquez l’opération mesurée, l’outil utilisé, le nombre de répétitions et si le système effectuait d’autres tâches. Une mesure locale peut aider à prendre une décision sur cet équipement, mais elle ne se transpose pas automatiquement à un autre appareil.

Constituez un petit ensemble représentatif du travail

Ne choisissez pas seulement des exemples faciles ni des cas dont vous vous souvenez parce qu’un candidat les avait bien traités. Rassemblez des entrées typiques de l’usage prévu et ajoutez des situations susceptibles de poser problème. L’échantillon initial peut être réduit si chaque cas a un objectif explicite ; l’essentiel est de ne pas le présenter comme une représentation statistique de l’ensemble du travail.

Incluez au moins trois types d’entrées : les cas courants, les cas limites et les cas où le modèle devrait reconnaître que les informations disponibles ne suffisent pas. Si la tâche dépend de consignes de format, ajoutez des exemples qui permettent de vérifier leur respect. Si elle s’appuie sur le contenu fourni par l’utilisateur, vérifiez que le modèle s’en tient à ce contenu au lieu de combler les lacunes par des suppositions.

Préparez une réponse attendue ou un guide d’évaluation pour chaque exemple avant de lancer les modèles. Il n’est pas toujours nécessaire de fixer une seule phrase comme réponse correcte : pour un résumé, il peut être plus pertinent d’énumérer les faits à reprendre et les affirmations à ne pas ajouter. Pour une extraction structurée, en revanche, il peut exister des valeurs précises et un format attendu.

Veillez à la qualité de l’ensemble. N’incluez pas d’informations confidentielles si elles ne sont pas nécessaires, supprimez les identifiants personnels qui ne font pas partie du cas et conservez les entrées de façon à ce que les évaluateurs sachent quelles informations étaient disponibles. Si vous modifiez un exemple après avoir observé les résultats, identifiez-le comme une nouvelle version ; ne mélangez pas silencieusement le test initial et sa version révisée.

Évaluez séparément les dimensions et consignez les erreurs

Une grille pratique distingue au minimum l’exactitude pour la tâche, le respect des consignes, l’utilité du format et les erreurs critiques. Définissez ce qui constitue une erreur critique pour l’usage prévu : par exemple, une extraction erronée traitée sans vérification peut avoir un coût différent d’une phrase peu élégante dans un brouillon. Une liste générique de risques ne remplace pas la définition des besoins de votre équipe.

En plus de la qualité du résultat, mesurez séparément la latence et la mémoire observée. Ces dimensions répondent à des questions différentes : le résultat est-il utile, combien de temps prend-il selon la méthode retenue, et quelles ressources le système a-t-il semblé consommer pendant cette exécution ? Évitez de les fusionner dans une note unique, sauf si vous expliquez comment les pondérations ont été choisies et en quoi elles répondent à un besoin réel. Il est souvent plus utile de présenter un tableau par dimension et de discuter des compromis.

Pour chaque échec, consignez le cas, la réponse, le critère non respecté et le niveau de gravité attribué. Regroupez les erreurs par type — omission, donnée inventée, format invalide ou consigne ignorée, par exemple — si ces catégories correspondent à votre tâche. Vous pourrez ainsi distinguer un problème récurrent d’une erreur isolée. Ne masquez pas un échec critique derrière une moyenne élevée obtenue sur des cas faciles.

Les mesures de performance nécessitent une note méthodologique. L’outil llama-bench de llama.cpp documente les répétitions et des statistiques comme la moyenne et l’écart type, ainsi que des mesures distinctes pour le traitement du prompt et la génération. Il précise également les limites de ce qui est inclus dans ses mesures. C’est pourquoi il convient de décrire exactement ce qui a été mesuré, plutôt que de traiter n’importe quel chiffre comme une mesure universelle de vitesse.

Exécutez le test, examinez les résultats et prenez une décision limitée

Exécutez chaque cas avec le même prompt et les mêmes conditions documentées. Conservez les sorties originales, y compris les réponses défectueuses : modifier ou écarter une réponse avant de l’évaluer rend le test moins reproductible. Si les résultats varient, répétez les cas choisis selon une procédure définie et gardez chaque sortie, et pas seulement celle qui vous semble la plus représentative.

Pour réduire les biais, évaluez si possible les réponses sans afficher le nom du modèle. Si vous ne pouvez pas le masquer, appliquez au moins la même grille à tous les candidats et consignez les désaccords. Lors d’une évaluation humaine, des critères explicites et, si possible, plusieurs évaluateurs aident à repérer les jugements subjectifs. Si vous indiquez le degré d’accord entre évaluateurs, expliquez ce qui a été comparé et comment les divergences ont été tranchées.

Une fois le test terminé, décidez pour chaque candidat s’il faut l’adopter pour un usage limité, le modifier puis le tester de nouveau, ou l’écarter. Toute modification change les conditions du test : conservez la version précédente et relancez la comparaison dans des conditions comparables. Le choix peut dépendre d’une exigence éliminatoire — par exemple, la validité de tous les champs obligatoires — et non du candidat qui obtient le meilleur score global.

Une décision responsable peut aussi être : « aucun ne satisfait aux critères ». Si les erreurs touchent à des exigences essentielles, rien ne vous oblige à retenir le moins mauvais pour clore la comparaison. Même si un candidat semble convenir, la conclusion demeure provisoire et limitée aux exemples, à la configuration et à l’équipement testés.

Limites, maintenance et ressources complémentaires

Un petit test est exposé au biais de sélection : les exemples peuvent favoriser un style de rédaction, un domaine ou un type d’entrée. Le résultat dépend aussi du prompt et de la configuration. Indiquez les cas utilisés, les critères appliqués et les conditions d’exécution ; n’extrapolez pas le résultat à d’autres tâches, versions, équipements ou groupes d’utilisateurs sans éléments supplémentaires.

Revoyez le test si l’usage évolue. L’ajout d’une nouvelle source de données, une modification du format d’entrée ou l’automatisation d’une réponse auparavant relue par une personne peuvent changer l’importance des erreurs. Conservez des versions du jeu d’exemples et de la grille afin de pouvoir interpréter les comparaisons ultérieures. Un ancien score ne garantit pas que le comportement reste acceptable après une modification du système.

Les outils d’évaluation peuvent aider à organiser les tâches et les métriques, mais ils ne déterminent pas ce que signifie la réussite dans votre situation. Le projet lm-evaluation-harness documente des tâches, des métriques, des prompts personnalisés et l’évaluation locale. Il peut servir de référence ou d’outil s’il répond à votre besoin, mais le score obtenu avec une tâche standard ne remplace pas vos propres exemples et ne prouve pas que le modèle respecte vos exigences.

Ce guide porte sur l’acceptation ou le rejet de candidats pour une tâche précise. Pour approfondir, consultez le guide sur les modèles locaux, le comparateur et l’espace de découverte. Si votre prochaine question concerne la quantification, la concurrence ou la confidentialité, traitez-la comme une décision séparée : changer d’objectif sans adapter aussi le protocole risque de rendre la comparaison incapable de répondre à la question initiale.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.