Validando um modelo treinado

Um modelo treinado pode pontuar bem em uma suíte que já viu, inverter a resposta quando uma entrada muda um pouco e tirar uma seed de sorte. O Oloproof verifica cada uma dessas coisas antes que o modelo vá para produção: a suíte contra os dados de treinamento, cada predição sob ruído declarado e a receita de treinamento ao longo de várias seeds. Copie o exemplo com oloproof init --example model-validation: um modelo de empréstimo treinado pelo NumPy, offline, com dados sintéticos.

A suíte contra os dados de treinamento

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

Cada caso é comparado com cada linha de treinamento por correspondência exata, depois de passar strings para minúsculas e reduzir espaços em branco (--round arredonda números, --field indica as chaves a comparar). O arquivo de treinamento é lido na sua máquina e nunca é armazenado nem enviado; o registro guarda ids de casos e contagens. Declare leakage: required em release.yaml e o gate fica bloqueado (exit 3) até que uma verificação limpa desta suíte seja registrada. Um caso encontrado nos dados de treinamento invalida a evidência; não é um FAIL do modelo. Quase duplicatas não são verificadas.

Predições sob ruído

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 ganha uma cópia com ruído semeado nos números indicados, e flips_under_noise é a fração de casos cujo rótulo mudou. categorical_swap substitui valores por um mapa declarado, e blur, brightness, occlusion e jpeg alteram imagens. Um regressor usa same_score_within com uma tolerância. As pessoas não conseguem julgar se o ruído em uma linha preserva seu significado, então uma perturbação numérica é declarada: sua taxa é reportada, e uma regra sobre ela resulta em INSUFFICIENT_EVIDENCE com transform_declared. Uma transformação de imagem passa a decidir gates quando os rótulos das pessoas mostram que ela preserva o significado de cada imagem, como acontece com uma transformação de texto. O projeto image/ do exemplo mostra os dois: um desfoque que os rótulos verificam, cuja taxa de mudança não passa de um teto, e uma mancha cinza que, pelos rótulos, às vezes esconde o risco, cuja regra se abstém.

A receita ao longo das seeds

O checkpoint que você publica é decidido na sua própria execução, como qualquer sistema. Uma segunda pergunta é se o seu modo de treinar é bom o bastante: treine de novo no mês que vem e você obtém outro sorteio. Treine k checkpoints com k seeds, rode cada um na mesma suíte e nomeie as execuções:

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 lê a taxa de aprovação esperada ao longo das seeds, com um intervalo que conta tanto os casos da suíte quanto as seeds que você testou. No exemplo, cinco seeds pontuam de 85,7% a 90,3%, e a receita resulta em 88,2%, de 83,2% a 91,9%: PASS contra 80%. O intervalo é aproximado, então a política precisa de allow_approximate_methods: true; caso contrário, a resposta é MANUAL_REVIEW. A política precisa ter pelo menos uma regra; o comando lê o nível de confiança, a autorização e os limites dos juízes, e nada mais. Ele também lista os casos cujo veredito muda de uma semente para outra, e --html FILE grava uma página offline com cada caso sob cada checkpoint.

Todo checkpoint conta. Uma seed cujo treinamento falhou é mantida, e cada caso que ela não respondeu conta como falha para o limite inferior e como aprovação para o superior, então alarga o intervalo. Menos de três seeds resultam em INSUFFICIENT_EVIDENCE; são necessárias cerca de cinco para decidir qualquer coisa. Um juiz em que o gate não confiaria também não decide uma receita. Todo checkpoint precisa rodar a mesma suíte, com uma versão de sistema cada, e uma suíte que declara grupos é recusada.

O que isto não pode dizer

• Perturbações que ninguém declarou. Só as transformações declaradas são testadas, nos tamanhos declarados, e uma taxa de inversão baixa não diz nada sobre mudanças maiores ou sobre a busca de um atacante.
• Robustez certificada. Nenhum limite é provado para nenhuma entrada; a taxa de inversão é uma taxa sobre os casos da suíte.
• Como o modelo foi treinado. O Oloproof não vê se as seeds foram escolhidas antes de qualquer checkpoint ser avaliado, se execuções que falharam foram descartadas, nem se os checkpoints diferem apenas pela seed.
• Uma falha mais rara que cerca de uma seed em k. Se a receita falha ao treinar uma vez em dez e nenhuma de cinco seeds falhou, o intervalo não tem como saber.
• Vazamento que o arquivo de treinamento não mostra: quase duplicatas, uma imagem redimensionada ou linhas usadas para ajuste mas deixadas fora do arquivo.
• Vazamento nas execuções das seeds. oloproof seeds não lê leakage: required; o checkpoint que você publica passa pelo gate na sua própria execução, que lê.

O que nenhuma avaliação pode dizer está em uma página própria.