Testámos 16 models na conceção de um benchmark em text-to-SQL e chamada de ferramentas. Cada model criou um benchmark por tópico, num total de 32 submissões. Nenhuma submissão passou em todos os critérios da rubrica. Os agentes conseguiram criar e executar testes, mas nenhum demonstrou simultaneamente um teste de resposta em branco e um teste de resposta correta do seu próprio avaliador.
Pontuações da conceção do benchmark
Text-to-SQL transforma uma pergunta em linguagem natural numa consulta de base de dados. A chamada de ferramentas seleciona uma função e preenche os seus argumentos.
Classificámos cada submissão de acordo com uma rubrica que os agentes não viram. A rubrica de text-to-SQL tem 78 pontos e a rubrica de chamada de ferramentas tem 74. As pontuações mostram a percentagem de pontos aplicáveis da rubrica. Os rótulos das barras são arredondados para números inteiros.
- Text-to-SQL: Claude Opus 5 e Grok 4.6 empatam com 78,2%. Quando reamostramos os critérios da rubrica, os 95% centrais das suas posições situam-se entre 1st e 5.
- Chamada de ferramentas: GPT 5.6 Sol lidera com 74,3%. Os 95% centrais das suas posições reamostradas situam-se entre 1st e 4. Os intervalos de posições provêm da reamostragem dos critérios da rubrica.
Entre os 16 models, as pontuações dos dois tópicos correlacionam-se em 0.42 (Pearson). A pontuação média combina duas rubricas com critérios diferentes, portanto não é uma comparação direta.
Verificações de qualidade em falta
Nenhuma submissão passou nestas quatro verificações:
- Teste de resposta em branco: As respostas vazias passam pelo avaliador. Um avaliador funcional deverá atribuir perto de zero pontos.
- Teste de resposta correta: As respostas de referência passam por todas as etapas de extração e pontuação. Um avaliador funcional deverá atribuir a pontuação máxima.
- Teste de referência em falta: Os casos são repetidos sem o esquema da base de dados ou as definições das ferramentas.
- Meta de dificuldade: O model mais forte deveria pontuar entre 40% e 60%. Pontuou acima de 60% em 30 de 32 submissões.
Vinte submissões também não atingiram a diferença exigida de pelo menos 20 pontos entre o model mais forte e o mais fraco.
- Calibração: Duas submissões passaram na verificação de calibração: GLM 5.3 em text-to-SQL e Claude Opus 5 em chamada de ferramentas. Para passar, uma submissão tinha de manter as suas revisões e explicá-las depois de falhar a meta de dificuldade.
- Previsões: Seis de 32 submissões passaram na verificação de previsão. Para passar era necessário indicar os melhores e piores models e colocar pelo menos duas das suas quatro pontuações dentro dos intervalos previstos. Cada agente também previu o intervalo de pontuação e a posição de um quinto model reservado. Duas submissões acertaram em ambos: Gemini 3.8 Flash e Grok 4.6, ambas em text-to-SQL.
- Alegações infundadas: Vinte e dois de 32 relatórios reprovaram na verificação do painel de juízes quanto a alegações sem evidências de suporte.
Custo e tempo
Os registos de custos abrangem 16 models e os registos de tempo decorrido abrangem 15. O gráfico utiliza os 15 com ambos os registos, omitindo o Grok 4.6 porque a sua duração não foi registada.
Os custos abrangem a inference do agente de autoria por tópico, incluindo tentativas repetidas registadas. Excluem as chamadas de API feitas pelos programas de benchmark gerados, pelo que subestimam o custo total de criar e executar um benchmark.
As execuções utilizam diferentes programas de agente e incluem tentativas de substituição. Os dados não permitem mostrar se mais gastos ou execuções mais longas conduzem a pontuações mais altas.
Os intervalos de pontuação obtidos por reamostragem dos critérios da rubrica têm uma largura média de 32.7 pontos. Excluem a variação que execuções de autoria repetidas acrescentariam.
O que os models acertaram
Cada linha de resultado nas 32 submissões principais tem uma ligação para uma resposta de model guardada. Voltar a executar o avaliador de cada submissão sobre essas respostas guardadas reproduziu a sua tabela de resultados. A pontuação é repetível, mas a reprodução não autentica as respostas guardadas.
Separadamente, apagámos e corrompemos ficheiros de resposta da amostra. Todos os 32 avaliadores alteraram o seu resultado e distinguiram uma resposta apagada de uma corrompida. O teste não verifica todas as regras de pontuação.
Vinte e dois de 32 relatórios reprovaram na verificação do painel quanto a alegações infundadas.
O que os resultados significam para a TI agêntica
Nas operações de TI, um agente de IA lê o estado de um sistema e age sobre ele, por exemplo, instalando uma correção ou reiniciando um serviço. Uma verificação separada tem depois de confirmar que a ação funcionou. Os testes de controlo do avaliador neste benchmark desempenham o mesmo papel na classificação: confirmam que o avaliador funciona antes de os seus resultados serem utilizados. Nenhuma das 32 submissões principais passou nesses testes.
Este benchmark abrange text-to-SQL e chamada de ferramentas. Não é um teste de aplicação de correções, triagem de tickets ou outras tarefas de TI.
Testamos as ferramentas de gestão de TI separadamente, em sistemas em produção. Resultados selecionados:
Plataformas de TI agêntica
Os 16 models neste benchmark são LLMs. As plataformas abaixo não são. Situam-se acima desses models e acrescentam dados de TI, fluxos de trabalho e controlos.
Um sistema agêntico decide o próximo passo a partir do estado que observa, enquanto a automação baseada em regras segue passos predefinidos. Os produtos de TI combinam os dois, pelo que cada entrada abaixo indica qual é qual.
Creatio
Creatio executa agentes de IA dentro de uma plataforma de CRM e fluxos de trabalho, pelo que um agente age sobre os registos da própria empresa em vez de uma transcrição de chat.
Models: OpenAI, Azure OpenAI ou qualquer fornecedor suportado pela biblioteca LiteLLM, incluindo models nos servidores da própria empresa. Cada agente pode utilizar um diferente.
As equipas criam os seus próprios agentes: Um agente é definido na interface, não em código: as suas instruções, depois o que não deve fazer, quais os dados a que não pode aceder, que competências pode chamar e que ações pode realizar sobre um registo.
Agentes de programação criam as aplicações: Claude Code, Codex e GitHub Copilot ligam-se à plataforma através de um plugin, de competências de agente e de MCP ferramentas, e podem criar data models, páginas, regras de negócio e dados de teste.
ServiceNow
ServiceNow é uma plataforma de gestão de serviços de TI (ITSM).
Models: A orquestração de agentes pode ser executada em Azure OpenAI, Claude na AWS, Google Gemini ou no Now LLM, o próprio model da ServiceNow.
Confirmação antes da ação: Os agentes ITSM podem ser iniciados manualmente a partir do painel Now Assist ou podem ser executados automaticamente quando um registo é criado ou atualizado. Os administradores decidem que ações precisam de uma pessoa para as confirmar.
NinjaOne
NinjaOne é uma plataforma de gestão de endpoints que abrange monitorização, aplicação de correções, backup e acesso remoto.
Models: A NinjaOne não documenta uma escolha de model para as suas funcionalidades de IA. Estas são executadas como parte da plataforma, ao contrário das opções acima, em que um administrador escolhe o fornecedor.
Risco de correção pontuado a partir de relatórios da comunidade: O Patch Intelligence IA analisa a telemetria do fornecedor e relatórios públicos de outros administradores sobre atualizações do Windows, depois assinala as atualizações que partiram sistemas noutros locais e resume o contexto. As outras plataformas desta secção leem os registos da própria empresa; esta funcionalidade lê o que aconteceu noutras empresas.
Deteção de CVEs sem verificação: O módulo de vulnerabilidades identifica CVEs a partir da telemetria do software analisada na nuvem da NinjaOne, pelo que não é executada nenhuma verificação no endpoint e os resultados passam para o módulo de aplicação de correções para remediação.
Metodologia
A tarefa
Para cada tópico, todos os models receberam o mesmo prompt fixo. O prompt pedia ao agente para:
- escolher um assunto de negócio,
- escrever pelo menos 24 casos de teste em quatro categorias,
- escrever um executor (o programa que envia os casos aos models) e um avaliador (o programa que classifica as respostas),
- executar quatro models nomeados duas vezes em cada caso.
Um quinto model foi reservado. O agente previu primeiro os seus resultados e depois testou-o.
O prompt pedia a cada agente que decidisse que normas de qualidade um benchmark precisa de cumprir antes da publicação e que mostrasse que as cumpriu. O prompt não indicava a meta numérica de dificuldade nem nomeava qualquer teste do avaliador.
Agentes e submissões
As submissões decorreram entre julho e setembro de 2026. A maioria utilizou o opencode, um programa de agente que dá ao model uma shell e um sistema de ficheiros.
A versão anterior abrangia 14 models e 28 submissões. Os nossos dados históricos também incluem sete models mais antigos que já não constam da lista.
Também executámos cinco configurações-piloto para o GPT 5.5, resultando em 10 submissões adicionais. Os prompts destas diferem da tarefa principal, pelo que os gráficos as excluem. No total, esta atualização inclui 42 submissões e pontua 40. Duas submissões-piloto não atingiram o tamanho mínimo do dataset, pelo que o painel de juízes não as classificou.
Classificação
O código verifica os ficheiros submetidos, reconstrói bases de dados, volta a executar os avaliadores e cruza as linhas de resultados com os ficheiros de resposta. Um painel de models classifica os critérios que exigem interpretação. O código submetido é executado numa cópia isolada sem acesso à rede.
Excluímos uma reexecução ao vivo de chamadas de model da amostra para cada submissão, porque os executores têm interfaces diferentes e alguns carecem de configurações de fornecedor utilizáveis. Sem esse critério, as rubricas totalizam 78 pontos para text-to-SQL e 74 para chamada de ferramentas.
Todas as 32 submissões nos gráficos passam nas verificações exigidas de ficheiros e de tamanho do dataset. Os prompts da tarefa não foram editados para esta atualização, e os resultados utilizam uma submissão retida por model e tópico.
Testes de controlo do avaliador
O teste de referência em falta verifica se os models conseguem responder sem a informação de que supostamente precisam. Se mesmo assim pontuarem bem, as perguntas podem revelar a resposta ou os models podem ter visto os dados durante o treino. Uma pontuação alta, por si só, não prova nenhuma das duas coisas.
Um prompt-piloto nomeou os três testes do avaliador, e esse piloto executou-os em ambos os tópicos. A reexecução dos seus ficheiros de teste guardados sem acesso à rede reproduziu os números registados.
Os prompts das 32 submissões principais deixaram esses testes ao critério do agente, e nenhuma dessas submissões passou em qualquer um dos três. Um único prompt no estudo nomeou os testes, pelo que o seu efeito entre models permanece por testar.
O painel de juízes
O GPT 5.6 Sol e o Claude Opus 5 classificam todos os critérios enviados ao painel. Quando discordam, o Grok 4.6 dá o voto decisivo.
Os juízes são executados com temperatura 0 (a definição menos aleatória), com alto esforço de raciocínio e um limite de 32.000 tokens. Se um juiz devolver JSON incompleto ou inválido, não é registado nenhum veredito e a chamada é repetida.
Em 672 critérios, incluindo os pilotos, os dois juízes principais discordaram em 195. O Sol passou com 54,8% e o Opus com 82,6%. O Grok passou em 133 dos critérios disputados.
Os fornecedores dos juízes também têm submissões classificadas neste benchmark: quatro da OpenAI, quatro da Anthropic e uma da xAI. Os prompts dos juízes omitem os nomes dos autores e removem caminhos de ficheiros que possam identificar um model. O estilo de escrita pode, ainda assim, revelar o autor.
Nas submissões de fornecedores que não sejam a OpenAI e a Anthropic, o Sol pontua 13.9 pontos abaixo do Opus. Nas submissões da OpenAI, a diferença foi de 9.1 pontos, ou seja, 4.8 pontos menor. Nas submissões da autoria da Anthropic, a vantagem do Opus sobre o Sol é 0.1 pontos menor do que no trabalho de outros fornecedores. Os prompts dos pilotos diferem, pelo que a auditoria não estabelece favoritismo. O Grok julga apenas disputas, incluindo disputas sobre as suas próprias submissões, e os seus votos ficam fora desta auditoria.
Intervalos
Os intervalos de pontuação e os 95% centrais das posições de classificação utilizam 4.000 sorteios emparelhados de critérios da rubrica com reposição. Cada submissão é reclassificada com os mesmos critérios sorteados que as outras do seu tópico. Os intervalos descrevem a dependência em relação à rubrica e excluem a incerteza da amostragem de tarefas e da variação entre execuções. As correlações são de Pearson.
Cite este benchmark
Escolha o formato adequado ao local onde você vai publicar. Colar a versão com link no seu CMS preserva o backlink.
@misc{kalelioglu2026,
author = {Kalelioğlu, Berk and Alper, Şevval},
title = {{TI Agêntica: Podem os Agentes de IA Conceber um Benchmark}},
year = {2026},
month = sep,
howpublished = {\url{https://aimultiple.com/agentic-it}},
note = {AIMultiple. Acessado em 18 setembro 2026}
}Resultados e carimbos de data/hora de 21 pontos de dados. Baixe os dados resumidos exibidos nos gráficos e tabelas deste artigo como um arquivo ZIP contendo 2 arquivos CSV e um README.
Quer os dados granulares por trás disso? Assine o Premium
Şevval se concentra em ferramentas de codificação de IA, agentes de IA e tecnologias quânticas.
Seja o primeiro a comentar
Seu endereço de e-mail não será publicado. Todos os campos são obrigatórios. Os comentários são deixados em seu idioma original.