Escrevi este guia como o manual que eu gostaria de ter tido antes de fazer a transição para a Engenharia de IA Aplicada.
A função se sobrepõe amplamente à engenharia de software tradicional, mas adiciona alguns conceitos importantes que a maioria dos engenheiros de software precisa aprender ao fazer a transição. Sugiro que você use este material como um resumo dos tópicos principais que precisa entender e, em seguida, siga os recursos vinculados ao longo do artigo quando quiser se aprofundar.
Ao final, você deve ter uma compreensão muito mais clara do que é a Engenharia de IA Aplicada, o que o trabalho realmente exige e como ela vai além da engenharia de software tradicional.
Se você tem interesse em trabalhar em alguns dos problemas mais interessantes de IA Aplicada com uma equipe de engenharia muito talentosa, estamos sempre contratando. Candidate-se em nosso site em varickagents.com ou indique um candidato para ganhar um bônus de indicação de $20k.
Dito isso, a melhor maneira de entender a Engenharia de IA Aplicada é começar pela mudança na forma como você pensa sobre a construção de software.
Engenharia de software vs engenharia de IA
A maior diferença entre ser um engenheiro de software e um engenheiro de IA é que a engenharia de software tradicional treina você para pensar de forma determinística, enquanto a IA aplicada força você a pensar de forma probabilística.
No software normal, você escreve a lógica, faz funcionar e, quando algo quebra, geralmente consegue rastrear a causa – uma entrada estruturada produz deterministicamente uma saída estruturada.
A IA aplicada não funciona assim. Você está construindo em torno de uma chamada de API não determinística para inteligência, o que significa que a mesma entrada pode retornar diferente a cada vez. Por causa disso, o trabalho deixa de ser apenas construir o software e passa a ser medir se o sistema realmente se comporta como deveria.
A forma como fazemos isso é através de avaliações (evals), então vou detalhar como construir um conjunto de avaliações que garanta que o agente que você desenvolve não esteja cometendo erros. Aprendi que esta é uma das habilidades mais importantes de um desenvolvedor de IA aplicada, dada a natureza não determinística do trabalho que fazemos.
A próxima parte do artigo aborda o desenvolvimento de cada parte de um agente de IA (exceto o modelo em si, é claro), porque você pode chamar uma API para um modelo, mas precisa construir todo o resto sozinho. Isso é chamado de engenharia de harness (infraestrutura de suporte).
E, por último, vou abordar como passar de um agente em produção para vários – e por que isso é um problema de sistemas distribuídos. Se você conseguir chegar ao final deste artigo, não há razão para não conseguir fazer a transição para se tornar um engenheiro de IA Aplicada.
Avaliações (Evals)
Um engenheiro de IA aplicada transforma incerteza em confiança medida usando avaliações. No desenvolvimento de software tradicional, você confia no sistema porque escreveu a lógica e testou o código. Na IA aplicada, você não pode confiar no sistema dessa forma porque o modelo pode se comportar de maneira diferente entre execuções. Portanto, o engenheiro de IA precisa construir uma camada de medição em torno do agente.
Uma avaliação é o processo de dar uma tarefa a um agente, deixá-lo executar e avaliar o que ele fez. O objetivo é provar duas coisas: o agente concluiu o trabalho corretamente e o agente permaneceu dentro dos limites que lhe foram dados.
O primeiro passo é avaliar o resultado. Esta é a etapa mais fácil do processo de avaliação. Para um agente de faturas, nos quais costumo trabalhar, isso significa garantir que a fatura chegue ao lugar certo ou que a duplicata seja sinalizada. Você está apenas comparando o resultado final com o que deveria ter acontecido.
O segundo passo é avaliar a trajetória. Este é o caminho que o agente percorreu para chegar a esse resultado: as ferramentas que chamou, os campos que tocou, os argumentos que passou e as ações que tentou ao longo do caminho. Isso é importante porque um agente pode chegar à resposta final correta enquanto ainda faz algo perigoso no processo. Ele pode classificar uma fatura corretamente enquanto também altera dados bancários ou envia um pagamento antes da aprovação.
A trajetória em si é apenas um log: uma lista ordenada de cada ferramenta que o agente chamou e os argumentos que passou – avaliá-la significa apenas escrever verificações nesse log.
Algumas verificações são determinísticas – garantir que send_payment nunca apareça antes de uma chamada de aprovação, verificar se os únicos campos alterados foram aqueles que o agente tinha permissão para alterar. Outras são decisões de julgamento – se uma escalação foi apropriada, se a justificativa justificou a ação. Essas vão para um segundo modelo com uma rubrica.
O princípio geral a seguir é que as verificações determinísticas geralmente capturam as violações de segurança, enquanto o modelo de julgamento avalia a qualidade.
O resultado são duas notas por caso de teste: o agente obteve a resposta correta e ele se comportou corretamente para chegar lá. Elas precisam ser relatadas separadamente, porque um agente que classifica faturas corretamente 95% das vezes, mas toca em um campo proibido em 4% das execuções, parece ótimo em uma pontuação combinada, mas causa grandes complicações de negócios em produção.
Este artigo serve como uma introdução às avaliações e a todos os outros tópicos abordados, então vinculei outros recursos para ajudá-lo a se aprofundar. Alguns que me ajudaram a entender como construir avaliações eficazes são:
Recomendo passar por cada um deles, mas comece pelos do Lenny e do Hamel antes de fazer o curso de avaliações (que é um pouco mais prático).
Mas uma avaliação ainda precisa de um agente para testar, e tudo ao redor do modelo precisa ser construído por você. Esse sistema ao redor é chamado de harness – a próxima seção aborda como pensar sobre cada parte do processo de engenharia de harness, desde a chamada de ferramentas até a otimização da janela de contexto.
Engenharia de Harness
Um modelo sozinho não é um agente. Um modelo pode raciocinar, classificar, escrever e decidir, mas não pode operar dentro de uma empresa por conta própria. Ele pode dizer qual ação deve acontecer, mas não pode executar essa ação com segurança a menos que você construa o sistema ao seu redor – e esse sistema é o harness.
O harness é tudo ao redor do modelo que transforma uma chamada de API em um agente funcional: as ferramentas que ele pode usar, o contexto que ele vê, o estado que ele lembra, as proteções que o limitam e o loop que permite que ele continue trabalhando até que a tarefa seja concluída.
A primeira parte do harness é a execução de ferramentas.
Os modelos apenas leem e escrevem texto, portanto, quando um modelo decide fazer algo, ele não o executa de fato. Ele emite uma solicitação estruturada (uma string JSON) para atualizar um registro, enviar um e-mail ou pesquisar em um banco de dados.
O harness recebe essa solicitação, valida-a, executa a operação real e envia o resultado de volta para o modelo como texto.
A segunda parte é o gerenciamento de contexto. Cada instrução, menu de ferramentas, resultado de ferramenta e mensagem anterior ocupa espaço na janela de contexto do modelo. O harness precisa decidir o que o modelo precisa ver agora, o que deve ser resumido e o que deve ser removido. Sem isso, os agentes se perdem em um histórico irrelevante.
Escreverei um artigo mais abrangente que se aprofunda em cada parte do processo de desenvolvimento do harness, mas, por enquanto, recomendo ouvir esta palestra de um engenheiro da Arize, a plataforma de aprendizado contínuo para agentes, que se aprofunda em seu processo de pensamento sobre gerenciamento de contexto.
Para saber mais sobre como aplicar o gerenciamento de contexto eficaz a seus agentes na prática, leia estes blogs:
- Artigo da OpenAI sobre gerenciamento de contexto
- Um guia prático para gerenciamento de contexto
- Guia de engenharia de contexto da Anthropic
A terceira parte na engenharia de harness é estado e memória. Os modelos são sem estado entre as chamadas, portanto, tudo o que o agente precisa lembrar deve viver fora do modelo (geralmente em um banco de dados, armazenamento de arquivos ou registro de tarefa). Contexto é o que o modelo está olhando agora. Estado é tudo o que o agente sabe, mas não está olhando no momento.
A quarta parte são as proteções (guardrails). Como o modelo pode solicitar a ação errada com a mesma confiança que a correta, o harness precisa verificar permissões, validar entradas, bloquear ações inseguras e encaminhar etapas de alto risco para humanos.
Finalmente, tudo isso é unido no loop do agente: construir o contexto, chamar o modelo, inspecionar sua resposta, executar a ferramenta se permitido, armazenar o resultado, atualizar o contexto e repetir até que a tarefa seja concluída.
A engenharia de harness é a maior parte do que você fará como engenheiro de IA Aplicada, então dedique um tempo a esta seção. Como engenheiro de IA aplicada, seu trabalho inteiro é construir o ambiente operacional que permite que um sistema probabilístico funcione dentro de um software determinístico.
Mas a produção geralmente não para em um agente.
À medida que o fluxo de trabalho aumenta, o instinto natural é dividir o trabalho. Mas, uma vez que você adiciona esse segundo agente, o design do sistema muda.
Com um agente, a maior parte da complexidade vive dentro de um único loop. Com vários agentes, você agora tem vários loops atuando no mesmo ambiente. Cada agente pode ler o estado que outro agente acabou de alterar, escrever na memória da qual outro agente depende ou chamar uma ferramenta cujo resultado afeta todo o fluxo de trabalho.
Nesse ponto, a parte difícil não é mais apenas a criação de prompts, avaliações ou design de harness. Torna-se um problema de sistemas distribuídos: quem possui qual estado, quem pode escrever na memória, quais ferramentas são seguras para repetir e o que acontece quando dois agentes razoáveis tomam ações na ordem errada.
Implantações Multiagente são um Problema de Sistemas Distribuídos
Quando o primeiro agente funciona e o fluxo de trabalho aumenta, um novo engenheiro de IA aplicada naturalmente tem o instinto de dividir o trabalho em funções: um agente pesquisa, um planeja, um executa, um revisa.
Mas o segundo agente muda a unidade de design do agente para o sistema. Vários loops agora atuam no mesmo ambiente – um agente pode atualizar o status do cliente enquanto outro está no meio de um plano escrevendo com base no status desatualizado. Ambos tomaram decisões razoáveis, mas o sistema permitiu que essas decisões interagissem na ordem errada.
Isso é um problema de sistemas distribuídos. A boa notícia é que os engenheiros de sistemas distribuídos resolveram essas falhas há décadas. Seu trabalho é aplicá-las a loops que, por acaso, contêm um LLM. Abaixo está uma lista de soluções de sistemas distribuídos que se aplicam à engenharia de IA:
Princípio do único escritor. Cada parte importante do estado tem exatamente um agente que pode escrever nela – outros agentes leem dela ou enviam solicitações de alteração. Reforce isso no nível da ferramenta: se o agente de execução é o único que pode escrever no CRM, o agente de pesquisa não pode corromper o CRM, não importa o quão mal ele raciocine.
Chaves de idempotência. Os agentes repetem chamadas de ferramenta quando algo falha ou expira, mas as repetições podem ser perigosas quando a ferramenta altera algo no mundo real. Você não quer que um agente envie o mesmo pagamento duas vezes só porque a primeira solicitação pareceu ter falhado. A correção é anexar uma chave exclusiva a cada chamada de ferramenta mutável – ou seja, qualquer ação que altere dados em um sistema externo. Se a ferramenta vir a mesma chave novamente, ela deve retornar o resultado original em vez de executar a ação uma segunda vez. A API do Stripe funciona assim – e isso se aplica ao desenvolvimento de agentes ao lidar com pagamentos, e-mails, etc.
Pré-condições em gravações. Os agentes geralmente agem com base em uma visão antiga do mundo. Algo pode ter mudado entre o momento em que o agente fez seu plano e o momento em que tenta atualizar um sistema externo. Para evitar gravações desatualizadas, as ferramentas mutáveis devem exigir uma condição antes de fazer a alteração. Por exemplo: "definir o status como Aprovado somente se ainda estiver como Pendente". Se o status já mudou, a ferramenta deve falhar claramente em vez de sobrescrever silenciosamente o estado mais recente.
Transferências explícitas. Passe o trabalho como mensagens com um esquema definido, sequenciado por um orquestrador. Um agente deve receber sua tarefa, não descobri-la.
Resumo (TLDR)
Este artigo serve como uma visão geral dos tópicos mais importantes que aprendi como engenheiro de IA Aplicada: avaliações, engenharia de harness e design de sistemas multiagente.
Se você levar algo disso, que seja isto – o modelo fornece a inteligência, mas tudo o que o torna confiável (a camada de medição, o ambiente operacional, as regras de coordenação) é projetado por você. Entenda esses conceitos e a transição da engenharia de software se torna uma extensão das habilidades que você já possui.
Se você tem interesse neste tipo de trabalho e quer enfrentar alguns dos problemas mais interessantes em IA Aplicada com uma equipe de engenharia muito talentosa, estamos sempre contratando. Candidate-se em nosso site em varickagents.com e você pode começar o mais rápido possível. Por outro lado, se você indicar um candidato bem-sucedido, ofereceremos um bônus de indicação de $20K.
