O sucesso na construção de agentes de IA depende do mapeamento de papéis e fluxos de trabalho e do estabelecimento de salvaguardas, como supervisão humana e verificações de erros.
Na nossa primeira parte, delineamos estratégias-chave para aproveitar os agentes de IA para melhorar a eficiência empresarial. Expliquei como, ao contrário dos modelos de IA autônomos, os agentes refinam iterativamente as tarefas usando contexto e ferramentas para melhorar resultados, como a geração de código. Também discuti como sistemas de múltiplos agentes promovem a comunicação entre departamentos, criando uma experiência de usuário unificada e impulsionando a produtividade, resiliência e atualizações mais rápidas.
O sucesso na construção desses sistemas depende do mapeamento de papéis e fluxos de trabalho, bem como do estabelecimento de salvaguardas, como supervisão humana e verificações de erros, para garantir uma operação segura. Vamos mergulhar nesses elementos críticos.
Salvaguardas e autonomia
Os agentes implicam autonomia, portanto, várias salvaguardas devem ser incorporadas a um agente dentro de um sistema de múltiplos agentes para reduzir erros, desperdícios, exposição legal ou danos quando os agentes estão operando autonomamente. Aplicar todas essas salvaguardas a todos os agentes pode ser excessivo e representar um desafio de recursos, mas recomendo considerar cada agente no sistema e decidir conscientemente quais dessas salvaguardas eles precisariam. Um agente não deve ser permitido operar autonomamente se qualquer uma dessas condições for atendida.
Condições de intervenção humana explicitamente definidas
Acionar qualquer uma de um conjunto de regras pré-definidas determina as condições sob as quais 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, ser aplicadas usando código determinístico externo ao agente. Uma dessas regras, no caso de um agente de compras, seria: “Todas as compras devem ser primeiro verificadas e confirmadas 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 com o papel de verificar comportamentos arriscados, antiéticos ou não conformes. O agente pode ser forçado a sempre verificar todos ou certos elementos de seu comportamento contra um agente de salvaguarda e não prosseguir a menos que o agente de salvaguarda retorne um sinal verde.
Incerteza
Nosso laboratório publicou recentemente 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 a confabular (comumente conhecido como alucinações), dar preferência a uma certa saída pode tornar um agente muito mais confiável. Aqui também, há um custo a ser pago. Avaliar a incerteza requer que geremos múltiplas saídas para o mesmo pedido, 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 desligamento
Pode haver momentos em que precisamos parar todos os processos baseados em agentes autônomos. Isso pode ser porque precisamos de consistência ou detectamos um comportamento no sistema que precisa parar enquanto descobrimos o que está errado e como consertá-lo. 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, portanto, recomenda-se 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 ser totalmente integrados a aplicativos e APIs. Isso pode levar um tempo e requer algumas iterações para acertar. Minha recomendação é adicionar uma ferramenta genérica de espaço reservado aos agentes (tipicamente nós folha na rede) que simplesmente emitiria um relatório ou uma ordem de trabalho, contendo ações sugeridas a serem tomadas manualmente em nome do agente. Esta é uma ótima maneira de iniciar e operacionalizar sua rede de agentes de maneira á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 usado em software tradicional. A boa notícia, no entanto, é que já estamos acostumados a testar tais sistemas, pois temos operado organizações e fluxos de trabalho impulsionados por humanos desde o início da industrialização.
Enquanto os exemplos que mostrei 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 agir como o ponto de entrada para o sistema. Devemos usar dividir e conquistar, e primeiro testar subconjuntos do sistema começando a partir de vários nós dentro da hierarquia.
Também podemos empregar IA generativa para criar 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. Esses 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
Um equívoco comum com a IA generativa é que ela melhora quanto mais você a usa. Isso é obviamente errado. Os LLMs são pré-treinados. Dito isso, eles podem ser ajustados para enviesar seu comportamento de várias maneiras. Uma vez que um sistema de múltiplos agentes tenha sido elaborado, podemos optar por melhorar seu comportamento tomando 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 espiral descendente, o que significa que ocasionalmente uma consulta pode nunca terminar, com agentes falando perpetuamente entre si. Isso requer algum tipo de mecanismo de tempo limite. Por exemplo, podemos verificar o histórico de comunicações para a mesma consulta, e se estiver crescendo muito ou detectarmos 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 atual da arte para LLMs não nos permite passar instruções longas e detalhadas a agentes e esperar que eles as sigam todas, o tempo todo. Além disso, mencionei que esses sistemas podem ser inconsistentes?
Uma mitigação para essas situações é o que chamo de granularização: dividir agentes em múltiplos agentes conectados. Isso reduz a carga em cada agente e torna os agentes mais consistentes em seu comportamento e menos propensos a entrar em uma espiral descendente. (Uma área interessante de pesquisa que nosso laboratório está empreendendo é na automação do processo de granularização.)
Outro problema comum na forma como os 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 bastante complexo de papéis e responsabilidades. Minha sugestão nesses casos é considerar o fluxo de trabalho como um pipeline, com um agente completando parte do trabalho e, em seguida, passando para o próximo.
Os sistemas de múltiplos agentes também têm a tendência de passar o contexto para baixo na cadeia para outros agentes. Isso pode sobrecarregar esses outros agentes, confundi-los e muitas vezes é desnecessário. Sugiro permitir que os agentes mantenham seu próprio contexto e redefinam o contexto quando sabemos que estamos lidando com um novo pedido (meio que como as sessões funcionam para sites).
Finalmente, é importante notar que há uma barra relativamente alta para as capacidades do LLM usado como cérebro dos agentes. LLMs menores podem precisar de muita engenharia de prompt ou ajuste fino para atender aos pedidos. A boa notícia é que já existem vários agentes comerciais e de código aberto, embora relativamente grandes, que atendem a essa barra.
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 que esses sistemas, embora mais rápidos que os humanos, não serão tão rápidos quanto os sistemas de software que estamos acostumados.