Introdução aos agentes de IA (parte 2): Autonomia, salvaguardas e armadilhas

No nosso primeiro artigo, abordamos estratégias chave para aproveitar os agentes de IA para melhorar a eficiência empresarial. Expliquei como, ao contrário dos modelos de IA independentes, os agentes refinam iterativamente as tarefas usando contexto e ferramentas para aprimorar resultados como a geração de código. Também discuti como sistemas de múltiplos agentes fomentam a comunicação entre departamentos, criando uma experiência unificada para o usuário e impulsionando a produtividade, resiliência e atualizações mais rápidas.

O sucesso na construção desses sistemas depende do mapeamento de funções e fluxos de trabalho, bem como do estabelecimento de salvaguardas, como supervisão humana e verificações de erro, para garantir uma operação segura. Vamos explorar esses elementos críticos.

Salvaguardas e autonomia

Agentes implicam autonomia, por isso várias salvaguardas devem ser incorporadas a um agente dentro de um sistema de múltiplos agentes para reduzir erros, desperdícios, exposições legais ou danos quando os agentes estão operando de forma autônoma. Aplicar todas essas salvaguardas a todos os agentes pode ser excessivo e representar um desafio de recursos, mas recomendo fortemente considerar cada agente no sistema e decidir conscientemente quais dessas salvaguardas eles precisariam. Um agente não deve ser permitido operar de forma autônoma se qualquer uma dessas condições for atendida.

Condições de intervenção humana explicitamente definidas

Disparar qualquer uma de um conjunto de regras pré-definidas determina as condições em que um humano precisa confirmar algum comportamento do agente. Essas regras devem ser definidas caso a caso e podem ser declaradas no prompt do sistema do agente — ou em casos mais críticos, serem aplicadas usando código determinístico externo ao agente. Uma dessas regras, no caso de um agente de compras, seria: “Toda compra deve ser primeiramente verificada e confirmada por um humano. Chame sua função ‘check_with_human’ e não prossiga até que ela retorne um valor.”

Agentes de salvaguarda

Um agente de salvaguarda pode ser emparelhado com um agente que verifica comportamentos arriscados, antiéticos ou não conformes. O agente pode ser forçado a sempre checar todos ou certos elementos de seu comportamento contra um agente de salvaguarda e não prosseguir a menos que o agente de salvaguarda dê luz verde.

Incerteza

Nosso laboratório recentemente publicou um artigo sobre uma técnica que pode fornecer uma medida de incerteza para o que um modelo de linguagem grande (LLM) gera. Dada a propensão dos LLMs para confabular (comumente conhecidos como alucinações), dar preferência a uma determinada saída pode tornar um agente muito mais confiável. Aqui também, há um custo a ser pago. Avaliar incerteza exige gerar múltiplas saídas para a mesma solicitação para que possamos classificá-las com base na certeza e escolher o comportamento que tem a menor incerteza. Isso pode tornar o sistema lento e aumentar os custos, portanto, deve ser considerado para agentes mais críticos dentro do sistema.

Botão de disengajamento

Pode haver momentos em que precisamos parar todos os processos baseados em agentes autônomos. Isso pode ser porque precisamos de consistência ou porque detectamos um comportamento no sistema que precisa ser interrompido enquanto descobrimos o que está errado e como corrigir. Para fluxos de trabalho e processos mais críticos, é importante que esse desligamento não resulte em todos os processos parando ou se tornando totalmente manuais, então é recomendado que um modo de operação de fallback determinístico seja provisionado.

Ordens de trabalho geradas por agentes

Nem todos os agentes dentro de uma rede de agentes precisam estar totalmente integrados em aplicativos e APIs. Isso pode levar um tempo e demandar algumas iterações para ser feito corretamente. Minha recomendação é adicionar uma ferramenta genérica de espaço reservado aos agentes (normalmente nós folha na rede) que simplesmente emitiria um relatório ou uma ordem de trabalho, contendo ações sugeridas a serem realizadas manualmente em nome do agente. Esta é uma ótima maneira de iniciar e operacionalizar sua rede de agentes de forma ágil.

Testes

Com agentes baseados em LLM, estamos ganhando robustez à custa da consistência. Além disso, dada a natureza opaca dos LLMs, estamos lidando com nós de caixa-preta em um fluxo de trabalho. Isso significa que precisamos de um regime de teste diferente para sistemas baseados em agentes do que o utilizado em software tradicional. A boa notícia, porém, é que já estamos acostumados a testar tais sistemas, pois temos operado organizações e fluxos de trabalho dirigidos por humanos desde o início da industrialização.

Enquanto os exemplos que apresentei acima têm um único ponto de entrada, todos os agentes em um sistema de múltiplos agentes têm um LLM como seu cérebro, e assim podem atuar como o ponto de entrada para o sistema. Devemos usar a estratégia de dividir e conquistar, e primeiro testar subconjuntos do sistema começando a partir de vários nós dentro da hierarquia.

Podemos também empregar IA generativa para gerar casos de teste que podemos executar contra a rede para analisar seu comportamento e forçá-la a revelar suas fraquezas.

Finalmente, sou um grande defensor do sandboxing. Tais sistemas devem ser lançados em menor escala dentro de um ambiente controlado e seguro primeiro, antes de serem gradualmente implementados para substituir fluxos de trabalho existentes.

Ajuste fino

Uma ideia comum sobre IA generativa é que ela melhora quanto mais você a utiliza. Isso é obviamente errado. Os LLMs são pré-treinados. Dito isso, eles podem ser ajustados para direcionar seu comportamento de várias maneiras. Uma vez que um sistema de múltiplos agentes tenha sido elaborado, podemos optar por melhorar seu comportamento analisando os logs de cada agente e rotulando nossas preferências para construir um corpus de ajuste fino.

Armadilhas

Sistemas de múltiplos agentes podem entrar em um ciclo sem fim, o que significa que ocasionalmente uma consulta pode nunca terminar, com agentes conversando perpetuamente entre si. Isso requer algum tipo de mecanismo de timeout. Por exemplo, podemos verificar o histórico de comunicações sobre a mesma consulta e, se ele estiver crescendo muito ou se detectarmos um comportamento repetitivo, podemos encerrar o fluxo e começar de novo.

Outro problema que pode ocorrer é um fenômeno que chamarei de sobrecarga: esperar demais de um único agente. O estado da arte atual para LLMs não nos permite dar a agentes instruções longas e detalhadas e esperar que eles as sigam o tempo todo. Além disso, já mencionei que esses sistemas podem ser inconsistentes?

Uma mitigação para essas situações é o que chamo de granularização: quebrar agentes em múltiplos agentes conectados. Isso reduz a carga sobre cada agente e torna os agentes mais consistentes em seu comportamento e menos propensos a entrar em um ciclo sem fim. (Uma área de pesquisa interessante que nosso laboratório está empreendendo é na automação do processo de granularização.)

Outro problema comum na forma como sistemas de múltiplos agentes são projetados é a tendência de definir um agente coordenador que chama diferentes agentes para completar uma tarefa. Isso introduz um ponto único de falha que pode resultar em um conjunto de papéis e responsabilidades bastante complexo. Minha sugestão nesses casos é considerar o fluxo de trabalho como um pipeline, com um agente completando parte do trabalho e depois passando para o próximo.

Sistemas de múltiplos agentes também tendem a passar o contexto para outros agentes. Isso pode sobrecarregar esses outros agentes, causar confusão e muitas vezes é desnecessário. Sugiro permitir que os agentes mantenham seu próprio contexto e redefinam o contexto quando soubermos que estamos lidando com uma nova solicitação (como funciona com sessões para websites).

Finalmente, é importante notar que há uma barreira relativamente alta para as capacidades do LLM usado como cérebro dos agentes. LLMs menores podem precisar de muito ajuste fino ou engenharia de prompt para cumprir solicitações. A boa notícia é que já existem diversos agentes comerciais e de código aberto, embora relativamente grandes, que atendem os critérios.

Isso significa que custo e velocidade precisam ser uma consideração importante ao construir um sistema de múltiplos agentes em escala. Além disso, as expectativas devem ser definidas de modo que esses sistemas, embora mais rápidos que humanos, não serão tão rápidos quanto os sistemas de software que estamos acostumados.

Babak Hodjat é CTO de IA na Cognizant.