Affiner un LLM sur vos annotations

Nouveauté de la v2.14.0

Ce tutoriel entraîne quatre types de modèles de langage sur les réponses qu'une étude Potato recueille. Le module llm-sft affine un LLM sur des réponses rédigées ou des traces d'agent corrigées, llm-dpo règle un LLM sur des choix par paires, reward-model ajuste un modèle de récompense scalaire sur des comparaisons, et prm-reward ajuste un modèle de récompense de processus sur des notes d'étapes. La page s'adresse aux équipes qui recueillent déjà des données de préférence ou de trace dans Potato et veulent un premier modèle à partir de ces étiquettes, sans exporter les données vers un script d'entraînement distinct. Chaque section nomme le schéma qui produit les données, donne une configuration qui passe le validateur de Potato, liste les paramètres qui valent la peine d'être modifiés, et précise ce que mesure le score sur items réservés et si les prédictions retournent aux annotateurs sous forme de pré-étiquettes. La vue d'ensemble de l'entraînement de modèles traite de la page Training, et Entraîner votre premier modèle exécute toute la boucle avec un classifieur qui n'a pas besoin de GPU.

Modules d'entraînement par schéma d'annotation

Chaque module d'entraînement de cette page apprend d'un seul schéma d'annotation par exécution, et la page Training ne propose un module que pour les schémas qu'il sait apprendre. Le tableau ci-dessous liste les schémas dont chaque module apprend :

Avant de commencer

Les extras d'entraînement de Potato installent PyTorch, Transformers et PEFT pour les quatre modules :

pip install "potato-annotation[train-llm]"
pip install "potato-annotation[train-text]"

Le premier extra couvre llm-sft et llm-dpo, et le second couvre reward-model et prm-reward. pip install "potato-annotation[train]" installe tous les extras d'entraînement d'un coup. Un module dont les paquets manquent apparaît sur la page Training avec la mention « not installed » et la commande qui installe les paquets.

Chaque module refuse de s'ajuster avec moins de 20 items dans la partition train (le paramètre min_instances). La partition par défaut place 70 % des items étiquetés dans train, 15 % dans val et 15 % dans test, donc prévoyez environ 30 items étiquetés avant la première exécution. Les items val et test sont tenus à l'écart de l'entraînement et servent à évaluer le modèle.

llm-sft et llm-dpo partent de Qwen/Qwen2.5-0.5B-Instruct, reward-model de distilbert/distilroberta-base et prm-reward de answerdotai/ModernBERT-base. Les modules pour LLM sont conçus pour tourner sur un GPU. Quand la machine qui fait tourner Potato n'a pas de GPU, l'entraînement à distance envoie les exécutions à un serveur GPU par ssh ou à un cluster SLURM.

Une étude qui recueille des préférences et des réécritures

La première configuration pose deux questions sur chaque invite de support client. Les annotateurs choisissent la meilleure de deux réponses et écrivent la réponse qu'un annotateur voudrait obtenir de l'assistant. Le choix entraîne llm-dpo et reward-model, et la réponse écrite entraîne llm-sft. Chaque ligne de data/answers.jsonl contient une invite et les deux réponses :

{"id": "q001", "prompt": "How do I reset my router to factory settings?", "responses": ["Hold the reset button on the back for 10 seconds until the lights blink, then wait two minutes for the router to restart.", "Routers can be reset. Check the manual."]}

La configuration affiche l'invite comme texte de l'item et les deux réponses comme cartes A et B :

annotation_task_name: "Support answers: preferences and rewrites"
task_dir: .
data_files:
  - data/answers.jsonl
item_properties:
  id_key: id
  text_key: prompt
output_annotation_dir: annotation_output
user_config:
  allow_all_users: true
 
annotation_schemes:
  - annotation_type: pairwise
    name: preferred
    description: "Which response answers the question better?"
    mode: binary
    items_key: responses
    allow_tie: true
    tie_label: "No preference"
 
  - annotation_type: text
    name: rewrite
    description: "Write the answer you would want the assistant to give."
    multiline: true
    rows: 4
 
model_training:
  enabled: true
  writeback:
    schemas: [preferred]
    min_confidence: 0.7

text_key: prompt compte deux fois, car l'invite est ce que les annotateurs lisent et ce que llm-sft place après la question. items_key: responses nomme la liste d'où viennent les cartes pairwise, dans l'ordre des données, donc A est la première réponse. writeback.schemas ne liste que preferred, donc les annotateurs voient le choix du modèle et non une réécriture générée. Les pré-étiquettes ancrent les annotateurs, donc n'ajoutez rewrite à la liste que lorsque le score sur items réservés de l'exécution llm-sft justifie de montrer le texte du modèle. min_confidence: 0.7 garde hors de la page les prédictions dont le modèle est moins sûr, tout en les stockant. Vérifiez la configuration avec le validateur de Potato avant de démarrer le serveur :

python -m potato.validate_cli config.yaml --strict

Démarrez Potato, étiquetez au moins 30 invites et ouvrez /admin/training en tant qu'administrateur. Les exécutions ci-dessous peuvent aussi démarrer depuis l'API avec le admin_api_key de la configuration dans $KEY.

Affinage supervisé avec llm-sft

llm-sft transforme chaque item étiqueté en un exemple d'entraînement. L'invite est le description du schéma (la question que les annotateurs ont vue) suivi du texte de l'item, et la cible est la réponse que l'annotateur a écrite. La perte ne porte que sur les jetons de la réponse, donc le modèle apprend à répondre plutôt qu'à répéter l'invite. Un adaptateur LoRA est entraîné par défaut au lieu de tous les poids.

Choisissez llm-sft et le schéma rewrite sur la page Training et cliquez sur Train now, ou lancez la même exécution depuis l'API :

curl -X POST -H "X-API-Key: $KEY" -H "Content-Type: application/json" \
  http://localhost:8000/admin/training/api/runs \
  -d '{"trainer": "llm-sft", "schemas": ["rewrite"], "params": {"max_new_tokens": 256}}'

La plupart des exécutions ne modifient que les paramètres de ce tableau :

L'exécution conserve le point de contrôle dont la perte sur val est la plus basse. Comme l'exécution a choisi le point de contrôle sur val, le score sur items réservés est lu sur test. Le score est le F1 par jeton, le recouvrement de mots entre la réponse générée et la réponse écrite sans tenir compte de l'ordre, avec la correspondance exacte indiquée à côté du score. Le F1 par jeton crédite une réponse qui emploie les bons mots aux mauvais endroits, donc lisez les deux métriques ensemble.

Le modèle génère une réponse de façon gloutonne pour chaque item val et test. Avec writeback.include_unlabeled: true, le modèle répond aussi aux items que personne n'a étiquetés. La confiance d'une prédiction est la probabilité moyenne que le modèle donne aux jetons qu'il a générés, et la file de relecture des modèles trie selon cette confiance. Avec rewrite sous writeback.schemas, la réponse générée remplit la zone de texte quand un annotateur ouvre l'item.

Le texte libre convient mal à plusieurs annotateurs par item. Le paramètre aggregation résout plusieurs réponses en une seule en comparant les réponses mot pour mot, et deux réponses écrites coïncident rarement mot pour mot. Pour llm-sft sur un schéma text, un seul rédacteur par item évite la comparaison mot pour mot.

Réglage par préférences avec llm-dpo

Direct Preference Optimization (DPO) entraîne un LLM à augmenter la vraisemblance de la réponse préférée par rapport à l'autre réponse, mesurée face à une copie de référence figée du modèle de départ. llm-dpo construit un exemple à partir de chaque item répondu A ou B. L'invite est le champ prompt de l'item, ou le premier des champs question, instruction, query, input et context que l'item possède. Les items répondus avec l'option d'égalité sont écartés, car une égalité ne désigne aucune réponse comme meilleure.

Choisissez llm-dpo et le schéma preferred, ou envoyez la même requête que ci-dessus avec "trainer": "llm-dpo" et "schemas": ["preferred"]. Avec l'adaptateur LoRA par défaut, le modèle de référence est le même modèle avec l'adaptateur désactivé, donc aucune seconde copie n'est gardée en mémoire. lora: false entraîne tous les poids et garde une copie figée comme référence, et la copie figée double la mémoire.

L'exécution conserve le point de contrôle dont la perte DPO sur val est la plus basse, et le journal de l'exécution indique à quelle fréquence le modèle préfère le choix des annotateurs sur val. Le score sur items réservés est l'exactitude sur test, calculée sur les items non répondus par une égalité, avec le F1 macro à côté de l'exactitude. Une prédiction est la réponse que le modèle entraîné préfère, avec la probabilité de cette préférence comme confiance. Comme pré-étiquette, la carte de la réponse préférée est sélectionnée quand l'annotateur ouvre l'item. Avec randomize_order sur le schéma, la sélection suit la réponse là où l'annotateur la voit. L'adaptateur enregistré est aussi une politique et génère du texte une fois chargé avec PEFT. Pour le contexte de la collecte des données de préférence elles-mêmes, voir Recueillir des données RLHF et de préférence et Comparaison par paires.

Un modèle de récompense avec reward-model

Un modèle de récompense associe une réponse à un nombre, pour le RLHF, pour l'échantillonnage best-of-n ou pour classer de nouvelles sorties. reward-model entraîne un transformeur à une seule sortie pour que la réponse préférée par les annotateurs obtienne un score plus élevé. La perte est la perte de Bradley–Terry, -log sigmoid(r_winner - r_loser), la perte de modélisation de la récompense d'InstructGPT. Le schéma preferred ci-dessus entraîne reward-model sans aucun changement de configuration. Chaque schéma comparatif donne un signal d'entraînement différent :

Quand un item a un champ d'invite, chaque récompense porte sur la réponse étant donné l'invite. Les options d'un classement sont les étiquettes du schéma, chacune évaluée étant donné le texte de l'item. Le serveur construit les n-uplets BWS à partir de bws_config, donc une exécution sur les données propres du serveur dispose des n-uplets, et les fichiers de données n'ont pas besoin de les contenir.

Les prédictions répondent à la question propre du schéma, donc elles sont évaluées et réécrites comme celles de n'importe quel autre schéma. La pré-étiquette est la carte sélectionnée pour un choix binaire, la position du curseur pour une échelle, l'ordre de la liste pour un classement, et le meilleur et le pire sélectionnés pour BWS. Chaque prédiction stocke aussi les rewards dont elle provient. Seules les différences entre récompenses ont un sens. Pairwise et Best-Worst Scaling compare les formats comparatifs pour recueillir les données.

Une étude qui recueille des notes d'étapes et des corrections

La seconde configuration porte sur des traces d'agent. Les annotateurs notent chaque étape de la trace puis corrigent les étapes fausses. Les notes d'étapes entraînent prm-reward, et les corrections entraînent llm-sft ou llm-dpo. Chaque ligne de data/traces.jsonl contient la tâche, les étapes de l'agent et la réponse finale :

{"id": "traj_001", "task_description": "Find the current weather in San Francisco and report the temperature.", "steps": [{"thought": "I should look up the current weather.", "action": "web_search(queyr='San Francisco weather')"}, {"thought": "Open the first result.", "action": "open_url(results[0])"}, {"thought": "Read the temperature from the page.", "action": "extract_text('.temp')"}], "final_answer": "It is sunny."}

Les modules d'entraînement lisent la tâche dans le champ task_description, task ou text de l'item, dans cet ordre :

annotation_task_name: "Agent traces: step ratings and corrections"
task_dir: .
data_files:
  - data/traces.jsonl
item_properties:
  id_key: id
  text_key: task_description
output_annotation_dir: annotation_output
user_config:
  allow_all_users: true
 
annotation_schemes:
  - annotation_type: process_reward
    name: step_quality
    description: "Rate each step of the agent's trace"
    steps_key: steps
    step_text_key: action
    mode: per_step
    allow_neutral: true
    ai_prelabel: true
 
  - annotation_type: trajectory_edit
    name: corrected_trace
    description: "Fix the wrong steps, then correct the final answer"
    steps_key: steps
    step_text_key: action
    editable_fields: [action]
    show_diff: true
    edit_final_answer: true
    final_answer_key: final_answer
 
model_training:
  enabled: true
  writeback:
    schemas: [step_quality]
    include_unlabeled: true

mode: per_step avec allow_neutral: true donne les trois notes que prm-reward apprend. ai_prelabel: true ajoute le bouton « AI pre-label steps » au schéma, et les notes entraînées apparaissent par ce bouton. writeback.schemas ne nomme que step_quality. Y lister corrected_trace empêche le serveur de démarrer, et le validateur en donne la raison :

model_training.writeback.schemas names 'corrected_trace', a trajectory_edit scheme, which has no prelabel display: its predictions are stored and scored but annotators would never see them. Leave it out of writeback.schemas.

Réparer des traces avec llm-sft et llm-dpo

Une réponse trajectory_edit est une paire de traces, les étapes d'origine de l'agent et les étapes après les corrections de l'annotateur. Édition de trajectoire pour SFT/DPO traite de l'éditeur, et l'article sur l'édition de trajectoire explique comment les paires deviennent des données d'entraînement. Les deux modules écartent les traces que personne n'a modifiées.

• llm-sft prend la tâche et les étapes d'origine comme invite et les étapes corrigées comme cible, donc le modèle apprend à réparer une trace. Chaque étape est écrite sous la forme Step N suivie des champs de l'étape (action: ..., thought: ...), et la réponse finale suit la dernière étape quand le schéma a final_answer_key.
• llm-dpo prend la tâche comme invite, les étapes corrigées comme réponse préférée et les étapes d'origine comme autre réponse. Une prédiction indique si le modèle préfère la correction (A) ou l'original (B), et n'est faite que pour les traces réservées qui ont une correction.

Les deux exécutions rapportent closer_to_correction comme score sur items réservés. Pour llm-dpo, le score est la part des traces réservées où le modèle préfère la correction. Pour llm-sft, le score est la part où les étapes écrites sont plus proches de la correction que de l'original selon le F1 par jeton, avec le token_f1 par rapport à la correction indiqué à côté du score.

Les prédictions d'une exécution trajectory_edit sont stockées et évaluées, et les annotateurs ne les voient jamais. L'éditeur part toujours de la trace d'origine de l'agent, donc la page n'a aucun endroit où montrer une réécriture prédite. Lisez les prédictions depuis la page de l'exécution ou depuis artifacts/predictions.jsonl dans le répertoire de l'exécution.

Notes d'étapes avec prm-reward

Un modèle de récompense de processus note les étapes d'une trace plutôt que la seule réponse finale, comme dans PRM800K. prm-reward donne la trace entière à un encodeur transformeur comme une seule entrée, la tâche suivie de Step 1, Step 2, et ainsi de suite. L'encodeur apprend une note à trois classes sur le dernier jeton de chaque étape, donc chaque note est faite en voyant les étapes qui précèdent. Les étapes que personne n'a notées sont écartées de la perte. Le modèle par défaut, answerdotai/ModernBERT-base, a été choisi pour son contexte de 8 192 jetons.

Les longues traces perdent leurs dernières étapes. Une trace plus longue que max_length jetons est coupée par la fin, et les étapes au-delà de la coupure ne sont ni apprises ni notées. Le journal de l'exécution compte les étapes perdues. Quand max_length dépasse ce que le modèle accepte, l'exécution abaisse max_length à la limite du modèle avec un avertissement, et cette limite est de 512 jetons pour la plupart des encodeurs de type BERT. Quand le journal signale des étapes perdues, augmentez max_length et choisissez un modèle dont le contexte contient les traces plus longues.

Le score sur items réservés est step_macro_f1, le F1 macro sur les trois notes de chaque étape notée. La plupart des étapes de la plupart des traces sont correctes, donc l'exactitude flatterait un modèle qui ne dit jamais « faux ». L'exécution rapporte aussi step_accuracy et first_error_accuracy, la part des traces où la première étape fausse du modèle est la première étape fausse des annotateurs.

Une prédiction note chaque étape qui tient dans max_length, avec la probabilité de chaque note comme confiance de la note et l'étape la moins sûre comme confiance de la trace. Avec le schéma dans writeback.schemas et ai_prelabel: true, le bouton « AI pre-label steps » propose les notes entraînées à vérifier par l'annotateur. Un LLM juge configuré sous ai_support n'est pas appelé pour un item qui a des notes entraînées. Annotation de récompense de processus traite du schéma, et le guide des modèles de récompense de processus traite des données.

Ajuster un modèle plus grand avec QLoRA

QLoRA charge les poids du modèle de base sur 4 bits et entraîne un adaptateur LoRA par-dessus. llm-sft, llm-dpo, hf-text-classification, vlm-sft et reward-model acceptent lora: {quantize: 4bit}, et prm-reward refuse ce réglage avant de charger le modèle. Prévoyez la mémoire d'après la ligne « Peak GPU memory » que chaque exécution de transformeur consigne à la fin. La section QLoRA de la référence de configuration décrit comment les poids de base se chargent et l'option 8 bits.

Ajoutez ce bloc à la configuration ci-dessus pour définir QLoRA comme réglage par défaut de llm-sft :

model_training:
  enabled: true
  trainer_params:
    llm-sft:
      model_name: Qwen/Qwen2.5-7B-Instruct
      lora: {quantize: 4bit}
      gradient_checkpointing: true

QLoRA exige un GPU CUDA et une version de bitsandbytes compatible avec le CUDA de cette machine, installée avec pip install bitsandbytes. Sans GPU ni version fonctionnels, l'exécution s'arrête à la validation avant de charger le modèle.

Publier une exécution sur le Hugging Face Hub

Une exécution réussie dont le modèle se trouve sur le serveur Potato affiche Publish to the Hugging Face Hub sur la page de l'exécution. L'envoi téléverse le modèle et une fiche de modèle README.md rédigée à partir de l'exécution, avec le module d'entraînement, le modèle de base et l'adaptateur, les schémas et les étiquettes, la taille des partitions, le score sur items réservés et ce sur quoi le score a été mesuré, ainsi que les identifiants de l'exécution et du lot. Une exécution LoRA n'a enregistré que l'adaptateur, donc le dépôt du Hub contient l'adaptateur, et la fiche nomme le modèle de base sur lequel charger l'adaptateur.

Le jeton reste hors du navigateur. Créez un jeton d'écriture dans vos paramètres Hugging Face et placez-le dans l'environnement du serveur avant de démarrer Potato :

export HF_TOKEN=hf_your_write_token
potato start config.yaml

Le formulaire nomme la variable d'environnement, HF_TOKEN par défaut, demande deux fois le nom du dépôt et garde Private coché par défaut. Publier sur le Hugging Face Hub liste les fichiers envoyés, les vérifications avant un envoi et la licence de la fiche de modèle. Le même envoi depuis l'API :

curl -X POST -H "X-API-Key: $KEY" -H "Content-Type: application/json" \
  http://localhost:8000/admin/training/api/runs/RUN_ID/push-to-hub \
  -d '{"repo_id": "your-org/support-dpo", "confirm_repo_id": "your-org/support-dpo", "private": true, "licence": "apache-2.0"}'

La route renvoie 201 avec le commit. Un modèle laissé sur un hôte distant avec fetch_artifacts: false ne peut pas être envoyé depuis le serveur Potato, et la page de l'exécution indique où se trouve le modèle. Pour passer d'un modèle publié à une boucle d'apprentissage actif, poursuivez avec Le modèle dans la boucle.

Pour aller plus loin

• Configuration de l'entraînement de modèles : chaque clé model_training, les scores sur items réservés, l'écriture en retour et les routes.
• Modules d'entraînement : les 38 modules d'entraînement, regroupés par tâche.
• Entraînement à distance : serveurs GPU par ssh, clusters SLURM et agent d'interrogation.
• Annotation de trajectoires d'agent : recueillir des données de trace dans Potato.
• Sections de référence en amont pour llm-sft, llm-dpo, les traces d'agent, prm-reward, reward-model, QLoRA et la publication sur le Hub.

Références

• Dettmers, T., Pagnoni, A., Holtzman, A., and Zettlemoyer, L. (2023). QLoRA: Efficient Finetuning of Quantized LLMs. arXiv:2305.14314. arxiv.org/abs/2305.14314
• Hu, E. J., Shen, Y., Wallis, P., Allen-Zhu, Z., Li, Y., Wang, S., Wang, L., and Chen, W. (2021). LoRA: Low-Rank Adaptation of Large Language Models. arXiv:2106.09685. arxiv.org/abs/2106.09685
• Lightman, H., Kosaraju, V., Burda, Y., Edwards, H., Baker, B., Lee, T., Leike, J., Schulman, J., Sutskever, I., and Cobbe, K. (2023). Let's Verify Step by Step. arXiv:2305.20050. arxiv.org/abs/2305.20050
• Ouyang, L., Wu, J., Jiang, X., Almeida, D., Wainwright, C. L., Mishkin, P., Zhang, C., Agarwal, S., Slama, K., Ray, A., Schulman, J., Hilton, J., Kelton, F., Miller, L., Simens, M., Askell, A., Welinder, P., Christiano, P., Leike, J., and Lowe, R. (2022). Training Language Models to Follow Instructions with Human Feedback. arXiv:2203.02155. arxiv.org/abs/2203.02155
• Rafailov, R., Sharma, A., Mitchell, E., Ermon, S., Manning, C. D., and Finn, C. (2023). Direct Preference Optimization: Your Language Model is Secretly a Reward Model. arXiv:2305.18290. arxiv.org/abs/2305.18290