Metlivi-blog

Moet een AI-personage-app persoonlijkheidsveranderingen aankondigen vóór een modelupdate?

Ja. Wanneer een update de gespreksstijl van een personage of de manier waarop het opgeslagen projectcontext gebruikt kan veranderen, informeer gebruikers dan voordat ze de verandering merken. Leg uit wat anders kan aanvoelen, toon een representatief voorbeeld en geef mensen duidelijke manieren om ondersteunde instellingen te bekijken of aan te passen. Wees specifiek over de beperkingen: een voorbeeld illustreert waarschijnlijk gedrag, maar kan niet beloven dat elk toekomstig antwoord hetzelfde aanvoelt.

30 september 20266 min leestijdDoor Metlivi Editorial Team
Sectie 1

Waarom een modelwijziging kan aanvoelen als een verandering van het personage

Een modelupdate kan meer veranderen dan de snelheid of kwaliteit van antwoorden. Ook de formulering, toon en gesprekspatronen die gebruikers bij een personage opmerken, kunnen veranderen. OpenAI heeft beschreven hoe het de standaardpersoonlijkheid van een model wijzigde en later een update terugdraaide nadat het gedrag te inschikkelijk was geworden. Het bedrijf merkte ook op dat persoonlijkheid van invloed is op hoe mensen het product ervaren en vertrouwen. Dat voorbeeld laat zien waarom een releasenotitie die alleen “kwaliteitsverbeteringen” vermeldt, gebruikers mogelijk niet vertelt wat ze moeten weten. OpenAI's verslag van de GPT-4o-update

In een personageproduct hebben gebruikers mogelijk ook een personagebeschrijving geschreven, stijlinstellingen gekozen of gedurende meerdere sessies aan een project gewerkt. Dat zijn afzonderlijke onderdelen van de ervaring. Een nieuw model kan veranderen hoe instructies worden opgevolgd, terwijl opgeslagen projectmateriaal beschikbaar kan blijven of anders kan worden geïnterpreteerd. Het product moet aangeven welke onderdelen veranderen, welke opgeslagen items worden beïnvloed en welke details gebruikers misschien willen controleren. Dit is een aanbeveling voor productcommunicatie, geen bewering dat elke modelupdate opgeslagen gegevens verandert.

Sectie 2

Wat moet de voorafgaande melding bevatten?

Stel de melding op rond waarneembaar gedrag in plaats van modeljargon. Vermeld indien bekend de release of uitrolperiode, geef aan wie de update ontvangt en wanneer, en beschrijf de zichtbare verschillen in gewone taal. Bijvoorbeeld: “Antwoorden kunnen beknopter zijn en het personage kan je opgeslagen projectnotities anders gebruiken.” Neem alleen uitspraken op die het productteam voor die update heeft bevestigd. Is de timing of het effect onzeker, zeg dat dan.

Onderscheid in de melding drie categorieën: de stijl van het personage, instellingen die de gebruiker beheert en het behoud van projectcontext. Leg uit of elk onderdeel naar verwachting verandert, blijft zoals ingesteld of moet worden gecontroleerd. Is het effect onbekend, benoem dat dan als onbekend in plaats van te suggereren dat alles hetzelfde blijft. Dit is belangrijk omdat producten afzonderlijke stijl- en personalisatie-instellingen kunnen aanbieden: zo beschrijven de releasenotities van ChatGPT toonkeuzes en wijzigingen die in alle chats gelden. Dat toont aan dat gebruikersinstellingen onderdeel kunnen zijn van het updateverhaal, maar bewijst niet dat een andere app dezelfde instellingen biedt. ChatGPT-releasenotities

Een nuttige melding beantwoordt vier praktische vragen: Wat zou ik kunnen merken? Wanneer zou ik dat kunnen merken? Welke instellingen of opgeslagen gegevens moet ik controleren? Waar kan ik feedback geven als het resultaat afwijkt van het voorbeeld? Vermijd algemene beloften zoals “je personage blijft hetzelfde”. Zelfs als opgeslagen tekst intact blijft, kunnen de antwoorden van het model variëren.

Sectie 3

Hoe kan een voorbeeld de verandering concreet maken?

Bied een kort voorbeeld aan met dezelfde personagebeschrijving en instellingen die een gebruiker al heeft, als het product dat betrouwbaar kan doen. Toon enkele representatieve gesprekken waarin de relevante verandering zichtbaar wordt: bijvoorbeeld een begroeting, een reactie op een projectdetail en een alledaags gesprek over plannen. Geef aan dat het voorbeelden zijn, vermeld welke nieuwe versie of update ze vertegenwoordigen en zeg dat daadwerkelijke antwoorden kunnen variëren.

Een vergelijking naast elkaar kan gebruikers helpen het huidige en voorgestelde gedrag te vergelijken, mits beide voorbeelden dezelfde prompt en context gebruiken. Houd de vergelijking gericht op aspecten die voor deze release van belang zijn, zoals zinslengte, formaliteit of het verwijzen naar een opgeslagen projectdetail door het personage. Presenteer geen selectief gekozen “voor” en “na” als bewijs dat elke interactie beter wordt.

Verander de personagebeschrijving of projectcontext niet ongemerkt in het voorbeeld. Als het voorbeeld aangepaste instellingen gebruikt, vermeld dat dan en leg uit hoe gebruikers een voorbeeld met hun eigen configuratie kunnen bekijken. De updateaankondiging van Character.AI biedt een relevant productvoorbeeld: daarin introduceerde het bedrijf selecteerbare chatstijlen en zei het uitdrukkelijk dat die stijlen konden veranderen naarmate het product verder werd ontwikkeld. Zo'n duidelijke kanttekening helpt verwachtingen te scheppen, al zouden een voorbeeld en een uitleg die specifiek op de update is toegespitst gebruikers beter helpen bij hun keuze. De community-update van Character.AI van februari 2025

Sectie 4

Welke keuzes moeten gebruikers krijgen?

Bied keuzes aan die het product daadwerkelijk ondersteunt en leg de gevolgen duidelijk uit. Afhankelijk van het product kunnen nuttige opties zijn: de opgeslagen personagebeschrijving bekijken, beschikbare stijlinstellingen aanpassen, een voorbeeldgesprek uitproberen of na de uitrol feedback geven. Als de update voor een beperkte periode kan worden uitgesteld, vermeld dan de einddatum en wat er daarna gebeurt. Wek niet de indruk dat gebruikers zich kunnen afmelden, een oude versie kunnen behouden of een eerdere gespreksstijl kunnen herstellen, tenzij die mogelijkheden echt bestaan.

Een updatemelding is nuttiger als deze de getroffen gebruiker bereikt voordat de wijziging ingaat. De richtlijnen van Microsoft voor veranderingsbeheer bevelen aan om de gevolgen voor gebruikers in kaart te brengen, grote wijzigingen vooraf aan te kondigen wanneer gebruikers actie moeten ondernemen en feedbackkanalen aan te bieden. Die richtlijnen zijn geschreven voor Microsoft 365-klanten. Toepassing op personage-apps is dus een onderbouwde afleiding voor productontwerp, geen regel voor die apps. Microsoft 365-gids voor wijzigingen

Als gebruikers geen keuze hebben over het moment van uitrollen, zeg dat dan rechtstreeks. Gebruikers hebben nog steeds baat bij een voorbeeld, een samenvatting van de update, een manier om hun eigen instellingen te bekijken en een kanaal voor feedback. De aankondiging van Gemini van Google laat zien hoe een AI-product een nieuwe personalisatie-instelling kan toelichten, samen met de instellingen om deze te beheren. De concrete instellingen verschillen per product, maar het communicatieprincipe blijft hetzelfde: vertel gebruikers wat de functie gebruikt en waar ze de relevante instelling kunnen beheren. Aankondiging van Google over Gemini-personalisatie

Sectie 5

Hoe moet het product na de release met feedback omgaan?

Houd het feedbackkanaal gekoppeld aan de update. Vraag gebruikers aan te geven wat ze hebben opgemerkt, zoals een verandering in formaliteit, een gemist projectdetail of een andere begroeting, in plaats van alleen te vragen of ze het nieuwe model prettig vinden. Als het product een feedbackformulier heeft, zorg er dan voor dat supportteams de updateversie of uitrolgroep kunnen zien, zodat ze meldingen in de juiste context kunnen plaatsen.

Beoordeel feedback samen met het voorbeeld en de productdoelen. Eén beoordeling maakt misschien niet duidelijk of een gebruiker reageert op een nieuwe stijl, een gewijzigde instelling of een probleem met het behoud van context. In het verslag over de GPT-4o-update schrijft OpenAI dat het team te zwaar leunde op feedback op korte termijn en onvoldoende rekening hield met veranderingen in interacties door de tijd heen. Het beschrijft ook hoe het team vóór de uitrol meer mogelijkheden voor directe feedback bood. Voor een personageproduct pleit dit ervoor feedback te verzamelen bij representatieve toepassingen en het feedbackkanaal vóór en na een update zichtbaar te maken. OpenAI over de GPT-4o-update en feedback

Sectie 6

Een praktische checklist voor meldingen

Stel vóór de uitrol een korte melding op die aangeeft welke ervaring wordt beïnvloed, de waarschijnlijke veranderingen in alledaagse bewoordingen uitlegt, stijl onderscheidt van het behoud van projectcontext en linkt naar een representatief voorbeeld. Vermeld wat gebruikers kunnen bekijken of aanpassen, welke keuzes niet beschikbaar zijn en waar ze een afwijking kunnen melden. Houd de uitleg na de uitrol toegankelijk en erken belangrijke veranderingen zodra die duidelijk worden.

De norm is eenvoudig: geef gebruikers genoeg informatie om te begrijpen wat kan veranderen en wat ze daaraan kunnen doen, zonder garanties te geven over de precieze persoonlijkheid van een model. Het personage kan herkenbaar blijven in de beschrijving en projectgeschiedenis, maar in de praktijk anders klinken. Eerlijke communicatie vooraf helpt gebruikers te bepalen hoe ze met die verandering omgaan.

Gerelateerde artikelen

Blijf dit onderwerp verkennen