Anleitungen

Menschliche Prüfung

Ihre eigenen Leute können die Antworten Ihres Systems in Oloproof labeln, und ihre Labels können allein über ein Release entscheiden oder den Judge prüfen, der es entscheidet. Diese Seite fasst zusammen, was es gibt und wo jeder Teil ausführlich erklärt wird.

Was Menschen labeln können

Bestanden, nicht bestanden oder nicht entscheidbar zu einem Kriterium, Fall für Fall.
Eine Bewertung auf einer Skala Ihrer Wahl, etwa 1 bis 5.
Eine Präferenz zwischen den Antworten zweier Runs auf denselben Fall, als A und B gezeigt in einer Reihenfolge, die der Workspace per aufgezeichnetem Münzwurf festlegt, sodass die prüfende Person nicht erkennen kann, welcher Run welcher ist.
Bestanden oder nicht bestanden für beide Antworten auf denselben Fall, um zwei Versionen nach dem Urteil von Menschen zu vergleichen.

Neben jedem Fall wird eine für die Queue geschriebene Bewertungsrubrik angezeigt.

Wo sie labeln

Im Browser. In einem gehosteten Workspace öffnet ein Owner oder Admin auf der Review-Seite des Projekts eine Review-Queue und weist Prüfer zu. Jeder Prüfer sieht die ihm zugewiesenen Queues und labelt mit den Schaltflächen oder den Tasten P, F und C. Ein Urteil von einem Konto, das der Queue nicht zugewiesen ist, wird abgelehnt, und jedes Urteil wird unter dem eigenen Konto des Prüfers gespeichert.

Im Terminal. oloproof review RUN --criterion NAME --by YOU labelt einen Fall pro Zeile. Ohne weitere Option prüft es den Judge in einem Durchgang: eine blinde Stichprobe, deren Größe Ihre Schwelle bestimmt, der Judge an Ihren Labels gemessen und der Run neu entschieden.

In einer Tabelle. oloproof labels export RUN --criterion NAME --sample 50 schreibt eine CSV zum Ausfüllen, und oloproof labels import speichert alle ausgefüllten Zeilen oder keine. Nutzen Sie das für Prüfer, die außerhalb von Oloproof arbeiten, auch für einen Labeling-Dienstleister. Labels aus einer Datei zählen auf Ihrem Rechner, nicht in der Prüfung einer Stichprobe, die ein Workspace selbst gezogen hat.

Eine Queue betreiben

Wenn ein Owner oder Admin eine Queue öffnet, erhält jeder Prüfer eine E-Mail über seine Zuweisung, sofern er Prüf-E-Mails nicht abgeschaltet hat. Eine Queue kann ein Fälligkeitsdatum tragen, das auf der Queue und in der E-Mail steht; es entscheidet nichts, und nichts wird versendet, wenn es verstreicht. Auf der Seite der Queue sehen Owner und Admins den Fortschritt jedes Prüfers (erledigte Fälle und sein letztes Urteil) und können das Fälligkeitsdatum ändern.

Die Prüfer einer Review-Queue lassen sich jederzeit ändern, und jeder hinzugefügte erhält eine E-Mail. Die einer Mess-Queue nicht: Sie gehören zu ihrer Zufallsstichprobe, und nur ihre Labels zählen dort; andere Prüfer übernehmen daher eine neue Queue mit eigener Stichprobe.

Zwei Arten von Queues

Eine Mess-Queue lässt den Workspace eine Zufallsstichprobe ziehen und verbirgt das Urteil des Judges. Ihre Labels messen den Judge oder entscheiden eine Regel allein durch Menschen. Eine Review-Queue markierter Fälle zeigt das Urteil des Judges und erledigt diese Fälle, ohne etwas zu messen. Nur die erste Art kann für die ganze Suite stehen.

Wenn Prüfer uneins sind

Ein Projekt kann zwei oder mehr Prüfer pro Stichprobenfall verlangen, nach Konto gezählt. Sind sie bei bestanden oder nicht bestanden uneins, entscheidet der Workspace nichts, bis ein Owner oder Admin, der nichts von diesem Fall gelabelt hat, ihn auflöst, auf der Queue-Seite oder der Run-Seite. Wie oft Menschen untereinander übereinstimmen, steht neben jedem Evaluator, als Anteil der übereinstimmenden Prüferpaare, mit seinem Intervall, und als Krippendorffs Alpha, das diesen Anteil um die Übereinstimmung bereinigt, die der Zufall allein bei einem Kriterium ergäbe, das die meisten Antworten bestehen: 1 ist perfekte Übereinstimmung und 0 ist Zufall. Alpha wird ab 300 Fällen, die zwei oder mehr Menschen gelabelt haben, mit einem Intervall angegeben; darunter wird es allein gezeigt, mit dem Grund. Es entscheidet nichts.

Eine Messungs-Queue für bestanden oder nicht bestanden mit drei oder mehr Prüfern kann stattdessen per Mehrheit gelesen werden, was beim Öffnen gewählt wird. Das erste Urteil jedes Prüfers ist seine Stimme; ein Fall zählt, sobald mehr als die Hälfte seiner Prüfer übereinstimmt, und ein Gleichstand wartet, bis ein Owner oder Admin ihn auflöst. Die Queues für bestanden oder nicht bestanden eines Laufs zu einem Kriterium werden alle gleich gelesen.

Bewertungen, Präferenzen und bestanden oder nicht bestanden auf zwei Läufen brauchen keine solche Wahl: Der Wert jedes Falls ist der Mittelwert über alle Prüfer, die ihn gelabelt haben, sodass eine Uneinigkeit den Wert verschiebt, statt auf eine Auflösung zu warten, und ein strenger oder nachsichtiger Prüfer Teil dessen ist, was die Antwort misst.

Labels von einem Dienstleister

Eine Messungs-Queue für bestanden oder nicht bestanden oder für Bewertungen kann statt von Mitgliedern von den Bewertern eines Dienstleisters gelabelt werden. Öffnen Sie sie mit „Von einem Dienstleister gelabelt“ und den Namen der Bewerter. Laden Sie auf der Seite der Queue das Blatt herunter (eine Zeile pro gezogenem Fall und Bewerter, auszufüllen mit bestanden oder nicht bestanden oder mit einer Bewertung auf der Skala der Queue), geben Sie es dem Dienstleister mit den anzuzeigenden Antworten und laden Sie die zurückgegebene CSV- oder XLSX-Datei hoch. Jede Zeile wird geprüft: ein Fall, den die Queue nicht gezogen hat, ein Bewerter, den sie nicht nennt, oder ein zweites Urteil eines Bewerters zu einem Fall weist die ganze Datei ab.

Jeder Bewerter zählt dann namentlich als Prüfer, sodass Übereinstimmung, Alpha, Genauigkeit auf Antwortschlüsseln und die Mehrheit ihn alle lesen. Versehen Sie zuerst einige Fälle mit einem Schlüssel, um die Bewerter eines Dienstleisters zu prüfen, bevor Sie sich auf sie verlassen; ihre Genauigkeit wird berichtet und entscheidet nichts. Der Workspace kennt die Datei, die er erhalten hat, nicht, wer hingesehen hat: Jedes Label nennt das Konto, das es hochgeladen hat.

Antwortschlüssel und Genauigkeit der Prüfer

Ein Owner oder Admin kann einigen Fällen einer Bestanden-oder-nicht-bestanden-Warteschlange einen Schlüssel geben: Öffnen Sie einen Fall und setzen Sie den Schlüssel auf bestanden oder nicht bestanden. Nur ein Owner oder Admin, dem die Warteschlange nicht zugewiesen ist, sieht die Schlüssel, sodass Prüfer nicht erfahren, welche Fälle einen Schlüssel haben. Die Seite Prüfung zeigt Owners und Admins dann für jeden Prüfer den Anteil der Antworten mit Schlüssel, die dem Schlüssel entsprachen, mit seinem Intervall, und dasselbe nach Monat.

Das erste Bestanden oder Nicht bestanden eines Prüfers zur Antwort mit Schlüssel zählt; „kann ich nicht sagen“ wird daneben gezeigt, Auflösungen und die eigenen Urteile des Schlüsselautors bleiben außen vor, und ein Schlüssel gilt einer Antwort, sodass ein Urteil über die Antwort eines anderen Laufs zum selben Fall nicht verglichen wird. Ein Schlüssel ist nie ein Label und entscheidet nichts. Das Intervall liest die Fälle mit Schlüssel als Zufallsstichprobe ähnlicher Fälle; von Hand gewählte Schlüssel sind keine, lesen Sie es also als Genauigkeit auf diesen Fällen.

Labels von Menschen entscheiden ein Release

human_score: wie Menschen die ganze Suite bewerten, aus den Fällen, die sie bewertet haben.
human_preference: ob Menschen den Kandidaten der Baseline vorziehen, und um wie viel.
human_difference: um wie viel häufiger Menschen den Kandidaten bestehen lassen als die Baseline.
judge_bias_bar: ein von einem Judge entschiedener Vergleich geht an einen Menschen, es sei denn, die Labels von Menschen zeigen, dass der Judge beide Versionen gleich behandelt.

Jede wird in release.yaml oder compare.yaml deklariert und, mit ihrer Methode und dem, was sie nicht behaupten kann, unter Judges erklärt. Ein Fall, den niemand gelabelt hat, zählt mit seinem schlechtesten Wert, sodass es nie hilft, die schweren Fälle ungelabelt zu lassen.

Noch nicht gebaut

Folgendes existiert heute nicht:

ein Dienstleister, der eine Review-Queue, Präferenzen oder bestanden oder nicht bestanden auf zwei Läufen labelt: Jede davon zeigt einem Prüfer zwei Antworten in einer Reihenfolge, die der Workspace pro Prüfer festlegt, und eine außerhalb von Oloproof erstellte Datei kann sie nicht einhalten.

Oloproof stellt keine Prüfer und verbindet sich nicht mit den eigenen Werkzeugen eines Dienstleisters.