Multiagentes de IA: Melhor que conhecer o caminho de uso, é trilhá-lo!

Bem-viiindos! Depois de um tempo de descanso e planejamento para 2025, nossa coluna está de volta. E hoje, eu quero poder abordar o já tão falado “mundo dos agentes da IA”.

Um agente de IA é como uma entidade ou programa que pode realizar um conjunto de ações fim a fim, seguindo orientações ou outros tipos de dados para realizar tarefas específicas. Podem variar entre sistemas simples, como sensores no seu smartwatch e que podem monitorar sinais vitais e realizar ações de acionamento a partir da leitura de sensores, até sistemas mais complexos, como carros autônomos que trafegam pelo trânsito. As principais características dos agentes incluem autonomia, “programabilidade”, reatividade e proatividade.

Por definição, um agente de IA pode automatizar ações que uma pessoa poderia realizar, mas neste contexto, podendo poupar tempo e esforços.

Observando que é uma opção para automatizações, os agentes de IA podem falhar, ou seja, a supervisão e intervenção humana são necessárias, mesmo quando empregados a tarefas simples.

Um pouco sobre a evolução dos Agentes de IA

Lendo o artigo Agents Are Not Enough de Chirag Shah e Ryen W. White, achei interessante compartilhar como foi organizada a evolução dos agentes.

Tivemos cinco períodos distintos no desenvolvimento de agentes, cada um marcado por uma arquitetura ou tecnologia central e pelos desafios enfrentados rumo ao sucesso generalizado, como segue.

• Agentes de IA Pioneiros: A ideia de agentes de IA vem dos anos 1950, com a IA simbólica. Exemplos iniciais como o General Problem Solver (GPS) tentavam replicar o raciocínio humano através da lógica simbólica. Contudo, esses agentes se depararam com dificuldades ao tentar lidar com a complexidade da vida real, dependentes de regras predefinidas e com pouca capacidade de adaptação.
• Sistemas Especialistas: Nos anos 1980, surgiram sistemas especialistas como o MYCIN e o DENDRAL, que utilizavam conhecimento específico para tomar decisões. Embora fossem eficazes em áreas limitadas, esses sistemas se mostravam frágeis e incapazes de generalizar além do que foram programados. Além disso, o intenso esforço manual necessário para a engenharia de conhecimento tornava esses sistemas impraticáveis para aplicações mais amplas.
• Agentes Reativos: Os anos 1990 trouxeram os agentes reativos, que respondiam a estímulos do ambiente, mas sem modelos internos. A arquitetura de integração de Rodney Brooks exemplificava essa abordagem, priorizando interações em tempo real em vez de raciocínios complexos. No entanto, esses agentes não conseguiam planejar ou aprender com experiências passadas, o que limitava sua utilidade em ambientes dinâmicos.
• Sistemas Multiagentes: Os Sistemas Multiagentes (MAS) introduziram a ideia de múltiplos agentes interagindo, cada um com papéis específicos. Apesar do potencial em resolver problemas distribuídos, desafios de coordenação, comunicação e escalabilidade se tornaram evidentes. Gerir a interação entre os agentes muitas vezes resultava em ineficiências e comportamentos imprevisíveis.
• Arquiteturas Cognitivas: Arquiteturas cognitivas como SOAR e ACT-R tentaram modelar a cognição humana, integrando percepção, memória e raciocínio. Apesar de seus designs sofisticados, enfrentaram problemas de escalabilidade e desempenho em tempo real. A complexidade dessas arquiteturas frequentemente resultava em altos custos computacionais e limitações em suas aplicações práticas.

Inspiração: Multiagentes

Antes de exemplificar na prática sobre agentes de IA, eu gostaria de compartilhar uma rápida reflexão:

• Eu sempre gostei de aprender sobre novos assuntos, o que invariavelmente, me faz buscar profundidade sobre o tema em questão, para poder atingir o nível necessário para aplicação do meu senso crítico.

Essa paixão por aprender me proporcionou entender e conhecer muitas ferramentas, técnicas e temas, as quais faço uso ou emprego em meus desafios profissionais e pessoais. E por ser uma paixão, eu queria oferecer isso a todos que tivessem a mesma paixão por aprender. E foi assim que me tornei professor!

Me tornando professor, eu percebi que transmitir conhecimento era um novo desafio, entretanto, poder ensinar sobre um tema, me permitia aprender ainda mais, pois sumarizar o conhecimento e torná-lo acessível é um exercício que testava meu nível de domínio.

Ok, mas onde tudo isso vai parar? Foi então que percebi que eu precisava dar um novo passo: trilhar o caminho! O que pode ser chamado de experimentação, também.

Sendo assim, vamos lá, me acompanhem nos próximos parágrafos.

Minha intenção era: degustar, sentir, experimentar, saborear e digerir essa nova forma de aplicar Agentes de IA. 😉

Primeiramente, com base em um problema ou necessidade latente a ser resolvido, eu defini qual o conjunto de soluções eu precisava selecionar, considerando as restrições existentes – dimensionamento do meu laptop e tecnologias que eu soubesse operar – e minhas restrições autoimpostas – para buscar custo zero. Neste cenário, comecei a listar requisitos funcionais e não funcionais, e exemplo de:

• Opensource ou serviços free?
• Qual o modelo de linguagem mais adequado?
• Quais as funcionalidades necessárias?
• Code, LowCode ou NoCode?

Com isso, pude viabilizar a primeira versão do “Meu Multiagentes de IA”. E nos últimos 7 meses venho aprendendo, testando e evoluindo no desenvolvimento e aplicação do conceito, desde vez na prática!

Figura 1: NoCode Pipeline, especializado para a aplicação GenAI.

DNA da solução de multiagentes

Para poder alcançar os objetivos dessa primeira milha da jornada, organizei alguns passos. Abaixo vou tentar simplificar:

1. Primeiro passo: definir o problema ou necessidade a ser resolvido!

A evolução dos programas de geração de código-fonte – assistentes de criação de uma aplicação –, também chamados Co-Piloto tem ocupado espaço nas discussões como a próxima evolução no desenvolvimento de software, com potencial fato-gerador na eficiência na esteira de desenvolvimento de software.

Com base em pesquisas no Github, Google, Discord, Kaggle, Youtube, entre outros, encontrei o SWE-bench, que organiza e centraliza iniciativas ligadas ao tema.

Figura 2: ranking de aplicações para desenvolvimento de software.

As soluções são realmente muito interessantes, mas eu não precisava de algo tão completo. Além disso, eu queria ter controle no passo a passo e processo criativo.

Dado contexto e considerando que sou professor e executivo de dados e inteligência artificial, fiz minha escolha:

• Criar meu assistente de construção de solução e pipeline de dados, visando atender as necessidades de ingestão, transformação e utilização de dados para a aplicação pensada e almejada. De maneira prática, eu queria uma aplicação que respondesse a um prompt de entrada, com as instruções que deveriam ser atendidas e, como resultado, gerasse um prompt de saída com os esboços iniciais da aplicação (script python, massa de dados e testes automatizados e documentação de referência).

Como exemplo de prompt de entrada eu poderia escrever algo como: elaborar uma solução de dados que integre e capture os dados do IBGE para enriquecimento de informações para uma região em específico no estado de São Paulo.

Nota: esse é um prompt extremamente simples e serve apenas para exemplificar o conceito. O resultado está diretamente ligado ao nível de detalhe e sua profundidade, ou seja, quanto melhor o prompt de entrada, melhor será o prompt de saída, possivelmente.

1. Segundo passo: definir a solução opensource e a solução free, se necessário.

Definir uma ou mais soluções opensource requer 99% transpiração e 1% inspiração. A comunidade opensource é muito ativa e neste momento o tema IA tem inundado os fóruns de discussão, grupos de meetup, podcasts e vídeos de youtube. Neste cenário, particularmente, eu prefiro entender, testar escolher uma solução da vertical de especialização que pretendo aplicar, ou seja, estava mais interessado em uma solução especializada no tema. Como parte relevante do meu processo de escolha, busquei avaliar o quanto a comunidade vem adotando e contribuindo com a solução (Github).

Os finalistas foram n8n ou Flowise. Acabei optando pelo Flowise por seu foco em solução de IA.

Figura 3: curva de contribuições.

1. Terceiro passo: definir o modelo de linguagem foi uma decisão mais fácil, pois 2024 foi um ano riquíssimo quanto ao lançamento de modelos de linguagem gratuitos, e principalmente, por conta das condições de uso que tenho em meu ambiente operacional, que neste caso era um laptop com processador Intel i7, 16gb de RAM e uma placa de vídeo Nvidia GeForce MX450.

Neste cenário, adotei o llama3:8b (8 bilhões de parâmetros). Este modelo de linguagem é gratuito e se mostrou uma boa opção para ser executado diretamente do meu laptop, ou seja, rodando localmente. Entretanto, o tempo de resposta era alto (demorado), mais por conta das configurações do meu laptop. Felizmente, em Julho/2024 chegou o llama3.1 e atualmente estou utilizando o llama3.2:3b, que já se enquadra como um SLM (small language model), onde o tempo de resposta melhorou.

Para baixar e rodar o llama3 e sucessores, fiz a escolha pelo ollama – plataforma de modelos para IA generativa. Uma vez instalado o llama, via ollama pull [nome do modelo] e/ou ollama run [nome do modelo], o mesmo se tornou acessível via http://localhost:11434.

1. Terceiro passo: fiz o mapeamento das principais funcionalidades necessárias para atender a necessidade que eu queria resolver. Entendendo que seria necessário criar um sistema multiagentes, eu precisava atender a alguns requisitos da aplicação, tais como:

• Orquestrador de agentes, considerando seus papéis e condições para acionamento;
• Controle de estado dos processos/dados do fluxo de orquestração dos agentes;
• Memória de contexto para os agentes;
• Definição da ordem de execução e controle de retorno durante a interação entre os agentes;
• Definição e criação de agentes, seus papéis e responsabilidades;
• Possibilidade de ser acessível/acionável por end-points (API).

Para este conjunto de funcionalidades, agora no quarto passo, passei a utilizar o Flowise como meu NoCode, a qual fiz um fork e integrei o uso a partir do VSCode, com git clone.

Figura 4: open-soource NoCode Flowise, no github.

O Flowise se mostrou uma solução simples e que atendeu muito bem as funcionalidades listadas acima. A documentação se mostrou completa o suficiente para criação do meu primeiro “Hello World” de Multiagentes.

Com o NoCode eu consegui utilizar o llama3.2:3b a partir do ollama.

Figura 5: componente de Chat Models do Flowise, usando llama3.2:3b na laptop (standalone), sem conexão internet.

A partir de agora, após a definição do modelo de linguagem e da ferramenta NoCode, ambos instalados e configurados em meu laptop, foi possível criar e configurar o orquestrador de agentes e definir o papel e responsabilidade de cada agente, como segue abaixo:

Figura 6: fragmento do pipeline Flowise, apresentando os agentes e a funcionalidade de “Condition”, que apoia o orguestrador (Tech_Lead).

• Engenheiro_Dados: Especialista, que domina e utiliza tecnologias como:
  • SQL
  • Python

  Constrói códigos para atender a solução solicitada pelo usuário, sempre enviando seu código para o Code_Reviewer. O processo pode ser considerado como completo após um acionamento de revisão do código pelo Code_Reviewer. Posteriormente deve atender as recomendações do Code_Reviewer, que deve enviar seu código para o Tester.

• Code_Reviewer: Especialista, revisa os códigos criados pelo Engenheiro_Dados. Garante que boas práticas foram seguidas e que o código foi comentado. Deve enviar seu feedback para o Engenheiro_Dados, uma vez.
• Tester: Especialista, domina e utiliza tecnologias como:
  • SQL
  • Python

  Irá coletar o código gerado pelo Engenheiro_Dados e escrever código para geração de testes unitários e integrados. Deve criar instruções para uso dos scripts que irão executar os códigos de teste e é responsável pela geração da massa de testes que será utilizada no código de testes. Depois que você concluir o código de testes unitários e integrados, massa de testes, scripts e as instruções de uso, você deve acionar o Analista_Documentador.

• Analista_Documentador: Especialista, deve coletar os resultados e respostas gerados pelo Engenheiro_Dados e Tester para documentar a solução. A documentação deve ser clara e de simples entendimento.

Por fim, e não menos importante, consegui realizar a utilização e chamada do “Meu Multiagentes de IA” a partir do end-point, que aliás, o Flowise nos dá algumas opções:

Figura 7: gerador de scripts para end-point de integração ou interação a partir de Chatbot.

Enfim, depois de tudo isso, pensei que valeria rodar a aplicação com o prompt exemplo citado mais acima. Com isso, tivemos os resultados do prompt de saída, abaixo (alguns fragmentos):

Figura 8: Prompt de saída a patir do prompt de entrada e interação entre os agentes.

Ufa! E agora? Tranquilize-se, não se preocupe em entender o “como” foi feito, mas sim “o que” foi feito e a “linha de raciocínio” adotada.

Meu interesse com essa jornada, é poder trilhar o caminho que conheço na teoria, para então poder buscar novas perguntas e dar mais um passo em direção a próxima resposta.

Sinta-se a vontade para fazer perguntas, estarei atento 😊