A tese numa frase: mudar de modelo de IA é a primeira coisa que se faz quando algo não funciona e a última que se devia fazer. Sai um modelo novo, alguém lê que é mais esperto, e a conversa da equipa passa de «porque é que isto não rende?» para «mudamos para o último?». É a reação mais cómoda do mundo —não obriga a olhar para dentro— e quase sempre é a errada. O estrangulamento raramente é o modelo. São o processo que ninguém definiu bem e os dados que ninguém limpou.
Mudar de modelo de IA é tratar o sintoma, não a doença
Quando um projeto de IA desilude, há dois culpados possíveis: o motor ou tudo o que o rodeia. O motor é o modelo; o que o rodeia é como lhe chega a informação, o que se lhe pede, com que dados trabalha e o que se faz com a resposta dele. A indústria inteira empurra-te a olhar para o motor, porque é o que se vende, se compara e sai nos títulos. Mas na maioria dos projetos que encravam, o motor não é o problema: o problema é que lhe estás a pedir que adivinhe sobre um processo que nem tu tens claro, alimentado com dados que se contradizem uns aos outros.
Pensa nisto com uma analogia aborrecida mas exata: se o teu carro não arranca porque o depósito está vazio, trocar o motor por um mais potente não o move um metro. Mudar de modelo quando o travão é o processo é exatamente isso —uma obra cara que não toca na causa—. E entretanto, a equipa convence-se de que «já tentou tudo», quando na verdade não tocou na única coisa que importava.
O verdadeiro estrangulamento: processo mal definido e dados sujos
Um modelo de IA é tão bom quanto a clareza do trabalho que lhe encomendas e a qualidade do que lhe dás para trabalhar. Quando falha, quase sempre falha por uma destas duas, não por falta de inteligência bruta:
Processo mal definido
Se tu não consegues explicar o processo em passos claros, a IA também não o vai inventar por ti. Muitos «casos de uso de IA» são na verdade processos que nunca foram documentados: cada pessoa fazia-os à sua maneira, com exceções na cabeça e critérios que ninguém escreveu. Pedes à IA que automatize esse caos e, logicamente, produz caos com melhor gramática. Um modelo mais potente não te vai dar a definição do processo que a ti te falta. Como esmiuçar uma tarefa em instruções que uma IA consegue mesmo seguir é metade do trabalho, e abordamo-lo em automatizar tarefas com o ChatGPT.
Dados sujos
A outra metade é de que se alimenta. Se a IA responde a partir de informação desatualizada, duplicada, contraditória ou espalhada por dez sítios que não se falam, a resposta será má por muito excelente que o modelo seja. Lixo entra, lixo sai —isso não o arranja lançamento nenhum—. Este travão é tão comum que lhe dedicamos um artigo inteiro: os dados desordenados são o travão real da IA. E se o teu caso exige que o modelo conheça o teu negócio, o arranjo quase nunca é mudar de modelo: é dar-lhe acesso ordenado à tua informação, algo que destrinçamos em treinar o agente com a tua própria informação.
Porque é que mudar de modelo é tão tentador (e tão inútil)
Se o problema quase sempre é o processo, porque é que a reação por defeito é mudar de modelo? Porque é o fácil. Mudar de modelo é uma decisão de uma tarde: mexes numa configuração, apontas para outro endpoint e já está. Arranjar o processo e os dados é uma decisão de semanas, obriga a falar com quem faz o trabalho, a documentar o que ninguém documentou e a limpar o que ninguém quer limpar. Perante essa escolha, o ser humano prefere a que parece progresso sem ser incómoda.
- Dá sensação de ação sem o ser. Migrar de modelo sente-se produtivo —há algo para mexer, um antes e um depois— mesmo que o resultado não se mova. É teatro de progresso.
- O marketing dá-te o álibi. Cada lançamento vem com benchmarks que prometem um salto. É facílimo convenceres-te de que ESTE é que faltava, em vez de aceitar que a falha está em tua casa.
- Olhar para dentro incomoda. Reconhecer que o teu processo não estava definido ou que os teus dados são um desastre aponta para decisões próprias. Mudar de fornecedor externaliza a culpa: foi o modelo, não nós.
E há um custo que quase ninguém contabiliza: cada migração de modelo não é grátis. Reescreves prompts, revalidas resultados, ajustas a integração e voltas a testar tudo. Se o fazes a perseguir um problema que não estava no modelo, gastas esse esforço para acabar no mesmo sítio —com o processo tão partido como antes, mas com um modelo diferente a quem atirar a culpa da próxima vez—.
Quando mudar de modelo é mesmo a decisão certa
Isto não é «nunca mudes de modelo». Às vezes o motor é mesmo o limite, e então mudar é o sensato. A diferença é que o fazes depois de descartar o resto, não antes de o olhar. Estes são os sinais de que o modelo é de verdade o teu teto:
- Um humano com as tuas mesmas instruções e dados fá-la bem, e a IA não. Se a tarefa está bem definida, os dados estão limpos e uma pessoa com essa mesma informação acerta, mas o modelo falha num tipo de raciocínio concreto, aí sim o motor é o limite.
- Bates num limite técnico real. Janela de contexto insuficiente para o teu caso, idioma que o modelo maneja mal, latência ou custo por token que não batem certo para o teu volume: são limites do motor, não do processo.
- Testaste-o em igualdade de condições. Mudaste só o modelo, com o mesmo processo e os mesmos dados já ordenados, e o novo ganha de forma mensurável e repetível —não numa demo com sorte—.
Repara na ordem: primeiro arranjas processo e dados, e só então, com essa base limpa, comparar modelos torna-se uma decisão com sentido em vez de uma fuga para a frente. Sobre como montar essa base para poder mudar de motor sem dor —desacoplando a aplicação do fornecedor— escrevemos em IA open source vs API fechada.
O que fazer na segunda-feira em vez de mudar de modelo
- Escreve o processo à mão, em passos. Se não consegues explicá-lo numa página clara, a IA não vai resgatar o que tu não tens definido. Esse documento é o arranjo, não o modelo.
- Olha de que dados come a IA. Segue a informação que usa até à origem e verifica se está atualizada, é única e não se contradiz. Ordena isso antes de mexer em mais nada.
- Faz o teste do empregado novo. Um humano brilhante com essas instruções e esses dados faria bem a tarefa? Se não, arranja as instruções e os dados. Se sim e a IA falha, então —e só então— compara modelos.
Se ao fazer isto descobres que o travão não era o modelo mas o processo —que é o mais provável—, é exatamente esse o trabalho que fazemos: definir o processo, ordenar os dados e deixar a automatização a funcionar por cima, com automatização de operações. O modelo é a parte fácil; que o trabalho se faça bem, a difícil.