Configuration du moteur d'étiquetage

Tout ce que fait le moteur d'étiquetage se règle dans un seul bloc labeling_engine. Un bloc invalide arrête le serveur au démarrage et liste tous les problèmes d'un coup. Pour que les annotateurs reçoivent les demandes du moteur, définissez aussi assignment_strategy: engine. Choisir cette stratégie sans moteur activé est une erreur de validation.

Le bloc comporte les sections suivantes, chacune décrite plus bas :

assignment_strategy: engine
 
labeling_engine:
  enabled: true
  schemas: [sentiment]            # default: every scheme a source can label
  sources: []
  cascade: [laya, gemma]          # default: the first source alone
  contracts: []
  humans: {}
  crowd: {}
  budgets: {}
  runtime: {}
  features: {}
  redaction: {}
  distill: {}

Clés de premier niveau

Cinq clés se placent directement sous labeling_engine :

Sources

Une source est un modèle, ou un ensemble d'étiquettes existantes, qui propose une étiquette et une confiance pour chaque item. Chaque source a un id unique et un kind, et une clé inconnue sur une source est une erreur :

Tout ce qui peut changer une réponse (modèle, prompt, température, options) entre dans le hachage de version de la source. Une nouvelle version fait passer à stale chaque contrat qui dépend de la source.

Une réponse qui n'est pas une valeur que le schéma peut contenir, comme une étiquette absente de sa liste, un champ numérique qui n'est pas un nombre ou une liste sur un schéma à choix unique, est enregistrée comme une erreur et jamais comme une étiquette, et le message de l'exécution compte ces erreurs. Un item dont les appels échouent est redemandé lors des exécutions suivantes, au plus trois fois par version de source, puis il attend une source modifiée (une clé ou un prompt corrigé constitue une nouvelle version). Une exécution où une source échoue n'arrête pas les autres niveaux. Le niveau suivant étiquette chaque item, et potato label run se termine avec le statut 1 en nommant la source en échec.

Méthodes de confiance

Les règles d'acceptation du moteur fixent un seuil sur la confiance de chaque prédiction, donc la façon dont une source exprime sa confiance détermine ce que le moteur peut accepter. confidence.method prend l'une de cinq valeurs :

Options propres à chaque type

Cinq types de source lisent leurs propres options :

• decision couvre Laya dans le processus, ou tout serveur /v1/systemone comme Jev hébergé ou OpenJev. Un seul passage avant renvoie une probabilité pour chaque option, et il fonctionne sur les schémas radio, select, likert et slider. endpoint_type doit valoir laya ou systemone, et systemone exige base_url, la racine du serveur (une URL qui se termine par /v1/systemone est aussi acceptée). L'état est envoyé sous la forme {"text": ...} dans les deux cas, si bien qu'un même checkpoint donne les mêmes réponses dans le processus et derrière laya-serve, et options: {state_key: ""} envoie la chaîne seule à la place. Sur les échelles de notation (likert, slider), les scores de Laya suivent à peine l'échelle, alors vérifiez quelques items avant de vous y fier. Le point de terminaison laya dans le processus exige pip install 'potato-annotation[decision]'.
• detector lit les boîtes d'un détecteur d'objets sur les schémas image_annotation. keep_threshold (0.35) fixe le score à partir duquel une boîte fait partie de la prédiction. Les boîtes entre candidate_threshold (0.05) et keep_threshold abaissent la confiance de l'image. label_map associe les classes du détecteur aux étiquettes du schéma, et les classes non associées sont ignorées. image_field nomme le champ de l'item qui contient le chemin ou l'URL de l'image. Les chemins se résolvent comme sur la page d'annotation, /media/x.jpg sous le media_directory de la tâche et un chemin relatif sous task_dir.
• judge prend rubric (par défaut la description du schéma), fields (les champs de l'item montrés au juge, dans l'ordre) et swap_order, qui pose la question deux fois en inversant l'ordre des étiquettes et transforme un verdict qui s'inverse en abstention. Sur les schémas de traces d'agents (process_reward, trajectory_eval, ...), le juge étiquette chaque étape.
• vlm utilise un point de terminaison de vision (openai_vision, anthropic_vision, ollama_vision). Pour un modèle auto-hébergé derrière un serveur compatible OpenAI, utilisez openai_vision avec base_url.
• trained prend artifact_dir, trainer (sklearn-text par défaut) et run_id. C'est en général la distillation qui crée cette source, plutôt qu'une configuration écrite à la main.

humans

Le bloc humans définit qui étiquette et comment le moteur échantillonne ces personnes :

crowd

Le bloc crowd s'applique quand crowd figure dans humans.pools, et Prolific est la seule plateforme de crowdsourcing que le moteur peut piloter :

Le recrutement de crowdsourcing est une simulation par défaut, et le planificateur indique ce qu'il ferait. Dépenser de l'argent exige features.crowd_live_spend: true et un plafond budgets.human_usd, et une configuration qui active la dépense réelle sans ce plafond est rejetée. Intégration du crowdsourcing explique comment mettre en place l'étude Prolific elle-même.

budgets

Le bloc budgets arrête les dépenses avant qu'une limite soit dépassée :

runtime

Le bloc runtime règle le traitement par lots, la concurrence et la durée pendant laquelle une personne peut détenir une demande :

features

Toutes les fonctionnalités sont désactivées par défaut, sauf drift :

redaction

redaction.categories liste lesquels de email, url, ip, card, ssn, phone et handle masquer, et vaut tous par défaut. Le masquage ne s'applique qu'avec features.pii_redaction, et seulement aux API tierces. Les types de points de terminaison auto-hébergés (vllm, ollama, laya, yolo, ...) ne sont pas masqués, où qu'ils tournent, pas plus que tout point de terminaison dont la base_url se trouve sur la même machine.

distill

Avec features.distill activé, le moteur entraîne un modèle peu coûteux sur les étiquettes de l'étude et le place en tête de la cascade :

Les items des partitions cert et audit n'entrent jamais dans le jeu d'entraînement, si bien que le modèle distillé n'est jamais testé sur des étiquettes qui ont servi à l'entraîner.

Validation

potato validate config.yaml vérifie le bloc labeling_engine en même temps que le reste de la configuration, et chaque erreur nomme sa clé, par exemple labeling_engine.sources[1].kind must be one of ... ou labeling_engine.contracts[0].error is required for selective_risk. La validation refuse aussi :

• une clé de contrat que le type de contrat ne lit pas, comme une faute de frappe dans error ;
• un contrat sur un schéma qu'aucune source de la cascade ne peut étiqueter, avec la raison propre à chaque source ;
• un contrat sur un schéma que le moteur ne sait pas évaluer (texte libre, paires) ;
• une source decision dont l'endpoint_type n'est pas un modèle de décision, et une source llm, vlm ou judge dont l'endpoint_type en est un ; et
• no_worse_than_human avec humans.overlap_k inférieur à 3.

La validation avertit aussi quand budgets.human_labels est trop faible pour certifier un contrat selective_risk, même si chaque réponse machine était juste. Augmentez le budget, ou assouplissez error, jusqu'à ce que cet avertissement disparaisse.

Pour aller plus loin

• Le moteur d'étiquetage
• Contrats du moteur d'étiquetage
• Ligne de commande, REST API, outils MCP et SDK
• Support IA, pour les types de points de terminaison que les sources partagent avec le reste de Potato

Pour les détails d'implémentation, consultez la documentation source.