Peut-on changer de fournisseur de modèles d’IA plus tard ? Liste de contrôle pour les applications auto-hébergées

Ce que signifie la portabilité — et ce qu’elle ne signifie pas

La portabilité entre fournisseurs de modèles d’IA désigne ici la possibilité de transférer les tâches d’une application qui reposent sur un modèle vers un autre fournisseur, puis de vérifier que les résultats restent acceptables selon vos critères. Ce n’est pas une propriété tout ou rien : modifier un point de terminaison peut être simple, alors que l’adaptation des prompts, des outils ou de la récupération d’informations peut demander davantage de travail.

Un paramètre qui accepte un autre point de terminaison ou une autre clé d’API ne prouve donc pas, à lui seul, que l’application est portable. Le test utile consiste à examiner les dépendances concernées et à essayer le changement sur des flux de travail représentatifs.

Google Cloud décrit le développement d’applications d’IA comme pouvant inclure un choix entre des modèles gérés et l’utilisation de modèles ouverts apportés par l’équipe. Cette référence étaye ce choix de modèles et de modes d’utilisation, mais ne garantit pas la portabilité entre fournisseurs : [Google Cloud, “Choosing a self-hosted or managed solution for AI app development”](https://cloud.google.com/blog/products/application-development/choosing-a-self-hosted-or-managed-solution-for-ai-app-development).

• Séparez la configuration du point de terminaison de la compatibilité des flux de travail.
• Évaluez les résultats selon les exigences de votre application, sans supposer qu’ils seront identiques d’un fournisseur à l’autre.

Cartographiez les dépendances avant le test

La liste ci-dessous est une démarche générale d’évaluation, et non une garantie technique. Les points à vérifier dépendent de l’application, de sa configuration et de la documentation de ses composants. Pour chaque dépendance, notez où elle est configurée, qui en est responsable et comment vous pourrez la vérifier.

Signalez les éléments impossibles à localiser ou à tester : ce sont des inconnues à résoudre avant de conclure que le changement est faisable.

• Modèles et tâches : identifiants des modèles et flux de travail qui les utilisent.
• Prompts : instructions, modèles de texte, formats attendus et versions.
• Outils : actions externes, arguments attendus et comportement prévu en cas d’échec ou d’utilisation inappropriée.
• Récupération d’informations : modèle d’embedding, préparation du texte, index et base vectorielle, s’il y a lieu.
• Opérations : emplacement des identifiants d’accès, exigences relatives aux données, limites d’utilisation et comportement attendu en cas de défaillance.

Testez la configuration, les prompts et les outils

Suivez le chemin de configuration, depuis les paramètres de l’application ou du déploiement jusqu’aux flux de travail concernés. Vérifiez si le changement de fournisseur nécessite une seule modification ou plusieurs changements distincts. Effectuez le premier essai dans un environnement de préproduction ou une configuration à faible risque, si votre application le permet.

Faites passer les mêmes entrées représentatives dans la configuration actuelle et dans la configuration candidate. Comparez les résultats aux critères définis pour chaque tâche. Pour les flux qui utilisent des outils, vérifiez le parcours complet, notamment l’action demandée, les arguments transmis et la manière dont l’application rend compte du résultat. Ces vérifications sont des recommandations générales : adaptez-les aux comportements pris en charge par votre application.

• Incluez des cas courants, des cas limites et des exemples hors périmètre ; retirez les données sensibles lorsque c’est approprié.
• Vérifiez les champs de sortie et les contraintes de formatage exigés par le flux de travail.
• Examinez les échecs par tâche : un résultat moyen satisfaisant peut masquer un problème important dans un cas particulier.
• Si vous modifiez un prompt, consignez le changement afin de pouvoir distinguer ses effets de ceux du changement de fournisseur.

Évaluez séparément les embeddings et la récupération d’informations

Si l’application utilise la récupération d’informations, vérifiez séparément le modèle d’embedding et la façon dont l’index est créé et interrogé. Ne présumez pas que les vecteurs existants pourront être réutilisés avec une configuration différente : la compatibilité doit être vérifiée pour votre application et ses composants.

Si elle reste incertaine, prévoyez un essai de reconstruction de l’index et vérifiez les résultats de récupération avant tout basculement. Conservez une possibilité de retour à la configuration précédente pendant l’évaluation. Il s’agit de précautions générales à confirmer au regard de la documentation des composants concernés.

• Consignez le modèle d’embedding, la préparation du texte et la segmentation en blocs utilisés.
• Vérifiez la compatibilité de la configuration candidate avec l’index et le processus de récupération existants.
• Testez avec des requêtes représentatives et vérifiez si les éléments attendus sont récupérés.
• Si une reconstruction est nécessaire, définissez comment la réaliser et comment valider le nouvel index.

Définissez des critères d’acceptation et un retour arrière

Un test reproductible est plus utile que quelques exemples marquants. Constituez un jeu réduit d’entrées représentatives et définissez à l’avance ce qui constitue un résultat acceptable ou inacceptable. Incluez les outils et la récupération d’informations lorsque le flux de travail les utilise.

Avant l’essai, enregistrez la configuration d’origine et déterminez comment la rétablir. Après le test, consignez ce qui a été transféré sans modification, les ajustements effectués, les points non vérifiés et les tâches restantes. Élargissez les essais si une défaillance aurait des conséquences importantes.

• Couvrez les tâches courantes et les cas de défaillance connus.
• Comparez les deux configurations selon les mêmes critères propres à votre application.
• Consignez les échecs et les mesures correctives, pas seulement une impression générale.
• Décidez si les lacunes restantes sont acceptables, nécessitent des mesures d’atténuation ou excluent le changement envisagé.

Vérifiez les exigences opérationnelles avant le basculement

Une connexion qui fonctionne techniquement ne suffit pas à décider d’une migration. Vérifiez que l’utilisation du fournisseur candidat respecte les règles et accords applicables aux données concernées. Examinez également qui peut accéder aux identifiants d’accès, comment ils seront modifiés ou révoqués et comment l’équipe suivra les limites d’utilisation pertinentes.

Si vous envisagez une solution de repli, traitez-la comme un choix à tester plutôt que comme une garantie. Définissez les conditions d’activation, les flux de travail concernés et la manière dont vous évaluerez les résultats du système de repli.

• Confirmez que les données concernées peuvent être transmises au fournisseur candidat selon vos règles.
• Documentez la gestion des identifiants d’accès et les personnes autorisées à les modifier.
• Définissez ce que les utilisateurs voient lorsque des requêtes échouent ou sont retardées.
• Testez toute solution de repli prévue avec les critères d’évaluation retenus.