Guias
Aprendizado por reforço
O Oloproof avalia uma política de aprendizado por reforço executando-a em episódios, ou a partir do log da política que ela substituiria. Execute-a quando puder; use o log quando o resultado só acontecer no mundo. Esta página é a referência das duas, e o tutorial percorre cada uma com um exemplo executável.
O Oloproof não hospeda, não reinicia nem simula um ambiente, e não treina políticas. O seu sistema executa o próprio ambiente, assim como todo sistema que ele avalia executa o próprio código.
Episódios
Uma tarefa é um caso. Um episódio é uma medição dela: o seu sistema executa a política no ambiente dele e registra o episódio com current_case().rl_episode(...), como um artefato rl_episode/v1.
| Campo | Tipo | Significado |
|---|---|---|
| steps | lista de passos, index a partir de 1 | O reward de cada passo, o seu cost de restrição (padrão 0) e, opcionalmente, action e observation |
| success | verdadeiro, falso ou ausente | O veredito do próprio ambiente sobre o episódio |
| truncated | booleano, padrão falso | O limite de passos encerrou o episódio antes de um estado terminal |
| horizon | inteiro, opcional | O limite de passos; o episódio não pode ser mais longo |
O registro contém todos os passos do episódio. Um episódio truncado é um que o protocolo de avaliação define como terminando no seu limite, então o seu retorno e o seu custo estão completos, e não são limites inferiores.
Declare o tipo que o sistema registra, para que uma execução possa recusar um avaliador que precisa de um registro que o sistema nunca grava:
system:
name: grid-agent
callable: env:run_baseline
records: [rl_episode/v1]Avaliadores de episódios
| Tipo | Mede | Campos |
|---|---|---|
| episode_return | O retorno, com cada recompensa ponderada por discount a cada passo, como uma pontuação | return_range (obrigatório), discount (padrão 1) |
| episode_success | Passa quando o episódio registra success: true; faltante quando não registra nenhum | nenhum |
| episode_cost_within | Passa quando os custos dos passos somam no máximo budget | budget (obrigatório) |
return_range é a faixa em que todo retorno está, como 30 passos a -1 cada no pior caso e a recompensa do objetivo no melhor. O intervalo de um retorno médio só vale dentro dela, então um retorno fora dela interrompe a execução com saída 2. No SDK, as classes são EpisodeReturn, EpisodeSuccess e EpisodeCostWithin em oloproof.evaluators.
Vários episódios por tarefa
Defina replicates: para executar vários episódios de cada tarefa. current_case().replicate diz qual está em execução (0 para o primeiro), e faz parte da chave da execução armazenada, então um ambiente que gera a semente do episódio a partir dele reproduz o mesmo episódio para a mesma réplica, e uma segunda execução reaproveita o que armazenou.
A tarefa continua sendo a unidade. Cada critério passa a ser a média, sobre as tarefas, da média de cada tarefa sobre os seus episódios, e o intervalo conta tarefas: cinco episódios de uma tarefa não são cinco tarefas independentes.
Uma taxa de aprovação sobre tarefas replicadas lê a proporção de episódios aprovados de cada tarefa. Para perguntar, em vez disso, se uma tarefa passa todas as vezes, declare uma métrica every_replicate:
metrics:
- {id: solved_every_time, type: every_replicate, criterion: episode_success}Uma tarefa só conta quando todos os seus episódios passaram, então cada tarefa é uma aprovação ou uma reprovação e o intervalo binomial exato se aplica. Com um episódio por tarefa, ela é igual à taxa de aprovação. Uma tarefa com um episódio faltante fica faltante, mesmo quando outro dos seus episódios falhou.
Comparando duas políticas
oloproof compare pareia cada tarefa consigo mesma, com cada lado valendo a sua média sobre os seus episódios. A diferença de um retorno é mostrada na própria unidade do retorno, a de uma taxa de aprovação em pontos percentuais. As duas execuções podem ter números diferentes de episódios por tarefa, exceto para uma métrica every_replicate: ter sucesso em cada um de cinco episódios e no único episódio são perguntas diferentes, então essa comparação não é calculada. Comparações de quantil e de ranqueamento não são calculadas quando qualquer uma das execuções tem vários episódios por tarefa.
Avaliação off-policy
Use-a quando o resultado que importa para você só acontece no mundo (um chamado resolvido, um usuário que voltou) e você ainda não pode testar a nova política em tráfego real. A evidência é um log de decisões que uma política mais antiga tomou.
Cada caso é uma decisão registrada:
{"id":"t001","input":{"topic":"technical","length":"short"},"expected":{"action":"small","logging_probabilities":{"small":0.7,"large":0.3},"reward":1}}| Campo | Significado |
|---|---|
| input | O que a política viu quando decidiu |
| expected.action | A ação que a política de registro tomou |
| expected.logging_probabilities | A probabilidade que a política de registro deu a cada ação naquele momento, somando 1 |
| expected.reward | O que se seguiu, dentro de reward_range; ausente se nunca chegou |
O sistema é a política que você quer avaliar. Ele recebe input e retorna a sua própria probabilidade para cada ação em probabilities, ou no campo que você nomear em probabilities_field. Ele nunca executa um modelo nem toca o mundo. input contém só o que a política de registro viu quando decidiu: nunca a ação registrada nem a recompensa, que a política em teste não pode ver. Uma política que sorteia a sua escolha retorna as probabilidades das quais sorteia, não a ação que sorteou; cada decisão é avaliada de novo mesmo quando a sua entrada se repete. As ações são nomeadas exatamente como o log as nomeia: uma ação escrita de outro jeito conta como uma que a política de registro nunca tomou.
| Tipo | Estima |
|---|---|
| off_policy_value | A recompensa média da política em decisões como as registradas |
| off_policy_improvement | Essa média menos a da própria política de registro |
Os dois recebem reward_range e propensity_floor, a menor probabilidade que a política de registro deu a qualquer ação que a nova política possa tomar. Defina-o a partir de como a política de registro foi projetada (uma taxa de exploração, uma participação mínima), nunca testando valores no log. Cada decisão registrada é reponderada pela probabilidade da sua ação segundo a nova política dividida pela da política de registro, e o piso limita esse peso: sem ele, nenhum intervalo vale. No SDK, as classes são OffPolicyValue e OffPolicyImprovement.
O que o engine faz com uma decisão que não consegue ler como foi dada:
| Situação | Resultado |
|---|---|
| Probabilidades que não somam 1, uma ação registrada com probabilidade 0, uma recompensa fora de reward_range | A execução para com saída 2: uma probabilidade errada tornaria o intervalo errado sem mostrar isso |
| A nova política pode tomar uma ação registrada com probabilidade abaixo do piso | A decisão fica faltante e é limitada no seu pior caso |
| A recompensa está ausente | A decisão fica faltante e é limitada no seu pior caso |
O que a resposta pressupõe:
- As probabilidades foram registradas quando a política de registro decidiu, e são as que ela usou. O Oloproof nunca as estima.
- A recompensa de cada decisão depende da sua própria entrada e ação, não de outras decisões.
- A política de registro manteve as mesmas probabilidades ao longo da janela do log.
- A resposta descreve decisões como as registradas, no período que o log cobre.
O intervalo é largo quando o piso é pequeno: as decisões que informam sobre uma ação raramente escolhida são poucas, e cada uma conta muitas vezes. Um log mais longo, e uma política de registro que explora mais, o estreitam.
O que não foi construído
- Avaliação off-policy de uma sequência de decisões, em que cada escolha muda o que vem a seguir.
- Um log cuja política mudou as suas probabilidades enquanto aprendia durante a janela.
- Probabilidades estimadas depois do fato.
- Hospedar ou reiniciar ambientes e simuladores.
Próximos passos
- Tutorial: avaliar uma política de aprendizado por reforço: as duas partes, executadas de ponta a ponta.
- Escrevendo uma suíte: réplicas e os outros campos da suíte.
- Referência de configuração: todos os campos destes avaliadores.