Mi modelo fine-tuned supera a OpenAI GPT-4

• En 724 pruebas de extracción de datos estructurados realizadas sobre comunicados de prensa de ISAF, varios modelos fine-tuned lograron mayor precisión que la familia GPT-4
• La comparación incluyó GPT-4o, GPT-4 Turbo, GPT-3.5 Turbo y modelos fine-tuned basados en TinyLlama, Mistral, Llama3, Solar y GPT-3.5
• Los modelos de OpenAI siempre generaron JSON válido, y los fine-tuned de Mistral y Llama3 también fueron estables, pero TinyLlama mostró grandes diferencias en valores faltantes y calidad del JSON según la plantilla
• En el resultado final agregado, Mistral-7B fine-tuned con OpenPipe quedó en primer lugar, seguido muy de cerca por Solar LLM y Llama3-7B
• El fine-tuning puede mejorar privacidad, control y costos, pero también incrementa la complejidad de MLOps para gestionar inferencia, evaluación y reproducibilidad de modelos dispersos en varios entornos

---

Objetivo del experimento y dataset

• El objetivo fue evaluar la precisión de LLM fine-tuned en una tarea de extracción de información de eventos a partir de comunicados de prensa de ISAF
• Los datos están en un repositorio público de Hugging Face Hub, y la evaluación se hizo con el test split que los modelos no habían visto
  • Los datos de prueba están compuestos por 724 filas
  • Los campos incluyen name, eventrefnumber, text, StartDate, eventtype, province, targetgroup, minkilled, mincaptured, killq, captureq, killcaptureraid, airstrike, noshotsfired, minleaderskilled, minleaderscaptured, entre otros
• Cada fila se convirtió en un objeto de Pydantic para facilitar la validación y el procesamiento
• Se esperaba que la salida del modelo siguiera la siguiente estructura JSON
  • name
  • start_date
  • event_type
  • province
  • target_group
  • min_killed
  • min_captured
  • killq
  • captureq
  • killcaptureraid
  • airstrike
  • noshotsfired
  • min_leaders_killed
  • min_leaders_captured

Método de evaluación de los modelos base de OpenAI

• Se usaron GPT-4o, GPT-4 Turbo y GPT-3.5 Turbo como modelos base de referencia
• Los modelos GPT no podían usar exactamente el mismo prompt que los modelos fine-tuned, así que necesitaron un prompt más largo
  • Se especificó la lista de campos a extraer
  • Se proporcionaron los valores permitidos para tipo de evento, provincia y grupo objetivo
  • Se incluyeron reglas de anotación numérica
  • Se agregó un ejemplo de comunicado y la salida JSON esperada
• Las reglas de anotación numérica usaron los siguientes criterios
  • a couple se interpreta como 2
  • several se interpreta como mínimo 3
  • a few, some, a group, a small group, multiple se interpretan como mínimo 3
  • numerous, a handful se interpretan como mínimo 4
  • a large number se interpreta como mínimo 5
  • facilitator no es un leader
• Las predicciones a gran escala se ejecutaron de forma asíncrona, y por el rate limit de GPT-3.5 Turbo se agregó lógica de reintento
• Los resultados de predicción se guardaron por nombre de modelo en el campo predictions de cada evento

Configuración de los modelos fine-tuned

• Después de obtener las predicciones de los modelos base de OpenAI, se añadieron al mismo dataset las predicciones de modelos locales previamente fine-tuned y de modelos basados en servicios de fine-tuning con un clic
• Los modelos fine-tuned incluidos fueron los siguientes
  • tinyllama-templatefree
  • tinyllama-sharegpt
  • mistral-lora-templatefree
  • finetuned-openai-gpt-3.5-turbo-1106
  • finetuned-mistral-7b-optimised-openpipe
  • ft-solar-1-mini-chat-240612-predibase
  • finetuned-llama3-7b-32k-openpipe
• El modelo local fine-tuned de Mistral no podía ejecutarse fácilmente en local, así que la inferencia se hizo en un entorno A100 de Modal
  • Después, en la evaluación, falló en casi todos los ítems
  • En los gráficos aparece como mistral-lora-templatefree
• Se hizo fine-tuning del modelo gpt-3.5-turbo-1106 con el servicio de fine-tuning con un clic de OpenAI
• Con OpenPipe se generaron predicciones para Mistral 7B, Mistral 8x7B y modelos Llama3
• En Predibase se evaluó un modelo basado en Solar LLM de Upstage
  • Solar LLM se presenta como un modelo entrenado para rendir bien en tareas donde el fine-tuning se usa con frecuencia, como la extracción de datos estructurados
  • Se estima que el modelo base es upstage/SOLAR-10.7B-v1.0 de Hugging Face Hub
• La inferencia de Qwen2 en Predibase no funcionó, así que quedó fuera de esta evaluación
• El dataset final de predicciones se publicó en un dataset público de Hugging Face Hub

Validez del JSON y valores faltantes

• La primera evaluación consistió en verificar si la salida de cada modelo era JSON válido
• Los modelos de OpenAI generaron JSON válido en todos los casos
• Los modelos fine-tuned de Mistral y Llama3 también produjeron JSON válido de forma estable
• TinyLlama mostró grandes diferencias según la plantilla elegida
  • tinyllama-sharegpt tiene 38 valores faltantes
  • Se considera que, de no haber tenido esos valores faltantes, habría logrado 724 predicciones y JSON válido en todos los casos
• El conteo de valores faltantes fue el siguiente
  • gpt-4o: 0
  • gpt-4-turbo: 0
  • gpt-3.5-turbo: 0
  • tinyllama-templatefree: 0
  • tinyllama-sharegpt: 38
  • finetuned-openai-gpt-3.5-turbo-1106: 0
  • finetuned-llama3-7b-32k-openpipe: 0
  • mistral-lora-templatefree: 0
  • finetuned-mistral-7b-optimised-openpipe: 0
  • ft-solar-1-mini-chat-240612-predibase: 0

Precisión por campo

• La evaluación de precisión se hizo sobre un total de 13 atributos
  • start_date
  • province
  • target_group
  • event_type
  • min_killed
  • min_captured
  • killq
  • captureq
  • killcaptureraid
  • airstrike
  • noshotsfired
  • min_leaders_killed
  • min_leaders_captured
• El total de tareas en todos los gráficos es 724

• start_date

  • En precisión de start_date, Solar y el modelo GPT-3.5 fine-tuned tuvieron el mejor desempeño
  • Las puntuaciones fueron las siguientes
    • gpt-4o: 527
    • gpt-4-turbo: 522
    • gpt-3.5-turbo: 492
    • tinyllama-templatefree: 231
    • tinyllama-sharegpt: 479
    • finetuned-openai-gpt-3.5-turbo-1106: 646
    • finetuned-llama3-7b-32k-openpipe: 585
    • mistral-lora-templatefree: 0
    • finetuned-mistral-7b-optimised-openpipe: 636
    • ft-solar-1-mini-chat-240612-predibase: 649
  • Incluso el mejor modelo se equivocó en 75 fechas, así que la extracción de fechas todavía tiene margen de mejora

• province

  • En la predicción de provincia, los modelos fine-tuned superaron a los modelos de OpenAI
  • Las puntuaciones fueron las siguientes
    • gpt-4o: 649
    • gpt-4-turbo: 645
    • gpt-3.5-turbo: 595
    • tinyllama-templatefree: 335
    • tinyllama-sharegpt: 660
    • finetuned-openai-gpt-3.5-turbo-1106: 704
    • finetuned-llama3-7b-32k-openpipe: 707
    • mistral-lora-templatefree: 0
    • finetuned-mistral-7b-optimised-openpipe: 711
    • ft-solar-1-mini-chat-240612-predibase: 704

• target_group y event_type

  • target_group puede incluir varios grupos, así que la puntuación se calculó según la proporción de grupos correctos que el modelo acertó
  • Los modelos fine-tuned mostraron un desempeño significativamente mejor que los modelos de OpenAI en la identificación de grupos objetivo
  • Aun así, el rendimiento podría caer si se agregan nuevos grupos que no estaban en los datos de entrenamiento
  • event_type tiene categorías con solapamiento semántico, por lo que se considera un ítem difícil incluso para anotadores humanos
  • Incluso en este ítem difícil, los modelos fine-tuned lograron buen desempeño

• Campos numéricos y booleanos

  • En estimaciones numéricas como min_killed, la diferencia entre modelos fine-tuned y modelos de OpenAI se redujo
  • Mistral obtuvo el mejor resultado, pero la diferencia no fue grande, y los modelos de OpenAI también rindieron bien en este ítem
  • Es posible que las reglas de anotación numérica incluidas en el prompt largo hayan ayudado
  • En atributos booleanos como killq, la mayoría de los modelos registró alta precisión
  • El Mistral fine-tuned también superó la mejor puntuación de GPT-4o en este ítem
  • killcaptureraid apareció como un ítem desfavorable para los modelos de OpenAI
    • kill-capture raid era un término especializado usado de una manera específica en el etiquetado
    • Los modelos de OpenAI no conocían el criterio usado para esa decisión de etiquetado
  • noshotsfired es un campo surgido de comunicados de cierto periodo que enfatizaban el hecho de que “no hubo disparos”
  • Los modelos de OpenAI mostraron un rendimiento en el orden inverso al esperado, y se necesita investigación adicional para entender la causa
  • En min_leaders_killed y min_leaders_captured se obtuvieron puntuaciones altas en general
  • A diferencia de la percepción común de que los LLM son débiles con números, en esta tarea mostraron alto rendimiento, y aun así los modelos fine-tuned obtuvieron los mejores resultados

Resultado final agregado

• Después de sumar las 13 puntuaciones de precisión individuales y sacar el promedio, se calculó una precisión agregada final en escala de 0 a 100
• En el resultado final, los modelos fine-tuned superaron a la familia OpenAI GPT
• Incluso TinyLlama mostró una precisión agregada mayor que GPT-3.5 Turbo
• El modelo con mejor desempeño fue Mistral-7B fine-tuned en OpenPipe
• Solar LLM y Llama3-7B quedaron muy, muy cerca de Mistral-7B
• Para fine-tuning de extracción de datos estructurados, parece razonable empezar con Mistral-7B, Solar 7B y Llama3-7B, y comparar cuál se ajusta mejor
• Viendo solo la precisión, los tres modelos pueden ser casi equivalentes
• Puede haber trade-offs aparte en serving del modelo, eficiencia y latencia

Ventajas y costos del fine-tuning

• Los modelos de OpenAI también pueden mejorar su rendimiento si se añaden más ejemplos y reglas al prompt
• Pero cuando el prompt se hace más largo, el costo por solicitud aumenta
• Un modelo propio fine-tuned ofrece las siguientes ventajas
  • Privacidad de datos, ya que no hace falta enviar información confidencial a OpenAI
  • Posible mejora de rendimiento gracias a modelos más pequeños
  • Más control
  • Posible mejora de costos
• La comparación de costos todavía es difícil de cerrar con claridad
  • Los grandes proveedores cloud pueden aprovechar economías de escala
  • En casos de uso reales con inferencia repetida a largo plazo, la lógica de costos de modelos propios puede resultar más convincente
  • Para mejorar llamadas a OpenAI puede hacer falta incluir muchos ejemplos y explicaciones, lo que puede elevar el costo por consulta

Operación de la evaluación y complejidad de MLOps

• El fine-tuning logró un desempeño mejor que GPT-4 con relativamente pocos ajustes
  • Los modelos usados fueron los primeros modelos fine-tuned construidos con los datos recopilados
  • En su mayoría se usaron valores por defecto
• A futuro, el plan es enfocarse en los modelos Solar, Llama3 y Mistral 7B
• La evaluación se implementó principalmente alrededor de notebooks de Jupyter, y la operación fue engorrosa
  • Algunos modelos corren en local
  • Otros están desplegados en distintos servicios y entornos
  • Recorrer las 724 filas fue lento
• En la siguiente iteración, hace falta poder ejecutar la evaluación en local y evaluar primero solo un slice parcial de los datos antes de ampliar al dataset completo
• Al trabajar con varios modelos en un mismo proyecto, hace falta una interfaz de inferencia estándar
• Cuando los modelos están repartidos en múltiples ubicaciones, el fine-tuning y las actualizaciones se repiten, y los datos siguen cambiando, hace falta un sistema para gestionarlo todo
• El principal trade-off de los LLM fine-tuned es que, para una operación estable y repetible, hay que administrar muchos componentes

El valor que dejó la evaluación y los siguientes pasos

• Aunque implementar la evaluación fue engorroso, proporciona un criterio específico de la tarea para comprobar si mejorar los datos de entrenamiento o el modelo realmente produce progreso
• Sin evaluación, es difícil juzgar si hubo mejora
• La idea de crear varios modelos ultrasespecializados por separado no es el siguiente paso más claro por ahora
  • Por ejemplo: un modelo aparte que solo sea bueno para estimar personas capturadas
  • Viendo el rendimiento actual, no está claro que ese enfoque vaya a elevar mucho la precisión
• El siguiente paso prioritario es ejecutar evaluaciones más allá de la precisión
  • Un ejemplo es la evaluación con datos out-of-domain mencionada en un texto anterior
  • Se quiere comprobar el comportamiento ante datos falsos de temas completamente distintos
• Otro siguiente paso es analizar más a fondo el LLM serving de los 3 modelos principales
  • El serving de LLM tiene herramientas, trade-offs y técnicas distintas al serving de modelos no LLM
• Si se profundiza más en el problema, puede ser útil subir los casos erróneos a una interfaz web como Lilac o Argilla para analizar patrones de fallo
• Entender los escenarios de error podría ayudar más a mejorar la precisión que ajustar parámetros de fine-tuning

[GN⁺]

Opiniones de Hacker News

• Como fundador de OpenPipe, no me sorprende que haya dado buenos resultados, porque la extracción de datos es un caso de uso en el que los modelos con fine-tuning se destacan especialmente.
  Si puedes crear buenos datos de entrenamiento, también es bastante fácil superar a GPT-4 en varios tipos de tareas; en un estudio que publicamos hace una semana, un Llama 3 8B con fine-tuning superó a GPT-4 en 3 de 4 tareas de ejemplo: resumen creativo, preguntas y respuestas, extracción de datos y clasificación.
  La clave fue crear una forma de generar datos de entrenamiento de alta calidad de manera iterativa, y el artículo también trata ese punto: https://openpipe.ai/blog/mixture-of-agents

  • Me pregunto si un entusiasta técnico que no sea experto puede hacer fine-tuning y ejecutarlo fácilmente.
    El caso de uso sería entrenarlo con documentación técnica, noticias específicas, dos años de entradas de blog, fuentes primarias e hilos explicativos de Twitter para crear un LLM experto en un tema que reúna información de nicho sobre un tema de los últimos dos años.
  • Me pregunto si, creando con un LLM un metamodelo que elija uno entre varios modelos con fine-tuning según la pregunta, se podrían obtener resultados globalmente mejores que GPT-4.
  • Me pregunto si entrenar un modelo nuevo con respuestas de modelos de los principales proveedores de LLM (OpenAI, Anthropic, etc.) viola sus términos de uso.

• Este resultado no sorprende en absoluto y coincide con resultados previos que muestran que, en extracción de información y clasificación de texto, incluso los modelos pequeños especializados rinden mejor.
  Durante mi doctorado trabajé en extracción fina de eventos y sentimientos al estilo ACE, y transformers especializados “pequeños” con fine-tuning superaban al prompting de LLM como BERT o Roberta-large.
  Sería bueno incluir también puntajes de modelos pequeños junto con los pipelines modernos; aunque sea una reproducción de resultados conocidos, es un buen trabajo.

  • Hay una salvedad: si no sabes cómo crear un buen modelo especializado, solo terminarás haciendo que todos pierdan tiempo y dinero: https://www.threads.net/@ethan_mollick/post/C46AfItO8RS?hl=e...
  • El tema de la tesis suena interesante; me pregunto si tienes algún enlace.

• El único uso serio de LLM que me resultó útil en trabajo real fue la extracción/estructuración de datos.
  Tenía que extraer el inicio, el fin y la descripción de eventos desde informes de muestreo de experiencias que no podía compartir en línea, y ejecuté el modelo con llama.cpp para convertirlos en un CSV de cuatro columnas: onset, offset, description y si cumplía ciertas condiciones.
  Con solo poner en el prompt algunos ejemplos de la estructura deseada, varios modelos lo resolvieron bien, y me gustó Mixtral 8x7b, que fue el más rápido en mi laptop dentro del mismo rango de calidad.
  Es muy probable que para esta tarea un modelo más pequeño con fine-tuning sea mejor y más rápido; además, cuando no se pueden enviar los datos a lugares como OpenAI, se necesita procesamiento offline, así que los modelos pequeños, ejecutables localmente y aptos para fine-tuning pueden brillar.

  • Me di cuenta de esto temprano al experimentar con GPT-3 para extracción de datos web, y después de publicar el primer prototipo en Reddit y HN vi mucha demanda de automatización para stacks de web scraping basados en reglas.
    Eso derivó en la startup https://kadoa.com, que automatiza este problema “aburrido y difícil”, con mucho mantenimiento y difícil de escalar.
    Donde la IA agrega más valor es en estos usos relativamente menos vistosos, y más que eliminar empleos automatizará tareas repetitivas como web scraping, llenado de formularios e ingreso de datos.
  • Como siguiente paso, quisiera trabajar en despliegue/inferencia y ver qué tan pequeños pueden hacerse los modelos.
    Spacy lleva mucho tiempo impulsando este enfoque con modelos de decenas de MB, y me alegra que ahora haya más interés.
    Idealmente habría muchos modelos diminutos, cada uno muy especializado, pequeño y rápido en inferencia, pero si no se organizan bien, mantenerlos todos actualizados en algún momento se vuelve inmanejable.

• Ese es precisamente el punto central del fine-tuning de modelos.
  Me gusta que haya mostrado el proceso de fine-tuning combinando opciones alojadas y locales.

  • Me pregunto si existe un buen servicio del estilo: “aquí está el dataset; haz fine-tuning de estos 9 modelos y dame las estadísticas de evaluación”.
  • Lo importante no es simplemente que el modelo mejoró al hacerle fine-tuning, sino que con fine-tuning de un modelo mucho más simple se superó a un modelo mucho más avanzado.

• El artículo está bien escrito y es útil.
  Vi que en la prueba de GPT del ejemplo se usó temperature=1; me pregunto si esa es una buena práctica para tareas que requieren salida estructurada.
  Según mi comprensión básica, para estas cargas de trabajo lo mejor sería temperature 0, y una temperatura alta es más adecuada para tareas más creativas.

  • Se configuró siguiendo la guía de cada modelo.
    Algunos proveedores de fine-tuning de LLM de hecho indicaban temperature 0 y lo seguí tal cual; otros recomendaban 1.
    Se podría iterar para encontrar el mejor valor para cada modelo, y valdría la pena hacerlo con los modelos en los que se vaya a concentrar en iteraciones/fine-tuning posteriores.

• Me gustaría ver ejemplos en los que GPT-4o se equivocó pero el modelo con mejor rendimiento acertó.
  Además, como alguien que ha hecho mucha extracción de datos estructurados, recomendaría intentarlo de nuevo con temperature 0; por experiencia, siempre hay que usar 0, y la diferencia puede ser enorme.
  Temperature 1 básicamente significa que el modelo empieza a elegir tokens con menor probabilidad de ser correctos.

  • Para este caso de uso, donde hay respuestas claramente correctas/incorrectas basadas en datos históricos, una comparación con temperature 0 sería interesante.
    Cuando experimenté con temperature en un editor SQL con IA, 0.3 resultó ideal, porque mientras más cerca de 0, más se optimiza para precisión, pero si se produce un error, al modelo le cuesta más autocorregirse.

• Escribí un paper sobre un tema similar: https://www.nature.com/articles/s41467-024-45563-x

• Me pregunto si el contenido potencialmente polémico de los artículos de noticias objetivo puede afectar la capacidad de ChatGPT para resumirlos.

  • Estamos usando extracción de información con LLM mediante OpenAI Azure para artículos de noticias financieras, y esto es un gran problema.
    Solo con textos de noticias financieras, en el 4% de los artículos aparece una respuesta 404 de moderación de contenido, y esa es una razón importante por la que estamos evaluando modelos abiertos.
  • No creo que sea el caso.
    Normalmente, cuando ocurre ese tipo de error, no hay salida en absoluto, pero el artículo muestra que obtuvieron salidas JSON válidas para las consultas de los 724 casos de prueba.
    Es probable que estos temas estén bien representados en los datos de entrenamiento, y como los modelos open source probablemente usaron datos similares, la brecha entre modelos propietarios y open source tampoco debería ser tan grande.

• A riesgo de sonar como alguien de otra época, diría que la máxima prioridad debería ser publicar todos los modelos como software libre/open source en la mayor medida posible para que todo el mundo pueda hacerles fine-tuning.
  Es un subcaso de la idea de que el software libre/open source suele ser mejor tanto en libertad como en calidad.

  • Parece implicar que quien acumule más datos personales y reclame su propiedad terminará creando los mejores productos.
    Es parecido a cuando la publicidad personalizada parecía mejor porque era más “relevante”, pero ahora no se trata solo de anuncios, sino también de productos útiles.
    Los dueños de plataformas como Apple o Microsoft pueden extraer datos de apps y productos, incluso localmente, así que obtienen una ventaja mucho mayor que estar 3 a 6 meses adelante en calidad de modelo.
    No me gusta la centralización de esta tecnología, pero aunque sea esperanzador que los modelos pequeños con fine-tuning sean mejores, será difícil —o casi imposible— ganar solo con apertura y privacidad.
    Lo mejor sería que los modelos abiertos se generalicen y sean eficaces en el ámbito de servicios para pymes, de modo que no haga falta pagar costos de tokens de OpenAI.
    Probablemente ese era el plan de Zuck, y quizá buscaba evitar guardianes centralizados en una tecnología que beneficia principalmente a sus competidores.
    Aun así, el enemigo de mi enemigo es mi amigo, así que sus acciones podrían ser de lo mejor que ha hecho en favor del interés público.

• En Predibase realizamos recientemente más de 700 experimentos de fine-tuning para comparar el rendimiento de LLM open source populares en 30 tareas y contrastarlo con GPT-4.
  En el 85% de los casos superaron a GPT-4, y los resultados pueden verse aquí: https://predibase.com/fine-tuning-index
  El sitio incluye gráficos interactivos y un enlace al paper en Arxiv.