Un nouveau modèle d’IA vient de sortir : votre entreprise doit-elle changer ?

Pourquoi est-il tentant de changer tout de suite ?

Les annonces mettent en avant des scores de benchmarks, des baisses de prix et de nouvelles capacités. Elles sont écrites pour tout le monde, pas pour une entreprise qui attend du modèle une tâche bien précise.

Les premiers articles sont aussi souvent contradictoires. Dans les premiers jours, les médias peuvent diverger sur les noms, les versions et la disponibilité. Attendez la documentation du fournisseur lui-même avant de décider quoi que ce soit.

Que peut-il mal se passer quand on change de modèle ?

• Le comportement change. Les mêmes instructions peuvent produire des réponses différentes, un format différent ou un ton différent. Ce qui était fiable peut cesser de l’être.
• Le coût évolue dans les deux sens. Un prix unitaire plus bas ne sert à rien si le nouveau modèle rédige des réponses plus longues ou nécessite davantage de tentatives.
• La rapidité change. C’est surtout important lorsqu’un client attend la réponse.
• Les conditions relatives aux données diffèrent. Le lieu de traitement des données, leur durée de conservation et leur utilisation éventuelle pour l’entraînement sont fixés par les conditions du fournisseur. Vérifiez-les avant d’envoyer des données clients à un nouveau modèle ou à un nouveau fournisseur.
• D’autres parties du code dépendent de la sortie. Si un système lit la réponse, par exemple sous forme de données structurées, un petit changement de format peut le casser.
• Les modèles sont retirés. Les fournisseurs retirent leurs anciens modèles selon leur propre calendrier : celui que vous utilisez aujourd’hui ne durera pas éternellement.

Comment tester équitablement un nouveau modèle ?

1. Rassemblez des exemples réels. Réunissez quelques dizaines de tâches typiques tirées de votre propre activité, sans données personnelles, et notez à quoi ressemble une bonne réponse.
2. Faites tourner les deux modèles sur le même ensemble. Utilisez les mêmes instructions et les mêmes entrées pour le modèle actuel et le nouveau.
3. Évaluez ce qui compte pour vous. Exactitude, format, ton, refus, temps de traitement et coût par tâche.
4. Faites relire les résultats par quelqu’un qui connaît le métier. Regardez les pires réponses, pas seulement la moyenne.
5. Comparez le coût par réponse correcte. Pas la grille tarifaire.

Si vous ne pouvez pas faire cela, vous n’avez pas encore les moyens de savoir si un nouveau modèle est meilleur pour vous. Constituer cet ensemble de tests est la chose la plus utile à faire en premier, et il pourra resservir à chaque nouveau modèle.

Faut-il épingler une version ?

Si le fournisseur le permet, oui. Indiquez une version précise du modèle en production pour que son comportement ne change pas à votre insu, et fixez une date pour la réexaminer. L’épinglage permet de choisir quand vous changez, pas d’éviter de changer.

Que demander à votre prestataire ou à vos développeurs ?

• Quel modèle et quelle version utilisons-nous aujourd’hui ?
• De quel ensemble de tests disposons-nous, et quand a-t-il été exécuté pour la dernière fois ?
• Que se passe-t-il si le fournisseur modifie ou retire le modèle ?
• Où nos données sont-elles traitées, et combien de temps sont-elles conservées ?
• Pouvons-nous revenir en arrière en une journée si le nouveau modèle se comporte mal ?

Quand le changement en vaut-il la peine ?

Changer vaut généralement l’effort lorsque :

• le nouveau modèle réussit une tâche importante que l’actuel échoue ;
• le coût par tâche baisse d’un montant qui justifie le travail de migration ;
• la rapidité compte et le nouveau modèle est nettement plus rapide ;
• le modèle actuel est sur le point d’être retiré.

Cela n’en vaut généralement pas la peine lorsque la configuration actuelle fonctionne, que personne ne se plaint et qu’aucun test ne montre ce qui s’améliorerait.

Comment faciliter les changements futurs ?

Placez le modèle derrière une fine couche d’abstraction dans votre logiciel, afin qu’en changer soit une question de paramètre et non de réécriture. Conservez vos instructions et vos exemples de test avec le code, et notez quel modèle utilise chaque fonctionnalité. Évitez de développer des fonctionnalités qui ne marchent qu’avec les options spécifiques d’un seul fournisseur, sauf si le gain est évident.

Si vous vous demandez encore quelle place l’IA peut avoir dans votre entreprise, lisez quand une entreprise a réellement besoin de développement IA et ce que les chatbots IA peuvent et ne peuvent pas faire. Si vous souhaitez de l’aide pour tester des modèles sur votre propre travail ou construire quelque chose que vous pourrez faire évoluer, découvrez nos Services de développement IA ou contactez-nous.