Anleitungen

Reinforcement Learning

Oloproof evaluiert eine Reinforcement-Learning-Policy, indem es sie in Episoden ausführt, oder anhand des Protokolls der Policy, die sie ersetzen würde. Führen Sie sie aus, wenn Sie können; nutzen Sie das Protokoll, wenn das Ergebnis erst in der realen Welt eintritt. Diese Seite ist die Referenz für beides, und das Tutorial führt beides an einem ausführbaren Beispiel vor.

Oloproof hostet, setzt zurück oder simuliert keine Umgebung, und es trainiert keine Policies. Ihr System betreibt seine eigene Umgebung, so wie jedes System, das Oloproof evaluiert, seinen eigenen Code ausführt.

Episoden

Eine Aufgabe ist ein Fall. Eine Episode ist eine Messung davon: Ihr System führt die Policy in seiner Umgebung aus und zeichnet die Episode mit current_case().rl_episode(...) als rl_episode/v1-Artefakt auf.

Feld	Typ	Bedeutung
steps	Liste von Schritten, index ab 1	Die Belohnung (reward) jedes Schritts, seine Constraint-Kosten (cost, Standard 0) und optional action und observation
success	true, false oder fehlend	Das eigene Urteil der Umgebung über die Episode
truncated	Boolean, Standard false	Das Schrittlimit hat die Episode vor einem Endzustand beendet
horizon	Ganzzahl, optional	Das Schrittlimit; die Episode darf nicht länger sein

Der Datensatz enthält jeden Schritt der Episode. Eine abgeschnittene Episode ist eine, die das Evaluationsprotokoll an ihrem Limit enden lässt, daher sind ihr Return und ihre Kosten vollständig und keine unteren Schranken.

Deklarieren Sie die Art, die das System aufzeichnet, damit ein Lauf einen Evaluator abweisen kann, der einen Datensatz braucht, den das System nie schreibt:

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

Episoden-Evaluatoren

Typ	Misst	Felder
episode_return	Den Return, jede Belohnung pro Schritt mit discount gewichtet, als Score	return_range (erforderlich), discount (Standard 1)
episode_success	Besteht, wenn die Episode success: true aufzeichnet; fehlt, wenn sie nichts dazu aufzeichnet	keine
episode_cost_within	Besteht, wenn sich die Kosten der Schritte auf höchstens budget summieren	budget (erforderlich)

return_range ist der Bereich, in dem jeder Return liegt, etwa im schlechtesten Fall 30 Schritte zu je -1 und im besten die Belohnung für das Ziel. Das Intervall um einen mittleren Return gilt nur innerhalb dieses Bereichs, daher stoppt ein Return außerhalb davon den Lauf mit Exit 2. Im SDK sind die Klassen EpisodeReturn, EpisodeSuccess und EpisodeCostWithin in oloproof.evaluators.

Mehrere Episoden pro Aufgabe

Setzen Sie replicates:, um mehrere Episoden jeder Aufgabe auszuführen. current_case().replicate sagt, welche gerade läuft (0 für die erste), und es ist Teil des Schlüssels der gespeicherten Ausführung: Eine Umgebung, die den Seed der Episode daraus ableitet, spielt für dasselbe Replikat dieselbe Episode erneut ab, und ein zweiter Lauf verwendet wieder, was er gespeichert hat.

Die Aufgabe bleibt die Einheit. Jedes Kriterium wird zum Mittelwert über die Aufgaben des Mittelwerts jeder Aufgabe über ihre Episoden, und das Intervall zählt Aufgaben: Fünf Episoden einer Aufgabe sind nicht fünf unabhängige Aufgaben.

Eine Bestehensrate über replizierte Aufgaben liest den Anteil bestandener Episoden jeder Aufgabe. Um stattdessen zu fragen, ob eine Aufgabe jedes Mal besteht, deklarieren Sie eine every_replicate-Metrik:

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

Eine Aufgabe zählt nur, wenn alle ihre Episoden bestanden haben, daher ist jede Aufgabe ein einziges Bestanden oder Nicht bestanden, und das exakte Binomialintervall gilt. Mit einer Episode pro Aufgabe ist sie gleich der Bestehensrate. Eine Aufgabe mit einer fehlenden Episode gilt als fehlend, selbst wenn eine andere ihrer Episoden nicht bestanden hat.

Zwei Policies vergleichen

oloproof compare paart jede Aufgabe mit sich selbst, wobei jede Seite so viel zählt wie ihr Mittelwert über ihre Episoden. Die Differenz eines Returns wird in der eigenen Einheit des Returns angezeigt, die einer Bestehensrate in Prozentpunkten. Die beiden Läufe dürfen unterschiedlich viele Episoden pro Aufgabe ausführen, außer bei einer every_replicate-Metrik: In jeder von fünf Episoden erfolgreich zu sein und in der einzigen sind verschiedene Fragen, daher wird dieser Vergleich nicht berechnet. Quantil- und Ranking-Vergleiche werden nicht berechnet, wenn einer der beiden Läufe mehrere Episoden pro Aufgabe hat.

Off-Policy-Evaluierung

Verwenden Sie sie, wenn das Ergebnis, auf das es Ihnen ankommt, erst in der realen Welt eintritt (ein gelöstes Ticket, ein Nutzer, der zurückkam) und Sie die neue Policy noch nicht an echtem Traffic ausprobieren können. Die Evidenz ist ein Protokoll der Entscheidungen, die eine ältere Policy getroffen hat.

Jeder Fall ist eine protokollierte Entscheidung:

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

Feld	Bedeutung
input	Was die Policy sah, als sie entschied
expected.action	Die Aktion, die die protokollierende Policy (logging policy) gewählt hat
expected.logging_probabilities	Die Wahrscheinlichkeit, die die protokollierende Policy in diesem Moment jeder Aktion gab, in der Summe 1
expected.reward	Was darauf folgte, innerhalb von reward_range; fehlt, wenn es nie eintraf

Das System ist die Policy, die Sie evaluieren wollen. Es erhält input und gibt seine eigene Wahrscheinlichkeit für jede Aktion unter probabilities zurück oder unter dem Feld, das Sie in probabilities_field nennen. Es führt nie ein Modell aus und berührt nie die reale Welt. input enthält nur, was die protokollierende Policy sah, als sie entschied: nie die protokollierte Aktion oder die Belohnung, die die getestete Policy nicht sehen darf. Eine Policy, die ihre Wahl zufällig zieht, gibt die Wahrscheinlichkeiten zurück, aus denen sie zieht, nicht die gezogene Aktion; jede Entscheidung wird neu evaluiert, auch wenn sich ihre Eingabe wiederholt. Aktionen heißen genau so, wie das Protokoll sie nennt: Eine anders geschriebene Aktion zählt als eine, die die protokollierende Policy nie gewählt hat.

Typ	Schätzt
off_policy_value	Die mittlere Belohnung der Policy bei Entscheidungen wie den protokollierten
off_policy_improvement	Diesen Mittelwert abzüglich des Mittelwerts der protokollierenden Policy selbst

Beide nehmen reward_range und propensity_floor, die kleinste Wahrscheinlichkeit, die die protokollierende Policy irgendeiner Aktion gab, die die neue Policy wählen kann. Legen Sie sie anhand dessen fest, wie die protokollierende Policy entworfen wurde (eine Explorationsrate, ein Mindestanteil), nie durch Ausprobieren von Werten am Protokoll. Jede protokollierte Entscheidung wird mit der Wahrscheinlichkeit ihrer Aktion unter der neuen Policy im Verhältnis zu der unter der protokollierenden Policy neu gewichtet, und die Untergrenze beschränkt dieses Gewicht: Ohne sie gilt kein Intervall. Im SDK sind die Klassen OffPolicyValue und OffPolicyImprovement.

Was die Engine mit einer Entscheidung macht, die sie nicht so lesen kann, wie sie vorliegt:

Situation	Ergebnis
Wahrscheinlichkeiten, die sich nicht zu 1 summieren, eine protokollierte Aktion mit Wahrscheinlichkeit 0, eine Belohnung außerhalb von reward_range	Der Lauf stoppt mit Exit 2: Eine falsche Wahrscheinlichkeit würde das Intervall falsch machen, ohne es zu zeigen
Die neue Policy kann eine Aktion wählen, die mit einer Wahrscheinlichkeit unter der Untergrenze protokolliert wurde	Die Entscheidung gilt als fehlend und wird mit ihrem ungünstigsten Wert begrenzt
Die Belohnung fehlt	Die Entscheidung gilt als fehlend und wird mit ihrem ungünstigsten Wert begrenzt

Was die Antwort voraussetzt:

Die Wahrscheinlichkeiten wurden aufgezeichnet, als die protokollierende Policy entschied, und sie sind die, die sie verwendet hat. Oloproof schätzt sie nie.
Die Belohnung jeder Entscheidung hängt von ihrer eigenen Eingabe und Aktion ab, nicht von anderen Entscheidungen.
Die protokollierende Policy hat über das Zeitfenster des Protokolls dieselben Wahrscheinlichkeiten beibehalten.
Die Antwort beschreibt Entscheidungen wie die protokollierten, über den Zeitraum, den das Protokoll abdeckt.

Das Intervall ist breit, wenn die Untergrenze klein ist: Die Entscheidungen, die über eine selten gewählte Aktion Auskunft geben, sind wenige, und jede zählt vielfach. Ein längeres Protokoll und eine protokollierende Policy, die mehr exploriert, machen es schmaler.

Was nicht gebaut ist

Off-Policy-Evaluierung einer Folge von Entscheidungen, bei der jede Wahl verändert, was als Nächstes kommt.
Ein Protokoll, dessen Policy ihre Wahrscheinlichkeiten änderte, während sie im Zeitfenster lernte.
Nachträglich geschätzte Wahrscheinlichkeiten.
Das Hosten oder Zurücksetzen von Umgebungen und Simulatoren.

Wie es weitergeht

Tutorial: eine Reinforcement-Learning-Policy evaluieren: beide Teile, von Anfang bis Ende ausgeführt.
Eine Suite schreiben: Replikate und die anderen Felder einer Suite.
Konfigurationsreferenz: jedes Feld dieser Evaluatoren.