Une fois le modèle open source restreint, la première chose qui doit être indépendante est la couche neutre du modèle.

Une fois qu’un modèle open source commence à être restreint, la première chose exposée n’est souvent pas l’entrée de téléchargement, mais les hypothèses par défaut du code. Le nom du modèle a été modifié, mais l’interface est toujours là, mais le processus métier n’est plus synchronisé avec l’ancien comportement : format de sortie, séquence d’appel de fonction, tonalité de rejet, longueur de contexte, paramètres d’échantillonnage, chacun d’entre eux peut être visualisé individuellement, mais les empiler ensemble fera glisser l’intégralité du lien.

Ce type de problème est généralement difficile à considérer comme un problème architectural. Pendant la phase de développement, je n’ai vu que “can run”. Après être allé en ligne, j’ai découvert que la sélection du modèle avait déjà été inscrite dans la logique métier. Certains champs ne s’adaptent qu’à un seul format de retour, certaines tentatives ne reconnaissent qu’une seule méthode de rejet et certaines exceptions reviennent par défaut au modèle d’origine pour donner une explication plus longue. Une fois les restrictions imposées, tous ces tas cachés ont été exposés.

Le comportement par défaut liera le modèle à l’entreprise

Au stade de l’accès, le modèle est souvent considéré comme l’ajout d’un SDK, la connexion d’une API et l’ajout d’un mot d’invite. Une fois connecté, la chose la plus difficile à nettoyer n’est pas l’appel lui-même, mais les branches qui se sont développées autour du comportement par défaut. Si la sortie doit être strictement JSON, si l’appel de l’outil doit être réessayé après un échec, où tronquer une entrée trop longue et sur quelle couche placer les invites de contrôle des risques. Ces questions relèvent souvent du code des affaires.

Une fois qu’un modèle open source est restreint ou supprimé des étagères, ou que l’image locale et la version en amont commencent à se diviser, ces comportements par défaut ne sont plus fiables. En apparence, il s’agit simplement de changer le modèle, mais en dessous, il est nécessaire de modifier en même temps l’analyse, la surveillance, la restauration et les tests. Le plus difficile n’est pas d’écrire quelques lignes supplémentaires d’adaptation, mais que l’ensemble initial d’hypothèses ne soit pas explicitement marqué du début à la fin.

Le rôle de la couche neutre est d’étaler les hypothèses implicites

Les couches neutres en termes de modèle ne sont pas abstraites par souci d’abstraction. Sa fonction est très simple : regrouper les mots d’invite, la vérification du schéma, le routage, la nouvelle tentative, le déclassement, les journaux et l’évaluation en un seul endroit, afin que les différences de modèle passent d’abord par le même ensemble de limites. De cette manière, même si le modèle est remplacé par le cloud, l’open source, l’inférence locale ou d’autres fournisseurs, l’entreprise bénéficiera toujours d’un contrat d’entrée et de sortie unifié.

Une fois cette couche établie, de nombreuses choses qui n’étaient pas claires à l’origine deviendront soudainement claires. Quels champs sont des valeurs obligatoires, quels champs sont simplement des préférences de modèle, quels échecs peuvent être réessayés, quels échecs doivent être annulés, quels contextes seront tronqués et quels indicateurs peuvent réellement être comparés passeront tous de « mémorisés par l’expérience » à « restreints par les interfaces ». L’impact provoqué par le modèle limité n’est plus directement inscrit dans le code métier, mais d’abord dans la couche neutre.

Toutes les scènes ne sont pas dignes de cette couche

Certaines scènes n’ont pas du tout besoin que les couches soient aussi épaisses. Résumés ponctuels, génération temporaire, expérimentations internes et chaînes d’outils entièrement verrouillées sur un modèle unique, il suffit de connecter le modèle à ces endroits. Construire une couche neutre complète pour un processus de courte durée ne fera que dépasser le coût à l’avance.

Cette couche est nécessaire là où le modèle participera réellement au jugement commercial. Tels que l’extraction, le routage, l’exécution d’outils, la réponse du service client, l’assistance à la révision et la réécriture par lots. Dans ces scénarios, le modèle n’est pas un jouet, mais une partie du processus. Tant que le modèle peut changer ou que des contraintes extérieures peuvent déstabiliser une certaine entrée, la couche neutre n’est pas une décoration mais un mur qui maintient le changement dans les limites.

Ce qui oblige réellement à restreindre le modèle open source, ce n’est pas l’alternative d’un fournisseur spécifique, mais la question de savoir si l’équipe traite les « différences de modèle » comme des citoyens de premier ordre. Plus le comportement par défaut dans le code est étalé tôt, moins il sera passif lors du changement de modèle ultérieur. Le modèle peut changer, mais les frontières ne peuvent pas suivre.