SUPERAGENTS.md: benchmark-arkkitehtuuri kehityksen todentamiseen

Moniulotteinen pisteytys (0-100), portaittaiset vaikeustasot
(CRUD → relaatiot → liiketoimintalogiikka → kehittyneet patternit),
historiavertailu ja regressiotunnistus.
This commit is contained in:
2026-04-14 07:16:37 +03:00
parent 7221f5e920
commit 8f154a578c

View File

@@ -128,6 +128,155 @@ Automaattinen promptien optimointi geneettisellä algoritmilla.
Yhdistetään kaikki tasot: järjestelmä **valitsee parhaan mallin tehtävään** (taso 3), **käyttää opittuja prompteja** (taso 2), **korjaa virheensä itse** (taso 4), ja **parantaa promptejaan joka kierroksella** (taso 5). Yhdistetään kaikki tasot: järjestelmä **valitsee parhaan mallin tehtävään** (taso 3), **käyttää opittuja prompteja** (taso 2), **korjaa virheensä itse** (taso 4), ja **parantaa promptejaan joka kierroksella** (taso 5).
## Benchmark — kehityksen todentaminen
Ilman kunnollista pisteytystä ja historiaa ei voi todentaa kehitystä. Benchmark-järjestelmä tarvitsee kolme kerrosta: **metriikat**, **vaikeustasot** ja **historiavertailu**.
### Metriikat
Yksittäinen "PASS/FAIL" ei riitä. Jokainen ajo pisteytetään moniulotteisesti:
| Metriikka | Mitä mittaa | Pisteytys |
|-----------|------------|-----------|
| **Parsittavuus** | Tuottiko malli kaikki 5 tiedostoa oikeilla markereilla? | 05 (tiedostoa) |
| **Syntaksi** | Parsitaanko koodi virheettä? | 04 (.py-tiedostot) |
| **Importit** | Ovatko kaikki importit resolvable? | 0/1 per tiedosto |
| **Testit** | Pytest pass rate | passed / total (0.01.0) |
| **Korjauskierrokset** | Montako korjausta tarvittiin? | 0 = paras, >2 = huono |
| **Token-tehokkuus** | Tokenia per läpäisty testi | pienempi = parempi |
| **Nopeus** | tok/s ja kokonaisaika | isompi tok/s = parempi |
| **Varoitukset** | Deprecation warnings, style issues | 0 = paras |
**Kokonaispistemäärä** (0100):
```
score = (
parsittavuus/5 * 15 + # 15p: tiedostot syntyvät
syntaksi/4 * 15 + # 15p: koodi parsitaan
testit * 40 + # 40p: testit menevät läpi (tärkein)
(1 - korjaukset/max) * 10 + # 10p: ei tarvitse korjauksia
tehokkuus_norm * 10 + # 10p: vähän tokeneita per testi
nopeus_norm * 10 # 10p: nopea generointi
)
```
Testien paino on 40% koska toimiva koodi on tärkein. Parsittavuus ja syntaksi ovat "pääsyvaatimuksia" — ilman niitä testejä ei voi edes ajaa.
### Vaikeustasot
Kolme nykyistä skenaariota (todo, users, blog) ovat kaikki samaa tasoa. Kehityksen mittaamiseen tarvitaan portaikko:
**Taso 1 — Perus-CRUD** (nykyiset)
- Yksi entiteetti, ei relaatioita
- Esim. todo, users
- Odotettu tulos: 100% kaikilla kelvollisilla malleilla
**Taso 2 — Relaatiot** (nykyinen blog)
- 23 entiteettiä, foreign key -viittaukset
- Esim. blog (author → post), kirjasto (author → book)
- Haaste: relaatioiden oikea käsittely, cascade
**Taso 3 — Liiketoimintalogiikka**
- Validointisääntöjä, tilasiirtymiä, laskentaa
- Esim. verkkokauppa (tuote → tilaus → tilausrivi, varastosaldo, hintalaskenta)
- Haaste: pelkkä CRUD ei riitä, tarvitaan custom-endpointeja
**Taso 4 — Kehittyneet patternit**
- Autentikointi, middleware, taustatehtävät, WebSocket
- Esim. chat-sovellus (käyttäjä → huone → viesti, reaaliaikainen, online-status)
- Haaste: arkkitehtuuriosaamisesta, ei vain tietomallista
**Skenaariot per taso:**
```python
SCENARIOS = [
# Taso 1 — Perus-CRUD
{"id": "todo", "level": 1, "prompt": "Todo-sovellus: tehtävien hallinta, deadline, prioriteetti ja status"},
{"id": "users", "level": 1, "prompt": "REST API käyttäjähallinnalle SQLite-tietokannalla"},
{"id": "notes", "level": 1, "prompt": "Muistiinpanosovellus: otsikko, sisältö, tagit, luontipäivä"},
# Taso 2 — Relaatiot
{"id": "blog", "level": 2, "prompt": "Blogi-API: kirjoittajat ja artikkelit, julkaisupäivämäärä ja status"},
{"id": "library", "level": 2, "prompt": "Kirjasto-API: kirjailijat, kirjat ja lainaukset, palautuspäivä ja sakko"},
{"id": "school", "level": 2, "prompt": "Kouluhallinto: opettajat, kurssit ja ilmoittautumiset, arvosanat"},
# Taso 3 — Liiketoimintalogiikka
{"id": "shop", "level": 3, "prompt": "Verkkokauppa: tuotteet, tilaukset ja tilausrivit, varastosaldo vähenee tilauksessa, kokonaishinta lasketaan automaattisesti"},
{"id": "booking", "level": 3, "prompt": "Varausjärjestelmä: resurssit ja varaukset, päällekkäiset varaukset estetään, peruutus vapauttaa ajan"},
{"id": "project", "level": 3, "prompt": "Projektinhallinta: projektit, tehtävät ja kommentit, tehtävän status-siirtymät (todo→doing→done), projektin edistymisprosentti lasketaan tehtävistä"},
]
```
### Historiavertailu
Tulokset tallennetaan aikasarjana jotta kehitys näkyy:
```
benchmark-history/
├── 2026-04-14_1200_v1.json ← ensimmäinen ajo
├── 2026-04-14_1500_v2.json ← prompti paranneltu
├── 2026-04-15_0900_v3.json ← few-shot lisätty
└── latest.json ← symlink uusimpaan
```
**Jokainen tallennus sisältää:**
```json
{
"version": "v3",
"timestamp": "2026-04-15T09:00:00Z",
"prompts_hash": "a3f2c1...",
"results": [
{
"model": "qwen3-coder-next",
"scenario": "todo",
"level": 1,
"score": 85,
"metrics": {
"parsability": 5,
"syntax": 4,
"tests_passed": 6,
"tests_total": 6,
"fix_rounds": 0,
"tokens": 2100,
"tok_per_sec": 72,
"warnings": 0
}
}
],
"summary": {
"avg_score": 72,
"pass_rate": 0.67,
"by_level": {"1": 95, "2": 72, "3": 48}
}
}
```
**Kehitysraportti** (automaattinen vertailu edelliseen):
```
╔═══════════════════════════════════════╗
║ Kehitysraportti v2 → v3 ║
╠═══════════════════════════════════════╣
║ Kokonaispistemäärä: 62 → 72 (+10) ║
║ Pass rate: 44% → 67% (+23) ║
║ Taso 1: 80 → 95 (+15) ║
║ Taso 2: 60 → 72 (+12) ║
║ Taso 3: 45 → 48 (+3) ║
║ ║
║ Parantunut: pyproject-muoto ✓ ║
║ Parantunut: import-ongelmat ✓ ║
║ Ennallaan: liiketoimintalogiikka ║
╚═══════════════════════════════════════╝
```
### Regressiotunnistus
Jos promptimuutos parantaa yhtä skenaariota mutta rikkoo toisen, se pitää havaita:
- Jokaisella ajolla verrataan **kaikkia skenaarioita** edelliseen
- Jos mikä tahansa skenaario laskee >10 pistettä → **varoitus**
- Jos taso 1 (perus-CRUD) laskee → **esto** (perustason pitää aina toimia)
## Toteutusjärjestys ## Toteutusjärjestys
``` ```