Pular para o conteúdo

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.

CampoTipoSignificado
stepslista de passos, index a partir de 1O reward de cada passo, o seu cost de restrição (padrão 0) e, opcionalmente, action e observation
successverdadeiro, falso ou ausenteO veredito do próprio ambiente sobre o episódio
truncatedbooleano, padrão falsoO limite de passos encerrou o episódio antes de um estado terminal
horizoninteiro, opcionalO 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

TipoMedeCampos
episode_returnO retorno, com cada recompensa ponderada por discount a cada passo, como uma pontuaçãoreturn_range (obrigatório), discount (padrão 1)
episode_successPassa quando o episódio registra success: true; faltante quando não registra nenhumnenhum
episode_cost_withinPassa quando os custos dos passos somam no máximo budgetbudget (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}}
CampoSignificado
inputO que a política viu quando decidiu
expected.actionA ação que a política de registro tomou
expected.logging_probabilitiesA probabilidade que a política de registro deu a cada ação naquele momento, somando 1
expected.rewardO 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.

TipoEstima
off_policy_valueA recompensa média da política em decisões como as registradas
off_policy_improvementEssa 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çãoResultado
Probabilidades que não somam 1, uma ação registrada com probabilidade 0, uma recompensa fora de reward_rangeA 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 pisoA decisão fica faltante e é limitada no seu pior caso
A recompensa está ausenteA 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