Skip to content
Announcements9 min read

Potato 2.11 : le moteur d'étiquetage et les étiquettes machine certifiées

Potato 2.11 étiquette avec des modèles, teste leurs étiquettes sur un échantillon humain en aveugle et émet un certificat. Les sessions inactives expirent après 8 h.

Potato Team

Potato 2.11 ajoute le moteur d'étiquetage, qui étiquette un jeu de données avec des modèles et s'appuie sur un échantillon aléatoire d'étiquettes humaines recueillies en aveugle pour mesurer à quelle fréquence les modèles se trompent. Vous énoncez ce que les étiquettes finales doivent respecter, par exemple qu'au plus 10 % des étiquettes machine acceptées soient fausses, avec une confiance de 90 %. Le moteur accepte les étiquettes machine qu'un test statistique justifie, envoie les items restants à des personnes et rédige un certificat qui consigne ce qui a été testé et sur combien d'étiquettes humaines. La version étend aussi le rapport d'accord aux objets 3D, à l'ancrage temporel, à l'annotation par niveaux et aux traces d'agents, et corrige un bogue d'image qui pouvait compter comme répondus des items jamais touchés.

bash
pip install --upgrade potato-annotation

Notes de mise à jour

Les sessions inactives sont désormais déconnectées, après 8 heures par défaut. Avant la 2.11, session_timeout_minutes n'avait aucun effet sur une application servie, parce que la vérification était enregistrée sur un objet d'application que potato start abandonne. Une session inactive plus longtemps que la valeur fixée est maintenant effacée, et sa requête suivante mène à la page de connexion. Les bornes et les machines partagées de laboratoire qui restent connectées toute la nuit vont commencer à voir des déconnexions : augmentez donc session_timeout_minutes là où une étude dépend d'une connexion maintenue. Les annotations déjà enregistrées ne sont pas concernées.

Trois anciennes clés affichent une note au démarrage. icl_labeling, judge_calibration et pre_annotation fonctionnent exactement comme avant, et chacune écrit sur stderr une ligne commençant par NOTE: qui nomme son équivalent dans le moteur. Ces notes sont informatives, donc potato validate --strict n'échoue pas à cause d'elles. Le retrait de ces clés est prévu pour la 3.0, et potato label migrate-config écrit pour vous le bloc labeling_engine équivalent.

Le moteur d'étiquetage

Le moteur s'adresse aux études qui comptent plus d'items que les personnes ne peuvent en étiqueter, avec un modèle qui a raison la plupart du temps. Il traite les modèles comme des sources, essayées en cascade dans l'ordre où vous les listez, et envoie un item à une personne après la dernière source. Une source peut être un LLM, un modèle vision-langage, un modèle de décision comme Laya, un détecteur YOLO, un juge LLM, un jury, un modèle entraîné sur les propres étiquettes de l'étude, ou des étiquettes que vous avez déjà.

Un contrat est ce que le moteur teste. Le principal, selective_risk, borne la part des étiquettes machine acceptées qui sont fausses. Le moteur choisit un seuil de confiance sur une moitié de l'échantillon en aveugle et le teste sur l'autre moitié avec un test binomial unilatéral, selon le Learn-then-Test à séquence fixe. Chaque nouveau test se fait à un niveau plus strict, si bien que recertifier jusqu'à ce qu'un test passe ne gonfle pas la confiance. Le contrat ppi indique la prévalence de chaque étiquette avec un intervalle construit par inférence assistée par prédiction, qui reste valide quelle que soit la qualité du modèle. no_worse_than_human exécute le test de l'annotateur alternatif pour remplacer une personne ou un juge, et distributional compare la distribution des étiquettes du modèle à la façon dont les personnes se partagent sur les items subjectifs.

Une configuration qui certifie un LLM sur un schéma de sentiment ajoute deux clés à une étude ordinaire :

yaml
assignment_strategy: engine
 
labeling_engine:
  enabled: true
  sources:
    - id: gemma
      kind: llm
      endpoint_type: vllm
      model: google/gemma-4-12B-it-qat-w4a16-ct
      base_url: http://localhost:8001/v1
      confidence: {method: logprob}
  contracts:
    - id: accuracy
      kind: selective_risk
      schema: sentiment
      error: 0.1
      confidence: 0.9
  budgets:
    human_labels: 400

confidence: {method: logprob} lit la confiance du modèle dans les probabilités de ses tokens, ce qui demande un appel par item et donne en général la mieux calibrée des méthodes de confiance du moteur. Le contrat autorise au plus 10 % d'étiquettes acceptées fausses, et sa confiance de 90 % est la valeur par défaut de Potato. budgets.human_labels plafonne le nombre de demandes humaines que le moteur peut ouvrir, et 400 est le plafond qu'utilise l'exemple textuel fourni.

L'exemple textuel fourni avec Potato fait passer 481 critiques par une cascade où Laya précède Gemma 12B. Dans cette exécution, le contrat à 10 % a été respecté avec 165 étiquettes humaines, et le moteur a accepté 316 étiquettes machine, toutes venues de Gemma, car le seuil de Laya n'a jamais été fixé. Leur erreur mesurée par rapport aux étiquettes de référence était de 7,6 %. L'exemple de traces d'agents compte 288 traces synthétiques avec des résultats de référence. Le juge avait raison sur 80 % d'entre elles mais attribuait une confiance de 1,0 à chaque verdict, si bien que selective_risk n'avait rien sur quoi fixer un seuil et est resté infaisable. L'intervalle PPI du succès des tâches obtenu sur les mêmes données, [0,57 ; 0,76], couvrait le taux de référence de 0,60, alors que le juge seul annonçait 0,76.

Limites d'un contrat respecté

Un contrat respecté est un énoncé sur l'accord avec les personnes qui ont étiqueté l'échantillon. Le moteur ne vérifie pas que ces personnes ont raison, donc un contrat testé contre des annotateurs négligents certifie l'accord avec des annotateurs négligents. Trois règles font tenir cet énoncé. Les demandes de calibration sont en aveugle : la page n'affiche ni pré-annotation, ni verdict de juge, ni aide IA tant qu'une personne en détient une. Les seuils sont choisis sur une moitié de l'échantillon et testés sur l'autre. Seules les étiquettes humaines certifient, et toute modification d'une source, d'un prompt ou d'un schéma marque les contrats concernés stale jusqu'à ce qu'ils soient testés de nouveau.

Les interfaces du moteur

Le même fichier engine.sqlite sert toutes les interfaces, si bien que vous pouvez lancer une étude dans l'une et certifier dans une autre :

  • potato label run|status|certify|certificate|export|calls|distill|optimize|migrate-config en ligne de commande ;
  • une REST API sous /api/engine/v1 ;
  • cinq outils engine_* dans le serveur MCP ;
  • potato.labeling_engine.sdk.Study en Python ; et
  • une page d'administration à /admin/labeling-engine, avec le statut des contrats, la courbe erreur-couverture, un diagramme de fiabilité par source et le journal des appels aux modèles.

potato label export écrit les étiquettes avec leur provenance, le certificat en JSON, Markdown et HTML, une fiche de jeu de données et le journal des appels. Le moteur d'étiquetage détaille une première étude, et Contrats du moteur d'étiquetage explique ce que teste chaque contrat et comment il échoue.

Solo Mode

Le Solo Mode peut désormais masquer sa suggestion. solo_mode.suggestions retient l'étiquette du LLM sur tous les items ou sur un échantillon aléatoire. Une suggestion affichée tire la réponse vers elle, c'est pourquoi le passage de relais lit l'accord sur les items en aveugle. Les modèles de décision (laya et tout serveur /v1/systemone) peuvent servir de premier niveau rapide, et le Solo Mode vérifie le ai_budget.cap_usd du projet avant le début de l'étiquetage et avant chaque lot. Un jeu de référence, un jury d'étiquetage et un ordonnancement par curriculum sont également nouveaux. Quand le moteur est activé, le Solo Mode écrit ses prédictions dans le stockage du moteur, afin que celui-ci puisse les calibrer et les certifier. Solo Mode donne les configurations.

Accord

/admin/iaa indique désormais l'accord sur spatial_annotation, temporal_grounding, tiered_annotation et les cinq schémas de traces d'agents, qu'il ignorait auparavant comme non pris en charge. Les objets 3D et les segments temporels reçoivent un accord moyen sur ensembles appariés, qui n'est pas corrigé du hasard, et les étapes des traces d'agents reçoivent l'alpha de Krippendorff et le kappa de Cohen, chaque étape de chaque trace formant une unité. /admin/api/agreement ne rend plus compte des schémas structurés et renvoie à /admin/iaa, parce que, réduits aux noms d'étiquettes, ces schémas affichaient un accord parfait entre toutes les paires d'annotateurs. Deux segments identiques de longueur nulle comptent désormais comme concordants. La publication et le Mode article excluent les annotateurs machine des étiquettes de référence et des chiffres d'accord.

Correctifs qui touchent les études menées en 2.10

Trois correctifs peuvent modifier des chiffres que vous avez déjà recueillis ou publiés :

  • Une page d'image enregistrait d'elle-même une réponse préremplie. Sur un schéma image_annotation avec pre_annotation, le canevas enregistrait les formes préremplies comme réponse de l'annotateur quand il refaisait sa mise en page après le chargement, si bien qu'un item jamais touché comptait comme répondu. Dans une étude d'images en 2.10 avec pré-annotations, un item dont les formes enregistrées correspondent exactement à sa pré-annotation n'a peut-être jamais été touché : traitez ces items comme non relus, sauf si vos données de temps montrent le contraire.
  • Le Mode article calculait le kappa avec son propre code. Le Mode article et le module d'accord calculent désormais le kappa de Cohen avec la même fonction que /admin/iaa, donc un kappa issu du Mode article avant la 2.11 peut différer de celui que /admin/iaa affiche pour les mêmes données.
  • L'arbitrage et la mise à l'échelle automatique de Prolific comptaient les annotateurs machine. Des annotateurs machine pouvaient envoyer un item en arbitrage, min_human_annotations était ignoré, et la mise à l'échelle automatique de Prolific comptait les annotations machine dans les plafonds par item.

Les autres correctifs changent ce qu'une étude peut faire. Les images servies par des hôtes qui n'envoient aucun en-tête CORS, comme cocodataset.org, se chargent désormais. Sur une telle image, le remplissage par diffusion, SAM et la segmentation par prompt textuel indiquent maintenant pourquoi ils ne peuvent pas la lire. Une forme pré-annotée sans color prend la couleur de son étiquette au lieu d'être abandonnée. Le bouton « Generate prompt » du Solo Mode demande désormais au modèle de révision d'écrire le premier prompt. Les refus passés par potato mcp connect reviennent comme des erreurs d'outil et non plus comme des succès. La découverte de cas limites fonctionne désormais sur vLLM, qui ne renvoyait pas les champs de cas limites avant leur ajout au schéma de réponse.

Installer la 2.11

Mettez à jour avec pip install --upgrade potato-annotation, ou récupérez ghcr.io/davidjurgens/potato:2.11.0. Le modèle de décision Laya exécuté dans le processus demande le nouvel extra decision, pip install 'potato-annotation[decision]', qui reste hors de all parce qu'il entraîne torch. Les notes de version listent chaque changement, et Nouveautés résume chaque version 2.x.