Meu modelo com fine-tuning supera o OpenAI GPT-4

• Em 724 testes de extração de dados estruturados em comunicados de imprensa da ISAF, vários modelos com fine-tuning alcançaram maior precisão do que a família GPT-4
• A comparação incluiu GPT-4o, GPT-4 Turbo, GPT-3.5 Turbo e modelos com fine-tuning baseados em TinyLlama, Mistral, Llama3, Solar e GPT-3.5
• Os modelos da OpenAI sempre produziram JSON válido, e os fine-tunings de Mistral e Llama3 também foram estáveis, mas o TinyLlama mostrou grande variação em valores ausentes e qualidade do JSON dependendo do template
• Na apuração final, o Mistral-7B com fine-tuning via OpenPipe ficou em 1º lugar, seguido de perto pelo Solar LLM e pelo Llama3-7B
• O fine-tuning pode trazer melhorias em privacidade, controle e custo, mas também aumenta a complexidade de MLOps para gerenciar inferência, avaliação e reprodutibilidade entre modelos espalhados por vários ambientes

---

Objetivo do experimento e conjunto de dados

• O objetivo foi avaliar a precisão de LLMs com fine-tuning na tarefa de extrair informações de eventos a partir de comunicados de imprensa da ISAF
• Os dados estão em um repositório público no Hugging Face Hub, e a avaliação foi feita com o test split que os modelos não haviam visto
  • Os dados de teste são compostos por 724 linhas
  • Os campos incluem name, eventrefnumber, text, StartDate, eventtype, province, targetgroup, minkilled, mincaptured, killq, captureq, killcaptureraid, airstrike, noshotsfired, minleaderskilled, minleaderscaptured etc.
• Cada linha foi convertida em um objeto Pydantic para facilitar validação e processamento
• Esperava-se que a saída dos modelos seguisse a seguinte estrutura JSON
  • name
  • start_date
  • event_type
  • province
  • target_group
  • min_killed
  • min_captured
  • killq
  • captureq
  • killcaptureraid
  • airstrike
  • noshotsfired
  • min_leaders_killed
  • min_leaders_captured

Como os modelos de referência da OpenAI foram avaliados

• GPT-4o, GPT-4 Turbo e GPT-3.5 Turbo foram usados como base de comparação
• Os modelos GPT não podiam usar exatamente o mesmo prompt dos modelos com fine-tuning, então precisaram de um prompt mais longo
  • A lista de campos a extrair foi explicitada
  • Foram fornecidos os valores permitidos para tipo de evento, província e grupo-alvo
  • Foram incluídas regras de anotação numérica
  • Um comunicado de imprensa de exemplo e o JSON esperado foram incluídos
• As regras de anotação numérica usaram os seguintes critérios
  • a couple é interpretado como 2
  • several é interpretado como no mínimo 3
  • a few, some, a group, a small group, multiple são interpretados como no mínimo 3
  • numerous, a handful são interpretados como no mínimo 4
  • a large number é interpretado como no mínimo 5
  • facilitator não é leader
• As previsões em lote foram executadas de forma assíncrona, e por causa do rate limit do GPT-3.5 Turbo foi adicionada lógica de retry
• Os resultados foram salvos no campo predictions de cada evento, por nome de modelo

Configuração dos modelos com fine-tuning

• Depois das previsões dos modelos de referência da OpenAI, foram adicionadas ao mesmo dataset previsões de modelos locais já ajustados antes e de modelos baseados em serviços de fine-tuning com um clique
• Os modelos com fine-tuning incluídos foram os seguintes
  • 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
• O modelo local com fine-tuning de Mistral foi inferido em um ambiente A100 da Modal porque era difícil executá-lo localmente
  • Depois, na avaliação, ele falhou em quase todos os itens
  • Nos gráficos, aparece como mistral-lora-templatefree
• O modelo gpt-3.5-turbo-1106 foi ajustado usando o serviço de fine-tuning com um clique da OpenAI
• A OpenPipe foi usada para gerar previsões com Mistral 7B, Mistral 8x7B e Llama3
• Na Predibase, foi avaliado um modelo baseado no Solar LLM da Upstage
  • O Solar LLM é apresentado como um modelo treinado para ser forte em tarefas em que o fine-tuning é usado com frequência, como extração de dados estruturados
  • O modelo base é presumivelmente o upstage/SOLAR-10.7B-v1.0 no Hugging Face Hub
• A inferência do Qwen2 na Predibase não funcionou e ficou de fora desta avaliação
• O dataset final com previsões foi publicado como dataset público no Hugging Face Hub

Validade do JSON e valores ausentes

• A primeira avaliação verificou se a saída de cada modelo era um JSON válido
• Os modelos da OpenAI geraram JSON válido em todas as vezes
• Os modelos com fine-tuning de Mistral e Llama3 também produziram JSON válido de forma estável
• O TinyLlama variou bastante dependendo do template escolhido
  • tinyllama-sharegpt teve 38 valores ausentes
  • Sem esses valores ausentes, a avaliação considera que ele teria tido 724 previsões e JSON válido em todos os casos
• A contagem de valores ausentes foi a seguinte
  • 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

Precisão por campo

• A avaliação de precisão foi feita com base em 13 atributos no total
  • start_date
  • province
  • target_group
  • event_type
  • min_killed
  • min_captured
  • killq
  • captureq
  • killcaptureraid
  • airstrike
  • noshotsfired
  • min_leaders_killed
  • min_leaders_captured
• O total de tarefas em todos os gráficos foi 724

• start_date

  • Em precisão de start_date, o Solar e o modelo GPT-3.5 com fine-tuning tiveram o melhor desempenho
  • As pontuações foram as seguintes
    • 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
  • Mesmo o melhor modelo errou 75 datas, então ainda há espaço para melhorar a extração de datas

• province

  • Na previsão de província (province), os modelos com fine-tuning ficaram à frente dos modelos da OpenAI
  • As pontuações foram as seguintes
    • 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 e event_type

  • target_group pode ter vários grupos, então a pontuação foi calculada pela proporção de grupos corretos que o modelo acertou
  • Os modelos com fine-tuning tiveram desempenho significativamente melhor do que os modelos da OpenAI na identificação do grupo-alvo
  • Ainda assim, o desempenho pode cair se forem adicionados novos grupos que não existiam nos dados de treino
  • event_type tem categorias semanticamente sobrepostas, então foi tratado como um item difícil até para anotadores humanos
  • Mesmo nesse item difícil, os modelos com fine-tuning tiveram bom desempenho

• Campos numéricos e booleanos

  • Em estimativas numéricas como min_killed, a diferença entre os modelos com fine-tuning e os da OpenAI diminuiu
  • O Mistral teve a maior pontuação, mas a diferença não foi grande, e os modelos da OpenAI também tiveram bom desempenho nesse item
  • É possível que as regras de anotação numérica incluídas no prompt longo tenham ajudado
  • Atributos booleanos como killq tiveram alta precisão na maioria dos modelos
  • O Mistral com fine-tuning superou até a melhor pontuação do GPT-4o nesse item
  • killcaptureraid apareceu como um item desfavorável para os modelos da OpenAI
    • kill-capture raid era um termo técnico usado de uma forma específica na rotulagem
    • Os modelos da OpenAI não conheciam esse critério de rotulagem
  • noshotsfired é um campo derivado de comunicados de imprensa de um certo período que enfatizavam o fato de “nenhum tiro ter sido disparado”
  • Os modelos da OpenAI tiveram desempenho na ordem inversa da esperada, e será preciso investigação adicional para entender o motivo
  • min_leaders_killed e min_leaders_captured tiveram pontuações altas no geral
  • Ao contrário da percepção comum de que LLMs são fracos com números, nesta tarefa eles tiveram alto desempenho, embora os modelos com fine-tuning ainda tenham obtido os melhores resultados

Resultado final consolidado

• A precisão final consolidada foi calculada somando as 13 pontuações individuais de precisão, depois tirando a média em uma escala de 0 a 100
• No resultado final, os modelos com fine-tuning superaram a família OpenAI GPT
• Até o TinyLlama teve precisão consolidada maior que a do GPT-3.5 Turbo
• O modelo com melhor desempenho foi o Mistral-7B com fine-tuning via OpenPipe
• Solar LLM e Llama3-7B vieram logo atrás do Mistral-7B por uma margem muito pequena
• Em fine-tuning para extração de dados estruturados, parece razoável começar por Mistral-7B, Solar 7B e Llama3-7B e comparar qual se encaixa melhor
• Considerando apenas a precisão, os três modelos podem ser quase equivalentes
• Pode haver trade-offs separados em serving de modelos, eficiência e latência

Vantagens e custos do fine-tuning

• Os modelos da OpenAI também podem melhorar o desempenho se receberem mais exemplos e regras no prompt
• Mas, à medida que o prompt fica mais longo, o custo por requisição aumenta
• Um modelo próprio com fine-tuning oferece as seguintes vantagens
  • Privacidade de dados, por não precisar enviar informações confidenciais para a OpenAI
  • Potencial melhoria de desempenho com modelos menores
  • Mais controle
  • Possibilidade de reduzir custos
• A comparação de custos ainda é difícil de cravar com clareza
  • Grandes provedores de nuvem podem aproveitar economias de escala
  • Em casos de uso reais com inferência repetida no longo prazo, a lógica de custo de um modelo próprio pode ser mais convincente
  • Para melhorar chamadas à OpenAI, pode ser necessário incluir muitos exemplos e explicações, elevando o custo por consulta

Operação da avaliação e complexidade de MLOps

• O fine-tuning obteve desempenho melhor que o GPT-4 com relativamente poucos ajustes
  • Os modelos usados foram os primeiros modelos com fine-tuning feitos com os dados coletados
  • A maioria usou os valores padrão
• O plano daqui para frente é focar nos modelos Solar, Llama3 e Mistral 7B
• A avaliação foi implementada principalmente em um Jupyter notebook, e a operação foi trabalhosa
  • Alguns modelos rodavam localmente
  • Outros estavam implantados em serviços e ambientes diferentes
  • Percorrer as 724 linhas foi lento
• Na próxima iteração, será necessário permitir que a avaliação rode localmente e usar uma abordagem de avaliar primeiro apenas um slice dos dados e depois expandir para o conjunto completo
• Ao lidar com vários modelos no mesmo projeto, é preciso uma interface de inferência padronizada
• Quando os modelos estão espalhados por vários lugares, o fine-tuning e as atualizações se repetem, e os dados continuam mudando, passa a ser necessário um sistema para gerenciar tudo isso
• O principal trade-off de LLMs com fine-tuning é que muitos componentes precisam ser gerenciados para manter uma operação estável e reproduzível

O valor deixado pela avaliação e próximos passos

• Embora implementar a avaliação tenha sido trabalhoso, ela fornece um critério específico da tarefa para verificar se melhorias nos dados de treino ou no modelo estão gerando progresso real
• Sem avaliação, fica difícil julgar se houve melhora
• A ideia de criar vários modelos ultrasspecializados não é o próximo passo mais claro neste momento
  • Ex.: um modelo separado que só seja bom em estimar número de capturados
  • Pelo desempenho atual, não está claro se essa abordagem elevaria muito a precisão
• O próximo passo de maior prioridade é executar avaliações além da precisão
  • Um exemplo é a avaliação em dados out-of-domain mencionada no texto anterior
  • A intenção é verificar o comportamento em dados falsos de temas completamente diferentes
• Outro próximo passo é analisar mais a fundo o LLM serving dos 3 melhores modelos
  • LLM serving tem ferramentas, trade-offs e técnicas diferentes do serving de modelos não LLM
• Se quiser aprofundar mais o problema, uma abordagem útil é enviar os casos errados para interfaces web como Lilac ou Argilla e analisar padrões de falha
• Entender os cenários de falha pode ajudar mais a melhorar a precisão do que ajustar parâmetros de fine-tuning

[GN⁺]

Opiniões no Hacker News

• Como fundador da OpenPipe, vejo extração de dados como um caso de uso em que modelos ajustados por fine-tuning se saem especialmente bem, então não surpreende que tenham obtido bons resultados.
  Se você consegue criar bons dados de treinamento, também foi bastante fácil superar o GPT-4 em vários tipos de tarefa; em um estudo que publicamos há uma semana, um Llama 3 8B com fine-tuning superou o GPT-4 em 3 das 4 tarefas de exemplo: resumo criativo, perguntas e respostas, extração de dados e classificação.
  O ponto central foi criar uma forma de gerar dados de treinamento de alta qualidade de modo iterativo, e o texto também aborda isso: https://openpipe.ai/blog/mixture-of-agents

  • Fico curioso se até entusiastas de tecnologia que não são especialistas conseguem fazer fine-tuning e executar isso com facilidade.
    O caso de uso seria treinar em documentação técnica, notícias específicas, dois anos de posts de blog, fontes primárias e threads explicativas no Twitter para criar um LLM especialista no assunto, reunindo informações de nicho sobre um tema nos últimos dois anos.
  • Fico curioso se, ao criar com um LLM um modelo meta que escolhe um entre vários modelos com fine-tuning conforme a pergunta, não seria possível obter resultados melhores que o GPT-4 no geral.
  • Fico curioso se treinar um novo modelo usando respostas de modelos dos principais provedores de LLMs (OpenAI, Anthropic etc.) viola os termos de uso.

• Esse resultado não surpreende em nada e está alinhado com resultados já existentes de que, em extração de informação e classificação de texto, modelos pequenos especializados também se saem melhor.
  No doutorado, trabalhei com extração detalhada de eventos e sentimentos no estilo ACE, e transformers “pequenos”, especializados e ajustados por fine-tuning, foram melhores que usar prompts em LLMs como BERT ou Roberta-large.
  Seria bom incluir também pontuações de modelos pequenos junto com pipelines modernos; ainda que seja uma reprodução de um resultado conhecido, é um bom trabalho.

  • Há a ressalva de que, se você não souber criar um bom modelo especializado, vai apenas desperdiçar o tempo e o dinheiro de todos: https://www.threads.net/@ethan_mollick/post/C46AfItO8RS?hl=e...
  • O tema da tese parece interessante; fico curioso se há um link.

• O único uso sério de LLMs que achei útil no trabalho real foi extração/estruturação de dados.
  Eu precisava extrair o início, o fim e a descrição de eventos de relatórios de amostragem de experiências que não podia compartilhar online, e rodei um modelo com llama.cpp para convertê-los em CSV com 4 colunas: onset, offset, description e se determinada condição era atendida.
  Só de colocar no prompt alguns exemplos da estrutura desejada, vários modelos deram conta muito bem, e gostei do Mixtral 8x7b, que foi o mais rápido entre os de qualidade semelhante no notebook.
  Para essa tarefa, é bem provável que um modelo menor com fine-tuning seja melhor e mais rápido; quando não se pode enviar dados para lugares como a OpenAI, o processamento offline é necessário, então modelos pequenos, executáveis localmente e passíveis de fine-tuning podem brilhar.

  • Percebi isso cedo ao experimentar extração de dados da web com GPT-3 e, depois de publicar o primeiro protótipo no Reddit e no HN, vi muita demanda por automação da stack de web scraping baseada em regras.
    Isso levou à startup https://kadoa.com, que automatiza esse problema “chato e difícil”, que exige muita manutenção e é difícil de escalar.
    Onde a IA agrega mais valor é nesses usos relativamente menos glamourosos; em vez de eliminar empregos, ela vai automatizar tarefas repetitivas como web scraping, preenchimento de formulários e entrada de dados.
  • Como próximo passo, ao trabalhar com implantação/inferência, quero ver o quanto dá para reduzir o tamanho do modelo.
    A Spacy há muito tempo impulsiona esse caminho de usar modelos de dezenas de MB, e é bom ver que agora há mais interesse nisso.
    Idealmente, seria bom ter muitos modelos minúsculos, cada um muito especializado, pequeno e rápido na inferência, mas, se não forem bem organizados, manter todos atualizados em algum momento se torna inviável.

• Esse é justamente o ponto central do fine-tuning de modelos.
  Foi bom ver o processo de fine-tuning sendo mostrado com uma mistura de opções hospedadas e locais.

  • Fico curioso se existe um bom serviço do tipo: “aqui está um dataset; faça fine-tuning destes 9 modelos e me entregue as estatísticas de avaliação”.
  • O ponto central não é simplesmente que o modelo melhorou com fine-tuning, mas que um modelo muito mais simples, ajustado por fine-tuning, venceu um modelo muito mais avançado.

• O texto é bem escrito e útil.
  Vi que, no teste com GPT do exemplo, foi usado temperature=1; fico curioso se isso é uma prática recomendada para tarefas que exigem saída estruturada.
  Pelo que entendo de forma geral, temperature 0 é o melhor para esse tipo de carga de trabalho, enquanto temperaturas mais altas são adequadas para tarefas mais criativas.

  • Configurei de acordo com o guia de cada modelo específico.
    Alguns provedores de fine-tuning de LLMs de fato especificavam temperature 0, e eu segui isso; outros recomendavam 1.
    Dá para iterar em experimentos para encontrar o melhor valor para cada modelo, e valeria a pena fazer isso nos modelos em que eu for concentrar iterações/fine-tuning depois.

• Seria bom ver um exemplo em que o GPT-4o errou, mas o modelo de melhor desempenho acertou.
  Além disso, como alguém que já fez bastante extração de dados estruturados, seria bom tentar de novo com temperature 0; pela minha experiência, deve-se sempre usar 0, e a diferença pode ser muito grande.
  Temperature 1 basicamente significa que ele começa a escolher também tokens com menor probabilidade de estarem corretos.

  • Para esse caso de uso, em que há respostas claramente certas/erradas com base em dados históricos, uma comparação com temperature 0 seria interessante.
    Quando experimentei temperature em um editor de SQL com IA, 0.3 foi o ideal, porque quanto mais perto de 0, mais otimizado para precisão, mas, se ocorre um erro, fica mais difícil de se recuperar sozinho.

• Escrevi um artigo sobre um tema parecido: https://www.nature.com/articles/s41467-024-45563-x

• Fico curioso se o conteúdo potencialmente controverso dos artigos de notícias-alvo pode afetar a capacidade de resumo do ChatGPT.

  • Estamos usando extração de informação com LLM via OpenAI Azure em notícias financeiras, e isso é um grande problema.
    Só com textos de notícias financeiras, recebemos respostas 404 de moderação de conteúdo em 4% dos artigos, e esse é um dos principais motivos para avaliarmos modelos abertos.
  • Acho que não.
    Normalmente, quando esse tipo de erro acontece, não sai nenhuma resposta; no texto, eles mostram que obtiveram saída JSON válida para consultas em todos os 724 casos de teste.
    Esse tipo de tema provavelmente foi bem incluído nos dados de treinamento, e modelos open source também devem ter usado dados parecidos, então a diferença entre modelos proprietários e open source não deve ser grande.

• Correndo o risco de soar como alguém antiquado, eu diria que a prioridade máxima deveria ser publicar todos os modelos da forma mais livre e open source possível, para que todos possam fazer fine-tuning.
  Isso é um subcaso da ideia de que software livre/open source tende a ser melhor tanto em liberdade quanto em qualidade.

  • Parece significar que quem acumular a maior quantidade de dados pessoais e reivindicar propriedade sobre eles acabará criando o melhor produto.
    É parecido com quando anúncios personalizados pareciam melhores por serem mais “relevantes”, mas agora isso vale não só para anúncios, como também para produtos úteis.
    Donos de plataformas como Apple ou Microsoft podem coletar dados de apps e produtos, até localmente, então ganham uma vantagem muito maior do que ficar 3 a 6 meses à frente na qualidade do modelo.
    Não gosto da centralização dessa tecnologia, mas, embora seja promissor que modelos pequenos com fine-tuning sejam melhores, será difícil, ou quase impossível, vencer apenas com abertura e privacidade.
    O melhor cenário é uma disseminação em que modelos abertos se tornem generalizados e eficazes no espaço de serviços para pequenas e médias empresas, tornando desnecessário pagar pelos tokens da OpenAI.
    Esse provavelmente era o plano do Zuck, e talvez a intenção fosse impedir um gatekeeper centralizado em uma tecnologia que beneficia principalmente concorrentes.
    Ainda assim, o inimigo do meu inimigo é meu amigo, então suas ações talvez sejam a melhor coisa que ele já fez pelo interesse público.

• Na Predibase, recentemente realizamos mais de 700 experimentos de fine-tuning para fazer benchmark do desempenho de LLMs open source populares em 30 tarefas e compará-los com o GPT-4.
  Em 85% dos casos, eles venceram o GPT-4, e os resultados podem ser vistos aqui: https://predibase.com/fine-tuning-index
  O site tem gráficos interativos e link para um artigo no Arxiv.