Une fois le modèle open source chinois restreint, la première chose à faire est la version et le calibre d'évaluation.

Une fois ces restrictions levées, la première chose qui tombe en panne n’est généralement pas « peut-il encore être téléchargé ? mais « peut-il toujours être basé sur le même ensemble de scores ?

Le modèle lui-même est toujours là et la mise en miroir peut être synchronisée, mais le problème commence à se déplacer de l’entrée vers la comparaison. Une version qui fonctionne bien aujourd’hui présentera de légères différences sur une autre machine en raison du découpage du poids, de la version du tokenizer, des paramètres d’inférence ou des délais de mise en miroir. Rien qu’en regardant chaque sortie, il semble que cela fonctionne toujours ; une fois remise dans l’ensemble de régression, la courbe commence à s’étaler. Auparavant, il suffisait d’examiner un score total pour décider de mettre à niveau, mais vous devez désormais déterminer d’abord « si ce changement vient du modèle ou de la pile de services ».

Le véritable problème causé par les restrictions ne réside pas dans l’action de téléchargement elle-même, mais dans la destruction des relations de comparaison. Dans le passé, il suffisait de se concentrer sur une seule version en amont, mais il existe désormais souvent à la fois des sources officielles, des sources miroir, des caches internes, des versions quantifiées et des versions de restauration temporaires. Chaque ligne peut être exécutée, mais les résultats ne partagent plus la même référence. Une fois l’ensemble d’évaluation créé, l’équipe perdra rapidement un langage commun : R&D affirme que cette version a été améliorée et le produit affirme que l’expérience en ligne n’a pas changé. Les dépanneurs doivent d’abord confirmer si le modèle a changé ou si l’environnement d’inférence a changé.

Le plus gênant avec ce type de fourche, c’est qu’elle ne se manifeste pas immédiatement par un dysfonctionnement. Lors de la première journée, l’écart n’était que de 0,3 point entre les deux milieux. Le deuxième jour, un certain long échantillon de texte a commencé à dériver. Après avoir annulé le troisième jour, j’ai constaté que les anciens résultats ne pouvaient pas être reproduits. A ce stade, la discussion ne porte plus sur « peut-on avoir le modèle ? mais « que ce que nous obtenions soit la même chose ».

Ce qui devrait vraiment être arrêté en premier, ce n’est pas l’entrée du téléchargement, mais la ligne de base. Au moins les éléments suivants doivent être précisés :

• Le hachage, la version du tokenizer, la méthode de quantification et les paramètres d’inférence du fichier modèle.
• Ensemble d’évaluation, mots d’invite, paramètres d’échantillonnage et logique de post-traitement.
• Encapsulation d’inférence partagée par les services en ligne et régression hors ligne pour éviter que les deux ensembles d’implémentations ne dérivent.
• Conservez l’ancienne image et la ligne de base lors de la restauration, sans compter sur la reconstruction de la mémoire.

Ces choses peuvent sembler triviales, mais une fois que l’accès aux modèles commence à être restreint, c’est cette couche de trivialité qui est vraiment précieuse. Sans eux, l’équipe ne peut que parier sur la prochaine mise à niveau avec « ça a l’air bien cette fois » ; avec eux, ils peuvent au moins confirmer si le problème réside dans le modèle, la pile d’inférence ou l’ensemble de données lui-même.

Ainsi, lorsque cette question reviendra finalement au projet, le jugement deviendra très simple : la question de savoir si le modèle peut être obtenu n’est que le début ; le fait que le même ensemble d’entrées, le même ensemble de paramètres et le même ensemble d’échantillons puissent être exécutés en continu sur la même ligne détermine s’il peut toujours être utilisé de manière stable. Tant que le calibre comparatif demeure, il y a encore une marge de manœuvre dans le modèle ; une fois que le calibre diverge en premier, le remplacement, la restauration et le dépannage ultérieurs deviendront plus coûteux.