Une fois le modèle open source chinois restreint, la première chose à augmenter est le coût de la vérification.

Une fois les modèles open source restreints, la première chose qui devient coûteuse n’est généralement pas le modèle lui-même, mais la vérification. La question de savoir si le modèle peut encore être abaissé n’est que la première couche ; après son extraction, le fait que le format de sortie, l’appel de l’outil, la politique de rejet, la longueur du contexte et les paramètres d’échantillonnage puissent toujours être alignés sur l’ancienne version déterminera si le système continuera à être stable.

Ce qui ressemblait à un problème d’approvisionnement s’est transformé en un problème d’ingénierie pour l’équipe. Une fois qu’un modèle entre dans le processus, la couche d’accès se retrouve rarement avec une simple adresse API. Les mots d’invite, les schémas, les tentatives, les délais d’attente, les positions de troncature et les séquences d’appels d’outils deviendront progressivement des prémisses implicites. Lorsque la version est stable, ces prémisses peuvent être étayées par l’expérience ; lorsque le modèle est limité, que l’image est fourchue ou que les performances de la version du même nom dérivent, l’expérience commence à échouer. La première chose qui perd son effet est souvent le jugement de régression, car l’ensemble de tests indique uniquement au système ce qui n’est pas cassé et ne peut pas déterminer directement ce qui a changé.

L’hypothèse par défaut est qu’il sera lié et renvoyé en premier.

Dans le passé, un groupe de cas dorés pouvait fonctionner longtemps. La plupart du temps, ils examinaient simplement si le rendement avait manifestement dévié. Le modèle est fixe et le mot d’invite est également fixe. Tout le monde affichera par défaut “ce lien a été vérifié”. Dès que des restrictions apparaissent, ce défaut commence à s’effondrer. Les modèles peuvent changer de région, d’image ou de version, et même les modèles portant le même nom peuvent se comporter différemment selon les périodes. À l’heure actuelle, la régression ne consiste plus à juger si elle peut être utilisée, mais à juger sur quelle couche le changement tombe et si la valeur du changement vaut la peine d’être modifiée.

La distribution et la restauration amplifieront les petits changements

Une fois le modèle restreint, les premières choses à faire sont le téléchargement, la mise en miroir, l’approbation, l’audit et la restauration. En apparence, il s’agit simplement d’un modèle disponible. En fait, il ajoute le verrouillage des versions, la synchronisation du cache, le contrôle des autorisations et le basculement. Tant que la distribution des modèles ne dispose pas d’une couche indépendante, l’entreprise remettra ces tâches à son propre rythme de publication. Le résultat n’est souvent pas de « faire plus d’adaptation », mais le contrat d’entrée et de sortie doit être reconfirmé à chaque mise à jour.

La première chose que la couche neutre arrête n’est pas la capacité du modèle.

Ce qui doit vraiment être séparé n’est généralement pas le modèle lui-même, mais la couche de limites neutres autour du modèle : modèles de mots d’invite, vérification du schéma, stratégies de routage, logique de nouvelle tentative, journaux et évaluations. Rassembler ces éléments ne vise pas à rechercher la propreté, mais à permettre aux changements de tomber d’abord sur le même ensemble de contrats. Le modèle peut être remplacé, les entrées et les sorties ne peuvent pas dériver et la ligne de base de régression ne peut pas se disperser. Une fois la couche neutre établie, de nombreux comportements par défaut initialement mémorisés grâce à l’expérience deviendront des éléments qui pourront être comparés, annulés et rejoués.

Tous les projets ne valent pas la peine de faire cette couche en premier.

Des résumés ponctuels, des expériences internes, des scripts éphémères, directement connectés au modèle suffisent. Ce qui nécessite une couche neutre, c’est un scénario dans lequel le modèle a commencé à participer au jugement de production, et il existe une forte probabilité que le fournisseur ou la région change ultérieurement. Pour ces systèmes, le vrai problème est de ne jamais écrire quelques lignes d’adaptation supplémentaires, mais que les comportements par défaut d’origine ne soient pas explicitement marqués. Sans cette couche, à chaque changement de modèle, le rythme de retour, de distribution et de libération devra être recalculé.

Le soi-disant sceau rembourse souvent à l’équipe les coûts de vérification, de distribution et de restauration initialement économisés. Les modèles changent et les liens ne peuvent être stabilisés par le hasard. Nous devons d’abord démonter le lien de vérification avant de pouvoir discuter de la question de savoir si le modèle peut continuer à être utilisé.