WP-Bench: oficialus „WordPress“ AI benchmarkas, kuris pagaliau tikrina tai, kas mums svarbu

Jei esi bandęs naudoti coding assistant’ą kuriant įskiepį ar tvarkant temą, turbūt jau matei klasiką: modelis gražiai sugeneruoja PHP, bet nepaiso „WordPress“ coding standards, sumaišo hook’us, pasiūlo nesaugius SQL gabalus arba tiesiog parašo kodą, kuris realiame „WordPress“ neveikia. Iki šiol dauguma AI vertinimų buvo bendriniai (algoritmai, bendras web dev), o „WordPress“ specifika likdavo paraštėse.

„WordPress“ AI komanda pristatė WP-Bench – oficialų „WordPress“ AI benchmarką: atvirą testų rinkinį ir vertinimo sistemą, kuri bando atsakyti į paprastą klausimą: kiek gerai kalbos modeliai supranta „WordPress“ kūrimą ir kiek gerai jie sugeba sugeneruoti veikiantį, standartus atitinkantį kodą? Pagrindinis repo: github.com/WordPress/wp-bench.

Kodėl WP-Bench atsirado dabar (ir kodėl tai aktualu „WordPress“ dev’ams)

„WordPress“ maitina didelę dalį web’o, bet AI modeliai dažniausiai lyginami pagal universalias užduotis. Iš praktikos tai reiškia, kad modelis gali atrodyti „stiprus“ pagal bendrus testus, tačiau realiai strigti ties tokiais dalykais kaip WP_Query, capability patikros, REST endpoint’ų autorizacija, duomenų sanitizavimas/escaping ar net taisyklingas hook’ų naudojimas.

Geriau suprasti šiandienos modelius. Jei renkiesi, kurį modelį naudoti įrankyje (pvz., AI funkcijoms įskiepyje) ar kasdienėje dev’e, WP-Bench idėja – turėti „WordPress“ fokusą, o ne abstraktų programavimą.
Paveikti rytojaus modelius. Pagal paskelbimą siekiama, kad AI laboratorijos ir tiekėjai (pvz., OpenAI, Anthropic, Google) įtrauktų „WordPress“ į savo prieš-release vertinimus. Kitaip tariant: kad „WordPress“ našumas nebūtų „afterthought“.
Atvira, vieša rezultatų kryptis. Komanda juda link viešos „leaderboard“ (reitingų lentelės), kuri leistų skaidriai matyti modelių rezultatus „WordPress“ užduotyse ir padėtų bendruomenei priimti sprendimus.

Kaip WP-Bench matuoja modelius: Knowledge + Execution

WP-Bench vertina modelius dviem kryptimis, kurios „WordPress“ atveju labai skiriasi.

1) Knowledge: „WordPress“ žinios (multiple-choice)

Tai klausimai su pasirenkamais atsakymais apie „WordPress“ koncepcijas: core API, hook’us, saugumo šablonus, coding standards. Akcentuojami ir modernesni papildymai, pvz., Abilities API ir Interactivity API – būtent naujesnėse vietose modeliai dažnai stringa, nes jų mokymo duomenys gali būti pasenę.

2) Execution: kodo generavimas su realiu „WordPress“ runtime vertinimu

Šita dalis, mano akimis, yra didžiausias WP-Bench „kablys“. Modelis ne tik sugeneruoja kodą – tas kodas paleidžiamas „WordPress“ aplinkoje (sandbox’e), atliekama statinė analizė, o po to vykdymo metu tikrinamos assertions (t. y. testinės sąlygos). Tokiu būdu vertinama ne vien teorija, bet ir praktinė kompetencija: ar kodas realiai veikia ir ar atitinka standartus.

Vertinimo pipeline: kas tiksliai vyksta po prompt’o

Pagal aprašytą procesą WP-Bench naudoja „WordPress“ kaip „graderį“ (vertintoją) ir automatizuoja visą grandinę.

Benchmark harness (valdymo įrankis) siunčia modelio provider’iui prompt’ą su užduotimi sugeneruoti „WordPress“ kodą.
Sugeneruotas kodas perduodamas „WordPress“ runtime’ui per WP-CLI (komandinės eilutės įrankį, skirtą valdyti „WordPress“ instaliaciją).
Runtime’as atlieka statinę analizę: sintaksė, coding standards, saugumo patikros.
Kodas vykdomas sandbox’e, paleidžiami testai ir assertions.
Rezultatas grįžta JSON formatu su score’ais ir detalesniu feedback’u.

Kodėl tai svarbu praktiškai

Kai modelį vertini per realų „WordPress“ vykdymą, nebeužtenka „panašaus į teisingą“ kodo. Išlenda edge case’ai: neteisingi hook’o parametrai, netinkami sanitizavimo/escaping pasirinkimai, nepagrįstos prielaidos apie global’us, klaidos su wpdb ir pan.

Greitas startas: kaip paleisti WP-Bench lokaliai

WP-Bench repo struktūra atskiria dvi dalis: Python harness (kuris kalbasi su modeliais ir orkestruoja testus) ir „WordPress“ runtime (graderis), kuris realiai paleidžia sugeneruotą kodą. Žemiau – minimalus kelias, kad turėtum pirmą rezultatų failą.

1) Instaliacija (Python virtualenv + editable install)

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) API raktai per .env

WP-Bench numato, kad dirbsi su modelių tiekėjų API. Susikurk .env failą ir sudėk raktus pagal tai, kuriuos provider’ius naudos tavo config’as:

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) Paleisk „WordPress“ runtime (graderį)

Runtime kataloge yra Node.js dalis su wp-env konfiguracija ir grader plugin’u. Paleidimas:

cd runtime
npm install
npm start

cd runtime
npm install
npm start

4) Paleisk benchmarką

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

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

Pagal aprašymą rezultatai rašomi į output/results.json, o per-test log’ai – į output/results.jsonl. Tai patogu, jei vėliau nori vizualizuoti ar filtruoti pagal kategorijas.

Multi-model paleidimai: realus palyginimas vienu šūviu

Jei nori lyginti kelis modelius vienodomis sąlygomis, WP-Bench leidžia išvardinti kelis models config’e. Harness juos prasukinėja nuosekliai ir pateikia palyginimo lentelę. Modelių pavadinimai remiasi LiteLLM conventions (LiteLLM – sluoksnis, kuris suvienodina skirtingų provider’ių modelių kvietimus ir vardinimą): docs.litellm.ai/docs/providers.

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

Konfigūracija: ką realiai verta pasikeisti

Repo pateikia wp-bench.example.yaml, kurį verta nusikopijuoti ir pritaikyti. Pagrindinės vietos: dataset šaltinis, modeliai, grader (docker), suite pasirinkimas, limit’as ir concurrency.

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

Naudingos CLI komandos

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

Dataset’ai ir testų rinkiniai: kaip sudėliota struktūra

Testų rinkiniai (suites) laikomi datasets/suites/<suite-name>/ ir kiekvienas suite turi dvi dalis: knowledge/ (multiple-choice) ir execution/ (kodo generavimo užduotys su assertions). Pagal paskelbimą numatytas default suite yra wp-core-v1 – jis dengia „WordPress“ core API, hook’us, DB operacijas ir saugumo šablonus.

Įkėlimas iš Hugging Face

Jei nori naudoti dataset’ą iš Hugging Face, config’e pakeiti dataset.source ir name:

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

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

Dabartinė būsena ir ribojimai: ką svarbu žinoti prieš interpretuojant score’us

WP-Bench šiuo metu įvardijamas kaip ankstyvas leidimas, todėl rezultatus verta skaityti su kontekstu.

Nedidelis dataset’as. Dabartinis testų kiekis dar nėra pakankamas, kad tai būtų „galutinis“ WordPress AI matas. Reikia daugiau testų per įvairias API ir realius pattern’us.
Versijų šališkumas į naujoves. Benchmarkas labiau krypsta į „WordPress 6.9“ funkcijas (pvz., Abilities API, Interactivity API). Tai iš dalies sąmoninga, nes naujovėse modeliai stringa, bet tuo pačiu tai gali šališkai numušti modelius, kurių mokymo duomenys senesni.
„Saturation“ senesnėse temose. Ankstyvi bandymai parodė, kad modeliai labai aukštai surenka score’us ant senų, gerai žinomų „WordPress“ konceptų – tokie klausimai duoda mažai signalo. Iššūkis: surasti užduotis, kurios yra tikrai sunkios, o ne tik naujos.

Kam tai pravers praktiškai (net jei nesi AI lab’e)

Net jei nekuri „modelių“ ir netreniruoji LLM, WP-Bench gali būti naudingas kaip bendras atskaitos taškas renkantis įrankius: kokiam modeliui patikėti refactor’ą, kuris geriau laikosi „WordPress“ saugumo praktikų, kuris mažiau „haliucinuoja“ API, o kuris geriau rašo testuojamą kodą. Ilgainiui vieša leaderboard kryptis turėtų padėti sumažinti sprendimų priėmimą „iš nuojautos“.

Kur rasti ir kaip prisidėti

WP-Bench yra open source ir, pagal paskelbimą, stipriai remiasi bendruomenės indėliu: testų atvejais, griežtesniu vertinimu ir rezultatų pateikimu. Pradžios taškas – GitHub repo: https://github.com/WordPress/wp-bench. Papildomas kontekstas apie „WordPress“ AI kryptį: AI Building Blocks for WordPress. Taip pat minima diskusijų erdvė „WordPress“ Slack’e: #core-ai.