Een eigen toetsset maakt ‘elk model’ waar

Sinds de herbouw herhaal ik dat Inora niet van één taalmodel mag afhangen. Het is een makkelijke zin. Deze week vroeg ik me af wat ik nodig heb om hem te bewijzen, en het antwoord is ongemakkelijker dan de zin.

Wisselen zonder toets is een sprong

Elf weken nadat de eerste organisaties met Inora aan het werk gingen, is de keuze van het model voor ons een variabele geworden in plaats van een gegeven. Er komt een nieuw model uit, iemand zegt dat het beter is, en dan? Beter waarin, en op wiens vragen? Een openbare ranglijst zegt hoe een model het doet op andermans opdrachten. Over een vraag in de nachtdienst naar een wondprotocol dat in twee versies bestaat, zegt hij niets.

Daarom reken ik de eigen set vragen van een organisatie, met de antwoorden die haar eigen kwaliteitsmedewerkers goed vinden, nu tot de voorwaarden voor ‘elk model’. Zonder die set is wisselen een sprong in het diepe. Mét die set is het een run: dezelfde vragen, het nieuwe model, en een vergelijking. Wie keuzevrijheid belooft zonder een manier om die na te gaan, belooft iets wat hij niet kan zien.

Nieuw is dit niet, en ik heb het niet bedacht. Hamel Husain betoogde dat producten op basis van taalmodellen meestal om dezelfde reden mislukken: niemand schreef productspecifieke toetsen, en de remedie is elke fout die je ziet om te zetten in een toets die blijft. Sayash Kapoor en Arvind Narayanan lieten zien hoe vaak agents alleen op juistheid worden beoordeeld en de kosten buiten beeld blijven, en vroegen om een vergelijking met een goedkope basislijn tegen gelijke kosten. Beide neem ik over zoals ze zijn.

Wat een goed antwoord is

Bij ons zijn fouten niet symmetrisch. Een stellig antwoord terwijl de bronnen zwijgen is erger dan een gewoon “dit staat niet in onze bronnen”. Dat laatste telt als een goede uitkomst. Het referentieantwoord is het eigen protocol van de organisatie, en als ooit een model een ander model beoordeelt, moet dat zijn afgestemd op degene die dat protocol beheert. Niet op mij en niet op een leverancier.

Waar ik het mee oneens ben

Sierra, dat platforms voor klantgerichte agents verkoopt, beschrijft in The Agent Development Life Cycle versiebeheerde releases en regressietests. Beide spreken me aan. Wat ik wantrouw is kennis die bevroren in een release meereist, want dan reist een vervangen protocol mee met de agent die het aanhaalt. Kennis heeft een eigen klok nodig, en elk antwoord moet vastleggen op welke versie het rustte.

Testen op zorgmedewerkers, zoals een webwinkel twee knoppen test, kan niet. Een nieuw model draait eerst naast het oude op dezelfde vragen zonder dat iemand de uitkomst ziet, en bereikt pas daarna een kleine groep.

Sporen van echte vragen horen bij de zorgdossiers. Een toetsing die vraagt dat ze de organisatie verlaten om elders te draaien, ondermijnt zichzelf. Ze draait waar de gegevens staan.

En finetunen als manier om een model passend te maken: dat bindt je aan de gewichten van één model. Wat je houdt als het model verandert, is de set vragen en de bronnen met hun eigenaren.

Wat ik niet zeg

Ik meld geen resultaten. We draaien elf weken, en wat ik hier beschrijf is hoe ik wil werken en wat er volgens mij moet staan vóór de eerste wissel. ‘Elk model’ is een belofte. De toetsset is hoe je haar nakomt.