A armadilha do modelo único
Todos os grandes fornecedores de IA querem que acredite que o seu modelo de topo é a resposta certa a qualquer pergunta. Essa crença é comercialmente cómoda para eles e tecnicamente falsa para si.
Um modelo que se destaca em raciocínio jurídico de contexto longo não é o certo para produzir uma legenda de dez palavras. Um modelo com visão de ponta é excessivo — e provavelmente demasiado caro — para um trabalho em lote que reformata JSON estruturado. Um modelo cujo preço está otimizado para débito pode ser a pior escolha possível quando precisa de uma resposta em dois segundos.
Quando constrói sobre um único modelo, não está a escolher a melhor ferramenta. Está a escolher a melhor ferramenta disponível dentro de uma restrição artificial. Com o tempo essa restrição acumula-se: paga a mais nas tarefas simples, fica aquém nas complexas, e quando esse fornecedor tem uma avaria ou um aumento de preço, todo o seu produto para.
Capacidades, não nomes
A abstração útil não é «que modelo», mas «de que capacidades precisa este pedido». Essa pergunta tem uma resposta precisa.
Uma mensagem de conversa com uma captura anexada precisa de visão. Um passo de fluxo que chama uma API externa precisa de ferramentas. Um assistente de código que deve verificar a própria saída precisa de execução de código. Um canal noturno de resumo que não precisa de ser rápido pode usar preços em lote; um assistente dentro do produto com alguém à espera, não.
Quando enumera primeiro os requisitos de capacidade, a seleção de modelo torna-se um problema de filtrar e ordenar. Dado um conjunto exigido — digamos texto, visão e saída estruturada — encontra todos os modelos que suportam os três e depois ordena-os por qualidade e preço para o contexto atual do pedido. Essa ordenação pode mudar de pedido para pedido consoante o que a pessoa está a fazer e como estão os seus fundos.
É exatamente isto que o canal de encaminhamento do ToRun faz. O modo (Conversa, Código, Imagem, Investigação e outros) corresponde a um conjunto de capacidades. O conjunto filtra o catálogo de modelos. A ordenação por preço e qualidade escolhe o vencedor. O resultado é que pode usar DeepSeek para extração estruturada em grande volume, Claude ou modelos de classe GPT-4 para raciocínio matizado, Google Gemini para trabalho documental de contexto longo e um modelo de imagem especializado para geração — tudo a partir da mesma superfície de produto, sem escrever a lógica de despacho.
O recurso não é um extra simpático
As avarias de fornecedor não são casos raros. Acontecem várias vezes por mês em toda a indústria. Se o seu produto depende de um único fornecedor e a API dele se degrada, o seu produto degrada-se com ela.
Uma cadeia de recurso é o mínimo operacional: quando o modelo principal devolve um erro transitório para um pedido, a plataforma repete-o com o melhor modelo apto seguinte. Isso pressupõe que a camada de encaminhamento já saiba que modelos são aptos — que é precisamente o que o encaminhamento por capacidades fornece.
O recurso tem outro benefício menos óbvio: mantém previsível o seu comportamento de faturação. Se o modelo de primeira escolha estiver temporariamente acima de um limite de uso, desviar para o modelo apto seguinte mantém o custo dentro do intervalo sem mostrar um erro a quem usa o sistema.
A conclusão prática
Quando avaliar plataformas de IA, faça duas perguntas: como escolhe um modelo para cada pedido, e o que acontece quando esse modelo não está disponível ou fica demasiado caro?
Se a resposta a qualquer uma delas for «usa sempre o modelo X», é um cheiro arquitetural. Os modelos disponíveis hoje não são os melhores modelos que existirão daqui a seis meses. Surgem novos fornecedores. Os preços mexem-se. As fronteiras de capacidade deslocam-se. Uma arquitetura que trata a escolha do modelo como um problema de encaminhamento — e não como uma decisão de configuração — envelhece melhor, custa menos ao longo do tempo e degrada-se com mais elegância sob pressão.
Um modelo é um ponto de partida. Uma camada de encaminhamento é a verdadeira fundação.