Autonoom experimenteren

Wat is autonoom experimenteren?

Autonoom experimenteren is een loop die draait zonder iemand in de cyclus. Er wordt iets gewijzigd, het resultaat wordt afgemeten aan een score die het systeem zelf uitrekent, de winnaar blijft staan, en het begint opnieuw. Je zet hem 's avonds aan en leest 's morgens een gerangschikte lijst. Een instelling veranderen en meten is altijd al wat tunen was; nieuw is dat allebei die helften zonder jou gebeuren, honderden keren na elkaar.

Voor zo'n loop kan draaien, moeten er drie dingen bestaan. De meeste ideeën sneuvelen op een van de drie.

1. Een wijziging die het systeem alleen kan doorvoeren. Een waarde in een configuratiebestand, een prompt, een chunkgrootte. Iets dat werkt zodra er een waarde weggeschreven wordt, en niet iets waarvoor iemand een pipeline moet herbouwen.

2. Een score die het systeem berekent zonder iemand iets te vragen. Hoeveel van 120 opgeslagen vragen de juiste passage terugkregen, of hoe ver de forecast van vorig jaar naast de werkelijke cijfers zat. Moet er iemand elk resultaat beoordelen, dan heb je een wachtrij werk voor die persoon en geen loop.

3. Een veilige plek om te draaien, waar een slechte variant niets kost. Een kopie van de data, een agent sandbox, een aparte database. Schrijft variant tien van driehonderd naar het echte grootboek, dan is dat geen experiment maar een incident.

Ontbreekt er een van de drie, dan is dit werk nog niet klaar om over te dragen. Het ontbrekende stuk is bijna altijd het tweede.

Waar dit vandaag echt draait

Het stuk waar een gewoon team bij kan, is werk aan modellen, prompts en retrieval. Optuna noemt een run een study die uit trials bestaat, waarbij een trial een enkele oproep is van de objective function die jij schreef. Je geeft per instelling aan welke waarden ze mag aannemen en legt een stopregel vast: n_trials begrenst het aantal pogingen, timeout legt de study stil na zoveel seconden, en de pruners stoppen volgens de documentatie zelf de trials die er vroeg in de training al niet veelbelovend uitzien. Een optimizer in DSPy doet hetzelfde voor prompts: geef hem jouw programma, een reeks voorbeelden en een metriek, en hij herschrijft de instructies en kiest few-shot voorbeelden om die metriek omhoog te krijgen, binnen een budget dat je met max_metric_calls vastlegt.

De andere wereld is fysiek. Een self-driving lab hangt dezelfde loop aan robots: een model stelt een experiment voor, een machine voert het uit, een toestel meet het product, en het resultaat bepaalt wat er hierna geprobeerd wordt. Het A-Lab van Berkeley Lab deed 353 experimenten in 17 dagen ononderbroken draaien en maakte 36 verbindingen uit een lijst van 57 doelen. Dat is een onderzoeksinstelling met meerjarige financiering, geen capaciteit die je kan kopen, en ze hoort hier thuis omdat de loop dezelfde is.

Uitgewerkt voorbeeld: een run van één nacht

Een technische groothandel heeft een interne assistent die de productfiches en de datasheets van leveranciers doorzoekt. Sommige dagen kloppen de antwoorden, andere dagen niet, en niemand kan zeggen welke instelling daar verantwoordelijk voor is.

De score. Twee mensen zetten een dag opzij en schrijven 180 echte vragen op, met bij elke vraag het document en de pagina waar het antwoord staat. Die lijst is de hele basis van de run. Ze splitsen hem: 120 vragen mag de loop zien, 60 gaan opzij en worden nooit aangeraakt.

De zoekruimte en het budget. Chunkgrootte op 300, 600 of 1000 tokens; overlap op geen of 15 procent; 3, 5 of 8 chunks per vraag; reranker aan of uit. Dat zijn 36 combinaties, klein genoeg om ze allemaal te proberen, zodat de winnaar geen bijproduct van de zoekmethode kan zijn. Maal 120 vragen kom je op 4.320 gescoorde vragen, met drie plafonds errond: 5.000 model-calls, vier uur op de klok en een harde grens op de kost, wat het eerst bereikt wordt. De run start om 22 uur en schrijft elke variant, met zijn instellingen en zijn score, naar een tabel.

Het resultaat. De configuratie die vandaag live staat, chunks van 600 tokens zonder overlap, 5 chunks, geen reranker, haalt 71 op 120, dus 59 procent. De winnaar is 300 tokens met 15 procent overlap, 8 chunks en de reranker aan, op 103 op 120, dus 86 procent.

De controle op de apart gehouden vragen. De volgende ochtend draait iemand alleen die twee configuraties tegen de 60 vragen die de loop nooit zag. De oude haalt 35 op 60, dus 58 procent; de winnaar haalt 48 op 60, dus 80 procent. Het verschil is gekrompen van 27 naar 22 punten, en net daarvoor hield je die 60 apart: een deel van de winst van die nacht was de loop die zich naar die specifieke 120 vragen geplooid had.

Wat de run bewijst, is beperkt. De juiste passage werd vaker opgehaald. Of de assistent daarna ook een correct antwoord schrijft, is een andere meting die niemand deed, acht chunks en een reranker kosten meer tokens en meer wachttijd dan de score enige reden had om mee te tellen, en over de vragen die niemand opschreef zegt het niets.

De score is het hele ontwerp

Alles wat de loop doet, is zoeken naar de goedkoopste manier om één cijfer omhoog te krijgen. Daarmee is de keuze van dat cijfer de hele ontwerpbeslissing, en er zijn twee manieren om ze fout te maken.

Een score die je omhoog krijgt zonder dat er iets verbetert. Scoor een samenvatter op lengte en je krijgt lange samenvattingen. Scoor retrieval op de vraag of het juiste document ergens in de top 20 belandt en je krijgt een configuratie die 20 documenten teruggeeft. De loop speelt niet vals, hij doet exact wat je vroeg. Het gat dichten tussen het cijfer en waar het je eigenlijk om ging, is jouw werk, en het gebeurt voor de run vertrekt.

Het A-Lab laat zien hoe scherp dat wordt. De score daar was of de gezochte verbinding als hoofdfase uit de oven kwam met meer dan 50 procent opbrengst, beoordeeld door een geautomatiseerde verfijning van het röntgendiffractiepatroon. Begin 2024 gingen Robert Palgrave van University College London en Leslie Schoop van Princeton opnieuw door die data en besloten ze dat de verfijning fases verkeerd had geïdentificeerd, en dat twee derde van de voorspelde structuren geordende versies waren van verbindingen waarvan al geweten was dat ze ongeordend zijn. Gerbrand Ceder, die het A-Lab leidde, antwoordde dat een mens die verfijning van betere kwaliteit kan doen, en dat het opzet was te tonen wat een autonoom lab aankan, niet wat een goede mens aankan. Allebei die uitspraken kunnen tegelijk kloppen, en de les blijft dezelfde: de loop was precies zo goed als het ding dat scoorde, en niets erbinnen kon merken dat net dat de zwakke schakel was.

Overfitting op de set waarop je getuned hebt. De documentatie van scikit-learn zegt het mechanisme onomwonden: omdat je aan de instellingen kan blijven draaien tot het model optimaal presteert, lekt kennis over de testset het model binnen en zeggen de evaluatiecijfers niets meer over hoe het model op nieuwe data presteert. Een automatische loop doet dat sneller en harder dan een mens, want hij probeert honderden combinaties in plaats van vijf. GEPA in DSPy waarschuwt er in de tooling zelf voor: draai je hem met de trainingsset die tegelijk als validatieset dienstdoet, dan krijg je te horen dat je overfitting riskeert.

Hou dus voorbeelden apart voor de run start, hou ze uit elke ronde, en gebruik ze één keer, op de twee of drie configuraties die overbleven. Zakt de voorsprong van de winnaar daar in elkaar, dan heeft de loop iets gevonden over jouw tuningset en niet over je bedrijf. Het is dezelfde redenering als bij een train-test split, toegepast op configuraties in plaats van op modelgewichten.

Autonoom experimenteren versus een A/B-test

Het zijn allebei experimenten met varianten en een winnaar. Het verschil dat telt: wie of wat levert de uitkomst waaraan de run gescoord wordt.

Bij een A/B-test komt die uitkomst van echte klanten. Je zet variant B live voor een deel van het verkeer en wacht tot die mensen kopen, klikken, opzeggen of niets doen. Niemand kan dat vooraf berekenen, en daarom kost een A/B-test echt geld als B slechter is, heb je genoeg bezoekers nodig voor het verschil iets betekent, en duurt hij weken in plaats van minuten. Bij autonoom experimenteren komt de uitkomst uit data die je al hebt, dus komt er geen klant aan te pas, kost een verkeerde variant een paar cent aan rekenkracht, en raakt de loop door 36 varianten in één nacht. Gebruik de loop om van 36 configuraties naar de twee te gaan die een echte proef waard zijn, en laat de klanten kiezen tussen die twee.

Waar moet je op letten bij autonoom experimenteren

Geef hem een hard budget waar niet over te discussiëren valt. Een plafond op het aantal pogingen, op de klok en op de kost. Een loop zonder plafond draait een heel weekend en een factuur van vier cijfers stuk om een score een half punt te verzetten.

Schrijf de zoekruimte met de hand uit. De loop probeert wat jij opsomde en niets anders. Een open opdracht om de pipeline te gaan verbeteren is geen zoekruimte, dat is een agent met toegang tot productie.

Niets schrijven naar een echt systeem. De loop leest een kopie en schrijft naar zijn eigen werkruimte. Er gaat niets live tenzij een mens het bewust toepast, met de cijfers van de apart gehouden set erbij.

Hou elke variant bij, niet enkel de winnaar. Instellingen, score, seed, versie van de data, tijdstip. Daar dient experiment tracking voor, en zonder dat is de winnende configuratie een cijfer dat iemand om half acht van een scherm aflas en dat in november niet meer te reproduceren valt.

Daarnaast is er de grens die geen enkele regel wegneemt. De loop optimaliseert het cijfer dat jij hem gaf, vindt de goedkoopste weg om het omhoog te krijgen, en kan niet merken dat het het verkeerde cijfer was. Die controle blijft bij een mens, en ze gebeurt voor de run.

Twee situaties maken zo'n nachtelijke loop meteen het verkeerde gereedschap. De eerste: alles waarvan de uitkomst pas weken later zichtbaar wordt, zoals een prijswijziging die je in de verlengingen van volgend kwartaal terugziet. Die score kan je vanavond niet berekenen, dus is er niets om op te loopen. De tweede: alles waarbij een variant die bij een echte klant terechtkomt zelf het experiment is. Dat is een A/B-test. Daar hoort een mens bij die verantwoordelijk is voor wat klanten te zien krijgen, en een manier om terug te draaien, geen planner die om 22 uur vertrekt.