Évaluer une file de révision pour les contenus utilisateurs

Définissez les étiquettes de politique, conservez la soumission originale et rendez les règles d’escalade visibles avant toute automatisation.

Rendre les étiquettes de politique utilisables

Commencez par l’évaluation téléchargeable de trois signalements fictifs. L’enregistrement ci-dessous décrit une sortie, pas un système de modération déployé. Validez le fichier localement avant tout envoi. Les signalements urgents réels doivent éviter le traitement par lots et suivre directement votre procédure immédiate existante.

Une étiquette comme "dangereux" est trop vague. Définissez le domaine de politique, la gravité, la confiance et l’action attendue du réviseur. Gardez une catégorie pour les cas incertains.

Écrivez les règles d’escalade avant de traiter le backlog. Les menaces, l’automutilation, la sécurité des enfants, les demandes juridiques et le piratage de compte vont à une personne immédiatement.

Télécharger et valider le lot fictif

Téléchargez ces trois fichiers dans un même dossier : ugc-requests.jsonl, ugc-expected.json et ugc-validate.mjs. Avec Node.js 22 ou ultérieur, lancez :

node ugc-validate.mjs input ugc-requests.jsonl

Le JSONL contient déjà la politique complète et un signalement fictif par requête. Aucune invite n’est à assembler. Gardez les cas en anglais inchangés au premier essai. Le fichier expected sert aux vérifications locales ; ne l’envoyez jamais au modèle. Le validateur n’effectue aucun appel réseau.

Le fichier emploie le format de lot OpenAI Chat Completions, l’endpoint /v1/chat/completions et l’identifiant du catalogue DigitalOcean openai-gpt-4o-mini. Avant tout envoi, vérifiez la compatibilité actuelle avec les lots, l’accès de votre compte et les tarifs. Si ce modèle n’est plus disponible, remplacez body.model sur les trois lignes par un identifiant OpenAI Chat Completions pris en charge, puis relancez la validation. Une réussite locale vérifie la structure, pas vos droits d’accès ni la qualité du modèle. La requête limite la sortie à 400 jetons avec max_completion_tokens ; n’augmentez pas cette limite pour masquer un échec de validation.

Suivez ensuite le parcours officiel de traitement par lots DigitalOcean : envoyez le fichier validé, créez un lot OpenAI avec l’endpoint correspondant, conservez son identifiant et récupérez les résultats ainsi que tout fichier d’erreurs. Cette étape distante facultative est facturée ; elle n’a pas été exécutée pour cet exemple. Le catalogue des modèles et le format de lot OpenAI ont été consultés le 8 octobre 2026.

Enregistrez les résultats sous ugc-results.jsonl dans le même dossier, puis lancez :

node ugc-validate.mjs output ugc-results.jsonl

Un fichier d’erreurs, une réponse manquante, un identifiant inconnu ou répété, une réponse incomplète, un mauvais parcours, un champ invalide ou une décision finale non nulle bloque l’acceptation. Conservez les échecs en revue manuelle. Le statut completed ne garantit pas la réussite de chaque requête. Le validateur accepte les enveloppes documentées response.choices de DigitalOcean et response.body.choices d’OpenAI ; l’absence de finish_reason est indéterminée et entraîne un refus. Relisez chaque signalement original et sa citation même après réussite locale.

Conserver la soumission avec la suggestion

Le réviseur a besoin du texte ou de la référence média, de la raison du signalement, de l’étiquette proposée, de la phrase de preuve et de la confiance. Une étiquette seule ne suffit pas.

Créez un petit échantillon étiqueté avec les spécialistes de politique. Mesurez les faux négatifs par domaine de politique.

Vérifications attendues : UGC-01 → standard_review pour spam possible ; UGC-02 → standard_review avec contexte manquant signalé, sans sanction proposée ; UGC-03 → needs_specialist pour prise de contrôle de compte. Le résultat final reste vide jusqu’à la décision humaine.

La politique téléchargeable définit ces champs propres à l’exercice :

• severity : low pour une nuisance courante, medium pour un préjudice possible qui exige du contexte, high pour un cas nécessitant immédiatement un spécialiste. Le contexte manquant de UGC-02 ne prouve pas un harcèlement.
• confidence : low lorsque le contexte manque, medium pour une interprétation plausible, high pour un élément clair appuyant l’étiquette proposée. Ces catégories ne sont ni des probabilités calibrées ni une autorisation de sanctionner.
• reviewer_action : standard_review, review_now ou needs_specialist. Les règles d’escalade priment sur la confiance. review_now signifie une priorité immédiate de revue humaine dans standard_review.
• queue_state : needs_specialist pour le parcours spécialiste, standard_review sinon. final_reviewer_outcome reste null à la sortie du modèle.

Le validateur attend spam/low pour UGC-01, harassment_uncertain/medium avec confidence=low pour UGC-02 et account_compromise/high pour UGC-03. Ces étiquettes servent à l’exercice ; elles ne constituent pas une politique universelle. Faites valider les définitions par vos spécialistes avant de les adapter.

{
  "submission_id": "UGC-03",
  "policy_area": "account_compromise",
  "severity": "high",
  "evidence_quote": "an unknown person took control of the account",
  "confidence": "medium",
  "reviewer_action": "needs_specialist",
  "queue_state": "needs_specialist",
  "final_reviewer_outcome": null
}

Cet exemple de forme attendue est rédigé à la main, pas issu d’une exécution du modèle. Le fichier téléchargeable conserve les trois signalements originaux ; reliez les résultats par custom_id et non par ordre des lignes.

Rendre chaque état de la file explicite

Conservez séparément l’action proposée par le modèle, l’état de la file et la décision finale humaine. Ces champs permettent de revoir une mauvaise orientation et de comprendre un changement de décision.

• needs_specialist : prise en charge immédiate par un spécialiste ; n’attendez pas une hausse de la confiance du modèle.
• standard_review : parcours normal de révision, avec la soumission originale visible.
• returned_for_policy_clarification : les règles ou le contexte ne permettent pas une orientation sûre ; demandez une clarification humaine.
• resolved : un réviseur autorisé a consigné la décision finale, son identité et l’horodatage.
• escalated : un réviseur a transmis le cas à un responsable identifié ; conservez l’horodatage et laissez la décision finale vide tant qu’elle n’est pas prise.

À l’entrée, utilisez needs_specialist ou standard_review. La valeur reviewer_action=review_now indique une priorité de traitement, pas une sanction ni un état final ; gardez le cas en standard_review avec une priorité immédiate, sauf si une règle exige needs_specialist. Seule une personne autorisée peut décider d’une mesure et renseigner final_reviewer_outcome. Ces états décrivent le modèle de revue à implémenter, pas un système déjà déployé.

Traiter une ancienne file de façon asynchrone

Un backlog historique est un problème de lot. Batch Inference de DigitalOcean accepte des requêtes JSONL et retourne les résultats après traitement asynchrone. Gardez le travail sur des requêtes texte et donnez à chaque enregistrement un identifiant unique.

Exécutez un lot limité et échantillonnez chaque étiquette avant de router tout le backlog. Arrêtez si les réviseurs voient une erreur systématique.

Mesurer les résultats des réviseurs

Suivez délai de révision, accord avec la décision finale, appels ou annulations, et éléments urgents captés par les règles. La confiance du modèle ne sert qu’au tri.

Conservez la politique et l’instruction datées avec chaque lot pour pouvoir expliquer un changement ou revenir en arrière.

Questions fréquentes

Un modèle peut-il supprimer le contenu automatiquement ?

Ne commencez pas ainsi. Servez-vous d’abord du modèle pour préparer une file transparente, puis évaluez préjudice, politique et exigences de recours.

Que mettre dans le jeu de test ?

Des exemples simples, ambigus, des cas limites et des éléments qui exigent une revue spécialiste immédiate.