Guías
Aprendizaje por refuerzo
Oloproof evalúa una política (policy) de aprendizaje por refuerzo ejecutándola en episodios, o a partir del registro de la política a la que reemplazaría. Ejecútela cuando pueda; use el registro cuando el resultado solo ocurra en el mundo real. Esta página es la referencia de ambas, y el tutorial recorre cada una con un ejemplo ejecutable.
Oloproof no aloja, reinicia ni simula un entorno, y no entrena políticas. Su sistema ejecuta su propio entorno, igual que todo sistema que Oloproof evalúa ejecuta su propio código.
Episodios
Una tarea es un caso. Un episodio es una medición de ella: su sistema ejecuta la política en su entorno y registra el episodio con current_case().rl_episode(...), como un artefacto rl_episode/v1.
| Campo | Tipo | Significado |
|---|---|---|
| steps | lista de pasos, index desde 1 | La recompensa (reward) de cada paso, su coste de restricción (cost, 0 por defecto) y, opcionalmente, action y observation |
| success | true, false o ausente | El propio veredicto del entorno sobre el episodio |
| truncated | booleano, false por defecto | El límite de pasos terminó el episodio antes de un estado terminal |
| horizon | entero, opcional | El límite de pasos; el episodio no puede ser más largo |
El registro contiene cada paso del episodio. Un episodio truncado es uno que el protocolo de evaluación define como terminado en su límite, así que su retorno y su coste están completos, no son cotas inferiores.
Declare el tipo que registra el sistema, para que una ejecución pueda rechazar un evaluador que necesita un registro que el sistema nunca escribe:
system:
name: grid-agent
callable: env:run_baseline
records: [rl_episode/v1]Evaluadores de episodios
| Tipo | Mide | Campos |
|---|---|---|
| episode_return | El retorno, con cada recompensa ponderada por discount en cada paso, como puntuación | return_range (obligatorio), discount (1 por defecto) |
| episode_success | Aprueba cuando el episodio registra success: true; queda como faltante cuando no registra ninguno | ninguno |
| episode_cost_within | Aprueba cuando los costes de los pasos suman como mucho budget | budget (obligatorio) |
return_range es el rango en el que se encuentra todo retorno, como 30 pasos a -1 cada uno en el peor caso y la recompensa del objetivo en el mejor. El intervalo de un retorno medio solo es válido dentro de él, así que un retorno fuera de él detiene la ejecución con salida 2. En el SDK, las clases son EpisodeReturn, EpisodeSuccess y EpisodeCostWithin en oloproof.evaluators.
Varios episodios por tarea
Fije replicates: para ejecutar varios episodios de cada tarea. current_case().replicate indica cuál se está ejecutando (0 para el primero), y forma parte de la clave de la ejecución almacenada, de modo que un entorno que fija la semilla del episodio a partir de él reproduce el mismo episodio para la misma réplica, y una segunda ejecución reutiliza lo que almacenó.
La tarea sigue siendo la unidad. Cada criterio pasa a ser la media sobre las tareas de la media propia de cada tarea sobre sus episodios, y el intervalo cuenta tareas: cinco episodios de una tarea no son cinco tareas independientes.
Una tasa de aprobación sobre tareas replicadas lee la proporción de episodios aprobados de cada tarea. Para preguntar, en cambio, si una tarea aprueba todas las veces, declare una métrica every_replicate:
metrics:
- {id: solved_every_time, type: every_replicate, criterion: episode_success}Una tarea solo cuenta cuando todos sus episodios aprobaron, así que cada tarea es un único aprobado o fallo y se aplica el intervalo binomial exacto. Con un episodio por tarea es igual a la tasa de aprobación. Una tarea con un episodio faltante queda como faltante, incluso cuando otro de sus episodios falló.
Comparar dos políticas
oloproof compare empareja cada tarea consigo misma, y cada lado vale su media sobre sus episodios. La diferencia de un retorno se muestra en la propia unidad del retorno, la de una tasa de aprobación en puntos porcentuales. Las dos ejecuciones pueden ejecutar distinto número de episodios por tarea, salvo para una métrica every_replicate: tener éxito en cada uno de cinco episodios y en el único son preguntas distintas, así que esa comparación no se calcula. Las comparaciones de cuantiles y de ranking no se calculan cuando cualquiera de las dos ejecuciones tiene varios episodios por tarea.
Evaluación fuera de política
Úsela cuando el resultado que le importa solo ocurre en el mundo real (un ticket resuelto, un usuario que volvió) y todavía no puede probar la nueva política con tráfico real. La evidencia es un registro de las decisiones que tomó una política anterior.
Cada caso es una decisión registrada:
{"id":"t001","input":{"topic":"technical","length":"short"},"expected":{"action":"small","logging_probabilities":{"small":0.7,"large":0.3},"reward":1}}| Campo | Significado |
|---|---|
| input | Lo que vio la política cuando decidió |
| expected.action | La acción que tomó la política de registro (logging policy) |
| expected.logging_probabilities | La probabilidad que la política de registro dio a cada acción en ese momento, que suman 1 |
| expected.reward | Lo que siguió, dentro de reward_range; ausente si nunca llegó |
El sistema es la política que quiere evaluar. Recibe input y devuelve su propia probabilidad de cada acción bajo probabilities, o bajo el campo que indique en probabilities_field. Nunca ejecuta un modelo ni toca el mundo real. input contiene solo lo que vio la política de registro cuando decidió: nunca la acción registrada ni la recompensa, que la política evaluada no debe ver. Una política que muestrea su elección devuelve las probabilidades de las que muestrea, no la acción que obtuvo; cada decisión se evalúa de nuevo aunque su entrada se repita. Las acciones se nombran exactamente como las nombra el registro: una acción escrita de otra forma cuenta como una que la política de registro nunca tomó.
| Tipo | Estima |
|---|---|
| off_policy_value | La recompensa media de la política en decisiones como las registradas |
| off_policy_improvement | Esa media menos la de la propia política de registro |
Ambos toman reward_range y propensity_floor, la probabilidad más pequeña que la política de registro dio a cualquier acción que la nueva política pueda tomar. Fíjelo a partir de cómo se diseñó la política de registro (una tasa de exploración, una proporción mínima), nunca probando valores sobre el registro. Cada decisión registrada se repondera por la probabilidad de su acción según la nueva política dividida por la de la política de registro, y el mínimo acota ese peso: sin él no es válido ningún intervalo. En el SDK, las clases son OffPolicyValue y OffPolicyImprovement.
Lo que hace el motor con una decisión que no puede leer tal como viene:
| Situación | Resultado |
|---|---|
| Probabilidades que no suman 1, una acción registrada con probabilidad 0, una recompensa fuera de reward_range | La ejecución se detiene con salida 2: una probabilidad errónea haría erróneo el intervalo sin mostrarlo |
| La nueva política puede tomar una acción registrada con una probabilidad inferior al mínimo | La decisión queda como faltante y se acota en su peor valor |
| La recompensa está ausente | La decisión queda como faltante y se acota en su peor valor |
Lo que supone la respuesta:
- Las probabilidades se registraron cuando decidió la política de registro, y son las que usó. Oloproof nunca las estima.
- La recompensa de cada decisión depende de su propia entrada y acción, no de otras decisiones.
- La política de registro mantuvo las mismas probabilidades a lo largo de la ventana del registro.
- La respuesta describe decisiones como las registradas, durante el periodo que cubre el registro.
El intervalo es ancho cuando el mínimo es pequeño: las decisiones que informan sobre una acción poco elegida son pocas, y cada una cuenta muchas veces. Un registro más largo, y una política de registro que explore más, lo estrechan.
Lo que no está construido
- La evaluación fuera de política de una secuencia de decisiones, donde cada elección cambia lo que viene después.
- Un registro cuya política cambió sus probabilidades a medida que aprendía durante la ventana.
- Probabilidades estimadas a posteriori.
- Alojar o reiniciar entornos y simuladores.
Siguientes pasos
- Tutorial: evaluar una política de aprendizaje por refuerzo: ambas partes, ejecutadas de principio a fin.
- Escribir una suite: las réplicas y los demás campos de la suite.
- Referencia de configuración: todos los campos de estos evaluadores.