Valider un modèle entraîné

Un modèle entraîné peut bien noter sur une suite qu'il a déjà vue, changer de réponse quand une entrée bouge un peu, et tomber sur une graine chanceuse. Oloproof vérifie chacun de ces points avant que le modèle ne parte en production : la suite face aux données d'entraînement, chaque prédiction sous un bruit déclaré, et la recette d'entraînement sur plusieurs graines. Copiez l'exemple avec oloproof init --example model-validation : un modèle de prêt entraîné par NumPy, hors ligne, sur des données synthétiques.

La suite face aux données d'entraînement

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

Chaque cas est comparé à chaque ligne d'entraînement par égalité exacte, après mise en minuscules des chaînes et réduction des espaces (--round arrondit les nombres, --field nomme les clés à comparer). Le fichier d'entraînement est lu sur votre machine et n'est jamais stocké ni envoyé ; l'enregistrement garde les identifiants de cas et des comptes. Déclarez leakage: required dans release.yaml et la porte est bloquée (code de sortie 3) tant qu'une vérification propre de cette suite n'est pas enregistrée. Un cas trouvé dans les données d'entraînement rend la preuve invalide ; ce n'est pas un FAIL du modèle. Les quasi-doublons ne sont pas vérifiés.

Les prédictions sous bruit

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}

Chaque cas reçoit une copie avec un bruit amorcé sur les nombres nommés, et flips_under_noise est la part des cas dont l'étiquette a changé. categorical_swap remplace des valeurs selon une table déclarée, et blur, brightness, occlusion et jpeg modifient des images. Un régresseur utilise same_score_within avec une tolérance. Personne ne peut juger si un bruit sur une ligne en garde le sens, donc une perturbation numérique est déclarée : son taux est rapporté, et une règle qui porte sur lui donne INSUFFICIENT_EVIDENCE avec transform_declared. Une transformation d'image peut décider d'une porte dès que les étiquettes humaines montrent qu'elle garde le sens de chaque image, comme une transformation de texte. Le projet image/ de l’exemple montre les deux : un flou que ses étiquettes vérifient, dont le taux de bascule échoue sous un plafond, et une tache grise dont les étiquettes montrent qu’elle cache parfois la rayure, et dont la règle ne tranche pas.

La recette sur plusieurs graines

Le point de contrôle que vous livrez est décidé sur sa propre exécution, comme tout système. Une seconde question est de savoir si votre façon d'entraîner est assez bonne : réentraînez le mois prochain et vous obtenez un autre tirage. Entraînez k points de contrôle avec k graines, exécutez chacun sur la même suite, et nommez les exécutions :

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 lit le taux de réussite attendu sur les graines, avec un intervalle qui compte à la fois les cas que contient la suite et les graines essayées. Dans l'exemple, cinq graines obtiennent de 85,7 % à 90,3 %, et la recette donne 88,2 %, de 83,2 % à 91,9 % : PASS face à 80 %. L'intervalle est approché, donc la politique doit déclarer allow_approximate_methods: true, sinon la réponse est MANUAL_REVIEW. La politique doit contenir au moins une règle ; la commande lit son niveau de confiance, l'option d'acceptation et ses seuils de juge, et rien d'autre. Elle liste aussi les cas dont le verdict change d’une graine à l’autre, et --html FILE écrit une page hors ligne avec chaque cas sous chaque checkpoint.

Chaque point de contrôle compte. Une graine dont l'entraînement a échoué est conservée, et chaque cas auquel elle n'a pas répondu compte comme un échec pour la borne basse et une réussite pour la borne haute, ce qui élargit l'intervalle. Moins de trois graines donnent INSUFFICIENT_EVIDENCE ; il en faut environ cinq pour décider quoi que ce soit. Un juge auquel la porte ne ferait pas confiance ne décide pas non plus d'une recette. Chaque point de contrôle doit exécuter la même suite, avec une seule version de système chacun, et une suite qui déclare des groupes est refusée.

Ce que cela ne peut pas vous dire

• Les perturbations que personne n'a déclarées. Seules les transformations déclarées sont essayées, aux tailles déclarées, et un faible taux de bascule ne dit rien des changements plus grands ni de la recherche d'un attaquant.
• La robustesse certifiée. Aucune borne n'est prouvée pour une entrée ; le taux de bascule est un taux sur les cas de la suite.
• La façon dont le modèle a été entraîné. Oloproof ne peut pas voir si les graines ont été choisies avant l'évaluation de tout point de contrôle, si des exécutions ratées ont été écartées, ni si les points de contrôle ne diffèrent que par leur graine.
• Un échec plus rare qu'environ une graine sur k. Si la recette échoue à l'entraînement une fois sur dix et qu'aucune des cinq graines n'a échoué, l'intervalle ne peut pas le savoir.
• Une fuite que le fichier d'entraînement ne montre pas : quasi-doublons, image redimensionnée, ou lignes utilisées pour le réglage mais absentes du fichier.
• Une fuite dans les exécutions des graines. oloproof seeds ne lit pas leakage: required ; le point de contrôle que vous livrez est soumis à la porte sur sa propre exécution, qui la lit.

Ce que toute évaluation ne peut pas vous dire se trouve sur sa propre page.