Ein LLM auf den eigenen Annotationen fine-tunen

Neu in v2.14.0

Dieses Tutorial trainiert vier Arten von Sprachmodellen auf den Antworten, die eine Potato-Studie sammelt. Der Trainer llm-sft fine-tunt ein LLM auf geschriebenen Antworten oder korrigierten Agenten-Traces, llm-dpo tunt ein LLM auf paarweisen Entscheidungen, reward-model fittet ein skalares Reward-Modell auf Vergleichen, und prm-reward fittet ein Process-Reward-Modell auf Schrittbewertungen. Die Seite richtet sich an Teams, die in Potato bereits Präferenz- oder Trace-Daten sammeln und aus diesen Labels ein erstes Modell erhalten wollen, ohne die Daten in ein separates Trainingsskript zu exportieren. Jeder Abschnitt nennt das Schema, das die Daten erzeugt, gibt eine Konfiguration an, die den Validator von Potato besteht, listet die Parameter, die sich zu ändern lohnen, und sagt, was der Holdout-Score misst und ob die Vorhersagen als Vorlabels zu den Annotatoren zurückgehen. Die Übersicht zum Modelltraining behandelt die Training-Seite, und Das erste Modell trainieren durchläuft den ganzen Kreislauf mit einem Klassifikator, der keine GPU braucht.

Trainer nach Annotationsschema

Jeder Trainer auf dieser Seite lernt pro Lauf aus einem Annotationsschema, und die Training-Seite bietet einen Trainer nur für die Schemas an, aus denen er lernen kann. Die folgende Tabelle listet die Schemas, aus denen jeder Trainer lernt:

Bevor es losgeht

Die Trainings-Extras von Potato installieren PyTorch, Transformers und PEFT für die vier Trainer:

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

Das erste Extra deckt llm-sft und llm-dpo ab, das zweite reward-model und prm-reward. pip install "potato-annotation[train]" installiert alle Trainings-Extras auf einmal. Ein Trainer, dessen Pakete fehlen, steht auf der Training-Seite als „not installed“, zusammen mit dem Befehl, der die Pakete installiert.

Jeder Trainer verweigert das Fitten mit weniger als 20 Items im Train-Split (der Parameter min_instances). Der Standard-Split legt 70 % der gelabelten Items in Train, 15 % in Val und 15 % in Test, daher sind vor dem ersten Lauf etwa 30 gelabelte Items einzuplanen. Die Val- und Test-Items sind vom Training zurückgehalten und bewerten das Modell.

llm-sft und llm-dpo starten von Qwen/Qwen2.5-0.5B-Instruct, reward-model von distilbert/distilroberta-base und prm-reward von answerdotai/ModernBERT-base. Die LLM-Trainer sind für den Lauf auf einer GPU gebaut. Hat die Maschine, auf der Potato läuft, keine GPU, schickt Remote-Training Läufe per ssh an einen GPU-Server oder an einen SLURM-Cluster.

Eine Studie, die Präferenzen und Umschreibungen sammelt

Die erste Konfiguration stellt zu jedem Kundensupport-Prompt zwei Fragen. Annotatoren wählen die bessere von zwei Antworten und schreiben die Antwort, die sich ein Annotator vom Assistenten wünschen würde. Die Wahl trainiert llm-dpo und reward-model, und die geschriebene Antwort trainiert llm-sft. Jede Zeile von data/answers.jsonl enthält einen Prompt und die zwei Antworten:

{"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."]}

Die Konfiguration zeigt den Prompt als Text des Items und die zwei Antworten als Karten A und 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 zählt doppelt, denn der Prompt ist das, was Annotatoren lesen, und das, was llm-sft nach der Frage einsetzt. items_key: responses nennt die Liste, aus der die Pairwise-Karten stammen, in Datenreihenfolge, sodass A die erste Antwort ist. writeback.schemas listet nur preferred, daher sehen Annotatoren die Wahl des Modells und keine generierte Umschreibung. Vorlabels verankern Annotatoren, daher sollte rewrite erst dann in die Liste aufgenommen werden, wenn der Holdout-Score des llm-sft-Laufs dafür spricht, den Text des Modells zu zeigen. min_confidence: 0.7 hält Vorhersagen, bei denen sich das Modell weniger sicher ist, von der Seite fern und speichert die Vorhersagen dennoch. Die Konfiguration wird vor dem Start des Servers mit dem Validator von Potato geprüft:

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

Potato starten, mindestens 30 Prompts labeln und /admin/training als Admin öffnen. Die folgenden Läufe lassen sich auch über die API starten, mit dem admin_api_key der Konfiguration in $KEY.

Supervised Fine-Tuning mit llm-sft

llm-sft macht aus jedem gelabelten Item ein Trainingsbeispiel. Der Prompt ist die description des Schemas (die Frage, die Annotatoren sahen), gefolgt vom Text des Items, und das Ziel ist die Antwort, die der Annotator geschrieben hat. Der Loss deckt nur die Tokens der Antwort ab, sodass das Modell lernt zu antworten, statt den Prompt zu wiederholen. Standardmäßig wird ein LoRA-Adapter trainiert statt aller Gewichte.

Auf der Training-Seite llm-sft und das Schema rewrite wählen und auf Train now klicken, oder denselben Lauf über die API starten:

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}}'

Die meisten Läufe ändern nur die Parameter in dieser Tabelle:

Der Lauf behält den Checkpoint mit dem niedrigsten Val-Loss. Weil der Lauf den Checkpoint anhand von Val gewählt hat, wird der Holdout-Score auf Test gelesen. Der Score ist Token-F1, die Überschneidung der Wörter zwischen generierter und geschriebener Antwort unabhängig von der Reihenfolge, mit Exact Match neben dem Score. Token-F1 honoriert eine Antwort, die die richtigen Wörter an den falschen Stellen verwendet, daher sind beide Metriken zusammen zu lesen.

Das Modell generiert für jedes Val- und Test-Item greedy eine Antwort. Mit writeback.include_unlabeled: true beantwortet das Modell auch die Items, die niemand gelabelt hat. Die Konfidenz einer Vorhersage ist die mittlere Wahrscheinlichkeit des Modells für die Tokens, die es generiert hat, und die Warteschlange zur Modellprüfung sortiert nach dieser Konfidenz. Steht rewrite unter writeback.schemas, füllt die generierte Antwort das Textfeld, sobald ein Annotator das Item öffnet.

Freitext eignet sich schlecht für mehrere Annotatoren pro Item. Die Einstellung aggregation löst mehrere Antworten zu einer auf, indem sie Antworten Wort für Wort vergleicht, und zwei geschriebene Antworten stimmen selten Wort für Wort überein. Bei llm-sft auf einem text-Schema vermeidet ein Schreiber pro Item den Wort-für-Wort-Vergleich.

Präferenz-Tuning mit llm-dpo

Direct Preference Optimization (DPO) trainiert ein LLM darauf, die Wahrscheinlichkeit der bevorzugten Antwort relativ zur anderen Antwort zu erhöhen, gemessen an einer eingefrorenen Referenzkopie des Ausgangsmodells. llm-dpo baut aus jedem Item, das mit A oder B beantwortet wurde, ein Beispiel. Der Prompt ist das Feld prompt des Items oder das erste der Felder question, instruction, query, input und context, das das Item hat. Items, die mit der Gleichstand-Option beantwortet wurden, bleiben außen vor, denn ein Gleichstand markiert keine der beiden Antworten als besser.

llm-dpo und das Schema preferred wählen, oder dieselbe Anfrage wie oben mit "trainer": "llm-dpo" und "schemas": ["preferred"] senden. Beim standardmäßigen LoRA-Adapter ist das Referenzmodell dasselbe Modell mit abgeschaltetem Adapter, sodass keine zweite Kopie im Speicher gehalten wird. lora: false trainiert alle Gewichte und behält eine eingefrorene Kopie als Referenz, und die eingefrorene Kopie verdoppelt den Speicher.

Der Lauf behält den Checkpoint mit dem niedrigsten DPO-Loss auf Val, und das Lauf-Log meldet, wie oft das Modell auf Val die Wahl der Annotatoren bevorzugt. Der Holdout-Score ist die Accuracy auf Test über die Items, die nicht als Gleichstand beantwortet wurden, mit Macro-F1 neben der Accuracy. Eine Vorhersage ist die Antwort, die das trainierte Modell bevorzugt, mit der Wahrscheinlichkeit dieser Präferenz als Konfidenz. Als Vorlabel ist die Karte der bevorzugten Antwort ausgewählt, wenn der Annotator das Item öffnet. Mit randomize_order am Schema folgt die Auswahl der Antwort dorthin, wo der Annotator sie sieht. Der gespeicherte Adapter ist ebenfalls eine Policy und generiert Text, wenn er mit PEFT geladen wird. Hintergründe zum Sammeln der Präferenzdaten selbst bieten RLHF- und Präferenzdaten sammeln und Paarvergleich.

Ein Reward-Modell mit reward-model

Ein Reward-Modell bildet eine Antwort auf eine Zahl ab, für RLHF, für Best-of-n-Sampling oder zum Ranken neuer Ausgaben. reward-model trainiert einen Transformer mit einem Ausgang so, dass die Antwort, die Annotatoren bevorzugt haben, höher punktet. Der Loss ist der Bradley-Terry-Loss, -log sigmoid(r_winner - r_loser), der Reward-Modeling-Loss von InstructGPT. Das Schema preferred von oben trainiert reward-model ohne Änderung der Konfiguration. Jedes vergleichende Schema liefert ein anderes Trainingssignal:

Hat ein Item ein Prompt-Feld, gilt jeder Reward der Antwort bei gegebenem Prompt. Die Optionen eines Rankings sind die Labels des Schemas, jedes bewertet bei gegebenem Text des Items. Der Server baut BWS-Tupel aus bws_config, daher hat ein Lauf aus den eigenen Daten des Servers die Tupel, und die Datendateien brauchen die Tupel nicht.

Vorhersagen beantworten die eigene Frage des Schemas, daher werden die Vorhersagen wie bei jedem anderen Schema bewertet und zurückgeschrieben. Das Vorlabel ist die ausgewählte Karte bei einer binären Wahl, die Reglerposition bei einer Skala, die Reihenfolge der Liste bei einem Ranking und das ausgewählte Beste und Schlechteste bei BWS. Jede Vorhersage speichert außerdem die rewards, aus denen sie entstand. Nur Differenzen zwischen Rewards sind aussagekräftig. Paarvergleich und Best-Worst-Scaling vergleicht die vergleichenden Formate zum Sammeln der Daten.

Eine Studie, die Schrittbewertungen und Korrekturen sammelt

Die zweite Konfiguration arbeitet mit Agenten-Traces. Annotatoren bewerten jeden Schritt des Traces und korrigieren dann die falschen Schritte. Die Schrittbewertungen trainieren prm-reward, und die Korrekturen trainieren llm-sft oder llm-dpo. Jede Zeile von data/traces.jsonl enthält die Aufgabe, die Schritte des Agenten und die endgültige Antwort:

{"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."}

Die Trainer lesen die Aufgabe aus dem Feld task_description, task oder text des Items, in dieser Reihenfolge:

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 mit allow_neutral: true ergibt die drei Bewertungen, die prm-reward lernt. ai_prelabel: true setzt die Schaltfläche „AI pre-label steps“ ans Schema, und die trainierten Bewertungen erscheinen über die Schaltfläche. writeback.schemas nennt nur step_quality. Steht corrected_trace dort, startet der Server nicht mehr, und der Validator nennt den Grund:

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.

Traces reparieren mit llm-sft und llm-dpo

Eine trajectory_edit-Antwort ist ein Paar von Traces, die ursprünglichen Schritte des Agenten und die Schritte nach den Korrekturen des Annotators. Trajectory-Bearbeitung für SFT/DPO behandelt den Editor, und der Beitrag zur Trajectory-Bearbeitung behandelt, wie aus den Paaren Trainingsdaten werden. Beide Trainer lassen Traces außen vor, die niemand bearbeitet hat.

• llm-sft nimmt die Aufgabe und die ursprünglichen Schritte als Prompt und die korrigierten Schritte als Ziel, sodass das Modell lernt, einen Trace zu reparieren. Jeder Schritt wird als Step N geschrieben, gefolgt von den Feldern des Schritts (action: ..., thought: ...), und die endgültige Antwort folgt auf den letzten Schritt, wenn das Schema final_answer_key hat.
• llm-dpo nimmt die Aufgabe als Prompt, die korrigierten Schritte als bevorzugte Antwort und die ursprünglichen Schritte als andere Antwort. Eine Vorhersage sagt, ob das Modell die Korrektur (A) oder das Original (B) bevorzugt, und wird nur für zurückgehaltene Traces gemacht, die eine Korrektur haben.

Beide Läufe melden closer_to_correction als Holdout-Score. Bei llm-dpo ist der Score der Anteil zurückgehaltener Traces, bei denen das Modell die Korrektur bevorzugt. Bei llm-sft ist der Score der Anteil, bei dem die geschriebenen Schritte der Korrektur nach Token-F1 näher sind als dem Original, mit token_f1 gegenüber der Korrektur neben dem Score.

Die Vorhersagen eines trajectory_edit-Laufs werden gespeichert und bewertet, und Annotatoren sehen die Vorhersagen nie. Der Editor beginnt immer beim ursprünglichen Trace des Agenten, daher hat die Seite keinen Platz, um eine vorhergesagte Umschreibung zu zeigen. Die Vorhersagen sind auf der Lauf-Seite oder in artifacts/predictions.jsonl im Verzeichnis des Laufs zu lesen.

Schrittbewertungen mit prm-reward

Ein Process-Reward-Modell bewertet die Schritte eines Traces statt nur die endgültige Antwort, wie in PRM800K. prm-reward gibt den ganzen Trace als eine Eingabe an einen Transformer-Encoder, die Aufgabe gefolgt von Step 1, Step 2 und so weiter. Der Encoder lernt am letzten Token jedes Schritts eine dreistufige Bewertung, sodass jede Bewertung mit den vorangehenden Schritten im Blick entsteht. Schritte, die niemand bewertet hat, bleiben im Loss außen vor. Das Standardmodell answerdotai/ModernBERT-base wurde wegen seines Kontexts von 8.192 Tokens gewählt.

Lange Traces verlieren ihre letzten Schritte. Ein Trace, der länger als max_length Tokens ist, wird am Ende abgeschnitten, und die Schritte hinter dem Schnitt werden weder trainiert noch bewertet. Das Lauf-Log zählt die verlorenen Schritte. Ist max_length größer, als das Modell fasst, senkt der Lauf max_length mit einer Warnung auf die Grenze des Modells, und die Grenze liegt bei den meisten BERT-artigen Encodern bei 512 Tokens. Meldet das Lauf-Log verlorene Schritte, ist max_length zu erhöhen und ein Modell zu wählen, dessen Kontext die längeren Traces fasst.

Der Holdout-Score ist step_macro_f1, Macro-F1 über die drei Bewertungen bei jedem bewerteten Schritt. Die meisten Schritte der meisten Traces sind correct, daher würde die Accuracy ein Modell begünstigen, das nie „wrong“ sagt. Der Lauf meldet außerdem step_accuracy und first_error_accuracy, den Anteil der Traces, bei denen der erste falsche Schritt des Modells der erste falsche Schritt der Annotatoren ist.

Eine Vorhersage bewertet jeden Schritt, der in max_length passt, mit der Wahrscheinlichkeit jeder Bewertung als deren Konfidenz und dem am wenigsten sicheren Schritt als Konfidenz des Traces. Steht das Schema in writeback.schemas und ist ai_prelabel: true gesetzt, bietet die Schaltfläche „AI pre-label steps“ die trainierten Bewertungen dem Annotator zur Prüfung an. Ein unter ai_support konfigurierter LLM-Judge wird für ein Item mit trainierten Bewertungen nicht aufgerufen. Process-Reward-Annotation behandelt das Schema, und der Leitfaden zu Process-Reward-Modellen behandelt die Daten.

Ein größeres Modell mit QLoRA unterbringen

QLoRA lädt die Gewichte des Basismodells in 4 Bit und trainiert darauf einen LoRA-Adapter. llm-sft, llm-dpo, hf-text-classification, vlm-sft und reward-model akzeptieren lora: {quantize: 4bit}, und prm-reward lehnt die Einstellung ab, bevor das Modell geladen wird. Der Speicher ist anhand der Zeile „Peak GPU memory“ zu planen, die jeder Transformer-Lauf am Ende loggt. Der QLoRA-Abschnitt der Konfigurationsreferenz beschreibt, wie die Basisgewichte geladen werden, und die 8-Bit-Option.

Dieser Block, zur obigen Konfiguration hinzugefügt, setzt QLoRA als Standard für llm-sft:

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

QLoRA braucht eine CUDA-GPU und einen bitsandbytes-Build für das CUDA dieser Maschine, installiert mit pip install bitsandbytes. Ohne funktionierende GPU oder passenden Build bricht der Lauf bei der Validierung ab, bevor das Modell geladen wird.

Einen Lauf auf dem Hugging Face Hub veröffentlichen

Ein erfolgreicher Lauf, dessen Modell auf dem Potato-Server liegt, hat auf der Lauf-Seite Publish to the Hugging Face Hub. Der Push lädt das Modell und eine aus dem Lauf erzeugte README.md-Modellkarte hoch, mit dem Trainer, dem Basismodell und Adapter, den Schemas und Labels, den Split-Größen, dem Holdout-Score und dem, woran der Score gemessen wurde, sowie den Lauf- und Bundle-IDs. Ein LoRA-Lauf hat nur den Adapter gespeichert, daher enthält das Hub-Repository den Adapter, und die Karte nennt das Basismodell, auf das der Adapter geladen wird.

Der Token bleibt außerhalb des Browsers. Ein Schreib-Token wird in den Hugging-Face-Einstellungen angelegt und vor dem Start von Potato in die Umgebung des Servers gesetzt:

export HF_TOKEN=hf_your_write_token
potato start config.yaml

Das Formular nennt die Umgebungsvariable, standardmäßig HF_TOKEN, fragt den Repository-Namen zweimal ab und lässt Private standardmäßig angehakt. Auf dem Hugging Face Hub veröffentlichen listet die Dateien, die hochgeladen werden, die Prüfungen vor einem Push und die Lizenz der Modellkarte. Derselbe Push über die 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"}'

Die Route liefert 201 mit dem Commit. Ein Modell, das mit fetch_artifacts: false auf einem Remote-Host geblieben ist, lässt sich nicht vom Potato-Server aus pushen, und die Lauf-Seite sagt, wo das Modell liegt. Der Schritt von einem veröffentlichten Modell zu einem Active-Learning-Kreislauf führt weiter über Das Modell im Kreislauf.

Weiterführende Links

• Konfiguration des Modelltrainings: jeder model_training-Schlüssel, die Holdout-Scores, das Rückschreiben und die Routen.
• Trainer: alle 38 Trainer, nach Aufgabe gruppiert.
• Remote-Training: GPU-Server über ssh, SLURM-Cluster und der Polling-Agent.
• Annotation von Agenten-Trajektorien: Trace-Daten in Potato sammeln.
• Referenzabschnitte im Upstream zu llm-sft, llm-dpo, Agenten-Traces, prm-reward, reward-model, QLoRA und Hub-Veröffentlichung.

Literatur

• 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