Guides

Apprentissage par renforcement

Oloproof évalue une politique d’apprentissage par renforcement en l’exécutant par épisodes, ou à partir du journal de la politique qu’elle remplacerait. Exécutez-la quand vous le pouvez ; utilisez le journal quand le résultat ne se produit que dans le monde réel. Cette page est la référence pour les deux, et le tutoriel parcourt chacune sur un exemple exécutable.

Oloproof n’héberge, ne réinitialise ni ne simule aucun environnement, et il n’entraîne pas de politiques. Votre système exécute son propre environnement, comme chaque système qu’il évalue exécute son propre code.

Épisodes

Une tâche est un cas. Un épisode en est une mesure : votre système exécute la politique dans son environnement et enregistre l’épisode avec current_case().rl_episode(...), sous forme d’artefact rl_episode/v1.

Champ	Type	Signification
steps	liste d’étapes, index à partir de 1	La reward (récompense) de chaque étape, son cost de contrainte (0 par défaut), et facultativement action et observation
success	vrai, faux ou absent	Le verdict de l’environnement lui-même sur l’épisode
truncated	booléen, faux par défaut	La limite d’étapes a mis fin à l’épisode avant un état terminal
horizon	entier, facultatif	La limite d’étapes ; l’épisode ne peut pas être plus long

L’enregistrement contient chaque étape de l’épisode. Un épisode tronqué est un épisode que le protocole d’évaluation définit comme se terminant à sa limite, donc son retour et son coût sont complets, et non des bornes inférieures.

Déclarez la sorte que le système enregistre, pour qu’une exécution puisse refuser un évaluateur qui a besoin d’un enregistrement que le système n’écrit jamais :

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

Évaluateurs d’épisodes

Type	Mesure	Champs
episode_return	Le retour, chaque récompense pondérée par discount à chaque étape, comme score	return_range (obligatoire), discount (1 par défaut)
episode_success	Réussite quand l’épisode enregistre success: true ; manquant quand il n’en enregistre aucun	aucun
episode_cost_within	Réussite quand la somme des coûts des étapes est au plus budget	budget (obligatoire)

return_range est la plage dans laquelle se trouve tout retour, par exemple 30 étapes à -1 chacune au pire et la récompense de l’objectif au mieux. L’intervalle sur un retour moyen ne tient qu’à l’intérieur de cette plage, donc un retour hors de celle-ci arrête l’exécution avec le code 2. Dans le SDK, les classes sont EpisodeReturn, EpisodeSuccess et EpisodeCostWithin dans oloproof.evaluators.

Plusieurs épisodes par tâche

Fixez replicates: pour exécuter plusieurs épisodes de chaque tâche. current_case().replicate indique lequel est en cours (0 pour le premier), et il fait partie de la clé de l’exécution stockée, donc un environnement qui en tire la graine de l’épisode rejoue le même épisode pour le même réplicat, et une deuxième exécution réutilise ce qu’elle a stocké.

La tâche reste l’unité. Chaque critère devient la moyenne sur les tâches de la moyenne propre à chaque tâche sur ses épisodes, et l’intervalle compte des tâches : cinq épisodes d’une même tâche ne sont pas cinq tâches indépendantes.

Un taux de réussite sur des tâches répliquées lit la part d’épisodes réussis de chaque tâche. Pour demander plutôt si une tâche réussit à chaque fois, déclarez une métrique every_replicate :

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

Une tâche ne compte que lorsque tous ses épisodes ont réussi, donc chaque tâche est une seule réussite ou un seul échec et l’intervalle binomial exact s’applique. Avec un épisode par tâche, elle est égale au taux de réussite. Une tâche avec un épisode manquant est manquante, même quand un autre de ses épisodes a échoué.

Comparer deux politiques

oloproof compare apparie chaque tâche avec elle-même, chaque côté valant sa moyenne sur ses épisodes. La différence d’un retour est exprimée dans l’unité propre du retour, celle d’un taux de réussite en points de pourcentage. Les deux exécutions peuvent exécuter des nombres d’épisodes par tâche différents, sauf pour une métrique every_replicate : réussir chacun de cinq épisodes et réussir le seul épisode sont des questions différentes, donc cette comparaison n’est pas calculée. Les comparaisons de quantiles et de classement ne sont pas calculées quand l’une ou l’autre exécution a plusieurs épisodes par tâche.

Évaluation hors politique

Utilisez-la quand le résultat qui vous importe ne se produit que dans le monde réel (un ticket résolu, un utilisateur qui est revenu) et que vous ne pouvez pas encore essayer la nouvelle politique sur du trafic réel. Les preuves sont un journal des décisions qu’une politique plus ancienne a prises.

Chaque cas est une décision journalisée :

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

Champ	Signification
input	Ce que la politique voyait quand elle a décidé
expected.action	L’action que la politique de journalisation a prise
expected.logging_probabilities	La probabilité que la politique de journalisation donnait à chaque action à ce moment, dont la somme vaut 1
expected.reward	Ce qui a suivi, dans reward_range ; absent s’il n’est jamais arrivé

Le système est la politique que vous voulez évaluer. Il reçoit input et renvoie sa propre probabilité pour chaque action sous probabilities, ou sous le champ que vous nommez dans probabilities_field. Il n’exécute jamais de modèle et ne touche jamais au monde réel. input ne contient que ce que la politique de journalisation voyait quand elle a décidé : jamais l’action journalisée ni la récompense, que la politique testée ne doit pas voir. Une politique qui tire son choix au sort renvoie les probabilités selon lesquelles elle tire, et non l’action qu’elle a tirée ; chaque décision est évaluée à nouveau même quand son entrée se répète. Les actions sont nommées exactement comme le journal les nomme : une action orthographiée différemment compte comme une action que la politique de journalisation n’a jamais prise.

Type	Estime
off_policy_value	La récompense moyenne de la politique sur des décisions semblables à celles du journal
off_policy_improvement	Cette moyenne moins celle de la politique de journalisation elle-même

Les deux prennent reward_range et propensity_floor, la plus petite probabilité que la politique de journalisation donnait à toute action que la nouvelle politique peut prendre. Fixez-la d’après la conception de la politique de journalisation (un taux d’exploration, une part minimale), jamais en essayant des valeurs sur le journal. Chaque décision journalisée est repondérée par la probabilité de son action selon la nouvelle politique divisée par celle selon la politique de journalisation, et le plancher borne ce poids : sans lui, aucun intervalle ne tient. Dans le SDK, les classes sont OffPolicyValue et OffPolicyImprovement.

Ce que fait le moteur d’une décision qu’il ne peut pas lire telle quelle :

Situation	Résultat
Des probabilités dont la somme ne vaut pas 1, une action journalisée de probabilité 0, une récompense hors de reward_range	L’exécution s’arrête avec le code 2 : une probabilité fausse rendrait l’intervalle faux sans le montrer
La nouvelle politique peut prendre une action journalisée avec une probabilité inférieure au plancher	La décision est manquante et bornée à son pire
La récompense est absente	La décision est manquante et bornée à son pire

Ce que la réponse suppose :

Les probabilités ont été enregistrées au moment où la politique de journalisation a décidé, et ce sont celles qu’elle a utilisées. Oloproof ne les estime jamais.
La récompense de chaque décision dépend de sa propre entrée et de sa propre action, pas des autres décisions.
La politique de journalisation a gardé les mêmes probabilités sur toute la période du journal.
La réponse décrit des décisions semblables à celles du journal, sur la période que couvre le journal.

L’intervalle est large quand le plancher est petit : les décisions qui renseignent sur une action rarement choisie sont peu nombreuses, et chacune compte de nombreuses fois. Un journal plus long, et une politique de journalisation qui explore davantage, le resserrent.

Ce qui n’est pas construit

L’évaluation hors politique d’une séquence de décisions, où chaque choix change ce qui vient ensuite.
Un journal dont la politique a changé ses probabilités en apprenant pendant la période.
Des probabilités estimées après coup.
L’hébergement ou la réinitialisation d’environnements et de simulateurs.

Pour aller plus loin

Tutoriel : évaluer une politique d’apprentissage par renforcement : les deux parties, exécutées de bout en bout.
Écrire une suite : les réplicats et les autres champs de la suite.
Référence de configuration : chaque champ de ces évaluateurs.