Construir ou comprar não é uma pergunta binária. Há cinco caminhos: a API de um modelo de fronteira, um modelo de pesos abertos num endpoint gerido, um modelo de pesos abertos afinado, um modelo treinado de raiz e a opção que a maioria das equipas esquece — não resolver o problema com um LLM de todo. Apenas três lentes decidem entre eles: o custo ao volume projetado, o teto de capacidade que a tarefa exige e a exposição regulatória. Para a maioria das organizações, a resposta prática é começar por comprar, construir uma camada de abstração desde o primeiro dia e só reabrir a questão de construir quando existirem dados de utilização reais.
Cinco caminhos, não dois
O enquadramento habitual do debate produz decisões más porque esconde três opções intermédias, e é exatamente aí que está o valor.
| Caminho | O que significa na prática | Quando é o certo |
|---|---|---|
| API de modelo de fronteira | Chamadas a um fornecedor comercial, sem infraestrutura própria | Tarefa ampla, volume moderado, equipa sem profundidade em ML |
| Modelo de pesos abertos gerido | Pesos abertos no endpoint de um fornecedor de infraestrutura | Necessidade de controlo de versões e de custo previsível |
| Modelo aberto afinado | Treino adicional sobre os vossos dados para uma tarefa estreita | Tarefa estreita e repetitiva, bem acima de dez mil exemplos anotados |
| Modelo treinado de raiz | Treino completo, equipa de investigação dedicada | Quase nunca. Só se o próprio modelo for o produto |
| Nenhum LLM | Regras, pesquisa, um modelo estatístico clássico | Quando a tarefa é determinística e inteiramente especificável |
As três lentes que decidem
O custo ao volume projetado. Não o volume de hoje, mas aquele que estão a planear para daqui a um ano. O cálculo rápido: unidades de trabalho por mês multiplicadas pelo custo por unidade no caminho de comprar, contra o custo fixo de engenharia e infraestrutura do caminho de construir. Expomos o método no nosso artigo sobre o custo total de propriedade de uma funcionalidade LLM.
O teto de capacidade. Se a tarefa exige raciocínio em vários passos, uma língua rara ou conhecimento geral do mundo, um modelo pequeno afinado não lá chega, por muito que o treinem. Se a tarefa é classificar em sete categorias, um modelo de fronteira é desperdício.
A exposição regulatória. Quando os dados têm de permanecer dentro de uma jurisdição ou de uma rede fechada, os caminhos de comprar estreitam-se de imediato. É a única lente capaz de eliminar um caminho por completo, e por isso deve ser verificada em primeiro lugar e não em último. A relação entre tipos de dados e permissões está exposta no nosso artigo sobre classificar dados empresariais antes de chegarem a um LLM.
Quando a afinação compensa realmente
A afinação é o caminho que a maioria das equipas escolhe cedo demais. Torna-se compensadora quando todas as condições seguintes se verificam em conjunto, e não apenas algumas:
- A tarefa é estreita, repetitiva e bem definida, e não muda a cada trimestre.
- Têm muitos milhares de exemplos anotados de boa qualidade, vindos da vossa própria produção e não de um corpus genérico.
- O custo ou a latência da API tornou-se de facto a restrição determinante, não uma preocupação teórica.
- Alguém na equipa vai manter o modelo, medir a deriva e retreinar quando a distribuição mudar.
Se faltar uma condição, a afinação acrescenta um custo de manutenção permanente sem o devolver. O padrão que funciona é o oposto: ficar numa API, recolher dados de produção sistematicamente e voltar à questão ao fim de cerca de noventa dias de utilização real, quando existem números em vez de estimativas.
A camada de abstração: a única decisão a tomar já
Não precisam de escolher um caminho no primeiro dia, mas precisam de decidir não se comprometer. Uma camada fina de abstração entre o vosso código e o fornecedor do modelo é o seguro mais barato do projeto:
| O que a camada contém | Porque é que importa |
|---|---|
| Uma interface única para as chamadas ao modelo | Mudar de fornecedor passa a ser a alteração de um ficheiro, não uma reescrita |
| Encaminhamento por tipo de tarefa | Permite enviar tarefas baratas para um modelo barato sem mexer na lógica |
| Registo uniforme de entrada, saída e custo | Sem ele não há dados para decidir daqui a três meses |
| Validação da saída | Permite trocar de modelo sem alterar o contrato de saída |
Os custos que não estão na folha de cálculo
Uma comparação entre construir e comprar feita numa folha de cálculo tende a pesar preço de licença contra custo de computação e a falhar três custos que realmente decidem o desfecho: o tempo até ao mercado, o custo de oportunidade de uma equipa que constrói em vez de vender, e a manutenção ao longo de anos. As publicações até 2026 relatam que as organizações que construíram capacidade de IA à medida sem a validarem primeiro contra uma opção pronta a usar perderam tempo considerável antes de descobrirem que a direção estava errada.
Do outro lado, comprar para sempre cria dependência de um fornecedor único e retira à organização a capacidade de melhorar aquilo que a distingue. O equilíbrio prático é quase sempre híbrido: comprar a base e construir por cima a camada onde vive a vantagem competitiva — os dados, a recuperação, as regras de negócio e a interface — e não o modelo em si.
A sequência recomendada
- Definir a unidade de trabalho e o critério de sucesso antes de escolher qualquer tecnologia.
- Verificar a lente regulatória. Se eliminar caminhos, todo o resto fica sem efeito.
- Fazer uma prova de conceito sobre uma opção pronta a usar mesmo estando convencidos de que vão construir. É barato e cria uma referência.
- Construir a camada de abstração e o registo logo no primeiro dia.
- Voltar à decisão ao fim de noventa dias com custo por unidade real, taxa de sucesso e distribuição de tarefas.
Esse acompanhamento, da definição da unidade de trabalho até à escolha do caminho, é exatamente o que cabe nas nossas áreas de especialização.
Perguntas frequentes
Qual é a diferença prática entre afinação e recuperação a partir de uma base de conhecimento?
A recuperação acrescenta informação atual ao prompt no momento da execução; a afinação altera o comportamento do próprio modelo. Para conhecimento organizacional que muda, a recuperação é quase sempre a escolha correta. A afinação serve para mudanças de estilo, de formato ou uma tarefa estreita, não para injetar factos.
Quantos exemplos anotados exige realmente a afinação?
A ordem de grandeza aceite é de muitos milhares de exemplos de qualidade para uma tarefa estreita. O fator determinante não é a quantidade mas a qualidade e a representatividade: mil exemplos limpos da vossa própria produção valem mais do que dezenas de milhares de exemplos sintéticos.
Uma camada de abstração não acrescenta complexidade desnecessária?
Uma camada fina que apenas unifica a chamada, o registo e a validação custa alguns dias de desenvolvimento. O custo de não a ter aparece no dia em que precisam de mudar de fornecedor, encaminhar tarefas baratas para um modelo barato ou explicar de onde veio uma fatura.
Quando é que treinar um modelo de raiz faz sentido?
Quase nunca, a não ser que o próprio modelo seja o produto que vendem, ou que detenham dados proprietários de dimensão única num domínio que os modelos gerais não cobrem. Para a maioria das organizações, o custo excede o benefício em ordens de grandeza.
Como se sabe que chegou a altura de passar de comprar para construir?
Quando três condições se verificam em conjunto: o custo mensal de comprar ultrapassou o custo anual de engenharia e manutenção da alternativa, a tarefa estabilizou e deixou de mudar, e têm dados de produção suficientes para treinar e medir. Duas em três não chegam.