Tutorial: mengevaluasi kebijakan reinforcement learning

Panduan yang dapat dijalankan untuk dua jenis pertanyaan reinforcement learning: seberapa baik kinerja sebuah kebijakan (policy) yang dapat Anda jalankan selama beberapa episode, dan seberapa baik hasil yang akan dicapai sebuah kebijakan yang tidak dapat Anda coba di dunia nyata, dinilai dari log kebijakan yang akan digantikannya. Kedua contoh berjalan secara lokal tanpa kredensial penyedia.

Referensi untuk setiap field dan evaluator adalah Reinforcement learning; istilah kasus, evaluator, metrik, interval, dan gerbang ada di Konsep inti. Halaman ini adalah jalur praktik melalui semuanya.

Apa yang dilakukan dan tidak dilakukan Oloproof di sini

Oloproof tidak menjalankan lingkungan Anda, tidak meng-hosting simulator, dan tidak melatih kebijakan. Sistem Anda menjalankan setiap episode di lingkungannya sendiri dan merekamnya sebagai artefak rl_episode/v1, dan setiap metrik episode dibaca dari rekaman itu. Pada bagian kedua tidak ada yang dijalankan sama sekali: kebijakan yang diuji hanya menyatakan probabilitas yang akan diberikannya pada setiap aksi.

Pisahkan kedua pertanyaan itu:

Prasyarat

• Python 3.11 atau yang lebih baru, dan Oloproof terpasang (pip install oloproof).
• Proyek contoh, yang disertakan dalam paket. Salin ke direktori baru:

oloproof init --example rl my-rl

Isinya dua proyek, episodes/ dan off_policy/. Setiap perintah di bawah dijalankan dari dalam salah satunya, dan bukti disimpan di direktori .oloproof/ miliknya.

Bagian 1: kebijakan yang dapat Anda jalankan

cd my-rl/episodes

File-filenya

Sebuah episode bergerak satu sel per langkah sampai mencapai tujuan atau kehabisan langkah. Setiap langkah bernilai -1 dan mencapai tujuan bernilai +10, sehingga return berada di antara -30 (30 langkah, tanpa tujuan) dan 10. Memasuki sel bahaya berbiaya 1: itulah batasan keselamatannya. Satu dari sepuluh gerakan tergelincir ke arah acak, apa pun pilihan kebijakannya, sehingga kebijakan yang sama dapat berhasil secara berbeda pada grid yang sama.

Merekam episode

Sistem menjalankan episode itu sendiri dan menyerahkan rekamannya ke perekam kasus:

@system(name="grid-agent", version="wander-v1", records=("rl_episode/v1",))
def run_baseline(task):
    return _run(task, wander)


def _run(task, policy):
    recorder = current_case()
    record = episode(task, policy, seed=task["seed"] * 1000 + recorder.replicate)
    recorder.rl_episode(record)
    return {"success": record["success"], "steps": len(record["steps"])}

Rekaman itu mencantumkan reward dan biaya setiap langkah, apakah episode mencapai tujuan (success), dan apakah batas langkah yang mengakhirinya (truncated).

Beberapa episode per tugas

oloproof.yaml mendeklarasikan replicates: 5, sehingga setiap tugas menjalankan lima episode. current_case().replicate menyatakan episode yang mana (0 sampai 4), dan lingkungan menurunkan seed episode darinya: episode yang sama dari tugas yang sama selalu terulang dengan cara yang sama, dan eksekusi kedua memakai kembali episode yang tersimpan alih-alih menjalankannya lagi.

Tugas tetap menjadi unitnya. Setiap kriteria adalah rata-rata, atas 24 tugas, dari rata-rata masing-masing tugas atas lima episodenya, sehingga interval menghitung 24 tugas dan bukan 120 episode. Menghitung episode sama saja dengan berpura-pura bahwa lima episode dari satu grid adalah lima grid yang independen.

Evaluatornya:

evaluators:
  - {type: episode_return, return_range: [-30, 10]}
  - {type: episode_success}
  - {type: episode_cost_within, budget: 0, criterion: hazard_free}
metrics:
  - {id: solved_every_time, type: every_replicate, criterion: episode_success}

return_range wajib: interval atas return rata-rata hanya berlaku di dalam rentang tempat setiap return berada, dan return di luarnya menghentikan eksekusi. solved_every_time hanya menghitung sebuah tugas ketika kelima episodenya mencapai tujuan.

Jalankan baseline

oloproof run

Gate: BLOCK (exit 3)
                                        Decisions
┏━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ Rule          ┃ Metric          ┃ State                 ┃ Reasons                     ┃
┡━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┩
│ success-floor │ episode_success │ INSUFFICIENT_EVIDENCE │ interval_overlaps_threshold │
│ safety-floor  │ hazard_free     │ INSUFFICIENT_EVIDENCE │ interval_overlaps_threshold │
└───────────────┴─────────────────┴───────────────────────┴─────────────────────────────┘
                                                           Metrics
┏━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━┳━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ Metric            ┃ Estimate ┃ Interval        ┃ N                                                                         ┃
┡━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━╇━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┩
│ episode_return    │ -10.51   │ [-16.44, -5.11] │ mean of 24 observed · 0 missing · 0 excluded                              │
│ episode_success   │ 76.7%    │ [55.4%, 89.6%]  │ 24 cases observed · 0 missing · 0 excluded · 5 replicates each · 14 flaky │
│ hazard_free       │ 29.2%    │ [10.3%, 54.0%]  │ 24 cases observed · 0 missing · 0 excluded · 5 replicates each · 9 flaky  │
│ solved_every_time │ 37.5%    │ [18.7%, 59.5%]  │ 9 / 24 observed · 0 missing · 0 excluded · 5 replicates each · 14 flaky   │
└───────────────────┴──────────┴─────────────────┴───────────────────────────────────────────────────────────────────────────┘
Cache: execution 0 hit/120 miss; judgment 0 hit/360 miss

Bacalah baris demi baris:

• Kebijakan yang berkeliaran mencapai tujuan pada 76.7% episode, tetapi intervalnya membentang dari 55.4% sampai 89.6%, sehingga batas minimum 75% tidak terlampaui maupun terlewat: INSUFFICIENT_EVIDENCE.
• Kebijakan itu hanya menyelesaikan 9 dari 24 tugas pada setiap dari kelima episodenya. "Biasanya berhasil" dan "berhasil setiap kali" adalah klaim yang berbeda, dan agen yang akan berjalan tanpa pengawasan membutuhkan yang kedua.
• 14 tugas tidak stabil (flaky): keberhasilannya berubah-ubah di antara episode yang identik. Satu episode per tugas tidak akan dapat menunjukkannya.
• Kebijakan itu menghindari bahaya pada 29.2% episode. Ujung atas interval, 54.0%, berada di atas batas minimum 50%, sehingga bahkan rekam jejak seburuk ini belum membuktikan bahwa kebijakan itu tidak aman.

Lihat satu tugas:

oloproof inspect RUN_ID --case grid_03

output: {
  "success": false,
  "steps": 30
}
judgments:
  episode_return: score -30
  episode_success: failed
  hazard_free: passed

Episode pertama dari grid_03 kehabisan langkah: return -30, tidak mencapai tujuan, tidak memasuki bahaya.

Jalankan kandidat

oloproof run --config candidate.yaml

│ success-floor │ episode_success │ PASS                  │ lower_bound_meets_minimum   │
│ safety-floor  │ hazard_free     │ INSUFFICIENT_EVIDENCE │ interval_overlaps_threshold │

│ episode_return    │ 0.42     │ [-5.78, 2.59]   │ mean of 24 observed · 0 missing · 0 excluded                             │
│ episode_success   │ 100.0%   │ [79.9%, 100.0%] │ 24 cases observed · 0 missing · 0 excluded · 5 replicates each           │
│ hazard_free       │ 57.5%    │ [29.3%, 81.5%]  │ 24 cases observed · 0 missing · 0 excluded · 5 replicates each · 6 flaky │
│ solved_every_time │ 100.0%   │ [85.7%, 100.0%] │ 24 / 24 observed · 0 missing · 0 excluded · 5 replicates each            │

Perencana mencapai tujuan pada setiap episode, sehingga batas minimum keberhasilan lolos. Ia masih memasuki bahaya: beberapa grid tidak memiliki jalur yang aman, dan lantai yang licin mendorongnya masuk ke bahaya lain. Tingkat keselamatannya sebesar 57.5% berada di atas batas minimum, tetapi 24 tugas belum dapat menunjukkan bahwa nilainya di atas 50%.

Bandingkan kedua kebijakan

oloproof compare CANDIDATE_RUN_ID BASELINE_RUN_ID --policy comparison.yaml

episode_return: +10.92 [+0.21, +17.74] · 24 paired · 0 missing · 0 excluded
episode_success: +23.3 points [-3.2, +44.6] · 24 paired · 0 missing · 0 excluded
hazard_free: +28.3 points [-2.4, +54.7] · 24 paired · 0 missing · 0 excluded
solved_every_time: +62.5 points [+24.3, +87.7] · 24 paired · 0 missing · 0 excluded
Decisions
  return-better  episode_return  superiority  PASS  difference_above_zero
  safety-no-worse  hazard_free  non-inferiority, margin 5.0 points  PASS  lower_bound_above_margin
Gate: ALLOW (exit 0)

Perbandingan memasangkan setiap tugas dengan dirinya sendiri, dengan setiap sisi bernilai rata-ratanya atas lima episode. Selisih return dinyatakan dalam satuan return itu sendiri: perencana memperoleh sekitar 10.9 lebih banyak per episode, dan setidaknya 0.21 lebih banyak. Dengan dipasangkan pada grid yang sama, margin 5 poin sudah cukup untuk menunjukkan bahwa perencana tidak kurang aman, meskipun tidak satu pun eksekusi secara terpisah dapat menuntaskan batas minimum keselamatannya sendiri.

Bagian 2: kebijakan yang dinilai dari log

cd ../off_policy

Sebuah layanan dukungan merutekan setiap tiket ke model kecil atau model besar. Router saat ini memilih model kecil 70% dari waktu dan model besar 30%, secara acak. Anda telah menulis aturan baru: tiket teknis, dan tiket penagihan yang panjang, dikirim ke model besar. Anda belum dapat mencobanya pada tiket nyata, tetapi log router lama dapat menjawab untuknya. Itulah evaluasi off-policy.

Log dan file-filenya

Setiap baris log adalah satu keputusan:

{"id":"t001","input":{"topic":"technical","length":"short"},"expected":{"action":"small","logging_probabilities":{"small":0.7,"large":0.3},"reward":1}}

input adalah apa yang dilihat router, action apa yang dipilihnya, logging_probabilities probabilitas yang diberikannya pada setiap model saat itu, dan reward apakah tiket itu terselesaikan. Aturan baru hanya menjawab dengan probabilitasnya sendiri:

@system(name="ticket-router", version="by-topic-v1")
def route_by_topic(ticket):
    large = ticket["topic"] == "technical" or (
        ticket["topic"] == "billing" and ticket["length"] == "long"
    )
    return {"probabilities": {"small": 0.0 if large else 1.0, "large": 1.0 if large else 0.0}}

Evaluatornya:

evaluators:
  - {type: off_policy_value, reward_range: [0, 1], propensity_floor: 0.3}
  - {type: off_policy_improvement, reward_range: [0, 1], propensity_floor: 0.3}

Setiap keputusan yang dicatat diberi bobot ulang menurut seberapa jauh lebih mungkin, atau lebih tidak mungkin, aturan baru mengambilnya dibandingkan router lama: tiket yang dikirim router lama ke model besar dengan probabilitas 0.3, dan yang akan selalu dikirim ke sana oleh aturan baru, dihitung 1 / 0.3 kali, dan keputusan yang tidak akan pernah diambil aturan baru dihitung nol. propensity_floor adalah probabilitas terkecil yang diberikan router lama pada model mana pun yang dapat dipilihnya. Nilai ini membatasi bobot tersebut, dan tanpa batas itu tidak ada interval yang berlaku.

Jalankan

oloproof run

│ resolution-floor    │ off_policy_value       │ PASS                  │ lower_bound_meets_minimum                                                          │
│ better-than-current │ off_policy_improvement │ INSUFFICIENT_EVIDENCE │ interval_overlaps_threshold                                                        │
│                     │                        │                       │ about 2633 more cases would decide it, if the observed values hold (3233 in total) │

│ off_policy_value       │ 0.775    │ [0.632, 0.921]  │ mean of 600 observed · 0 missing · 0 excluded │
│ off_policy_improvement │ 0.060    │ [-0.064, 0.188] │ mean of 600 observed · 0 missing · 0 excluded │

Aturan baru diperkirakan akan menyelesaikan 77.5% tiket dan, pada tingkat kepercayaan 95%, setidaknya 63.2%: batas minimum 60% lolos. Apakah aturan itu mengungguli router saat ini belum tuntas. Estimasinya 6 poin lebih baik, tetapi intervalnya membentang dari 6.4 poin lebih buruk sampai 18.8 lebih baik, dan mesin menyatakan kira-kira berapa banyak lagi keputusan tercatat yang akan menuntaskannya.

Lebar itu adalah harga dari belajar dari pilihan pihak lain. Hanya 30% tiket yang kebetulan dikirim router lama ke model besar yang mengatakan sesuatu tentang model besar, dan masing-masing dihitung lebih dari tiga kali. Dua hal mempersempitnya: log yang lebih panjang, dan router lama yang lebih banyak bereksplorasi.

Mencatat keputusan dari sistem Anda sendiri

• Rekam probabilitas ketika router memutuskan, bukan sesudahnya, dan rekam probabilitas setiap opsi, bukan hanya opsi yang dipilih. Oloproof tidak mengestimasinya: probabilitas hasil tebakan akan membuat interval bertumpu pada tebakan itu.
• Masukkan ke input hanya apa yang dilihat router ketika memutuskan, jangan pernah opsi yang dipilih atau hasilnya: kebijakan yang diuji tidak boleh melihatnya.
• Jika kebijakan baru Anda mengambil sampel untuk pilihannya, kembalikan probabilitas yang menjadi sumber sampelnya, bukan satu opsi yang diambilnya. Namai setiap opsi persis seperti di log: opsi yang dieja berbeda dihitung sebagai opsi yang tidak pernah dipilih router lama.
• Pertahankan sedikit keacakan dalam perutean produksi. Kebijakan yang tidak pernah memilih sebuah opsi tidak meninggalkan apa pun di log untuk menilai aturan yang akan memilihnya.
• Jawabannya menggambarkan tiket seperti yang dicatat, selama periode yang dicakup log. Perubahan pada lalu lintas Anda berada di luarnya.
• Baris yang cacat (probabilitas yang tidak berjumlah 1, opsi terpilih dengan probabilitas 0, reward di luar reward_range) menghentikan eksekusi. Keputusan yang akan diambil aturan baru dengan opsi yang diberi probabilitas di bawah batas bawah oleh router lama, atau yang reward-nya tidak ada, dihitung sebagai hilang dan melebarkan interval.

Apa yang belum dibangun

• Evaluasi off-policy atas serangkaian keputusan, ketika pilihan pada setiap langkah mengubah apa yang terjadi berikutnya. Hanya satu keputusan per kasus yang didukung.
• Log yang router-nya mengubah probabilitasnya sambil belajar selama jendela waktu itu.
• Meng-hosting atau mengatur ulang lingkungan, simulator, atau robot.

Langkah selanjutnya

• Reinforcement learning: referensi untuk evaluator ini dan rekaman episode.
• Menulis suite: replikasi dan field suite lainnya.
• Membandingkan kandidat dengan baseline: apa yang dibaca perbandingan berpasangan.
• Konsep inti: apa yang dijangkau sebuah hasil dan apa yang tidak.