Fine-tuning vs RAG vs prompting: qual deve utilizar?
Tradução automática
Este artigo foi traduzido automaticamente a partir da versão original em inglês.
Utilize prompting para clarificar a tarefa, geração aumentada por recuperação (RAG) para fornecer conhecimento atual ou privado e fine-tuning para alterar comportamentos consistentes do modelo. Estas técnicas resolvem problemas diferentes e pertencem frequentemente ao mesmo sistema.
Comece por estabelecer um baseline de prompting medido. Adicione RAG quando as respostas precisarem de evidência externa ou de factos que mudam frequentemente. Considere fine-tuning para erros persistentes de tom, classificação, tool use ou linguagem de domínio, quando existirem exemplos revistos em quantidade suficiente. Para erros no formato das respostas, experimente primeiro structured output condicionado por um esquema.
Escolha com base nos erros observados, na frequência com que os factos mudam e nos dados disponíveis para testar uma correção.
Tabela de decisão
| Problema | Primeira intervenção | Motivo |
|---|---|---|
| As instruções não são claras ou faltam exemplos | Prompting | Permite testar se instruções e exemplos mais claros resolvem as falhas observadas. |
| Os factos são privados, citados ou mudam frequentemente | RAG | A recuperação de informação atualiza o conhecimento sem novo treino e pode preservar a proveniência das fontes. |
| Um comportamento estável continua a falhar após os testes de prompts | Considerar fine-tuning | Exemplos revistos podem ensinar estilo, rótulos ou comportamento na utilização de ferramentas; compare o resultado com o baseline de prompting. |
| Um baseline de prompting cuidadoso continua a falhar | Testar outro modelo ou desenho do sistema | Compare alternativas nos mesmos casos; uma falha de prompting, por si só, não demonstra que o tuning ajudaria. |
| As respostas precisam de factos atuais e comportamento especializado | RAG mais fine-tuning | A recuperação de informação fornece evidência, enquanto o tuning altera a forma como o modelo a utiliza. |
Utilize prompting primeiro
Prompting é uma forma de diagnosticar falhas com pouca configuração. Defina a tarefa, o contrato de saída, os exemplos, as ferramentas permitidas e as condições de recusa. Crie um pequeno conjunto de avaliação antes de adicionar mais infraestrutura. Se um prompt mais forte corrigir as falhas representativas, fique por aí.
Se um prompt cada vez maior se tornar mais difícil de manter, identifique o que foi acrescentado. Os factos sobre o produto que mudam podem ser fornecidos através da recuperação de informação. Exemplos repetidos de comportamento podem ser candidatos a dados de treino. A extensão do prompt, por si só, não demonstra que qualquer uma destas alterações melhorará o resultado.
Utilize RAG para conhecimento e proveniência
RAG é adequado para manuais de produto, políticas, documentos internos, acontecimentos recentes e respostas que tenham de citar uma fonte. O artigo original sobre RAG combina um gerador com excertos recuperados; a evidência recuperada é fornecida no momento do pedido. A sua qualidade depende da análise, da segmentação em fragmentos, da recuperação de informação, da ordenação por relevância, das permissões e do suporte para citações. Alterar apenas o gerador não fornece uma fonte que a recuperação de informação tenha omitido.
RAG não é um método de treino de comportamento. Pode mostrar ao modelo um exemplo ou uma regra, mas não torna esse comportamento estável em todos os pedidos.
Num assistente de suporte, uma resposta desatualizada sobre a garantia indica que falta a política atual: forneça-a através da recuperação de informação. Se a política correta já estiver presente, mas o assistente atribuir repetidamente a categoria errada à reclamação, teste primeiro exemplos mais claros. O fine-tuning passa a ser uma opção se esse erro de classificação persistente se mantiver e existirem exemplos de treino revistos.
Utilize fine-tuning para comportamentos consistentes
O fine-tuning supervisionado treina com exemplos de entrada/saída, conforme descrito no guia de treino do TRL. É uma opção para classificação, estilo de extração, estrutura das respostas, terminologia de domínio e padrões recorrentes de tool use. Para falhas apenas de formato, experimente primeiro structured output condicionado por um esquema, se o seu runtime o suportar. Uma estrutura válida ainda requer verificações dos valores corretos dos campos.
O fine-tuning requer dados de treino revistos, um conjunto de avaliação separado, versionamento do modelo e um procedimento de reversão. Não faça fine-tuning de factos que mudam frequentemente quando a recuperação de informação os pode fornecer no momento do pedido.
Uma sequência prática
- Defina o sucesso e crie um conjunto de avaliação representativo.
- Estabeleça um baseline apenas com prompting, utilizando o modelo mais forte aceitável.
- Adicione RAG se as falhas resultarem de evidência em falta ou em mudança.
- Recolha e reveja exemplos das falhas consistentes que permanecem.
- Faça fine-tuning apenas se o ganho de qualidade, latência ou custo compensar os dados e as operações adicionais do modelo.
- Volte a executar a mesma avaliação após cada alteração ao prompt, ao índice, ao modelo ou ao adaptador.
Leitura adicional
- Fine-tuning de LLMs aborda dados, LoRA, avaliação e implementação.
- Métricas de avaliação de RAG mostra como localizar falhas por fase do pipeline.
- Context engineering para agentes AI aborda o contexto de runtime em torno dos prompts e da recuperação de informação.