Resumo Técnico: Ambig-DS: Um Benchmark para Ambiguidade de Enquadramento de Tarefa em Agentes de Ciência de Dados

Declaração do Problema

À medida que os agentes de ciência de dados evoluem de copilotos para pilotos automáticos, um modo de falha crítico emerge: o enquadramento silencioso incorreto. Diferentemente de erros de execução (por exemplo, falhas de código ou erros de sintaxe), o enquadramento silencioso incorreto ocorre quando um agente se compromete com uma interpretação plausível, mas não intencional, do objetivo de uma tarefa. O agente produz um pipeline limpo e executável e um artefato de submissão válido, no entanto, o enquadramento subjacente da tarefa (alvo de previsão ou objetivo de avaliação) está incorreto. Como o pipeline é executado com sucesso e o formato de submissão está correto, benchmarks padrão — que pontuam principalmente a execução do pipeline e a validade do artefato — falham em detectar essa falha.

Os benchmarks atuais (por exemplo, DS-1000, DSBench, MLE-bench) geralmente fornecem prompts totalmente especificados onde o alvo de previsão, a forma de saída e a métrica de avaliação são explicitamente definidos. No entanto, os fluxos de trabalho reais de ciência de dados frequentemente carecem desses compromissos; as partes interessadas fornecem um objetivo e dados, deixando ao modelador a decisão do que constitui o alvo e o sucesso. O artigo argumenta que a capacidade de reconhecer quando uma tarefa está subespecificada (ou seja, quando a observação prompt-dados não justifica um compromisso único) e de solicitar esclarecimentos antes de agir é uma competência ausente nas avaliações atuais de agentes.

Metodologia

Os autores introduzem o Ambig-DS, um benchmark diagnóstico pareado projetado para isolar e medir a ambiguidade de enquadramento de tarefa. O benchmark consiste em duas suites analisadas independentemente:

1. Ambig-DS-Target (51 tarefas): Construído sobre o DSBench (modelagem tabular).
   • Intervenção: Edições controladas de prompt-dados onde a coluna alvo real é renomeada (por exemplo, para val_1) e um alvo isca plausível (val_2) é adicionado. O prompt é reescrito para usar linguagem genérica (por exemplo, "prever valor") em vez de nomes específicos de alvo.
   • Construção: O alvo isca é projetado para ter a mesma distribuição marginal que o alvo real, mas é impulsionado por um conjunto diferente de características. O ruído é calibrado para que a isca seja quase tão previsível a partir das características quanto o alvo real, impedindo que os agentes as distingam por meio de verificações simples de correlação ou aprendibilidade.
2. Ambig-DS-Objective (61 tarefas): Construído sobre o MLE-bench (competições no estilo Kaggle).
   • Intervenção: Apenas edições de prompt onde referências explícitas a métricas (por exemplo, "ROC-AUC", "RMSE") são removidas e substituídas por frases genéricas como "um procedimento de avaliação padrão". Os dados, o alvo e o formato de submissão permanecem inalterados.
   • Objetivo: Criar ambiguidade sobre se o agente deve submeter probabilidades, rótulos rígidos ou como otimizar (por exemplo, maximizar versus minimizar).

Protocolo de Verificação:
Cada variante ambígua passa por um pipeline de verificação rigoroso envolvendo revisão humana e auditorias de LLM de diferentes famílias contra uma lista de verificação de quatro itens:

• Alternativas Plausíveis: Pelo menos dois enquadramentos razoáveis existem.
• Preservação da Ambiguidade: Nenhuma pista revela o enquadramento pretendido no prompt ou nos dados.
• Relevância da Decisão: Resolver a ambiguidade altera uma escolha crítica em nível de tarefa (por exemplo, seleção de alvo, tipo de saída).
• Preservação da Tarefa: A edição não altera informações de tarefa não relacionadas.

Condições de Avaliação:
Os agentes são avaliados sob três condições:

1. Completo: A tarefa original, totalmente especificada.
2. Ambig.: A variante ambígua sem nenhum canal de esclarecimento. Os agentes devem comprometer-se silenciosamente.
3. Perguntar: A variante ambígua onde o agente pode fazer uma pergunta de esclarecimento autossuficiente (≤50 palavras) a um Oráculo de Esclarecimento antes da modelagem. O oráculo responde com verdade, mas é restrito à variável de enquadramento específica faltante (nome do alvo ou detalhes da métrica) e recusa solicitações fora do escopo.

Principais Contribuições

1. Formalização do Enquadramento de Tarefa: O artigo isola duas variáveis de enquadramento centrais: o alvo de previsão ($T$) e o objetivo de avaliação ($M$). Define "enquadramento incorreto não sinalizado" como a falha em reconhecer a subespecificação e comprometer-se com um enquadramento não intencional sem perguntar.
2. Benchmark Ambig-DS: O lançamento de duas suites diagnósticas (112 tarefas pareadas no total) construídas por meio de intervenções controladas que preservam os avaliadores originais do benchmark de origem. Isso garante que as quedas de desempenho sejam atribuídas exclusivamente à ambiguidade de enquadramento, e não a mudanças nas regras de pontuação.
3. Quantificação Empírica: O artigo quantifica a prevalência do enquadramento silencioso incorreto e a calibração do comportamento "perguntar antes de agir" em cinco agentes de ponta e eficientes baseados em código (Gemini 3 Flash/Pro, GPT-5.4 Nano/Pro, Claude Haiku 4.5).

Resultados

1. O Enquadramento Silencioso Incorreto é Prevalente

Em todos os agentes, a ambiguidade induz degradação significativa de desempenho:

• Ambiguidade de Alvo: Os agentes comprometem-se com um alvo errado em 39–63% das execuções ambíguas (dependendo do modelo). Estes são pipelines válidos e executáveis que resolvem o problema errado.
• Ambiguidade de Objetivo: Os agentes exibem falha silenciosa em 16–62% das execuções. Isso se divide em dois modos:
  • Enquadramento Incorreto: Otimização para uma métrica plausível, mas não intencional (por exemplo, precisão em vez de AUC).
  • Abdicação: Submissão de uma linha de base degenerada (por exemplo, previsões constantes) em vez de tentar resolver a ambiguidade.
• Comprometimento Silencioso: Mesmo quando os agentes reconhecem a ambiguidade em seus rastros internos, raramente sinalizam o compromisso final como passível de anulação pelo usuário. A falha é caracterizada por um "comprometimento silencioso" com um enquadramento padrão.

2. O Esclarecimento Recupera o Desempenho

Quando os agentes podem fazer uma única pergunta ao oráculo:

• Recuperação: O desempenho recupera-se significativamente, com $\Delta_{ask}$ (pontuação Perguntar menos pontuação Ambig) variando de +0,03 a +0,20.
• Capacidade versus Detecção: Os agentes demonstram a capacidade de integrar informações de enquadramento quando fornecidas perfeitamente (a recuperação é alta), mas carecem da calibração para detectar quando perguntar.
• Falha de Calibração: Nenhuma combinação de modelo-prompt alcança calibração robusta:
  • Prompts Permissivos: Levam a alta sensibilidade (recall) em tarefas ambíguas, mas a altos falsos positivos (perguntas desnecessárias) em tarefas totalmente especificadas.
  • Prompts Conservadores: Reduzem falsos positivos, mas suprimem perguntas legítimas em tarefas ambíguas, levando a compromissos silenciosos padrão.

3. Assinaturas de Falha

• Suite de Alvo: As falhas são submissões discretas de alvo errado.
• Suite de Objetivo: As falhas são uma mistura de enquadramento incorreto substantivo (métrica errada) e abdicação (desistir).
• Consistência entre Suites: O padrão de degradação sob ambiguidade e recuperação sob esclarecimento mantém-se entre diferentes famílias de modelos (Gemini, GPT, Claude) e não é um artefato dos oráculos ou modelos juízes específicos utilizados.

Significado e Alegações

O artigo alega que reconhecer a subespecificação de alvo e objetivo é o gargalo ausente nas avaliações padrão de agentes de ciência de dados.

• Desacoplamento de Competência: O trabalho separa a competência de execução de pipeline (o agente consegue executar código?) da competência de enquadramento de tarefa (o agente sabe o que resolver?). Benchmarks padrão confundem essas competências ao assumir que a tarefa está totalmente especificada.
• Sinais Acionáveis:
  • Para Usuários: Variáveis de enquadramento (alvo, métrica, tipo de saída) devem ser especificadas explicitamente; omiti-las causa quedas de desempenho confiáveis, mesmo para agentes capazes.
  • Para Construtores: A "calibração perguntar-agir" deve ser um alvo concreto para pós-treinamento ou engenharia de prompts. Estratégias de prompts atuais deslocam o ponto de operação, mas não produzem sensibilidade robusta à ambiguidade relevante para decisões.
  • Para Designers de Benchmark: Os benchmarks devem parear tarefas totalmente especificadas com variantes diagnósticas ambíguas para evitar superestimar a competência do agente.

Os autores mantêm uma postura modesta, observando que o Ambig-DS é uma suite diagnóstica controlada, e não um censo de toda a ambiguidade do mundo real. Os resultados estimam modos de falha sob ambiguidade verificada e relevante para decisões, em vez de fornecer uma taxa de prevalência para todas as tarefas de ciência de dados. O estudo destaca que, embora os agentes possam usar informações faltantes se oferecidas, atualmente não conseguem detectar de forma confiável quando precisam delas.