Experimento de fine-tuning de Mistral 7B con draft de Magic: The Gathering
(substack.com/generallyintelligent)- Se usó la selección de cartas en draft de Magic: The Gathering como tarea para medir cuánto puede mejorar el fine-tuning el rendimiento de razonamiento en un entorno de cartas reciente que podría no estar en el corpus de entrenamiento del LLM
- Los registros de draft de 17lands se convirtieron en prompts, y las elecciones de jugadores con alta tasa de victorias se usaron como señal de respuesta correcta para que el modelo eligiera cartas viendo el paquete actual y el pool de cartas previo
- El modelo de 7B parámetros ajustado superó con claridad a GPT-4 en esta tarea, mostró un rendimiento cercano al de humanos o al del experimentador, y aunque un GPT-3.5 fine-tuned podría ser mejor, su costo sería mucho mayor
- El formato de datos y la estructura del prompt fueron difíciles de validar rápido por los largos ciclos de entrenamiento, y aun tras unas 40 horas de experimentos no había certeza sobre cuál era el formato de prompt óptimo
- En la práctica, conviene crear primero un set de evaluación y usar herramientas como axolotl en lugar de escribir scripts de entrenamiento desde cero; además, incluso un LLM OSS pequeño exige bastante memoria de GPU y espacio de almacenamiento
Tarea experimental: draft de Magic
- El experimento usó el draft de Magic: The Gathering para ver hasta qué punto un LLM puede razonar con datos fuera de distribución
- Magic: The Gathering es un juego de cartas coleccionables estratégico en el que se compite con criaturas y hechizos, y el draft consiste en ir eligiendo cartas por turnos de paquetes aleatorios para construir un mazo
- El draft encajaba bien con el experimento por dos razones
- Razonamiento: para elegir bien hay que entender en conjunto las cartas ya seleccionadas y las cartas del paquete actual
- Datos fuera de distribución: las nuevas cartas de Magic se lanzan de 4 a 6 veces al año, y las más recientes pueden no estar en el corpus de entrenamiento del LLM
- Los datos se tomaron de los registros de seguimiento de draft de 17lands
- 17lands es un servicio que rastrea datos de draft del cliente digital de Magic
- Al observar las elecciones de los jugadores con mejor tasa de victorias, se puede construir una señal cercana a la “respuesta correcta”
- Incluso entre jugadores de Magic hay mucho debate sobre cuál es la elección correcta, así que esta señal no es totalmente clara, pero basta para probar si el modelo aprende una tarea nueva
Construcción del dataset y formato del prompt
- Los datos de draft de 17lands son un gran archivo CSV con información aproximada como la siguiente
- Cartas disponibles para elegir en el paquete actual
- Cartas que el jugador ya había elegido hasta ese momento
- Carta realmente elegida en ese paquete
- Para adaptar estos datos al fine-tuning de un modelo de lenguaje, se transformaron a un formato de conversación en texto
- El mensaje system define al modelo como “DraftGPT” y le indica que, cuando se le pida un pick de draft, responda primero con el nombre de la carta
- El mensaje user incluye el número de paquete y el número de pick actuales, el pool de cartas hasta ese momento, el conteo por color de las cartas vistas en los últimos 5 paquetes y la descripción de las cartas del paquete actual
- El mensaje assistant imprime solo el nombre de la carta elegida
- Se ofrecen ejemplos de esta transformación en ejemplo de conversión de datos de 17lands a prompts para LLM y en prompt de draft completo en formato ChatML
- La parte más difícil fue formatear los datos para obtener el resultado deseado
- En fine-tuning, probar cambios en el prompt normalmente requiere lanzar entrenamientos que duran varias horas
- Por eso, el ciclo experimental se sintió 100 veces más lento que en la ingeniería de prompts habitual
- Entre las variantes probadas estuvieron unos 5 formatos de prompt, la cantidad de detalle por carta, añadir contexto de los picks recientes e incluir líneas de entrenamiento de “conocimiento de cartas” para que el modelo memorizara información sobre cartas nuevas
- Incluso después de unas 40 horas de experimentos, no se pudo determinar con certeza cuál era el mejor formato de prompt para esta tarea
Entorno de ejecución del fine-tuning
- La GPU se alquiló por horas en Runpod
- La GPU usada fue una RTX 4090 con 24 GB de VRAM
- El costo fue de aproximadamente $0.7/hora
- Al principio se intentó escribir directamente un script de entrenamiento con HuggingFace transformers y PEFT, y por las limitaciones de GPU se eligió QLoRA
- El enfoque de escribir el script manualmente implicó mucho ensayo y error
- Desde optimizaciones sencillas si sabes que existen, como FlashAttention, hasta opciones difíciles de entender sin leer papers, como los parámetros de LoRA
- Se podía resolver todo uno por uno, pero entenderlo directamente tomaba mucho tiempo
- Al final se usó axolotl
- Ya implementa varias optimizaciones por defecto, así que era más fácil ponerlo a correr
- La documentación era decente y se consideró un buen punto de partida para la mayoría de quienes empiezan con fine-tuning de LLM
Tamaño del modelo y costo
- Incluso un LLM OSS “pequeño” es enorme comparado con los estándares de antes
- BERT, que se entrenaba con frecuencia alrededor de 2019, tenía unos 110 millones de parámetros
- Un modelo de 7B es unas 70 veces más grande que eso
- Un modelo de 7B también es pesado en términos operativos
- Los pesos ocupan unos 16 GB, así que el almacenamiento se vuelve un problema
- Incluso usando métodos como QLoRA, la memoria de GPU sigue siendo complicada
- El fine-tuning de GPT-3.5 parecía tener potencial para dar mejores resultados, pero era costoso
- Aproximadamente 100 veces más caro que afinar Mistral en bare metal
- La inferencia también tiene precio premium
- Se estimó que un fine-tuning de GPT-3.5 comparable a la mayor corrida de entrenamiento de Mistral-7B habría costado alrededor de $500
Método de evaluación y resultados
- Antes del experimento, era importante construir primero un buen set de evaluación
- En esta tarea, se dejaron fuera drafts completos del dataset de entrenamiento y luego se verificó si el modelo elegía las mismas cartas que un humano
- Tener ese set de evaluación facilitó juzgar los resultados del fine-tuning
- La exactitud en la selección de cartas era relativamente fácil de definir, pero los siguientes criterios eran más ambiguos
- Que, cuando el modelo hiciera una elección distinta, esa elección pudiera justificarse
- Que pudiera explicar de forma razonable por qué eligió esa carta
- Estos criterios ambiguos se revisaron con evaluación visual mirando ejemplos manualmente, y ese proceso fue lento
- GPT-4 hacía elecciones menos extrañas que el modelo pequeño fine-tuned y era mejor justificando sus picks
- El modelo de 7B fine-tuned superó con facilidad a GPT-4 con aprendizaje en contexto en esta tarea de selección de cartas, tanto en exactitud como en costo
- En un experimento, el modelo se ajustó con un set de cartas y luego se evaluó en otro set de cartas que no había visto
- Parecía que el modelo no solo había memorizado cartas fuertes, sino que había generalizado en cierta medida el concepto de draft
Magic Copilot y bots de draft
- El modelo fine-tuned para picks de draft se conectó a los logs de Magic Arena y, con una app rápida en Electron, se creó “Magic Copilot”, que se usó en varios drafts
- La selección de cartas la generaba el modelo fine-tuned y la explicación la daba GPT-4
- En general funcionó bien, aunque a veces GPT-4 no estaba de acuerdo con la elección del modelo fine-tuned y la refutaba de inmediato
- También se conectaron 8 IA de draft para correr drafts simulados entre bots
- Cuando solo los bots se pasaban cartas entre sí, tendían con fuerza a elegir mazos monocolor
- Cuando se mezclaban elecciones humanas distintas, tendían a converger hacia mazos mucho más normales
- En conjunto, esta IA de draft parecía acercarse más a una IA de draft más potente y más humana que las existentes actualmente
- Comparada con los bots de quick draft de Magic Arena, hacía elecciones más cercanas a las de drafters humanos de alta calidad que a las de bots heurísticos
1 comentarios
Opiniones de Hacker News
Me gustó que este artículo muestra muy bien lo difícil que es implementar con fine-tuning de LLM incluso una idea que conceptualmente parece simple.
Parece que fue una tarea nada fácil, aun teniendo un dataset inicial bastante bueno y un modelo de partida. Este tipo de modelo parece adecuado para tareas naturales y sin una respuesta definitiva correcta. Por ejemplo, elegir la carta perfecta de una lista dada de opciones sería difícil de resolver de forma combinatoria, pero elegir una buena carta sí es posible, y un LLM puede acercarse al rendimiento humano. Creo que aquí se ve el conjunto de problemas que actualmente se pueden resolver haciendo fine-tuning de LLM.
Por ejemplo, este mes me está ayudando a buscar regalos para amigos y niños. Para resolver el problema no necesito la mejor opción; con una buena opción alcanza.
Quizá no sea el cambio más revolucionario para la vida cotidiana, pero tengo muchas ganas de ver partidas contra bots con estilos de juego interesantes en juegos como Magic: The Gathering.
Parece un caso claro en el que se podría mejorar mucho la capacidad del equipo de investigación y desarrollo para crear y probar nuevas mecánicas en distintos niveles de juego.
En la parte que dice “con esos datos, se miran las elecciones de draft hechas por los mejores jugadores del servicio y se extrae la respuesta correcta”, ¿significa que miraron las elecciones de draft de https://www.17lands.com/leaderboard y las ordenaron por tasa de victorias?
Me parece que originalmente habría que elegir Match Wins o Trophies. Si no, no estás midiendo a los mejores jugadores del servicio, sino aprendiendo de elecciones de draft en las que la mayoría de las decisiones fueron muy buenas, es decir, de jugadores que tuvieron suerte. Ese efecto también aparecería igual en la validación o las pruebas.
Creo que habría que compararlo no con una línea base de LLM, sino con una línea base calculada a partir de los datos de 17lands, asignando a cada carta una puntuación tipo “Elo” frente a otras cartas. Antes de fijar los dos colores, recomendaría la carta con mayor puntuación; después de fijar los colores, recomendaría la carta con mayor puntuación dentro de esos colores o entre las tierras.
Es posible que el LLM tenga cierto conocimiento de las reglas, pero con cartas que nunca vio parece captar más señales como rareza de la carta, coste o “tamaño”. La “exactitud” del draft también parece baja, y no tengo claro si significa lo que creo que significa. En situaciones donde todas las opciones son en general buenas, como las elecciones con alta tasa de victorias, si significa que eligió algo distinto del jugador de los datos originales, entonces elegir entre buenas opciones parece todavía más difícil.
El criterio es Diamante o superior. Eso sí, de esos jugadores se miran todos sus drafts, incluso los que tuvieron malos resultados.
Aquí, exactitud significa si hizo la misma elección que uno de los buenos jugadores en un paquete dado. Obviamente es subjetivo y no es una métrica perfecta, pero sirve para comprobar la capacidad de imitar a drafters de alto nivel.
Me pregunto si, en vez de hacer que la pérdida del prompt sea 0, también probaron pérdida ponderada en Axolotl.
En algún momento, creo que la documentación de GPT-3 de Microsoft decía que este método era ventajoso cuando la respuesta era corta, como el “Cut in.” de aquí. También podría ayudar hacer adaptación de dominio con subreddits o foros antes del fine-tuning.
También estaba pensando en adaptación de dominio, y estoy considerando además transcribir videos de draft de YouTube. Me da bastante curiosidad cuánto podría ayudar.
Si leí bien el artículo del autor, en cada momento de elección el prompt que se le da al agente incluye, del pool de cartas acumulado hasta entonces, solo los nombres de las cartas, y solo las cartas del paquete recibido incluyen el texto completo.
Probablemente no se mantiene el contexto entre elecciones por el tamaño de la ventana de contexto.
Si es así, y si es correcta la suposición de que estos sets son posteriores al corte de entrenamiento del bot, ¿no sería pura casualidad que se convierta en un buen drafter? El bot literalmente no tiene forma de saber qué cartas combinan bien con las elecciones anteriores, qué señales ha enviado y recibido hasta ahora, etc. Ni siquiera el mejor jugador humano puede ver solo “Gadwick's First Duel -- {1}{U} (uncommon)” en el prompt de ejemplo y saber con qué combina si nunca vio esa carta.
Al final elegirá cartas de draft generalmente buenas que compartan color con las elecciones anteriores, que es lo que las heurísticas existentes basadas en orden de picks siempre han hecho.
El modelo también se entrena con datos de completar quizzes de cartas, donde debe completar el texto completo de la carta y datos como el tipo y el CMC. Además, para las cartas dentro de un paquete también tiene que aprender a completar el siguiente token, así que mientras genera picks de draft también aprende a predecir el texto completo de las cartas. En conjunto, el bot aprende de forma bastante amplia el texto de las cartas nuevas.
Si no lo vieron, https://news.ycombinator.com/item?id=38525978 también podría interesarle a este público.
Es el artículo “I hacked Magic the Gathering: Arena for a 100% win rate”, y vale la pena aunque sea porque el investigador descubrió que Sparky, la pseudo IA de MTGA, no parece ser tan estúpidamente compleja como se sospechaba desde afuera.
Está más cerca de darles a los jugadores nuevos que recién conocen el juego y ni siquiera saben las reglas la experiencia de jugar contra una computadora tonta, o de una versión con computadora de “jugar contra un goldfish” para ver cómo roba y combea un mazo que armaste. No es algo como una CPU de ajedrez.
Es muy interesante que el draft pueda representarse con un LLM.
Las IA de draft con mejor rendimiento que he visto usaban aprendizaje de representaciones de alguna forma. Referencia: https://arxiv.org/pdf/2107.04438.pdf
Si con “aprendizaje de representaciones” querían decir otra cosa, puede que lo haya entendido mal.
Aun así, la representación con LLM tiene aspectos divertidos. Por ejemplo, mediante el prompt de sistema se le pueden dar preferencias o personalidad al bot, lo cual resulta bastante entretenido.
Me pregunto si se podría usar un modelo más pequeño u obtener mejores resultados tratando cada carta como un token, dando el estado del draft como entrada y haciendo que el token predicho sea la carta a elegir.
Habría que entrenar desde cero con un tokenizador personalizado.
<|post_author|>username<|post_title|>title here....El modelo resultante fue mucho peor que cuando todo se formateaba como texto normal. Fue con MPT-30B, 15 tokens especiales, 300 millones de tokens de entrenamiento y fine-tuning completo.
Puede que yo haya cometido algún error, pero todavía no he visto casos de fine-tuning open source que agreguen exitosamente una gran cantidad de tokens.
No funcionaría con “cartas que nunca ha visto” y, cuando se equivoque, probablemente haga elecciones absurdas, pero creo que podría llegar a un 90% de precisión.
Sería interesante compararlo con entrenar una red neuronal para drafts sin partir de Mistral. Me gustaría verlo tanto en términos de épocas como de costo.
No queda claro por qué el componente LLM es relevante. Podría ser que en internet haya suficientes listas de mazos o drafts simulados como para influir, o quizá que la infraestructura para “fine-tuning de LLM” esté más desarrollada que la de “crear una red neuronal”. Tal vez haga falta algo como nnfiddle que facilite esto.
El fine-tuning es relativamente barato, y con solo meterle datos se puede lograr que haga este tipo de tareas bastante bien. Crear el checkpoint base requiere mucho cómputo, pero ahí dentro está la mayor parte del “conocimiento”.
Si creas una red neuronal desde cero, primero tienes que resolver cómo mapear las cartas a entradas. No sé mucho de MTG, pero la mayoría de los juegos de cartas coleccionables tienen descripciones de texto y efectos complejos. Mapear texto a lógica es algo que los LLM hacen realmente bien; si no, empiezas desde cero y además necesitas bastante cómputo hasta que aparezca un comportamiento aceptable.
Para la mayoría de los desarrolladores de software, este camino también es más fácil. El fine-tuning en general consiste en juntar texto y pasarlo a un script de fine-tuning. Puedes hacerlo sin saber álgebra lineal ni qué es una “convolución”.
Supongo que “entrenar una red neuronal para drafts sin Mistral” significa usar como capa de entrada un vector bitmap de las cartas del paquete. La funcionalidad clave de este experimento es que el modelo funciona solo con el texto de las cartas incluso en sets que nunca ha visto y para los que tiene 0 datos de entrenamiento. Sin un LLM, creo que eso sería difícil.
Me gustó mucho este artículo. De hecho, esta semana estaba investigando fine-tuning de LLM para Magic: The Gathering.
Estoy creando un pequeño navegador de similitud de cartas que usa embeddings semánticos para encontrar cartas parecidas tanto funcionalmente como en estilo.
Por ahora solo estoy usando InstructorXL, pero no sé si a Instructor le falta conocimiento innato del juego o si necesito mejorar los prompts. Hasta ahora probé 9 prompts, pero el rendimiento al generar embeddings no parece muy bueno: https://github.com/HanClinto/MtgMatrix/blob/main/data/create...
El siguiente paso era descargar un dataset de cartas similares, para ver si con eso podía hacer algo como entrenamiento con pérdida tripleta sobre un modelo de embeddings grande. Todavía no he descubierto cómo conectarlo en la práctica, pero este artículo me inspira mucho.