Agregadores de LLM: como escolher modelos gratuitos que realmente funcionam e não distorcer o resultado

Se em um projeto surge a necessidade de escolher um LLM, na maioria das vezes você segue o caminho mais óbvio: uma grande lista de modelos, você escolhe um, envia a solicitação. Funciona a curta distância. A longa distância começa a quebrar.

Onde a Abordagem Simples Falha

Os problemas não aparecem na interface, mas no comportamento dos provedores e dos próprios modelos:

• Modelos free instáveis — listados como gratuitos, mas respondem de forma instável, desaparecem durante downtime do provedor
• Modelos desaparecem — estava disponível ontem, hoje o provedor o removeu ou o fechou para novos usuários
• Degradação de qualidade — formalmente vivo, mas serve apenas para demo ou tarefas simples
• Desajuste entre frontend e backend — a lista na interface está desatualizada por um ou dois dias, enquanto o backend conhece uma realidade diferente
• Erros e redirecionamentos — você solicitou um modelo, recebeu um erro, ou a resposta veio de um modelo completamente diferente

O principal problema: a interface não sabe qual modelo realmente respondeu. O usuário selecionou Claude 3.5, mas a resposta veio do Gemini — e ele não saberá disso. Isso cria confusão: se a qualidade da resposta não corresponder ao modelo selecionado, o usuário perde a confiança.

Um Loop Rígido de Engenharia em Vez de um Catálogo

A solução é construída não através de uma lista infinita, mas através do controle no backend:

Passo 1: limpeza da lista. O backend recebe uma lista bruta de modelos do provedor, filtra — mantém apenas opções free adequadas, remove as instáveis, elimina duplicatas. Você pode adicionar health checks — periodicamente consulta cada modelo e verifica se está vivo.

Passo 2: um modelo por marca. Mesmo que o OpenAI tenha 5 modelos free na lista, o frontend recebe um, o mais estável. Isso simplifica a escolha para o usuário e reduz a chance de acabar em um modelo ruim.

Passo 3: fallback entre marcas. Durante uma solicitação real — se o primeiro modelo retornar um erro, automaticamente tente o segundo, depois o terceiro. O usuário não saberá sobre a falha, para ele será apenas um pouco mais lento.

Passo 4: honestidade na resposta. Retorne não apenas o texto gerado, mas também `actual_model` — qual modelo realmente o gerou. Agora a interface pode dizer honestamente ao usuário: "A resposta é do GPT 4o mini, porque o modelo principal estava em downtime."

"O problema não é como mostrar lindamente uma lista de modelos.

O problema é como construir um sistema que escolha modelos free vivos e não minta sobre o resultado" — essa é a essência da tarefa.

Isso transforma um catálogo instável em um loop previsível. O provedor removeu um modelo — o backend notará isso na próxima verificação e atualizará a lista no frontend. O modelo caiu — o fallback entra em ação, o usuário recebe uma resposta de outro provedor.

O Que Isso Significa

Escolher um LLM deixa de ser uma tarefa de UI e se torna uma tarefa de engenharia — com limpeza de dados, health checks, lógica de fallback e rastreamento honesto. Para o produto, significa confiabilidade e menos perguntas de suporte. Para o usuário — a escolha funciona, as respostas chegam, a interface não mente.