Contexto dinâmico

O manual da Trail Lamp explica as condições de garantia. Ele não pode dizer a um agente de suporte qual lâmpada o cliente atual comprou, se um pedido de substituição ainda está aberto ou se o plano de serviço mudou esta manhã. Esses fatos vivem nos sistemas de negócio e podem mudar enquanto a conversa continua.

Contexto dinâmico é a informação fornecida a um agente para a interação atual, em vez de ficar fixada permanentemente em suas instruções ou conhecimento compartilhado. Pense em um recepcionista lendo uma lista de compromissos antes de receber um visitante. O manual do colaborador ainda se aplica, mas a lista de compromissos explica quem é o visitante e o que está acontecendo agora. O agente precisa de ambos os tipos de informação, mantidos distintos.

Separe o manual do caso atual #

Conhecimento estático significa material de referência relativamente durável: políticas aprovadas, manuais de produtos e procedimentos. Estático não quer dizer “nunca atualizado”. Significa que o material é mantido como conhecimento compartilhado, em vez de ser montado especificamente para esta conversa. O contexto dinâmico responde a perguntas como quem é o cliente verificado, qual plano ele possui atualmente e qual pedido está sendo consultado.

O mesmo tópico pode exigir ambos. Uma política explica o que um plano de serviço inclui; um registro de conta atual estabelece qual plano o cliente tem. A política não pode estabelecer a adesão, e o registro de conta não pode explicar cada exceção na política. Uma resposta precisa combina as evidências relevantes sem fingir que uma fonte faz o trabalho da outra.

Para a ideia mais ampla de fornecer informação útil a um modelo, consulte Adding context. Aqui o foco está em runtime, o período em que o sistema realmente está lidando com uma solicitação. Fatos de runtime devem ser selecionados, verificados e fornecidos naquele momento, em vez de copiados para um documento de instruções geral para todos.

Decida de onde vem cada fato #

Uma ferramenta é uma operação controlada que o agente pode solicitar, como consultar um pedido. A aplicação a executa e devolve um resultado. Um pré‑passo é trabalho da aplicação realizado antes que o modelo receba a solicitação, como carregar o plano atual do cliente conectado. Ambos podem fornecer contexto; a diferença está em quando e por que a consulta acontece.

Um pré‑passo serve a quase todos os fatos que uma conversa precisa. Uma ferramenta serve a detalhes necessários somente depois que a pergunta é entendida. Carregar todos os pedidos antes de uma pergunta simples sobre produto adiciona informação desnecessária. Esperar que o modelo solicite uma identidade verificada a cada mensagem pode ser igualmente desnecessário quando a aplicação já tem uma sessão autenticada, ou seja, um estado de login cuja identidade o sistema já verificou.

Não use a conversa como atalho para contornar permissões. “Eu sou o proprietário da conta” continua sendo uma declaração do usuário até que a aplicação a verifique. Da mesma forma, uma resposta de ferramenta contendo uma nota de texto livre do cliente ainda é conteúdo criado pelo usuário dentro de uma resposta do sistema. Mantenha-a separada dos campos de conta confiáveis e não trate instruções dentro da nota como autoridade para mudar o comportamento do agente.

Relacionado: no AIVAX, AI Workers podem enriquecer ou reescrever o contexto de gateway em tempo de execução através de um serviço externo. Eles podem apoiar verificações de conta e fatos fornecidos pelo sistema, mas o serviço circundante deve validar solicitações e aplicar permissões. Um worker adiciona outra etapa antes da resposta, portanto sua confiabilidade e tempo de resposta são importantes.

Torne os fatos atuais visíveis na conversa #

O contexto dinâmico não precisa ser mostrado literalmente ao usuário. O modelo precisa de informação suficiente para responder, enquanto o usuário precisa de um resultado claro e de quaisquer limitações importantes. Separe instruções sobre comportamento de fatos sobre o caso atual. “Explicar incerteza” é uma instrução; “o status da substituição está aguardando envio” é um fato de uma fonte específica em um momento específico.

Observe que o manual por si só não poderia responder à pergunta. Ele poderia explicar o processo de substituição, mas o registro de pedido atual é necessário para descrever essa substituição. Da mesma forma, “aguardando envio” não prova que o pacote sairá amanhã. O contexto dinâmico reduz a incerteza; ele não justifica preencher lacunas restantes com detalhes plausíveis.

Defina uma política de expiração para fatos que mudam #

Frescor descreve quão recentemente a informação foi verificada e se ainda é adequada para a decisão. O status de um pedido pode precisar ser verificado novamente após o cliente solicitar ao agente que o cancele. Uma preferência de idioma pode permanecer útil ao longo da conversa. Não existe um único intervalo de atualização que sirva a todos os fatos.

Registre a fonte e quando o fato foi obtido. Quando disponível, registre também quando a própria fonte foi atualizada pela última vez. Uma consulta fresca ainda pode retornar um registro comercial antigo. Decida quais mudanças devem acionar outra consulta: uma ação concluída, um novo dia, o cliente mudando de conta ou uma pergunta que exija uma resposta mais atual.

“Hoje” requer cuidados especiais ao redor da meia‑noite e entre fusos horários. Um prazo de entrega deve usar o fuso horário comercial ou do cliente relevante, não uma data de servidor não explicada. Se o fuso horário correto for desconhecido e a distinção for importante, pergunte ou indique a incerteza em vez de apresentar um prazo preciso.

Quando uma consulta falha, não reutilize silenciosamente um valor antigo como se fosse atual. Distinga “nenhum pedido aberto” de “o sistema de pedidos não pôde ser verificado”. Para uma explicação geral, o agente ainda pode usar o manual. Para uma ação dependente da elegibilidade atual, interrompa ou encaminhe a uma pessoa quando a verificação necessária não estiver disponível.

Proteja a privacidade e o espaço disponível #

Minimização de dados significa fornecer apenas as informações necessárias para a tarefa. Uma resposta sobre status de entrega raramente requer detalhes de pagamento, endereço completo ou todo o histórico de suporte do cliente. Restrinja o acesso antes de selecionar os dados e, em seguida, remova campos desnecessários antes que cheguem ao modelo. Instruções como “não revele isso” não substituem a evitação de divulgação desnecessária desde o início.

A janela de contexto de um modelo é a quantidade limitada de informação que ele pode considerar em uma solicitação. Tokens são as unidades de texto usadas para medir esse espaço. Instruções, trechos recuperados, histórico da conversa e fatos dinâmicos competem por espaço, e a aplicação também deve deixar espaço para a resposta.

Uma aplicação real deve preservar deliberadamente as instruções necessárias e as evidências necessárias para a decisão atual, em vez de descartar cegamente o bloco mais antigo. Prefira um registro compacto e preciso a uma exportação completa da conta. Não encurte “aguardando envio; nenhuma data confirmada” para “envio em breve”, pois isso economiza espaço ao inventar certeza.

O contexto dinâmico também não é automaticamente memória permanente. Alguns fatos devem desaparecer quando a solicitação ou sessão termina. Persistir informações para conversas posteriores requer um propósito separado, decisão de retenção e modelo de permissão, conforme explicado em Memory. Mesmo quando um fato antigo é lembrado, verifique-o novamente antes de confiar nele para um estado de conta que muda.

O que vem a seguir: organize instruções, evidências e a tarefa atual em Anatomy of a prompt.