Continual learning

Wat is continual learning?

Continual learning is het idee dat een model zichzelf blijft bijwerken met nieuwe data nadat het is uitgerold, in plaats van bevroren te blijven op het moment dat de training stopte. Het is wat mensen bedoelen wanneer ze in een eerste gesprek vragen of dat ding leert van hun correcties.

Als onderzoeksdoel is het scherp omschreven. Google Research beschreef het in november 2025 als het vermogen van een model om na verloop van tijd nieuwe kennis en vaardigheden op te pikken zonder de oude te vergeten, en voegde eraan toe dat de kennis van een model vandaag beperkt blijft tot wat in zijn context zit of tot wat het tijdens de pre-training heeft geleerd. Die tweede helft is het eerlijke antwoord voor alles wat je nu kan aankopen.

De modellen waar een KMO vandaag mee werkt, veranderen hun gewichten niet omdat iemand ze verbeterd heeft. Verbeter tien keer hetzelfde factuurveld en de elfde run vertrekt van precies hetzelfde model als de eerste. Er kan tussen maandag en vrijdag wel degelijk iets beter worden. Alleen wordt het niet beter binnenin het model, en dat verschil bepaalt wie het kan aanpassen, wie het kan lezen en wie het kan terugdraaien.

Wat verandert er echt als een systeem lijkt bij te leren

Drie mechanismen zorgen voor de schijn van bijleren. In elk product doen er een of twee het werk, en het loont om te benoemen welke.

• Het staat in de context. Verbeter je de assistent binnen één gesprek, dan houdt hij die correctie vast tot de sessie stopt. De API-documentatie van OpenAI is daar duidelijk over: elke aanvraag om tekst te genereren staat op zichzelf en is stateless, en de continuïteit die je ziet bestaat omdat je toepassing de eerdere berichten bij elke oproep opnieuw meestuurt.

• Het is naar een memory store geschreven. Een bestand of een rij in een database buiten het model, tijdens het gesprek geschreven en later opnieuw ingelezen. De memory tool van Anthropic werkt client-side: het model vraagt bestandsbewerkingen aan en jouw toepassing voert ze uit op opslag die jij beheert. Copilot Studio doet hetzelfde in opslag die Microsoft beheert, één map per gebruiker, in een cyclus die ze capture, store, apply noemen.

• Iemand heeft iets aangepast. Een collega heeft de system prompt bijgewerkt, een regel toegevoegd aan een instructiebestand, of een verbeterd document in de verzameling gezet die RAG doorzoekt. Dit is veruit de vaakst voorkomende reden waarom een assistent zichtbaar beter werd, en meteen ook de reden die niemand de eer geeft, want de verandering gebeurde in een bestand en niet in het gesprek.

Geen van de drie raakt het model aan. Alle drie veranderen ze wat het model leest voor het antwoordt. Zegt een leverancier dus dat zijn product leert van jouw feedback, dan maken vier vragen het duidelijk: welke van de drie draait er, waar wordt het bewaard, kan je het lezen, en kan je het voor één persoon wissen.

Eén regel, teruggevolgd

Een technische groothandel bij Hasselt laat een assistent orderbevestigingen opstellen. In april begon het verkoopteam te vragen om de leveringsvoorwaarden als aparte paragraaf voor één klantengroep, en na een paar correcties deed de assistent het uit zichzelf. De lezing in het bedrijf lag voor de hand: hij had de regel geleerd.

In augustus stopte hij ermee.

Uitzoeken waarom kostte twintig minuten en drie controles. Het model-ID stond vastgepind en was niet verschoven, dus er was niets van de leverancier binnengekomen. Er bestond geen fine-tuned model. Wat er wel was: één regel in het persoonlijke geheugen van de accountmanager die de correcties had gedaan, en die was zes weken weg geweest. De leverancier wist het geheugen van een gebruiker na een periode zonder interactie, en die regel ging mee.

Daar volgen twee dingen uit, en geen van beide gaat over het model. De regel gold alleen wanneer die ene collega met de assistent werkte, want het geheugen in dat product staat per gebruiker. En de oplossing was niet vaker corrigeren. Ze was de regel verhuizen naar het instructiebestand dat elke sessie inleest, een gedeeld bestand met een eigenaar die het nakijkt.

Dat is meteen ook het antwoord wanneer een collega zegt dat de assistent zijn voorkeuren heeft geleerd. Hij heeft iets gelezen dat iemand heeft opgeschreven, en je kan gaan kijken wat dat precies is.

Waarom continual learning moeilijk is

Dit is geen functie waar nog niemand aan toe gekomen is. Het zijn twee open problemen.

Het eerste is catastrophic forgetting. Train een netwerk bij op nieuwe data en het gaat achteruit op wat het al goed deed. Een team bij DeepMind publiceerde in 2017 een methode die daar deels omheen werkt door oude taken te onthouden en het leren af te remmen op net die gewichten die voor die taken tellen. Dat zegt genoeg over hoe wankel de afweging is: je koopt behoud door niet te bewegen. Onderzoekers die taalmodellen tussen ongeveer één en zeven miljard parameters in opeenvolgende rondes bijstuurden, zagen over dat hele bereik vergeten optreden, en het werd erger naarmate de modellen groeiden, niet beter. Google Research zette zijn eigen antwoord van november 2025 neer als een proof-of-concept architectuur, niet als een product.

Het tweede probleem is evaluatie. Een model dat voortdurend verandert, kan je niet één keer testen en dan certificeren, want wat je getest hebt is niet wat er morgen draait. De AI Act vangt dat op twee plaatsen op. Artikel 15(4) vraagt dat AI-systemen met een hoog risico die na het op de markt brengen blijven bijleren, zo gebouwd worden dat het risico dat vertekende output terug in de invoer van latere verwerkingen belandt, zoveel mogelijk wordt weggenomen of beperkt, met maatregelen voor de feedback loops die overblijven. Artikel 3(23) omschrijft een substantiële wijziging als een verandering na het op de markt brengen die niet voorzien was in de oorspronkelijke conformiteitsbeoordeling en die de conformiteit of het beoogde doel raakt, terwijl artikel 43 wijzigingen uitzondert die de aanbieder vooraf bepaalde en bij die eerste beoordeling in de technische documentatie zette. Een lerend systeem is dus niet verboden. Het moet op voorhand beschreven zijn, inclusief de grenzen waarbinnen het blijft.

Wat wel verandert, en op wiens agenda

Het gedrag verschuift wel degelijk in de tijd, alleen op de kalender van iemand anders. De leverancier traint opnieuw en brengt een nieuwe versie uit, en dat is waarom een assistent in oktober anders antwoordt dan in juni zonder dat iemand bij jou een prompt heeft aangeraakt. Het is een andere set gewichten achter een model-ID, op het schema van die leverancier. Ons artikel over modelversies en deprecation legt uit hoe je een ID vastpint zodat dit geen verrassing meer is.

De twee updates die jij wel in de hand hebt, zijn eenmalige klussen. Een fine-tuning run maakt van een dataset die je op één moment samenstelde een aparte modelversie, en die moet opnieuw wanneer het basismodel eronder met pensioen gaat. Een scoringsmodel of voorspellingsmodel elke maand hertrainen op verse data is het gewone antwoord op model drift. Beide zijn geplande releases: iemand start ze, iemand vergelijkt oud met nieuw, iemand kan terugdraaien. Net dat verlies je bij een model dat zichzelf bijwerkt.

Continual learning tegenover een memory store

De twee worden besproken alsof het één functie is in twee stadia van rijpheid. Wat ze scheidt, is wat er echt verandert wanneer het systeem lijkt bij te leren.

Bij continual learning veranderen de gewichten. Iedereen die dat model gebruikt deelt in die verandering, er is geen bestand dat iemand kan openen en nalezen, je kan één feit niet wissen zonder de rest aan te raken, en je kan een auditor niet tonen welke versie de cijfers van vorig kwartaal heeft geproduceerd. Bij een memory store verandert een bestand of een rij. Die hoort bij één gebruiker of één agent, je kan hem openen, een regel aanpassen, hem wissen, hem laten vervallen, en je kan een klant antwoorden die vraagt wat het systeem over hem bijhoudt. Daarom kiezen gereglementeerde omgevingen voor releases met een versienummer: een systeem dat zichzelf verandert is een systeem waarvan je geen vast dossier kan tonen, en een conformiteitsdossier wil net dat.

Waar zet je een correctie zodat ze blijft

Drie plaatsen, gerangschikt naar hoe goed ze standhouden in een klein bedrijf, telkens met de manier waarop ze stukgaan.

1. De documenten die retrieval doorzoekt. Antwoordde de assistent fout over het retourbeleid, pas dan het document over het retourbeleid aan dat retrieval inleest. De correctie geldt dan voor iedereen, blijft overeind bij een modelwissel en wordt nagekeken door wie dat document toch al beheert. Ze gaat stuk wanneer de oude versie naast de nieuwe in de index blijft staan en het model citeert wat het eerst tegenkomt.

2. Een instructiebestand. Een gedeeld bestand dat de agent bij het begin van elke sessie inleest: huisstijl, benamingen, welke klantengroep welke papieren nodig heeft. Het is leesbaar, je ziet de verschillen tussen versies, en het hoort in version control, dezelfde discipline als bij promptversiebeheer. Het gaat stuk door aan te groeien: een bestand dat niemand uitmest wordt een pagina met tegenstrijdige regels die bij elke oproep context kost.

3. Een memory store. Het dichtste bij bijleren dat vandaag bestaat, en meteen het minst gecontroleerde, want niemand keurt een regel goed voor die geschreven wordt. Het gaat op twee manieren stuk: een entry veroudert en wordt maanden later met evenveel stelligheid geciteerd, of iets dat een kwaadaardige invoer één keer schreef, wordt bij elke volgende run opnieuw ingelezen. Onze artikels over agent memory en memory poisoning gaan daarop in.

De menselijke versie van dezelfde wens heet compound engineering: na elke taak beslist iemand wat het waard was om bij te houden en schrijft het in het bestand dat de volgende taak inleest. Een team dat die stap overslaat, verbetert elke week dezelfde output in de overtuiging dat het het systeem aan het opleiden is, en doet dat volgend jaar nog altijd.