Machine Learning clássico está tendo um momento de redenção que poucos esperavam. 😄
Com o boom dos AI Agents, muita gente assumiu que o trabalho do dia a dia nessa área seria basicamente escrever prompts, ajustar instruções e torcer para o LLM fazer mágica. A narrativa popular dizia que os grandes modelos de linguagem haviam tornado obsoleto tudo que veio antes deles, incluindo anos de conhecimento acumulado em algoritmos, features e pipelines de dados. Parecia que o futuro seria apenas um grande modelo conversando com o mundo.
Mas quem está na prática construindo plataformas agênticas de verdade sabe que a história é bem diferente. O dia a dia de quem trabalha com sistemas agênticos sofisticados envolve muito mais do que ajustar o comportamento de um LLM. Existe uma camada inteira de lógica, decisão e filtragem que precisa ser construída com cuidado, e é justamente aí que o Machine Learning clássico entra em cena com força total.
Tem um texto que circulou recentemente no Towards Data Science que resume bem essa virada. Uma engenheira que trabalha com uma plataforma de IA agêntica sofisticada contou que passa boa parte do seu tempo construindo classificadores com CatBoost e ajustando isolation forests, e não fazendo prompt engineering como se poderia imaginar. Segundo ela, colegas às vezes se surpreendem quando ouvem que ela ainda constrói esse tipo de modelo no meio de uma stack tão moderna. Isso não é um caso isolado, é um padrão que está se repetindo em times de engenharia ao redor do mundo, onde a complexidade real dos sistemas agênticos exige uma combinação de abordagens, e não uma substituição total de uma pela outra.
Isso levanta uma questão bem interessante: se os AI Agents dependem tanto de ferramentas para funcionar, por que não dar a eles modelos clássicos de ML como ferramentas poderosas? A resposta curta é que faz todo sentido, e a resposta longa é exatamente o que vamos explorar aqui, desde o que define um AI Agent até as duas principais abordagens arquiteturais para conectar seus modelos ao agente, passando pelos motivos concretos que fazem o ML clássico ainda ser indispensável. 🚀
O que é um AI Agent, afinal?
Antes de entrar nas arquiteturas e nas combinações técnicas, vale alinhar o conceito. Um AI Agent significa combinar LLMs e outras ferramentas de software para criar fluxos de trabalho com pouca ou nenhuma intervenção humana, orquestrando qualquer número de modelos ou ferramentas. Não é simplesmente um chatbot com memória ou um assistente virtual com acesso à internet, é um sistema que percebe o contexto, decide o que fazer e executa ações para atingir um objetivo.
- E-BOOK GRATUITO
Um guia prático para avaliar, comparar e implementar inteligência artificial com clareza — sem desperdício de tempo ou dinheiro.
Pare de contratar ferramentas sem direção. Criamos um método estruturado para decidir qual IA realmente faz sentido para o seu negócio.
Entrega em PDF no seu e-mail · Sem spam · LGPD
🔒 Seus dados são protegidos conforme a LGPD. Você pode descadastrar a qualquer momento.
Os LLMs, como GPT, Claude ou Gemini, funcionam como a interface central de muitos desses agentes modernos. Eles são responsáveis por traduzir prompts humanos para a linguagem da máquina, interpretar os resultados que as ferramentas devolvem e decidir qual ferramenta acionar em cada momento. Mas aqui está o ponto crucial: o LLM sozinho não executa nada por conta própria. Como sempre reforçamos, um LLM é apenas um modelo gerador de tokens, prevendo a próxima palavra ou frase de um texto com base no contexto que recebeu. Ele precisa de ferramentas para interagir com o mundo real, e essas ferramentas podem ser chamadas de API, scripts, buscas em banco de dados e, cada vez mais, modelos de Machine Learning clássico encapsulados como funções acessíveis ao agente.
Essa arquitetura baseada em ferramentas é o que transforma um LLM em um agente funcional. E vale lembrar que mesmo os chatbots que usamos no dia a dia, como ChatGPT, Gemini e Claude, dependem desse tipo de encadeamento, combinando a interface do LLM com recuperação de dados, busca na web, calculadoras matemáticas e outros recursos. O modelo de linguagem não precisa saber fazer tudo por conta própria, ele precisa saber quando chamar quem. Isso abre espaço para uma divisão de responsabilidades muito mais eficiente, onde cada componente do sistema faz o que faz de melhor, e o LLM orquestra essa sinfonia com base em linguagem natural e raciocínio contextual.
Por que dar modelos clássicos de ML ao seu agente
Um aspecto central de todo o ecossistema de IA agêntica é o Tooling. Seu agente precisa ter acesso a ferramentas para conseguir completar tarefas que vão além das funções básicas do LLM. Muitas dessas ferramentas hoje, no ambiente corporativo, são de recuperação e organização de dados, bancos de grafos, bases de conhecimento RAG, construção e validação de consultas, e por aí vai. Mas existe uma categoria de ferramenta que muita gente esquece: os próprios Classical Models.
Pense num agente projetado para análise imobiliária. Se você quer descobrir o preço justo de mercado de um imóvel, basta dar o endereço ao agente. Ele pode usar uma ferramenta de recuperação via API para buscar detalhes da propriedade e depois passar esses dados formatados para um modelo de regressão que gera uma estimativa de preço. Você até poderia, em teoria, pedir para o LLM estimar o valor sozinho. Mas isso é questionável e até arriscado por uma série de motivos.
- Precisão dos números: um LLM é particularmente ruim em qualquer tarefa que exija calcular um número significativo, porque ele está adivinhando, e não fazendo um cálculo baseado em evidências empíricas. Um modelo clássico bem treinado será muito mais preciso e confiável.
- Interpretabilidade: com o LLM adivinhando, você tem pouquíssima explicabilidade. Sabemos que LLMs tendem a ser uma caixa preta, o que limita muito sua capacidade de avaliar o caminho até a estimativa. Com um modelo clássico, você identifica as decisões tomadas e valida contra o conhecimento de especialistas.
- Custo: rodar um LLM fica caro muito rápido por conta dos tokens. Se você tem muitos casos para processar, os preços viram um problema real. Já rodar um classificador ou uma regressão é incrivelmente leve e barato, mesmo em altos volumes.
- Controle e ajuste fino: você não controla o treinamento ou o tuning do LLM, a menos que faça fine tuning de um modelo fundacional, o que exige muito mais dados e habilidade especializada, e ainda deixa problemas de interpretabilidade.
- Controle dos seus dados: seus dados podem estar saindo do ambiente controlado e sendo acessados por um provedor terceiro de LLM, o que gera risco.
- Controle da infraestrutura: com um LLM, você não tem autoridade sobre a gestão de infraestrutura, então uma queda do provedor terceiro cria risco para o seu negócio.
Claro que construir um modelo clássico exige habilidades diferentes de apenas soltar um LLM numa tarefa. Você precisa entender bem seus dados, estar preparado para fazer engenharia de features com conhecimento de domínio, e ter computação e dados suficientes para treinar o modelo. Se não tiver dados rotulados, ficará limitado a aprendizado não supervisionado ou terá que criar seus próprios rótulos. Felizmente, existe muito material disponível sobre como construir esses modelos, avaliá-los com rigor e monitorá-los depois da implantação.
Como conectar seu modelo ao agente
Convencido a testar essa ideia? Antes de começar, há algumas escolhas de arquitetura para considerar. Como seu modelo e seu agente vão interagir? Existem basicamente duas abordagens principais.
Chamadas diretas
Talvez o jeito mais rápido de colocar tudo para rodar seja deixar o agente ter o modelo como uma ferramenta que ele chama diretamente. É a forma do exemplo da análise imobiliária: o agente aciona o modelo para uma inferência sob demanda com base num prompt. Para isso funcionar, seu agente precisa estar preparado para formatar corretamente as requisições ao modelo clássico. Ele precisa entender para que serve aquele modelo, quando chamá-lo e quando usar outra coisa. Isso significa documentar claramente o propósito e as capacidades do modelo, mas se você já constrói IA agêntica, essa é uma tarefa familiar.
Do lado da saída, a resposta do modelo precisa ser estruturada de forma que o agente consiga processá-la bem. Simplesmente devolver um resultado numérico pode não resolver, porque o agente vai precisar de informação contextual para interpretar aquilo e usar da melhor forma. Uma boa prática é usar f-strings para montar descrições em texto como parte da inferência, indicando, por exemplo, quais foram as features mais importantes do modelo, qual a probabilidade do resultado e assim por diante. Devolver só uma probabilidade limita a capacidade do agente de interpretar a saída e produzir uma resposta útil para o usuário final.
Acesso via banco de dados
Outra opção é fazer com que o modelo não seja uma ferramenta direta do agente, mas um provedor de dados de contexto. Você pode pré-calcular as inferências rodando seu modelo clássico como um job agendado e armazenar esses resultados na solução de armazenamento que o agente tem acesso. Em vez de o agente fazer uma chamada inicial de inferência direto para uma API de modelo, ele escreve uma consulta e a passa para o banco de dados.
Se você tem um conjunto finito de casos para os quais poderia precisar da inferência, essa é uma boa solução. Por exemplo, se você tem 500 indivíduos no banco de dados e o agente precisa recuperar informações de saúde financeira sobre eles, você pode usar um modelo de credit scoring e pré-calcular a capacidade de crédito de cada um, deixando pronto para o agente buscar em tempo de execução junto com os demais dados. Dependendo da sua infraestrutura, isso pode reduzir latência e repetição, funcionando como um cache de resultados.
Essa abordagem cria requisitos diferentes para a chamada e a recuperação em relação à chamada direta de ferramenta. Se você pré-calcula as inferências e as disponibiliza via banco de dados, o agente precisa saber que esses resultados existem. Se ele não estiver ciente da tabela ou do conteúdo disponível, não vai usá-los quando for apropriado. Talvez você já tenha a infraestrutura para informar ao agente o que o banco contém no seu prompt engineering, o que economiza esforço. Sobre o formato dos resultados, os requisitos são parecidos com os da chamada direta: ter uma descrição em texto é uma boa escolha, porque o agente precisa interpretar o que recupera, independentemente da origem.
Tooling: a cola que une tudo isso
Falar em integração entre AI Agents, LLMs e Classical Models sem falar em Tooling é como falar em construção sem mencionar as ferramentas do canteiro de obras. O ecossistema de ferramentas disponível hoje para engenheiros que trabalham com sistemas agênticos evoluiu muito nos últimos anos, e parte dessa evolução foi justamente em direção a facilitar a integração de modelos heterogêneos dentro de um mesmo pipeline. Frameworks modernos já oferecem abstrações que permitem registrar qualquer função como uma ferramenta disponível para o agente, o que significa que um modelo de ML serializado pode se tornar uma ferramenta agêntica com poucas linhas de código.
O ponto mais importante sobre Tooling nesse contexto é que ele não é apenas uma questão técnica, é uma decisão de design que afeta diretamente a capacidade do sistema de evoluir. Quando você constrói um pipeline agêntico com boas abstrações de ferramentas, adicionar um novo modelo de Machine Learning, trocar um classificador por uma versão mais recente ou experimentar uma arquitetura diferente se torna uma operação incremental e não uma refatoração completa. Isso é especialmente relevante hoje, quando o ritmo de evolução tanto dos LLMs quanto dos algoritmos clássicos continua acelerado e a capacidade de iterar rápido é o que separa times que entregam valor de times que ficam presos em dívida técnica. 🛠️
Receba o melhor conteúdo de inovação em seu e-mail
Todas as notícias, dicas, tendências e recursos que você procura entregues na sua caixa de entrada.
Ao assinar a newsletter, você concorda em receber comunicações da Método Viral. A gente se compromete a sempre proteger e respeitar sua privacidade.
O melhor dos dois mundos
Os modelos clássicos de ML foram a capacidade de ponta em muitas indústrias por mais de uma década antes dos LLMs entrarem em cena, dando às pessoas insights sobre dados que elas não conseguiriam de outra forma. Esse poder não deve ser descartado, mas sim combinado com as capacidades dos LLMs. Podemos aproveitar as forças do LLM, convertendo linguagem humana em linguagem de máquina, encadeando diferentes chamadas de ferramentas e recuperando resultados delas, e ainda usar modelos clássicos dentro desse framework para fazer o trabalho para o qual um LLM simplesmente não é apropriado.
A barreira de entrada é a habilidade de criar modelos clássicos de alta qualidade, algo que, infelizmente, não é tão glamouroso quanto boa parte do trabalho relacionado a IA hoje em dia. Mas vale o esforço, pelas vantagens claras: precisão, interpretabilidade, custo e controle. Para quem quer colher esses resultados na prática, vale a pena revisitar ferramentas como XGBoost, LightGBM e scikit-learn, além do próprio CatBoost, e ver a diferença com os próprios olhos.
A combinação de AI Agents com LLMs e Classical Models não é uma contradição, é uma evolução natural. O campo está aprendendo, na prática, que inteligência artificial robusta raramente vem de uma única abordagem aplicada a tudo. Vem da combinação inteligente das ferramentas certas para os problemas certos, orquestradas por sistemas que sabem quando usar cada uma delas.
