Les risques du modèle open source reposent d’abord sur la couche d’accès

Ces derniers jours, on s’est demandé si les modèles open source resteraient bloqués par la politique de durcissement des États-Unis. La première chose qui change en ingénierie, ce ne sont pas les capacités du modèle, mais l’accessibilité par défaut. Le modèle est toujours là, tout comme les papiers. Ce qui tremble vraiment en premier, ce sont l’adresse d’extraction, la source miroir, la plate-forme d’hébergement, les conditions de licence et la disponibilité régionale. La première chose que rencontrent souvent les personnes qui accèdent au travail n’est pas « le modèle n’est pas assez solide », mais « pouvons-nous encore l’obtenir de manière stable aujourd’hui ?

L’accessibilité par défaut devient d’abord pire

Dans le passé, le problème le plus ennuyeux lors de l’accès au modèle était “le même modèle pouvait être téléchargé hier, mais tout à coup, il recevait un 403 aujourd’hui”. Ce type de changement ressemble à une petite fluctuation dans la chaîne d’approvisionnement, mais entraîne en réalité l’ensemble du lien dans un état instable : le téléchargement du poids doit être réessayé, la source de l’image doit être changée, la somme de contrôle doit être recalculée, l’image de déploiement doit être reconditionnée et le cache dans le CI deviendra également invalide. En apparence, seule l’étape d’obtention du modèle est rendue fragile, mais en réalité, le principe de « convivialité » est retiré du système.

Le modèle open source est souvent compris comme « une fois que le code est open source, il ne sera plus contrôlé par d’autres ». Cette phrase n’est qu’à moitié correcte. Le code open source ne signifie pas qu’il est accessible par défaut, et être visible dans l’entrepôt ne signifie pas que l’environnement de production peut être lancé de manière stable. Qui l’héberge, dans quelle région il existe, si la licence a changé et s’il existe des restrictions sur la fréquence de téléchargement. Une fois que ces détails sont bloqués par la plate-forme, les politiques ou les conditions commerciales, ce que l’équipe voit, ce n’est pas « le modèle disparaît », mais « les éléments qui étaient facilement disponibles commencent à devenir une infrastructure qui doit être entretenue ».

L’interface du modèle sera agrandie jusqu’à la limite du système

Dans le passé, lorsque j’écrivais tous les détails du routage du modèle, la chose la plus difficile à collecter n’était pas que le score était en retard de deux ou trois points, mais que l’interface du modèle n’était pas assez stable. Une fois qu’une base est remplacée, les habitudes d’invite, la structure de sortie, le format d’appel de l’outil et le comportement du contexte long changeront tous en conséquence. Le nom du modèle ne semble pas avoir changé, mais l’analyseur, l’ensemble d’évaluation, le journal de relecture et la gestion des échecs dans le système doivent être réexécutés. Ce qui était le plus facilement révélé à ce moment-là était que le système confondait « un certain modèle » avec « une certaine capacité ».

C’est également le domaine le plus négligé dans les discussions liées aux modèles open source. Ce qui est vraiment précieux n’est pas un nom lui-même, mais l’ensemble des fonctionnalités remplaçables qu’il peut fournir : complétion, classification, extraction, dialogue, appel d’outil, résumé d’article long et génération de code. Tant que la couche d’accès lie ces fonctionnalités à des modèles spécifiques, tout changement ultérieur sera amplifié par les coûts de migration. En revanche, si la couche d’interface est d’abord condensée en un contrat stable, la base peut être remplacée comme une dépendance, et le risque ne sera limité que dans une mesure limitée.

Le routage et le repli sont plus importants que les noms

Que le modèle open source soit « scellé » ou non, l’impact sur le système final n’est généralement pas le nom du modèle, mais l’existence d’une issue. Si une équipe confie toutes les tâches sur un seul modèle distant, toute restriction géographique, restriction d’accès ou changement de stratégie commerciale entraînera directement une interruption des activités. Au contraire, tant que des modèles exécutables localement, des sources d’hébergement de sauvegarde, des pools de modèles de différents niveaux de capacité et des ensembles d’évaluation rejouables sont tous présents, les limitations externes augmenteront au mieux les coûts de commutation et ne rendront pas immédiatement le système indisponible.

Par conséquent, lorsque l’on porte un jugement au niveau du modèle, il est préférable de ne pas se contenter de se demander « quel modèle est le plus fort », mais également de se demander « cette chaîne de capacités peut-elle être remplacée par une base ? Les poids peuvent-ils être conservés dans un entrepôt contrôlable ? Les dépendances peuvent-elles être verrouillées dans des versions fixes ? Le routage, la mise en cache, la lecture et la restauration peuvent-ils être transformés en un ensemble complet d’actions ? Ces questions sont plus proches de la frontière réelle que le nom du modèle. Le risque de restriction du modèle ne disparaîtra pas en premier, mais l’accessibilité par défaut changera en premier ; et ce que le système doit maintenir n’est jamais un modèle, mais un ensemble de capacités qui peuvent être fournies en continu.