Identifiera potentiella skador
Det första steget i en ansvarsfull generativ AI-process är att identifiera potentiella skador som kan påverka din planerade lösning. Det finns fyra steg i det här steget, som du ser här:
- Identifiera potentiella skador
- Prioritera identifierade skador
- Testa och verifiera de prioriterade skadorna
- Dokumentera och dela de verifierade skadorna
1: Identifiera potentiella skador
De potentiella skador som är relevanta för din generativa AI-lösning beror på flera faktorer, inklusive de specifika tjänster och modeller som används för att generera utdata samt eventuella finjusterings- eller jordningsdata som används för att anpassa utdata. Några vanliga typer av potentiella skador i en generativ AI-lösning är:
- Generera innehåll som är stötande, nedsättande eller diskriminerande.
- Generera innehåll som innehåller faktiska felaktigheter.
- Generera innehåll som uppmuntrar eller stöder olagligt eller oetiskt beteende eller metoder.
Om du vill förstå de kända begränsningarna och beteendet för tjänsterna och modellerna i din lösning kan du läsa den tillgängliga dokumentationen. Azure OpenAI-tjänsten innehåller till exempel en transparensanteckning som du kan använda för att förstå specifika överväganden som rör tjänsten och de modeller som den innehåller. Dessutom kan enskilda modellutvecklare tillhandahålla dokumentation, till exempel OpenAI-systemkortet för GPT-4-modellen.
Överväg att granska vägledningen i microsofts guide för utvärdering av ansvarsfull AI-påverkan och använda den associerade mallen för utvärdering av ansvarsfull AI-konsekvensanalys för att dokumentera potentiella skador.
2: Prioritera skadorna
För varje potentiell skada som du har identifierat ska du bedöma sannolikheten för dess förekomst och den resulterande effektnivån om den gör det. Använd sedan den här informationen för att prioritera skadorna med de mest sannolika och effektfulla skadorna först. Med den här prioriteringen kan du fokusera på att hitta och minimera de mest skadliga riskerna i din lösning.
Prioriteringen måste ta hänsyn till den avsedda användningen av lösningen och risken för missbruk. och kan vara subjektiv. Anta till exempel att du utvecklar en smart kökspilot som ger recepthjälp till kockar och amatörkockar. Potentiella skador kan vara:
- Lösningen ger felaktiga tillagningstider, vilket resulterar i underkokt mat som kan orsaka sjukdom.
- När du uppmanas ger lösningen ett recept på ett dödligt gift som kan tillverkas av vardagliga ingredienser.
Även om inget av dessa resultat är önskvärt, kan du besluta att lösningens potential att stödja skapandet av ett dödligt gift har högre inverkan än potentialen att skapa underkokt mat. Men med tanke på kärnanvändningsscenariot för lösningen kan du också anta att frekvensen med vilken felaktiga tillagningstider föreslås sannolikt kommer att vara mycket högre än antalet användare som uttryckligen ber om ett giftrecept. Den slutgiltiga prioriteringen är föremål för diskussion för utvecklingsteamet, som kan involvera konsultpolicy eller juridiska experter för att kunna prioritera tillräckligt.
3: Testa och kontrollera förekomsten av skador
Nu när du har en prioriterad lista kan du testa din lösning för att kontrollera att skadorna inträffar. och i så fall under vilka förhållanden. Testningen kan också visa förekomsten av tidigare oidentifierade skador som du kan lägga till i listan.
En vanlig metod för att testa potentiella skador eller sårbarheter i en programvarulösning är att använda "red team"-testning, där ett team av testare avsiktligt avsöker lösningen efter svagheter och försöker ge skadliga resultat. Exempeltester för den smarta kökslösningen som diskuterats tidigare kan vara att begära giftrecept eller snabbrecept som innehåller ingredienser som ska tillagas noggrant. Framgångarna för det röda teamet bör dokumenteras och granskas för att fastställa den realistiska sannolikheten för att skadliga utdata inträffar när lösningen används.
Kommentar
Red teaming är en strategi som ofta används för att hitta säkerhetsrisker eller andra svagheter som kan äventyra integriteten i en programvarulösning. Genom att utöka den här metoden för att hitta skadligt innehåll från generativ AI kan du implementera en ansvarsfull AI-process som bygger på och kompletterar befintliga cybersäkerhetsmetoder.
Mer information om Red Teaming för generativa AI-lösningar finns i Introduktion till red teaming large language models (LLMs) i dokumentationen för Azure OpenAI Service.
4: Dokumentera och dela information om skador
När du har samlat in bevis för att stödja förekomsten av potentiella skador i lösningen dokumenterar du informationen och delar dem med intressenter. Den prioriterade listan över skador bör sedan bibehållas och läggas till om nya skador identifieras.