Chuyển đến nội dung
Tài liệu
Nhật ký thay đổiGiáMở bảng điều khiển

Hướng dẫn

Kiểm định một mô hình đã huấn luyện

Một mô hình đã huấn luyện có thể đạt điểm cao trên một bộ kiểm thử nó đã từng thấy, đảo ngược câu trả lời khi đầu vào thay đổi một chút, và gặp một seed may mắn. Oloproof kiểm tra từng điều này trước khi mô hình được phát hành: bộ kiểm thử so với dữ liệu huấn luyện, từng dự đoán dưới nhiễu đã khai báo, và công thức huấn luyện qua nhiều seed. Sao chép ví dụ bằng oloproof init --example model-validation: một mô hình cho vay do NumPy huấn luyện, ngoại tuyến, trên dữ liệu tổng hợp.

Bộ kiểm thử so với dữ liệu huấn luyện

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

Mỗi case được so với mọi hàng huấn luyện theo khớp chính xác, sau khi chuyển chuỗi về chữ thường và gộp khoảng trắng (--round làm tròn số, --field chỉ định các khóa cần so sánh). Tệp huấn luyện được đọc trên máy của bạn và không bao giờ được lưu hay gửi đi; bản ghi giữ id của case và số lượng. Khai báo leakage: required trong release.yaml và gate bị chặn (exit 3) cho đến khi một lần kiểm tra sạch của bộ kiểm thử này được ghi lại. Một case tìm thấy trong dữ liệu huấn luyện làm bằng chứng vô hiệu; đó không phải là FAIL của mô hình. Các bản gần trùng lặp không được kiểm tra.

Dự đoán dưới nhiễu

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}

Mỗi case có thêm một bản sao với nhiễu theo seed trên các con số được chỉ định, và flips_under_noise là tỷ lệ case có nhãn bị thay đổi. categorical_swap thay giá trị theo một ánh xạ đã khai báo, còn blur, brightness, occlusion và jpeg thay đổi hình ảnh. Một mô hình hồi quy dùng same_score_within với một dung sai. Con người không thể phán đoán liệu nhiễu trên một hàng có giữ nguyên ý nghĩa của nó hay không, nên một nhiễu loạn số được coi là đã khai báo: tỷ lệ của nó được báo cáo, và một quy tắc dựa trên nó cho kết quả INSUFFICIENT_EVIDENCE cùng transform_declared. Một phép biến đổi hình ảnh được dùng cho gate khi nhãn của con người cho thấy nó giữ nguyên ý nghĩa của từng hình ảnh, giống như một phép biến đổi văn bản. Dự án image/ của ví dụ cho thấy cả hai: một phép làm mờ được nhãn kiểm tra, có tỷ lệ đổi nhãn vượt trần, và một mảng xám mà nhãn cho thấy đôi khi che vết xước, nên quy tắc của nó không quyết định.

Công thức qua các seed

Checkpoint bạn phát hành được quyết định trên lần chạy của chính nó, như mọi hệ thống. Câu hỏi thứ hai là cách bạn huấn luyện có đủ tốt không: huấn luyện lại vào tháng sau và bạn nhận được một lần rút khác. Huấn luyện k checkpoint với k seed, chạy từng cái trên cùng một bộ kiểm thử, và đặt tên cho các lần chạy:

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 đọc tỷ lệ đạt kỳ vọng qua các seed, với một khoảng tính đến cả các case trong bộ kiểm thử lẫn các seed bạn đã thử. Trong ví dụ, năm seed đạt từ 85,7% đến 90,3%, và công thức cho kết quả 88,2%, từ 83,2% đến 91,9%: PASS so với 80%. Khoảng này là xấp xỉ, nên chính sách cần allow_approximate_methods: true, nếu không câu trả lời là MANUAL_REVIEW. Chính sách phải có ít nhất một quy tắc; lệnh đọc mức tin cậy, sự cho phép đó và các ngưỡng của giám khảo, và không gì khác. Lệnh này cũng liệt kê các trường hợp có phán quyết thay đổi giữa các seed, và --html FILE ghi một trang ngoại tuyến với mọi trường hợp dưới mọi checkpoint.

Mọi checkpoint đều được tính. Một seed huấn luyện thất bại vẫn được giữ lại, và mỗi case nó không trả lời được tính là thất bại cho cận dưới và là đạt cho cận trên, nên nó làm rộng khoảng. Ít hơn ba seed cho kết quả INSUFFICIENT_EVIDENCE; cần khoảng năm seed để quyết định bất cứ điều gì. Một giám khảo mà gate không tin cậy cũng không quyết định một công thức. Mọi checkpoint phải chạy cùng một bộ kiểm thử, mỗi cái một phiên bản hệ thống, và một bộ kiểm thử khai báo nhóm sẽ bị từ chối.

Điều này không thể cho bạn biết

  • Những nhiễu loạn không ai khai báo. Chỉ các phép biến đổi đã khai báo được thử, ở các mức đã khai báo, và một tỷ lệ đảo thấp không nói gì về những thay đổi lớn hơn hay sự tìm kiếm của kẻ tấn công.
  • Độ bền vững được chứng nhận. Không có cận nào được chứng minh cho bất kỳ đầu vào nào; tỷ lệ đảo là một tỷ lệ trên các case của bộ kiểm thử.
  • Mô hình đã được huấn luyện như thế nào. Oloproof không thể thấy liệu các seed có được chọn trước khi bất kỳ checkpoint nào được đánh giá, liệu các lần chạy thất bại có bị bỏ đi, hay liệu các checkpoint chỉ khác nhau ở seed.
  • Một lỗi hiếm hơn khoảng một seed trên k. Nếu công thức huấn luyện thất bại một lần trong mười và không seed nào trong năm seed thất bại, khoảng không thể biết điều đó.
  • Rò rỉ mà tệp huấn luyện không thể hiện: các bản gần trùng lặp, một hình ảnh đã đổi kích thước, hoặc các hàng dùng để tinh chỉnh nhưng bị bỏ ra khỏi tệp.
  • Rò rỉ trong các lần chạy seed. oloproof seeds không đọc leakage: required; checkpoint bạn phát hành được gate trên lần chạy của chính nó, lần chạy đó có đọc.

Những gì mọi đánh giá không thể cho bạn biết nằm ở trang riêng.