Votre prototype fonctionne sur certains exemples, mais l'équipe ne sait pas s'il est prêt pour une diffusion plus large. inAi peut évaluer le système et réaliser un programme défini de préparation à la production.
Il s'agit d'une mission d'ingénierie délimitée, pas d'une certification ni d'une promesse de supprimer toutes les erreurs.
Partir de l'usage attendu
Décrire les utilisateurs, les tâches, les données, les conséquences d'un résultat incorrect et la charge prévue. Examiner l'implémentation, les tests et les incidents connus.
Distinguer l'incertitude produit, les problèmes de données, le comportement du modèle et les défauts logiciels classiques. Ils ne se corrigent pas nécessairement de la même manière.
Construire une évaluation représentative
Créer un jeu de tests versionné couvrant les tâches fréquentes et les exceptions importantes. Définir les critères, les évaluateurs et les éléments justifiant chaque décision. Inclure, selon le projet, les questions sans réponse, les entrées invalides, les permissions, les fournisseurs indisponibles et les sources modifiées.
Examiner séparément la réussite de la tâche, les sources, la validité du format, les accès, la latence et les coûts d'exploitation. Un score global peut masquer une faiblesse importante.
Transformer les constats en travaux
L'évaluation peut conduire à améliorer la recherche, les validations, les prompts, les modèles, la revue utilisateur, les relances, les délais d'expiration, le déploiement, la supervision ou le support. Tous les échecs ne nécessitent pas de changer de modèle.
Les livrables peuvent comprendre un rapport, une liste de travaux priorisée, les données et scripts d'évaluation, les tests de non-régression, les corrections et une recommandation de lancement au regard des critères convenus.
Contrôler les évolutions
Préciser les tests à exécuter avant de modifier un prompt, un modèle, un corpus ou une intégration. Conserver les versions utiles pour analyser une régression plutôt que comparer deux démonstrations non documentées.
Prévoir un retour arrière ou une désactivation et désigner le responsable d'exploitation. Le système doit rester gérable après la réunion de lancement.
Présenter les résultats sans les exagérer
Indiquer la population testée, la configuration, la date et les limites. Un taux observé sur un jeu de données renseigne sur ce jeu et cette configuration ; il ne constitue pas une garantie universelle.
Si une exigence importante n'est pas satisfaite, la recommandation peut être de réduire le périmètre, de maintenir une validation humaine ou de différer une fonction, sans nécessairement bloquer le reste.
Les éléments à fournir
Une vue d'architecture, un environnement de test, des entrées représentatives, des exemples d'échec, les journaux partageables et la décision de lancement à prendre.