Une fois le modèle open source restreint, la première chose que l’équipe perd est la possibilité de changer de modèle.

Lorsqu’un modèle commence à être limité, la première chose qui casse n’est généralement pas les résultats d’inférence, mais la capacité de commutation. Le nom de l’interface est toujours là, l’entrepôt est toujours là, mais la chaîne de production d’origine a commencé à rester bloquée sur les quotas, les régions, les invites d’authentification et de conformité. Le vrai problème n’est pas qu’un modèle manque, mais que le chemin d’origine ne convient que pour “continuer à utiliser le modèle d’origine” et ne convient pas pour “passer à un autre ensemble de piles au cours de la même semaine”.

Ce type de changement donne l’impression qu’un fournisseur n’est pas disponible du côté produit, mais constitue en réalité une exposition à une dépendance du côté ingénierie. Les mots d’invite, l’analyse des résultats, le schéma d’appel de fonction, la longueur du contexte long, le budget des jetons, le rythme des nouvelles tentatives et les seuils de contrôle des risques sont tous masqués dans le comportement par défaut du modèle d’origine. Chaque fois que l’objet de remplacement change, ces valeurs par défaut doivent être relues.

Changez de fenêtre pour exposer le problème en premier

Lorsque les limites externes arrivent, il devient souvent clair pour l’équipe que la mesure n’est pas une ligne de score, mais un ensemble d’actions alignées. L’ancien modèle comble les vides de manière très fluide. Le nouveau modèle open source n’est peut-être pas mauvais sur les benchmarks, mais il y aura différents problèmes dans la stabilité JSON, le calibre de rejet et la séquence d’appel des outils. Les bavures ne sont pas grosses lorsqu’elles sont vues individuellement, mais lorsqu’elles sont connectées ensemble, elles peuvent endommager le lien d’automatisation.

Ce qui est encore plus inconfortable, c’est que cette différence ne se produit généralement pas d’un seul coup. La première page semble normale, mais la deuxième page commence à manquer des champs. Un certain appel de fonction nécessite une étape supplémentaire et une certaine nouvelle tentative repousse les anciens résultats dans des conditions limites. Après sa mise en ligne, il porte toujours le même nom de modèle en surface, mais il a en fait été remplacé par une autre distribution de comportement.

Le réalignement est plus lent que le remplacement du modèle

Pour remplacer un modèle, quatre éléments doivent souvent être remplacés en même temps : le format d’entrée, l’acceptation de sortie, le repli des exceptions et les seuils de surveillance. Si vous laissez ces éléments intacts pour le modèle, le résultat sera que le même ensemble de logique métier oscille entre deux distributions de comportement. Les erreurs les plus laides en ligne ne sont généralement pas des échecs complets, mais des succès occasionnels, des champs manquants occasionnels et des explications supplémentaires occasionnelles. Plus tard, le système traite ces coins comme une entrée normale et continue de les transmettre.

C’est pourquoi « pouvoir courir » ne signifie pas « pouvoir migrer ». La valeur du modèle open source réside certes dans sa substituabilité, mais la substitution ne s’arrête pas à l’importance accordée au passé. Tant que les formats de sortie, les appels d’outils et les limites de longueur n’ont pas été resserrés à nouveau, la migration n’est qu’à moitié terminée. Le changement apparent de modèle finira par se transformer en une transformation conjointe des mots d’invite, des analyseurs, des réessayeurs et des chaînes de restauration.

Le chemin de sauvegarde doit être construit selon le chemin officiel.

Si le modèle de sauvegarde n’est placé que dans une certaine section « plan de rétrogradation » du document, il sera presque trop tard au moment de changer. Une approche plus stable consiste à inclure à la fois le modèle principal et le modèle de sauvegarde dans le même ensemble de références : le même lot d’échantillons, le même ensemble d’indicateurs, la même version de l’analyseur et la même chaîne de restauration de version. Lorsqu’un tel changement se produit, le commutateur modifie uniquement l’itinéraire du chemin parcouru, plutôt que de créer temporairement un nouveau système.

La chose la plus précieuse à propos de cette chose n’est pas à quel point le modèle de rechange est bon marché, mais s’il est maintenu en tant que capacité formelle. Une équipe véritablement mature ne comprendra pas le « changement de modèle » comme une action d’approvisionnement, mais comme un cheminement d’exécution. Cette voie ne sera peut-être pas utilisée normalement, mais tant que le resserrement externe, les modifications des quotas et les restrictions régionales deviendront plus strictes, cette voie devra pouvoir tenir toute seule.

La question de savoir si le modèle open source peut continuer à être obtenu n’est qu’une question de premier niveau. Un jugement plus réaliste consiste à savoir si l’équipe a la capacité de déplacer en douceur le flux de travail vers un autre ensemble de piles une fois le modèle externe renforcé, au lieu d’arrêter l’activité en place et d’attendre que le fournisseur se rétablisse. Ce qu’il faut réellement préserver, ce n’est pas le nom d’un modèle donné, mais un chemin qui peut être tracé à plusieurs reprises.