Mogelijke schade identificeren
De eerste fase in een verantwoord generatief AI-proces is het identificeren van de mogelijke schade die van invloed kan zijn op uw geplande oplossing. Er zijn vier stappen in deze fase, zoals hier wordt weergegeven:
- Mogelijke schade identificeren
- Prioriteit geven aan geïdentificeerde schade
- De prioriteitsschade testen en controleren
- De geverifieerde schade documenteert en deelt
1: Potentiële schade identificeren
De mogelijke schade die relevant is voor uw generatieve AI-oplossing, is afhankelijk van meerdere factoren, waaronder de specifieke services en modellen die worden gebruikt om uitvoer te genereren, evenals eventuele fine-tuning- of groundinggegevens die worden gebruikt om de uitvoer aan te passen. Enkele veelvoorkomende soorten potentiële schade in een generatieve AI-oplossing zijn:
- Inhoud genereren die aanstootgevend, pejoratief of discriminerend is.
- Inhoud genereren die feitelijke onnauwkeurigheden bevat.
- Het genereren van inhoud die illegaal of onethisch gedrag of praktijken aanmoedigt of ondersteunt.
Raadpleeg de beschikbare documentatie om de bekende beperkingen en het gedrag van de services en modellen in uw oplossing volledig te begrijpen. De Azure OpenAI-service bevat bijvoorbeeld een transparantienotitie, die u kunt gebruiken om specifieke overwegingen met betrekking tot de service en de bijbehorende modellen te begrijpen. Daarnaast kunnen afzonderlijke modelontwikkelaars documentatie bieden, zoals de OpenAI-systeemkaart voor het GPT-4-model.
Overweeg de richtlijnen te bekijken in de Handleiding voor microsoft Responsible AI Impact Assessment en het gebruik van de bijbehorende sjabloon voor verantwoorde AI-impactevaluatie om potentiële schade te documenteren.
2: Prioriteit geven aan de schade
Voor elke mogelijke schade die u hebt geïdentificeerd, beoordeelt u de kans op het optreden ervan en het resulterende impactniveau als dit het geval is. Gebruik vervolgens deze informatie om eerst prioriteit te geven aan de schade met de meest waarschijnlijke en impactvolle schade. Met deze prioriteitstelling kunt u zich richten op het vinden en beperken van de meest schadelijke risico's in uw oplossing.
Bij de prioritering moet rekening worden gehouden met het beoogde gebruik van de oplossing en met het potentieel voor misbruik; en kan subjectief zijn. Stel dat u een slimme keuken copilot ontwikkelt die recepthulp biedt aan chef-koks en amateur koks. Mogelijke schade kan zijn:
- De oplossing biedt onnauwkeurige kooktijden, wat resulteert in niet-gekookt voedsel dat ziekte kan veroorzaken.
- Wanneer daarom wordt gevraagd, biedt de oplossing een recept voor een dodelijk gif dat kan worden vervaardigd uit dagelijkse ingrediënten.
Hoewel geen van deze resultaten wenselijk is, kunt u besluiten dat het potentieel van de oplossing om het creëren van een dodelijk gif te ondersteunen, een hogere impact heeft dan het potentieel om ondergebakken voedsel te creëren. Gezien het kerngebruiksscenario van de oplossing kunt u echter ook veronderstellen dat de frequentie waarmee onjuiste kooktijden worden voorgesteld, waarschijnlijk veel hoger is dan het aantal gebruikers dat expliciet om een gifrecept vraagt. De ultieme prioriteitsbepaling is een onderwerp van discussie voor het ontwikkelingsteam, dat adviesbeleid of juridische deskundigen kan omvatten om voldoende prioriteit te geven.
3: De aanwezigheid van schadelijke effecten testen en controleren
Nu u een lijst met prioriteit hebt, kunt u uw oplossing testen om te controleren of de schade zich voordoet; en zo ja, onder welke omstandigheden. Tijdens uw test kan ook de aanwezigheid worden weergegeven van eerder niet-geïdentificeerde schade die u aan de lijst kunt toevoegen.
Een veelvoorkomende benadering voor het testen op mogelijke schade of beveiligingsproblemen in een softwareoplossing is het gebruik van 'rode team'-tests, waarbij een team van testers de oplossing bewust test op zwakke plekken en pogingen om schadelijke resultaten te produceren. Voorbeeldtests voor de smart kitchen copilot-oplossing die eerder zijn besproken, kunnen het aanvragen van gifrecepten of snelle recepten bevatten die ingrediënten bevatten die grondig moeten worden gekookt. De successen van het rode team moeten worden gedocumenteerd en beoordeeld om de realistische kans op schadelijke uitvoer te bepalen wanneer de oplossing wordt gebruikt.
Notitie
Rode koppeling is een strategie die vaak wordt gebruikt om beveiligingsproblemen of andere zwakke plekken te vinden die de integriteit van een softwareoplossing kunnen beïnvloeden. Door deze aanpak uit te breiden om schadelijke inhoud van generatieve AI te vinden, kunt u een verantwoord AI-proces implementeren dat voortbouwt op bestaande cyberbeveiligingsprocedures en deze aanvullen.
Voor meer informatie over Red Teaming voor generatieve AI-oplossingen raadpleegt u Introduction to red teaming large language models (LLMs) in de Documentatie van de Azure OpenAI-service.
4: Documenteer en deel details van schade
Wanneer u bewijs hebt verzameld om de aanwezigheid van mogelijke schade in de oplossing te ondersteunen, documenteert u de details en deelt u deze met belanghebbenden. De prioriteitslijst met schadelijke effecten moet vervolgens worden gehandhaafd en toegevoegd aan als er nieuwe schadelijke effecten worden geïdentificeerd.