Una vez restringido el modelo de código abierto, lo primero que debe ser independiente es la capa neutral del modelo.

Una vez que un modelo de código abierto comienza a restringirse, lo primero que se expone no suele ser la entrada de descarga, sino las suposiciones predeterminadas en el código. Se ha cambiado el nombre del modelo, pero la interfaz sigue ahí, pero el proceso de negocio ya no está sincronizado con el comportamiento anterior: formato de salida, secuencia de llamada de función, tono de rechazo, longitud del contexto, parámetros de muestreo, cualquiera de ellos se puede ver individualmente, pero apilarlos arrastrará el enlace completo.

Este tipo de problema suele ser difícil de considerar como un problema arquitectónico. Durante la etapa de desarrollo, solo vi “puede ejecutarse”. Después de conectarme, descubrí que la selección del modelo ya se había escrito en la lógica empresarial. Algunos campos solo se adaptan a un formato de devolución, algunos reintentos solo reconocen un método de rechazo y algunas excepciones recurren de manera predeterminada al modelo original para brindar una explicación más detallada. Una vez que se impusieron las restricciones, todos estos montones ocultos quedaron al descubierto.

El comportamiento predeterminado vinculará el modelo al negocio.

En la etapa de acceso, a menudo se considera que el modelo agrega un SDK, conecta una API y agrega una palabra de aviso. Después de conectarse, lo más difícil de limpiar no es la llamada en sí, sino las ramas que han crecido alrededor del comportamiento predeterminado. Si la salida debe ser estrictamente JSON, si la llamada a la herramienta debe intentarse nuevamente después de una falla, dónde truncar la entrada demasiado larga y en qué capa colocar las indicaciones de control de riesgos. Estas cuestiones suelen caer en el código empresarial.

Una vez que un modelo de código abierto se restringe o se elimina de los estantes, o la imagen local y la versión ascendente comienzan a bifurcarse, estos comportamientos predeterminados ya no son confiables. En la superficie, es solo cambiar el modelo, pero en el fondo es necesario cambiar el análisis, el monitoreo, la reversión y las pruebas al mismo tiempo. Lo más difícil no es escribir unas cuantas líneas más de adaptación, sino que el conjunto original de supuestos no esté marcado explícitamente de principio a fin.

El papel de la capa neutral es difundir los supuestos implícitos.

Las capas neutrales al modelo no son abstractas por el simple hecho de ser abstractas. Su función es muy simple: colocar palabras de aviso, verificación de esquema, enrutamiento, reintento, degradación, registros y evaluación en un solo lugar, de modo que las diferencias de modelo pasen primero por el mismo conjunto de límites. De esta manera, incluso si el modelo es reemplazado por la nube, el código abierto, la inferencia local u otros proveedores, la empresa seguirá viendo un contrato unificado de entrada y salida.

Una vez que se establece esta capa, muchas cosas que originalmente no estaban claras de repente se aclararán. Qué campos son valores obligatorios, qué campos son solo preferencias del modelo, qué fallas se pueden reintentar, qué fallas se deben revertir, qué contextos se truncarán y qué indicadores realmente se pueden comparar cambiarán de “recordados por la experiencia” a “restringidos por interfaces”. El impacto causado por el modelo limitado ya no se ingresa directamente en el código comercial, sino primero en la capa neutral.

No todas las escenas son dignas de esta capa.

Algunas escenas no necesitan que las capas sean tan gruesas en absoluto. Resúmenes únicos, generación temporal, experimentos internos y cadenas de herramientas bloqueadas de un solo modelo, es suficiente conectar el modelo en estos lugares. Construir una capa neutral completa para un proceso de corta duración sólo sobregirará el costo por adelantado.

Esta capa es necesaria donde el modelo realmente participará en el juicio empresarial. Como extracción, enrutamiento, ejecución de herramientas, respuesta de servicio al cliente, asistencia en revisión y reescritura por lotes. En estos escenarios, el modelo no es un juguete, sino parte del proceso. Mientras el modelo pueda cambiar, o las limitaciones externas puedan desestabilizar una determinada entrada, la capa neutra no es decoración sino una pared que mantiene el cambio dentro de los límites.

Lo que realmente obliga a restringir el modelo de código abierto no es la alternativa de un proveedor específico, sino si el equipo trata las “diferencias de modelo” como ciudadanos de primera clase. Cuanto antes se distribuya el comportamiento predeterminado en el código, menos pasivo será al cambiar de modelo más adelante. El modelo puede cambiar, pero los límites no pueden seguirlo.