Guides
Revue humaine
Vos propres équipes peuvent étiqueter les réponses de votre système dans Oloproof, et leurs étiquettes peuvent décider seules d'une publication ou vérifier le juge qui la décide. Cette page rassemble ce qui existe et indique où chaque partie est expliquée en détail.
Ce que les personnes peuvent étiqueter
- Réussi, échoué ou impossible à dire sur un critère, cas par cas.
- Une note sur l'échelle de votre choix, par exemple de 1 à 5.
- Une préférence entre les réponses de deux exécutions au même cas, présentées comme A et B dans un ordre que l'espace de travail fixe par un tirage à pile ou face enregistré, de sorte que le relecteur ne peut pas savoir quelle exécution est laquelle.
- Réussi ou échoué sur les deux réponses au même cas, pour comparer deux versions selon le verdict des personnes.
Une grille d'évaluation écrite pour la file s'affiche à côté de chaque cas.
Où elles étiquettent
Dans le navigateur. Dans un espace de travail hébergé, un Owner ou Admin ouvre une file de revue depuis la page Review du projet et y affecte des relecteurs. Chaque relecteur voit les files qui lui sont affectées et étiquette avec les boutons ou les touches P, F et C. Un verdict venant d'un compte non affecté à la file est refusé, et chaque verdict est enregistré sous le compte du relecteur.
Dans le terminal. oloproof review RUN --criterion NAME --by YOU étiquette un cas par ligne. Sans autre option, elle vérifie le juge d'un seul coup : un échantillon en aveugle dimensionné par votre seuil, le juge mesuré par rapport à vos étiquettes, et l'exécution décidée de nouveau.
Dans un tableur. oloproof labels export RUN --criterion NAME --sample 50 écrit un CSV à remplir, et oloproof labels import enregistre toutes les lignes remplies ou aucune. Utilisez-le pour des relecteurs qui travaillent hors d'Oloproof, y compris un prestataire d'étiquetage. Les étiquettes issues d'un fichier comptent sur votre machine, pas dans la vérification par un espace de travail d'un échantillon qu'il a lui-même tiré.
Faire fonctionner une file
Lorsqu'un Owner ou un Admin ouvre une file, chaque relecteur reçoit un e-mail l'informant de son affectation, sauf s'il a désactivé les e-mails de relecture. Une file peut porter une échéance, affichée sur la file et dans l'e-mail ; elle ne décide de rien, et rien n'est envoyé quand elle passe. Sur la page de la file, les Owners et les Admins voient l'avancement de chaque relecteur (cas traités et dernier verdict) et peuvent modifier l'échéance.
Les relecteurs d'une file de relecture peuvent être changés à tout moment, et chaque relecteur ajouté reçoit un e-mail. Ceux d'une file de mesure ne le peuvent pas : ils font partie de son échantillon aléatoire, et seules leurs étiquettes y comptent ; d'autres relecteurs prennent donc une nouvelle file avec son propre échantillon.
Deux sortes de files
Une file de mesure fait tirer à l'espace de travail un échantillon aléatoire et masque le verdict du juge. Ses étiquettes mesurent le juge, ou décident une règle par les personnes seules. Une file de revue des cas signalés montre le verdict du juge et tranche ces cas sans rien mesurer. Seule la première sorte peut représenter toute la suite.
Quand les relecteurs ne sont pas d'accord
Un projet peut exiger deux relecteurs ou plus par cas échantillonné, comptés par compte. Lorsqu'ils divergent sur un réussi ou échoué, l'espace de travail ne décide rien tant qu'un Owner ou Admin n'ayant étiqueté aucune partie de ce cas ne l'a pas tranché, sur la page de la file ou celle de l'exécution. La fréquence d'accord entre les personnes s'affiche à côté de chaque évaluateur, comme la part des paires de relecteurs qui se sont accordées, avec son intervalle, et comme l'alpha de Krippendorff, qui corrige cette part de l'accord que le hasard seul donnerait sur un critère que la plupart des réponses réussissent : 1 est un accord parfait et 0 le hasard. L'alpha est donné avec un intervalle à partir de 300 cas étiquetés par deux personnes ou plus ; en dessous, il est affiché seul, avec la raison. Il ne décide rien.
Une file de mesure réussi ou échoué comptant trois relecteurs ou plus peut plutôt être lue à la majorité, choix fait à son ouverture. Le premier verdict de chaque relecteur est son vote ; un cas compte dès que plus de la moitié de ses relecteurs s'accordent, et une égalité attend qu'un Owner ou Admin la tranche. Les files réussi ou échoué d'une exécution sur un même critère sont toutes lues de la même façon.
Les notes, les préférences et réussi ou échoué sur deux exécutions n'appellent pas ce choix : la valeur de chaque cas est la moyenne sur tous les relecteurs qui l'ont étiqueté, de sorte qu'un désaccord déplace la valeur au lieu d'attendre d'être tranché, et qu'un relecteur sévère ou indulgent fait partie de ce que mesure la réponse.
Étiquettes d'un prestataire
Une file de mesure réussi ou échoué ou de notes peut être étiquetée par les annotateurs d'un prestataire plutôt que par des membres. Ouvrez-la avec « Étiquetée par un prestataire » et les noms des annotateurs. Sur la page de la file, téléchargez la feuille (une ligne par cas tiré et par annotateur, à remplir avec réussi ou échoué, ou une note sur l'échelle de la file), remettez-la au prestataire avec les réponses à montrer, et téléversez le CSV ou XLSX renvoyé. Chaque ligne est vérifiée : un cas que la file n'a pas tiré, un annotateur qu'elle ne nomme pas, ou un second verdict d'un annotateur sur un même cas refuse tout le fichier.
Chaque annotateur compte alors comme un relecteur à son nom, si bien que l'accord, l'alpha, la justesse sur les clés de réponse et la majorité le lisent tous. Donnez d'abord une clé à quelques cas pour vérifier les annotateurs d'un prestataire avant de vous fier à eux ; leur justesse est rapportée et ne décide rien. L'espace de travail connaît le fichier qu'on lui a donné, pas qui l'a regardé : chaque étiquette nomme le compte qui l'a téléversée.
Clés de réponse et justesse des relecteurs
Un Owner ou Admin peut poser une clé sur certains cas d'une file réussi ou échoué : ouvrez un cas et donnez-lui la clé réussi ou échoué. Seul un Owner ou Admin auquel la file n'est pas affectée voit les clés, si bien que les relecteurs ne savent pas quels cas en ont une. La page Relecture montre ensuite, aux Owners et Admins, la part des réponses à clé de chaque relecteur qui concordaient avec la clé, avec son intervalle, et la même chose par mois.
Le premier réussi ou échoué d'un relecteur sur la réponse à clé compte ; « impossible à dire » s'affiche à côté, les arbitrages et les verdicts de l'auteur de la clé sont écartés, et une clé porte sur une seule réponse, si bien qu'un verdict sur la réponse d'une autre exécution au même cas n'est pas comparé. Une clé n'est jamais une étiquette et ne décide rien. L'intervalle lit les cas à clé comme un échantillon aléatoire de cas semblables ; des clés choisies à la main n'en sont pas un, lisez-le donc comme la justesse sur ces cas.
Les étiquettes des personnes décidant d'une publication
- human_score : la note que les personnes donnent à toute la suite, à partir des cas notés.
- human_preference : si les personnes préfèrent le candidat à la référence, et de combien.
- human_difference : de combien les personnes valident le candidat plus souvent que la référence.
- judge_bias_bar : une comparaison décidée par un juge revient à une personne, sauf si les étiquettes des personnes montrent que le juge traite les deux versions de la même façon.
Chacune se déclare dans release.yaml ou compare.yaml et est expliquée, avec sa méthode et ce qu'elle ne peut pas affirmer, dans Juges. Un cas que personne n'a étiqueté compte à sa pire valeur, si bien que laisser les cas difficiles sans étiquette n'aide jamais.
Pas encore construit
Ces éléments n'existent pas aujourd'hui :
- un prestataire étiquetant une file de relecture, des préférences, ou réussi ou échoué sur deux exécutions : chacune montre à un relecteur deux réponses dans un ordre que l'espace de travail fixe pour chaque relecteur, ce qu'un fichier fait hors d'Oloproof ne peut pas conserver.
Oloproof ne fournit pas de relecteurs et ne se connecte pas aux outils propres d'un prestataire.