Fine tuning com LoRA: como treinar, avaliar e usar adaptadores

O fine tuning com LoRA é um bom próximo passo quando erros recorrentes de estilo, formato ou execução de uma tarefa persistem mesmo com um prompt bem elaborado. A técnica treina 2 matrizes pequenas para cada matriz de pesos adaptada, mantendo os pesos originais congelados; o QLoRA também armazena o modelo-base congelado com precisão de 4 bits. O resultado que importa é uma melhora mensurável na sua tarefa, acompanhada de um plano de implantação que preserve esse ganho.

Documentação e restrições de implantação verificadas em 26 de outubro de 2026. Os mecanismos vêm dos artigos originais sobre LoRA e QLoRA.

Para quem desenvolve a aplicação, a decisão começa com uma falha recorrente. Um modelo de suporte tem a política correta no contexto, mas insiste em escolher o rótulo errado de encaminhamento. Um assistente de escrita entende o briefing, mas ignora repetidamente o padrão editorial da empresa. São bons candidatos. Já um modelo que desconhece a política de reembolso em vigor precisa ter acesso a ela antes de precisar de treinamento.

O que é fine tuning com LoRA?

O LoRA muda o comportamento de um modelo ao aprender uma pequena correção para determinadas matrizes de pesos. No treinamento convencional com LoRA, as matrizes originais permanecem congeladas. Uma matriz de pesos é uma tabela de números aprendidos que transforma informações dentro do modelo; o adaptador é o conjunto adicional de parâmetros aprendidos que modifica essa transformação.

Imagine instalar um módulo de entrada sob medida em um prédio existente. A estrutura é preservada, mas muda a forma como as pessoas passam por ela. O módulo é menor que o prédio e continua dependendo dele. Da mesma forma, um adaptador LoRA não é um modelo de linguagem completo nem substitui seu modelo-base.

O nome significa Low-Rank Adaptation, ou adaptação de baixo posto. Em vez de aprender uma atualização do tamanho inteiro de uma matriz de pesos, o LoRA representa essa atualização como o produto de matrizes menores, normalmente chamadas de A e B. Em uma camada linear, a transformação efetiva pode ser escrita como W + sBA: os pesos congelados W somados à atualização do adaptador, ajustada por um fator de escala. A entrada percorre tanto o caminho do modelo-base quanto o do adaptador, e as saídas são somadas. Formulação original do LoRA.

É assim que o adaptador consegue aprender um formato próprio da empresa sem salvar uma cópia modificada de cada peso da base. Por isso, também, o modelo-base já precisa oferecer uma base adequada para a tarefa. A correção precisa funcionar com o modelo escolhido.

Um exemplo de parâmetros, sem promessa de economia de memória na GPU

Considere uma camada hipotética com 4,096 × 4,096 pesos, ou 16,777,216 parâmetros originais. Com rank 8, suas matrizes LoRA têm 8 × 4,096 e 4,096 × 8 parâmetros. Juntas, somam 65,536 parâmetros treináveis, cerca de 0.39% da quantidade de parâmetros da matriz original.

Essa é uma conta nossa baseada nas dimensões das matrizes descritas no artigo, não um benchmark nem uma recomendação de rank. Ela descreve uma única matriz adaptada. Os pesos congelados continuam presentes, e o treinamento ainda exige memória de trabalho para cálculos intermediários, gradientes do adaptador e estado do otimizador. O estado do otimizador reúne as informações usadas para decidir a próxima atualização do treinamento.

Na prática, é preciso separar quantos parâmetros você atualiza de quanta memória o treinamento inteiro exige. Um adaptador pequeno não torna o modelo por trás dele pequeno.

A distinção entre os métodos segue os artigos sobre LoRA e QLoRA. Nenhum desses nomes garante um resultado específico nos seus dados.

Como configurar o LoRA: rank, módulos-alvo e escala

As configurações controlam o tamanho e a posição da correção, não o quanto o modelo se torna inteligente. O rank é a dimensão interna de A e B: aumentá-lo acrescenta parâmetros treináveis. Os módulos-alvo definem quais partes do modelo recebem adaptadores. O alpha ajusta a escala da atualização, enquanto o dropout pode regularizar o treinamento do adaptador. A referência de configuração do LoRA define esses controles.

Comece pela receita mantida para o seu modelo e só altere uma configuração quando um resultado de validação justificar a mudança. Se o modelo confunde duas categorias de suporte, examine primeiro os rótulos contraditórios e os casos de fronteira que faltam nos dados. Aumentar o rank não informa ao modelo qual dos exemplos contraditórios a sua empresa considera correto.

Confira também quais componentes são treináveis. Algumas configurações treinam módulos adicionais, como uma camada de saída, junto com os adaptadores. Chamar um treinamento de “LoRA” não comprova que apenas A e B mudaram; quem determina isso é a configuração.

O que o QLoRA acrescenta — e quais são seus limites?

O QLoRA atua tanto sobre a memória ocupada pelo modelo-base congelado quanto sobre a quantidade de parâmetros treinados. Sua configuração central armazena a base em 4 bits e treina adaptadores LoRA de maior precisão por meio dela. A base fica congelada, mas continua participando do cálculo usado para aprender o adaptador. Artigo sobre QLoRA.

O artigo combina NF4, uma representação numérica projetada para pesos com distribuição normal; quantização dupla, que comprime as constantes usadas na quantização; e otimizadores paginados, que gerenciam picos de uso de memória. Você não precisa implementar esses mecanismos por conta própria para usar uma receita de QLoRA mantida pelo projeto.

A expressão “treinamento em 4 bits” pode induzir ao erro. Ela não significa que todos os cálculos, ativações e parâmetros do adaptador usem quatro bits. Também não significa que seja possível treinar um modelo com a mesma memória necessária apenas para carregar seus pesos quantizados. Exemplos longos e lotes maiores continuam consumindo memória de trabalho.

Escolha QLoRA quando a memória ocupada pelo modelo-base for o obstáculo e a stack de treinamento oferecer suporte ao modelo de que você precisa. Se o LoRA convencional já couber na memória disponível, compare os dois nos seus casos de validação, sem presumir que quantizar é sempre a melhor escolha. A compressão muda a configuração numérica; seu efeito na tarefa precisa entrar na avaliação.

Nosso guia de quantização de LLMs explica uma questão diferente, ligada à implantação: qual representação comprimida o seu mecanismo de inferência consegue executar. Treinar um adaptador QLoRA não o torna compatível com todos os formatos quantizados usados em produção.

Quando o fine tuning vale mais que prompts ou RAG?

Faça fine tuning quando a falha restante for um padrão de comportamento estável que você consegue demonstrar com exemplos aprovados. Continue usando prompts quando instruções claras já atenderem ao requisito. Use geração aumentada por recuperação, ou RAG, para fornecer documentos relevantes ou informações de bancos de dados no momento da requisição. O processo de decisão mais detalhado está em RAG vs. fine tuning.

Para o padrão editorial da empresa, teste primeiro uma especificação concisa de estilo e exemplos representativos no prompt. Considere treinar quando o comportamento desejado estiver definido e os mesmos desvios se repetirem em entradas variadas. Seus exemplos devem ensinar decisões, como começar pela resposta ou evitar superlativos sem fundamento, em vez de apenas repetir um bordão.

Para o formato, separe sintaxe de significado. Se o ambiente de execução oferecer saída estruturada com restrições, teste esse recurso antes de treinar apenas para obter JSON válido. Uma resposta pode respeitar o esquema e ainda escolher a categoria errada. O LoRA se torna mais interessante quando essa decisão semântica é o problema persistente. Mantenha a validação na aplicação mesmo depois que o adaptador melhorar.

Para uma tarefa específica, defina a fronteira entre as decisões. Um chamado sobre uma cobrança desconhecida pode exigir verificação da conta, enquanto um pagamento duplicado confirmado precisa de análise do faturamento. Treine com pares aprovados de entrada e saída que mostrem essa diferença, incluindo casos que exigem esclarecimento. O ganho é uma decisão recorrente mais precisa, não uma afirmação genérica de que o modelo ficou mais inteligente.

Para conhecimento que muda, a recuperação continua sendo a fonte de referência mais adequada. Um adaptador de estilo não deve determinar a disponibilidade atual de um produto. É possível combinar recuperação e fine tuning: recuperar a política mais recente e treinar o modelo para usar as evidências fornecidas e devolver a resposta no formato exigido. Avalie essa aplicação combinada com o mesmo contexto recuperado nos dois lados da comparação.

Para quem desenvolve, isso significa medir o erro que resta antes de escolher uma stack de treinamento. Para quem opera, significa assumir a responsabilidade pelos exemplos aprovados e decidir quais erros importam. Para quem compra, significa pedir os resultados da comparação antes e depois e o artefato exato que poderá ser implantado, sem aceitar “modelo personalizado” como prova de melhoria.

Se um modelo professor maior fornece exemplos de treinamento para um modelo menor, esse também é um fluxo de destilação de modelos. O LoRA descreve quais parâmetros o aluno atualiza; a destilação descreve de onde vem o sinal de treinamento. Os dois podem ser usados juntos, mas as respostas-alvo geradas ainda precisam de revisão.

API gerenciada ou GPU própria: qual caminho escolher?

Escolha o serviço gerenciado quando os modelos disponíveis, o tratamento dos dados e as opções de implantação atenderem à sua aplicação. Escolha uma GPU própria quando precisar controlar o checkpoint, a receita de treinamento e o ambiente de execução, e tiver condições de operar essa stack. Decida como o modelo será servido antes de iniciar o treinamento.

Together AI: treinamento LoRA explícito e exportação

O Together AI oferece uma API gerenciada de fine tuning cujo guia de início rápido inicia explicitamente um treinamento LoRA. A chamada Python client.fine_tuning.create() usa LoRA por padrão e permite definir lora=True de forma explícita. O fluxo prepara os dados de conversação, valida e envia esses dados, treina e, por fim, implanta o resultado. Guia de início rápido do Together AI.

O ponto crítico é a disponibilidade de uma opção de implantação compatível. Suporte ao treinamento não equivale a disponibilidade serverless, e o guia atual disponibiliza modelos ajustados por meio de inferência dedicada. Confirme que a base escolhida tem uma opção de implantação dedicada compatível antes de se comprometer com ela.

A exportação exige uma decisão à parte. O Together documenta checkpoint="adapter" para exportar apenas os pesos do adaptador e checkpoint="merged" para um checkpoint que combina base e adaptador. Use o adaptador quando o ambiente de execução for carregá-lo sobre a base correspondente; escolha o artefato mesclado quando precisar de um modelo independente. Implantação e tipos de checkpoint.

Fireworks AI: verifique treinamento e inferência separadamente

O Fireworks AI documenta o uso de LoRA em seu fluxo gerenciado de fine tuning supervisionado. O fine tuning supervisionado, ou SFT, aprende a partir de exemplos da resposta desejada. Para configurar explicitamente um treinamento com adaptador, a API REST usa loraRank; o SDK Python usa lora_rank. Documentação de SFT do Fireworks.

A distinção a conferir é entre Tunable e Supports Lora. Uma base pode aceitar um adaptador treinado externamente para inferência sem permitir treinamento no próprio Fireworks. O guia de treinamento também aceita um evaluation_dataset separado, para que você forneça exemplos de validação em vez de depender da divisão automática.

Para inferência, o Fireworks documenta o live merge, que mescla um adaptador no momento da implantação, e o multi-LoRA, que aplica o adaptador selecionado a uma base compartilhada. O guia atual de implantação informa que LoRAs treinados exigem implantações dedicadas sob demanda; a implantação serverless não é compatível. Ele também informa que as configurações de implantação FP8 e FP4 não aceitam complementos LoRA. Portanto, uma opção de implantação comprimida não é automaticamente compatível com adaptadores. Guia de implantação do Fireworks.

PEFT ou Unsloth para fazer fine tuning com LoRA?

O Hugging Face PEFT é a biblioteca aberta para métodos de fine tuning eficientes em parâmetros, incluindo LoRA. Escolha-a quando quiser controle explícito sobre o modelo, a configuração de quantização e os módulos do adaptador. Seu guia de quantização documenta como carregar uma base quantizada, prepará-la para treinamento e então adicionar o adaptador.

O caminho documentado para QLoRA usa BitsAndBytesConfig com load_in_4bit=True, NF4 e quantização dupla; prepare_model_for_kbit_training() prepara o modelo antes que get_peft_model() o envolva com a estrutura do adaptador. Para cobrir as camadas lineares no estilo QLoRA, o guia usa target_modules="all-linear". Trate isso como um padrão de configuração compatível, não como evidência de que toda arquitetura ou todo ambiente de execução posterior aceita qualquer adaptador.

O limite do PEFT está no restante do sistema de treinamento: ele não escolhe seus exemplos, não corrige seu template de chat e não fornece a métrica de sucesso do seu produto.

O Unsloth é um toolkit aberto de treinamento com guias e notebooks de fine tuning mantidos pelo projeto. Seu guia documenta LoRA, QLoRA e fine tuning completo, incluindo load_in_4bit=True para o caminho quantizado. Escolha-o quando um notebook mantido pelo projeto corresponder ao modelo e ao hardware que você pretende usar, e adote esse notebook como receita inicial. Guia de fine tuning do Unsloth.

O ponto crítico do Unsloth é a compatibilidade da receita. Um notebook que conclui o treinamento não prova que o modelo exportado preserva o mesmo comportamento em outro ambiente. Mantenha consistentes o tokenizador, o template de chat e as configurações de geração, e depois avalie o artefato servido. Um template de chat é a formatação que identifica para o modelo os papéis de usuário, assistente e demais mensagens.

O Hugging Face TRL fornece o SFTTrainer, um loop de treinamento supervisionado integrado ao PEFT. Ele aceita conjuntos de dados de treinamento e avaliação, além de assistant_only_loss=True com templates de chat compatíveis, para aprender com as respostas do assistente em vez de todos os tokens da conversa. A restrição é que o template precisa oferecer a máscara necessária para identificar os tokens do assistente; confira os exemplos de treinamento já formatados. SFTTrainer do TRL.

Em um experimento com GPU própria, a sequência é concreta: selecione a base e a receita compatíveis, formate uma conversa de exemplo, confira quais tokens entram no cálculo da perda de treinamento, adicione o adaptador, forneça os dados de treinamento e validação e salve checkpoints. Um checkpoint é uma versão salva que você pode avaliar ou restaurar. Nosso guia de como fazer fine tuning de um LLM aborda as demais decisões do projeto.

Como disponibilizar e alternar adaptadores na inferência?

Um adaptador precisa acompanhar a identificação e a configuração de seu modelo-base. No PEFT, save_pretrained() salva os pesos do adaptador e o arquivo adapter_config.json; esses arquivos não substituem os pesos da base. Guarde a revisão exata da base, o tokenizador, o template de chat e a configuração de treinamento junto com o adaptador. Formato de checkpoint do PEFT.

Mantenha os adaptadores separados quando várias variantes de tarefa precisarem compartilhar uma base ou quando for importante alternar entre elas. O load_adapter() do PEFT carrega outro adaptador identificado por nome, e set_adapter() o seleciona. Carregar e ativar são operações diferentes. O gerenciador de contexto disable_adapter() permite fazer inferência com o comportamento da base. API de modelos do PEFT.

Essa distinção ajuda na avaliação, mas a seleção de adaptadores em uma aplicação compartilhada também precisa ser segura com requisições simultâneas. Não alterne o adaptador ativo de um único modelo global enquanto requisições independentes estão em andamento presumindo que cada uma receberá o comportamento esperado. Use um ambiente de inferência com regras explícitas de roteamento por requisição.

O vLLM é um mecanismo de inferência que oferece suporte a LoRA em implementações de modelos compatíveis. Seu servidor usa --enable-lora e --lora-modules para registrar adaptadores; as requisições selecionam um adaptador pelo campo model. Confira o suporte do modelo a LoRA, o rank máximo do adaptador e a capacidade configurada de adaptadores simultâneos. Essas são restrições da inferência, não configurações de treinamento. Documentação de LoRA do vLLM.

O carregamento e o descarregamento durante a execução também estão documentados, mas o vLLM desaconselha esse recurso em produção, a menos que o ambiente seja isolado e inteiramente confiável. Para uma implantação rotineira, registrar adaptadores conhecidos na inicialização é uma escolha operacional mais simples.

Mescle o adaptador quando quiser um modelo independente e não precisar alternar adaptadores nesse artefato. O merge_and_unload() do PEFT incorpora a atualização à base e retorna um modelo sem as funcionalidades de adaptador do PEFT. Algumas configurações de quantização não permitem a mesclagem. Preserve o adaptador original e a base separadamente se quiser retomar esse fluxo depois. Limitações de mesclagem do PEFT.

A portabilidade tem uma última ressalva: a base correspondente precisa ter exatamente os mesmos pesos, não apenas um nome conhecido de família de modelos. O Fireworks alerta explicitamente que um checkpoint do fornecedor usado no treinamento pode diferir dos pesos públicos. Confirme essa dependência antes de levar um adaptador para fora da plataforma. Orientações para exportação de adaptadores.

Fine tuning com LoRA: como avaliar o antes e o depois?

Coloque o adaptador em produção somente quando ele melhorar o comportamento desejado em exemplos que não influenciaram sua escolha. A queda da perda de treinamento indica que o modelo se ajusta melhor aos exemplos de treino; ela não é um critério de liberação.

Use este protocolo de avaliação no exemplo de encaminhamento de chamados de suporte. Trata-se de um procedimento recomendado, não do relato de um experimento de treinamento.

1. 1

   Defina os critérios de aceitação antes de treinar

   Defina os rótulos permitidos, os campos obrigatórios da saída e o comportamento de encaminhamento. Decida quais erros impedem a liberação. Para o padrão editorial, escreva regras observáveis, como “apresentar a resposta antes do contexto” e “não acrescentar afirmações sem fundamento”. Uma instrução vaga para escrever melhor não sustenta uma comparação confiável.

2. 2

   Separe os casos de treinamento, validação e teste final

   Os casos de treinamento atualizam o adaptador. Os de validação orientam a escolha da receita e do checkpoint. O teste final permanece reservado até que essas escolhas estejam fechadas. Mantenha chamados relacionados, paráfrases do mesmo documento e exemplos quase duplicados no mesmo subconjunto. Caso contrário, o teste pode premiar familiaridade em vez de capacidade de generalização.

3. 3

   Registre uma referência de comparação forte

   Execute o modelo-base sem ajuste com o melhor prompt viável e os controles de saída estruturada que pretende manter. Em uma aplicação com recuperação, registre também as evidências recuperadas. Salve a revisão do modelo, o prompt, o template, as configurações de geração, as saídas e a versão do avaliador. O adaptador precisa superar uma alternativa viável, não um prompt propositalmente fraco.

4. 4

   Escolha com a validação e compare no teste reservado

   Use os resultados de validação para escolher o checkpoint e encerre essa escolha. Execute o adaptador e o modelo de referência nas mesmas entradas do teste final, com configurações equivalentes. Se a aplicação pretendida usar um prompt mais curto após o treinamento, meça isso separadamente da comparação controlada do adaptador, para que a origem da melhoria fique clara.

5. 5

   Avalie o artefato que será usado na inferência

   Depois de mesclar, quantizar ou trocar o mecanismo de inferência, repita as verificações de aceitação no artefato implantado. Inclua entradas longas, solicitações ambíguas e casos que devem preservar o comportamento da base. Libere somente quando a melhoria desejada sobreviver à implantação e os resultados das verificações de regressão continuarem aceitáveis.

Mantenha pontuações separadas para sintaxe, acerto na tarefa e estilo. No modelo de suporte, um objeto JSON bem formado com uma decisão errada de encaminhamento continua errado. No modelo de escrita, uma resposta mais bem redigida que inventa uma afirmação sobre o produto representa uma regressão.

Informe os denominadores e os resultados por categoria, não apenas uma porcentagem geral de sucesso. A precisão mede com que frequência uma categoria prevista está correta; a revocação mede quantos casos reais daquela categoria o modelo identifica. Se a maioria dos exemplos for de dúvidas rotineiras sobre faturamento, a média geral pode esconder falhas em uma categoria de encaminhamento pouco frequente, mas de grande impacto. Inclua tanto os acertos que viraram erros quanto os erros que viraram acertos.

Na revisão subjetiva de estilo, oculte qual modelo produziu cada saída e varie a ordem de apresentação. Um avaliador baseado em modelo pode ajudar a organizar a revisão, mas confira suas decisões com avaliações humanas antes de usar sua pontuação como critério de liberação. São os critérios de avaliação, e não a fluência da explicação do avaliador, que determinam sua utilidade.

Não transforme o teste final em um segundo conjunto de validação. Assim que você analisa suas falhas e as usa para alterar a receita, esses casos passam a ter influenciado o desenvolvimento. Mantenha-os como casos de regressão e reserve novos casos intocados para a próxima comparação final. Não há uma regra universal de tamanho do conjunto de dados aqui: a questão é se a avaliação representa as decisões que a sua aplicação enfrentará.

Por fim, compare a latência e o uso de recursos do sistema implantado sob a carga de trabalho que ele enfrentará. A economia de parâmetros do LoRA não comprova ganho de velocidade na inferência. Guarde a versão da base com o adaptador que foi aprovada, preserve uma versão para rollback e monitore as mesmas categorias de erro após a liberação.

Onde as promessas sobre LoRA passam do ponto?

“Fine tuning barato” descreve uma otimização mais restrita que “personalização barata”. Você ainda precisa de exemplos aprovados, avaliação, infraestrutura de inferência e manutenção. Nem um checkpoint menor nem um log de treinamento bem-sucedido provam que a aplicação melhorou.

Pesos congelados não significam comportamento congelado. O adaptador muda deliberadamente as saídas do modelo, então a capacidade geral, o comportamento de recusa e a qualidade das respostas ainda precisam de verificações de regressão. Remover o adaptador pode restaurar o caminho da base; mantê-lo ativo não garante respostas inalteradas nas demais situações.

Não há garantia de que LoRA iguale o fine tuning completo. O artigo original relata bons resultados nas tarefas avaliadas. Isso é evidência a favor do método, não um teorema de equivalência universal. Se um adaptador bem avaliado ainda não atender ao requisito, investigue os dados, o modelo-base e a tarefa antes de presumir que um treinamento maior é a resposta.

Não existe rank mágico, quantidade de exemplos ou estimativa de horas de GPU que sirva para tudo. A arquitetura do modelo, o comprimento das sequências, os módulos-alvo e a tarefa concreta mudam o experimento. Comece por uma receita documentada e deixe a validação justificar a próxima mudança.

Perguntas frequentes sobre fine tuning com LoRA

O que é fine tuning com LoRA?

É o treinamento de matrizes adicionais de baixo posto enquanto os pesos originais da base permanecem congelados. O adaptador aprendido modifica o cálculo da base e precisa desse modelo-base para inferência, a menos que os pesos sejam mesclados.

Já provaram que fine tuning não funciona?

Um experimento malsucedido ou um benchmark não sustentam uma conclusão geral. Na sua aplicação, compare o melhor prompt viável no modelo-base com o modelo treinado, usando casos reservados para teste. Se o treinamento não melhorar o comportamento exigido, não coloque o resultado em produção.

Quanto custa fazer fine tuning?

Depende do modelo, dos dados processados, da receita de treinamento e da estrutura de inferência. O LoRA reduz os parâmetros treináveis, mas não elimina a preparação dos dados, a avaliação nem a hospedagem. Escolha um caminho compatível de treinamento e inferência antes de consultar os preços vigentes publicados pelo serviço; um preço universal por treinamento não seria útil.

Qual é um exemplo de fine tuning?

Treinar com mensagens de suporte aprovadas, pareadas com a categoria correta, a ação de encaminhamento e o formato de resposta. Os exemplos ensinam um padrão recorrente de decisão; os registros atuais do cliente ainda precisam ser fornecidos no momento da requisição.

Fine tuning ainda é usado?

Sim. Together AI, Fireworks AI, Hugging Face PEFT e Unsloth documentam caminhos atuais de treinamento. A escolha depende da falha que persiste depois de trabalhar os prompts e, quando necessário, a recuperação de informações.

Como fazer fine tuning?

Defina uma métrica para a tarefa, estabeleça uma referência de comparação, prepare dados separados de treinamento e avaliação, escolha um modelo e uma receita compatíveis, treine, selecione com a validação e compare em um teste reservado antes de implantar. Verifique também o artefato implantado.

O que são PEFT e LoRA?

PEFT significa fine tuning eficiente em parâmetros, uma família de métodos que treina um conjunto limitado de parâmetros. Hugging Face PEFT também é uma biblioteca que implementa esses métodos. LoRA é um dos métodos dessa família.

Quais modelos permitem fine tuning?

Consulte a lista exata de modelos compatíveis do provedor gerenciado ou da stack aberta de treinamento, junto com a licença do modelo. Suporte ao treinamento, suporte a adaptadores na inferência e disponibilidade dos pesos da base são verificações distintas. O nome de uma família de modelos, sozinho, não basta.

Qual é outro nome para fine tuning?

Neste contexto, adaptação à tarefa ou continuação do treinamento com exemplos direcionados. A engenharia de prompt altera as instruções fornecidas no momento da inferência; o fine tuning altera parâmetros aprendidos.

Qual é o próximo passo no seu projeto?

Na próxima semana, pegue uma falha recorrente da aplicação que você já opera e transforme-a em um teste de aceitação explícito. Reúna exemplos aprovados, agrupe os casos relacionados antes de dividir os dados e meça o desempenho do melhor prompt no modelo-base. Se essa referência falhar em um padrão de comportamento estável, escolha um caminho documentado de LoRA cujo resultado você consiga disponibilizar para inferência. Só treine depois que essas decisões estiverem claras.

Para receber guias práticos de desenvolvimento e avaliação de sistemas de IA, assine a newsletter.