Identifikace potenciálních škod
První fází zodpovědného procesu generování AI je identifikace potenciálních škod, které by mohly ovlivnit vaše plánované řešení. V této fázi jsou čtyři kroky, jak je znázorněno tady:
- Identifikace potenciálních škod
- Stanovení priorit zjištěných škod
- Testování a ověření prioritizovaných škod
- Zdokumentujte a sdílejte ověřené škody
1: Identifikace potenciálních škod
Potenciální škody, které jsou relevantní pro vaše řešení generující umělé inteligence, závisí na několika faktorech, včetně konkrétních služeb a modelů používaných k vygenerování výstupu a také všech jemně vyladěných nebo uzemněných dat používaných k přizpůsobení výstupů. Mezi běžné typy potenciálních škod v řešení generující umělé inteligence patří:
- Generování obsahu, který je urážlivý, pejorativní nebo nediskriminační.
- Generování obsahu, který obsahuje faktické nepřesnosti.
- Generování obsahu, který podporuje nezákonné nebo neetické chování nebo postupy.
Pokud chcete plně porozumět známým omezením a chování služeb a modelů ve vašem řešení, projděte si dostupnou dokumentaci. Služba Azure OpenAI například obsahuje poznámku k transparentnosti, kterou můžete použít k pochopení konkrétních aspektů souvisejících se službou a modelů, které zahrnuje. Vývojáři jednotlivých modelů mohou navíc poskytnout dokumentaci, jako je systémová karta OpenAI pro model GPT-4.
Zvažte kontrolu pokynů v průvodci posouzením dopadu umělé inteligence Microsoftu a použitím přidružené šablony zodpovědného posouzení dopadu AI k dokumentaci potenciálních škod.
2: Stanovení priority škod
Pro každou potenciální škodu, kterou jste identifikovali, vyhodnoťte pravděpodobnost výskytu a výslednou úroveň dopadu, pokud ano. Tyto informace pak použijte k určení priority škod s nejpravděpodobnějším a ovlivněným poškozením. Toto stanovení priority vám umožní zaměřit se na hledání a zmírnění nejvíce škodlivých rizik ve vašem řešení.
Stanovení priorit musí zohlednit zamýšlené použití řešení a také potenciál zneužití; a může být subjektivní. Předpokládejme například, že vyvíjíte inteligentní kopírovací graf kuchyně, který poskytuje pomoc s receptem kuchařům a amatérským kuchařům. Mezi potenciální škody může patřit:
- Řešení poskytuje nepřesné doby vaření, což vede k nevyužitým potravinám, které mohou způsobit nemoc.
- Po zobrazení výzvy poskytuje řešení recept na smrtelný jed, který lze vyrobit z každodenních ingrediencí.
I když ani jeden z těchto výsledků není žádoucí, můžete se rozhodnout, že potenciál řešení podporovat vytváření smrtelného jedu má vyšší dopad než potenciál vytvářet nedostatečně zakódované potraviny. Vzhledem k základnímu scénáři použití řešení však můžete předpokládat, že frekvence, s jakou jsou navrhované nepřesné doby vaření, bude pravděpodobně mnohem vyšší než počet uživatelů, kteří explicitně požadují o jed recept. Konečné stanovení priority je předmětem diskuse pro vývojový tým, který může zahrnovat konzultační zásady nebo právní odborníky, aby bylo možné dostatečně určit prioritu.
3: Testování a ověření přítomnosti škod
Teď, když máte seznam s prioritami, můžete otestovat své řešení a ověřit, že dojde k škodám; a pokud ano, za jakých podmínek. Testování může také odhalit přítomnost dříve neidentifikovaných škod, které můžete přidat do seznamu.
Běžným přístupem k testování potenciálních škod nebo ohrožení zabezpečení v softwarovém řešení je použití "červeného týmu" testování, ve kterém tým testerů záměrně tester testuje řešení slabých stránek a snaží se vyvolat škodlivé výsledky. Ukázkové testy pro řešení smart kitchen copilot probírané dříve můžou zahrnovat žádosti o jedovaté recepty nebo rychlé recepty, které obsahují přísady, které by měly být důkladně uvařené. Úspěch červeného týmu by měl být zdokumentován a zkontrolován, aby pomohl určit realistickou pravděpodobnost škodlivého výstupu, ke kterému dochází při použití řešení.
Poznámka:
Red teaming je strategie, která se často používá k nalezení ohrožení zabezpečení nebo jiných slabých stránek, které můžou ohrozit integritu softwarového řešení. Rozšířením tohoto přístupu najděte škodlivý obsah z generující umělé inteligence, můžete implementovat zodpovědný proces AI, který vychází ze stávajících postupů kybernetické bezpečnosti a doplňuje ho.
Další informace o red Teaming for generative AI solutions, see Introduction to red teaming large language models (LLMs) in the Azure OpenAI Service documentation.
4: Dokumentovat a sdílet podrobnosti o škodách
Když jste shromáždili důkazy pro podporu přítomnosti potenciálních škod v řešení, zdokumentujte podrobnosti a sdílejte je se zúčastněnými stranami. V případě zjištění nových škod by se měl zachovat a přidat seznam prioritních škod.