Mapuj potencjalne szkody
Pierwszym etapem procesu odpowiedzialnego generowania sztucznej inteligencji jest mapowania potencjalnych szkód, które mogą mieć wpływ na planowane rozwiązanie. Na tym etapie znajdują się cztery kroki, jak pokazano poniżej:
- Identyfikowanie potencjalnych szkód
- Określanie priorytetów zidentyfikowanych szkód
- Testowanie i weryfikowanie priorytetowych szkód
- Dokumentowanie i udostępnianie zweryfikowanych szkód
1: Identyfikowanie potencjalnych szkód
Potencjalne szkody, które są istotne dla rozwiązania generatywnej sztucznej inteligencji, zależą od wielu czynników, w tym określonych usług i modeli używanych do generowania danych wyjściowych, a także wszelkiego drobnego dostrajania lub danych fundamentowych używanych do dostosowywania wyników. Niektóre typowe typy potencjalnych szkód w rozwiązaniu do generowania sztucznej inteligencji obejmują:
- Generowanie treści obraźliwych, pejoracyjnych lub dyskryminujących.
- Generowanie zawartości zawierającej faktyczne niedokładności.
- Generowanie zawartości zachęcającej lub wspierającej nielegalne lub nieetyczne zachowanie lub praktyki.
Aby w pełni zrozumieć znane ograniczenia i zachowanie usług i modeli w rozwiązaniu, zapoznaj się z dostępną dokumentacją. Na przykład usługa Azure OpenAI Service zawiera notę przezroczystości, której można użyć, aby zrozumieć konkretne zagadnienia związane z usługą i modelami, które zawiera. Ponadto indywidualni deweloperzy modeli mogą udostępniać dokumentację, taką jak karta systemu OpenAI dla modelu GPT-4.
Rozważ zapoznanie się ze wskazówkami w Przewodnik po ocenie wpływu sztucznej inteligencji firmy Microsoft i użycie skojarzonego szablonu oceny wpływu odpowiedzialnej sztucznej inteligencji w celu udokumentowania potencjalnych szkód.
Zapoznaj się z informacjami i wytycznymi dotyczącymi zasobów używanych do identyfikowania potencjalnych szkód.
2: Ustalanie priorytetów szkód
W przypadku każdej zidentyfikowanej potencjalnej szkody należy ocenić prawdopodobieństwo wystąpienia i wynikowy poziom wpływu, jeśli tak. Następnie użyj tych informacji, aby w pierwszej kolejności nadać priorytet szkodom, które są najbardziej prawdopodobne i mają największy wpływ. Ta priorytetyzacja umożliwi skoncentrowanie się na znajdowaniu i zmniejszaniu najbardziej szkodliwych zagrożeń w rozwiązaniu.
Priorytetyzacja musi uwzględniać zamierzone użycie rozwiązania, a także możliwość nieprawidłowego użycia; i może być subiektywne. Załóżmy na przykład, że opracowujesz inteligentnego asystenta kuchni, który zapewnia pomoc w przygotowywaniu przepisów dla szefów kuchni i amatorów gotowania. Potencjalne szkody mogą obejmować:
- Rozwiązanie zapewnia niedokładne czasy gotowania, co powoduje niedogotowane jedzenie, które może powodować choroby.
- Po wyświetleniu monitu rozwiązanie dostarcza przepis na śmiertelną truciznę, którą można wyprodukować z codziennych składników.
Chociaż żaden z tych wyników nie jest pożądany, możesz zdecydować, że potencjał rozwiązania do wspierania tworzenia śmiertelnej trucizny ma większe znaczenie niż potencjał tworzenia niedogotowanego jedzenia. Jednak biorąc pod uwagę podstawowy scenariusz użycia rozwiązania, można również przypuszczać, że częstotliwość, z jaką sugerowane są niedokładne czasy gotowania, może być znacznie wyższa niż liczba użytkowników wyraźnie proszących o przepis trucizny. Ostateczne ustalenie priorytetów jest przedmiotem dyskusji dla zespołu rozwojowego, co może obejmować konsultacje z ekspertami ds. polityki lub prawa w celu odpowiedniego określenia priorytetów.
3: Przetestuj i sprawdź obecność szkód
Teraz, gdy masz listę priorytetową, możesz przetestować rozwiązanie, aby sprawdzić, czy występują szkody; a jeśli tak, w jakich warunkach. Testowanie może również ujawnić obecność wcześniej niezidentyfikowanych szkód, które można dodać do listy.
Typowym podejściem do testowania potencjalnych szkód lub luk w zabezpieczeniach w rozwiązaniu oprogramowania jest użycie testowania "czerwonego zespołu", w którym zespół testerów celowo sonduje rozwiązanie pod kątem słabych stron i próbuje uzyskać szkodliwe wyniki. Przykładowe testy inteligentnego rozwiązania copilot kuchni omówione wcześniej mogą obejmować żądanie przepisów zawierających szkodliwe składniki lub szybkich przepisów, zawierających składniki wymagające dokładnego gotowania. Sukcesy czerwonego zespołu powinny być udokumentowane i przeanalizowane, aby ułatwić określenie realistycznego prawdopodobieństwa wystąpienia szkodliwych efektów w wyniku użycia rozwiązania.
Uwaga
Red teaming to strategia, która jest często używana do znajdowania luk w zabezpieczeniach lub innych słabości, które mogą naruszyć integralność rozwiązania programowego. Rozszerzając to podejście w celu znalezienia szkodliwej zawartości z generowania sztucznej inteligencji, można zaimplementować proces odpowiedzialnej sztucznej inteligencji, który opiera się na istniejących praktykach cyberbezpieczeństwa i uzupełnia je.
Aby dowiedzieć się więcej na temat testów Red Teaming dla generatywnych rozwiązań AI, zobacz Wprowadzenie do testów Red Teaming dużych modeli językowych (LLM) w dokumentacji usługi Azure OpenAI Service.
4: Dokumentowanie i udostępnianie szczegółów szkód
Po zebraniu dowodów na poparcie obecności potencjalnych szkód w rozwiązaniu należy udokumentować szczegóły i udostępnić je uczestnikom projektu. Priorytetowa lista szkód powinna być następnie utrzymywana i dodawana do listy, jeśli zostaną zidentyfikowane nowe szkody.