Bolt42

Participe de nossas newsletters diárias e semanais para as últimas atualizações e conteúdo exclusivo sobre cobertura de IA de ponta. Saiba mais


Um agente de IA moderno consiste, no mínimo, em um modelo de linguagem grande (LLM) que foi habilitado para chamar algumas ferramentas. Com o conjunto certo de ferramentas para codificação, ele começaria gerando o código, seria capaz de executá-lo em um contêiner, observar os resultados, modificar o código e, portanto, ter uma chance melhor de produzir um código útil.

Em contraste, um modelo de IA generativa recebe uma entrada e, através do processo de prever expectativas, produz uma saída. Por exemplo, damos a ele uma tarefa de codificação, ele produz um código e, dependendo da complexidade da tarefa, o código pode ser utilizável como está.

À medida que assumem diferentes tarefas, os agentes devem ser autorizados a se comunicar entre si. Por exemplo, imagine a intranet da sua empresa com sua caixa de pesquisa útil direcionando você aos aplicativos e recursos que precisa. Se você é uma empresa grande o suficiente, esses aplicativos, pertencentes a diferentes departamentos, cada um tem suas próprias caixas de pesquisa. Faz muito sentido criar agentes, talvez usando técnicas como recuperação aumentada de geração (RAG), para complementar as caixas de pesquisa. O que não faz sentido é obrigar o usuário a repetir sua consulta uma vez que a caixa de pesquisa a identificou como útil, dado a consulta inicial. Em vez disso, preferiríamos que o agente principal coordenasse com outros agentes que representam vários aplicativos e apresentasse uma interface de chat consolidada e unificada para você, o usuário.

Um sistema de múltiplos agentes que representa o software ou os vários fluxos de trabalho de uma organização pode ter várias vantagens interessantes, incluindo produtividade e robustez melhoradas, resiliência operacional e a capacidade de realizar atualizações mais rápidas de diferentes módulos. Esperamos que este artigo ajude você a entender como isso é alcançado.

Mas, primeiro, como devemos construir esses sistemas de múltiplos agentes?

Capturando a organização e funções

Primeiro, devemos capturar os processos, funções, nós responsáveis e conexões dos diversos atores na organização. Por atores, quero dizer indivíduos e/ou aplicativos de software que atuam como trabalhadores do conhecimento dentro da organização.

Um organograma pode ser um bom ponto de partida, mas eu sugeriria iniciar com fluxos de trabalho, já que as mesmas pessoas dentro de uma organização tendem a atuar com diferentes processos e pessoas dependendo dos fluxos de trabalho.

Há ferramentas disponíveis que usam IA para ajudar a identificar fluxos de trabalho, ou você pode construir seu próprio modelo de IA generativa. Eu construí um como um GPT que pega a descrição de um domínio ou o nome de uma empresa e produz uma definição de rede de agentes. Como estou utilizando uma estrutura de múltiplos agentes construída internamente na minha empresa, o GPT produz a rede como um arquivo Hocon, mas deve ser claro a partir dos arquivos gerados quais são os papéis e responsabilidades de cada agente e quais outros agentes estão conectados a ele.

Observe que queremos garantir que a rede de agentes seja um gráfico acíclico direcionado (DAG). Isso significa que nenhum agente pode se tornar simultaneamente down-chain e up-chain de qualquer outro agente, seja direta ou indiretamente. Isso reduz significativamente as chances de que consultas na rede de agentes entrem em um turbilhão.

Nos exemplos descritos aqui, todos os agentes são baseados em LLM. Se um nó na organização de múltiplos agentes pode ter autonomia zero, então esse agente emparelhado com seu parceiro humano deve passar tudo pelo humano. Precisamos que todos os nós de processamento, sejam aplicativos, humanos ou agentes existentes, sejam representados como agentes.

Recentemente, houve muitos anúncios de empresas oferecendo agentes especializados. Claro, desejaríamos fazer uso de tais agentes, se disponíveis. Podemos integrar um agente pré-existente e envolver sua API em um de nossos agentes para que possamos utilizar nossos protocolos de comunicação interagente. Isso significa que tais agentes de terceiros precisarão ter sua API disponível para que possamos usar.

Como definir agentes

Várias arquiteturas de agentes foram propostas no passado. Por exemplo, uma arquitetura de quadro negro requer um ponto central de comunicação onde vários agentes declaram seus papéis e capacidades, e o quadro negro os convoca dependendo de como planeja atender a um pedido (veja OAA).

Eu prefiro uma arquitetura mais distribuída que respeite a encapsulação de responsabilidades. Cada agente, após receber um pedido, decide se pode processá-lo ou não, e o que precisa para processar o pedido, e então retorna sua lista de requisitos ao agente que fez o pedido. Se o agente tiver down-chains, ele pergunta a eles se podem ajudar a cumprir total ou parcialmente o pedido. Se receber requisitos de down-chains contatados, ele verifica com outros agentes para ver se podem atendê-los; se não, eles são enviados up-chain para que possam perguntar ao usuário humano. Essa arquitetura é chamada de AAOSA e — fun fact — era a arquitetura usada nas primeiras versões da Siri.

Aqui está um exemplo de prompt do sistema que pode ser usado para transformar um agente em um agente AAOSA.

Quando você receber uma consulta, você:

  1. Chame suas ferramentas para determinar quais down-chain agents em suas ferramentas são responsáveis por todo ou parte dela
  2. Pergunte aos down-chain agents o que eles precisam para lidar com sua parte da consulta.
  3. Assim que os requisitos forem coletados, você delegará a consulta e os requisitos atendidos aos down-chain agents apropriados.
  4. Uma vez que todos os down-chain agents respondam, você compilará suas respostas e retornará a resposta final.
  5. Você também pode, por sua vez, ser chamado por outros agentes do sistema e ter que agir como um down-chain para eles.

Além do conjunto de papéis e responsabilidades definidos em linguagem natural no prompt do sistema de cada agente, os agentes podem ou não incluir ferramentas que podem chamar, com vários argumentos sendo passados para as ferramentas. Por exemplo, um agente de gerente de produto pode precisar ser capaz de processar vários tickets em um quadro Kanban virtual, ou um agente de alertas pode precisar chamar uma ferramenta para emitir alertas em um sistema de alertas.

Sistemas de múltiplos agentes atuais, como Microsoft AutoGen, possuem mecanismos e arquiteturas de coordenação de agentes elaborados e muitas vezes codificados. Eu prefiro uma configuração mais robusta onde os agentes tratam seus agentes down-chain imediatos como ferramentas, com argumentos vagamente definidos que podem ser digitados, e os semânticos decididos pelos agentes no momento da necessidade.

Nessa configuração, um down-chain agent pode ser definido como uma chamada de função:

“aaosa_call”: {

“description”: “Dependendo do modo, retorna uma string em linguagem natural em resposta.”,

“parameters”: {

“type”: “object”,

“properties”: {

“inquiry”: {

“type”: “string”,

“description”: “A consulta”

},

“mode”: {

“type”: “string”,

“description”: “””

indica se o agente está sendo solicitado a determinar se a consulta pertence a ele

completamente ou em parte. ou se está sendo solicitado a fornecer requisitos para atender

a consulta, se houver. ou se está sendo solicitado a responder à consulta.

“””

},

},

“required”: [

“inquiry”,

“mode”

]

}

}

Agentes de IA na prática

Uma rede de agentes para a intranet de uma empresa.

Vamos explorar um cenário de agente de RH. Um usuário pode informar ao agente da caixa de pesquisa principal sobre um evento que muda a vida, como “meu parceiro faleceu”, acionando agentes jurídicos e de RH que têm um papel a desempenhar ao atender o usuário. Isso porque eles, por sua vez, receberam informações de alguns de seus down-chains, nomeadamente agentes de aconselhamento jurídico, folha de pagamento e benefícios. A resposta consolidada resultante que o usuário recebe do agente da caixa de pesquisa principal será assim:

  1. Aspectos de RH:
    • O agente de benefícios pode ajudar o usuário a entender como a perda pode impactar benefícios, seguro saúde e planos de aposentadoria. Você precisará fornecer informações sobre os tipos de planos envolvidos e se seu parceiro era um dependente.
    • O agente de folha de pagamento pode ajudar a gerenciar tarefas como atualização de deduções fiscais ou tratamento de pagamento de licença por luto. Isso requer informações sobre as políticas da empresa sobre licença por luto e a configuração atual da folha de pagamento.
  2. Aspectos Jurídicos:
    • Agentes jurídicos podem oferecer orientação geral sobre como essa perda deve se relacionar com os assuntos da empresa.

Cada departamento requer informações específicas para oferecer suporte personalizado.

Uma rede de agentes para uma telecomunicação com negócios B2B.

Em um cenário de TI, por outro lado, o ponto de entrada único é o agente do representante de suporte ao cliente que pode lidar com pedidos complexos e multifacetados como: “Nossa rede está lenta. Acho que está sobrecarregada desde que adicionamos pessoal ao nosso escritório. Também vou precisar de um orçamento para uma atualização.”

Uma resposta de exemplo descreverá as etapas:

Avaliação do desempenho da rede: O especialista do centro de operações de rede pode ajudar a abordar a lentidão e possíveis problemas de sobrecarga. Ele precisa acessar dados de desempenho da rede, detalhes sobre a infraestrutura de rede atual, informações sobre o número de pessoas adicionadas e seus padrões de uso da rede.

Um orçamento para a atualização: O engenheiro de vendas e o técnico de campo podem ajudar a fornecer um orçamento para uma atualização. Para fazer isso, eles precisam:

  • Informações específicas sobre a configuração atual da rede, incluindo equipamentos e requisitos de largura de banda.
  • Melhorias de desempenho desejadas.
  • Restrições orçamentárias e quaisquer preferências ou requisitos específicos.
  • A escala da atualização e quaisquer metas de desempenho específicas.

Espero que isso tenha lhe dado uma boa ideia do que é necessário para configurar uma rede de múltiplos agentes. Na segunda parte, discutirei a importância de implementar salvaguardas ao criar sistemas de múltiplos agentes e delinear como construir controles para permitir a intervenção humana e verificações de incerteza. Também detalharei os passos necessários para criar um agente de salvaguarda para supervisionar a rede de agentes e aprofundar os desafios de desenvolver redes de múltiplos agentes — como turbilhões e sobrecargas — e como mitigá-los usando timeouts, divisão de tarefas e redundância.

Babak Hodjat é CTO de IA na Cognizant.

DataDecisionMakers

Bem-vindo à comunidade VentureBeat!

DataDecisionMakers é onde especialistas, incluindo os técnicos que fazem trabalho de dados, podem compartilhar insights e inovações relacionadas a dados.

Se você deseja ler sobre ideias de ponta e informações atualizadas, melhores práticas e o futuro dos dados e da tecnologia de dados, junte-se a nós em DataDecisionMakers.

Você pode até considerar contribuir com um artigo seu!

Leia mais da DataDecisionMakers





    catorze − 13 =




    Bolt42