Resumo Técnico: Protegendo Agentes de LLM contra o Desalinhamento através da Análise de Proveniência

Declaração do Problema

À medida que os agentes de Large Language Model (LLM) evoluem de assistentes conversacionais para sistemas autônomos capazes de executar ações irreversíveis (ex: transferir dinheiro, modificar arquivos), garantir que suas ações estejam alinhadas com a intenção do usuário é crítico. O artigo identifica o desalinhamento como um fenômeno onde a proposta de invocação de ferramenta de um agente desvia da intenção do usuário, não necessariamente devido a uma intenção maliciosa, mas devido a mal-entendidos ou suposições injustificadas sobre a solicitação do usuário.

Os guardiões de tempo de execução (runtime guardrails) existentes frequentemente dependem de um paradigma "LLM-como-juiz", onde um único prompt de LLM avalia se uma ação deve ser permitida. Os autores argumentam que esta abordagem carece de um framework sistemático para raciocinar sobre o alinhamento, levando a julgamentos inconsistentes, racionalidades subjetivas e dificuldades de auditoria. Além disso, medidas de segurança tradicionais, como o sandboxing, limitam as consequências em vez de prevenir a ação desalinhada inicial, e a verificação post-hoc não pode desfazer invocações de ferramentas irreversíveis.

Metodologia

1. Framework Conceitual: Guardiões Baseados em Proveniência

Motivado pela análise de proveniência (o estudo da origem e do histórico de derivação de um artefato), os autores propõem um framework onde uma ação é considerada alinhada apenas se for suportada por evidência rastreável dentro do contexto do agente. O contexto inclui a consulta do usuário ($q$), a documentação da ferramenta ($d$) e o histórico de interação ($h$).

O framework formaliza a detecção de desalinhamento categorizando-a em três tipos distintos, cada um correspondendo a uma falha no estabelecimento de relações de proveniência específicas:

• Desalinhamento ao Nível da Ferramenta (Tool-Level): O agente seleciona uma ferramenta irrelevante para a tarefa.
  • Verificação de Proveniência: A ferramenta selecionada ($t$) possui documentação ($d_t$) que é RelevantePara (RelevantTo) uma subtarefa ($s$) que ContribuiPara (ContributesTo) a consulta do usuário ($q$)?
• Desalinhamento ao Nível do Parâmetro (Parameter-Level): O agente seleciona a ferramenta correta, mas atribui parâmetros que não estão fundamentados no contexto.
  • Verificação de Proveniência: A atribuição de parâmetro ($a$) pode ser DerivadaDe (DerivedFrom) evidência factual ($e$) presente na consulta ou no histórico? Além disso, a ferramenta instanciada ($t$ com $a$) PodeEndereçar (CanAddress) a subtarefa ($s$)?
  • Nota: O framework distingue entre parâmetros deriváveis (que requerem proveniência) e parâmetros generativos (ex: redigir o corpo de um e-mail), que não requerem rastreamento direto de proveniência.
• Desalinhamento ao Nível da Interpretação (Interpretation-Level): O agente resolve uma consulta subespecificada ao comprometer-se arbitrariamente com uma interpretação quando múltiplas interpretações plausíveis existem.
  • Verificação de Proveniência: A ação proposta é a única candidata admissível à proveniência dado o contexto? Se múltiplas ações distintas são suportadas pelo contexto, a consulta é subespecificada, e comprometer-se com uma sem esclarecimento é um desalinhamento.

2. Implementação: ProvenanceGuard

Os autores implementam este framework como ProvenanceGuard, um pipeline de execução em múltiplas etapas que intercepta chamadas de ferramentas antes da execução. Diferente de um "LLM-como-juiz" de etapa única, o ProvenanceGuard decompõe a decisão em três estágios sequenciais:

1. Estágio I (Nível da Ferramenta): Filtra ferramentas que alteram o ambiente e verifica se a ferramenta selecionada é relevante para o plano de subtask atual do agente.
2. Estágio II (Nível do Parâmetro): Identifica quais parâmetros são deriváveis e verifica se seus valores podem ser rastreados de volta ao contexto e se eles instanciam corretamente a ferramenta para a subtask.
3. Estágio III (Nível da Interpretação): Pergunta ao LLM (sem revelar a ação escolhida pelo agente para evitar viés) se existem outras ações admissíveis à proveniência. Se múltiplas existirem, a ação é bloqueada por depender de uma suposição injustificada.

O sistema utiliza um LLM para avaliar as relações de proveniência específicas (ex: RelevantTo, DerivedFrom), mas estrutura o processo de raciocínio para ser mais explícito e auditável do que um prompt holístico.

Principais Contribuições

1. Taxonomia de Desalinhamento: Uma distinção formal entre desalinhamento de nível de ferramenta, nível de parâmetro e nível de interpretação.
2. Framework Baseado em Proveniência: Um modelo conceitual que enquadra a verificação de alinhamento como a determinação de se as chamadas de ferramenta estão fundamentadas em evidências rastreáveis, formalizadas através de relações binárias específicas.
3. ProvenanceGuard: Uma implementação de pipeline de tempo de execução do framework que atua como um guardião de execução.
4. Benchmarking: Avaliação em dois benchmarks (Agent-SafetyBench e WorkBench) e 10 LLMs de base, incluindo um subconjunto anotado manualmente de traços do Agent-SafetyBench.

Resultados Experimentais

Os autores avaliaram o ProvenanceGuard contra um DirectPrompt Baseline (padrão LLM-como-juiz) e um Single-step Provenance Prompt (ProvePrompt, que utiliza os conceitos do framework em uma única passagem).

• Detecção de Desalinhamento (Taxa de Erro):
  • No Agent-SafetyBench (focado em subespecificação), o ProvenanceGuard reduziu a taxa de erro em traços desalinhados de 42,9% (Baseline) para 1,8%.
  • No WorkBench, a taxa de erro diminuiu de 32,1% para 17,3%.
  • O design multi-estágio (ProvenanceGuard) superou consistentemente a variante de etapa única (ProvePrompt), particularmente no Agent-SafetyBench, sugerindo o valor de decompor o processo de raciocínio.
• Custo de Intervenção (Falsos Positivos/Intervenções Desnecessárias):
  • No Agent-SafetyBench (traços alinhados), o ProvenanceGuard não introduziu um aumento estatisticamente significativo em intervenções desnecessárias comparado ao baseline.
  • No WorkBench (traços de sucesso na tarefa), o ProvenanceGuard reduziu significativamente a taxa de intervenção de 30,5% (Baseline) para 12,8%, indicando que é mais preciso em permitir que ações corretas prossigam.

Significância e Alegações

O artigo afirma que o raciocínio estruturado baseado em proveniência fornece uma fundação eficaz e prática para salvaguardar agentes de LLM. A significância reside em:

• Raciocínio Sistemático: Afastamento de julgamentos subjetivos e holísticos para um framework baseado em links de dependência explícitos e auditáveis entre ação e contexto.
• Tratamento de Subespecificação: O framework aborda especificamente o risco de agentes fazerem suposições injustificadas em consultas subespecificadas, uma causa comum de desalinhamento que filtros de segurança padrão costumam perder.
• Desempenho Equilibrado: A abordagem multi-estágio alcança alta precisão de detecção para ações desalinhadas sem incorrer em um custo proibitivo de bloqueio de tarefas válidas e bem-sucedidas do agente.

Os autores concluem que, embora o framework não possa detectar desalinhamento em parâmetros puramente generativos (como geração de texto livre) e dependa do próprio plano do agente (que poderia, teoricamente, estar desalinhado), ele oferece um mecanismo robusto para prevenir ações irreversíveis e não fundamentadas no contexto em sistemas agênticos.