O contexto de um agente precisa de especificação. Defina quatro propriedades antes de culpar o modelo
Os lançamentos da semana atacaram o contexto dos agentes por quatro lados: significado, qualidade da evidência, atualidade e a capacidade de não achar nada. Trate o contexto como produto.
Ouça este artigo · 5 min
Narração completa do artigo, gerada por IA.
Quando um agente enterprise dá uma resposta errada, a análise costuma começar pelo modelo. Era o modelo errado, o prompt estava confuso, vale testar a versão nova? Muitas vezes o modelo fez exatamente o que pediram com o que recebeu. O que ele recebeu estava errado: uma política desatualizada, um documento que o usuário não deveria ver, uma definição de “cliente ativo” que o financeiro abandonou no ano passado, ou cinco trechos vagamente relacionados quando a resposta honesta era “não há nada sobre isso”.
Três lançamentos desta semana atacaram, cada um, uma dessas falhas, de fornecedores diferentes:
- Significado. O Agent Knowledge Foundation da NVIDIA inclui a biblioteca Auto-Ontology, que mapeia dados brutos para conceitos de negócio e suas relações, e modelos Kumo que preveem a partir de dados relacionais.
- Evidência e abstenção. O Rerank 5 da Cohere devolve scores de relevância calibrados, em que 0,7 significa 70% de chance de o documento ser útil, e seleção por trecho.
- Atualidade. A AWS reduziu à metade, para cinco segundos, o intervalo padrão de atualização das coleções de busca e vetoriais do OpenSearch Serverless, para que dados recém-ingeridos fiquem pesquisáveis mais cedo.
Nenhum deles é a resposta completa. Juntos, sugerem um jeito de pensar o contexto dos agentes que falta à maioria dos programas: como um produto com especificação.
Quatro propriedades, cada uma com dono e teste
| A pergunta que responde | Como testar | Quem é dono | |
|---|---|---|---|
| Significado | Os nossos termos significam uma coisa só, e é a atual? | Definições resolvidas contra o glossário aprovado | O dono de negócio de cada definição |
| Evidência | O que o agente leu é relevante, permitido e atribuível? | Evals de busca; checagem de permissão por usuário | Donos do conteúdo e o time de plataforma |
| Atualidade | Quão antigo o contexto pode ser quando o agente o usa? | Tempo entre a mudança na fonte e ela ficar pesquisável | Engenharia de dados, por fonte |
| Abstenção | O agente sabe quando não achou nada utilizável? | Perguntas sem resposta na base | O dono de produto do agente |
Significado é a propriedade que mais falta. Agentes leem definições ao pé da letra. Se “receita” é uma coluna para o dashboard de vendas e outra para o financeiro, o agente vai escolher uma, com confiança. Defendemos que as definições de negócio estão virando infraestrutura compartilhada dos agentes; uma ontologia gerada automaticamente torna a questão mais urgente, porque produz definições mais rápido do que alguém consegue revisá-las.
Evidência tem três partes, e os times costumam medir só a primeira: relevância, permissão e atribuição. O documento precisa responder à pergunta, o usuário precisa ter permissão para vê-lo, e a resposta precisa dizer de onde veio. A relevância pode ser avaliada; explicamos como ao medir a busca como um sistema à parte. A permissão precisa ser aplicada por usuário, não por agente.
Atualidade é um número, e deveria estar escrito por fonte. A mudança da AWS de dez para cinco segundos é uma configuração padrão de atualização, não uma garantia de ponta a ponta: o que importa é o tempo entre uma mudança no sistema de origem, passando pela ingestão e pela indexação, até o agente conseguir recuperá-la. Para um agente de preços, minutos podem ser lentos demais. Para um assistente de políticas internas, um dia pode bastar. Sem uma meta, ninguém percebe quando ela escorrega.
Abstenção é a propriedade que transforma a busca de uma ordenação numa decisão. Se os scores de relevância significam probabilidades, um corte pode significar “nada aqui é bom o bastante”, e o agente pode dizer isso, fazer uma pergunta de esclarecimento ou encaminhar para uma pessoa. Um agente que sempre responde com os cinco primeiros resultados vai sempre responder, inclusive quando não deveria.
Por que “especificação” e não “boas práticas”
Porque uma especificação pode ser testada e ter dono, e uma boa prática não. Cada propriedade acima tem um número ou uma checagem que pode rodar todo dia, e uma pessoa cujo trabalho é mantê-la verdadeira. Quando uma resposta sai errada, a análise pode perguntar qual propriedade falhou antes de alguém mexer no modelo. Quando um fornecedor muda algo, como o modelo por trás do alias “stable” no Agent Search do Google, os testes pegam.
Ela também redistribui o trabalho. Em muitos programas, o time de IA é dono de tudo, do prompt até o índice, inclusive de definições sobre as quais não tem autoridade. Uma especificação de contexto devolve o significado ao negócio, a atualidade à engenharia de dados e a evidência aos donos do conteúdo, e deixa o time de IA responsável pelo que ele de fato controla.
Por onde começar
Escolha um agente em produção e escreva a especificação de contexto dele numa página: os dez termos de que depende e quem é dono de cada um, as fontes que lê com suas metas de atualidade, o conjunto de avaliação da busca com checagens de permissão, e as perguntas que ele precisa se recusar a responder. Rode os testes toda semana. A primeira rodada costuma explicar mais respostas erradas do que um mês de ajustes de prompt.