Identyfikowanie potencjalnych szkód
Pierwszym etapem procesu odpowiedzialnego generowania sztucznej inteligencji jest zidentyfikowanie 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 generowania rozwiązania 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 wszelkich drobnych dostrajania lub uziemienia danych używanych do dostosowywania danych wyjściowych. 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 notatkę o przejrzystości, której można użyć do zrozumienia konkretnych zagadnień związanych 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 zawartymi w przewodniku po ocenie wpływu odpowiedzialnej sztucznej inteligencji firmy Microsoft i użycie skojarzonego szablonu odpowiedzialnej oceny wpływu sztucznej inteligencji w celu udokumentowania potencjalnych szkód.
Zapoznaj się z informacjami i wytycznymi dotyczącymi zasobów, których używasz, aby pomóc zidentyfikować potencjalne szkody.
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 najpierw określić priorytety szkód z najbardziej prawdopodobnymi i wpływającymi szkodami. 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 inteligentny copilot kuchni, który zapewnia pomoc w przepisie dla kucharzy i kucharzy amatorskich. 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ększy wpływ niż potencjał tworzenia nieużywanej żywności. 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. Ostatecznym priorytetem jest dyskusja dla zespołu deweloperów, który może obejmować politykę konsultingową lub ekspertów prawnych w celu wystarczającego 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 trucizny lub szybkich przepisów, które zawierają składniki, które powinny być dokładnie gotowane. Sukcesy czerwonego zespołu powinny być udokumentowane i przejrzane, aby ułatwić określenie realistycznego prawdopodobieństwa wystąpienia szkodliwych danych wyjściowych w przypadku 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 red teaming for generative AI solutions ( Wprowadzenie do red teaming dużych modeli językowych ) 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.