Registry, política continua y deriva

El modelo de estas capturas

Todo lo de esta página está medido conduciendo la aplicación con un modelo de verdad, no montado con maquetas. Es una red densa pequeña —915 parámetros entrenables, cinco entradas, tres clases— que clasifica tickets de soporte en baja / media / alta. Se entrenó por el camino normal, con 400 filas generadas por el core desde una receta.

Los números que vas a ver —los umbrales, las cuatro mediciones, la huella— son los que salieron en esa sesión. Aquí no hay nada ilustrativo.

1 · Registry — qué hay publicado

Mis modelos es tu taller: guardas, pisas, tiras. El Registry es lo contrario: una entrada nunca se sobrescribe. Publicar otra vez crea una versión nueva al lado de la vieja, y la vieja sigue funcionando para quien ya la estuviera usando.

Cada entrada lleva, y el panel las enseña:

• su huella (sha256:3793a5541c18…), que es el hash de todo lo que la entrada contiene. Cambia un peso y cambia.
• sus tipos: Takes VECTOR 5 · produces ProbabilityMap. Es lo que permite al core decir si dos piezas encajan; sin ellos tendría que aprobar por omisión.
• sus etiquetas: current es la que significa «esto es lo desplegado». La mueve promover, y la devuelve un rollback.
• una acción Verificar que recalcula la huella y dice si la entrada está íntegra. Mientras no lo pidas pone Not checked, que no es «íntegra».

El registry no se crea por abrir el panel. Si esta instalación no tiene, la vista lo dice y dice qué lo crearía: un GET que deja ficheros es un efecto que nadie ha pedido.

2 · Política continua — qué prometió vigilar el modelo

Un modelo puede viajar con un fichero .mxcontinual al lado: una política que declara, antes de que nada derive, qué contaría como derivar y qué se haría entonces. El panel la lee y la enseña. No recalcula nada: todos esos números son del core, y el panel lo dice abajo.

Qué significa cada fila, con los valores de este modelo:

• Modelo objetivo — de qué modelo habla la política.
• Umbrales de deriva — por columna, el método y la cifra que hay que cruzar: urgencia: psi threshold=0.2 · impacto: psi threshold=0.2 · carga_del_equipo: ks threshold=0.15. Una columna sin método declarado no se mide nunca, y la vista de deriva lo dice en vez de contar un cero.
• Ventana (7) — cuántos días de verdad-terreno cuentan.
• Mínimo de muestras (30) — cuántos datos de producción hacen falta antes de que la política esté dispuesta a opinar.
• Versión en curso (v1) — sale de la etiqueta current del registry. Si nadie ha etiquetado ninguna, el panel dice por qué no la hay en vez de poner un guion.
• Métrica de rollback — qué métrica vigilaría una vuelta atrás.

Un modelo sin política no se queda con un panel vacío: se queda con un panel que dice que no la tiene y qué fichero se la daría.

3 · Deriva — qué ha cambiado de verdad

Arriba del todo está Check with a batch —«medir con un lote»—. Se sube un solo fichero, y conviene decir exactamente cuál:

• Qué CSV. Uno con datos nuevos: los que el modelo está recibiendo ahora, o cualquier lote que quieras comparar contra su entrenamiento.
• Qué tiene que traer. Las columnas que vigila la política —el propio panel las nombra— y al menos tantas filas como diga su Minimum samples. La respuesta no hace falta: lo que se mira es si han cambiado las entradas.
• De dónde sale. No lo genera el Studio: es tuyo. Para probar, en Datos hay dos descargas y no son lo mismo: Descargar plantilla da las columnas vacías, y Descargar los datos del entrenamiento da el CSV con filas con el que se entrenó el modelo. Ese segundo te sirve de punto de partida: cámbiale los valores y ya tienes un lote.
• La referencia no se sube. Los datos con los que se entrenó el modelo los pone el Studio: comparar contra otra cosa mediría otra cosa.

Cada medición se guarda, así que la vista es un histórico y no una foto suelta, y sale de la más reciente a la más antigua: la que acabas de hacer es la primera. El veredicto lo calcula el core; el panel lo enseña.

En la captura hay siete mediciones del mismo modelo —la interfaz está en inglés—, y no dicen todas lo mismo:

• las de arriba ponen Drift detected, en rojo, y nombran la columna que cruzó su umbral: urgencia: 15.71… against a threshold of 0.2 · psi method · 200 samples;
• más abajo, las que se quedaron por debajo ponen No drift;
• dos columnas ponen Not measured: no method declared for feature. Eso no es un cero ni un «va bien»: es que la política nunca dijo cómo vigilarlas;
• y alguna pone Not measured: no reference data for feature, que es distinto: la referencia no traía esa columna, así que no había contra qué compararla.

Un modelo que nunca se ha medido dice exactamente eso. Una gráfica en blanco se leería como «no hay deriva», y son dos cosas muy distintas.

Hay modelos a los que no se les puede medir la deriva, y eso se dice antes de que subas nada: si el modelo no conservó su dataset y su captura no permite regenerarlo —le falta la semilla, por ejemplo—, no hay contra qué comparar ningún lote. Entonces el panel no ofrece la puerta: enseña el motivo y ya está. Para poder medirle deriva habría que volver a entrenarlo conservando el dataset.

Y cuando falla al medir, se dice ahí mismo, en rojo y junto al fichero que acabas de soltar: si el lote no trae ninguna de las columnas vigiladas, las nombra; y si el dataset regenerado no casa con la huella que el modelo declara, tampoco se usa. Medir contra algo que no es con lo que se entrenó daría un veredicto sobre otra cosa con la cara de ser sobre ésta.

Y entonces qué: proponer y decidir

Con la deriva medida, la vista puede pedir una propuesta de refinamiento: un diff sobre el prompt que produjo el modelo. Tres cosas de ella son deliberadas.

• Hace falta el prompt. Un modelo guardado conserva un label, que es un extracto: refinar el extracto daría una propuesta sobre un texto truncado que se leería como una propuesta sobre el original.
• Rechazar exige un motivo, y toda decisión guarda quién y cuándo. Un rechazo mudo dejaría constancia de que alguien dijo que no y de nada más.
• Aceptar no despliega. Deja un candidato que puedes mirar y descartar. Convertir un prompt propuesto en modelo versionado exige reentrenar, y promover es un acto aparte y humano. La respuesta lo dice antes de que pulses.

En la interfaz por fases están repartidas distinto, y a propósito

En el Workbench las tres van en la barra del propio modelo, junto a Diagrama, Pipeline, Fuente, Datos y Exportar — y al pulsarlas se abren en el centro, exactamente igual que ellas. Son vistas del modelo que tienes abierto, así que viven donde viven sus otras vistas. La interfaz por fases es un ciclo de vida, así que esas mismas tres cosas viven donde ocurren.

• Despliegue enseña lo que puedes publicar y lo que ya está publicado: la entrada del registry va justo debajo de las opciones de empaquetado. Publicar sin poder mirar el resultado te obligaría a salir de la fase para comprobar lo que acabas de hacer.
• Seguimiento es una séptima fase, detrás de Despliegue, y junta la política y la deriva: son la misma pregunta por sus dos lados —lo que el modelo prometió vigilar y lo que ha pasado—.
• Sale bloqueada mientras el modelo no esté firmado. Sin nada desplegado no hay nada que vigilar, y encenderla llevaría a paneles vacíos.

Lo que esto no hace

• La deriva se mide con un lote que subes, no con el tráfico de producción en vivo. Recoger producción automáticamente exige una traza de acción firmada que el Studio todavía no produce.
• Aquí nada reentrena, promueve ni hace rollback por su cuenta. La política declara qué se haría; hacerlo es un acto aparte y humano.
• Una columna sin método declarado no se vigila. El panel lo dice en cada medición en vez de contarla en silencio como que va bien.