Source docs/quality.fr.md · 1de96aa

Juge qualité (facultatif)

Le juge qualité est un modèle d’un autre provider — Codex (un compte ChatGPT), ou toute API compatible OpenAI ou compatible Anthropic déjà configurée dans Réglages › Providers — qui relit chaque passage que Libris traduit, juste avant de le clore, comme le dernier correcteur avant publication. Un passage où il trouve des erreurs est corrigé sur le modèle du juge, puis relu. Rien ne tourne sur la machine de Libris en dehors des appels habituels : un petit VPS suffit.

Sans juge, Libris traduit exactement comme avant.

Pourquoi un modèle, et pas une métrique

Une métrique de traduction a d’abord été essayée, MetricX-24 (Google), sur vingt paragraphes d’un light novel anglais → français tels que Libris les avait traduits et tels qu’une personne les a corrigés (26 septembre 2026). Elle repérait les fautes grossières — « J’ai abandonné » pour « I abandoned her » (10,2 sur 25, contre 3,1 corrigé), une proposition omise — mais ne préférait le paragraphe corrigé que 8 fois sur 20 sur les calques et les faux amis qui font sentir la traduction, et elle demandait PyTorch, plusieurs gigaoctets de mémoire et un gros processeur. Un grand modèle à qui l’on pose les questions d’un correcteur voit les deux sortes d’erreurs, par une API que l’installation a déjà.

Ce que fait le juge

  1. Il relit le passage terminé (après la traduction, le polissage, la relecture et la révision), avec son contexte : glossaire, fiches de personnages, fiche de style, passages voisins, et la liste des fautes de sa paire de langues. Il répond comme une relecture : chaque point nomme le paragraphe, une catégorie, les mots fautifs et une correction.
    • Erreur : ce qu’un correcteur professionnel changerait avant publication — un changement de sens, un pronom, un complément ou une négation perdus ou faux, une omission ou un ajout, un nom ou un terme verrouillé faux, une faute de grammaire ou d’orthographe, un temps qui casse le récit, un calque ou un faux ami qu’un lecteur natif remarque, un registre qui trahit le personnage, du texte non traduit.
    • Avertissement : une tournure correcte qu’un bon correcteur rendrait encore plus idiomatique.
  2. Un passage à erreurs est corrigé sur le modèle du juge, avec ses points comme points de relecture, sous les mêmes gardes que le polissage (aucun paragraphe raccourci, aucune nouvelle erreur des contrôles automatiques), puis relu. La correction n’est gardée que si le juge trouve désormais moins d’erreurs ; la version porte l’origine quality_rework dans l’historique et la décision est journalisée (Pilote automatique › Décisions, type quality_rework).
  3. Les erreurs que le juge trouve encore dans le texte gardé rejoignent les points de relecture du passage (marquées by: judge) ; ses avertissements ne servent qu’à sa correction. Les points de la relecture restent, sauf si le texte qu’ils visent a été réécrit depuis (sa révision, la correction du juge). Sans point restant, le passage est clos OK ; sinon il est À vérifier, son score de qualité baisse, et l’arbitrage du pilote automatique et la relecture finale reprennent ses points comme tout point de relecture.

Au plus QUALITY_REWORK_SHARE des passages qu’un travail s’est donné à traduire (25 % par défaut, au moins un) sont corrigés, chacun une fois, même après une reprise du travail. Un livre en qualité rapide est jugé mais jamais corrigé. Le juge lit la consigne du travail comme toute relecture et n’est jamais remplacé par le modèle supérieur : c’est le provider choisi pour juger. Ses règles de typographie et sa liste de fautes sont celles de tout relecteur (prompts/quality_judge.txt, puis les règles de la paire de langues).

Un juge qui ne répond pas — panne, clé refusée, réponse invalide — ne fait jamais échouer un passage : le passage est clos sans son avis et la raison est journalisée (type quality_judge, action sauté). Aucun provider de secours ne remplace le juge.

Choisir le juge

  • Pour l’installation : Paramètres › Pilote automatique › Juge qualité, ou QUALITY_JUDGE_PROVIDER (nom ou identifiant d’un provider) dans le .env. Seuls les providers de l’installation conviennent (ni celui d’un membre, ni un provider retiré, ni un nom que deux providers partagent) : le juge lit tous les livres de l’installation, avec la clé de son provider. Une valeur enregistrée dans l’interface l’emporte sur l’environnement.
  • Pour un livre : Livre › Réglages › Juge qualité : vide, celui de l’installation ; Aucun juge pour ce livre (un livre confidentiel traduit sur un modèle local) ; ou un provider que le propriétaire du livre peut utiliser. Le choix est revérifié à chaque passage : un provider devenu inutilisable laisse juger celui de l’installation.

Choisissez un modèle plus fort que celui qui traduit, ou au moins un autre : un modèle ne voit pas ses propres fautes (#180). Codex par un compte ChatGPT ne coûte aucun jeton ; avec une API, chaque passage coûte un appel de jugement (le passage deux fois — source et traduction — plus son contexte, environ le prix d’une relecture) et, pour les passages corrigés, une révision et une seconde lecture. Le budget et la concurrence du provider s’appliquent comme pour tout appel ; l’estimation affichée avant une traduction ne compte pas encore les appels du juge.

VariableValeur par défautEffet
QUALITY_JUDGE_PROVIDERvideNom ou identifiant du provider qui juge. Vide : pas de juge, sauf si Paramètres › Pilote automatique ou le livre en nomment un.
QUALITY_REWORK_SHARE0.25 (0–1)Part maximale des passages d’un travail corrigés après le juge. 0 : jugés, jamais corrigés.

Banc de mesure

python -m app.bench fait relire des traductions par le juge, pour comparer deux modèles, deux versions de prompts ou deux versions de Libris sur le même texte avant une publication. Les appels sont journalisés comme les autres ; rien n’est écrit dans les livres.

# Un fichier : un objet JSON par ligne, avec "source", un champ par système et une "reference" facultative.
# --book nomme le volume dont la paire de langues et la licence portent les appels.
docker compose exec api python -m app.bench file /data/bench/pairs.jsonl --book <id du projet> [--judge <provider>]
# Un échantillon d’un volume (40 passages répartis dans le livre), et les mêmes passages d’un autre volume.
docker compose exec api python -m app.bench book <id du projet> --compare <id du projet> --sample 40

Une ligne par système (ou par volume) : items, errors et warnings (les points du juge), with errors (les éléments qu’il ferait corriger) et chrF (score F sur n-grammes de caractères contre les références, calculé comme sacreBLEU). --json donne tous les points.

Contrôle de fidélité sémantique

Le contrôle qui compare chaque nouvelle version d’un passage à sa source (première traduction, révision, polissage, correction, arbitrage) est lu par le juge configuré, et non par le modèle qui a traduit : deux lectures du même modèle peuvent partager un même contresens. Le provider qui a lu est enregistré avec chaque preuve (provider_id).

ConfigurationQui lit le contrôle de fidélité
Le livre ou l’installation nomme un jugeCe juge
Aucun juge nulle partLe provider du livre
Aucun juge pour ce livreLe provider du livre : rien d’autre n’est contacté
Le juge ne répond pas (panne, clé refusée, réponse invalide)Le provider du livre, pour ce contrôle

Confidentialité

Le provider du juge reçoit le passage, sa traduction et son contexte, comme le provider du livre. Avec Codex ou une API externe, ce texte quitte la machine pour ce provider, selon ses conditions.

Cela vaut aussi pour le contrôle de fidélité : un livre traduit sur un modèle local est envoyé au juge de l’installation dès qu’il y en a un, même sans pilote automatique. Pour garder un tel livre sur la machine, choisir Aucun juge pour ce livre dans ses réglages, ou lui donner un provider local comme juge.