Metodologia de benchmarking de inteligência da Artificial Analysis

Artificial Analysis Intelligence Index v4.3.2

Artificial Analysis Intelligence Index

O Artificial Analysis Intelligence Index combina um conjunto abrangente de conjuntos de dados de avaliação para avaliar as capacidades do modelo de linguagem em raciocínio, conhecimento, matemática e programação.

É uma síntese útil da inteligência geral do modelo de linguagem e pode ser usada para comparar modelos de linguagem. Como todas as métricas de avaliação, tem limitações e pode não se aplicar diretamente a todos os casos de uso. No entanto, estamos confiantes de que é uma comparação de síntese mais útil entre modelos de linguagem do que qualquer outra métrica existente hoje.

O Artificial Analysis Intelligence Index v4.3.2 incorpora 10 avaliações: AA-Briefcase v1.1, GDPval-AA v2.1, AutomationBench-AA, Terminal-Bench 4.0, SciCode, AA-LCR v1.1, AA-Omniscience, Humanity's Last Exam, GDP.pdf, CritPt. Nossa metodologia enfatiza a justiça e a aplicabilidade no mundo real.

Estimamos um intervalo de confiança de 95% para o Artificial Analysis Intelligence Index inferior a ±1% - com base em experimentos com >10 repetições em determinados modelos para todos os conjuntos de dados de avaliação incluídos no Artificial Analysis Intelligence Index v4.3.2. Os resultados da avaliação individual podem ter intervalos de confiança superiores a ±1%. Esperamos divulgar mais detalhes de nossa análise estatística no futuro.

Artificial Analysis Intelligence Index é um conjunto de avaliação baseado principalmente em texto e em inglês. Comparamos modelos para entradas de imagem, entradas de fala e desempenho multilíngue separadamente do conjunto de avaliação do Intelligence Index.

Conjunto de avaliação do Intelligence Index

O Intelligence Index é calculado como uma média ponderada em quatro categorias: Agentes (30%), Codificação (20%), Raciocínio Científico (20%) e Geral (30%). A ponderação enfatiza as tarefas de agência. A associação à categoria e os pesos por avaliação são mostrados abaixo.

CategoriaAvaliaçãoPerguntasTentativas por tarefaTipo de respostaPontuaçãoPeso no
Intelligence Index		Uso de
ferramentas		Privado
Agentes (30%)AA-Briefcase v1.191 tarefas em 4 cenários1Agentes que concluem tarefas e entregam arquivosElo combinado de comparações em pares do sucesso das tarefas segundo rubricas, da qualidade analítica e da qualidade de apresentação15%✓
GDPval-AA v2.1220 tarefas1Agentes que concluem tarefas e entregam arquivosComparação em pares (Elo) por um painel de avaliadores, ancorada em DeepSeek V4.1 Flash (max) em 1600, congelada e normalizada10%✓✗
AutomationBench-AA657 tarefas1Automação do fluxo de trabalho SaaS com ferramentas REST APICumprimento de objetivos; tarefas que violam uma medida de proteção recebem zero ponto5%✓
Programação (20%)Terminal-Bench 4.0663Execução de tarefas pelo terminalAprovação/reprovação na suíte de testes, pass@110%✗
SciCode288 subproblemas (conjunto de teste)3Código Python (deve passar em todos os testes de unidade)Execução de código, pass@1; pontuação por subproblema com informações de contexto anotadas por cientistas no prompt10%✗✗
Geral (30%)AA-Omniscience6,0001Resposta abertaPrecisão (10%) e 1 - Taxa de Alucinação (5%) como componentes separados15%✗
GDP.pdf100 tarefas em 10 domínios5Resposta de formato livre baseada em um longo PDFAll-pass como métrica principal e Mean Pass com peso igual por tarefa10%✗✗
AA-LCR v1.11003Resposta abertaLLM que verifica a equivalência das respostas, pass@15%✗✗
Raciocínio científico (20%)HLE (Humanity's Last Exam)2,1581Resposta abertaLLM que verifica a equivalência das respostas, pass@110%✗✗
CritPt705Funções Python, expressões simbólicas, respostas numéricasServidor de classificação oficial, pass@110%✗

Avaliações adicionais

Além do conjunto Intelligence Index, realizamos uma série de avaliações adicionais que abrangem recursos multilíngues, visuais, matemáticos e outros. Eles são relatados separadamente e não estão incluídos na pontuação do Intelligence Index.

Artificial Analysis Multilingual Index: representa a capacidade multilíngue dos modelos. Isso se baseia na avaliação Global-MMLU-Lite nos idiomas suportados. Apoiamos os seguintes idiomas:

  • 🇬🇧 English
  • 🇨🇳 Chinese
  • 🇮🇳 Hindi
  • 🇪🇸 Spanish
  • 🇫🇷 French
  • 🇸🇦 Arabic
  • 🇧🇩 Bangla
  • 🇵🇹 Portuguese
  • 🇮🇩 Indonesian
  • 🇯🇵 Japanese
  • 🇰🇪 Swahili
  • 🇩🇪 German
  • 🇰🇷 Korean
  • 🇮🇹 Italian
  • 🇳🇬 Yoruba
  • 🇲🇲 Burmese
CategoriaAvaliaçãoPerguntasTentativas por tarefaTipo de respostaPontuaçãoUso de
ferramentas		Privado
Agentes𝜏³-Banking975Simulação agente-usuário de controle duplo com recuperação de conhecimentoAvaliação do estado do banco de dados de back-end, pass@1✓✗
Harvey LAB-AA120 tarefas1Agentes que produzem entregáveis jurídicos em arquivosAvaliação dos critérios da rubrica por um único avaliador LLM, pass@1✓✓
APEX-Agents-AA452 tarefas3Agentes que concluem tarefas de serviços profissionaisClassificação de arquivo local baseada em rubrica, pass@1✓✗
AA-AnalystAgent80 em 14 domínios5Execução de código Python por um agente, com resposta final em formato livreAvaliação binária de correção por um LLM, com prevalência da verificação numérica prévia, pass^5✓✓
ITBench-AA59 cenários (públicos + privados)3Diagnóstico estruturado de causa raiz JSON do instantâneo do incidente Kubernetes off-lineCorrespondência de entidades normalizada por um LLM; precisão média com recall completo✓
EnterpriseOps-Gym-AA1.117 tarefas no modo oracle (8 domínios)3Uso de ferramentas MCP em vários turnos em servidores reiniciáveis de um ambiente de avaliação empresarialVerificadores de estado SQL baseados em resultados, taxa de sucesso estrita de pass@1✓✗
Terminal-Bench-Science 0.170 (5 domínios)3Execução de tarefas pelo terminalAprovação/reprovação na suíte de testes, pass@1✗
GeralIFBench2945Resposta abertaExtração e avaliação orientada por regras, pass@1✗✗
MLCR-AA60 perguntas (níveis especialista + composto)3Resposta abertaRequisito de concisão e painel de avaliadores LLM (maioria de 3 avaliadores sobre completude e exatidão), pass@1✗
OutrosGlobal-MMLU-Lite~ 6.000 (~ 400 por idioma)1Múltipla Escolha (4 opções)Extração Regex, pass@1✗✗
MMMU Pro1,7301Múltipla Escolha (10 opções)Extração Regex, pass@1✗✗

Princípios da avaliação de inteligência

A nossa abordagem de avaliação é guiada por quatro princípios fundamentais:

  • Padronizado: todos os modelos são avaliados sob condições idênticas com estratégias de prompting, configurações de temperatura e critérios de avaliação consistentes.
  • Imparcial: empregamos técnicas de avaliação que evitam penalizar injustamente os modelos por respostas que seguem corretamente as instruções em nossos prompts. Isso inclui o uso de prompts claros, métodos robustos de extração de respostas e validação flexível de respostas para acomodar variações válidas nos resultados do modelo.
  • Instruções zero-shot: Avaliamos com instruções claras, sem exemplos ou demonstrações, para testar a capacidade dos modelos de seguir orientações sem aprendizado few-shot. Essa abordagem se adequa aos modelos atuais ajustados para seguir instruções e conversar.
  • Transparente: divulgamos nossa metodologia, incluindo modelos de prompt, critérios de avaliação e limitações.

Parâmetros gerais de teste

Testamos todas as avaliações com as seguintes configurações:

  • Temperatura: 0 para modelos sem raciocínio, 0,6 para modelos com raciocínio (a menos que outra temperatura seja recomendada pelo laboratório de modelos)
  • Máximo de tokens de saída:
    • Modelos sem raciocínio: 16.384 tokens (ajustados para baixo onde os modelos têm uma janela de contexto menor ou limite máximo de tokens de saída menor)
    • Modelos de raciocínio: Máximo de tokens de saída permitidos, conforme divulgado pelos criadores do modelo (configuração personalizada para cada modelo de raciocínio)
  • Tratamento de erros:
    • Nova tentativa automática em falhas de API (até 30 tentativas)
    • Todas as perguntas que falharam em todas as 30 tentativas são revisadas manualmente. Os resultados em que falhas persistentes da API causaram problemas não são publicados. Erros em que todas as APIdisponíveis para modelos proprietários bloqueiam uma determinada pergunta podem diminuir as pontuações (esse efeito não é material)
  • Metodologia de pontuação: geralmente usamos pontuação pass@1 em nossas avaliações, onde um modelo deve produzir a resposta correta em sua primeira tentativa. Para avaliações com múltiplas repetições, pass@1 é calculado agregando os resultados de todas as repetições. Isso é calculado como:
    onde pi = 1 se a tentativa i estiver correta, 0 caso contrário, ek é o número total de instâncias de teste em todas as repetições.

Mantemos cópias internas de todos os conjuntos de dados de avaliação. As fontes de nossos conjuntos de dados selecionados estão listadas abaixo.

Para as avaliações do Artificial Analysis Intelligence Index, usamos as contagens de tokens informadas pelo provedor de API de cada modelo, quando disponível, para relatar com precisão o custo de execução do Intelligence Index. Nos raros casos em que as contagens de tokens do provedor não estão disponíveis, usamos um substituto do tokenizador canônico. Isso contrasta com a abordagem de benchmarking de desempenho, onde usamos contagens de tokens do lado do cliente do tokenizer o200k_base para padronizar contagens de tokens para o mesmo texto em todos os modelos. Ao relatar taxas e custos de acertos de cache, combinamos essas contagens de tokens com medições em tempo real da taxa de acertos de cache típica do modelo, em vez de confiar na medição única quando a avaliação foi executada.

Usamos e2b como nosso principal provedor de sandbox para benchmarks de agentes.

Avaliações do Artificial Analysis Intelligence Index

Avaliações que compõem o atual Artificial Analysis Intelligence Index, agrupadas por capacidade.

Agentes

AA-Briefcase v1.1

  • Status: Incluído no Artificial Analysis Intelligence Index v4.3.2 com ponderação de 15%.
  • Descrição: AA-Briefcase é uma novo benchmark para testar modelos em tarefas de trabalho de conhecimento realistas em projetos complexos criados por especialistas do setor. Os modelos são avaliados em projetos de trabalho de conhecimento de várias semanas, cada um com muitas tarefas vinculadas e milhares de arquivos de origem de entrada. AA-Briefcase combina rubricas e classificação em pares para avaliar o sucesso verificável da tarefa, a qualidade analítica e a qualidade da apresentação, proporcionando uma visão holística da capacidade geral do agente no trabalho do conhecimento.
  • Mudanças em relação ao AA-Briefcase v1: A v1.1 altera apenas o ajuste das pontuações Elo. Ajustamos as pontuações com um modelo Crowd-BT. Para comparar as entregas e , com parâmetros de força ajustados e e qualidade do anotador :
    Definimos , dando:
    em que é ajustado por dimensão com base em avaliações anteriores do AA-Briefcase. A avaliação por rubricas é decidida por uma comparação determinística, e não por um avaliador, portanto nessa dimensão. Embora as pontuações Elo mudem, a ordem dos modelos é preservada em grande parte.
  • Conjunto de dados de exemplo: https://huggingface.co/datasets/ArtificialAnalysis/AA-Briefcase-Lite
  • Ambiente de execução do agente: https://github.com/ArtificialAnalysis/Stirrup
  • Implementação:
    • Cada cenário AA-Briefcase é um problema de negócios realista de várias semanas, organizado como um fluxo de trabalho de várias semanas no qual o agente trabalha em sequência, com 2 a 5 tarefas por semana. Embora as tarefas dentro de um cenário compartilhem arquivos e contexto ao longo de semanas, os modelos atualmente completam cada tarefa em uma execução independente, sem transferir seus próprios envios anteriores. O agente recebe a descrição da tarefa e os arquivos de origem acessíveis e, em seguida, produz os arquivos de entrega final sem interação ao vivo ou feedback iterativo durante a execução.
    • Os conjuntos de fontes de cenários incluem arquivos compartilhados e arquivos específicos da semana, misturando materiais reais, aumentados e sintéticos. Os arquivos de origem são projetados para incluir artefatos profissionais realistas, como exportações do Slack, planilhas, PDFs, transcrições de entrevistas, pesquisas de mercado, documentos padrão, páginas de lojas de aplicativos, materiais do conselho, e-mails e outros registros comerciais. As tarefas posteriores da semana podem receber arquivos de caso base padronizados (os mesmos produtos de trabalho de referência fornecidos para cada modelo), de modo que cada tarefa permaneça executável de forma independente, preservando a continuidade ao longo da semana.
    • Os envios de modelos são executados com Stirrup em um sandbox E2B com escopo semanal.
      • Turnos: os agentes realizam até 500 turnos por tarefa.
      • Ferramentas: O agente recebe uma única ferramenta de execução de código que executa comandos shell e código dentro da sandbox, além das ferramentas de acabamento abaixo (e uma ferramenta de visualização de imagem quando o modelo suporta visão). A sandbox não tem acesso à Internet, portanto o agente só pode usar os arquivos de origem fornecidos.
      • Ambiente isolado: cada sandbox de cenário/semana é construído a partir dos arquivos de origem daquela semana, com pacotes Python padrão e ferramentas de sistema para processamento de documentos e computação científica pré-instalados.
      • Ferramentas de finalização: uma ferramenta de finalização, que o agente chama para enviar um resumo e os caminhos absolutos de suas entregas (validados como arquivos reais, não diretórios ou caminhos ausentes), e uma ferramenta abandon_task_finish (desistir), que ele chama com um motivo apenas quando conclui que a tarefa é genuinamente impossível.
    • Prompts: os prompts usados na geração e classificação:
      • Prompt de sistema do agente:
        You are an AI agent working on a specific task within a multi-week simulated workplace scenario. Each task is part of a longer workflow; your job is to complete the current task using the tools provided in up to 500 steps, then submit your deliverables.

When you are done you must call the `finish` tool as your final step, passing a brief summary of what you accomplished and a list of absolute paths for every deliverable file.

If you have genuinely concluded that the task cannot be completed — for example because required inputs are missing, a hard dependency is unavailable, or the request itself is incoherent — call the `abandon_task_finish` tool with a brief reason instead. Do not use it to escape difficulty.

You cannot interact with the user during the task. Record any clarifying assumptions you made in your finish summary.
      • Prompt de tarefa do agente:
        <execution_context>
## Sandbox

You operate inside an isolated Linux container through the `code_exec` tool, which runs shell commands and lets you read, create, and edit files. Commands run as the unprivileged user `user` (UID 1000), starting from `/home/user`. Passwordless `sudo` exists but is rarely needed, since your home directory is fully writable.

Every command runs independently: no working directory, environment variable, or other shell state carries over from one call to the next. Prefer absolute paths for both files and commands, and do not navigate with `cd` across calls — a `cd` in one command is gone by the next, so relying on it leaves you silently operating in the wrong place. When a step genuinely needs a different directory, chain it into the same command (e.g. `cd /home/user/work && python build.py`).

## No network

The container has no outbound connectivity, and there is no proxy, allowlist, or flag that can turn it on — treat the environment as permanently offline. Anything that reaches for the internet will fail, including package installs (`pip`, `npm`, `apt`), remote `git` operations, and any HTTP/HTTPS client request from any language.

Identify a network block by its error signature rather than by guessing: failed name resolution (`Could not resolve host`, `Temporary failure in name resolution`), an unreachable route (`Network is unreachable`, a refused or timed-out connection to a public host), or a stalled TLS handshake. When you see these, the failure is structural — do not retry the same call and do not hunt for a workaround (mirrors, alternate hosts, cached copies). Re-plan using only what is already installed and what ships inside your workspace.

## Filesystem

- Writable: everything under `/home/user/` plus `/tmp`. Use these for deliverables, intermediate files, and caches.
- Read-only inputs:
- `/home/user/shared/` — reference material shared across the whole scenario
- `/home/user/week/` — documents specific to this week's tasks
Copy these into a working folder before transforming them rather than editing them in place.

## Runtime

A broad scientific-computing and document-processing stack is already installed, so confirm what is present before assuming a gap:
- Python 3.13 with the usual data stack (numpy, pandas, polars, scipy), plotting (matplotlib, plotly), the scikit-learn ML family, and document tooling (python-docx, python-pptx, openpyxl, PyMuPDF, pdfplumber, reportlab, weasyprint, Pillow, opencv), plus Playwright.
- System tools include LibreOffice, Pandoc, Tesseract, FFmpeg, ImageMagick, Ghostscript, TeX Live, OpenJDK, Chromium, jq, and git.
- Check availability with `pip show <pkg>` or `which <tool>` instead of installing — installs fail offline, but almost anything you would reach for is already here.
- matplotlib runs headless (`MPLBACKEND=Agg`): write figures to files; never call `plt.show()`.
- Commands are terminated after 20 minutes. Keep them bounded, persist intermediate results to disk, and split long jobs into smaller steps.

## Submitting your work

Finish by calling the `finish` tool — anything not submitted through it is not graded. Your call must include:
1. A short summary of what you accomplished.
2. Absolute paths to every deliverable (files only, not folders).

Save each deliverable directly in `/home/user` under the exact filename the task asks for — not in a subdirectory.

Save deliverables as ordinary, visible files. Do not leave the only copy of your work in a dot-prefixed file or directory (e.g. `.submission.txt`, `.outputs/report.md`), including inside an archive; a `.zip` is fine when the task explicitly asks for one. Assume your files will be opened and edited by others after submission, so write them to last.

If the task genuinely cannot be completed, call the `abandon_task_finish` tool with a brief reason instead. Use it only when you have concluded the work is impossible — not to escape a difficult task.
</execution_context>

<scenario_overview>
{scenario_overview}
</scenario_overview>

<week_overview>
{week_overview}
</week_overview>

<task_description>
{task}
</task_description>

<deliverables>
Submit these files, by exact name, saved directly in `/home/user`:
{expected_output_filenames}
</deliverables>

Please begin working on the task now.
      • Prompt de classificação de rubrica binária:
        You are grading a submitted deliverable against one binary rubric check.

The user message contains:
- the task instructions,
- the rubric item,
- the submitted artifact content.

Submitted artifacts may appear as text blocks, image blocks, or parser notes for unsupported content.

Use only evidence from the submitted artifact content. Do not infer facts from filenames, task instructions, or rubric text unless the submitted artifact content supports them.

Beyond the task instructions and rubric in the user message, you only ever receive the submitted artifact itself, never the external source files it cites. Do not fail an item merely because you cannot open or cross-check a cited source — judge citations on whether they are present, specific, and well-formed in the submission, not on whether the source's contents can be independently confirmed.

Return a strict binary judgment:
- passed=true only if the pass criteria are satisfied.
- passed=false if any required element is missing, materially wrong, unsupported, or not evidenced.

Write concise reasoning that cites submitted artifact evidence or the absence of evidence.
Do not award partial credit.
    • Cada tarefa é avaliada em relação a dois estilos de verificações. Verificações de rubricas são critérios binários de aprovação/reprovação pontuados em um único envio. Verificações em pares comparam dois envios para a mesma tarefa e retornam um envio preferido ou empate. Existem dois tipos: Qualidade Analítica (cujo resultado tem uma análise mais profunda e melhor estruturada) e Apresentação (cujo resultado é apresentado de forma mais profissional).
    • A avaliação por rubricas e as comparações pareadas de qualidade analítica e apresentação usam, cada uma, um painel de três avaliadores em vez de um só. Isso reduz o viés a favor de entregas do mesmo modelo ou família de modelos. A avaliação por rubricas usa Claude Opus 4.8 com esforço máximo, GPT-5.5 com raciocínio alto e Gemini 3.1 Pro Preview com raciocínio alto. As comparações pareadas usam Claude Opus 5 com esforço alto, GPT-5.6 Sol com raciocínio médio e Gemini 3.8 Flash com raciocínio alto. Cada veredicto de rubrica e cada comparação pareada julgada por LLM são decididos por um avaliador selecionado do respectivo painel, com amostragem equilibrada entre verificações e confrontos. Para manter os resultados comparáveis, uma mesma verificação de rubrica é sempre avaliada pelo mesmo avaliador. AA-Briefcase Elo é a métrica principal: combina o Elo de qualidade analítica, o Elo de apresentação e a taxa de aprovação das rubricas. O desempenho nas rubricas é convertido em Elo por meio de confrontos sintéticos e uma agregação Elo de máxima verossimilhança. Cada dimensão é ajustada com um modelo Crowd-BT.
    • Integração ao Intelligence Index: Para inclusão no Intelligence Index, o Elo combinado do AA-Briefcase v1.1 é congelado quando um modelo é adicionado e normalizado por clamp((Elo - 500) / 2000). Essa é a mesma transformação aplicada ao GDPval-AA v2.1. A escala Elo está ancorada em GPT-5.5 (medium) em 1000, enquanto o intervalo fixo de normalização mantém estáveis as contribuições ao Intelligence Index ao longo do tempo. A Artificial Analysis pode atualizar os parâmetros de referência à medida que os modelos avançam nessa avaliação, para manter uma diferenciação significativa no Intelligence Index.

GDPval-AA v2.1

  • Descrição: GDPval-AA v2.1 é a estrutura de avaliação da Artificial Analysis para o conjunto de dados GDPval da OpenAI. Avalia as capacidades dos modelos linguísticos em tarefas economicamente valiosas, abrangendo 44 profissões em sectores-chave que contribuem para o PIB nos Estados Unidos.
  • Alterações em GDPval-AA v2: v2.1 altera apenas a forma como a escala Elo é fixada:
    • Ancoramos a escala fixando DeepSeek V4.1 Flash (max) em 1600.
    • Ajustamos as pontuações com um modelo Crowd-BT. Para comparar as entregas e , com parâmetros de força ajustados e e qualidade do anotador :
      Definimos , dando:
      em que é ajustado com base em avaliações anteriores do GDPval-AA.
    • Embora as pontuações Elo mudem, a ordem de classificação é amplamente preservada.
  • Artigo: https://arxiv.org/abs/2510.04374
  • Ambiente de execução do agente: https://github.com/ArtificialAnalysis/Stirrup
  • Conjunto de dados:
    • Baseamos nossa avaliação no conjunto de dados público ouro OpenAI GDPval de https://huggingface.co/datasets/openai/gdpval
    • Alguns arquivos do Microsoft Office no conjunto de dados tinham partes de metadados ausentes ou entradas de relacionamento malformadas que impediam o LibreOffice de abri-los. Adicionamos o mínimo de metadados ausentes e corrigimos as entradas malformadas para garantir a compatibilidade. O corpo do documento, o conteúdo do slide e o layout não foram alterados.
  • Implementação: Esta avaliação compreende duas etapas:
    • Envio de Tarefas – Os modelos recebem uma tarefa e são obrigados a produzir um ou mais arquivos.
    • Classificação em pares – Um juiz selecionado de um painel de três juízes de fronteira do LLM classifica cegamente duas submissões para a mesma tarefa, cada uma criada por um modelo diferente.
    • Cálculo de Elo: após coletar classificações pareadas, ajustamos elas a um modelo Crowd-BT por meio de estimativa de máxima verossimilhança e calculamos intervalos de confiança usando o estimador sanduíche para estabelecer nossa métrica Elo final. Ancoramos a escala Elo fixando DeepSeek V4.1 Flash (max) em 1600. Todas as outras classificações são ajustadas em relação a essa âncora.
    • Integração ao Intelligence Index: Para inclusão no Intelligence Index, o Elo do GDPval-AA v2.1 é congelado quando um modelo é adicionado e normalizado por clamp((Elo - 500) / 2000). A escala Elo está ancorada em DeepSeek V4.1 Flash (max) em 1600, enquanto o intervalo fixo de normalização mantém estáveis as contribuições ao Intelligence Index ao longo do tempo. A Artificial Analysis pode atualizar os parâmetros de referência à medida que os modelos avançam nessa avaliação, para manter uma diferenciação significativa no Intelligence Index.
  • Detalhes do envio da tarefa:
    • Todos os modelos são executados usando nosso ambiente de execução do agente de código aberto, Stirrup. Dentro do ambiente de execução, os modelos recebem um ambiente de execução de código (E2B sandbox) e as seis ferramentas a seguir para chamar a seu critério:
      • Web Fetch – busca e extrai o conteúdo principal de uma página da web como markdown.
      • Pesquisa na Web – Pesquisa na web usando a Brave Search API; retorna os 5 principais resultados com título, URL e descrição.
      • Visualizar imagem – Lê e exibe arquivos de imagem (.png,.jpg,.jpeg) do sandbox como tokens de imagem nativos para consumo de LLM. Esta ferramenta está exposta apenas a modelos com suporte de visão. As imagens são reduzidas para no máximo 1 megapixel antes de serem enviadas ao modelo.
      • Code Exec – Executa comandos bash no sandbox através da ferramenta code_exec; retorna código de saída, stdout e stderr.
      • Concluir – sinaliza a conclusão da tarefa e especifica quais arquivos enviar.
      • Abandon Task – Sinaliza que o modelo não acredita que possa concluir a tarefa, com um breve motivo, em vez de enviar arquivos.
    • Para cada tarefa, um novo sandbox E2B é inicializado com os arquivos de referência associados à tarefa específica e pré-instalado com uma variedade de pacotes relevantes para o conjunto de tarefas. Baseamos a coleção de pacotes no ambiente divulgado no artigo GDPval original, expandido na v2 com dependências adicionais (incluindo um conjunto de ferramentas TeX Live LaTeX completo e ferramentas de construção).

      Os pacotes do sistema são o fechamento transitivo fixo completo resolvido dentro da imagem base Debian trixie, então a maioria das entradas são dependências dos pacotes que instalamos diretamente

    • Solicitamos ao agente uma instrução interpolando o prompt de tarefa relevante, os arquivos de referência e os detalhes da ferramenta de conclusão.
  • Limites de Execução:
    • O LLM recebe 250 turnos para completar a tarefa. Um único turno é definido como uma mensagem do assistente e suas chamadas de ferramenta (se houver). À medida que o modelo se aproxima do limite, ele é notificado sobre o orçamento de turnos restante.
    • O modelo pode encerrar a execução mais cedo por meio da ferramenta Abandon Task, onde não acredita que possa concluir a tarefa, fornecendo um breve motivo em vez de enviar arquivos.
    • Se o modelo exceder 70% de sua janela de contexto após concluir um determinado turno, o agente solicitará que ele resuma o estado da tarefa, o trabalho concluído, os arquivos atuais, as etapas restantes e o contexto importante e, em seguida, limpará o histórico de turnos anteriores, mantendo o prompt da tarefa e o resumo para continuação.

Prompt do sistema de envio de tarefas:

You are an AI agent completing a standalone professional task. Your job is to use the provided tools to produce the requested deliverables within 250 steps, then submit your work.

When you are done, call the `finish` tool as your final step with:
1. A brief summary of what you accomplished.
2. Absolute paths to every deliverable file.

If you have genuinely concluded that the task cannot be completed because required inputs are missing, a hard dependency is unavailable, or the request is incoherent, call the `abandon_task_finish` tool with a brief reason instead. Do not use it to escape difficulty.

You cannot interact with the user during the task. Make reasonable assumptions when needed and record them in your finish summary.

Prompt de envio de tarefa:

## Runtime

You are running in an isolated Linux sandbox. Use the `code_exec` tool to read, create, and modify files. Commands run as the non-root user `user` (UID 1000). Default working directory is `/home/user`.

Every command runs independently: no working directory, environment variable, or other shell state carries over from one call to the next. Prefer absolute paths for both files and commands, and do not navigate with `cd` across calls — a `cd` in one command is gone by the next, so relying on it leaves you silently operating in the wrong place. When a step genuinely needs a different directory, chain it into the same command (e.g. `cd /home/user/work && python build.py`).

A broad scientific-computing and document-processing stack is already installed, so confirm what is present before assuming a gap:
- Python 3.13 with the usual data stack (numpy, pandas, polars, scipy), plotting (matplotlib, plotly), the scikit-learn ML family, and document tooling (python-docx, python-pptx, openpyxl, PyMuPDF, pdfplumber, reportlab, weasyprint, Pillow, opencv), plus Playwright.
- System tools include LibreOffice, Pandoc, Tesseract, FFmpeg, ImageMagick, Ghostscript, TeX Live, OpenJDK, Chromium, jq, and git.
- Commands are terminated after 10 minutes. Keep them bounded, persist intermediate results to disk, and split long jobs into smaller steps.

## Reference Files Location

(This section appears only when the task includes reference files.)

The reference files for the task are available in your environment's file system.

Here are their paths:

- [absolute path to each reference file]

## Completing Your Work

In order to complete the task you must use the `finish` tool to submit your work. If you do not use the `finish` tool you will fail this task!

As a last resort if you really cannot make any meaningful progress, use `abandon_task_finish` with a brief reason instead of submitting files.

**Required in your finish call:**
1. A brief summary of what you accomplished
2. A list of **ABSOLUTE file paths** for the required output files (Do not submit folders).

## Task

Here is the task you need to complete:

[task description]

Please begin working on the task now.
  • Estouro de contexto: se a próxima chamada de modelo (ou a própria solicitação de resumo) exceder a janela de contexto, o agente continuará desenrolando os turnos anteriores até que o resumo seja bem-sucedido.
  • Conclusão da tarefa: Para completar a tarefa, o LLM deve chamar a ferramenta de acabamento, fornecendo um resumo do trabalho realizado e os caminhos dos arquivos que pretende enviar. Esta ferramenta pode ser usada a qualquer momento.
  • Classificação: testamos correspondências de pares entre envios de modelos em dois estágios:
    • Amostragem equilibrada: primeiro amostramos cada modelo de forma diversificada, equilibrando a exposição entre tarefas, juízes e oponentes, para gerar classificações iniciais.
    • Amostragem ativa: após a fase inicial, fazemos a transição para a amostragem informada por Elo, que prioriza pares entre modelos com classificações semelhantes para obter o máximo de informações por comparação. Mantemos a exposição equilibrada das tarefas dentro de cada modelo ao longo do processo.
    • Os envios são anonimizados aleatoriamente como Envio A e B para mitigar qualquer modelo ou preconceito de posição do modelo do avaliador.
    • As correspondências são avaliadas por um painel de três juízes LLM de fronteira dos principais laboratórios, cada um executado em suas configurações de raciocínio padrão: GPT-5.6 Sol (medium reasoning), Gemini 3.8 Flash (high reasoning) e Claude Opus 5 (high effort). Fazemos uma amostragem entre os juízes para cada comparação. A tarefa inicial, todos os arquivos de referência e todos os arquivos de submissão são analisados ​​e fornecidos como contexto ao juiz.
    • Arquivos baseados em documentos (.pdf,.docx,.pptx,.xlsx, etc.) são analisados como texto e como imagens. Extraímos arquivos.zip e analisamos cada arquivo individual separadamente. Para tarefas contendo arquivos de áudio ou vídeo, a comparação é direcionada para o Gemini 3.8 Flash, que lida com essas modalidades nativamente. Este contexto está incorporado em uma solicitação de classificação que pede ao juiz para determinar qual das Submissões A e B responde melhor à tarefa.
    • Pontuação final: nossa pontuação final Elo é uma classificação Bradley-Terry calculada por meio da estimativa de máxima probabilidade de todas as comparações entre pares (empates contados como meias vitórias para cada lado), ancorada em DeepSeek V4.1 Flash (max) em 1600. Os intervalos de confiança de 95% são calculados usando o estimador sanduíche para quantificar a incerteza de classificação.

AutomationBench-AA

  • Descrição: AutomationBench-AA é uma execução de Artificial Analysis do AutomationBench de Zapier. Ele testa se os modelos podem concluir fluxos de trabalho SaaS realistas que abrangem vários aplicativos de negócios simulados, usando REST APIs como interface da ferramenta.
  • Artigo: https://arxiv.org/abs/2604.18934
  • Leaderboard: https://zapier.com/benchmarks
  • Repositório: https://github.com/zapier/AutomationBench
  • Conjunto de dados:
    • Avaliamos uma divisão retida privada de 657 tarefas do conjunto de dados AutomationBench versão 1.0.6
    • As tarefas abrangem seis domínios de negócios: Finanças, HR, Marketing, Operações, Vendas e Suporte
    • Eles são executados em ambientes de aplicativos simulados que incluem produtos como Gmail, Planilhas Google, Slack, Salesforce, Zendesk, Jira e HubSpot.
  • Implementação:
    • Executamos cada tarefa uma vez no ambiente multivoltas do AutomationBench, com um limite de 50 voltas. Os modelos usam o conjunto de ferramentas API, descobrindo e chamando os endpoints REST necessários por meio de chamadas de ferramentas estruturadas
    • Classificamos cada afirmação do AutomationBench como um objetivo, que deve ser concretizado pelo agente, ou como uma proteção, que inicialmente passa e não deve ser quebrada pelo agente.
    • Os objetivos e as proteções são classificados por meio de verificações programáticas do estado final do ambiente. AutomationBench-AA não usa um juiz LLM separado para avaliação
    • Para a pontuação do título, uma tarefa recebe 0 se o modelo violar qualquer proteção. Se nenhuma proteção for violada, a tarefa receberá a porcentagem de objetivos que o modelo completou. Tarefas com erro também pontuam 0
    • Cada tarefa pertence a um domínio de negócios, portanto, os detalhamentos de domínio são subconjuntos mutuamente exclusivos do conjunto de tarefas. As quebras de aplicativos não são mutuamente exclusivas: uma tarefa pode envolver vários aplicativos, portanto, seu objetivo e suas afirmações de proteção podem contribuir para mais de um aplicativo

Programação

Terminal-Bench 4.0

  • Descrição: A versão 4.0 do Terminal-Bench, desenvolvida por pesquisadores da Stanford University, do Laude Institute e da comunidade de código aberto. Abrange engenharia de software, administração de sistemas, processamento de dados, treinamento de modelos e segurança, com cada tarefa classificada por seu próprio conjunto de verificação.
  • Leaderboard: https://www.tbench.ai/?version=4
  • Conjunto de dados: https://github.com/harbor-framework/terminal-bench
  • Implementação:
    • Avaliamos o conjunto de dados completo do Terminal-Bench 4.0 (66 tarefas) usando o equipamento mini-swe-agent, com pontuação pass@1 média de 3 repetições por tarefa
    • Cada tarefa tem seu próprio conjunto de testes. Seguimos a metodologia Terminal-Bench: uma tarefa só será aprovada se todos os testes forem aprovados, a avaliação é executada no próprio contêiner de verificação separado de cada tarefa, isolado do ambiente do agente, e um verificador que excede seu tempo limite conta como uma falha
    • Aplicamos as seguintes restrições nas avaliações do agente:
      • O número máximo de etapas do agente é limitado a 500
      • Os tempos limite das tarefas e os recursos do sandbox seguem as definições de tarefa upstream
    • Todas as outras configurações do agente seguem os padrões do mini-swe-agent, incluindo a miniconfiguração interativa e prompts, a ferramenta bash nativa e nenhuma compactação ou resumo de contexto: o agente sempre vê sua transcrição completa

SciCode

  • Descrição: programação Python para resolver tarefas de computação científica.
  • Artigo: https://arxiv.org/abs/2407.13168
  • Conjunto de dados: https://scicode-bench.github.io/
  • Implementação:
    • Testamos com informações básicas anotadas por cientistas incluídas no prompt
    • Relatamos pontuação em nível de subproblema
    • Critérios de avaliação Pass@1
    • Os scripts de etapa do SciCode são classificados em executores isolados com um tempo limite de execução de 300 segundos (conjunto de dados v1.0.1)

Geral

AA-Omniscience

  • Descrição: AA-Omniscience é um benchmark de conhecimento e alucinações que mede a confiabilidade factual, recompensa o conhecimento preciso e penaliza suposições incorretas ou alucinações. Ele fornece uma avaliação detalhada da capacidade de um modelo de distinguir o conhecido do desconhecido em diversos domínios de conhecimento.
  • Artigo: https://arxiv.org/abs/2511.13029
  • Conjunto de dados: https://huggingface.co/datasets/ArtificialAnalysis/AA-Omniscience-Public
  • Implementação:
    • O benchmark consiste em 6.000 perguntas cobrindo 42 tópicos, incluindo Negócios, Ciências Humanas e Sociais, Saúde, Direito, Engenharia de Software e Ciências, Engenharia e Matemática.
    • Os modelos são pontuados usando o AA-Omniscience Index, que atribui pontos para respostas corretas, subtrai pontos para respostas alucinadas e mantém as abstenções neutras, recompensando as abstenções em vez de suposições incorretas
    • Cada resposta é classificada como CORRECT, INCORRECT, PARTIAL_ANSWER ou NOT_ATTEMPTED com base na resposta do modelo e na resposta verdadeira. GPT-5.6 Luna (medium) é usado como modelo de classificação
    • Integração ao Intelligence Index: AA-Omniscience contribui com dois componentes para o Intelligence Index: (1) Precisão - a proporção de respostas corretas, ponderada em 10% do Índice geral, e (2) Taxa de Não Alucinações - calculada como 1 menos a taxa de alucinações, ponderada em 5% do Índice geral (participação de 15% da AA-Omniscience).

GDP.pdf

  • Descrição: implementação da Artificial Analysis do Surge AI do GDP.pdf, um benchmark que testa se os modelos podem raciocinar em documentos profissionais longos e do mundo real e satisfazer critérios específicos de tarefas.
  • Artigo: https://arxiv.org/abs/2607.11192
  • Conjunto de dados: surgeai/GDP.pdf
  • Conjunto de avaliação: 100 tarefas em dez domínios profissionais, baseadas em 4.592 páginas PDF e avaliadas de acordo com 1.275 critérios. Tentamos cada tarefa cinco vezes, então cada modelo tem um denominador fixo de 500 tentativas.
  • Preparação e entrega de documentos: Preparamos cada PDF de origem com LiteParse 2.5.0, com OCR em inglês habilitado. Cada modelo recebe o texto completo extraído de cada página. Quando suportado pelo endpoint, enviamos as imagens da página primeiro na ordem das páginas, seguidas pela tarefa e concluímos o texto extraído em uma única mensagem do usuário. Modelos sem entrada de imagem recebem apenas texto. Renderizamos imagens de páginas a 150 DPI e as reduzimos, para um mínimo de 72 DPI, quando o contexto do modelo ou os limites de carga útil do provedor assim o exigem. Também podemos converter páginas opacas de PNG para JPEG. Onde um endpoint limita quantas imagens uma solicitação pode transportar, combinamos páginas em imagens compostas, duas páginas por imagem primeiro e até quatro onde o limite é mais restrito, cada célula rotulada com seu número de página. Após quatro páginas por imagem, as imagens cobrem apenas as páginas iniciais; as páginas restantes permanecem no texto extraído. Quando qualquer um deles se aplica, o prompt informa ao modelo que as imagens da página são compostas e o número da página onde a cobertura da imagem termina. Caso as imagens não caibam no contexto ou nos limites de tamanho da solicitação após a adaptação, enviamos apenas o texto completo extraído. Não truncamos nem resumimos o texto extraído. Os modelos respondem de uma só vez, sem navegação ou ferramentas.

    Ao contrário da implementação do Surge AI, não usamos recursos de entrada de documentos da API. Eles são opacos para o usuário e ficam acima da camada do modelo, para que possam introduzir variações nas decisões de produtos e hosts da API, em vez de comparar modelos idênticos.

  • Julgamento: GPT-5.6 Luna Medium julga cada critério de forma independente. Cada chamada recebe o prompt da tarefa, a resposta do concorrente e um critério, mas não o PDF de origem ou a identidade do concorrente. Aceitamos uma classificação de tarefa somente quando cada critério tiver um veredicto. Pontuamos erros, tentativas perdidas e falhas de entrada do terminal como zero.
  • Métricas informadas:
    • All-pass é a métrica principal: a parcela de todas as 500 tentativas em que todos os critérios foram aprovados.
    • Mean Pass é a métrica secundária: calculamos a taxa de aprovação no critério de cada tentativa e, em seguida, calculamos a média com peso igual entre tarefas e repetições.
    • Os cortes de domínio usam o mesmo cálculo de Mean Pass da macro de tarefa. Não informamos o domínio All-pass.
  • Escopo de custo e velocidade: os custos publicados cobrem apenas chamadas de modelos de concorrentes e excluem chamadas de juízes, preparação de PDF e OCR. Estimamos o tempo por tarefa a partir do uso do token de saída e da velocidade de saída do modelo. Exclui chamadas de juízes, preparação de PDF e OCR, portanto não é um momento de avaliação de ponta a ponta.

Diferenças da implementação do Surge AI

Artificial AnalysisSurge AI
Entrada de documentosTexto extraído com LiteParse e OCR, além de imagens de páginas para modelos com capacidade de imagemPDF bruto enviado para entrada de documentos do provedor
AvaliadorGPT-5.6 Luna MediumGemini 3.5 Flash

O conjunto de tarefas é compartilhado, mas a entrada e o julgamento do documento são diferentes, portanto, as pontuações de Artificial Analysis e Surge não são diretamente comparáveis.

AA-LCR v1.1

  • Descrição: avalie o desempenho de contexto longo testando recursos de raciocínio em vários documentos longos (aproximadamente 100 mil tokens medidos usando o tokenizer cl100k_base).
  • Alterações em AA-LCR: adiciona um prompt do sistema para esclarecer as instruções de avaliação, corrige 16 respostas e notas com GPT-5.6 Luna (medium). As pontuações não são diretamente comparáveis ​​com a v1.0.
  • Conjunto de dados: https://huggingface.co/datasets/ArtificialAnalysis/AA-LCR
  • Implementação:
    • 100 perguntas baseadas em texto, abrangendo 7 categorias de documentos (relatórios da empresa, relatórios do setor, consultas governamentais, academia, jurídico, materiais de marketing e relatórios de pesquisa)
    • Cerca de 100 mil tokens (medidos usando o tokenizer cl100k_base) de entrada por pergunta, exigindo que os modelos suportem uma janela de contexto mínima de 128K para pontuar neste benchmark. Cerca de 3 milhões de tokens de entrada exclusivos, abrangendo cerca de 230 documentos para executar o benchmark (os tokens de saída normalmente variam de acordo com o modelo)
    • As respostas do modelo são avaliadas usando GPT-5.6 Luna (medium) como um verificador de igualdade com pontuação pass@1

Raciocínio científico

HLE (Humanity's Last Exam)

  • Descrição: recente referência acadêmica de ponta do Centre for AI Safety (liderado por Dan Hendrycks).
  • Artigo: https://arxiv.org/abs/2501.14249v2
  • Conjunto de dados: https://huggingface.co/datasets/cais/hle
  • Implementação:
    • 2,158 questões somente de texto em matemática, humanidades e ciências naturais (da revisão de maio de 2025, que contém 2.500 questões no total — usamos o subconjunto somente de texto para máxima comparabilidade entre modelos)
    • Observamos que os autores do HLE divulgam que o processo de curadoria do conjunto de dados envolveu a seleção contraditória de perguntas com base em testes com GPT-4o, Gemini 1.5 Pro, Claude 3.5 Sonnet, o1, o1-mini e o1-preview (os dois últimos apenas para perguntas somente de texto). Portanto, desencorajamos a comparação direta desses modelos com modelos que não foram usados ​​no processo de curadoria HLE, pois o conjunto de dados é potencialmente tendencioso em relação aos modelos usados ​​no processo de curadoria.
    • Avaliado com um prompt do verificador de igualdade LLM adaptado do artigo HLE original, usando GPT-5.6 Luna (medium), com pontuação pass@1 (encontre o prompt abaixo)

CritPt

  • Descrição: Referência de raciocínio físico em nível de pesquisa com problemas de física de fronteira não publicados, abrangendo uma ampla variedade de subcampos.
  • Artigo: https://arxiv.org/abs/2509.26574
  • Site: https://critpt.com/
  • Repositório: https://github.com/CritPt-Benchmark/CritPt
  • Conjunto de dados: https://huggingface.co/datasets/CritPt-Benchmark/CritPt
  • Implementação:
    • Implementamos os componentes de nível 'desafio' para todos os 70 desafios do conjunto de testes (o desafio de exemplo está excluído) em colaboração com a equipe CritPt
    • Executamos 5 repetições para cada pergunta com pontuação pass@1
    • Os modelos são chamados com uma abordagem de análise em duas etapas, onde a primeira etapa solicita que o modelo complete o desafio com raciocínio, e a segunda etapa formata a resposta no formato de código esperado para classificação (veja exemplo de prompt para análise na página de avaliação CritPt)
    • O uso de token e as estimativas de custo refletem ambas as etapas (raciocínio e análise de respostas)
    • Os formatos de resposta incluem valores numéricos, expressões simbólicas em funções SymPy e Python (avaliadas com casos de teste)
    • O servidor de classificação oficial CritPt é usado para avaliar a correção de todas as respostas do desafio. O acesso à API de classificação é concedido caso a caso a laboratórios e pesquisadores aprovados. Envie um e-mail para critpt@artificialanalysis.ai para solicitá-lo e consulte a documentação da Artificial Analysis API para obter detalhes.

Detalhes das avaliações adicionais

Agentes

Harvey LAB-AA

  • Descrição: Harvey LAB-AA é a implementação da Artificial Analysis do Legal Agent Benchmark (LAB) da Harvey. Usa o conjunto de dados da Harvey com 120 tarefas privadas em 24 áreas da prática jurídica. Em cada tarefa, o agente lê os documentos do caso em um ambiente isolado e produz entregas jurídicas: memorandos, cronogramas de divulgação, resumos de depoimentos, documentos com alterações marcadas e outros trabalhos semelhantes. Um único avaliador LLM avalia as entregas critério por critério com uma rubrica específica da tarefa, composta de critérios individuais e binários de aprovação ou reprovação, oferecendo uma visão abrangente da capacidade agêntica em trabalhos jurídicos reais.
  • Conjunto de dados de exemplo: os cinco exemplos de tarefas públicas mostrados no explorador foram extraídos dos exemplos públicos de Harvey em https://github.com/harveyai/harvey-labs. Os números das manchetes são produzidos no conjunto de dados privado de 120 tarefas de Harvey, que não é divulgado publicamente.
  • Ambiente de execução do agente: https://github.com/ArtificialAnalysis/Stirrup
  • Implementação:
    • Cada tarefa é uma tarefa de trabalho jurídico independente em uma das 24 áreas de prática. O agente recebe as instruções da tarefa, um conjunto de documentos de entrada somente leitura e os nomes exatos dos arquivos das entregas que deve produzir e, em seguida, executa a tarefa em uma única execução, sem interação ao vivo ou feedback iterativo durante a execução.
    • Os documentos de entrada são os materiais do caso da tarefa – contratos, acordos, memorandos, transcrições e outros registros legais – armazenados como somente leitura na sandbox. O agente os copia em uma pasta de trabalho, os lê com as ferramentas de processamento de documentos disponíveis na sandbox e grava seus resultados (geralmente.docx,.xlsx ou.md) diretamente em seu diretório inicial com os nomes de arquivo exatos especificados pela tarefa.
    • Todos os modelos são executados usando nosso ambiente de execução do agente de código aberto, Stirrup.
      • Turnos: os agentes realizam até 200 turnos por tarefa.
      • Ferramentas: Dentro do equipamento, os modelos recebem um ambiente de execução de código em sandbox, e os modelos com capacidade de visão recebem adicionalmente uma ferramenta de visualização de imagens que lê arquivos de imagem da sandbox como tokens de imagem nativos para o modelo. O sandbox não possui acesso à internet, portanto o agente só poderá utilizar os documentos de entrada fornecidos e o software pré-instalado na imagem.
      • Ambiente isolado: cada tarefa é executada em um sandbox Linux isolado construído a partir de uma imagem base de avaliação de agente compartilhada (Debian + Python 3.13), com ferramentas de processamento de documentos como Pandoc, poppler/pdftotext, LibreOffice, python-docx, python-pptx, openpyxl, pdfplumber, PyMuPDF e markitdown pré-instalados. Os documentos de entrada da tarefa são preparados como somente leitura em tempo de execução; comandos shell individuais são encerrados após 20 minutos.
      • Ferramentas de finalização: uma ferramenta de finalização, que o agente chama para enviar um resumo e os caminhos absolutos de suas entregas (validados como arquivos reais, não diretórios ou caminhos ausentes), e uma ferramenta abandon_task_finish (desistir), que ele chama com um motivo apenas quando conclui que a tarefa é genuinamente impossível.
    • Diferenças do benchmark de Harvey: Harvey LAB-AA é uma reimplementação independente da Artificial Analysis, portanto, nossos números não são diretamente comparáveis aos resultados publicados pelo próprio Harvey. As principais diferenças:
      • Os envios devem corresponder ao nome de arquivo exato especificado nas instruções da tarefa. Um nome de arquivo quase errado conta como não produzido, o que é mais rigoroso do que a correspondência de melhor esforço de Harvey e pode diminuir nossas pontuações em relação às deles.
      • Um critério falha completamente, sem ser mostrado ao juiz, apenas quando nenhum dos seus resultados foi produzido. Uma submissão parcial - onde alguns dos arquivos declarados do critério estão presentes - ainda é julgada, sendo qualquer arquivo faltante marcado como ausente.
      • Gemini 3.1 Pro é usado como modelo de classificação.
      • Executamos as ferramentas de shell nativas do Stirrup em uma sandbox E2B com prompts de agente e juiz de autoria de Artificial Analysis, em vez da sandbox e ferramentas personalizadas de Harvey.
      • A implementação original de Harvey equipa o agente com ferramentas personalizadas e scripts de habilidades de geração de documentos (por exemplo, para produzir arquivos .docx, .xlsx e .pptx). Como não os fornecemos, os agentes produzem esses arquivos com as ferramentas de uso geral da sandbox.
    • Cada tarefa carrega uma rubrica de critérios de aprovação/reprovação binários, atômicos e igualmente ponderados. Cada critério é avaliado em relação ao texto extraído dos arquivos de entrega declarados do critério. A classificação é somente texto: o juiz vê o texto extraído das entregas, a descrição da tarefa e os critérios de correspondência do critério e retorna uma aprovação ou reprovação estrita, sem crédito parcial.
    • Duas métricas principais são relatadas: taxa de aprovação do critério, a parcela de critérios de rubrica atômicos de aprovação/reprovação que os resultados satisfazem (média sobre os critérios), e taxa de aprovação total, a parcela de tarefas em que cada critério é aprovado sem crédito parcial. A taxa de aprovação do critério é a métrica padrão mostrada em todo o site.
    • Prompts: os prompts usados na geração e classificação:
      • Prompt de sistema do agente:
        You are an AI agent completing a professional legal-work task. Use the tools provided to read the input documents, produce the requested deliverable files, and submit them within {max_turns} steps.

When you are done you must call the `{finish_tool_name}` tool as your final step, passing a brief summary of what you accomplished and a list of absolute paths for every deliverable file.

If you have genuinely concluded that the task cannot be completed - for example because required inputs are missing or a hard dependency is unavailable - call the `{abandon_task_finish}` tool with a brief reason instead. Do not use it to escape difficulty.

You cannot interact with the user during the task. Make reasonable assumptions when needed and record them in your finish summary.
      • Prompt de tarefa do agente:
        <execution_context>
## Sandbox

You operate inside an isolated Linux sandbox through the `code_exec` tool, which runs shell commands and lets you read, create, and edit files. Commands run as the unprivileged user `user` (UID 1000).

Files you write persist on disk across calls, but **shell state does not**: each command runs in a fresh shell, so no working directory, environment variable, or other shell state carries from one call to the next. Always use absolute paths for files, and do not navigate with `cd` across calls - a `cd` in one command is gone by the next. When a step genuinely needs a different directory, chain it into the same command (e.g. `cd /home/user && python build.py`).

## No network

The sandbox has no outbound connectivity, and there is no proxy, allowlist, or flag that turns it on - treat it as permanently offline. Anything that reaches the internet will fail: package installs (`pip`, `npm`, `apt`), remote `git`, and any HTTP/HTTPS request.

Recognise a network block by its error signature - failed name resolution (`Could not resolve host`, `Temporary failure in name resolution`), an unreachable route (`Network is unreachable`), or a stalled connection - rather than guessing. When you see these the failure is structural: do not retry the same call or hunt for a workaround (mirrors, alternate hosts, cached copies). Re-plan using only what is already installed and the files in your workspace.

## Filesystem

- Writable: everything under `/home/user/` plus `/tmp`. Use these for deliverables, intermediate files, and caches.
- Read-only inputs: `/home/user/documents` - the task's input documents. Copy these into a working folder before transforming them rather than editing them in place.

## Runtime

A document-processing stack is already installed - check what is present before assuming a gap:

- **Reading inputs**: `pandoc` or `python3 -c "import docx; ..."` for Word; `pdftotext` or `python3 -c "import pdfplumber; ..."` for PDFs; `python3 -c "import openpyxl; ..."` for Excel; `markitdown <path>` as a general-purpose extractor for .docx, .xlsx, .pptx, and .pdf. `libreoffice` (the `soffice` binary) is also installed - use `soffice --headless --convert-to pdf <path>` to convert any Office format (.docx/.xlsx/.pptx, including legacy .doc/.xls) when the python parsers fall short.
- **Producing deliverables**:
  - `.docx`: `python3 -c "from docx import Document; ..."` or `pandoc -o out.docx`.
  - `.xlsx`: `python3 -c "import openpyxl; ..."`.
  - `.md` and other plain text: write directly with `cat`/`tee`/your script.
- Check availability with `pip show <pkg>` or `which <tool>` rather than installing - installs fail offline, but the document stack above is already present.
- Commands are terminated after {command_timeout_minutes} minutes. Keep them bounded, persist intermediate results to disk, and split long jobs into smaller steps.

## Submitting your work

Finish by calling the `{finish_tool_name}` tool - anything not submitted through it is not graded. Your call must include:
1. A short summary of what you accomplished.
2. Absolute paths to every deliverable (files only, not folders).

Save each deliverable directly in `/home/user` under the exact filename the task asks for - not in a subdirectory. Save deliverables as ordinary, visible files - do not leave the only copy of your work in a dot-prefixed file or directory (e.g. `.report.docx`, `.output/report.docx`). Assume your files will be opened and edited by others after submission.

If the task genuinely cannot be completed, call the `{abandon_task_finish}` tool with a brief reason instead. Use it only when you have concluded the work is impossible - not to escape a difficult task.
</execution_context>

<task>
### {title}

{instructions}
</task>

<deliverables>
Submit these files, by exact name, saved directly in `/home/user`:
{expected_deliverables}
</deliverables>

Please begin working on the task now.
      • Prompt do sistema de avaliação (contexto da tarefa e produto de trabalho):
        You are evaluating a legal AI agent's work product against one binary quality criterion.

<task_context_for_work_product>
The work product below was produced for this legal task. Use the task only as context for what the deliverables were meant to address - judge the work product, not the task.

{task_title}

{task_instructions}
</task_context_for_work_product>

<work_product>
{agent_output}
</work_product>
      • Prompt de critério do juiz:
        <criterion>
<title>
{criterion_title}
</title>
<match_criteria>
{match_criteria}
</match_criteria>
</criterion>

Return `pass` only if the work product satisfies the criterion as described; otherwise `fail`.

APEX-Agents-AA

  • Descrição: APEX-Agents-AA é uma implementação independente de Artificial Analysis do benchmark APEX-Agents da Mercor. Ele avalia o trabalho de agentes de longo prazo e entre aplicações em ambientes de serviços profissionais que abrangem bancos de investimento, consultoria de gestão e direito.
  • Artigo: https://arxiv.org/abs/2601.14242
  • Conjunto de dados:
    • Baseamos nossa avaliação no conjunto de dados público APEX-Agents de https://huggingface.co/datasets/mercor/apex-agents
    • Avaliamos 452 tarefas da versão pública de 480 tarefas (excluindo Investment Banking Worlds 244 e 246, que têm dependências de tempo de execução externas)
  • Implementação:
    • Cada tarefa é executada com 3 repetições e pontuada usando pass@1 - uma repetição só é aprovada se todos os itens da rubrica forem satisfeitos e a pontuação do placar for a taxa média de aprovação entre as repetições
    • Todos os modelos são executados usando nosso ambiente de execução do agente de código aberto, Stirrup, com um limite de 200 turnos por tarefa
    • Os agentes operam dentro do ambiente Archipelago e acessam ferramentas do local de trabalho por meio de servidores MCP expostos por seu gateway
    • O agente começa com um pequeno conjunto de ferramentas de meta-ferramentas e deve gerenciar explicitamente as ferramentas apoiadas pelo MCP usando:
      • Listar Ferramentas – Mostra quais ferramentas estão disponíveis no momento
      • Ferramenta de inspeção – inspeciona uma ferramenta antes de adicioná-la
      • Adicionar ferramenta – Disponibiliza ao agente uma ferramenta apoiada pelo MCP
      • Remover ferramenta – Remove ferramentas que não são mais necessárias
    • O agente também recebe:
      • Todo Write – Cria ou atualiza a lista de tarefas do agente. Ele pode substituir a lista completa ou mesclar atualizações por ID de tarefa, e todas as tarefas devem ser concluídas ou canceladas antes que o envio final seja aceito
      • Concluir - Envia a resposta final do agente junto com um status de conclusão. É a única maneira de enviar uma resposta final, e apenas uma submissão concluída concluída prossegue para a avaliação
    • As chamadas de ferramenta MCP têm um tempo limite de 60 segundos. As saídas da ferramenta são truncadas quando necessário para um orçamento de token de 24 mil usando um trecho inicial de 20 mil caracteres e um trecho final de 5 mil caracteres. As entradas de imagem são compactadas para aproximadamente 1 MP antes de serem devolvidas ao modelo
    • A avaliação é executada localmente com o Archipelago classificador de arquivo local. Cada repetição é avaliada de acordo com a rubrica da tarefa usando a resposta final enviada por meio de Concluir e a diferença do sistema de arquivos entre os instantâneos mundiais iniciais e finais. Uma repetição só será aprovada se todos os itens da rubrica forem satisfeitos. Gemini 3 Flash com raciocínio 'baixo' é usado como juiz do LLM

AA-AnalystAgent

  • Descrição: AA-AnalystAgent é o benchmark de análise de dados de ponta a ponta da Artificial Analysis. Um agente responde a perguntas quantitativas em domínios comerciais e científicos, trabalhando a partir de planilhas e documentos de origem fornecidos como entradas primárias e executando Python em um ambiente de execução de código em área restrita. AA-AnalystAgent é relatado como um placar independente e não é um componente do Artificial Analysis Intelligence Index.
  • Ambiente de execução do agente: https://github.com/ArtificialAnalysis/Stirrup
  • Conjunto de dados:
    • AA-AnalystAgent é uma referência privada; o conjunto de perguntas, as respostas de referência e os arquivos de origem não são divulgados publicamente, para limitar o risco de contaminação
    • 80 questões quantitativas em 14 domínios empresariais e científicos, incluindo relatórios ambientais, estatísticas comerciais e de commodities, relatórios de despesas de saúde, dados hidrológicos e meteorológicos, dotações governamentais, modelos de custos de energia, modelos financeiros e cronogramas de projetos
    • As perguntas abrangem cinco arquétipos de fluxo de trabalho funcional que abrangem a difusão do trabalho real do analista: pesquisa e diagnóstico de origem, filtro e total, índices, tendências e sensibilidades, modelagem de P&L e modelagem de caixa, balanço patrimonial e avaliação
    • Cada pergunta é acompanhada de uma pasta de planilhas e documentos de referência (xlsx, docx) que é carregada no espaço de trabalho do agente. Uma resposta de referência de autoria humana é fornecida pelo agente e usada pelo avaliador no momento da pontuação
    • As respostas de referência são validadas independentemente pela Artificial Analysis
  • Implementação:
    • Cada questão é executada com 5 repetições independentes. A pontuação da tabela de classificação é pass^5 — a parcela de perguntas respondidas corretamente em cada uma das 5 tentativas:
      onde pji = 1 se a tentativa i na questão j estiver correta, 0 caso contrário, en é o número de questões. Isso se afasta da pontuação pass@1 que usamos em nossas outras avaliações: um agente analista só é útil se suas respostas se mantiverem sem nova verificação, portanto, a métrica principal recompensa a reprodução de uma resposta correta em vez de alcançá-la ocasionalmente
    • Juntamente com pass^5 calculamos pass@1 (a taxa média de aprovação por tentativa, agregada em todas as repetições) e pass@5 (a proporção de questões resolvidas em pelo menos uma tentativa), que separam a confiabilidade de um modelo de seu teto
    • Todos os modelos são executados como agentes usando nosso ambiente de execução do agente de código aberto, Stirrup, com um limite de 100 turnos por tarefa
    • O agente recebe um pequeno conjunto de ferramentas que cobre a execução de código em uma sandbox Linux isolada (Python 3.12 com os arquivos de referência da pergunta montados e um conjunto fixado de bibliotecas de análise de dados padrão Python pré-instaladas), busca de URL, visualização de imagens para modelos com capacidade de visão e envio de resposta final. Os modelos são instruídos a enviar apenas o valor da resposta (por exemplo, apenas o número ou rótulo), sem explicação
    • Cada resposta é classificada como binária correta ou incorreta em relação à resposta de referência mantida. Cada célula é enviada para um juiz LLM para que a classificação dos artefatos e a contabilidade dos custos do juiz permaneçam uniformes. Uma pré-verificação de equivalência numérica determinística substitui então o juiz em casos inequívocos: uma resposta igual ao valor de referência, na mesma convenção de unidade, com a precisão que a questão pede, é uma aprovação garantida. A pré-verificação é unilateral – nunca deixa de responder – então tudo o que não consegue resolver mantém o veredicto do juiz. Se o juiz retornar uma resposta malformada em uma célula a pré-verificação pode ser resolvida, a pré-verificação ainda registra uma aprovação. Gemini 3 Flash (Reasoning) é usado como juiz do LLM

Prompt do agente: o agente recebe o seguinte modelo, interpolando os arquivos de referência da pergunta, a tarefa e o nome da ferramenta de conclusão:

You are tasked with answering a data analysis question.

## Environment

The `code_exec` tool provides access to a Linux-based execution environment with a full file system where you can create, read, and modify files.

Python 3.12 is the default runtime. Use `python script.py` to run scripts.
The following Python packages are preinstalled (pinned versions):

- numpy 2.4.4, numpy-financial 1.0.0, pandas 3.0.2, scipy 1.17.1, polars 1.40.0
- matplotlib 3.10.8, seaborn 0.13.2
- scikit-learn 1.7.2, statsmodels 0.14.4
- openpyxl 3.1.5, xlrd 2.0.2, python-docx 1.2.0, formulas 1.3.4
- PyMuPDF 1.27.2.2, pdfplumber 0.11.9
- Pillow 12.2.0, requests 2.33.1, beautifulsoup4 4.13.4
- tqdm 4.67.3, tabulate 0.10.0, sympy 1.14.0

## Reference Files

The following reference files are available in your workspace:

<reference_files>
{reference_files}
</reference_files>

## Task

<task>
{task}
</task>

## Submitting Your Answer

When you have determined the answer, use the `{finish_tool_name}` tool to submit it.
Your answer should be a concise, direct response to the question.
If the question asks for a number, provide just the number.
If the question asks for a name or label, provide just that.
Do NOT include explanations in your answer — only the final answer value.

Prompt do avaliador: cada resposta (modelo, pergunta) é enviada a um juiz LLM com o seguinte aviso, interpolando a pergunta original, a resposta de referência mantida e a resposta enviada pelo agente. A pré-verificação numérica pode então substituir esse veredicto conforme descrito acima:

You are an expert evaluator grading a data analyst's response to a question.

Decide whether the response is correct or incorrect, judged against the reference answer and the standard a professional data analyst working in this question's domain would be held to. Focus on the substance of the answer, not prose style. Be objective and consistent, and give a brief explanation for your verdict.

First identify exactly what the reference requires — the specific value(s), item(s), or label(s) — and what the response actually commits to, then compare them directly before deciding.

Apply these conventions:

- Format directives are binding. If the question specifies a form or precision — a number of decimal places, "as a percentage", "to the nearest cent", a cell reference, particular units — the response must satisfy it. A right value in the wrong requested form is incorrect.
- Equivalent representations of the same value are correct. Thousands separators, currency symbols, surrounding whitespace, and trailing zeros are immaterial; a percentage and its decimal fraction (e.g. 12.84% and 0.1284) are the same value; adding or omitting a "%" sign never changes correctness when the digits already match the value the reference states; a quantity stated in the dataset's native units (e.g. thousands) matches the same amount written in full.
- Judge precision by value, to a sensible number of significant figures. When the question states a precision, require exactly that. When it does not, accept any answer that is a correct rounding of the reference value — reference answers often carry more decimal places than are meaningful (e.g. a dollar figure written as 64792.44714), and a competent analyst rounds sensibly, so do NOT reject an answer merely for having fewer decimals than the reference. Reject an answer only when its value genuinely differs from the reference (a wrong figure, not a coarser rounding of the same value) or when it discards so much precision that it misstates the quantity.
- Match every required item. If the question asks for more than one item (e.g. "which two tasks"), the response is correct only if it identifies exactly the reference's items. Judge the single set the response commits to and ignore hedged alternatives phrased as "(or ...)"; a response naming different items than the reference — however plausible — is incorrect.
- Honor explicit acceptance and rejection clauses in the reference answer. If the reference names specific values as acceptable or as not acceptable, follow it exactly.

## Question

{question_prompt}

## Reference Answer

{reference_answer}

## Response to Evaluate

{model_response}

EnterpriseOps-Gym-AA

  • Status: avaliação independente (não faz parte do Artificial Analysis Intelligence Index v4.3.2)
  • Descrição: EnterpriseOps-Gym-AA é uma implementação independente da Artificial Analysis do benchmark EnterpriseOps-Gym do ServiceNow, que avalia agentes de IA em planejamento com estado e em várias etapas e uso de ferramentas em fluxos de trabalho empresariais realistas. Os agentes operam sistemas corporativos ativos por meio de ferramentas e são classificados de acordo com o estado final dos bancos de dados subjacentes, e não com base na sequência exata de ações.
  • Artigo: https://arxiv.org/abs/2603.13594
  • Conjunto de dados: https://huggingface.co/datasets/ServiceNow-AI/EnterpriseOps-Gym
  • Ambiente de execução do agente: https://github.com/ArtificialAnalysis/Stirrup
  • Domínios: avaliamos as tarefas do modo oracle do benchmark em todos os oito domínios empresariais: gerenciamento de atendimento ao cliente (CSM), recursos humanos (HR), gerenciamento de serviços de TI (ITSM), e-mail, calendário, equipes e Drive, além de tarefas híbridas que exigem ações de orquestração em vários desses sistemas em um único fluxo de trabalho.
  • Implementação:
    • Cada tarefa é executada em uma sandbox isolada e reconfigurável: os sistemas corporativos relevantes são criados como servidores de academia independentes, cada um expondo suas ferramentas em um servidor Model Context Protocol (MCP) ativo e apoiado por um banco de dados SQLite específico da tarefa, semeado com dados sintéticos. Cada tarefa clona seu próprio banco de dados para que as execuções sejam isoladas e reproduzíveis.
    • Executamos o benchmark apenas em seu modo de ferramenta oracle: o agente recebe o conjunto de ferramentas necessárias para a tarefa, isolando o planejamento e a execução da recuperação da ferramenta. Os modos da ferramenta de distração do conjunto de dados de origem não são executados.
    • Todos os modelos são executados usando nosso ambiente de execução do agente de código aberto, Stirrup, em um ciclo padrão de uso de ferramentas de raciocinar e agir com um limite de 100 turnos por tarefa. Cada tarefa é executada com 3 repetições e a pontuação do título é a média das repetições.
    • A classificação é baseada em resultados. Depois que o agente termina, o estado final do banco de dados de cada tarefa é capturado e verificado com os verificadores SQL do benchmark, que testam a conclusão da meta, restrições de estado e integridade, permissão e conformidade do processo e a ausência de efeitos colaterais não intencionais.
    • Duas métricas são relatadas. O título taxa de sucesso é estrito pass@1: uma tarefa conta como sucesso apenas quando passa em todos os seus verificadores. Também informamos a taxa de aprovação do verificador, a parcela de verificações de verificadores individuais aprovadas, como uma métrica secundária mais refinada.
    • Diferenças em relação ao benchmark do ServiceNow: EnterpriseOps-Gym-AA é nossa implementação independente, executada em nosso próprio equipamento Stirrup e prompts do agente, portanto, nossos números não são diretamente comparáveis aos resultados relatados no artigo.

Terminal-Bench-Science 0.1

  • Status: avaliação independente (não faz parte do Artificial Analysis Intelligence Index v4.3.2)
  • Descrição: Terminal-Bench-Science é uma colaboração acadêmica aberta desenvolvida por pesquisadores da Stanford University com a equipe do Terminal-Bench e Harbour, e inclui contribuições de cientistas de instituições de todo o mundo. Suas tarefas de fluxo de trabalho de pesquisa são extraídas da prática científica real, e especialistas selecionam e revisam cada uma delas. Cada tarefa possui seu próprio conjunto de testes que o agente deve passar ao trabalhar em um terminal. A versão 0.1.0 cobre ciências da vida, físicas, matemáticas, engenharia e da terra.
  • Citação: https://doi.org/10.5281/zenodo.22110254
  • Leaderboard: https://terminal-bench-science.ai/
  • Conjunto de dados: https://github.com/harbor-framework/terminal-bench-science
  • Implementação:
    • Avaliamos a versão completa do Terminal-Bench-Science 0.1.0 (70 tarefas: 19 ciências biológicas, 17 ciências físicas, 17 ciências matemáticas, 9 ciências da engenharia, 8 ciências da terra) usando o equipamento mini-swe-agent, com pontuação pass@1 média de 3 repetições por tarefa
    • Cada tarefa tem seu próprio conjunto de testes. Uma tarefa será aprovada somente se todos os testes forem aprovados e a avaliação for executada no próprio contêiner verificador separado de cada tarefa, isolado do ambiente do agente
    • Aplicamos as seguintes restrições nas avaliações do agente:
      • Limitamos o agente a 1.000 passos
      • Os tempos limite das tarefas e os recursos do sandbox seguem as definições de tarefa upstream
    • Todas as outras configurações do agente seguem os padrões do mini-swe-agent

ITBench-AA

  • Status: avaliação independente (não faz parte do Artificial Analysis Intelligence Index v4.3.2)
  • Descrição: ITBench-AA é uma implementação independente de Artificial Analysis do IBM do ITBench, avaliando agentes de IA em Engenharia de Confiabilidade de Site (SRE): Análise da causa raiz do incidente do Kubernetes.
  • Artigo: https://arxiv.org/abs/2502.05352
  • Repositório: https://huggingface.co/datasets/ArtificialAnalysis/ITBench-AA
  • Ambiente de execução do agente: https://github.com/ArtificialAnalysis/Stirrup
  • Conjunto de dados:
    • Avaliamos 59 tarefas de incidente do Kubernetes: 40 do lançamento SRE público do IBM do ITBench e 19 tarefas privadas compartilhadas conosco pela equipe do ITBench. A pontuação do título é calculada em média em ambas as divisões
    • Cada tarefa é um instantâneo de incidente off-line do Kubernetes contendo alertas, eventos, rastreamentos, métricas, logs e topologia de aplicativo, incorporados em uma sandbox específica do cenário e montados em /home/user
  • Implementação:
    • Cada tarefa é executada com 3 repetições. A pontuação primária é a precisão na recuperação completa, uma repetição recebe 0,0 se perder qualquer entidade de causa raiz verdadeira; caso contrário, recebe precisão sobre as entidades submetidas.
    • Todos os modelos são executados usando nosso ambiente de execução do agente de código aberto, Stirrup com um limite de 100 turnos por tarefa. O loop do agente informa ao modelo de linguagem que seu limite de turno está se aproximando durante os últimos 20 turnos.
    • O agente recebe uma única ferramenta run_shell para inspecionar o snapshot, além de uma ferramenta finish para enviar sua resposta final. Ele deve escrever um diagnóstico JSON estruturado para /home/user/agent_output.json contendo o conjunto mínimo de entidades independentes do Kubernetes de causa raiz responsáveis pelo incidente, com raciocínio e evidências para cada uma, enquanto exclui sintomas posteriores
    • A avaliação usa um juiz LLM apenas para normalizar os contributing_factors nas entidades canônicas e grupos de alias verdadeiros.
    • Após a normalização, os grupos de alias de verdade são mesclados em grupos de pontuação, de modo que entidades equivalentes, como um pod e sua implantação/serviço correspondente, contam como a mesma previsão. Se qualquer membro de um grupo de alias for marcado como causa raiz, o grupo mesclado será pontuado como alvo de causa raiz; prever múltiplas entidades no mesmo grupo de alias conta apenas uma vez.
    • A precisão na recuperação completa é calculada como 0.0 se algum grupo de pontuação de causa raiz for perdido. Se nenhum grupo de causa raiz for perdido, será true_positives / (true_positives + false_positives), onde previsões sem correspondência e previsões mapeadas para grupos de causa não raiz contam como falsos positivos.
    • GPT-5.5 com esforço de raciocínio médio é usado como modelo de avaliação para comparar a saída do modelo com a verdade básica para cada tarefa
  • Prompt de geração:
    **Task**:

You are an expert SRE (Site Reliability Engineer) and Kubernetes SRE Support Agent investigating a production incident from OFFLINE snapshot data.

====================================================================
# INCIDENT SNAPSHOT DATA LOCATION
====================================================================
Your incident data and working directory is located in
- /home/user

The final output must be written to /home/user/agent_output.json

Available Python packages:
- `drain3==0.9.11`
- `numpy==2.4.5`
- `pandas==3.0.3`

Both `python` and `python3` are available and use the same environment.

Your objective is to generate a **JSON diagnosis** identifying the root causes of the incident — the minimal set of independent Kubernetes entities whose failures directly explain the incident.

Requirements:
- Provide reasoning and evidence for every listed entity.
- When the JSON file is ready, call the provided finish tool and submit `/home/user/agent_output.json`.

All entities MUST use the format: `namespace/Kind/name`

Examples:
- `otel-demo/Deployment/ad` (Deployment named "ad" in namespace "otel-demo")
- `otel-demo/Service/frontend` (Service named "frontend")
- `cluster/Node/worker-node-1` (cluster-scoped resource)

DO NOT include UIDs in the entity name.

====================================================================
## Output Format
====================================================================
Output must consist solely of the final diagnosis in the specified JSON format below — do **not** include any additional text, markdown, or comments:

```json
{
"contributing_factors": [
  {
    "name": "namespace/Kind/name",
    "reasoning": "A short, clear, human-readable explanation for why this entity is a root cause. Reference evidence where possible.",
    "evidence": "Concise summary of supporting facts — relevant alerts, events, logs, traces, or metrics. Plain string."
  }
]
}
```

====================================================================
# RULES FOR INCLUSION
====================================================================

**Only include an entity if both of the following are true:**

1. **There is qualifying evidence** — it appears in at least one of: a firing alert, a Kubernetes event, an error/warning log line, a metric anomaly, or trace evidence directly tied to the incident window. A passing mention in an unrelated log is not sufficient.

2. **It passes the irreducibility test** — you cannot fully explain its failure by pointing to another entity already in the list. Ask: *"If I remove this entity, does my explanation of the incident become incomplete?"* If yes, include it. If another entity already accounts for it, leave it out.

**Do not include** downstream effects, symptoms, or intermediates — only the independent upstream causes.

**Example (exhausted ResourceQuota blocking pod scheduling):**

Causal chain: ResourceQuota exhausted → ReplicaSet cannot schedule pods → Deployment degraded

- ✅ `otel-demo/ResourceQuota/otel-demo-mem-quota` — memory limit exhausted; directly blocks pod creation. Include.
- ❌ `otel-demo/ReplicaSet/ad-7f9d4b` — failed only because the quota above was exhausted. Exclude.
- ❌ `otel-demo/Deployment/ad` — degraded as a downstream consequence. Exclude.

**Multiple entries are allowed only if they are truly independent** — two separate upstream causes that do not explain each other.

When in doubt, prefer the most specific Kubernetes object that independently introduced the failure.

====================================================================
# INVESTIGATION WORKFLOW
====================================================================

### Phase 1 — Context Discovery
List available files (alerts, logs, events, topology).

### Phase 2 — Symptom Analysis
Read all alert files. Compute:
- Start time, End time, Duration, Frequency

### Phase 3 — Hypothesis Generation
- Create initial hypotheses (e.g. "checkout pods OOMKilled", "redis latency spike").
- Create a validation plan for each hypothesis.

### Phase 4 — Evidence Collection Loop
- Use tools (and generated python code) to gather log, event, metrics, trace evidence.
- Validate or refute each hypothesis using real data.
- Explain firing alerts as soon as you find supporting evidence.

### Phase 5 — Causal Chain Construction
Build a causal chain like
`[Config Error] → [CrashLoop] → [Service Down] → [Frontend 5xx]`

### Phase 6 — Conclusion
Ensure:
- All alerts are explained in the reasoning/evidence for the root causes, but do not add downstream entities only to account for alerts
- All included entities pass the irreducibility test
- JSON is written to `/home/user/agent_output.json`
- Call the finish tool and submit the file
  • Aviso de avaliação:
    You are an expert AI evaluator specializing in Root Cause Analysis (RCA) for complex software systems.

You will be provided with:

1. A **Ground Truth (GT)** JSON object containing entity definitions.
2. A **Generated Response** JSON object containing predicted entities.

Your job is only to normalize generated entities to ground-truth entities.

Ground Truth fields such as `groups`, `aliases`, `filter`, and `kind` may appear either at the top level of `GT` or under `GT.spec`. Treat `GT.spec` as the ground-truth payload when present.

-----

### Normalization Rules

Before any downstream scoring can occur, you must accurately normalize entities from the `Generated Response` to the `Ground Truth`.

This process must be based on **explicit evidence** from the entity's metadata.
You must not infer or guess mappings based on an entity's position in a causal chain.

Only normalize entities from `Generated Response.contributing_factors`.

An entity from the `Generated Response` can only be mapped to a `Ground Truth` entity if a **Confident Match** can be established.

**Definition of a Confident Match:**
A generated entity is a confident match to a ground-truth entity only if its `name` field, or other explicit identifying metadata, clearly corresponds to the `filter` and `kind` of a ground-truth entity.

**Alias Handling:**
The `GT.aliases` field contains arrays of equivalent entity IDs.
If a generated entity clearly matches an entity in an alias group, you may normalize it to the matching GT entity ID from that alias group.

**Workload Kind Equivalence:**
Treat `Deployment` and `Pod` as equivalent for normalization when the namespace and workload name correspond. For example, `otel-demo/Deployment/checkout` is a confident match for a GT `Pod` entity whose filter matches checkout pods in the `otel-demo` namespace.

**Entity Name Format:**
Generated entities use the format `namespace/Kind/name`.

Examples:
- `otel-demo/Deployment/flagd`
- `otel-demo/Service/frontend`
- `otel-demo/Pod/checkout-8546fdc74d-d68cn`

Confident match examples:
- A generated entity with `name: "otel-demo/Service/adservice"` is a confident match for the GT entity with `id: "ad-service-1"` and `filter: [".*adservice\\\\b"]`.
- A generated entity with `name: "otel-demo/Service/adservice"` can match `ad-pod-1` only if the GT alias set makes that link explicit, for example `["ad-pod-1", "ad-service-1"]`.
- If `GT.aliases` contains `["load-generator-pod-1", "load-generator-service-1"]`, then normalizing a generated `load-generator-service-1` match to that alias group is valid.
- A generated `chaos-mesh/Schedule/...` entity whose name matches a GT filter is a confident match for the spawned chaos resource of any kind, provided name and namespace correspond.
- A generated entity with `name: "67cbd7fe98a0776a"` and no other identifying evidence is not a confident match.

If a generated entity does not have a confident match, leave it unmatched and set its normalized GT entity ID to `null`.

Preserve the original order of the generated `contributing_factors`.

-----

### Output Format

Return only a single JSON object with this shape:

```json
{
"contributing_factor_entities": [
  {
    "submitted_entity_name": "namespace/Kind/name",
    "normalized_gt_entity_id": "ground-truth-entity-id-or-null",
    "reasoning": "brief explanation of why this is a confident match or why it is unmatched"
  }
]
}
```

Rules:
- Include one item for every generated entity in `contributing_factors`.
- Preserve input order.
- Use `normalized_gt_entity_id: null` when there is no confident match.
- Return only valid JSON.

Given the following Ground Truth (GT) and Generated Response, normalize the generated contributing-factor entities to the Ground Truth.

## Ground Truth (GT):
```json
{ground_truth}
```

## Generated Response:
```json
{generated_response}
```

## Task:
1. Look only at `Generated Response.contributing_factors`.
2. For each such entity, determine whether there is a confident match in the Ground Truth.
3. If there is a confident match, return the matched ground-truth entity ID.
4. If there is not a confident match, return `normalized_gt_entity_id: null`.
5. Do not score anything. Return only the normalization result JSON.

Geral

IFBench

  • Status: avaliação independente (não faz parte do Artificial Analysis Intelligence Index v4.3.2). O IFBench foi removido do Intelligence Index na v4.1, mas continuamos a executá-lo em novos lançamentos de modelos.
  • Descrição: um benchmark que avalia a capacidade de um modelo de seguir instruções precisas em um único turno. Ele testa uma ampla gama de habilidades, incluindo contagem, formatação e manipulação de frases.
  • Artigo: https://arxiv.org/abs/2507.02833
  • Conjunto de dados: https://huggingface.co/datasets/allenai/IFBench_test
  • Implementação:
    • Usa o conjunto de dados IFBench de turno único, que contém 294 perguntas
    • Executamos 5 repetições para cada pergunta com pontuação pass@1
    • Avaliamos as respostas usando o código-fonte oficial de allenai/IFBench
    • Empregamos o modo de avaliação flexível para avaliar de forma robusta o seguimento de instruções, que leva em conta texto ou formatação estranhos, verificando diversas variações da saída do modelo (por exemplo, com e sem a primeira e a última linhas, e com os asteriscos removidos)
    • Nossa pontuação representa a precisão do nível imediato (média de todas as perguntas e repetições)
    • Não usamos a versão multivoltas do IFBench, que usa um conjunto de dados diferente

MLCR-AA (Medical Long Context Reasoning)

  • Status: Avaliação independente (não faz parte do Artificial Analysis Intelligence Index v4.3.2); componente do Artificial Analysis Healthcare & Medical Index
  • Descrição: MLCR-AA é a avaliação da Artificial Analysis do MLCR (Medical Long Context Reasoning), um benchmark aberto da Wisedocs que mede a capacidade dos modelos de raciocinar sobre registros médicos longos e fragmentados. Avalia a síntese de múltiplos documentos realizada por profissionais de sinistros ao revisar casos de seguros e saúde, como reconstruir a cronologia, a causalidade, os padrões de tratamento e a relevância para uma solicitação de cobertura.
  • Código: Wisedocs-AI/medical-long-context-reasoning
  • Conjunto de dados público: Wisedocs/mlcr-dataset
  • Detalhes principais:
    • Casos médicos sintéticos e realistas de aproximadamente 25.000 a 64.000 tokens
    • As perguntas são classificadas em seis níveis de dificuldade, desde a localização de um único fato até a síntese clínica de nível especializado e o raciocínio composto de várias partes.
    • As respostas que passam pelo portão de concisão e contêm uma resposta são avaliadas por um painel de três juízes LLM; precisão e integridade são decididas por maioria de votos
    • Uma resposta mais longa que cinco vezes a resposta de referência falha no critério de concisão e pontua zero sem julgamento; a taxa geral de aprovação credita uma resposta somente quando ela passa por esse portão e é considerada completa e precisa
    • A Artificial Analysis avalia um conjunto privado mantido dos dois tipos de perguntas mais difíceis (síntese clínica de nível especializado e raciocínio composto de várias partes): 60 perguntas, cada uma com 3 repetições. Este conjunto privado é separado do conjunto de dados divulgado publicamente
    • A Artificial Analysis relata a taxa de aprovação geral (creditada apenas quando uma resposta é concisa e considerada completa e precisa) como a pontuação principal. A precisão e a completude do juiz são taxas condicionais entre as respostas julgadas; a concisão cobre todas as respostas. Estas repartições são apresentadas juntamente com a pontuação primária; pass@1

Outros

Global-MMLU-Lite

  • Status: avaliação independente (não faz parte do Artificial Analysis Intelligence Index v4.3.2); alimenta o Artificial Analysis Multilingual Index
  • Descrição: uma versão leve e multilíngue do MMLU projetada para avaliar conhecimentos e habilidades de raciocínio em diversos idiomas e contextos culturais.
  • Conjunto de dados: CohereLabs/Global-MMLU-Lite
  • Detalhes principais:
    • Cerca de 6.000 perguntas (cerca de 400 por idioma suportado)
    • Múltipla Escolha (4 opções)
    • Extração de Regex, pass@1

MMMU Pro

  • Status: avaliação independente (não faz parte do Artificial Analysis Intelligence Index v4.3.2); um benchmark de raciocínio multimodal (visual)
  • Descrição: um benchmark MMMU aprimorado que elimina atalhos e estratégias de adivinhação para testar modelos multimodais com mais rigor em 30 disciplinas acadêmicas.
  • Conjunto de dados: MMMU/MMMU_Pro
  • Detalhes principais:
    • 1.730 perguntas
    • Múltipla Escolha (10 opções)
    • Extração de Regex, pass@1

Avaliações anteriores

Avaliações que retiramos ou substituímos. Mantemos aqui sua metodologia para referência e comparabilidade histórica; eles não fazem mais parte do Artificial Analysis Intelligence Index ou de nossos relatórios ativos.

GPQA Diamond (Graduate-Level Google-Proof Q&A Benchmark)

  • Status: removido do Artificial Analysis Intelligence Index na v4.2, tendo sido um componente até a v4.1.1 inclusive. Ainda o executamos em lançamentos de novos modelos e o reportamos como uma avaliação independente.
  • Descrição: Referência de conhecimento científico e raciocínio.
  • Subconjunto: subconjunto diamante (198 perguntas) selecionado para máxima precisão e poder discriminativo
  • Artigo: https://arxiv.org/abs/2311.12022
  • Conjunto de dados: https://github.com/openai/simple-evals/blob/main/gpqa_eval.py
  • Detalhes principais:
    • 198 questões cobrindo biologia, física e química - testamos o subconjunto GPQA Diamond do conjunto de dados GPQA completo (448 questões no total), que foi definido pelos autores originais como o subconjunto de mais alta qualidade, onde ambos os especialistas respondem corretamente e a maioria dos não especialistas responde incorretamente
    • Formato de múltipla escolha com 4 opções
    • Extração de resposta baseada em Regex com pontuação pass@1 (prompt e regex abaixo)

𝜏³-Banking

  • Status: removido do Artificial Analysis Intelligence Index na v4.3, tendo sido um componente até a v4.2 inclusive. Ainda o executamos em lançamentos de novos modelos e o reportamos como uma avaliação independente.
  • Descrição: domínio de suporte ao cliente Fintech da estrutura 𝜏-Knowledge desenvolvida por Sierra, avaliando agentes que devem coordenar a recuperação de uma grande base de conhecimento não estruturada com alterações de conta mediadas por ferramentas em várias etapas.
  • Artigo: https://arxiv.org/abs/2603.04370
  • Blog: sierra.ai/blog/bench-advancing-agent-benchmarking-to-knowledge-and-voice
  • Conjunto de dados: https://github.com/sierra-research/tau2-bench
  • Implementação:
    • Os agentes lidam com cerca de 700 documentos de política interconectados (aproximadamente 195 mil tokens, 21 categorias de produtos) e devem localizar a política relevante, raciocinar sobre ela e executar uma sequência de várias etapas de chamadas de ferramentas - incluindo ferramentas referenciadas apenas na documentação, em vez de listadas explicitamente
    • Avaliamos o conjunto completo de tarefas 𝜏³-Banking (97 tarefas) com 5 repetições por tarefa e reportamos a média de pass@1 entre as repetições, executando o conjunto de dados e avaliador tau2-bench v1.0.1 upstream
    • Os resultados são pontuados em relação ao estado real do banco de dados back-end — por exemplo, se uma disputa foi aberta ou um crédito provisório emitido — em vez da qualidade da conversação
    • Usamos GPT-5.4 Mini (medium reasoning) tanto para o simulador de usuário quanto para o juiz de afirmação de linguagem natural
    • Para recuperação de conhecimento no corpus bancário, habilitamos a pesquisa lexical BM25 e grep (modo bm25_grep) dentro do equipamento 𝜏-Bench original
    • Aplicamos uma restrição na execução para limitar as etapas a um máximo de 200 por repetição de tarefa (o padrão de referência 𝜏-Knowledge para execuções em modo texto). Um 'passo' aqui é a definição do ambiente de execução 𝜏-Bench - cada mensagem passada na simulação, incluindo turnos do simulador do usuário - em vez de apenas os turnos realizados pelo modelo em avaliação

Terminal-Bench 2.1

  • Status: Substituído pelo Terminal-Bench 4.0 no Intelligence Index v4.3, tendo sido um componente até a v4.2 inclusive. Continua fazendo parte do Coding Index.
  • Descrição: uma atualização verificada do Terminal-Bench, desenvolvida por pesquisadores da Stanford University, do Laude Institute e da comunidade de código aberto. Mantém as mesmas 89 tarefas selecionadas em engenharia de software, administração de sistema, processamento de dados, treinamento de modelo e segurança, com correções de ambiente e instruções que fazem com que as pontuações reflitam a capacidade do agente em vez das lacunas do ambiente.
  • Artigo: https://arxiv.org/abs/2601.11868
  • Leaderboard: tbench.ai/leaderboard/terminal-bench/2.1
  • Implementação:
    • Avaliamos o conjunto de dados completo do Terminal-Bench 2.1 (89 tarefas) usando o equipamento do agente Terminus 2 em um ambiente sandbox E2B, com pontuação pass@1 média de 3 repetições por tarefa
    • Cada tarefa vem com um conjunto de verificação que o agente deve satisfazer ao interagir com o terminal – as tarefas são consideradas bem-sucedidas somente se todos os testes passarem
    • Aplicamos as seguintes restrições nas avaliações do agente:
      • O máximo de 'episódios' (onde o modelo analisa o estado atual e planeja uma série de próximas ações no terminal) é limitado a 250
      • O tempo limite do agente por tarefa é definido como duas horas (7.200 segundos) ou o tempo limite especificado pela própria tarefa, quando for mais longo, bem acima da duração típica da tarefa
    • Em nossos testes, essas restrições limitam predominantemente os casos em que os modelos ficam presos em um loop malsucedido e não vemos diferenças consistentes no desempenho devido a essas restrições.

Terminal-Bench Hard

  • Nota: Substituído pelo Terminal-Bench 2.1, que usaremos daqui em diante. Terminal-Bench Hard era um componente do Artificial Analysis Intelligence Index antes da v4.1
  • Descrição: um benchmark de agente desenvolvido por pesquisadores da Stanford University, do Laude Institute e da comunidade de código aberto, lançado em 2025. Terminal-Bench avalia a capacidade de agentes e modelos de resolver uma ampla variedade de tarefas (incluindo engenharia de software, administração de sistemas e cenários de jogo) usando uma interface de terminal.
  • Página: https://www.tbench.ai/
  • Registro do conjunto de dados: https://www.tbench.ai/registry
  • Implementação:
    • Implementamos o subconjunto 'hard' do conjunto de dados terminal-bench-core, com a versão mais recente do conjunto de dados em 14 de agosto de 2025 (commit 74221fb); avaliamos 44 tarefas deste subconjunto (um pequeno número de tarefas é excluído devido a problemas de dependência externa no conjunto de dados original)
    • Avaliamos esse subconjunto 'difícil' usando o equipamento do agente Terminus 2 para consistência entre modelos e modelos de pontuação com base na pontuação pass@1 com a média geral de 3 repetições para cada tarefa
    • Na estrutura Terminal-Bench, cada tarefa tem um conjunto específico de testes aplicados e são consideradas bem-sucedidas se todos os testes passarem, ou malsucedidas caso contrário
    • Aplicamos as seguintes restrições nas avaliações do agente:
      • O máximo de 'episódios' (onde o modelo analisa o estado atual e planeja uma série de próximas ações no terminal) é limitado a 100
      • Definimos um tempo limite global por tarefa de duas horas (7.200 segundos); na prática, o limite de 100 episódios é a restrição vinculativa
      • Os modelos são limitados a um máximo de 1 milhão de tokens de entrada cumulativos por repetição de cada tarefa
    • Em nossos testes, essas restrições limitam predominantemente os casos em que os modelos ficam presos em um loop malsucedido e não vemos diferenças consistentes no desempenho devido a essas restrições.

𝜏²-Bench Telecom

  • Nota: Substituído por 𝜏³-Banking, que usaremos daqui para frente. 𝜏²-Bench Telecom era um componente do Artificial Analysis Intelligence Index antes da v4.1
  • Descrição: benchmark desenvolvido pela Sierra para agentes de IA conversacional em cenários de 'controle duplo' com modelos de linguagem que simulam funções de agente e usuário para testar planejamento, uso de ferramentas e orientação/comunicação.
  • Artigo: https://arxiv.org/abs/2506.07982
  • Blog: sierra.ai/resources/research/tau-squared-bench
  • Conjunto de dados: https://github.com/sierra-research/tau2-bench
  • Implementação:
    • O domínio 'telecom' introduzido em 𝜏²-Bench contém 114 tarefas (subamostradas de um total de 2.285 tarefas geradas programaticamente), com 'intenções' variadas que descrevem se a tarefa está relacionada a serviços, dados móveis ou problemas de MMS. Avaliamos o domínio de telecomunicações na íntegra com 3 repetições por tarefa e reportamos a pontuação usando a pontuação pass@1 como a média das 3 tentativas
    • Neste benchmark, o resultado 'estado mundial' decide se o agente teve sucesso - por exemplo, se os dados do telefone celular do usuário estão funcionando após o agente concluir a tarefa
    • O conjunto completo 𝜏²-Bench inclui 3 modos de execução com diversos níveis de planejamento e comunicação em estudos de ablação; implementamos o modo de controle duplo 'padrão' com usuários e agentes assistentes totalmente simulados e separados
    • Usamos Qwen3 235B A22B 2507 (Non-reasoning) para o simulador de agente de usuário para garantir disponibilidade consistente de pontos de verificação e controle total sobre configurações de inferência junto com forte inteligência de base
    • Aplicamos uma restrição na execução para limitar as etapas a um máximo de 100 por repetição de tarefa

MATH-500

  • Nota: retirado do Artificial Analysis Intelligence Index e de nossos relatórios ativos.
  • Descrição: Um subconjunto de 500 problemas do benchmark MATH abrangendo matemática competitiva do ensino médio em uma variedade de disciplinas e níveis de dificuldade.
  • Conjunto de dados: huggingface.co/datasets/HuggingFaceH4/MATH-500

AIME 2025 (American Invitational Mathematics Examination)

  • Nota: Retirado de nossos relatórios ativos; não faz mais parte do Artificial Analysis Intelligence Index v4.3.2.
  • Descrição: conjunto de dados avançados de resolução de problemas matemáticos do American Invitational Mathematics Examination de 2025.
  • Conjunto de dados: 2025 AIME I & 2025 AIME II
  • Detalhes principais:
    • Formato de resposta numérico estrito (número inteiro 1–999)
    • Pontuação Pass@1 com 10 repetições por pergunta
    • Avaliação baseada em script com normalização SymPy + verificador de igualdade LLM como backup

MMLU-Pro (Multi-Task Language Understanding Benchmark, Pro version)

  • Nota: removido do Intelligence Index na v4.0. Retirado de nossos relatórios ativos.
  • Descrição: avaliação abrangente de conhecimento avançado em vários domínios, adaptada do MMLU original.
  • Artigo: https://arxiv.org/abs/2406.01574
  • Conjunto de dados: https://huggingface.co/datasets/TIGER-Lab/MMLU-Pro
  • Detalhes principais:
    • Formato de múltipla escolha com 10 opções
    • Extração de resposta baseada em Regex com pontuação pass@1 (prompt e regex abaixo)

LiveCodeBench

Modelos de prompt, extração de respostas e avaliação

Perguntas de múltipla escolha (GPQA, MMLU-Pro)

Solicitamos avaliações de múltipla escolha com o seguinte prompt de instruções. Este prompt foi desenvolvido de forma independente pela Artificial Analysis e cuidadosamente validado com vários estudos de ablação. Avaliamos que esta solicitação é uma abordagem mais clara e, portanto, mais justa do que as metodologias tradicionais de avaliação de múltipla escolha no estilo de conclusão ou outras instruções de instrução que testamos.

GPQA usa quatro opções (A–D). MMLU-Pro usa dez opções (A – J); usamos a mesma estrutura com opções adicionais.

Answer the following multiple choice question. The last line of your response should be in the following format: 'Answer: A/B/C/D' (e.g. 'Answer: A').

{Question}

A) {A}
B) {B}
C) {C}
D) {D}
Answer the following multiple choice question. The last line of your response should be in the following format: 'Answer: A/B/C/D/E/F/G/H/I/J' (e.g. 'Answer: A').

{Question}

A) {A}
B) {B}
C) {C}
D) {D}
E) {E}
F) {F}
G) {G}
H) {H}
I) {I}
J) {J}

Expressão regular para extração de múltipla escolha

Extraímos respostas de múltipla escolha usando uma abordagem de vários estágios para lidar com vários formatos de resposta. Para respostas de uma única letra, usamos a letra diretamente. Caso contrário, primeiro tentamos corresponder ao nosso padrão primário que procura o formato formal "Answer: X" (considerando a formatação markdown opcional):

Padrão Primário:

(?i)[\*\_]{0,2}Answer[\*\_]{0,2}\s*:[\s\*\_]{0,2}\s*([A-Z])(?![a-zA-Z0-9])

Se o padrão primário falhar, tentamos os seguintes padrões alternativos em sequência para capturar vários formatos de resposta:

  • Notação LaTeX em caixa (por exemplo, \boxed{A} ou \boxed{The answer is A})
    \boxed\{[^}]*([A-Z])[^}]*\}
  • Linguagem natural (por exemplo, "answer is B")
    answer is ([a-zA-Z])
  • Com parênteses (por exemplo, "answer is (C")
    answer is \\(([a-zA-Z])
  • Formato de escolha (por exemplo, "D) some answer text")
    ([A-Z])\)\s*[^A-Z]*
  • Declaração explícita (por exemplo, "E is the correct answer")
    ([A-Z])\s+is\s+the\s+correct\s+answer
  • Carta independente no final da resposta
    ([A-Z])\s*$
  • Letra seguida de ponto final (por exemplo, "F.")
    ([A-Z])\s*\.
  • Letra seguida por caractere que não seja de palavra
    ([A-Z])\s*[^\w]

Sempre consideramos a última correspondência encontrada para contabilizar a autocorreção nas respostas.

LLM verificador de igualdade

Para avaliações com respostas abertas (HLE, AA-LCR), usamos um verificador de igualdade LLM para determinar se a resposta de um modelo é semanticamente equivalente à resposta correta. Esta abordagem utiliza um modelo de linguagem para avaliar se duas respostas têm o mesmo significado, mesmo que formuladas de forma diferente. O verificador de igualdade avalia a equivalência semântica em vez de exigir correspondências exatas de strings, o que é particularmente importante para questões onde existem múltiplas frases válidas.

HLE e AA-LCR compartilham um único verificador de igualdade, GPT-5.6 Luna (medium), selecionado com base na validação contra o julgamento humano. Os prompts específicos do verificador de igualdade para cada avaliação são detalhados nas seções abaixo.

HLE (Humanity's Last Exam)

Solicitamos HLE com o texto a seguir como um prompt do sistema, com uma diferença entre perguntas de Resposta Exata e de Múltipla Escolha - esses prompts são usados sem alterações em relação à implementação original por Hendrycks et al. Para modelos que não suportam prompt do sistema, acrescentamos o prompt do sistema ao prompt do usuário.

System Prompt for Exact Answer Questions:

"Your response should be in the following format:
Explanation: {your explanation for your final answer}
Exact Answer: {your succinct, final answer}
Confidence: {your confidence score between 0% and 100% for your answer}"

System Prompt for Multiple Choice Questions:

"Your response should be in the following format:
Explanation: {your explanation for your answer choice}
Answer: {your chosen answer}
Confidence: {your confidence score between 0% and 100% for your answer}"

Prompt do verificador de igualdade do HLE

Usamos o seguinte prompt em GPT-5.6 Luna (medium) para verificar se a resposta está correta - este prompt é usado novamente sem alterações em relação à implementação original por Hendrycks et al.

Judge whether the following [response] to [question] is correct or not based on the precise and unambiguous [correct_answer] below.

[question]: {question}

[response]: {response}

Your judgement must be in the format and criteria specified below:

extracted_final_answer: The final exact answer extracted from the [response]. Put the extracted answer as 'None' if there is no exact, final answer to extract from the response.

[correct_answer]: {correct_answer}

reasoning: Explain why the extracted_final_answer is correct or incorrect based on [correct_answer], focusing only on if there are meaningful differences between [correct_answer] and the extracted_final_answer. Do not comment on any background to the problem, do not attempt to solve the problem, do not argue for any answer different than [correct_answer], focus only on whether the answers match.

correct: Answer 'yes' if extracted_final_answer matches the [correct_answer] given above, or is within a small margin of error for numerical problems. Answer 'no' otherwise, i.e. if there if there is any inconsistency, ambiguity, non-equivalency, or if the extracted answer is incorrect.


confidence: The extracted confidence score between 0|\%| and 100|\%| from [response]. Put 100 if there is no confidence score available.

Prompt do verificador de igualdade do LCR 

Assess whether the following CANDIDATE ANSWER is CORRECT or INCORRECT.
For the CANDIDATE ANSWER to be correct, it must be consistent with the OFFICIAL ANSWER.

The question, for reference only: {question}
The OFFICIAL ANSWER: {official_answer}
CANDIDATE ANSWER TO ASSESS: {candidate_answer}

Reply only with CORRECT or INCORRECT.

Perguntas de matemática (AIME 2025)

Solicitamos ao AIME o seguinte prompt de instrução:

Solve the following math problem step by step. Put your answer inside \\boxed{{}}.

{Question}

Remember to put your answer inside \\boxed{{}}.

Prompt do verificador de igualdade matemática

Conforme descrito acima, complementamos nossa avaliação baseada em script com um verificador de igualdade de modelo de linguagem. Usamos o seguinte prompt com Llama 3.3 70B para verificar se duas respostas são equivalentes. Este prompt foi desenvolvido pela OpenAI e lançado em seu repositório simple-evals.

Look at the following two expressions (answers to a math problem) and judge whether they are equivalent. Only perform trivial simplifications

Examples:

  Expression 1: $2x+3$
  Expression 2: $3+2x$

Yes

  Expression 1: 3/2
  Expression 2: 1.5

Yes

  Expression 1: $x^2+2x+1$
  Expression 2: $y^2+2y+1$

No

  Expression 1: $x^2+2x+1$
  Expression 2: $(x+1)^2$

Yes

  Expression 1: 3245/5
  Expression 2: 649

No
(these are actually equal, don't mark them equivalent if you need to do nontrivial simplifications)

  Expression 1: 2/(-3)
  Expression 2: -2/3

Yes
(trivial simplifications are allowed)

  Expression 1: 72 degrees
  Expression 2: 72

Yes
(give benefit of the doubt to units)

  Expression 1: 64
  Expression 2: 64 square feet

Yes
(give benefit of the doubt to units)

---

YOUR TASK


Respond with only "Yes" or "No" (without quotes). Do not include a rationale.

  Expression 1: %(expression1)s
  Expression 2: %(expression2)s

Tarefas de geração de código

SciCode

Solicitamos SciCode com o seguinte prompt, usado sem alterações em relação à implementação original do prompt Scientist Annotated Background de Tian et al.

PROBLEM DESCRIPTION:
You will be provided with problem steps along with background knowledge necessary for solving the problem. Your task will be to develop a Python solution focused on the next step of the problem-solving process.

PROBLEM STEPS AND FUNCTION CODE:
Here, you'll find the Python code for the initial steps of the problem-solving process. This code is integral to building the solution.

{problem_steps_str}

NEXT STEP - PROBLEM STEP AND FUNCTION HEADER:
This part will describe the next step in the problem-solving process. A function header will be provided, and your task is to develop the Python code for this next step based on the provided description and function header.

{next_step_str}

DEPENDENCIES:
Use only the following dependencies in your solution. Do not include these dependencies at the beginning of your code.

{dependencies}

RESPONSE GUIDELINES:
Now, based on the instructions and information provided above, write the complete and executable Python program for the next step in a single block.
Your response should focus exclusively on implementing the solution for the next step, adhering closely to the specified function header and the context provided by the initial steps.
Your response should NOT include the dependencies and functions of all previous steps. If your next step function calls functions from previous steps, please make sure it uses the headers provided without modification.
DO NOT generate EXAMPLE USAGE OR TEST CODE in your response. Please make sure your response python code in format of ```python```.

LiveCodeBench

Solicitamos LiveCodeBench com o seguinte prompt, usado sem alterações em relação à implementação original do prompt LiveCodeBench pela equipe original. Observamos, no entanto, que não aplicamos os prompts de sistema personalizados que a equipe do LiveCodeBench usa - não usamos seus prompts de sistema genéricos nem seus prompts de sistema personalizados para determinados modelos.

Questions with starter code:

### Question:
{question.question_content}

### Format: You will use the following starter code to write the solution to the problem and enclose your code within delimiters.
```python
{question.starter_code}
```

### Answer: (use the provided format with backticks)


Questions without starter code:

### Question:
{question.question_content}

### Format: Read the inputs from stdin solve the problem and write the answer to stdout (do not directly test on the sample inputs). Enclose your code within delimiters as follows. Ensure that when the python program runs, it reads the inputs, runs the algorithm and writes output to STDOUT.
```python
# YOUR CODE HERE
```

### Answer: (use the provided format with backticks

Expressão regular para extração de código

Extraímos o código da resposta usando o seguinte regex:

(?<=```python\n)((?:\n|.)+?)(?=\n```)

Histórico de versões

Versão 4.3.2

Setembro de 2026 até o momento

  • GDPval-AA v2.1: a escala Elo agora está ancorada em DeepSeek V4.1 Flash (max) com 1600 pontos, e as pontuações são ajustadas com um modelo Crowd-BT.
  • AA-Briefcase v1.1: a âncora permanece em GPT-5.5 (medium) com 1000 pontos, mas cada dimensão de comparação pareada agora é ajustada com um modelo Crowd-BT.

Versão 4.3.1

Setembro de 2026

  • Atualizados os painéis de juízes em pares para as versões atuais do modelo: AA-Briefcase e GDPval-AA As comparações em pares v2 agora julgam com Claude Opus 5, GPT-5.6 Sol e Gemini 3.8 Flash. Os painéis de classificação das rubricas permanecem inalterados.

Versão 4.3

Setembro de 2026

  • Substituído 𝜏³-Banking por AutomationBench-AA (5%) na categoria Agentes
  • Terminal-Bench 2.1 substituído pelo Terminal-Bench 4.0 (66 tarefas, ambiente de execução de mini-swe-agent)
  • Atualização no tratamento de imagens do GDP.pdf: tratamento aprimorado de imagens que excedem as restrições da API, com redimensionamento agora aplicado em uma variedade mais ampla de casos para garantir que as imagens possam ser passadas para o modelo
  • Pesos: GDPval-AA v2 (10%), AA-Briefcase (15%), AutomationBench-AA (5%), Terminal-Bench 4.0 (10%), SciCode (10%), AA-LCR (5%), AA-Omniscience Precisão (10%) e Não-Alucinação (5%), HLE (10%), GDP.pdf (10%), CritPt (10%)

Versão 4.2

Setembro de 2026

  • Adicionada AA-Briefcase (15%) à categoria Agentes
  • Adicionado GDP.pdf (10%) à categoria Geral
  • Removido o GPQA Diamond do Intelligence Index
  • AA-LCR atualizado para v1.1
  • O limite de tempo da avaliação do SciCode foi ampliado de 60 para 300 segundos, com execução isolada dos scripts, para que códigos lentos, mas corretos, não sejam mais reprovados; nova avaliação como v1.0.1.
  • Pesos rebalanceados: GDPval-AA v2 (10%), 𝜏³-Banking (5%), AA-Briefcase (15%), Terminal-Bench 2.1 (10%), SciCode (10%), AA-LCR (5%), AA-Omniscience Precisão (10%) e Não-Alucinação (5%), HLE (10%), GDP.pdf (10%), CritPt (10%)

Versão 4.1.1

Agosto de 2026 a setembro de 2026

  • 𝜏³-Banking movido para o conjunto de dados e avaliador tau2-bench v1.0.1 upstream
  • O modelo avaliador de HLE, AA-LCR e AA-Omniscience foi atualizado para GPT-5.6 Luna (medium), substituindo, respectivamente, GPT-4o (Aug '24), Qwen3 235B A22B 2507 Non-Reasoning e Gemini 3 Flash Preview (Reasoning)

Versão 4.1

Junho de 2026 a agosto de 2026

  • GDPval-AA atualizado para GDPval-AA v2: sandbox atualizado com dependências novas e expandidas, pontuações Elo redefinidas para desempenho de especialistas humanos em 1000, painel de três juízes LLM de fronteira e limites de turno expandidos para 250 turnos com possibilidade de saída antecipada
  • Terminal-Bench Hard substituído pelo Terminal-Bench 2.1 (limites de turnos mais altos, sem limites de token)
  • Substituído 𝜏²-Bench Telecom por 𝜏³-Banking
  • Removido o IFBench do Intelligence Index (continuamos a executá-lo em lançamentos de novos modelos)
  • Pesos de categoria ajustados para enfatizar ainda mais as tarefas de agente: Agentes (34%), Codificação (24%), Raciocínio Científico (24%), Geral (18%), com componentes AA-Omniscience divididos em Precisão (8%) e Não-Alucinação (4%)
  • Token atualizado e métricas de custo para refletir melhor os custos reais, incluindo taxas de acertos de cache e preços de tokens de cache

Versão 4.0.4

Março de 2026 a junho de 2026

  • Modelo de avaliador atualizado para GDPval-AA para Gemini 3.1 Pro Preview após a descontinuação do modelo de avaliador anterior Gemini 3 Pro Preview

Versão 4.0.3

Fevereiro de 2026 a março de 2026

  • Modelo de avaliador atualizado para Omniscience para Gemini 3 Flash Preview (Reasoning) após a descontinuação do modelo de avaliador anterior Gemini 2.5 Flash (09-2025) (Reasoning)

Versão 4.0.2

Janeiro de 2026 a fevereiro de 2026

  • Pontuações GDPval-AA Elo reancoradas no Intelligence Index para os valores mais recentes após uma revisão para melhorar a robustez contra falhas raras de sandbox de código

Versão 4.0.1

Janeiro de 2026

  • Terminal-Bench Avaliação rígida refinada para 44 tarefas, removendo um pequeno conjunto de tarefas devido a problemas de dependência externa no conjunto de dados original no commit fixado

Versão 4.0

Janeiro de 2026

  • Adicionado GDPval-AA (trabalho de conhecimento do mundo real)
  • Adicionado AA-Omniscience (conhecimento e alucinação)
  • Adicionado CritPt (raciocínio físico)
  • MMLU-Pro, LiveCodeBench, AIME 2025 removidos do Intelligence Index
  • Nova estrutura de ponderação baseada em categorias: Agentes (25%), Codificação (25%), Geral (25%), Raciocínio Científico (25%)

Versão 3.0

2 de setembro de 2025 a dezembro de 2025

  • Adicionado Terminal-Bench Hard (fluxos de trabalho de agente)
  • Adicionado 𝜏²-Bench Telecom (fluxos de trabalho de agente)
  • Incluídos MMLU-Pro e LiveCodeBench no Intelligence Index
  • Ponderações atualizadas

Versão 2.2

6 de agosto de 2025 a 1º de setembro de 2025

  • Adicionado Artificial Analysis Long Context Reasoning
  • Ponderações atualizadas

Versão 2.1

5 de agosto de 2025—6 de agosto de 2025

  • Adicionado IFBench
  • Adicionado AIME 2025
  • MATH-500 removido
  • Removido AIME 2024
  • Ponderações atualizadas

Versão 2.0

11 de fevereiro de 2025 a 4 de agosto de 2025

Versão 1.0—1.3

Janeiro de 2024 a 10 de fevereiro de 2025