Hogyan öltem meg a saját backtestemet

A modell 60 feature-ből dolgozik. Ebből 12 (labdabirtoklás, lövések/90, védési arány, szabálytalanságok, hazai/vendég/különbség bontásban) egy fbref-táblából jön, ami csapatonként és szezononként egyetlen sort tartalmaz. Ez a sor viszont a teljes szezon összesítése — a szezon végén keletkezik.

row = fbref_df[(fbref_df["Squad"] == team) & (fbref_df["season"] == season)]
if len(row):
    return row.iloc[0]

Vagyis egy októberi meccs előrejelzésekor a modell már „tudta”, hogyan teljesít a csapat májusig. A gördülő (rolling) statisztikák és a keret-változás feature-ök tiszták voltak — csak ez az egy illesztés szivárgott, és ez elég volt ahhoz, hogy az egész eredmény hamis legyen.

A mérés négy változatot hasonlított össze ugyanazon a walk-forward kereten (2018/19–2022/23, szezononként újratanított modell, 17 356 meccs), ugyanazzal a döntési szabállyal, három különböző random seeddel. Kapcsold ki a szivárgást, és nézd, mi marad az élből.

A lényeg nem a pontos számokban van — azok ±1%-on belül szórnak —, hanem az előjelváltásban: a szivárgó változat mindhárom seeden +6% fölött van, minden tiszta változat a nulla körül. Ez nem zaj, hanem mechanizmus.

A mérés egy másik rejtélyt is megoldott. Élesben a modell rosszabbul teljesített, mint a backtestben, és ezt eddig „modell-zsugorodásnak” gondoltam. Valójában az éles rendszer a folyó szezonra még nem kapott fbref-sort, ezért az előző szezon adatait használta — ez a V2 állapot, −0,86%-kal.

A modellt tehát a V1-ben tanítottam, és a V2-ben futtattam. Ez a klasszikus train/serve skew: nem a modell romlott el élesben, hanem a tanítás hazudott.

A javítás nem egy sor törlése volt, hanem olyan szabályok, amik a következő hasonló hibát is elkapják:

• xfail(strict=True) teszt

  Egy teszt kifejezetten a szivárgást mutatja ki. Amíg a hiba fennáll, „várt hibaként” fut; ha valaki megjavítja, a teszt piros lesz, amíg a jelölést tudatosan le nem veszik. A hiba nem tűnhet el csendben.

• kötelező időablak

  A főkönyv csak egy kötelező ablak-paraméterrel olvasható, alapértelmezés nincs. Nem lehet „véletlenül” a teljes adatot betölteni.

• fail-closed záró ár

  Záró árnak csak a kezdés előtti pillanatkép számít. Ha nincs ilyen, a sor kimarad, és nem egy később mentett (élő) árral pótlódik.

• zárolt holdout + variáns-számláló

  Egy félretett, zárolt adathalmazhoz csak jóváhagyott körben lehet nyúlni, és minden kipróbált változat számít. 10 variáns fölött szigorúbb küszöb jön, 20 fölött a keresés leáll.

A mérést egy AI kódoló-agent (Claude Code) futtatta, előre rögzített szabályok között. Így dolgoztunk:

1. 01Külön ágon mért, a keresési ablakon belül (2023-07-01 előtt); a zárolt holdouthoz nem nyúlt.
2. 02A feladat mérés volt, nem javítás — a riportban külön „amit ez NEM állít” szakasz szerepel.
3. 03Az állítást három seeddel ellenőrizte, mielőtt kimondta, hogy nem zaj.
4. 04Az ágat én néztem át és mergeltem; a javítás külön döntés lett, dátummal rögzítve.
5. 05Szabály maradt: agent kódot ír és tesztel, élesbe, pénzhez és a main ágra csak ember nyúl.

• Minden ROI Pinnacle nyers áron értendő, döntési szabállyal szűrt tétekre — nem általános modell-pontosság.
• Egy hiperparaméter-készlet, három seed, öt szezon. Az előjelváltás robusztus, a ±1%-os különbségek nem.
• Nem állítom, hogy a modell menthetetlen — csak azt, hogy a mostani feature-készlettel, szivárgás nélkül ezen a mintán nincs kimutatható él.
• Ez kutatási projekt, nem tippszolgáltatás.

A szép backteszt gyanú, amíg a szivárgás-teszt nem zöld.

Ez azóta a projekt egyik alapszabálya. A legdrágább hiba nem az, amelyik elszáll, hanem az, amelyik csendben jó számokat ad.