Wie beslist wanneer het model achter uw agent verandert?

Uw agent beantwoordt al maanden vragen van klanten. Niemand heeft aan de instructies, de tools of de stappen gezeten. Op dinsdag blijven de antwoorden ineens leeg. Op woensdag zoekt uw team nog steeds naar de wijziging die het zelf heeft gemaakt, en er is er geen te vinden.

De wijziging was echt. Alleen was het niet aan u om haar te maken, en niemand vertelde u dat ze eraan kwam.

Een agent is een model, instructies, tools en stappen (zie wat een AI-agent is). Drie daarvan zijn van u. Het vierde is meestal van iemand anders, en het kan bewegen terwijl de rest stilstaat. Dit artikel gaat over dat vierde deel: wie beslist wanneer het verandert, en wat u kunt doen zodat die beslissing weer bij u komt te liggen.

Eén team meldde een standaardagent op een gehost platform voor het bouwen van agents. De agent had vele maanden goed gewerkt. Daarna gaf hij meestal helemaal geen antwoord meer, alleen een leeg veld. Aan de agent was niets veranderd. Twee ervaren helpers uit de community zeiden dat de oorzaak hoogstwaarschijnlijk aan de kant van het model of de runtime lag, niet in de agent. Het team kwam tot dezelfde conclusie en zei wat het meest stak: de update kwam zonder enige melding, dus moesten ze zoeken naar een probleem dat ze niet konden benoemen. Ze kregen de agent weer aan het werk door over te stappen op een ander model en één tool en een instelling voor diepere redenering uit te zetten. Niemand van de leverancier bevestigde dat een modelupdate de oorzaak was.

Een tweede team meldde een eenvoudige chatbot die antwoordde op basis van de eigen documenten van het team, zonder tools. In het testvenster van de bouwomgeving werkte hij met een nieuwer model. Gepubliceerd in het live chatkanaal gaf dezelfde agent met hetzelfde model elke keer een bericht dat hij geen antwoord kon geven. Met het oudere model gedroeg hij zich op beide plekken hetzelfde. Helpers uit de community dachten aan andere rechten in het live kanaal; de melder zei dat dat niet bij de eigen opzet paste. Maanden later meldde een andere gebruiker vrijwel hetzelfde gedrag met hetzelfde model: het werkte in de testmodus en gaf een foutmelding na publicatie. De uitweg van het tweede team was dezelfde als die van het eerste: terug naar een model dat werkte.

Twee meldingen zijn geen onderzoek. Maar ze hebben een vorm gemeen die de moeite waard is. In beide gevallen veranderde het team niets. In beide gevallen was de uitweg dat het team zelf het model koos.

Wanneer u een agent instelt, typt of kiest u een modelnaam. Die ziet eruit als iets vasts. Vaak is hij dat niet.

Veel namen zijn aliassen: een familienaam die de aanbieder laat wijzen naar de versie die hij vandaag levert. Verplaatst de aanbieder die verwijzing, dan gaat elke agent die de naam gebruikt mee, op de datum van de aanbieder. De instellingen van uw agent tonen nog steeds dezelfde naam. Ze vertellen u niets over de wijziging.

Andere namen bevatten een datum of een versienummer. Die wijzen naar één momentopname. Dat is beter, maar het blijft een belofte, en de aanbieder komt die na, niet u. Een aanbieder kan een oude versie ook uit de roulatie nemen. En een gehost platform kan de laag rond het model veranderen: de runtime die het model uw instructies en tools aanreikt en bepaalt hoe tools worden aangeroepen. De tweede melding laat zien dat één modelnaam zich op twee paden van hetzelfde product verschillend kan gedragen.

De vraag "welk model gebruikt mijn agent?" heeft dus drie eerlijke delen: de naam die u schreef, waar die naam vandaag naar wijst, en wie het een of het ander kan veranderen.

Het model vastzetten is één deel van weten wat er live draait. De rest leest u in Wat live draait, is niet wat u hebt getest.

De aanbieder beslist. U gebruikt een alias. Verbeteringen krijgt u zonder een vinger uit te steken, en wijzigingen krijgt u op dezelfde manier. Voor werk waar weinig van afhangt, is dat een redelijke keuze, zolang u er bewust voor kiest.

U beslist, binnen de belofte van de aanbieder. U noemt een exacte versie met datum. Een wijziging bereikt uw agent pas als u de naam verandert. De aanbieder bepaalt nog steeds hoe lang die versie blijft bestaan, dus u hebt ook een datum in de agenda nodig om de keuze opnieuw te bekijken.

U beslist, en u draagt het gewicht. U draait het model op een server die u zelf beheert. Dan verandert het model wanneer uw team het bijwerkt. In ruil daarvoor beheert u de hardware, de updates en de capaciteit, en het model dat u zelf kunt draaien, is misschien niet het model dat u uit een gehoste lijst zou kiezen. Wat het betekent om meer van uw stack zelf in handen te hebben, leest u in Zelfgehoste AI: zo houdt u uw AI-stack zelf in handen.

De meeste organisaties gebruiken meer dan één antwoord: een alias voor een interne hulp bij het schrijven van concepten, een vaste versie voor de agent die met klanten praat, en een zelfgehost model waar de gegevens of het contract daarom vragen.

U kunt een aanbieder niet tegenhouden als die een model verandert. U kunt er wel voor zorgen dat een wijziging u voorbereid aantreft.

1. Zet de namen op een rij. Schrijf voor elke agent op welke modelnaam hij gebruikt, en of dat een alias is of een versie met datum. Misschien vindt u aliassen waar u dacht dat de versie vaststond.
2. Houd een vaste vragenset bij. Kies een kleine set echte vragen, met antwoorden die uw team goed vond. Leg ze volgens een schema en na elke wijziging aan de live agent voor, en vergelijk. Een verschuiving die u op dinsdagochtend opmerkt, kost minder dan een die een klant vindt.
3. Test een weg terug. Kies een tweede model en test de agent erop voordat u het nodig hebt. Beide teams hierboven herstelden door van model te wisselen. Zij moesten die uitweg onder druk vinden. U kunt hem vinden op een rustige dag.
4. Behandel een modelwissel als een release. Overstappen op een nieuwe versie is een besluit. Een persoon met een naam neemt het, op een datum, nadat de vragenset is geslaagd. Hetzelfde geldt voor de datum waarop u een vaste versie opnieuw bekijkt.

Stel deze vragen over de versie die u zou installeren, en vraag om het antwoord te zien op een echte agent. Ons eigen antwoord staat bij elke vraag.

• Kan ik een exacte modelversie met datum noemen, niet alleen een familie-alias? EpicStaff: ja. Een model is een naam in vrije tekst, en de ingebouwde lijst bevat al versies met datum, bijvoorbeeld "gpt-4o-2024-08-06". EpicStaff stuurt de naam precies zoals u die schreef naar de aanbieder. Of een naam met datum vast blijft, is de belofte van de aanbieder, niet de onze.
• Kan ik het model van de agents draaien op een server die ik zelf beheer? EpicStaff: ja, voor de LLM-stappen van agents. Ollama en vLLM staan in de lijst met aanbieders, en elk model krijgt een eigen basis-URL, dus een OpenAI-compatibel endpoint werkt. Dit geldt alleen voor de LLM-aanroepen van agents; sommige paden voor embeddings, OCR en spraak roepen nog steeds clouddiensten aan.
• Zegt het runverslag welk model elke stap beantwoordde, of alleen welk model was ingesteld? EpicStaff: niet per stap.
• Wie waarschuwt mij voordat de naam die ik gebruik anders gaat antwoorden? Deze vraag is voor uw modelaanbieder, welk platform u ook gebruikt. Vraag of een versie met datum vast is, hoe lang die blijft bestaan en hoe een wijziging wordt aangekondigd.

Het model onder uw agent gaat veranderen. De enige vraag is of dat gebeurt volgens uw agenda of volgens die van een ander.