Walidacja wytrenowanego modelu

Wytrenowany model może dobrze wypaść na zestawie, który już widział, zmienić odpowiedź, gdy dane wejściowe nieco się przesuną, i trafić na szczęśliwy seed. Oloproof sprawdza każdą z tych rzeczy, zanim model trafi do wdrożenia: zestaw względem danych treningowych, każdą predykcję pod zadeklarowanym szumem i przepis treningowy na kilku seedach. Skopiuj przykład poleceniem oloproof init --example model-validation: model kredytowy wytrenowany przez NumPy, offline, na danych syntetycznych.

Zestaw względem danych treningowych

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

Każdy przypadek jest porównywany z każdym wierszem treningowym przez dokładne dopasowanie, po zamianie tekstu na małe litery i scaleniu białych znaków (--round zaokrągla liczby, --field wskazuje klucze do porównania). Plik treningowy jest czytany na Twoim komputerze i nigdy nie jest zapisywany ani wysyłany; rekord zachowuje identyfikatory przypadków i liczności. Zadeklaruj leakage: required w release.yaml, a bramka będzie zablokowana (exit 3), dopóki nie zostanie zapisane czyste sprawdzenie tego zestawu. Przypadek znaleziony w danych treningowych unieważnia dowody; nie jest to FAIL modelu. Bliskie duplikaty nie są sprawdzane.

Predykcje pod szumem

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}

Każdy przypadek zyskuje kopię z szumem o ustalonym seedzie na wskazanych liczbach, a flips_under_noise to odsetek przypadków, których etykieta się zmieniła. categorical_swap zastępuje wartości według zadeklarowanej mapy, a blur, brightness, occlusion i jpeg zmieniają obrazy. Regresor używa same_score_within z tolerancją. Ludzie nie potrafią ocenić, czy szum w wierszu zachowuje jego znaczenie, więc perturbacja liczbowa jest deklarowana: jej odsetek jest raportowany, a reguła na nim daje INSUFFICIENT_EVIDENCE z transform_declared. Transformacja obrazu może bramkować, gdy etykiety ludzi pokażą, że zachowuje znaczenie każdego obrazu, tak jak transformacja tekstu. Projekt image/ w przykładzie pokazuje oba przypadki: rozmycie sprawdzone etykietami, którego odsetek zmian nie mieści się w limicie, oraz szarą łatę, która według etykiet czasem zakrywa rysę, więc jej reguła wstrzymuje decyzję.

Przepis na kilku seedach

Checkpoint, który wdrażasz, jest rozstrzygany na podstawie własnego przebiegu, jak każdy system. Drugie pytanie brzmi, czy sposób, w jaki trenujesz, jest wystarczająco dobry: wytrenuj ponownie w przyszłym miesiącu, a otrzymasz inne losowanie. Wytrenuj k checkpointów z k seedami, uruchom każdy na tym samym zestawie i nazwij przebiegi:

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 odczytuje oczekiwany odsetek zaliczeń na seedach, z przedziałem uwzględniającym zarówno przypadki w zestawie, jak i wypróbowane seedy. W przykładzie pięć seedów uzyskuje od 85,7% do 90,3%, a przepis daje 88,2%, od 83,2% do 91,9%: PASS względem 80%. Przedział jest przybliżony, więc polityka wymaga allow_approximate_methods: true, w przeciwnym razie odpowiedzią jest MANUAL_REVIEW. Polityka musi zawierać co najmniej jedną regułę; polecenie odczytuje jej poziom ufności, tę zgodę i progi sędziów, i nic więcej. Wymienia też przypadki, których werdykt zmienia się między ziarnami, a --html FILE zapisuje jedną stronę offline z każdym przypadkiem pod każdym checkpointem.

Liczy się każdy checkpoint. Seed, którego trening się nie powiódł, zostaje zachowany, a każdy przypadek, na który nie odpowiedział, liczy się jako porażka dla dolnej granicy i jako zaliczenie dla górnej, więc poszerza przedział. Mniej niż trzy seedy dają INSUFFICIENT_EVIDENCE; do rozstrzygnięcia czegokolwiek potrzeba około pięciu. Sędzia, któremu bramka by nie zaufała, nie rozstrzyga też o przepisie. Każdy checkpoint musi uruchomić ten sam zestaw, każdy z jedną wersją systemu, a zestaw deklarujący grupy jest odrzucany.

Czego to nie powie

• Perturbacje, których nikt nie zadeklarował. Próbowane są tylko zadeklarowane transformacje, w zadeklarowanych rozmiarach, a niski odsetek zmian nic nie mówi o większych zmianach ani o poszukiwaniach atakującego.
• Certyfikowana odporność. Dla żadnego wejścia nie jest dowodzone żadne ograniczenie; odsetek zmian to odsetek na przypadkach zestawu.
• Jak model był trenowany. Oloproof nie widzi, czy seedy wybrano przed oceną jakiegokolwiek checkpointu, czy nieudane przebiegi odrzucono, ani czy checkpointy różnią się tylko seedem.
• Awaria rzadsza niż mniej więcej jeden seed na k. Jeśli przepis nie trenuje się raz na dziesięć razy, a żaden z pięciu seedów nie zawiódł, przedział nie może o tym wiedzieć.
• Wyciek, którego plik treningowy nie pokazuje: bliskie duplikaty, obraz o zmienionym rozmiarze lub wiersze użyte do strojenia, ale pominięte w pliku.
• Wyciek w przebiegach seedów. oloproof seeds nie odczytuje leakage: required; wdrażany checkpoint jest bramkowany na własnym przebiegu, który to robi.

To, czego nie powie żadna ewaluacja, opisuje osobna strona.