Discipline — productie-niveau testen op een onderzoeksvraagstuk.
Wat onze validatie-pijplijn deed toen een fundamentele aanname in onze eigen optimalisatie-laag onjuist bleek. Hoe wij het opvingen, en wat de discipline-praktijk doet die wij vervolgens op klantautomatiseringen toepassen.
Voor de volledigheid: dit gaat over AlphaPPO, ons R&D-platform — een experimenteel handelsplatform op simulatie-rekeningen, zonder klantrelaties of commercieel aanbod. De volledige verheldering staat in case study 1.
Een trading-systeem dat strategieën leert door experimenteren heeft een fundamenteel probleem.
Een trading-systeem dat strategieën leert door experimenteren op historische data heeft een fundamenteel probleem: een strategie die heel mooi presteert op een backtest kan in werkelijkheid waardeloos zijn. Het systeem heeft de geschiedenis «gelezen» en daar onbedoeld op overfit.
Daarom heeft AlphaPPO een aparte validatielaag — een proces dat elke strategie-aanpassing los toetst, met methoden die zijn ontworpen om zelf-bedrog te detecteren.
Drie checks — ontworpen om zelf-bedrog te detecteren.
- Rolling-window backtestsGeen enkele strategie wordt alleen op één tijdsvenster gemeten. Wij draaien dezelfde strategie over tientallen rollende vensters van historische data en kijken naar de spreiding in resultaten. Een strategie die alleen op één specifiek venster werkt, is geen strategie — het is overfitting.
- Statistische-significantie-testsBij elke strategievergelijking checken wij of de waargenomen verschillen statistisch significant zijn, niet zomaar ruis. Een «betere» strategie die op acceptabele significantie geen verschil maakt, krijgt geen voorrang.
- Out-of-sample-disciplineEen deel van de historische data wordt nooit gebruikt voor strategie-ontwikkeling — alleen voor finale validatie. Dat klinkt streng en dat is ook de bedoeling: het is de enige manier om met enige eerlijkheid te zeggen of een strategie zal werken op data die het systeem nog nooit heeft gezien.
Wij bouwen deze laag niet omdat het cool is. Wij bouwen het omdat het de enige manier is om vroeg te ontdekken dat onze eigen aannames niet kloppen — voordat een echte versie van het systeem op echte markten zou draaien.
Een beloningsfunctie die niet voldoende correleerde met portefeuille-rendement.
AlphaPPO leert via reinforcement learning. Dat betekent dat het systeem een beloningsfunctie heeft — een wiskundig signaal dat het systeem vertelt wat een goede uitkomst is. Het optimalisatieproces probeert die beloning te maximaliseren door te experimenteren met handelsstrategieën.
Onze validatie liet zien dat de beloningsfunctie niet voldoende correleerde met daadwerkelijk portefeuille-rendement. In gewone taal: het systeem leerde een getal te maximaliseren dat niet hetzelfde was als geld verdienen. Niet «een beetje af» — wezenlijk losgekoppeld.
Hadden wij geen rolling-window-backtests gehad, geen statistische-significantie-tests, geen out-of-sample-discipline, dan hadden wij dit niet kunnen detecteren. De bug was alleen zichtbaar door deze drie checks tegen elkaar te leggen.
Drie dingen, in volgorde.
- Documentatie van de bevinding Wij hebben de exacte methodiek vastgelegd waarmee wij de losse koppeling ontdekten — niet voor publicatie, maar zodat de bevinding reproduceerbaar is. Een ontdekking die niet reproduceerbaar is, is geen ontdekking; het is een hoop.
- Rebuild van de optimalisatielaag Wij hebben de optimalisatie herontworpen om direct portefeuille-rendement te targeten in plaats van de oude beloningsfunctie. Geen patch op de oude versie, geen tijdelijke fix — een nieuwe versie van de optimalisatielaag.
- Validatie van de rebuild Een nieuwe optimalisatieronde wordt door de hele validatie-pijplijn gehaald — rolling-window-backtests, statistische-significantie, out-of-sample. Of de rebuild beter werkt dan de oude versie wordt op basis van die validatie bepaald, niet op basis van hoe het ontwerp ervan eruitziet.
Binair op basis van die validatie.
Het uitkomst-scenario is binair op basis van die validatie:
- Alsde rebuild meetbaar betere strategieën produceertDanwij hebben een meer eerlijke versie van het systeem.
- Alsde rebuild geen meetbare verbetering laat zienDanwij hebben een sterk signaal dat de beloningsfunctie zelf opnieuw moet worden ontworpen, niet alleen de optimalisatie eromheen.
Beide uitkomsten zijn informatief. Dat is hoe een onderzoeksproject zich hoort te gedragen. Een project dat alleen «succesvolle» uitkomsten kan rapporteren is geen onderzoek; het is marketing.
De vraag verdwijnt niet — hij wordt op kleinere schaal gesteld.
Een werkflow-automatisering die wij voor een accountantskantoor bouwen — een deadlinetracker, een bankboekings-categorisering, een follow-up-systeem — heeft minder bewegende delen dan AlphaPPO. Dat betekent niet dat de validatie-vraag verdwijnt. Het betekent dat de vraag op een kleinere schaal wordt gesteld:
- Doet de werkflow daadwerkelijk wat hij beweert te doen?Niet alleen op de demo-data, maar op uw echte klantbestand met al zijn rommeligheid.
- Blijft hij dat doen wanneer de bronsystemen veranderen?Een API-update bij Moneybird, een nieuw veld in uw CRM, een verandering in hoe een klant zijn bankafschriften aanlevert.
- Heeft hij een manier om te tonen dat hij werkt?Of weet u het pas wanneer iemand klaagt?
Een werkflow die werkt op de dag van oplevering kan zes maanden later gebroken zijn zonder dat iemand het merkt. Wij bouwen werkflows die hun eigen werking aantoonbaar kunnen maken — niet uit perfectionisme, maar omdat het het verschil is tussen automatisering die uw kantoor stilletjes ondermijnt en automatisering die het versterkt.
Niet 655 tests. Niet drie validatielagen. Niet een regime-detector. Wel: de discipline om vooraf vast te stellen wat «werkt» betekent in uw context, dat te toetsen, en het toetsbaar te houden.
Klaar om te beginnen?
Vijftien minuten. Geen verkooppraatje. Wij bespreken uw werkflow en geven een eerlijk oordeel — Audit, Sprint, Webdesign, of geen fit.