A Anthropic Acaba de Corrigir a Maior Falha da Engenharia de Grafos
AAI LABS
Computing/SoftwareInternet Technology
Transcript
00:00:00Há um novo termo circulando chamado engenharia de grafos, e todo mundo no X está falando sobre isso.
00:00:04Antes dos grafos, era tudo engenharia de loops, onde você entregava um objetivo ao agente e ele trabalhava nisso
00:00:09por conta própria. Mas com grafos, o trabalho é feito mais rápido e cobre muito mais terreno de uma vez do que
00:00:14um loop jamais conseguiria. Mas há um grande problema com eles. Um erro em uma pequena parte do
00:00:18grafo perturba todo o resultado final, e é difícil rastreá-lo porque tudo o que você recebe
00:00:23no final é o resultado acabado. Então a Anthropic acabou de lançar algo que resolve exatamente esse
00:00:27problema e mantém seus grafos funcionando sem falhar. Se você é novo por aqui, somos uma empresa de
00:00:32software, e este é o nosso canal AI Labs, onde mostramos como otimizar seu negócio com IA,
00:00:37e se você não tiver o seu próprio, pode usar essas habilidades para ser pago otimizando para outra pessoa
00:00:42E neste vídeo, vamos abordar a engenharia de grafos para quem ainda não a conhece
00:00:46e lhe dar a solução exata sugerida pela Anthropic. Antes de explicarmos a engenharia de grafos, você
00:00:52precisa entender o que realmente é a engenharia de loops. Se você já sabe, pode pular esta seção.
00:00:56Um loop é basicamente um ciclo de trabalho que você entrega ao agente. Em vez de dar comandos a ele em
00:01:02cada etapa, você diz o objetivo final que ele precisa alcançar, e ele chega lá por conta própria,
00:01:07ajustando-se no caminho. Temos usado bastante isso em nossos próprios fluxos de trabalho. Já temos um vídeo completo
00:01:12sobre engenharia de loops também, onde aprofundamos as diferentes formas de configurá-los, mas os loops
00:01:17estão agora se transformando em algo chamado grafos. O problema dos loops se resume à forma como são construídos.
00:01:22Um loop faz uma parte do trabalho, e então entra uma etapa de verificação para ver se está realmente do jeito que deveria
00:01:27estar. Assim que passa, a próxima etapa começa. Tudo roda em linha reta, então cada etapa fica ali
00:01:32esperando pela etapa anterior, mesmo quando as duas não têm nada a ver uma com a outra. A engenharia de grafos
00:01:37corrige exatamente isso. Em vez de rodar em linha reta, um grafo divide a tarefa principal em partes menores
00:01:42e cada parte ganha seu próprio agente. A primeira coisa que você ganha com isso é velocidade, porque vários
00:01:47agentes cobrem o trabalho ao mesmo tempo, em vez de um único agente ralar em tudo sozinho. E dividir o
00:01:52trabalho assim também reduz um pouco os custos, porque você pode escolher em qual modelo cada um
00:01:56vai rodar. Assim, você para de queimar seu modelo mais caro nas partes que nunca precisaram de tanta
00:02:01inteligência em primeiro lugar. Mas esse é o custo por agente, não o custo geral. Um grafo queima muito mais
00:02:07tokens do que um único agente jamais queimará, porque você tem um conjunto inteiro rodando ao mesmo tempo em vez de apenas um.
00:02:12Se estiver usando grafos, espere atingir seus limites muito antes do habitual, então você não
00:02:17pode realmente configurar isso com os planos de $20 do ClaudeCode e do Codex. Agora, se você tem usado o ClaudeCode,
00:02:22isso provavelmente não é totalmente novo para você, pois já viu um grafo que é o fluxo de trabalho
00:02:27dinâmico. Um fluxo de trabalho dinâmico pega a tarefa entregue e a distribui por um conjunto de subagentes,
00:02:33que é basicamente o que um grafo faz. Agora, antes de entrarmos nas formas que um grafo pode ter, você precisa
00:02:38saber o que realmente o compõe. Todo grafo é construído de duas coisas: nós e arestas. Um nó é
00:02:44basicamente uma única tarefa do trabalho maior que você entregou, e ele roda por conta própria. Ele é um agente
00:02:49que realiza uma tarefa em sua própria janela de contexto isolada e reporta de volta. O que conecta todas essas tarefas separadas
00:02:55é a aresta. Uma aresta controla como os dados se movem de um nó para o outro, para que o resultado de um agente
00:03:01chegue ao agente certo no momento certo. Portanto, cada nó precisa estar vinculado ao restante do grafo
00:03:06de alguma forma. Você pode ver isso em um conjunto de agentes revisando o mesmo trabalho. Nenhum deles
00:03:10espera pelo outro. Mas todos começaram do mesmo trabalho, e cada um dos seus relatórios alimenta
00:03:15o mesmo lugar no final, então é disso que um grafo é feito. Agora, aqui estão os formatos em que essas peças
00:03:20são organizadas. A primeira é uma forma que já mostramos neste canal, e nós erramos o nome
00:03:25na época. Chamamos de loop, porque isso foi antes da engenharia de grafos sequer existir. Mas
00:03:30o que tínhamos na verdade era um grafo que estávamos colocando em loop, e o formato dele era um losango. Uma tarefa no
00:03:35topo se divide em vários subagentes rodando lado a lado, e depois todos se afunilam novamente em um único
00:03:41agente que reúne tudo o que encontraram em uma só resposta. Depois, há o grafo de convergência em barreira (fan-in at a barrier),
00:03:46e esse é o formato que você quer quando algo precisa ser julgado de vários ângulos ao mesmo tempo. A parte de divergência (fan-out)
00:03:51envia o mesmo problema para um conjunto de agentes, e cada um olha para ele através de uma perspectiva diferente.
00:03:56Nada avança até que cada um desses agentes tenha relatado de volta, e só então ele
00:04:00vai e executa as correções deles. Existem muitos outros formatos também. Mas cada uma dessas formas se apoia
00:04:05na mesma coisa: a verificação. Se você não configurar essas verificações corretamente, cada agente que vem
00:04:10depois estará apenas construindo em cima de um erro. Mas antes de falarmos sobre verificação, seria ótimo se você
00:04:15se inscrevesse no canal e deixasse o seu like. Esse pequeno gesto de apoio faz uma grande diferença para nós.
00:04:20Assim que você roda uma frota inteira de agentes, as coisas dão errado de maneiras que nunca acontecem com apenas um.
00:04:25O maior problema é apenas a quantidade de trabalho. Eles estão todos rodando ao mesmo tempo, então uma pilha enorme
00:04:30de dados volta de uma só vez, e isso é muito difícil de revisar no final. O outro problema é que
00:04:34você não consegue ver o que aconteceu. Quando algo dá errado, você não tem como saber o que causou o erro.
00:04:39Agora, todos os agentes verificam o que quer que escrevam, quer você peça ou não. Se você está trabalhando com código,
00:04:44isso significa apenas que o agente roda seus testes e captura os erros que retornam. Mas isso só pega erros
00:04:49maiores. Ainda não verifica como o código foi escrito, e isso é importante porque se o Claude
00:04:53continuar escrevendo assim, causará problemas no futuro. Existem algumas ferramentas integradas
00:04:58para isso no Claude code também. A primeira é a skill de verificação, que pega o código do início
00:05:03ao fim e confirma se ele realmente se comporta como deveria. A segunda é o encadeamento de ferramentas, que
00:05:08é basicamente o agente rodando ferramentas diferentes para verificar. O Claude já sabe rodar as ferramentas que
00:05:13verificam seu trabalho, então ele lê os erros que retornam e os corrige sozinho. Ele pode descobrir os
00:05:18comandos exatos do seu projeto por conta própria também. Mas escrevê-los no seu arquivo Claude.md economiza o trabalho
00:05:24de descobri-los toda vez. E a terceira é a skill de revisão de código, que verifica o código
00:05:29em relação a um conjunto de padrões. Nem todo agente vem com uma, mas você pode pedir ao seu agente para construir
00:05:33uma para você caso o seu não tenha. Mas a verificação que realmente funciona melhor é aquela que você mesmo configura,
00:05:38em vez de confiar totalmente nas coisas integradas. Portanto, a maneira mais rápida de criar uma skill que verifica
00:05:44seu trabalho é o plugin criador de skills no Claude code. Você também pode usar essa skill do Claude code no
00:05:49Codex. Você roda o comando do plugin, pesquisa por skill creator e o instala. A partir daí,
00:05:54você tem duas opções. Pode instalá-lo no escopo do usuário, o que significa que ele estará lá não importa em qual
00:05:58pasta esteja trabalhando. Ou pode instalá-lo apenas para o projeto em que está trabalhando agora.
00:06:03Como esta é uma skill que você usará constantemente, escolhemos o escopo do usuário. Depois disso,
00:06:07você recarrega os plugins com o comando de barra e o criador de skills estará pronto para uso. Agora você diz a ele
00:06:12o que deseja criar e esta é a parte em que você descreve o tipo de verificação que realmente
00:06:17procura. Usamos principalmente uma skill de revisão para checar o trabalho concluído com o que pedimos em
00:06:22primeiro lugar. E isso importa muito mais em um grafo porque cada agente vê apenas a sua própria parte.
00:06:28É isso que lhe dá uma maneira de checar essa parte em relação aos requisitos originais. Mas uma skill é
00:06:32tão boa quanto o modelo no qual você a executa. Quando estávamos construindo o sistema de verificação para a
00:06:37UI do nosso site comunitário, rodamos o revisor no Haiku porque é barato e o trabalho parecia simples
00:06:43o suficiente. Ele voltou com uma longa lista de problemas. Julgando apenas pelo número de achados, parecia
00:06:47que tinha feito um ótimo trabalho. Então rodamos exatamente a mesma coisa no Opus e ele apontou muito menos coisas.
00:06:53Isso parecia o pior resultado, até lermos a justificativa. Muito do que o Haiku tinha relatado
00:06:58era algo que tínhamos deixado lá de propósito. Então a maioria das descobertas foi completamente desnecessária.
00:07:03O Opus percebeu isso pelo código ao redor, algo que o Haiku perdeu completamente. Então a revisão barata
00:07:08não nos economizou nada, porque agora a própria revisão precisava ser revisada. Agora coloque isso dentro
00:07:13de um grafo onde todo um conjunto de nós está verificando seu próprio trabalho com essa mesma skill. Você teria
00:07:18agentes queimando tempo e tokens corrigindo coisas que nunca estiveram quebradas. E porque isso acontece através
00:07:23de agentes separados ao mesmo tempo, você não teria como saber quem começou o problema.
00:07:27Portanto, o modelo que você escolhe não decide apenas a qualidade da revisão, ele decide a qualidade
00:07:31de todo o grafo. O nó que faz o julgamento é o único lugar onde economizar tokens custa
00:07:37tudo. A outra coisa que você tem que decidir é como e quando essa skill é invocada. E isso
00:07:41as divide em três tipos. Mas antes de aprofundarmos nos tipos, uma palavra do nosso patrocinador.
00:07:46Se você já extraiu dados em tempo real da web, sabe que fazer scraping é uma verdadeira dor de cabeça, onde você acaba
00:07:51lutando contra CAPTCHAs e limites de requisições, brigando com proxies e corrigindo layouts que quebram no
00:07:56momento em que você lança. É por isso que usamos a SERP API, que resolve todos esses problemas para que você foque em construir.
00:08:01É uma única chamada de API: você envia uma requisição e recebe um objeto JSON limpo com exatamente os dados que precisa,
00:08:07com mais de 99,9% de disponibilidade e resposta em cerca de 1,2 segundo. Ao construir agentes de IA, você pode
00:08:14apontar a API do Google Search para um agente que precisa de informações atualizadas ou usar a API do Google Acadêmico para
00:08:20artigos revisados por pares com metadados completos, razão pela qual tantos agentes em produção confiam nela. Comece com
00:08:25250 créditos gratuitos usando o link na descrição ou escaneie o QR code na tela. Obrigado à SERP API por
00:08:32patrocinar este vídeo. O primeiro tipo é autônomo (standalone), e esse é o tipo de skill que só roda quando você
00:08:37mesmo a executa. Uma skill autônoma é feita para se aprofundar em algo que já existe, para que possa
00:08:42revisar adequadamente um resultado final. É por isso que você não quer que ela seja acionada após cada execução. Você estaria
00:08:48queimando tokens em uma revisão pesada de um trabalho que nem sequer foi concluído. Uma que usamos antes é o
00:08:53“thermonuclear code review” do Cursor. Ele distribui um conjunto de agentes e envia cada um pelo código sob
00:08:59um ângulo de segurança diferente. Cada achado volta para um único lugar, para que ele possa trabalhar nas correções
00:09:04junto, e esse é exatamente o tipo de revisão que você só executa quando o app está pronto. Para construir uma dessas, é melhor usar
00:09:10o criador de skills do que apenas pedir para ele fazer, porque o que volta é testado, o que torna mais fácil
00:09:15de confiar. Você diz no prompt qual área deseja revisar e certifica-se de mencionar que a
00:09:20revisão deve ser abrangente, para que ele saiba que você busca uma análise profunda e não rápida. Mas uma skill
00:09:26autônoma não tem utilidade para um nó que ainda está trabalhando, porque você mesmo precisa executá-la. É para isso que as skills
00:09:31incorporadas servem. Uma skill incorporada é acionada como parte do fluxo de trabalho que você já está rodando sem que você precise pedir.
00:09:36Você pode construir uma que é acionada sempre que alguém pede um novo recurso. Ela verifica se
00:09:41cada componente sendo criado segue as regras que você definiu na skill, e não deixa a
00:09:45implementação ser concluída até ter sido verificada em relação a essas regras. Você pode construir skills incorporadas
00:09:50você mesmo, mas não pode pegar uma pré-instalada e fazer com que ela seja invocada automaticamente, como a
00:09:54skill de verificação de que falamos antes. As instruções sob as quais essas skills rodam ficam dentro do produto, e você
00:10:00não pode alterá-las. Para construir a sua própria, dê ao criador de skills um comando dizendo para rodar etapas de verificação
00:10:05após cada implementação de recurso, instruindo-o a testar o recurso do início ao fim para que ele
00:10:10identifique se o novo trabalho quebrou algo que já estava funcionando. O Claude então cria a skill para
00:10:16você e, como o criador de skills a gerou, ela vem com referências e scripts que o próprio criador
00:10:21estruturou e testou como parte do processo. Agora, para verificar um recurso, o Claude usa testes no navegador por
00:10:26padrão, onde ele checa a interface abrindo um navegador Chrome completo, carregando a página e tirando
00:10:31capturas de tela dela. E se você configurou o Puppeteer ou o Playwright, que são basicamente as ferramentas que a maioria das
00:10:36pessoas usa para controlar um navegador automaticamente, eles fazem a mesma coisa. Mas o Chrome é famoso por devorar memória
00:10:41e rodar pesado, e para checar uma página repetidamente dentro de um fluxo de trabalho, ele é lento o suficiente para
00:10:46começar a custar tempo real. Portanto, há uma maneira mais leve de fazer isso, chamada Chrome Headless Shell. É basicamente
00:10:52uma versão enxuta do navegador com todas as partes extras removidas. O agente ainda vai até
00:10:57a página e tira suas capturas de tela da mesma forma. Ele apenas faz tudo isso muito mais rápido do que um Chrome
00:11:02completo faria. Você pode construir isso diretamente na skill de verificação que criar. Assim, cada recurso
00:11:07que o agente constrói é verificado visualmente sem que você precise configurar nada a cada vez. Além disso,
00:11:12a skill que mais usamos em nosso próprio fluxo de trabalho é uma chamada “segunda opinião”, e o motivo é simples.
00:11:17O agente que construiu a coisa é a pior opção possível para revisá-la. Ele está julgando o próprio trabalho com base no
00:11:23mesmo contexto que usou para construí-lo, então ele apenas revisa com base nisso. Uma nova sessão do Claude não viu
00:11:28nada disso. Ela dá uma revisão imparcial e lhe dá uma resposta direta. Agora, o Claude tem um conselheiro
00:11:33integrado que faz algo nessa linha, mas ele lê o chat em que você está atualmente, então herda
00:11:38todo esse mesmo contexto. A segunda opinião é para quando você quer a revisão sem isso. Ela funciona iniciando
00:11:43outra sessão do Claude de dentro daquela que você já está rodando, usando a flag -p. Essa é a
00:11:48flag que dispara uma sessão totalmente separada do Claude code em segundo plano, entregando a ela um comando para
00:11:53trabalhar. No entanto, há algumas coisas que você precisa saber se for usar isso. Como ela está
00:11:57iniciando uma sessão inteiramente separada, leva muito tempo para retornar com uma resposta,
00:12:02e o modelo importa aqui mais do que em qualquer outro lugar, porque o objetivo principal é uma segunda leitura mais inteligente.
00:12:07Portanto, vale a pena dizer ao Claude explicitamente para iniciar essa sessão no Opus. Isso dá a cada nó no seu
00:12:12grafo uma maneira de ter seu trabalho checado por algo que não participou da execução. Mas uma única skill não
00:12:18pode cobrir tudo. Quando você está revisando algo adequadamente, está revisando a partir de vários
00:12:22ângulos diferentes, e cada ângulo tem sua própria maneira de medir. Você não pode colocar todos os tipos de revisão em
00:12:27uma única skill, porque assim o agente terá muitas direções para revisar e acabará ficando pior
00:12:33em vez de melhor. Então você constrói uma skill separada para cada ângulo e as encadeia. A própria equipe da Anthropic
00:12:38trabalha dessa maneira também. Eles encadeiam a skill de revisão de código junto com a skill de simplificação e a skill de verificação,
00:12:43e todas as três agora vêm com o Claude code. Além disso, eles rodam sua própria skill de design,
00:12:49que compara a interface com o arquivo design.md, que é basicamente o arquivo que guarda cada
00:12:54decisão de design do produto. Portanto, essa é uma revisão vindo de quatro direções em vez de uma. Você
00:12:59chegará ao mesmo lugar, com uma pilha de skills em que cada uma cobre um ângulo diferente. Mas você não pode simplesmente
00:13:04dizer ao agente para rodar todas de uma vez. O que você precisa é de mais uma skill acima das outras,
00:13:09que é basicamente uma skill orquestradora cujo único trabalho é rodar outras skills. Ela cria um agente para
00:13:15cada skill de revisão que você tem e entrega a cada um a sua respectiva skill. Todos eles revisam ao mesmo tempo em suas
00:13:20próprias janelas de contexto separadas. Em seguida, ela reúne todas as descobertas em um único relatório que os agentes de correção
00:13:25podem usar como base. Então, ao construir um grafo, a única coisa que você precisa dizer no prompt é que
00:13:30ele deve usar essa única skill. Cada nó que ele cria carrega essa única skill e toda a revisão se distribui
00:13:35abaixo dela por conta própria. Agora, nós preparamos um documento contendo todas as maneiras pelas quais você pode configurar
00:13:40verificações para grafos em detalhes. Esse documento, junto com todas as skills mostradas neste vídeo, estão disponíveis
00:13:45no AI Labs Pro, que é a nossa comunidade. Então, se você encontrou valor no que fazemos e quer apoiar o
00:13:50canal, esta é a melhor maneira de fazer isso. O link está na descrição. Isso nos leva ao final deste
00:13:55vídeo. Se você quiser apoiar o canal e nos ajudar a continuar fazendo vídeos como este, pode fazer isso
00:14:00usando o botão de Valeu Demais abaixo. Como sempre, obrigado por assistir e nos vemos no próximo.