Planowanie czerwonego tworzenia zespołu dla dużych modeli językowych (LLMs) i ich aplikacji

Ten przewodnik oferuje potencjalne strategie planowania, jak skonfigurować i zarządzać zespołem ds. przeciwdziałania ryzykom związanym z odpowiedzialnym użyciem sztucznej inteligencji (RAI) w całym cyklu życia produktu związanego z dużymi modelami językowymi (LLM).

Co to jest red teaming?

Termin red teaming historycznie opisuje systematyczne ataki ze strony przeciwnika na potrzeby testowania luk w zabezpieczeniach. Wraz z rozwojem LLM-ów termin rozszerzył się poza tradycyjne cyberbezpieczeństwo i ewoluował w wspólne użycie, aby opisać wiele rodzajów sondowania, testowania i atakowania systemów sztucznej inteligencji. Dzięki LLMs zarówno łagodne, jak i niepożądane użycie może produkować potencjalnie szkodliwe dane wyjściowe, które mogą przyjmować wiele form, w tym szkodliwe treści, takie jak mowa nienawiści, podżeganie lub gloryfikacja przemocy lub treści seksualnych.

Dlaczego praktyka red teamingu RAI jest ważna?

Red teaming to najlepsza praktyka w zakresie odpowiedzialnego opracowywania systemów i funkcji przy użyciu LLMs. Chociaż to nie zastępuje systematycznego pomiaru i pracy nad ograniczaniem ryzyka, zespoły red team pomagają odkrywać i identyfikować szkody, co z kolei umożliwia stworzenie strategii pomiaru w celu zweryfikowania skuteczności działań łagodzących.

Podczas gdy firma Microsoft przeprowadziła ćwiczenia typu red teaming i zaimplementowała systemy bezpieczeństwa (w tym filtry zawartości i inne strategie ograniczania ryzyka) dla usługi Azure OpenAI w modelach usługi Azure AI Foundry (zobacz ten przegląd praktyk dotyczących odpowiedzialnego używania sztucznej inteligencji), kontekst każdej aplikacji LLM będzie unikalny, dlatego należy również przeprowadzić red teaming:

• Przetestuj model podstawowy LLM i ustal, czy istnieją luki w istniejących systemach bezpieczeństwa, biorąc pod uwagę kontekst aplikacji.

• Identyfikowanie i eliminowanie niedociągnięć istniejących domyślnych filtrów lub strategii ograniczania ryzyka.

• Prześlij opinię na temat niepowodzeń, aby wprowadzić ulepszenia.

• Należy pamiętać, że red teaming nie zastępuje systematycznego pomiaru. Najlepszym rozwiązaniem jest ukończenie początkowej rundy ręcznego czerwonego tworzenia zespołu przed przeprowadzeniem systematycznych pomiarów i wdrożeniem środków zaradczych. Jak wskazano powyżej, celem zespołu RAI jest zidentyfikowanie szkód, zrozumienie powierzchni ryzyka i opracowanie listy szkód, które mogą informować o tym, co należy zmierzyć i ograniczyć.

Oto jak rozpocząć i zaplanować proces red teaming LLMs. Planowanie z wyprzedzeniem ma kluczowe znaczenie dla efektywnego ćwiczenia zespołu czerwonego.

Przed rozpoczęciem testowania

Plan: Kto wykona testy

Zmontuj zróżnicowaną grupę osób z czerwonego zespołu

Określ idealną kompozycję zespołów czerwonych pod względem doświadczenia członków, różnorodności demograficznej i wiedzy w różnych dyscyplinach (na przykład ekspertów w dziedzinie sztucznej inteligencji, nauk społecznych, zabezpieczeń) w obszarze twojego produktu. Jeśli na przykład projektujesz czatbota, aby pomóc dostawcom opieki zdrowotnej, eksperci medyczni mogą pomóc zidentyfikować zagrożenia w tej domenie.

Rekrutuj członków czerwonych zespołów z zarówno pokojowym, jak i przeciwnym nastawieniem

Posiadanie red teamerów o antagonisticznym nastawieniu i doświadczeniu w testowaniu bezpieczeństwa jest niezbędne do zrozumienia zagrożeń bezpieczeństwa, ale red teamerzy, którzy są zwykłymi użytkownikami twojego systemu aplikacyjnego i nie byli zaangażowani w jego rozwój, mogą dostarczyć cennych perspektyw na szkody, jakie mogą spotkać regularnych użytkowników.

Przypisywanie czerwonych zespołów do szkód i/lub funkcji produktu

• Przypisz red teamerów RAI o określonej wiedzy do badania konkretnych rodzajów szkód (na przykład eksperci ds. bezpieczeństwa mogą badać jailbreaki, wyodrębnianie meta-poleceń oraz zawartość związaną z cyberatakami).

• W przypadku wielu rund testowania zdecyduj, czy zmieniać przypisania członków czerwonego zespołu w każdej rundzie, aby uzyskać zróżnicowane perspektywy na wszystkie szkody i podtrzymać kreatywność. W przypadku zmiany zadań, pozwól na czas, aby członkowie zespołu czerwonego mogli zapoznać się z instrukcjami dotyczącymi ich nowo przypisanych zadań.

• W późniejszych etapach, kiedy aplikacja i jej interfejs użytkownika są opracowywane, możesz przydzielić specjalistów ds. bezpieczeństwa do określonych części aplikacji (tj. funkcji), aby zapewnić objęcie całej aplikacji.

• Zastanów się, ile czasu i nakładu pracy powinien przeznaczyć każdy tester (na przykład testy dla scenariuszy łagodnych mogą potrzebować mniej czasu niż scenariusze wrogie).

Przydatne może być zapewnienie czerwonym zespołom:

• Klarowne instrukcje, które mogą obejmować:
  • Wprowadzenie opisujące cel i zamierzenie danej rundy czerwonej drużyny; produkt i funkcje, które zostaną przetestowane, oraz jak uzyskać do nich dostęp; jakie rodzaje problemów należy przetestować; obszary zainteresowania czerwonej drużyny, jeśli testowanie jest bardziej ukierunkowane; ile czasu i wysiłku każdy członek czerwonej drużyny powinien poświęcić na testowanie; jak rejestrować wyniki; oraz z kim się skontaktować w razie pytań.
• Plik lub lokalizacja do rejestrowania ich przykładów i wyników, w tym informacje, takie jak:
  • Data wystąpienia przykładu; unikatowy identyfikator pary wejściowej/wyjściowej, jeśli jest dostępny, do celów odtwarzania; monit wejściowy; opis lub zrzut ekranu przedstawiający dane wyjściowe.

Plan: Co należy przetestować

Ponieważ aplikacja jest opracowywana przy użyciu modelu podstawowego, może być konieczne przetestowanie w kilku różnych warstwach:

• Podstawowy model LLM, który posiada system bezpieczeństwa do identyfikowania wszelkich luk, które wymagają rozwiązania w kontekście systemu aplikacji. (Testowanie odbywa się zwykle za pośrednictwem punktu końcowego interfejsu API).

• Twoja aplikacja. (Testowanie najlepiej wykonać za pośrednictwem interfejsu użytkownika).

• Zarówno podstawowy model LLM, jak i aplikacja, są oceniane przed oraz po zastosowaniu środków zaradczych.

Poniższe zalecenia pomagają wybrać, co należy przetestować na różnych etapach podczas ćwiczeń red team.

• Możesz rozpocząć od przetestowania modelu podstawowego, aby zrozumieć powierzchnię ryzyka, zidentyfikować szkody i poprowadzić rozwój środków zaradczych RAI dla produktu.

• Przeprowadzaj testy wersji produktu w sposób iteracyjny, z wdrożeniem środków zaradczych RAI i bez nich, aby ocenić ich skuteczność. (Należy pamiętać, że ręczna ocena w ramach red teamingu może nie być wystarczająca — należy również stosować systematyczne pomiary, ale tylko po zakończeniu początkowej ręcznej oceny).

• Przeprowadź testowanie aplikacji w interfejsie użytkownika produkcyjnego tak bardzo, jak to możliwe, ponieważ jest to najbardziej podobne do rzeczywistego użycia.

Podczas raportowania wyników upewnij się, które punkty końcowe zostały użyte do testowania. Po zakończeniu testowania w punkcie końcowym innym niż produkt rozważ ponowne przetestowanie w produkcyjnym punkcie końcowym lub interfejsie użytkownika w przyszłych rundach.

Plan: Jak przetestować

Przeprowadź otwarte testy, aby odkryć szeroką gamę szkód.

Zaletą eksploracji i dokumentowania wszelkich problematycznych treści przez red teamów RAI (zamiast proszenia ich o znalezienie przykładów konkretnych szkód) jest to, że pozwala im twórczo badać szeroką gamę problemów, odkrywając niewidoczne obszary w zrozumieniu powierzchni ryzyka.

Utwórz listę szkód wynikających z testów o otwartym charakterze.

• Rozważ utworzenie listy szkód z definicjami i przykładami szkód.
• Podaj tę listę jako wytyczne dla czerwonych zespołów w kolejnych rundach testowania.

Przeprowadź etapowe i kierowane działania typu "red teaming": Kontynuuj badanie pod kątem szkód na liście; zidentyfikuj nowe szkody, które się pojawiają.

Użyj listy szkód, jeśli są dostępne i kontynuuj testowanie pod kątem znanych szkód i skuteczności ich środków zaradczych. W tym procesie prawdopodobnie zidentyfikujesz nowe szkody. Zintegruj je z listą i bądź otwarty na zmianę priorytetów pomiaru i środków zaradczych, aby rozwiązać nowo zidentyfikowane szkody.

Zaplanuj, które szkody należy priorytetowo testować w sposób iteracyjny. Kilka czynników może przyczynić się do ustalenia priorytetów, w tym, ale nie tylko, poważność szkód oraz kontekst, w jakim mogą się ujawniać.

Plan: Jak rejestrować dane

Zdecyduj, jakie dane chcesz zebrać i jakie dane są opcjonalne.

• Zdecyduj, jakie dane będą musieli rejestrować członkowie zespołu "red team" (na przykład użyte dane wejściowe, dane wyjściowe systemu, unikatowy identyfikator – jeśli jest dostępny – aby odtworzyć przykład w przyszłości, oraz inne notatki).

• Bądź strategiczny z tymi danymi, które zbierasz, aby uniknąć przytłaczania zespołów czerwonych, a jednocześnie nie przegap istotnych informacji.

Tworzenie struktury zbierania danych

Udostępniony arkusz Excel jest często najprostszą metodą zbierania danych z analiz red teamingowych. Zaletą tego udostępnionego pliku jest to, że członkowie zespołu odpowiedzialnego za testy mogą przeglądać przykłady innych, aby zdobyć twórcze pomysły na własne testowanie i uniknąć duplikowania danych.

Podczas testowania

Przygotowanie do pozostawania w gotowości podczas trwania red teaming

• Przygotuj się do pomocy członkom czerwonego zespołu, udzielając instrukcji i rozwiązując problemy z dostępem.
• Monitoruj postęp na arkuszu kalkulacyjnym i wysyłaj przypomnienia na czas do członków czerwonego zespołu.

Po każdej rundzie testowania

Dane raportu

Udostępnij krótki raport w regularnych odstępach czasu kluczowym uczestnikom projektu, który:

1. Wyświetla listę najważniejszych zidentyfikowanych problemów.

2. Udostępnia link do danych pierwotnych.

3. Wyświetla podgląd planu testowania dla nadchodzących rund.

4. Uznaje członków czerwonych zespołów.

5. Zawiera wszelkie inne istotne informacje.

Rozróżnianie identyfikacji i pomiaru

W sprawozdaniu należy wyjaśnić, że rola działań red team RAI polega na uwidacznieniu i zwiększeniu zrozumienia ryzyka i nie jest zamiennikiem systematycznego pomiaru i rygorystycznych działań łagodzących. Ważne jest, aby ludzie nie interpretowali konkretnych przykładów jako metryki dla wszechobecności tej szkody.

Ponadto jeśli raport zawiera problematyczną zawartość i przykłady, rozważ uwzględnienie ostrzeżenia dotyczącego zawartości.

Wytyczne zawarte w tym dokumencie nie mają być przeznaczone i nie powinny być interpretowane jako dostarczanie, porady prawne. Jurysdykcja, w której działasz, może mieć różne wymagania regulacyjne lub prawne, które mają zastosowanie do twojego systemu sztucznej inteligencji. Należy pamiętać, że nie wszystkie te zalecenia są odpowiednie dla każdego scenariusza i z drugiej strony te zalecenia mogą być niewystarczające w przypadku niektórych scenariuszy.