Guías

Validar un modelo entrenado

Un modelo entrenado puede puntuar bien en una suite que ya ha visto, cambiar su respuesta cuando una entrada se mueve un poco y dar con una semilla afortunada. Oloproof comprueba cada una de estas cosas antes de que el modelo salga a producción: la suite frente a los datos de entrenamiento, cada predicción bajo un ruido declarado y la receta de entrenamiento con varias semillas. Copie el ejemplo con oloproof init --example model-validation: un modelo de préstamos entrenado con NumPy, sin conexión, sobre datos sintéticos.

La suite frente a los datos de entrenamiento

oloproof leakage check --training data/training.jsonl --record

Cada caso se compara con cada fila de entrenamiento por coincidencia exacta, tras pasar las cadenas a minúsculas y colapsar los espacios (--round redondea los números, --field nombra las claves que se comparan). El archivo de entrenamiento se lee en su máquina y nunca se almacena ni se envía; el registro guarda los identificadores de los casos y los recuentos. Declare leakage: required en release.yaml y la puerta queda bloqueada (código de salida 3) hasta que se registre una comprobación limpia de esta suite. Un caso encontrado en los datos de entrenamiento invalida la evidencia; no es un FAIL del modelo. Los casi duplicados no se comprueban.

Predicciones bajo ruido

metamorphic:
  transforms:
    - name: noise
      field: features
      perturb: {kind: numeric_noise, scale: {income: 1.0, debt_ratio: 0.02}, seed: 7}
evaluators:
  - {type: metamorphic_relation, relation: same_label, transform: noise, field: label, passes_when: flipped}

Cada caso recibe una copia con ruido sembrado en los números indicados, y flips_under_noise es la proporción de casos cuya etiqueta cambió. categorical_swap sustituye valores según un mapa declarado, y blur, brightness, occlusion y jpeg modifican imágenes. Un regresor usa same_score_within con una tolerancia. Las personas no pueden juzgar si el ruido en una fila conserva su significado, así que una perturbación numérica es declarada: su tasa se informa, y una regla sobre ella da INSUFFICIENT_EVIDENCE con transform_declared. Una transformación de imagen decide una puerta cuando las etiquetas de las personas muestran que conserva el significado de cada imagen, igual que una transformación de texto. El proyecto image/ del ejemplo muestra ambos casos: un desenfoque que sus etiquetas verifican, cuya tasa de cambios no supera un techo, y un parche gris que según sus etiquetas a veces oculta el rayón, cuya regla se abstiene.

La receta con varias semillas

El checkpoint que usted publica se decide sobre su propia ejecución, como cualquier sistema. Otra pregunta es si su manera de entrenar es lo bastante buena: vuelva a entrenar el mes que viene y obtendrá otro sorteo. Entrene k checkpoints con k semillas, ejecute cada uno sobre la misma suite y nombre las ejecuciones:

seeds:
  recipe: loan-model
  checkpoints: {seed_1: latest~4, seed_2: latest~3, seed_3: latest~2, seed_4: latest~1, seed_5: latest}
  rule: {id: recipe_accurate, criterion: correct, min: 0.8}

oloproof seeds seeds.yaml --policy recipe.yaml lee la tasa de aprobación esperada sobre las semillas, con un intervalo que cuenta tanto los casos de la suite como las semillas probadas. En el ejemplo, cinco semillas obtienen del 85,7 % al 90,3 %, y la receta da 88,2 %, del 83,2 % al 91,9 %: PASS frente al 80 %. El intervalo es aproximado, así que la política necesita allow_approximate_methods: true; de lo contrario, la respuesta es MANUAL_REVIEW. La política debe contener al menos una regla; el comando lee su nivel de confianza, la aceptación explícita y sus umbrales de juez, y nada más. También enumera los casos cuyo veredicto cambia de una semilla a otra, y --html FILE escribe una página sin conexión con cada caso bajo cada checkpoint.

Cada checkpoint cuenta. Una semilla cuyo entrenamiento falló se conserva, y cada caso que no respondió cuenta como fallo para el extremo inferior y como acierto para el superior, de modo que ensancha el intervalo. Menos de tres semillas dan INSUFFICIENT_EVIDENCE; hacen falta unas cinco para decidir algo. Un juez en el que la puerta no confiaría tampoco decide una receta. Cada checkpoint debe ejecutar la misma suite, con una versión de sistema cada uno, y una suite que declara grupos se rechaza.

Lo que esto no puede decirle

Perturbaciones que nadie declaró. Solo se prueban las transformaciones declaradas, con los tamaños declarados, y una tasa de cambio baja no dice nada de cambios mayores ni de la búsqueda de un atacante.
Robustez certificada. No se demuestra ninguna cota para ninguna entrada; la tasa de cambio es una tasa sobre los casos de la suite.
Cómo se entrenó el modelo. Oloproof no puede ver si las semillas se eligieron antes de evaluar ningún checkpoint, si se descartaron ejecuciones fallidas o si los checkpoints solo difieren en su semilla.
Un fallo más raro que aproximadamente una semilla de cada k. Si la receta falla al entrenar una vez de cada diez y ninguna de las cinco semillas falló, el intervalo no puede saberlo.
Fugas que el archivo de entrenamiento no muestra: casi duplicados, una imagen redimensionada o filas usadas para el ajuste pero excluidas del archivo.
Fugas en las ejecuciones de las semillas. oloproof seeds no lee leakage: required; el checkpoint que publica pasa la puerta sobre su propia ejecución, que sí lo lee.

Lo que ninguna evaluación puede decirle está en su propia página.