RAG ou fine tuning é uma escolha sobre aquilo que o seu assistente precisa de fazer. O RAG, abreviatura de retrieval-augmented generation, fornece material de origem relevante quando o modelo responde; fine tuning significa continuar a treinar um modelo com exemplos. Comece por testar uma instrução clara para a tarefa, ou prompt. Depois, use o resultado para decidir se deve investigar a falta de material de origem, os resultados inconsistentes ou ambas as questões antes de contratar trabalho adicional.
Um fornecedor propõe treinar um sistema de IA para a sua empresa, enquanto outro propõe uma base de conhecimentos pesquisável. Estas descrições não definem a tarefa que o sistema final terá de executar nem o que seria considerado um resultado falhado. Começamos por colocar essa tarefa por escrito. Assim, terá algo concreto para comparar quando receber as propostas.
O que muda entre RAG e fine tuning?
O RAG altera o material fornecido para uma resposta; o fine tuning altera o modelo através do treino. O guia de precisão da OpenAI distingue a falta de contexto do comportamento inconsistente. Esta é uma distinção inicial útil para um comprador, desde que deixe espaço para necessidades que se sobreponham. Um assistente baseado em documentos também pode precisar de uma forma consistente de redigir a resposta.
Segundo a explicação da Amazon Bedrock sobre bases de conhecimentos, a recuperação seleciona material relevante e inclui-o nos dados de entrada da geração. Para uma proposta de assistente que responda a perguntas sobre uma política de devoluções, peça para ver qual é o excerto aprovado que sustenta a resposta. Uma referência à fonte continua a ter de ser comparada com aquilo que a resposta diz.
O fine tuning utiliza exemplos para continuar a treinar um modelo na forma como responde. O guia da OpenAI descreve-o como uma opção para melhorar o comportamento numa tarefa. Pense numa nota de passagem de trabalho, com uma estrutura acordada: o fornecedor precisa de exemplos de notas aceitáveis e dos dados de entrada que lhes deram origem. Este resultado é diferente de uma pasta de documentos de políticas.
Nenhuma das designações lhe diz se a demonstração cumpre os seus requisitos. Peça ao fornecedor que identifique aquilo que o componente proposto altera, mostre o material que utiliza e explique como verificará o resultado. Mantenha a discussão ligada ao trabalho que está efetivamente a comprar.
Comece com uma tarefa e uma demonstração simples
Descreva os dados de entrada e o resultado aceitável antes de escolher uma abordagem. O guia de prompts da Anthropic começa com critérios claros de sucesso, um teste com exemplos e um primeiro prompt. Usamos esta ordem para preparar um briefing de compra: escreva a instrução, forneça material aprovado e analise o que a configuração proposta mais simples consegue fazer. Este é o nosso método de avaliação sugerido, não um teste de referência publicado.
Para ilustrar, os dados de entrada de um assistente de devoluções poderiam ser a pergunta de um cliente e a política aplicável. Um rascunho aceitável responde apenas ao que essa política sustenta e encaminha as exceções para uma pessoa. Para ilustrar uma passagem de trabalho de vendas, os dados de entrada poderiam ser um pedido de informação e um formato de nota aprovado. O resultado deve preservar o significado do pedido e deixar por preencher os dados em falta.
Peça ao responsável pelo processo que escreva aquilo que torna aceitável cada resultado. Inclua um pedido que o assistente deva recusar ou encaminhar. Use material que tenha autorização para partilhar, com os dados pessoais desnecessários removidos. Uma demonstração que dependa de informação que não pode fornecer ainda não constitui uma proposta viável.
Se já tiver um assistente a dar respostas pouco fiáveis, use o guia separado para verificar por que razão a IA dá respostas erradas antes de decidir o que contratar.
Escolha o teste seguinte com base na lacuna restante
Use a falha observada para escolher aquilo que deve testar a seguir. A AWS recomenda começar pela recuperação para perguntas que façam referência a documentos personalizados e assinala a dificuldade de manter o treino alinhado com material que muda frequentemente. Também admite a utilização conjunta de recuperação e fine tuning. A tabela abaixo sugere um teste seguinte para a lacuna que encontrou na demonstração.
| Aquilo de que a demonstração ainda precisa | O que testar a seguir |
|---|---|
| Informação proveniente de documentos aprovados e em mudança | Recuperação que forneça o material atual relevante |
| Um resultado repetível que continua inconsistente depois de instruções e exemplos mais claros | Treino com exemplos aceites, caso o modelo escolhido o permita |
| Material de origem e uma resposta mais consistente | Uma configuração combinada, com uma verificação para cada requisito |
Quando a demonstração mais simples já cumpre os requisitos, mantenha essa opção na comparação. Pergunte que problema adicional resolveria o treino proposto ou o sistema de recuperação. A escolha também pode continuar em aberto enquanto prepara os dados de entrada em falta.
A AWS assinala que o fine tuning não está disponível para todos os modelos. Peça ao fornecedor que indique o prestador e o modelo, explique onde e como o sistema será executado e confirme o suporte atual para o treino e a implementação propostos.
Quem mantém o sistema após o lançamento?
Compare as responsabilidades que cada proposta deixa à sua equipa. Para a recuperação, identifique a pessoa que aprova os documentos de origem e verifica se as atualizações chegam ao assistente. Para o treino, identifique quem prepara os exemplos aceites e analisa alterações posteriores. Registe quem concede acesso, quem trata das falhas e como os colaboradores devolvem a tarefa ao processo manual quando o sistema não é adequado.
Incluímos estas questões no planeamento da implementação de IA antes de escolher componentes. Um briefing útil regista:
- A tarefa, os dados de entrada permitidos e o resultado esperado.
- As fontes oficiais, o respetivo responsável e o processo de atualização.
- Exemplos de trabalho aceitável e de omissões ou adições inaceitáveis.
- As condições para recusar um pedido ou o encaminhar para uma pessoa.
- As verificações de aceitação, o revisor e o material a entregar.
Para trabalho que envolva uma encomenda ou um registo de contacto ativo, pergunte como o sistema proposto obterá o registo atual permitido. Inclua esse requisito na parte do briefing dedicada à integração com o CRM. Uma proposta para treinar com registos exportados continua a precisar de explicar como serão tratadas as alterações posteriores.
Pergunte onde serão guardados os documentos, as cópias pesquisáveis, os exemplos e os resultados, quem lhes pode aceder e como é tratada a remoção. Registe as respostas referentes à implementação efetiva. Não trate o nome de nenhuma das arquiteturas como uma decisão sobre alojamento ou permissões.
Verifique a proposta com pedidos nunca vistos
Mantenha os pedidos de teste fora do material utilizado para configurar ou treinar o sistema proposto. Peça a cada fornecedor que execute esses pedidos segundo os mesmos critérios de aceitação. Peça ao responsável pelo processo que analise os resultados, os dados de entrada utilizados para os produzir e as correções necessárias. Isto verifica a proposta na sua tarefa, mas não prova o desempenho em todos os pedidos futuros.
- Mantenha uma referência. Guarde aquilo que o processo manual e o prompt mais simples produzem, juntamente com os respetivos dados de entrada e notas da análise.
- Verifique uma atualização da fonte. Altere um documento de teste aprovado e repita a pergunta afetada. Peça ao fornecedor que mostre a versão utilizada e como a atualização chegou até ela.
- Verifique as regras do resultado. Reformule um pedido e deixe alguma informação de fora. Analise se a nota mantém a estrutura necessária sem inventar um dado.
- Teste o acesso e o âmbito. Experimente um pedido fora do âmbito acordado e um utilizador que não deva receber um documento restrito. Analise a recusa ou o encaminhamento efetivamente realizados.
- Registe o trabalho que a sua equipa terá de continuar a fazer. Anote as correções, o tempo de análise e quem terá de manter os materiais. Compare estes elementos com a referência antes de alargar o trabalho.
Quando uma verificação falhar, registe o requisito que falhou e peça uma demonstração revista. Não pague por uma abordagem mais elaborada apenas porque o seu nome parece indicar maior capacidade. Aceite o âmbito que consegue verificar ou mantenha a tarefa a cargo de pessoas enquanto as condições em falta são resolvidas.
Onde intervimos
Começamos por escrever em conjunto a tarefa, os dados permitidos e as verificações de aceitação. Depois, comparamos as abordagens propostas com esse briefing e documentamos quem manterá as fontes, os exemplos e a avaliação. Um primeiro passo útil consiste em escrever um pedido real e aprovar um exemplo do resultado de que precisa.
