Experiment zum Fine-Tuning von Mistral 7B mit Magic: The Gathering Drafts
(substack.com/generallyintelligent)- Mit der Auswahl von Draft-Karten in Magic: The Gathering als Aufgabe wurde untersucht, wie stark Fine-Tuning die Inferenzleistung in einer aktuellen Kartenumgebung verbessern kann, die möglicherweise nicht im LLM-Trainingskorpus enthalten ist
- Die Draft-Protokolle von 17lands wurden in Prompts umgewandelt, und die Entscheidungen von Spielern mit hoher Siegquote dienten als Korrektursignal, damit das Modell anhand des aktuellen Packs und des bisherigen Kartenpools eine Karte auswählt
- Das feinabgestimmte 7B-Parameter-Modell lag bei dieser Aufgabe klar vor GPT-4 und zeigte eine Leistung nahe am menschlichen bzw. experimentatornahen Niveau; ein fine-tuned GPT-3.5 könnte noch besser sein, wäre aber deutlich teurer
- Datenformat und Prompt-Format ließen sich wegen der langen Trainingsschleifen nur schwer schnell validieren, und selbst nach rund 40 Stunden Experimenten blieb unklar, welches Prompt-Format optimal ist
- Praktisch gesehen ist es besser, zuerst ein Evaluierungsset zu erstellen und statt eigener Trainingsskripte eher Tools wie axolotl zu verwenden; selbst kleine OSS-LLMs sind bei GPU-Speicher und Speicherplatz nicht trivial
Experimentelle Aufgabe: Magic-Draft
- Für das Experiment wurde ein Draft in Magic: The Gathering verwendet, um zu prüfen, inwieweit ein LLM auf Daten außerhalb der Verteilung schlussfolgern kann
- Magic: The Gathering ist ein strategisches Sammelkartenspiel, in dem Spieler mit Kreaturen- und Zauberkarten gegeneinander antreten; beim Draft baut man ein Deck, indem man abwechselnd Karten aus zufälligen Kartenpaketen auswählt
- Der Draft eignete sich aus zwei Gründen gut für das Experiment
- Schlussfolgern: Für eine gute Auswahl muss man sowohl die bisher gewählten Karten als auch die Karten im aktuellen Pack gemeinsam verstehen
- Daten außerhalb der Verteilung: Neue Magic-Karten erscheinen 4- bis 6-mal pro Jahr, und die neuesten Karten sind möglicherweise nicht im LLM-Trainingskorpus enthalten
- Als Daten wurden die Draft-Tracking-Protokolle von 17lands verwendet
- 17lands ist ein Dienst, der Draft-Daten aus dem digitalen Magic-Client erfasst
- Anhand der Entscheidungen von Spielern mit den höchsten Siegquoten lässt sich ein Signal erzeugen, das nahe an der „richtigen“ Antwort liegt
- Auch unter Magic-Spielern gibt es viele Debatten darüber, was die richtige Wahl ist; das Signal ist also nicht völlig eindeutig, reicht aber aus, um zu testen, ob eine neue Aufgabe erlernt wird
Aufbau des Datensatzes und Prompt-Format
- Die Draft-Daten von 17lands bestehen aus großen CSV-Dateien mit ungefähr folgenden Informationen
- Im aktuellen Pack auswählbare Karten
- Die Karten, die der Draftende bisher gewählt hat
- Die Karte, die aus diesem Pack tatsächlich gewählt wurde
- Um die Daten für das Fine-Tuning eines Sprachmodells nutzbar zu machen, wurden sie in ein textbasiertes Gesprächsformat umgewandelt
- Die system-Nachricht setzt das Modell als „DraftGPT“ und weist es an, bei einer Anfrage nach einem Draft-Pick zuerst den Kartennamen zu nennen
- Die user-Nachricht enthält die aktuelle Pack-Nummer und Pick-Nummer, den bisherigen Kartenpool, die Anzahl der in den letzten 5 Packs gesehenen Karten pro Farbe sowie die Kartenbeschreibungen des aktuellen Packs
- Die assistant-Nachricht gibt nur den Namen der gewählten Karte aus
- Beispiele für die Datenumwandlung sind verfügbar unter Beispiel: 17lands-Daten in LLM-Prompts umwandeln und vollständiger Draft-Prompt im ChatML-Format
- Der schwierigste Teil war die Formatierung der Daten so, dass das gewünschte Ergebnis entsteht
- Beim Fine-Tuning muss man für Tests an Prompt-Änderungen meist Trainingsläufe von mehreren Stunden starten
- Dadurch fühlte sich die Experimentierschleife im Vergleich zu normalem Prompt Engineering etwa 100-mal langsamer an
- Getestet wurden etwa fünf Prompt-Formate, die Menge an Detailinformationen pro Karte, zusätzlicher Kontext aus den letzten Picks sowie Trainingszeilen mit „Karten-Allgemeinwissen“, damit sich das Modell neue Karteninformationen einprägt
- Selbst nach rund 40 Stunden Experimenten ließ sich nicht sicher bestimmen, welches Prompt-Format für diese Aufgabe am besten ist
Fine-Tuning-Umgebung
- Die GPU wurde stundenweise bei Runpod gemietet
- Verwendet wurde eine RTX 4090 mit 24 GB VRAM
- Die Kosten lagen bei etwa $0.7/Stunde
- Zunächst sollte mit HuggingFace transformers und PEFT ein eigenes Trainingsskript geschrieben werden; wegen der begrenzten GPU-Ressourcen fiel die Wahl auf QLoRA
- Das Schreiben eines eigenen Skripts brachte viel Trial-and-Error mit sich
- Es gab viele Optionen, von einfachen Optimierungen wie FlashAttention, die leicht sind, wenn man sie kennt, bis zu Entscheidungen wie LoRA-Parametern, die ohne Lektüre der Papers schwer zu verstehen sind
- Man kann die Probleme einzeln lösen, aber es kostet viel Zeit, das alles selbst herauszufinden
- Letztlich wurde axolotl verwendet
- Viele Optimierungen sind dort bereits standardmäßig implementiert, wodurch sich das Ganze leichter ausführen ließ
- Die Dokumentation war ordentlich, und es wurde als geeigneter Ausgangspunkt für die meisten bewertet, die mit LLM-Fine-Tuning beginnen
Modellgröße und Kosten
- Selbst „kleine“ OSS-LLMs sind nach früheren Maßstäben sehr groß
- Ein BERT-Modell, das um 2019 oft trainiert wurde, hatte etwa 110 Millionen Parameter
- Ein 7B-Modell ist etwa 70-mal so groß
- Ein 7B-Modell ist auch im praktischen Betrieb belastend
- Die Gewichte belegen etwa 16 GB, was Speicherplatz zu einem Problem macht
- Selbst mit Methoden wie QLoRA bleibt der GPU-Speicher anspruchsvoll
- Fine-Tuning von GPT-3.5 schien potenziell bessere Ergebnisse liefern zu können, war aber teuer
- Es war etwa 100-mal teurer, als Mistral auf Bare Metal fein abzustimmen
- Auch für die Inferenz fällt ein Premiumpreis an
- Ein GPT-3.5-Fine-Tuning vergleichbar mit dem größten Trainingslauf von Mistral-7B hätte rechnerisch etwa $500 gekostet
Evaluierung und Ergebnisse
- Es ist wichtig, schon vor dem Experiment zuerst ein gutes Evaluierungsset zu erstellen
- Für diese Aufgabe wurden einige vollständige Drafts aus den Trainingsdaten zurückgehalten, um zu prüfen, ob das Modell dieselben Karten wie Menschen auswählt
- Mit einem Evaluierungsset ließ sich das Ergebnis des Fine-Tunings leichter beurteilen
- Die Genauigkeit bei der Kartenauswahl war relativ leicht zu definieren, aber die folgenden Kriterien waren deutlich unklarer
- Wenn das Modell eine andere Wahl trifft, sollte diese Wahl begründbar sein
- Es wäre gut, wenn das Modell plausibel erklären kann, warum es diese Karte gewählt hat
- Diese unklaren Kriterien wurden durch visuelle Begutachtung vieler Beispiele geprüft, was langsam war
- GPT-4 traf weniger seltsame Entscheidungen als das feinabgestimmte kleine Modell und war besser darin, seine Auswahl zu begründen
- Das feinabgestimmte 7B-Modell übertraf GPT-4 mit In-Context Learning bei dieser Kartenauswahl-Aufgabe sowohl bei Genauigkeit als auch bei den Kosten deutlich
- In einem Experiment wurde das Modell auf einem Kartenset feinabgestimmt und anschließend auf einem ungesehenen Kartenset evaluiert
- Das Modell schien nicht einfach nur gute Karten auswendig gelernt zu haben, sondern den Draft-Begriff bis zu einem gewissen Grad zu verallgemeinern
Magic Copilot und Draft-Bots
- Das feinabgestimmte Draft-Pick-Modell wurde mit Magic-Arena-Logs verbunden, und mit einer schnellen Electron-App wurde „Magic Copilot“ gebaut, das in mehreren Drafts verwendet wurde
- Die Kartenauswahl wurde vom feinabgestimmten Modell erzeugt, die Erläuterungen übernahm GPT-4
- Meist funktionierte das gut, aber gelegentlich stimmte GPT-4 der Auswahl des feinabgestimmten Modells nicht zu und widersprach sofort
- Es wurden auch 8 Draft-AIs verbunden, um Simulations-Drafts zwischen Bots laufen zu lassen
- Wenn nur Bots Karten weitergaben, tendierten sie stark zu einfarbigen Decks
- Wenn Menschen andere Entscheidungen einbrachten, konvergierte das Ergebnis eher zu deutlich normaleren Deckformen
- Insgesamt wirkte diese Draft-AI wie eine der stärkeren und menschlicheren Draft-AIs, die es derzeit gibt
- Im Vergleich zu den Quick-Draft-Bots von Magic Arena trifft sie Entscheidungen, die näher an hochwertigen menschlichen Draftern liegen als an heuristikbasierten Bots
1 Kommentare
Hacker-News-Kommentare
Mir gefiel, dass dieser Beitrag gut zeigt, wie schwierig es ist, selbst konzeptionell simpel wirkende Ideen mit LLM-Finetuning umzusetzen
Selbst mit einem ziemlich guten Ausgangsdatensatz und einem brauchbaren Basismodell scheint das keine leichte Aufgabe gewesen zu sein. Solche Modelle wirken geeignet für Aufgaben, bei denen es keine natürliche, eindeutig richtige Antwort gibt. Aus einer vorgegebenen Liste die perfekte Karte auszuwählen, ist kombinatorisch womöglich schwer lösbar, aber eine gute Karte auszuwählen ist machbar, und auch ein LLM kann dabei offenbar an menschliche Leistung herankommen. Das zeigt wohl ganz gut, welche Problemklassen sich derzeit mit feinabgestimmten LLMs lösen lassen
Diesen Monat lasse ich mir zum Beispiel dabei helfen, Geschenke für Freunde und Kinder zu finden. Zur Lösung des Problems braucht man nicht die beste Wahl, eine gute Wahl reicht völlig aus
Vielleicht nicht die revolutionärste Veränderung im Alltag, aber ich freue mich wirklich auf Bot-Gegner mit interessanten Spielstilen in Spielen wie Magic: The Gathering
Das wirkt wie ein klarer Anwendungsfall, der die Fähigkeit von Forschungs- und Entwicklungsteams stark verbessern könnte, neue Mechaniken auf unterschiedlichen Spielniveaus zu entwickeln und zu testen
Bei der Stelle „aus diesen Daten die Draft-Picks der besten Spieler im Dienst ansehen und die richtige Antwort extrahieren“: Bedeutet das, dass die Draft-Picks aus https://www.17lands.com/leaderboard genommen und nach Siegquote sortiert wurden?
Eigentlich müsste man dafür doch eher Match Wins oder Trophies heranziehen. Sonst misst man nicht die besten Spieler auf dem Dienst, sondern trainiert auf Draft-Entscheidungen, bei denen die meisten Picks sehr gut waren, also auf Spieler, die einfach Glück hatten. Das würde sich dann genauso in Validierung und Test widerspiegeln.
Statt mit einer LLM-Baseline sollte man das meiner Meinung nach mit einer Baseline vergleichen, die aus den 17lands-Daten für jede Karte eine „Elo“-artige Bewertung relativ zu anderen Karten berechnet. Bevor zwei Farben feststehen, empfiehlt man die Karte mit dem höchsten Score; nachdem die Farben feststehen, empfiehlt man die Karte mit dem höchsten Score innerhalb dieser Farben oder unter den Ländern.
Dass das LLM ein gewisses Regelwissen hat, ist denkbar, aber bei unbekannten Karten scheint es eher Signale wie Seltenheit, Kosten oder „Größe“ aufzugreifen. Auch die Draft-„Genauigkeit“ wirkt niedrig, und ich bin nicht sicher, ob das hier wirklich so gemeint ist. Wenn das bedeutet, dass es eine andere Wahl als der Spieler in den Originaldaten getroffen hat, obwohl es sich bei den Entscheidungen mit hoher Siegquote ohnehin meist um insgesamt gute Optionen handelt, dann scheint die Auswahl zwischen guten Optionen eher schwieriger zu sein
Der Grenzwert ist Diamant oder höher. Es werden aber alle Drafts dieser Spieler betrachtet, auch die mit schlechtem Ergebnis.
Genauigkeit bedeutet hier, ob bei einem gegebenen Pack dieselbe Wahl wie ein guter Spieler getroffen wurde. Natürlich ist das subjektiv und kein perfekter Messwert, aber um zu prüfen, wie gut das Modell starke Drafter nachahmt, ist es brauchbar
Ich frage mich, ob statt den Verlust auf den Prompt auf 0 zu setzen in Axolotl auch gewichteter Verlust ausprobiert wurde
Ich meine, in der GPT-3-Dokumentation von Microsoft stand einmal, dass das bei kurzen Antworten hilfreich sein kann, etwa bei „Cut in.“ hier. Auch eine Domänenanpassung über Subreddits oder Foren vor dem Finetuning könnte helfen
Über Domänenanpassung hatte ich auch schon nachgedacht, und ich überlege zusätzlich, Draft-YouTube-Videos zu transkribieren. Ich bin ziemlich gespannt, wie viel das bringen würde
Wenn ich den Beitrag des Autors richtig gelesen habe, dann enthält der Prompt, den der Agent bei jeder Entscheidung bekommt, aus dem bisherigen Kartenpool wohl nur die Kartennamen, während nur für die Karten im übergebenen Pack der vollständige Text enthalten ist
Vermutlich bleibt der Kontext zwischen den Entscheidungen wegen der Größe des Kontextfensters nicht erhalten.
Falls das so ist und falls diese Sets nach dem Trainings-Cutoff des Bots erschienen sind, wäre es dann nicht reiner Zufall, ein guter Drafter zu werden? Der Bot hat buchstäblich keine Möglichkeit zu wissen, wie frühere Picks mit irgendeiner Karte zusammenspielen oder welche Signale bisher gesendet und empfangen wurden. Selbst die besten menschlichen Spieler könnten mit dem Beispiel-Prompt „Gadwick's First Duel -- {1}{U} (uncommon)“ nicht erkennen, womit die Karte gut zusammenspielt, wenn sie sie noch nie gesehen haben.
Am Ende würde er also einfach allgemein gute Draft-Karten nehmen, die sich farblich mit früheren Picks überschneiden, und genau das tun bestehende Heuristiken auf Basis der Pick-Reihenfolge ohnehin schon
Das Modell wird auch mit Daten zur Vervollständigung von Kartenquizzen trainiert, bei denen es den vollständigen Kartentext sowie Informationen wie Typ und CMC vervollständigen muss. Außerdem muss es für die Karten im Pack ebenfalls die nächste Token-Fortsetzung lernen und lernt dadurch beim Erzeugen von Draft-Picks auch, den vollständigen Kartentext vorherzusagen. Insgesamt lernt der Bot den Text neuer Karten ziemlich umfassend
Falls ihr es noch nicht gesehen habt: https://news.ycombinator.com/item?id=38525978 könnte für dieses Publikum auch interessant sein
Das ist der Beitrag „I hacked Magic the Gathering: Arena for a 100% win rate“, und schon allein sehenswert ist, dass der Forscher herausgefunden hat, dass Sparky, die Pseudo-KI von MTGA, offenbar nicht ganz so verblüffend simpel ist, wie man außerhalb des Spiels vermutet hatte
Sie ist eher dafür da, neuen Spielern, die das Spiel und seine Regeln noch nicht kennen, die Erfahrung zu geben, einmal gegen einen dummen Computer zu spielen, oder als Computer-Version davon, beim „Goldfischen“ zu prüfen, wie das eigene Deck zieht und welche Kombos zustande kommen. Sie ist nicht mit einer Schach-CPU vergleichbar
Dass man einen Draft als LLM-Repräsentation darstellen kann, ist sehr interessant
Die leistungsstärksten Draft-AIs, die ich gesehen habe, nutzten in irgendeiner Form Representation Learning. Siehe: https://arxiv.org/pdf/2107.04438.pdf
Falls mit „Representation Learning“ etwas anderes gemeint war, habe ich das vielleicht missverstanden
Trotzdem gibt es an der LLM-Repräsentation interessante Aspekte. Man kann dem Bot zum Beispiel über den System-Prompt Vorlieben oder eine Persönlichkeit geben, was ziemlich unterhaltsam ist
Ich frage mich, ob man ein kleineres Modell verwenden oder bessere Ergebnisse erzielen könnte, wenn man jede Karte als ein Token behandelt, den Draft-Zustand als Eingabe gibt und das vorhergesagte Token die zu wählende Karte sein lässt
Man müsste dafür wohl mit einem benutzerdefinierten Tokenizer von Grund auf trainieren
<|post_author|>username<|post_title|>title here...Das resultierende Modell war deutlich schlechter, als wenn alles als normaler Text formatiert wurde. Es war MPT-30B, 15 spezielle Tokens, 300 Millionen Trainingstokens und vollständiges Fine-Tuning.
Vielleicht habe ich einen Fehler gemacht, aber ich habe im Open-Source-Fine-Tuning auch noch keinen Fall gesehen, in dem erfolgreich viele Tokens hinzugefügt wurden
Bei „noch nie gesehenen Karten“ würde das nicht funktionieren, und wenn es falsch liegt, würde es vermutlich völlig unsinnige Picks machen, aber bis auf 90 % Genauigkeit könnte es kommen
Ein Vergleich mit dem Training eines neuronalen Netzwerks für Drafts ohne einen Mistral-Startpunkt wäre interessant. Ich würde das gern sowohl nach Epochen als auch nach Kosten sehen
Warum der LLM-Anteil überhaupt relevant ist, ist nicht ganz klar. Vielleicht gab es im Internet genug Decklisten oder Mock-Drafts, die Einfluss hatten, oder vielleicht ist die Infrastruktur rund um LLM-Fine-Tuning einfach besser als die für „ein neuronales Netz bauen“. Vielleicht braucht es so etwas wie nnfiddle, das das einfach macht
Fine-Tuning ist relativ günstig, und man kann es dazu bringen, solche Aufgaben ziemlich ordentlich zu erledigen, indem man ihm einfach Daten zuführt. Die Erstellung des Basis-Checkpoints kostet viel Rechenleistung, aber dort steckt bereits der Großteil des „Wissens“.
Wenn man ein neuronales Netz von Grund auf baut, muss man erst einmal klären, wie die Karten auf die Eingabe abgebildet werden. Ich kenne mich mit MTG nicht besonders gut aus, aber die meisten Trading-Card-Games haben Textbeschreibungen und komplexe Effekte. Text in Logik zu überführen ist etwas, worin LLMs wirklich stark sind, und ohne sie startet man sonst bei null und braucht vermutlich relativ viel Rechenleistung, bevor überhaupt brauchbares Verhalten entsteht.
Für die meisten Softwareentwickler ist dieser Weg auch einfacher. Fine-Tuning bedeutet meist einfach, Text zu sammeln und in ein Fine-Tuning-Skript zu stecken. Man muss dafür weder lineare Algebra verstehen noch wissen, was „Faltungen“ sind
Ich nehme an, mit „ein neuronales Netz für Drafts ohne Mistral trainieren“ ist gemeint, dass die Eingabeschicht aus Bitmap-Vektoren der Karten im Pack besteht. Die Kernfunktion dieses Experiments ist, dass das Modell allein anhand des Kartentexts auch auf Sets funktioniert, die es noch nie gesehen hat und für die es null Trainingsdaten gibt. Ohne ein LLM dürfte das schwer sein
Dieser Beitrag war wirklich großartig. Tatsächlich habe ich mich diese Woche gerade mit LLM-Fine-Tuning für Magic: The Gathering beschäftigt
Ich baue einen kleinen Kartenähnlichkeits-Browser, der über semantische Embeddings von Karten funktional oder atmosphärisch ähnliche Karten findet.
Im Moment verwende ich nur InstructorXL, aber ich weiß nicht, ob Instructor zu wenig angeborenes Wissen über das Spiel hat oder ob ich einfach bessere Prompts schreiben muss. Ich habe bisher 9 Prompts ausprobiert, aber die Qualität der Embedding-Erzeugung sah nicht besonders gut aus: https://github.com/HanClinto/MtgMatrix/blob/main/data/create...
Der nächste Schritt wäre gewesen, einen Datensatz mit ähnlichen Karten herunterzuladen und zu schauen, ob man damit bei einem großen Embedding-Modell etwas wie Triplet-Loss-Training machen kann. Ich habe allerdings noch nicht herausgefunden, wie ich das konkret zusammenstecken soll, aber dieser Beitrag ist unglaublich inspirierend