MapSatisfyBench: Benchmarking Satisfaction-Aware Map Agents through Behavior-Grounded Implicit Decision Factors

Resumo Técnico do MapSatisfyBench

Definição do Problema
Agentes de Grandes Modelos de Linguagem (LLMs) são cada vez mais implantados em serviços de mapas para traduzir solicitações em linguagem natural em ações, como navegação de rotas e planejamento de viagens. No entanto, consultas de mapas do mundo real são frequentemente subespecificadas; os usuários fornecem solicitações curtas e incompletas, esperando que o agente infira necessidades não ditas. Diferente de perguntas de busca de fatos com verdades fundamentais únicas, as tarefas de mapa são inerentemente multi-solução. O desafio central é que a satisfação do usuário depende de fatores de decisão implícitos — condições críticas não declaradas explicitamente na consulta (por exemplo, um usuário que chega de trem precisando de transporte público em vez de dirigir) mas recuperáveis de fontes de informação disponíveis, como perfis de usuário e histórico de interação.

Os benchmarks atuais avaliam primariamente a conclusão da tarefa (o agente consegue planejar uma rota?) ou a fidelidade factual. Eles falham em medir se um agente pode recuperar proativamente esses fatores implícitos para selecionar a resposta mais provável de ser aceita pelo usuário. Além disso, avaliar essa capacidade é difícil porque: (1) nem todos os fatores implícitos são recuperáveis a partir das informações pré-resposta, e (2) a satisfação não pode ser reduzida a uma única resposta de referência ou a um rótulo binário de satisfeito/insatisfeito.

Metodologia
Para enfrentar esses desafios, os autores propõem um framework de restauração-identificação-filtragem e constroem o MapSatisfyBench, um benchmark fundamentado em evidências de cadeia de comportamento.

1. Construção do Framework:

   • Restaurar (Restore): Reconstrói a necessidade completa do usuário combinando informações pré-consulta (contexto $c$, perfil $p$), o ambiente espaço-temporal ($g$) e o comportamento pós-consulta ($h^+$). Isso cria uma base objetiva para o que o usuário pretendia.
   • Identificar (Identify): Compara a necessidade completa reconstruída com a consulta superficial para expor fatores de decisão não ditos que restringem o espaço de solução viável.
   • Filtrar (Filter): Retém apenas aqueles fatores implícitos suportados por evidências disponíveis antes do agente responder (ou seja, $g$ e $h^-$). Fatores que exigem esclarecimento pós-resposta ou dados indisponíveis são excluídos para garantir a avaliabilidade.

2. Anotação da Verdade Fundamental (Ground Truth):
   Em vez de uma única resposta de ouro, o benchmark define uma referência de decisão estruturada $G(x)$ contendo:

   • Fatores Explícitos ($E(x)$): Derivados da consulta superficial.
   • Fatores Implícitos Avaliáveis ($Z_{eval}(x)$): Recuperados via framework, anotados com um tipo de restrição (Hard vs. Soft) e um peso suportado por evidência ($s_i$). Restrições rígidas (ex: transporte indisponível) são binárias; preferências suaves são graduadas.
   • Anotações de Execução: Políticas de esclarecimento, trajetórias de ferramentas esperadas e requisitos de resposta factual.

3. Ambiente de Avaliação:
   O benchmark opera em um Sandbox de Replay Determinístico. Ele simula um agente de usuário impulsionado pela necessidade completa e um agente de negócio (o modelo sob teste) interagindo com um conjunto fixo de 22 ferramentas de serviço de mapa. As respostas das ferramentas são mocks determinísticos para garantir a reprodutibilidade.

4. Métricas:
   A avaliação cobre todo o pipeline de decisão com sete métricas:

   • ECR (Taxa de Conclusão de Fatores de Decisão Explícitos): Mede a satisfação dos requisitos declarados.
   • IISR (Taxa de Satisfação de Fatores de Decisão Implícitos): Uma média ponderada das pontuações de satisfação para fatores implícitos, distinguindo entre restrições rígidas (hard) e preferências suaves (soft).
   • AR (Probabilidade de Resposta Aceita): A métrica agregada primária, calculada como $ECR \times IISR$. Representa a probabilidade de uma resposta ser aceita.
   • TS (Precisão de Seleção de Ferramentas): Mede a seleção correta de ferramentas necessárias para recuperar evidências.
   • IFS (Pontuação de Fidelidade de Informação): Verifica afirmações factuais contra as saídas das ferramentas.
   • Eff (Eficiência de Interação): Normaliza o número de turnos de interação em relação a um orçamento de referência.
   • SES (Pontuação de Eficiência de Satisfação): Uma métrica composta ($AR \times Eff$) que recompensa decisões de alta qualidade feitas de forma eficiente.

Principais Contribuições

1. Metodologia: Uma abordagem inovadora para operacionalizar a satisfação subjetiva do usuário em fatores de decisão implícitos objetivos e suportados pelo comportamento, permitindo a avaliação sem rótulos diretos de satisfação.
2. Benchmark: A construção do MapSatisfyBench, derivado de dados de usuários reais anonimizados em larga escala, cobrindo diversos cenários de serviço de mapa com protocolos completos de avaliação de cadeia total.
3. Insights Diagnósticos: Evidência empírica revelando uma lacuna persistente entre a conclusão de tarefas superficiais e a tomada de decisão consciente da satisfação em agentes de LLM atuais.

Resultos Experimentais
Os autores avaliaram 12 agentes baseados em LLM (incluindo famílias GPT-4.1/5.3, Claude Opus/Sonnet 4.6, Gemini 3.1, DeepSeek e Qwen).

• Conclusão de Tarefa vs. Satisfação: Modelos de fronteira alcançaram altos escores de ECR (ex: GPT-5.3 em 0.9272), indicando forte capacidade de completar tarefas explícitas. No entanto, os escores de IISR e AR foram significativamente menores (o melhor IISR foi 0.7170 para Claude-4.6-opus), mostrando uma falha em satisfazer necessidades implícitas.
• Gargalo de Seleção de Ferramentas: Os escores de TS foram consistentemente baixos (variando de 0.28 a 0.49), mesmo para os melhores modelos. A análise revelou que os agentes raramente invocam proativamente ferramentas relacionadas ao perfil para recuperar evidências implícitas, preferindo pedir esclarecimentos aos usuários, o que aumenta a carga de interação.
• Modo de Pensamento (Thinking Mode): Habilitar o "modo de pensamento" melhorou o desempenho para alguns modelos (ex: o SES do Gemini-3.1-pro-preview aumentou de 0.2120 para 0.2724), mas não fechou totalmente a lacuna entre satisfação explícita e implícita.
• Variância de Domínio: O desempenho variou por domínio; planejamento de itinerário foi o mais fácil, enquanto consultas de informações em tempo real e transporte por aplicativo foram as mais difíceis. Os agentes tiveram maior dificuldade com fatores espaço-temporais em comparação com fatores de contexto ou de preferência.

Significância
O artigo afirma que o MapSatisfyBench desloca o paradigma de avaliação para agentes de mapa de "se a tarefa foi concluída" para "se a decisão satisfaz o usuário". Os achados sugerem que os agentes atuais, embora capazes de planejar e recuperar fatos, carecem da habilidade de adquirir proativamente evidências de fontes disponíveis para resolver ambiguidades. O benchmark serve como uma ferramenta diagnóstica para guiar o desenvolvimento de agentes que possam alinhar decisões espaciais abertas com necessidades de usuários suportadas pelo comportamento, reduzindo interações desnecessárias com o usuário enquanto melhora a qualidade da decisão.