Modelos IA: contratos para frenar regresiones

El 3 de noviembre de 2026, un día calendario antes de esta publicación en America/Lima, Hugging Face presentó Model Integration Contracts, una propuesta para probar arquitecturas de Transformers con tres piezas versionadas: un fixture reducido y fijado, una ruta de uso ejecutable y baselines revisadas por una persona. La decisión útil para un CTO no es reemplazar la suite completa por modelos pequeños. Es añadir al CI una señal rápida que recorra el mismo tokenizer, formato de pesos, variante de atención y llamada que usan los equipos, y que compare salidas, pérdida, gradientes y actualización de parámetros contra expectativas aprobadas. Ese diseño puede detectar una regresión que no provoca crash y que un forward pass genérico deja pasar. Pero el contrato solo cubre la arquitectura, el entorno, las entradas y la ruta que declara. Debe convivir con checkpoints reales, pruebas de hardware, evaluación de calidad y observabilidad de producción.

La novedad llega con evidencia concreta y límites publicados. El proyecto reejecutó contratos congelados sobre meses de commits y reprodujo una regresión de UMT5 en la que el decoder podía atender tokens futuros bajo SDPA. El contrato seleccionado falló con las mismas diferencias al revertir el arreglo dentro del CI de Transformers. Aun así, el propio equipo mantiene el job como informativo: al 1 de noviembre reportaba fallos sin bloquear PRs porque todavía necesita medir bugs capturados en cambios reales, falsos positivos y costo de revisión. Esa separación entre demostración y política de merge es la parte más valiosa del anuncio.

El fixture parte de la configuración de un checkpoint real y reduce anchura y profundidad, pero conserva las clases de capa que cambian el comportamiento. Un modelo híbrido no puede quedarse con dos capas elegidas por comodidad si así desaparecen la atención completa, una capa MoE o una ruta que comparte KV cache. El builder compara los tipos construidos por la configuración original y la reducida, mantiene procesadores y tokens especiales sin reescribirlos, conserva el formato que activa conversiones de carga y publica los pesos una vez. El CI consume una revisión fijada; no reconstruye el fixture en cada ejecución, porque hardware distinto puede producir bytes distintos.

La ruta de uso transforma ese artefacto en un contrato. Puede generar de forma determinista, ejecutar un paso de entrenamiento, verificar gradientes finitos y confirmar que el optimizador cambia pesos. Luego compara resultados con baselines aprobadas para una clase de plataforma y dtype. La selección conecta archivos modificados con contratos: un cambio de modelo ejecuta su familia; una utilidad compartida puede activar varias. El objetivo no es abaratar cualquier test, sino adelantar la ruta de mayor señal que cabe en un runner frecuente.

Imagina, de forma hipotética, que una empresa sirve un encoder-decoder para resumir expedientes y quiere activar un kernel de atención más eficiente. Las pruebas unitarias validan dimensiones y el smoke test devuelve texto, pero ninguna pregunta si el decoder ve información futura durante entrenamiento. El equipo crea un fixture reducido que conserva la variante de atención predeterminada y el tokenizer real. La ruta ejecuta inferencia determinista y un batch de entrenamiento con etiquetas desplazadas; registra IDs generados, log-probabilities de etiquetas, pérdida, gradientes y el cambio de pesos después de un paso.

El PR modifica el selector del backend, por lo que el contrato corre en CPU y encuentra una divergencia de pérdida sin excepción. Eso no prueba que el nuevo kernel sea incorrecto: la diferencia puede venir de precisión, plataforma o una baseline obsoleta. El merge queda en espera mientras el owner reproduce con el checkpoint real en el hardware de destino, compara la ruta eager y revisa si el cambio altera una semántica aceptada. Si el cambio es intencional, la baseline se actualiza en un PR separado con evidencia; si no lo es, el contrato conserva un caso mínimo para el arreglo. El ejemplo describe un flujo de decisión, no un resultado medido de Wasyra.

Gate uno, alcance: cada contrato nombra arquitectura, llamadas, inputs, backend, plataforma y dtype. Gate dos, fidelidad: el fixture conserva procesadores, formatos y tipos de capa que ejercen la ruta del usuario. Gate tres, procedencia: checkpoint fuente, revisión del fixture, dependencias, baseline y selector del contrato quedan fijados por digest. Gate cuatro, sensibilidad: perturbaciones de entradas y fallos sembrados demuestran que las aserciones pueden ver el problema que dicen cubrir. Gate cinco, estabilidad: el equipo mide drift permitido entre runners y separa tolerancias por plataforma sin ensancharlas para esconder cambios. Gate seis, operación: owners, presupuesto de tiempo, escalamiento y mecanismo para aprobar nuevas expectativas están definidos antes de convertir un warning en bloqueo.

Durante cuatro a seis semanas, registra cuántos PRs seleccionan contratos, tiempo de setup y ejecución, fallos repetibles, regresiones confirmadas, falsas alarmas y minutos humanos hasta clasificación. Una regla de promoción puede exigir varias regresiones reales detectadas y una tasa de ruido aceptable antes de bloquear. También necesita escape controlado: si el contrato falla por infraestructura, el PR no debe aprobarse como si hubiese pasado; debe quedar en estado no evaluado con reintento y owner. Un bypass de emergencia debe expirar y abrir seguimiento, no regrabar automáticamente expectativas.

Reducir una arquitectura siempre descarta algo. Los pesos aleatorios pueden reaccionar a entradas y aun producir generaciones inútiles; los pesos sobreajustados mejoran legibilidad y sensibilidad en algunos casos, pero añaden convergencia y mantenimiento. El estudio del proyecto encontró rutas de Whisper que solo fallaban con pesos reales. También mostró que la misma baseline numérica no debe asumirse entre CPU, GPU, dtype o kernels distintos. Un contrato verde significa que las expectativas revisadas se conservaron para esa combinación; no certifica calidad lingüística, seguridad, throughput, memoria ni compatibilidad con todos los checkpoints.

El riesgo organizacional es convertir golden outputs en un ritual. Si cualquier diferencia se acepta regrabando baselines, el contrato pierde poder. Si toda diferencia bloquea, el equipo aprende a evitarlo. La revisión debe comparar intención, diff, reproducción y efecto en el checkpoint real. Los contratos tampoco sustituyen datos de producto: una salida idéntica puede seguir siendo inadecuada para usuarios, y una salida numéricamente distinta puede ser una mejora deliberada. Mantén separados compatibilidad de integración, calidad del modelo y resultado del negocio.

Adopta un contrato reducido cuando una arquitectura crítica tiene una ruta cara que hoy solo corre de noche, una regresión silenciosa plausible y una expectativa suficientemente estable para revisar. Empieza con una o dos rutas: la variante de atención predeterminada, el procesador que usan los clientes y un paso de entrenamiento o generación que haya fallado antes. Mantén el checkpoint real en una capa posterior y mide si la nueva señal cambia decisiones de merge. Si el fixture no preserva el mecanismo o sus fallos no son clasificables, todavía no merece bloquear.

Model Integration Contracts ofrece una forma disciplinada de mover evidencia hacia el PR sin fingir que un modelo diminuto es producción. Su valor depende menos del tamaño del fixture que de la fidelidad de la ruta, la procedencia de las expectativas y la política humana que responde a una diferencia. Si necesitas diseñar una pipeline de evaluación para modelos o agentes con gates reproducibles, Wasyra puede ayudarte a definir el contrato, automatizar la evidencia y conectarla con una decisión operativa verificable.