Resumo Técnico: Iteração Orientada pela Avaliação para Aplicações de LLM

Declaração do Problema

Avaliar aplicações de Grandes Modelos de Linguagem (LLMs) apresenta desafios distintos em comparação com o teste de software convencional. A verificação tradicional baseia-se em saídas determinísticas para dados de entrada, enquanto as aplicações de LLM exibem comportamento probabilístico, variabilidade semântica e sensibilidade a mudanças no prompt e no modelo. Esse não-determinismo torna o teste de correspondência exata pouco confiável. Além disso, a complexidade do espaço de saída significa que respostas semanticamente equivalentes podem ser lexicalmente distintas, e as expectativas do usuário são frequentemente implícitas e dependentes de contexto.

O artigo identifica riscos fundamentais decorrentes de uma avaliação insuficiente, incluindo:

• Alucinação: Geração de afirmações plausíveis, mas factualmente incorretas.
• Violações de Segurança: Produção de conteúdo prejudicial, tendencioso ou inapropriado.
• Deriva de Prompt (Prompt Drift): Degradação não pretendida de comportamentos não relacionados durante o refinamento iterativo de prompts.
• Mudança de Distribuição (Distribution Shift): Discrepâncias entre os casos de teste de desenvolvimento e as entradas reais de produção.

As práticas atuais de avaliação carecem frequentemente de auditabilidade, tornando difícil rastrear decisões de avaliação até modos de falha, artefatos e evidências de validação específicos. Além disso, existe o equívoco de que melhorias "genéricas" de prompt (ex: adicionar regras gerais de utilidade) geram ganhos de desempenho monotônicos em todos os contratos de tarefa.

Metodologia

O Conjunto Mínimo Viável de Avaliação (MVES)

O artigo propõe o Conjunto Mínimo Viável de Avaliação (MVES), um framework orientado à auditoria projetado para vincular a avaliação de nível de aplicação a modos de falha específicos. O MVES não é um benchmark universal, mas uma estrutura para decisões de avaliação inspecionáveis. Ele mapeia:

1. Categorias de Aplicação: LLM geral, Geração Aumentada de Recuperação (RAG) e fluxos de trabalho Agênticos.
2. Modos de Falha: Riscos específicos como deriva de formato, alegações não suportadas ou uso indevido de ferramentas.
3. Testes e Métricas: Verificações concretas (ex: validade de JSON, presença de citações).
4. Artefatos Necessários: Prompts versionados, conjuntos de ouro (golden sets) e identificadores de modelos.
5. Evidência de Validação: Intervalos de confiança de taxa de aprovação e amostras de auditoria humana.

O framework distingue três níveis:

• MVES-Core: Aplica-se a todas as aplicações (conjuntos de ouro, verificações de aceitação, prompts versionados).
• MVES-RAG: Adiciona métricas de recuperação (Recall@k, MRR) e verificações de conformidade de conteúdo/citação.
• MVES-Agêntico: Adiciona avaliação de trajetória, taxas de sucesso de ferramentas e revisões de execução em ambiente controlado (sandbox).

Design Experimental: Iteração Orientada pela Avaliação

Para demonstrar a utilidade do MVES e testar a hipótese de que adições genéricas de prompt não são universalmente benéficas, os autores conduziram um estudo de ablação local reproduzível.

• Configuração: Os experimentos foram executados localmente usando Ollama em um Mac mini M4 com dois modelos: llama3:8b-instruct-q4_K_M e qwen2.5:7b-instruct-q4_K_M.
• Tarefas: Três contratos de aplicação distintos foram avaliados:
  1. Extração Estruturada: Requisitos estritos de saída JSON.
  2. Conformidade de Conteúdo/Citação RAG: Respostas devem ser fundamentadas no contexto recuperado com citações.
  3. Seguimento de Instrução: Adesão a restrições de formato e comportamentos de recusa.
• Condições de Prompt: Cinco condições foram testadas:
  • A (Baseline): Prompt específico da tarefa + prompt de sistema mínimo.
  • B (+Wrapper): Baseline + wrapper curto de seguimento de instrução.
  • C (+Regras): Baseline + regras genéricas anexadas ao prompt do usuário.
  • D (Melhoria Total): Baseline + prompt de sistema completo e melhorado.
  • E (Não Conflitante): Baseline + orientação geral que preserva explicitamente os contratos da tarefa.
• Escala: Cada condição foi avaliada em 30 casos por tarefa (expandidos a partir de suítes semente escritas à mão via variantes sintéticas determinísticas).
• Métricas: Taxa de aprovação total (porcentagem de casos onde cada verificação passou) e taxa de aprovação de verificação (porcentagem de verificações individuais passadas).

Principais Resultados

O estudo de ablação revelou que mudanças de prompt não produzem melhorias monotônicas; elas criam compensações (trade-offs) específicas de tarefa.

1. Desempenho de Extração: Prompts de contrato de saída mais fortes (Condições D e E) melhoraram significativamente a extração JSON estrita. Para o Llama 3, a taxa de aprovação total saltou de 0% (Baseline) para 93,3% (Melhoria Total). Para o Qwen 2.5, subiu de 13,3% para 100%. Isso indica que baselines mínimos são frequentemente inadequados para contratos de saída estruturada estrita.
2. Declínio de Conformidade RAG: Adições genéricas de prompt frequentemente degradaram o desempenho de RAG.
   • Qwen 2.5: Sob a Condição C (regras genéricas anexadas ao prompt do usuário), a conformidade de citação/conteúdo RAG despencou de 26/30 (86,7%) na baseline para 9/30 (30,0%).
   • Llama 3: Sob as Condições D e E, a conformidade RAG caiu de 19/30 (63,3%) para 16/30 (53,3%).
3. Seguimento de Instrução: As melhorias foram mistas. Embora algumas condições tenham melhorado a adesão às instruções, outras causaram regressões dependendo do modelo e da natureza específica das regras adicionadas.
4. Orientação Não Conflitante: Mesmo a Condição E, desenhada para preservar os contratos da tarefa, falhou em proteger o desempenho de RAG para o Llama 3, sugerindo que o impacto negativo das regras genéricas não se deve apenas ao conflito direto de instruções, mas pode advir de mudanças mais amplas de atenção ou diluição de contexto.

Principais Contribuições

1. Framework MVES: A proposta de uma estrutura orientada à auditoria que vincula explicitamente classes de aplicação a modos de falha, artefatos necessários e evidências de validação, permitindo decisões de avaliação reproduzíveis e comparáveis.
2. Harness de Avaliação Reproduzível: Um harness de avaliação local cobrindo extração estruturada, conformidade de citação RAG e seguimento de instrução, incluindo suítes semente e scripts para expansão determinística.
3. Evidência Empírica de Trade-offs de Prompt: Um estudo de ablação de prompt demonstrando que melhorias de prompt "genéricas" podem melhorar um contrato de tarefa (ex: extração estrita) enquanto degradam outro (ex: fundamentação RAG), com efeitos variando por modelo e posicionamento do prompt.
4. Orientação Prática: Orientações consolidadas sobre design de conjuntos de teste, seleção de métricas, calibração de LLM-as-judge e monitoramento de produção, estruturadas para apoiar a avaliação de nível de aplicação reproduzível.

Significância e Alegações

O artigo alega que mudanças de prompt devem ser tratadas como potenciais riscos de regressão, em vez de serem assumidas como melhorias benéficas. A descoberta central é que "adições genéricas de prompt não produzem melhorias monotônicas".

A significância deste trabalho reside na mudança do paradigma da engenharia de prompt baseada em intuição para a iteração orientada pela avaliação. Os autores argumentam que:

• Testes de Regressão são Essenciais: Assim como mudanças no código de software exigem testes contra um conjunto de casos, edições de prompt devem ser validadas contra suítes específicas de tarefas antes da implantação.
• O Contexto Importa: Uma modificação de prompt que corrige um problema de formatação em uma tarefa de extração pode inadvertidamente fazer com que um sistema RAG alucine ou ignore citações.
• Auditabilidade: Ao estruturar a avaliação em torno do MVES, as equipes podem rastrear exatamente quais modos de falha foram cobertos, quais artefatos foram usados e qual evidência sustenta a decisão de implantar uma mudança.

O artigo afirma explicitamente que não visa classificar LLMs, estabelecer regras universais de engenharia de prompt ou fornecer um levantamento abrangente de ferramentas. Em vez disso, oferece uma demonstração local controlada de como pequenas mudanças de prompt podem ter efeitos divergentes em diferentes contratos de tarefa, defendendo uma abordagem rigorosa e baseada em evidências para o desenvolvimento de aplicações de LLM.