Hoe voorkom je dat een AI-strategieagent informatie uit morgen lekt naar vandaag?

Een AI-strategieagent kan een geldige backtest opleveren terwijl hij informatie gebruikt die nog niet bestond toen de transacties hadden moeten plaatsvinden. De code werkt. De vermogenscurve ziet er aannemelijk uit. Het signaal kan zelfs logisch zijn. Toch heeft een tijdstempel, een join of een herzien dataveld ongemerkt het antwoord van morgen verklapt.

De oplossing is om beschikbaarheidstijd onderdeel te maken van de onderzoeksafspraken. Voor elke input moet er een duidelijk antwoord zijn op 2 vragen: op welke periode slaat deze waarde, en wanneer kon de strategie die voor het eerst kennen?

Hoe ziet lookahead bias eruit in een door AI gegenereerde strategie?

De voor de hand liggende variant is een signaal dat wordt berekend op basis van de slotkoers van dezelfde candle, gevolgd door een uitvoering op die slotkoers. Als de strategie de slotkoers nodig heeft om een beslissing te nemen, kan ze niet ook tegen die prijs handelen. Maar bij het koppelen van databronnen of het kiezen van handige standaardinstellingen creëren agenten vaak subtielere varianten.

Stel dat een model aan het einde van elke minuut een voortschrijdend gemiddelde over 20 candles berekent en een positie inneemt wanneer de slotkoers het gemiddelde kruist. Als de backtest tegen diezelfde slotkoers uitvoert, gebruikt hij de laatste transactie van de candle voordat die voor de strategie beschikbaar was. De order doorschuiven naar de opening van de volgende candle kan een redelijke benadering zijn, al moet je bij een market order nog steeds rekening houden met kosten en marktimpact.

Maak de feature nu een dagelijks fundamenteel gegeven over een aandeel of een momentopname van de open interest in crypto. De datum van de rij kan maandag aangeven, maar de waarde is misschien pas na de slotkoers van maandag gepubliceerd of later gecorrigeerd. Een datum is geen beschikbaarheidstijdstempel.

Hoe moet ik de inputs van een strategie van tijdstempels voorzien?

Bewaar waar de bron dat toelaat minstens 3 tijdstippen: de periode waarop een waarde betrekking heeft, het tijdstip waarop de uitgever die publiceerde en het tijdstip waarop je systeem die ontving. De informatieset van de strategie op het beslismoment mag alleen waarden bevatten die op dat moment beschikbaar waren.

Bij een 1-minuutstrategie is een vertraging van 1 seconde niet automatisch onschadelijk. Of die ertoe doet, hangt af van het beslismoment en van wat het signaal gebruikt. Bij een afgerond statistisch gegeven per uur maakt die misschien nauwelijks verschil. Bij een orderboekonevenwicht dat vlak voor de order wordt gemeten, kan die de transactie omkeren.

Kan een point-in-time-datastore datalekken voorkomen?

Dat helpt, als “point-in-time” betekent dat je de waarde kunt ophalen die op een historisch beslismoment bekend was, inclusief de revisie die toen gold. Een tabel met alleen historische datums kan nog steeds de huidige, gecorrigeerde waarden voor die datums bevatten.

Bewaar voor elk record een geldigheidsinterval en een beschikbaarheidstijdstempel, en bewaar revisies in plaats van ze te overschrijven. Maak historische zoekopdrachten vervolgens expliciet: geef de meest recente versie terug die beschikbaar was op het gesimuleerde beslismoment. Dit is vooral belangrijk voor fundamentele gegevens, indexlidmaatschappen, economische publicaties en opgeschoonde datasets van leveranciers.

Er is een weinig glamoureuze operationele complicatie: een perfecte publicatietijdstempel helpt niets als de ingestietaak 20 minuten te laat draaide. Als de historische datastore de ingestietijd niet vastlegt, gebruik dan een conservatieve vertraging en vermeld dat. Precisie die de bron nooit heeft geregistreerd, is alleen voor de sier.

Welke controles sporen lookahead bias op voordat je met paper trading begint?

Vraag de onderzoeksagent om naast de backtest een tijdlijn van features en orders te genereren. Leg voor elke beslissing de meest recente beschikbaarheidstijd van de bron voor elke feature vast, evenals het beslismoment, het ordermoment en het gemodelleerde uitvoeringsmoment. Wijs elke rij af waarin een input na de beslissing binnenkwam.

• Schuif signalen 1 candle vooruit en vergelijk de resultaten. Een flinke terugval kan wijzen op afhankelijkheid van timing tussen slotkoersen, maar dit is een diagnose en geen bewijs van datalekken.
• Beperk elke bron tot een historische peildatum, voer de pijplijn opnieuw uit en vergelijk de resulterende features met de opgeslagen historische features.
• Vervang een verdachte feature door een constante. Blijven de resultaten vrijwel identiek, controleer dan of de code de bedoelde reeks daadwerkelijk heeft gebruikt.
• Voer een bewust onmogelijke toekomstfeature door de pijplijn. De validatie moet een duidelijke foutmelding geven wanneer de beschikbaarheidstijd na het beslismoment ligt.

Deze controles certificeren geen strategie. Ze maken specifieke timingaanames zichtbaar en sporen veelvoorkomende schendingen daarvan op.

Bewijst paper trading dat de backtest geen datalekken bevatte?

Nee. Paper trading kan een live datapad aan het licht brengen dat vertraagd is, gegevens mist of anders is uitgelijnd dan het historische datapad. Het kan niet vaststellen of oude trainingsfeatures weergaven wat destijds bekend was. Een model kan ook ophouden te profiteren van een datalek, simpelweg omdat de toekomst die het per ongeluk zag inmiddels het heden is geworden.

Gebruik paper trading als een controle op overeenstemming: vergelijk de live featurewaarden, beslistijdstempels, ordergeneratie en gemodelleerde uitvoeringen met de definities uit de backtest. Verschillen ze, traceer dan de precieze input en klok. Een agentteam dat de informatieset van elke beslissing kan uitleggen, doet nuttig onderzoek. Een agentteam dat alleen een vloeiende curve kan laten zien, heeft de lastigste audit overgeslagen.