WP-Bench: o benchmark oficial para medir IA a sério em desenvolvimento WordPress

Quem usa assistentes de código no dia a dia já percebeu o padrão: para tarefas genéricas, muitos modelos parecem excelentes; quando o assunto é WordPress (APIs do core, hooks, padrões de segurança, arquitetura de plugins), a qualidade varia bastante. O problema é que quase sempre essa percepção fica no “achismo” — faltam métricas reprodutíveis e específicas para o ecossistema.

O WP-Bench foi criado exatamente para preencher esse buraco: é o benchmark oficial de IA para WordPress, pensado para avaliar o desempenho de modelos de linguagem em tarefas que refletem o que developers realmente fazem quando desenvolvem para WordPress.

O que é o WP-Bench (e o que ele mede)

O WP-Bench avalia modelos em dois eixos complementares:

• Knowledge: questões de múltipla escolha sobre conceitos e detalhes do WordPress — APIs, hooks, padrões de segurança e coding standards — com atenção a adições mais recentes como a Abilities API e a Interactivity API.
• Execution: tarefas de geração de código avaliadas por um runtime real de WordPress, combinando análise estática e execução em sandbox com assertions (testes/validações).

Na prática, isso evita um problema comum em avaliações de IA: o modelo pode “parecer” certo ao explicar algo, mas falhar ao gerar código que roda, respeita padrões do projeto e não abre uma brecha de segurança.

Porque este benchmark é relevante para quem desenvolve em WordPress

Benchmarks tradicionais tendem a medir competências gerais (algoritmos, tarefas de programação genéricas, trivia de linguagens). Só que WordPress é um ecossistema com idiossincrasias: convenções próprias, APIs específicas, e muita superfície de segurança ligada a input do utilizador, permissões e saneamento de dados.

O WP-Bench entra como um “termómetro” do que interessa para o nosso contexto. Isto tem implicações bem práticas:

• Escolha de ferramentas com mais fundamento: se estás a construir um plugin com funcionalidades assistidas por IA ou a padronizar um modelo para a equipa, faz diferença saber qual modelo se sai melhor em tarefas WordPress.
• Pressão positiva sobre fornecedores: a ambição declarada é que o WP-Bench vire referência também para labs e providers na hora de avaliarem modelos antes do lançamento — para que WordPress não seja um caso periférico.
• Transparência via leaderboard open source: existe trabalho em direção a um ranking público, com resultados comparáveis em tarefas WordPress, para ajudar a comunidade a tomar decisões informadas.

Como o WP-Bench avalia código (o detalhe que faz a diferença)

O ponto mais interessante do WP-Bench é que o próprio WordPress atua como “avaliador”. Em vez de depender apenas de uma heurística textual, o benchmark executa o que o modelo gerou num ambiente controlado.

Pipeline de avaliação (em alto nível)

1. O harness (orquestrador) envia um prompt ao modelo pedindo código WordPress.
2. O código gerado é encaminhado para um runtime WordPress via WP-CLI (interface de linha de comandos do WordPress).
3. O runtime aplica análise estática: sintaxe, conformidade com coding standards e sinais de problemas de segurança.
4. O código é executado numa sandbox com assertions para verificar comportamento esperado.
5. O WP-Bench devolve um resultado em JSON, com pontuação e feedback detalhado por teste.

Instalação e quick start (para correr localmente)

O WP-Bench está no GitHub e traz uma estrutura com harness em Python e um runtime baseado em WordPress para fazer a correção. Um fluxo típico de arranque envolve: criar um ambiente Python, configurar chaves de API do provider e subir o runtime.

1) Criar virtualenv e instalar o harness

python3 -m venv .venv && source .venv/bin/activate
pip install -e ./python

python3 -m venv .venv && source .venv/bin/activate
pip install -e ./python

2) Configurar chaves de API

Cria um ficheiro .env com as chaves do(s) provider(s) que vais usar:

OPENAI_API_KEY=sk-...
ANTHROPIC_API_KEY=sk-ant-...
GOOGLE_API_KEY=...

OPENAI_API_KEY=sk-...
ANTHROPIC_API_KEY=sk-ant-...
GOOGLE_API_KEY=...

3) Subir o runtime do WordPress (grader)

cd runtime
npm install
npm start

cd runtime
npm install
npm start

4) Executar o benchmark

cd ..
wp-bench run --config wp-bench.example.yaml

cd ..
wp-bench run --config wp-bench.example.yaml

Os resultados são gravados em output/results.json, com logs por teste em output/results.jsonl.

Comparar vários modelos na mesma corrida

Um caso de uso comum é comparar modelos “lado a lado” com o mesmo dataset e a mesma configuração do grader. Para isso, basta listar múltiplos modelos no ficheiro YAML:

models:
  - name: gpt-4o
  - name: gpt-4o-mini
  - name: claude-sonnet-4-20250514
  - name: claude-opus-4-5-20251101
  - name: gemini/gemini-2.5-pro
  - name: gemini/gemini-2.5-flash

models:
  - name: gpt-4o
  - name: gpt-4o-mini
  - name: claude-sonnet-4-20250514
  - name: claude-opus-4-5-20251101
  - name: gemini/gemini-2.5-pro
  - name: gemini/gemini-2.5-flash

Os nomes seguem as convenções do LiteLLM (uma camada que uniformiza chamadas a vários providers), o que facilita alternar entre fornecedores sem reescrever o harness.

Configuração: o que dá para ajustar (e o que convém manter estável)

O WP-Bench usa um ficheiro de config (ex.: wp-bench.example.yaml) onde defines dataset, modelos, tipo de grader e parâmetros da corrida. Um exemplo representativo:

dataset:
  source: local              # 'local' or 'huggingface'
  name: wp-core-v1           # suite name

models:
  - name: gpt-4o

grader:
  kind: docker
  wp_env_dir: ./runtime      # path to wp-env project

run:
  suite: wp-core-v1
  limit: 10                  # limit tests (null = all)
  concurrency: 4

output:
  path: output/results.json
  jsonl_path: output/results.jsonl

dataset:
  source: local              # 'local' or 'huggingface'
  name: wp-core-v1           # suite name

models:
  - name: gpt-4o

grader:
  kind: docker
  wp_env_dir: ./runtime      # path to wp-env project

run:
  suite: wp-core-v1
  limit: 10                  # limit tests (null = all)
  concurrency: 4

output:
  path: output/results.json
  jsonl_path: output/results.jsonl

CLI: comandos úteis

wp-bench run --config wp-bench.yaml          # run with config file
wp-bench run --model-name gpt-4o --limit 5   # quick single-model test
wp-bench dry-run --config wp-bench.yaml      # validate config without calling models

wp-bench run --config wp-bench.yaml          # run with config file
wp-bench run --model-name gpt-4o --limit 5   # quick single-model test
wp-bench dry-run --config wp-bench.yaml      # validate config without calling models

Como os datasets estão organizados

As suites de testes ficam em datasets/suites/<suite-name>/ e seguem uma separação clara por tipo de tarefa:

• execution/: tarefas de geração de código com assertions (um JSON por categoria).
• knowledge/: perguntas de múltipla escolha (um JSON por categoria).

A suite padrão mencionada é a wp-core-v1, focada em APIs do core, hooks, operações com base de dados e padrões de segurança.

Carregar datasets a partir do Hugging Face

Além de suites locais, é possível apontar para um dataset no Hugging Face via configuração:

dataset:
  source: huggingface
  name: WordPress/wp-bench-v1

dataset:
  source: huggingface
  name: WordPress/wp-bench-v1

Estado atual (early release) e limitações conhecidas

O WP-Bench foi apresentado como uma versão inicial e já assume algumas limitações importantes:

• Tamanho do dataset: a suite atual ainda é relativamente pequena. Para virar referência, precisa de mais casos cobrindo padrões e APIs do WordPress de forma mais abrangente.
• Cobertura por versões: há um viés para funcionalidades recentes (por exemplo, WordPress 6.9, incluindo Abilities API e Interactivity API). Isto é útil para expor fragilidades reais dos modelos, mas também cria assimetria — muitas dessas APIs podem não estar no treino da maioria dos LLMs.
• Saturação em conceitos antigos: testes iniciais indicaram pontuações muito altas em tópicos “clássicos”, o que reduz o sinal do benchmark. A dificuldade passa a ser encontrar questões que sejam realmente discriminatórias, e não apenas novidades de última hora.

Estrutura do repositório (para te orientares rápido)

.
├── python/          # Benchmark harness (pip installable)
├── runtime/         # WordPress grader plugin + wp-env config
├── datasets/        # Test suites (local JSON + Hugging Face builder)
├── notebooks/       # Results visualization and reporting
└── output/          # Benchmark results (gitignored)

.
├── python/          # Benchmark harness (pip installable)
├── runtime/         # WordPress grader plugin + wp-env config
├── datasets/        # Test suites (local JSON + Hugging Face builder)
├── notebooks/       # Results visualization and reporting
└── output/          # Benchmark results (gitignored)

O que isto muda no dia a dia de quem faz plugins, themes e integrações

Na prática, o WP-Bench tende a virar uma peça útil em três cenários comuns:

1. Avaliar assistentes de código para equipas: em vez de escolher um modelo por popularidade, dá para medir performance em tarefas WordPress e reduzir fricção (menos correções, menos regressões, menos código fora do padrão).
2. Validar “prompts padrão” internos: se a tua equipa usa templates de prompt para gerar snippets (metaboxes, REST endpoints, sanitização, capabilities), a dimensão de execution ajuda a perceber se o resultado aguenta runtime.
3. Dar feedback ao ecossistema: benchmarks abertos criam linguagem comum para discutir qualidade. Quando algo falha, falha num teste reproduzível — e não numa anedota de Slack.

Recursos oficiais

• Repositório do WP-Bench: https://github.com/WordPress/wp-bench
• AI Building Blocks for WordPress: https://make.wordpress.org/ai/2025/07/17/ai-building-blocks/
• #core-ai no Slack: https://wordpress.slack.com/archives/C08TJ8BPULS