Guide

Apprendimento per rinforzo

Oloproof valuta una policy di apprendimento per rinforzo eseguendola in episodi, oppure a partire dal log della policy che sostituirebbe. Eseguila quando puoi; usa il log quando l'esito si verifica solo nel mondo reale. Questa pagina è il riferimento per entrambi i modi, e il tutorial li percorre ciascuno su un esempio eseguibile.

Oloproof non ospita, non reimposta e non simula un ambiente, e non addestra policy. Il tuo sistema esegue il proprio ambiente, come ogni sistema che valuta esegue il proprio codice.

Episodi

Un'attività è un caso. Un episodio è una misura di essa: il tuo sistema esegue la policy nel suo ambiente e registra l'episodio con current_case().rl_episode(...), come artefatto rl_episode/v1.

Campo	Tipo	Significato
steps	lista di passi, index a partire da 1	La reward di ogni passo, il suo cost di vincolo (predefinito 0) e, facoltativamente, action e observation
success	true, false o assente	Il verdetto dell'ambiente stesso sull'episodio
truncated	booleano, predefinito false	Il limite di passi ha terminato l'episodio prima di uno stato terminale
horizon	intero, facoltativo	Il limite di passi; l'episodio non può essere più lungo

Il record contiene ogni passo dell'episodio. Un episodio troncato è uno che il protocollo di valutazione definisce come terminato al suo limite, quindi il suo ritorno e il suo costo sono completi, non limiti inferiori.

Dichiara il tipo che il sistema registra, così che un'esecuzione possa rifiutare un valutatore che ha bisogno di un record che il sistema non scrive mai:

system:
  name: grid-agent
  callable: env:run_baseline
  records: [rl_episode/v1]

Valutatori di episodio

Tipo	Misura	Campi
episode_return	Il ritorno, con ogni ricompensa pesata per discount a ogni passo, come punteggio	return_range (obbligatorio), discount (predefinito 1)
episode_success	Pass quando l'episodio registra success: true; mancante quando non ne registra alcuno	nessuno
episode_cost_within	Pass quando i costi dei passi sommano al massimo a budget	budget (obbligatorio)

return_range è l'intervallo in cui si trova ogni ritorno, per esempio 30 passi a -1 ciascuno nel caso peggiore e la ricompensa dell'obiettivo nel caso migliore. L'intervallo di confidenza su un ritorno medio vale solo al suo interno, quindi un ritorno che ne esce arresta l'esecuzione con uscita 2. Nell'SDK le classi sono EpisodeReturn, EpisodeSuccess ed EpisodeCostWithin in oloproof.evaluators.

Più episodi per attività

Imposta replicates: per eseguire più episodi di ogni attività. current_case().replicate dice quale è in esecuzione (0 per il primo), e fa parte della chiave dell'esecuzione memorizzata, quindi un ambiente che inizializza il seed dell'episodio a partire da esso riproduce lo stesso episodio per la stessa replica, e una seconda esecuzione riusa ciò che ha memorizzato.

L'attività resta l'unità. Ogni criterio diventa la media sulle attività della media di ciascuna attività sui propri episodi, e l'intervallo conta le attività: cinque episodi di una sola attività non sono cinque attività indipendenti.

Un tasso di pass su attività replicate legge la quota di episodi superati di ciascuna attività. Per chiedere invece se un'attività passa ogni volta, dichiara una metrica every_replicate:

metrics:
  - {id: solved_every_time, type: every_replicate, criterion: episode_success}

Un'attività conta solo quando tutti i suoi episodi sono passati, quindi ogni attività è un solo pass o fail e si applica l'intervallo binomiale esatto. Con un episodio per attività è uguale al tasso di pass. Un'attività con un episodio mancante è mancante, anche quando un altro dei suoi episodi è fallito.

Confrontare due policy

oloproof compare appaia ogni attività con sé stessa, e ciascun lato vale la sua media sui propri episodi. La differenza di un ritorno è mostrata nell'unità del ritorno stesso, quella di un tasso di pass in punti percentuali. Le due esecuzioni possono eseguire un numero diverso di episodi per attività, tranne che per una metrica every_replicate: riuscire in ognuno di cinque episodi e nell'unico episodio sono domande diverse, quindi quel confronto non viene calcolato. I confronti di quantile e di ranking non vengono calcolati quando una delle due esecuzioni ha più episodi per attività.

Valutazione off-policy

Usala quando l'esito che ti interessa si verifica solo nel mondo reale (un ticket risolto, un utente che è tornato) e non puoi ancora provare la nuova policy sul traffico reale. L'evidenza è un log delle decisioni prese da una policy precedente.

Ogni caso è una decisione registrata:

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

Campo	Significato
input	Ciò che la policy vedeva quando ha deciso
expected.action	L'azione eseguita dalla policy di logging
expected.logging_probabilities	La probabilità che la policy di logging dava a ogni azione in quel momento, con somma 1
expected.reward	Ciò che è seguito, entro reward_range; assente se non è mai arrivato

Il sistema è la policy che vuoi valutare. Riceve input e restituisce la propria probabilità per ogni azione sotto probabilities, o nel campo che indichi in probabilities_field. Non esegue mai un modello e non tocca mai il mondo reale. input contiene solo ciò che la policy di logging vedeva quando ha deciso: mai l'azione registrata né la ricompensa, che la policy sotto test non deve vedere. Una policy che campiona la propria scelta restituisce le probabilità da cui campiona, non l'azione che ha estratto; ogni decisione viene valutata da capo anche quando il suo input si ripete. Le azioni sono nominate esattamente come le nomina il log: un'azione scritta in modo diverso conta come un'azione che la policy di logging non ha mai eseguito.

Tipo	Stima
off_policy_value	La ricompensa media della policy su decisioni simili a quelle registrate
off_policy_improvement	Quella media meno quella della policy di logging stessa

Entrambi accettano reward_range e propensity_floor, la più piccola probabilità che la policy di logging ha dato a una qualsiasi azione che la nuova policy può eseguire. Impostala in base a come è stata progettata la policy di logging (un tasso di esplorazione, una quota minima), mai provando valori sul log. Ogni decisione registrata viene ripesata per la probabilità della sua azione secondo la nuova policy divisa per quella secondo la policy di logging, e la soglia limita quel peso: senza di essa nessun intervallo regge. Nell'SDK le classi sono OffPolicyValue e OffPolicyImprovement.

Che cosa fa il motore con una decisione che non può leggere così com'è:

Situazione	Risultato
Probabilità la cui somma non è 1, un'azione registrata con probabilità 0, una ricompensa fuori da reward_range	L'esecuzione si arresta con uscita 2: una probabilità sbagliata renderebbe sbagliato l'intervallo senza mostrarlo
La nuova policy può eseguire un'azione registrata con probabilità sotto la soglia	La decisione è mancante e delimitata nel caso peggiore
La ricompensa è assente	La decisione è mancante e delimitata nel caso peggiore

Che cosa presuppone la risposta:

Le probabilità sono state registrate quando la policy di logging ha deciso, e sono quelle che ha usato. Oloproof non le stima mai.
La ricompensa di ogni decisione dipende dal suo input e dalla sua azione, non da altre decisioni.
La policy di logging ha mantenuto le stesse probabilità per tutto l'arco di tempo del log.
La risposta descrive decisioni simili a quelle registrate, nel periodo coperto dal log.

L'intervallo è ampio quando la soglia è piccola: le decisioni che informano su un'azione scelta raramente sono poche, e ciascuna conta molte volte. Un log più lungo, e una policy di logging che esplora di più, lo restringono.

Che cosa non è costruito

La valutazione off-policy di una sequenza di decisioni, in cui ogni scelta cambia ciò che viene dopo.
Un log la cui policy ha cambiato le proprie probabilità mentre imparava durante l'arco di tempo.
Probabilità stimate a posteriori.
Ospitare o reimpostare ambienti e simulatori.

Dove andare dopo

Tutorial: valutare una policy di apprendimento per rinforzo: entrambe le parti, eseguite da capo a fondo.
Scrivere una suite: le repliche e gli altri campi della suite.
Riferimento della configurazione: ogni campo di questi valutatori.