Voltar ao blog

Fine-tuning em APIs fechadas: do botão de produto ao caso especial

inteligencia-artificial fine-tuning llmops modelos-abertos engenharia-de-ia

A decisão recente da OpenAI de encerrar gradualmente o fine-tuning em autoatendimento não é só uma mudança de produto. Ela expõe uma fronteira técnica que ficou mais importante conforme os modelos ficaram melhores: customizar um modelo fechado por treinamento cria um artefato dependente do ciclo de vida do fornecedor.

O cronograma de encerramento

A partir de 7 de maio de 2026, organizações que não tinham usado fine-tuning deixaram de poder criar jobs. Em 2 de julho, a restrição passa a atingir organizações que não rodaram inferência em um modelo ajustado nos 60 dias anteriores. Em 6 de janeiro de 2027, mesmo clientes ativos deixam de criar novos jobs, e a inferência dos modelos ajustados permanece apenas até a depreciação do modelo-base correspondente.

Essa sequência importa porque fine-tuning sempre ocupou um espaço ambíguo na engenharia de aplicações com LLMs. Ele é vendido como personalização, mas operado como derivação de modelo. Um prompt, um índice de busca, uma função chamada pela API ou um parser de saída são artefatos da aplicação. Um modelo ajustado é diferente: ele incorpora dados, exemplos, formato de resposta, viés de tarefa, política de segurança e dependência de uma versão-base que não pertence ao time que usa o sistema. A vantagem técnica continua real, mas o custo operacional deixou de ser secundário.

A técnica funciona — o problema é o que vem depois

A própria OpenAI mostrou, em 2024, por que a técnica era atraente. No lançamento do fine-tuning para GPT-4o, a empresa descreveu ganhos em estrutura de resposta, tom, instruções específicas de domínio e redução de custo por uso. Também citou casos fortes: o Genie, da Cosine, alcançou 43,8% no SWE-bench Verified com um GPT-4o ajustado, e a Distyl reportou 71,83% de execução no BIRD-SQL com um modelo ajustado para tarefas de SQL. Esses números não sugerem que fine-tuning “não funciona”. Sugerem o oposto: quando a tarefa é estreita, repetível e mensurável, treinar o comportamento no modelo pode superar prompting puro.

O problema aparece depois do benchmark. Um modelo ajustado raramente é só “mais um endpoint”. Ele precisa de dataset versionado, avaliação de regressão, controle de drift, revisão de segurança, monitoramento de custo, estratégia de rollback e plano de migração quando o modelo-base muda. A página de depreciações da OpenAI deixa essa dependência explícita ao amarrar a vida útil dos modelos ajustados à vida útil dos modelos-base. Isso transforma a decisão de ajuste fino em uma decisão de arquitetura, não apenas em uma otimização de qualidade.

O padrão se repete em outras APIs

O movimento não é isolado. A documentação atual da Gemini API informa que, com a depreciação do Gemini 1.5 Flash-001 em maio de 2025, não há mais modelo disponível para fine-tuning na Gemini API ou no AI Studio, embora o suporte exista na Gemini Enterprise Agent Platform. No Vertex AI, o fine-tuning supervisionado continua disponível para Gemini 2.5 Pro, Gemini 2.5 Flash e Gemini 2.5 Flash-Lite, inclusive com modalidades como texto, imagem, áudio, vídeo e documentos. Mas o serviço vem com restrições próprias: não é coberto pelo SLO de SLA, há limites de 131.072 tokens por exemplo de treinamento e limites de dataset como 1 GB em JSONL, 10 milhões de exemplos textuais ou 300 mil multimodais em alguns modelos.

Essa divisão é reveladora. O fine-tuning não desaparece onde há plataforma gerenciada, governança, avaliação integrada e contratos empresariais. Ele desaparece, ou fica restrito, no caminho de menor atrito da API pública. A razão técnica é simples: treinar pesos, mesmo por adaptação supervisionada, muda a superfície de responsabilidade. Um modelo ajustado pode aprender formato, reduzir verbosidade e estabilizar classificação, mas também pode amplificar atalhos do dataset, degradar comportamento fora da distribuição e interagir mal com recursos de inferência que não existiam no momento do treinamento.

Anthropic e Mistral na mesma direção

A Anthropic segue uma linha ainda mais conservadora na API principal: a documentação de Claude afirma que a API não oferece fine-tuning atualmente e orienta interessados a tratar o assunto com contato comercial. A Mistral, por sua vez, mantém documentação de fine-tuning marcada como recurso depreciado e não mais ativamente suportado. Esses sinais apontam para a mesma direção técnica: em modelos fechados de fronteira, a customização por pesos está deixando de ser uma operação comum de desenvolvedor e passando a ser um caso especial, com mais controle do fornecedor e mais peso contratual.

O contraste com modelos de pesos abertos

O contraste aparece nos modelos com pesos abertos. A documentação do Llama descreve fine-tuning como uma forma de adaptar um modelo pré-treinado a um caso específico usando dados próprios, com controle maior do processo justamente por se tratar de um modelo open-weight. Também diferencia fine-tuning completo de métodos eficientes em parâmetros, como LoRA e QLoRA, que reduzem custo computacional ao treinar apenas parte dos parâmetros. Nesse cenário, o artefato ajustado pode ser controlado, exportado, avaliado e hospedado fora do ciclo de vida de uma API proprietária. O preço dessa autonomia é infraestrutura, MLOps, avaliação rigorosa e responsabilidade direta por segurança.

Onde a adaptação precisa viver

A implicação para engenharia é que a pergunta “prompt ou fine-tuning” ficou pobre. A decisão mais importante é onde a adaptação precisa viver. Se o objetivo é conhecimento atualizado, recuperação de documentos, citação de fontes ou integração com sistemas internos, o comportamento precisa ficar em tempo de execução, por busca, ferramentas e contexto. Se o objetivo é padronizar uma tarefa estreita, reduzir tokens, forçar um formato que o modelo erra com frequência ou capturar uma distribuição de exemplos muito repetitiva, fine-tuning ainda pode ser a opção tecnicamente correta. A diferença é que, em APIs fechadas, esse ganho agora vem com uma dependência de plataforma mais clara.

Isso muda também a forma de avaliar aplicações. Um classificador de tickets, um gerador de SQL, um extrator de campos fiscais ou um agente que produz patches não pode ser medido apenas por taxa de acerto no conjunto de validação. É preciso medir estabilidade entre versões de modelo, sensibilidade a mudanças de prompt, custo por tarefa concluída, latência, taxa de saída inválida e esforço de migração. Um fine-tune que melhora 5 pontos percentuais em um benchmark interno pode ser ruim se prende o sistema a um modelo-base prestes a sair. Um prompt maior pode ser ruim se aumenta latência e custo sem eliminar variação. A escolha técnica depende do ciclo de vida completo.

A separação dos caminhos

O sinal mais relevante do encerramento gradual da OpenAI não é o abandono da personalização. É a separação dos caminhos. Em modelos fechados de fronteira, a customização tende a se concentrar em contexto, ferramentas, saídas estruturadas, memória, avaliação e plataformas empresariais. Em modelos com pesos abertos, a customização por treinamento continua sendo parte central da engenharia, mas com responsabilidade operacional transferida para quem usa. O fine-tuning deixa de ser um botão genérico de produto e volta a ser o que sempre foi tecnicamente: uma alteração no modelo que só compensa quando o controle obtido é maior que a dependência criada.

Referências