Choisir un modèle d’IA pour une application réelle

Exigences

Transformer le parcours produit en contrat de sélection

Le point de départ est l’unité de comportement promise par le produit. Il faut décrire l’entrée réelle, le contrat de sortie, la personne ou le système qui agit et les preuves nécessaires. Tout le chemin autour du modèle compte: recherche documentaire, assemblage du contexte, outils, validation, revue humaine et écriture en aval. Un modèle choisi pour répondre à des questions isolées peut réagir autrement lorsqu’il doit citer un corpus privé, produire un schéma et appeler un outil restreint. La cible est donc le comportement assemblé et non un score abstrait d’intelligence.

Les contraintes éliminatoires sont séparées des préférences négociables. Le traitement des données, la frontière de déploiement, la licence, une erreur irréversible ou une limite contractuelle de latence peuvent exclure un candidat. Un léger gain de qualité ou des consignes plus simples peut être pondéré. Le contrat consigne langues, longueurs, bruit documentaire, concurrence et pointes de charge. Il définit aussi l’abstention et la personne autorisée à outrepasser le système. La comparaison ne change ainsi pas de cible dès qu’un exemple avantage un candidat.

Preuves

Comparer les candidats dans le même système représentatif

Le corpus vient de cas proches de la production et non de démonstrations favorables. Il contient le volume courant, des situations difficiles, des demandes hors périmètre, des contenus mal formés et des cas où une erreur assurée a de fortes conséquences. Il est segmenté par langue, source, complexité, groupe d’utilisateurs et impact. Les jugements de référence et consignes de revue sont explicites. Des tests déterministes vérifient le schéma, les citations, les permissions et actions interdites. Des spécialistes jugent l’utilité ou l’exactitude. Leur accord indique si le barème lui-même est stable.

Tous les candidats passent dans le même dispositif versionné. Les consignes système, paramètres de recherche, interfaces d’outils, aléa et validation restent fixes, sauf adaptation légitime et documentée. L’analyse couvre aussi les répétitions, refus, choix d’outils, preuves, latence et corrections. Les cas variables sont répétés et soumis à une concurrence réaliste. Un petit modèle peut gagner lorsque la tâche et la recherche sont bien contraintes. Un grand modèle peut n’être utile que sur une voie experte. L’essai doit révéler une architecture d’exploitation, pas proclamer un modèle universellement supérieur.

• Utiliser des cas proches de la production et conserver les échecs difficiles.
• Mesurer les segments importants séparément de la moyenne.
• Stabiliser le montage applicatif pendant la comparaison.
• Capturer la variance, les actions intermédiaires et la charge de revue.
• Tester le routage et le repli si aucun modèle n’est optimal partout.

Exploitation

Évaluer le flux de données, le service et le coût complet

Il faut tracer ce qui sort de l’application, le lieu de traitement, la conservation autorisée et les opérateurs ou sous-traitants concernés. Les contrôles techniques et engagements contractuels sont deux preuves différentes, à vérifier pour la région et le mode de service prévus. Pour un modèle exploité en interne ou à poids ouverts, il faut examiner licence, provenance, infrastructure, correctifs, accès, supervision et compétences requises. Le contrôle a de la valeur mais exige du travail. Pour un service hébergé, on évalue limites, politique de versions, observabilité, incidents et dépendance aux fonctions propres au fournisseur.

Le coût pertinent est celui d’un résultat accepté, pas celui d’une unité de texte. Il comprend le contexte ajouté par la recherche, les appels répétés, les outils, la validation, les replis, le cache, la revue humaine, l’évaluation continue et le support. Les latences médianes et extrêmes sous charge révèlent si le parcours interactif tient. Il faut aussi chiffrer une acceptation erronée et une escalade inutile. Le routage peut ensuite améliorer l’équilibre: petit modèle pour les cas ordinaires, spécialiste pour les cas difficiles, puis voie déterministe ou humaine lorsque la confiance ou la politique l’exige.

Décision

Choisir de façon réversible et gouverner les changements

Le dossier de décision indique candidats, versions, date, exclusions, critères pondérés, résultats par segment, risques non résolus et avis divergents. La pondération reflète les conséquences sans fabriquer une précision décorative. Le seuil d’une défaillance critique peut l’emporter sur un total élevé. Le portefeuille le plus simple qui respecte le contrat est retenu, avec les conditions de recours à une autre voie. Le pilote observe l’usage réel, les corrections, la latence et les exceptions. Les conditions de retour sont définies avant qu’une démonstration séduisante ne devienne implicitement irréversible.

Le modèle reste une dépendance remplaçable dont le comportement peut évoluer. Les appels passent par une interface applicative, les consignes et cas de test sont versionnés, les versions sont journalisées et les mises à niveau prévues passent une régression. Des groupes témoins et échantillons détectent aussi les changements silencieux. Une solution de secours proportionnée à la criticité est maintenue: autre fournisseur, déploiement à poids ouverts, mode déterministe ou file manuelle. La réversibilité n’impose pas une neutralité artificielle, mais une compréhension explicite des dépendances acceptées.

• Conserver les versions du modèle et de la configuration avec les preuves.
• Faire primer les seuils critiques sur un total pondéré séduisant.
• Observer l’usage et la charge réels pendant le pilote.
• Encapsuler les fonctions propres au fournisseur derrière des limites explicites.
• Tester toute modification importante du modèle, des consignes, des sources ou outils.