WP-Bench: официалният AI benchmark за WordPress (и защо най-после ни трябва)
В последните месеци AI coding assistants станаха ежедневие: генерираме плъгини, пишем миграции, скелетираме блокове, а понякога и дебъгваме с помощта на LLM (Large Language Model — езиков модел). Проблемът е, че „изглежда правилно“ не означава „работи в WordPress“ — особено когато влизат в игра hooks, capabilities, escaping, nonces и куп специфики на ядрото.
Точно тук влиза WP-Bench — официалният AI benchmark на WordPress, който цели да измерва доколко даден модел реално разбира WordPress разработката: от core API-та и coding standards до архитектура на плъгини и security best practices.
Какъв проблем решава WP-Bench
Повечето публични оценки на модели са върху общи програмни задачи: алгоритми, синтаксис, популярни framework-и. WordPress обаче има дълъг „опашат“ набор от конвенции и специфични API-та (actions/filters, WP_Query, REST API patterns, DB абстракция, nonce/capability проверки и т.н.). WP-Bench запълва тази празнина, като дефинира измерими задачи именно в контекста на WordPress.
Това е полезно в два слоя:
- За практиката днес: ако правиш AI-подпомогнат плъгин или разчиташ на асистент за код, има значение кой модел се справя по-добре със специфичните WordPress патерни.
- За моделите утре: идеята е WP-Bench да стане „стандартен“ benchmark, който доставчиците на модели да включват в pre-release оценките си, за да не се оказва WordPress второстепенна мисъл.
Какво точно измерва WP-Bench: Knowledge срещу Execution
WP-Bench разделя оценяването на две измерения:
- Knowledge — multiple-choice въпроси за WordPress концепции, API-та, hooks, security патерни и coding standards. Фокусът е и върху по-нови добавки като Abilities API и Interactivity API (споменати в анонса като области, където моделите реално се затрудняват).
- Execution — задачи за генериране на код, които не се оценяват „на око“, а се пускат през реален WordPress runtime. Резултатът се формира от статични проверки плюс изпълнение в sandbox с runtime assertions.
Ключовата разлика спрямо много други бенчмаркове е, че тук WordPress сам е „грейдърът“: генерираният код се тества в контролирана среда, вместо да се разчита само на текстова проверка.
Как протича оценяването (grading) на Execution тестовете
- Harness-ът изпраща prompt към модела с изискване за WordPress код.
- Генерираният код се подава към WordPress runtime през WP-CLI (командният интерфейс на WordPress).
- Runtime-ът прави статичен анализ (синтаксис, coding standards, security проверки).
- Кодът се изпълнява в sandbox среда и се валидира чрез тестови assertions.
- Връща се резултат като JSON със score и детайлен feedback.
Бърз старт: как да го пуснеш локално
Проектът е структуриран така, че да можеш да стартираш benchmark-а локално и да сравняваш модели. Има Python harness (инсталира се с pip) и отделен runtime (WordPress среда, която играе ролята на грейдър).
1) Инсталация на Python harness-а
python3 -m venv .venv && source .venv/bin/activate
pip install -e ./python
2) API ключове за доставчици на модели
Създаваш .env файл с ключовете за провайдърите, които ще тестваш (примерите в repo-то включват OpenAI, Anthropic и Google):
OPENAI_API_KEY=sk-...
ANTHROPIC_API_KEY=sk-ant-...
GOOGLE_API_KEY=...
3) Стартиране на WordPress runtime (грейдъра)
cd runtime
npm install
npm start
4) Пускане на benchmark-а
cd ..
wp-bench run --config wp-bench.example.yaml
Резултатите се записват в output/results.json, а подробните логове по тестове — в output/results.jsonl.
Multi-model сравнение: един run, няколко модела
Едно от практичните неща е, че можеш да сравняваш няколко модела последователно в рамките на една конфигурация:
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
Имената на моделите следват конвенциите на LiteLLM (т.е. очакван формат за provider/model), което улеснява стандартизираното им адресиране в конфигурация.
Конфигурация: какво реално контролираш
Базовата идея е да копираш wp-bench.example.yaml и да настроиш dataset, модели, грейдър и параметри на run-а:
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 команди
wp-bench run --config wp-bench.yaml # run с конфигурационен файл
wp-bench run --model-name gpt-4o --limit 5 # бърз smoke test с един модел
wp-bench dry-run --config wp-bench.yaml # валидира конфигурацията без да вика модели
Как са организирани dataset-ите и тестовете
Тестовите пакети (test suites) живеят в datasets/suites/<suite-name>/ и са разделени по тип:
execution/— задачи за генериране на код + assertions (по един JSON файл на категория).knowledge/— multiple-choice въпроси (по един JSON файл на категория).
По подразбиране suite-ът wp-core-v1 покрива WordPress core API-та, hooks, database операции и security патерни.
Зареждане на dataset от Hugging Face
Освен локални JSON-и, WP-Bench поддържа и зареждане от Hugging Face dataset builder:
dataset:
source: huggingface
name: WordPress/wp-bench-v1
Текущо състояние и реалистични ограничения
WP-Bench е в ранен етап и това се казва директно в анонса. Има няколко важни последствия, които е добре да имаш предвид, ако ще ползваш резултатите за избор на tooling:
- Размер на dataset-а: текущият suite е сравнително малък; за по-надежден сигнал ще трябват повече тестове и по-широко покритие на API-та и патерни.
- Покритие по версии: benchmark-ът има уклон към по-нови WordPress 6.9 функционалности (като Abilities API и Interactivity API). Това е частично търсен ефект (новите API-та са трудни за моделите), но води и до bias, защото често тези неща са извън training data на повечето модели.
- „Насищане“ на benchmark-а: при по-стари WordPress концепции моделите могат да вадят много високи резултати, което означава, че въпросите/задачите не дават достатъчно различим сигнал. Истинското предизвикателство е да се формулират задачи, които са трудни не само защото са нови, а защото са наистина сложни.
Защо това е важно за нас като WordPress разработчици
Ако приемем, че AI асистентът ще бъде част от ежедневния toolchain, тогава въпросът не е дали моделът може да пише PHP, а дали може да пише WordPress код, който:
- използва правилните hooks и API-та, вместо „измислени“ функции;
- пази coding standards и предвидими структури (които са важни за поддръжка в екип);
- има базови security гаранции (sanitization/validation/escaping, nonce/capability checks);
- реално минава тестове и се държи коректно в runtime.
WP-Bench е интересен точно защото премества фокуса от субективни демота към изпълними проверки в WordPress среда.
Къде да го следиш и с какво да започнеш
Най-прагматичният старт е: пускаш wp-core-v1 локално за моделите, които реално ползваш, и гледаш разликите в results.jsonl (там е детайлният лог по тестове). Ако работиш по вътрешен AI tooling за WordPress, това е удобен начин да валидираш regressions при смяна на модел или промяна на prompt-ове.
Ресурси от анонса:
- GitHub repo: WP-Bench
- Контекст за AI в WordPress: AI Building Blocks for WordPress
- Slack канал: #core-ai
Практическа бележка
Когато сравняваш модели, гледай не само общия score, а и категориите задачи, които са релевантни за твоята работа (например security и database операции). Един модел може да изглежда „по-добър“ общо, но да прави систематични грешки в точно твоите критични области.
Обобщение
WP-Bench е опит WordPress екосистемата да си изгради общ език за това как измерваме качеството на AI моделите спрямо реални WordPress задачи. Комбинацията от Knowledge тестове и Execution задачи, проверени в WordPress runtime, е добра посока — особено ако dataset-ите се разширят и започнат да покриват повече от реалните „остри ръбове“ на разработката.
Елена Димитрова
Специалист по дигитален маркетинг и анализи. Интересувам се от Google Analytics и вземане на решения, базирани на данни. Измерването е първата стъпка към развитието.
Всички публикации
