← Todos os insights

Nota de campoRecorte: Brasil4 min de leitura

Antes de rodar um sistema, um agente deveria explicá-lo. Poucos sistemas guardam histórico suficiente

O primeiro agente útil em um sistema complexo costuma ser somente leitura: ele explica o que aconteceu. Isso depende de quatro registros mal guardados, e mapear as lacunas é o primeiro entregável.

Ouça este artigo · 5 min

Narração completa do artigo, gerada por IA.

Uma planta arquitetônica com uma caneta e uma régua, em duotone La Madre, ao lado das palavras Explicar antes de agir
Foto: rawpixel (CC0)

A maioria dos programas de agentes começa perguntando o que o agente deve fazer. Em sistemas complexos, a primeira pergunta melhor é o que o agente consegue explicar.

A Bayer Crop Science deu um exemplo claro na semana passada. A plataforma roda mais de 500 configurações de modelos de machine learning para melhoramento genético de plantas, e o problema não era rodá-las; era que ninguém além dos engenheiros conseguia dizer por que um resultado tinha a cara que tinha. Os agentes que a Bayer construiu são somente leitura e explicam o que a plataforma fez. A Bayer relata que cerca de 80% das perguntas agora são respondidas sem um engenheiro.

O padrão não é único. A Minerva da NVIDIA mapeia um cluster de GPU e seus jobs em um único grafo para que um operador possa rastrear uma execução lenta até um componente. Agentes de operações da AWS e da Microsoft produzem um diagnóstico que é um ponto de partida, não uma constatação. A Microsoft está construindo modelos semânticos no Dataverse para que os agentes entendam o que os registros significam antes de tocá-los. Em cada caso, a primeira coisa valiosa que a IA faz é tornar legível um sistema que já existe.

Nossa visão, declarada como visão: em um sistema complexo de operações, o agente de explicação deve vir antes do agente de ação, e a principal coisa que ele entrega nos primeiros meses não são respostas. É um mapa do que o sistema não consegue explicar sobre si mesmo.

Uma explicação precisa de quatro registros

Quando alguém pergunta “por que isso aconteceu?”, um agente só pode responder a partir do que foi registrado. Quatro registros decidem se a resposta é uma explicação ou uma história plausível:

O que rodou. Histórico de execução com entradas, parâmetros, horários de início e fim e resultados, incluindo execuções que falharam e foram repetidas. Muitas plataformas guardam o último estado bem-sucedido e pouco mais.

O que foi configurado. Configuração versionada, para que “o que mudou desde a última safra” tenha resposta. Configuração editada no local, ou guardada no notebook de alguém, faz o agente adivinhar.

De onde os dados vieram. Linhagem da fonte até a saída. Sem isso, “a entrada era diferente?” vira uma busca que o agente não consegue fazer de forma confiável.

O que significa e quem é o dono. Definições de negócio e um responsável por componente. Um agente que consegue nomear a pessoa responsável por um pipeline é mais útil do que um que resume seus logs.

Um agente de explicação que não tem um desses registros não falha de forma evidente. Ele produz respostas fluentes com a peça faltante preenchida por inferência. É por isso que as lacunas precisam ser medidas de propósito: acompanhe as perguntas que o agente não conseguiu responder, ou respondeu sem uma fonte, e classifique-as por qual dos quatro registros faltou.

Por que essa ordem reduz o risco

Um agente somente leitura evita as perguntas que travam a maioria dos projetos de agentes: quem aprova uma ação, como desfazer, quem responde legalmente quando dá errado. Ele pode entrar em produção mais cedo, com permissões que um time de segurança aprova em uma única revisão.

Ele também constrói a evidência para o que vem a seguir. Já defendemos que a autonomia deve ser conquistada uma classe de ação por vez. Um agente que explicou mil falhas corretamente, com fontes, é o argumento mais forte para deixá-lo propor uma correção. Um agente que nunca foi solicitado a explicar nada está sendo confiado com base em uma demo.

E ele força o reparo de dados que agentes de ação precisariam de qualquer forma. Observamos que o primeiro entregável duradouro de um agente muitas vezes são os dados que ele força você a corrigir. Um agente de explicação encontra essas lacunas sem ter agido sobre elas primeiro.

Em trabalho regulado, isso já é o padrão

Times de ciências da vida e de bancos vão reconhecer os quatro registros. Expectativas de integridade de dados na fabricação farmacêutica pedem registros atribuíveis, contemporâneos e originais; a gestão de risco de modelo em bancos pede documentação que permita a outra pessoa reproduzir um resultado. Um agente de explicação é, na prática, um teste contínuo de se um sistema atende a esse padrão, feito por um leitor que faz mais perguntas do que qualquer auditor.

Isso sugere uma sequência prática para qualquer sistema complexo que uma organização queira automatizar:

  1. Faça o deploy de um agente de explicação somente leitura para as pessoas que hoje esperam por engenheiros.
  2. Registre toda pergunta que ele não consegue responder a partir de uma fonte registrada e classifique a lacuna.
  3. Corrija os registros, começando pelas lacunas que bloqueiam o maior número de perguntas.
  4. Só então deixe um agente recomendar ações e, mais tarde, executá-las, uma classe de ação por vez.

O apelo dos agentes é que eles agem. Os sistemas que vale a pena automatizar são os que conseguem primeiro se explicar, e um agente é uma boa forma de descobrir quais são.

Tem um caso de uso de IA parado entre o protótipo e a produção?

Conte o que você quer colocar no ar. Respondemos com próximos passos honestos.

Converse sobre um caso de uso