Engenharia de grafos: quando os agentes deixam de ser uma ferramenta e passam a ser uma organização
Engenharia de grafos: quando os agentes deixam de ser uma ferramenta e passam a ser uma organização
Durante grande parte da actual corrida à inteligência artificial, a discussão concentrou-se nos modelos: mais parâmetros, mais contexto, melhor raciocínio, melhores benchmarks e novas capacidades. Mas à medida que os modelos começam a utilizar ferramentas, executar código, consultar sistemas externos e trabalhar durante períodos mais longos, surge um problema diferente.
Já não basta perguntar qual é o melhor modelo.
É preciso perguntar como construir um sistema capaz de transformar esse modelo em trabalho fiável.
É neste contexto que começa a ganhar relevância a chamada engenharia de grafos: uma forma de estruturar agentes, ferramentas, dados, verificações e decisões humanas como componentes explícitos de um sistema, em vez de concentrar toda a lógica num único prompt ou num agente monolítico.
Astra mostra por que razão o problema já não está apenas no modelo
Um exemplo recente vem da própria OpenAI. A empresa revelou a 7 de Agosto que avaliações internas do Astra, um dos seus próximos modelos, demonstraram avanços suficientemente significativos em programação agentiva e cibersegurança para que deixasse de ser possível excluir a hipótese de o sistema atingir o nível de capacidades cibernéticas considerado “Critical” no Preparedness Framework da empresa.
Isto não significa que a OpenAI tenha confirmado que Astra possui essas capacidades, nem que tenha anunciado uma data de lançamento e posteriormente cancelado a disponibilização do modelo.
O que aconteceu foi mais específico.
A empresa decidiu pausar actividades internas relacionadas com Astra que ainda não cumpriam novos requisitos de segurança, enquanto reforça os mecanismos utilizados durante o desenvolvimento e avaliação do sistema.
Entre essas medidas estão ambientes de teste isolados, restrições ao acesso à rede e a ferramentas, execução em sandbox, maior protecção dos pesos do modelo e sistemas adicionais de monitorização e detecção.
A OpenAI implementou também monitorização universal das acções consideradas de risco nas aplicações agentivas de Astra, incluindo mecanismos que analisam o raciocínio do modelo e podem desencadear uma revisão ou interrupção da actividade.
Há ainda uma distinção importante: a própria OpenAI afirma explicitamente que Astra não esteve envolvido na exploração da Hugging Face.
O episódio não demonstra, portanto, que Astra tenha provocado um incidente. Mostra antes que, quando os modelos começam a adquirir capacidade para agir autonomamente sobre sistemas reais, a segurança deixa de poder depender apenas do comportamento esperado do próprio modelo. É necessário controlar também o ambiente onde ele opera.
Do outro lado da corrida está a escala
Enquanto a OpenAI enfrenta o problema de controlar capacidades cada vez mais poderosas, a ByteDance parece estar a explorar outra dimensão da corrida: a escala.
Segundo uma reportagem do Financial Times citada pela Reuters, a empresa estará a pré-treinar um modelo com até 10 biliões de parâmetros. O projecto encontrar-se-á ainda numa fase inicial de treino, que poderá prolongar-se durante três a seis meses antes das etapas posteriores de desenvolvimento.
A ByteDance não confirmou publicamente os detalhes e a Reuters também não conseguiu verificar de forma independente a informação.
Por isso, os 10 biliões de parâmetros devem ser entendidos como uma informação reportada sobre um projecto em desenvolvimento e não como uma especificação de um produto pronto a chegar ao mercado.
Existe ainda outro cuidado importante: Mais parâmetros não significam automaticamente melhor inteligência.
Arquitectura, dados de treino, quantidade de parâmetros activos, técnicas de inferência, ferramentas disponíveis e qualidade do pós-treino podem tornar dois modelos com dimensões aparentemente semelhantes extremamente diferentes na prática.
A corrida aos biliões de parâmetros continua a ser tecnologicamente interessante, mas começa a explicar cada vez menos aquilo que realmente determina a utilidade de um sistema de IA.
Do prompt ao grafo
A evolução dos sistemas agentivos pode ser vista como uma sucessão de camadas.
Primeiro surgiu a engenharia de prompts: escrever melhores instruções para obter melhores respostas.
Depois ganhou importância a engenharia de contexto: decidir que documentos, memória, dados e informação devem estar disponíveis quando o modelo toma uma decisão.
A seguir veio o harness, a infraestrutura que envolve o modelo e determina que ferramentas pode utilizar, que permissões possui, como executa código e de que forma são tratados os resultados.
Quando queremos que o sistema trabalhe durante mais tempo, aparece outra peça: o loop.
Um agente observa o estado do problema, decide o que fazer, executa uma acção, observa o resultado e repete o processo até atingir uma condição de conclusão ou falha.
Mas tarefas suficientemente complexas raramente cabem bem num único ciclo. É aí que entra o grafo.
Um loop controla um agente. Um grafo controla o trabalho.
A diferença é relativamente simples.
Um loop descreve o comportamento repetido de um agente:
observar → planear → agir → verificar → repetir.
Um grafo descreve como diferentes componentes desses processos se relacionam.
Pode definir que agente recebe determinada tarefa, que dados lhe são entregues, que ferramenta pode utilizar, para onde deve enviar o resultado, quem o verifica e o que deve acontecer caso essa verificação falhe.
Em vez de existir apenas uma sequência de decisões produzidas por um modelo, passam a existir nós e ligações explicitamente definidos. Um nó pode ser um modelo de linguagem. Mas também pode ser uma função tradicional, uma consulta a uma base de dados, uma ferramenta, uma regra determinística ou uma decisão humana.
As ligações determinam quais os caminhos que o trabalho pode seguir.
Isto já está a entrar nas ferramentas de produção
Esta arquitectura deixou de ser apenas uma ideia conceptual.
O Agent Development Kit da Google, por exemplo, permite actualmente construir workflows baseados em grafos onde agentes de IA coexistem com funções determinísticas, ferramentas e código tradicional.
Os fluxos podem incluir ramificações condicionais, gestão de estado e regras explícitas sobre a passagem de informação entre os diferentes nós. O ADK oferece também estruturas sequenciais, paralelas e em loop para problemas onde um grafo completo seria desnecessário.
A vantagem não está simplesmente em desenhar caixas e setas. Está em retirar parte da lógica de funcionamento de dentro dos prompts e transformá-la em arquitectura verificável. Se um documento tiver de ser validado antes de ser publicado, essa regra pode fazer parte do fluxo. Se determinada ferramenta só puder ser utilizada depois de uma autorização, essa passagem pode ser explicitamente bloqueada. Se uma etapa falhar, o sistema pode regressar a um ponto anterior em vez de permitir que o erro continue a contaminar as etapas seguintes.
Nem tudo precisa de vários agentes
A popularidade dos sistemas multiagente cria, contudo, uma tentação: transformar qualquer tarefa num pequeno organigrama digital.
Na maioria dos problemas simples isso apenas acrescenta complexidade. Se existe um objectivo claro, os passos são essencialmente sequenciais e toda a informação necessária pode ser mantida dentro do mesmo processo, um único agente com um bom loop pode ser suficiente.
Os grafos tornam-se mais interessantes quando aparecem outras necessidades:
- tarefas especializadas que beneficiam de agentes diferentes;
- trabalho que pode decorrer em paralelo;
- utilização de modelos distintos para funções distintas;
- ferramentas com diferentes níveis de permissão;
- decisões condicionais;
- validação independente;
- necessidade de isolar falhas.
O objetivo não deve ser maximizar o número de agentes... deve sim ser minimizar a probabilidade de o sistema inteiro falhar quando um deles se engana.
Uma redacção de notícias como exemplo
Imagine um sistema automatizado de produção editorial.
Um primeiro agente pesquisa informação. Outro compara as afirmações encontradas com fontes independentes. Um terceiro escreve o artigo. Um verificador analisa números, datas e afirmações factuais. Finalmente, determinadas matérias podem exigir aprovação humana antes da publicação.
O valor desta arquitectura não está em dizer que existem “cinco agentes de IA”.. está nas regras entre eles.
O redactor não deveria poder transformar uma afirmação não confirmada num facto apenas porque apareceu no material de pesquisa. O verificador deveria conseguir rejeitar uma alegação. Uma rejeição deveria devolver a tarefa à pesquisa. E assuntos suficientemente incertos deveriam poder terminar numa decisão humana em vez de obrigar o sistema a inventar uma conclusão.
É isto que o grafo torna explícito: quem pode fazer o quê, com que informação e em que condições o trabalho pode avançar.
Grafos permanentes e grafos criados para uma tarefa
Existe ainda outra distinção útil... é que alguns grafos podem representar processos relativamente permanentes.
Uma empresa pode manter agentes especializados em pesquisa, suporte técnico, programação, segurança ou análise financeira, com responsabilidades e permissões definidas. Esse é essencialmente um grafo organizacional.
Mas um sistema também pode construir temporariamente uma estrutura específica para resolver determinado problema. Uma tarefa complexa pode ser dividida em várias investigações paralelas. Alguns ramos podem desaparecer quando deixam de ser necessários. Outros podem subdividir-se se aparecer nova informação. No final, os resultados podem voltar a convergir para uma única decisão. Este seria um grafo de trabalho, existente apenas enquanto aquela tarefa estiver activa.
A terminologia ainda não constitui uma taxonomia universal da indústria, mas a distinção é útil para pensar sobre sistemas agentivos: algumas relações são estáveis; outras devem nascer e desaparecer juntamente com o problema.
O perigo de transformar “engenharia de grafos” em mais um termo de marketing
Como aconteceu anteriormente com “agentes”, “RAG” ou “engenharia de prompts”, existe o risco de a expressão começar a ser aplicada a praticamente qualquer sistema com várias chamadas a um modelo. Mas ligar três prompts através de algumas condições não cria automaticamente uma arquitectura robusta. Um sistema agentivo sério precisa de muito mais!
As interfaces entre componentes devem ter formatos de dados claros. As permissões precisam de ser limitadas. As decisões importantes devem ficar registadas. As tarefas necessitam de limites de custo e de iteração. Os resultados críticos precisam de validação... e, sobretudo, o sistema deve saber como falhar.
Se um agente não encontra informação suficiente, isso deve ser um estado válido. Se uma ferramenta deixa de responder, deve existir um caminho alternativo. Se dois agentes chegam a conclusões incompatíveis, o sistema não deve simplesmente escolher a resposta que apareceu por último. E se uma decisão ultrapassa o nível de autonomia permitido, deve existir uma forma clara de a encaminhar para uma pessoa.
A próxima geração de IA será também um problema de arquitectura
Os modelos continuarão a melhorar. Alguns terão mais contexto. Outros serão maiores. Outros conseguirão programar, utilizar computadores ou executar tarefas que hoje ainda necessitam de supervisão constante.
Mas quanto maior for a capacidade dos modelos para agir, menos razoável será confiar apenas na qualidade da resposta produzida por uma única chamada. O desafio passa a estar também na construção do sistema à sua volta... prompt, contexto, ferramentas, permissões, memória, loops, verificadores, agentes especializados e intervenção humana passam a ser partes de uma mesma arquitectura. É aí que a engenharia de grafos se torna interessante, não porque todas as aplicações precisem de dezenas de agentes, mas porque sistemas suficientemente complexos precisam de uma forma explícita de representar como o trabalho circula, como é verificado e o que acontece quando alguma coisa corre mal.
A evolução da IA está, assim, a mudar de uma pergunta relativamente simples — “o que consigo pedir a este modelo?” — para uma muito mais importante: “que sistema preciso de construir para confiar no trabalho que ele produz?”
