Planowanie czerwonego tworzenia zespołu dla dużych modeli językowych (LLMs) i ich aplikacji
Ten przewodnik zawiera pewne potencjalne strategie planowania sposobu konfigurowania czerwonego zespołu dla ryzyka odpowiedzialnego używania sztucznej inteligencji (RAI) i zarządzania nimi w całym cyklu życia produktu w dużym modelu językowym (LLM).
Co to jest red teaming?
Termin red teaming historycznie opisał systematyczne ataki niepożądane na potrzeby testowania luk w zabezpieczeniach. Wraz z rozwojem llMs termin rozszerzył się poza tradycyjne cyberbezpieczeństwo i ewoluował we wspólnym użyciu, aby opisać wiele rodzajów sondowania, testowania i ataków 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 RAI red teaming jest ważną praktyką?
Red teaming to najlepsze rozwiązanie w zakresie odpowiedzialnego opracowywania systemów i funkcji przy użyciu llMs. Chociaż nie zastępuje systematycznej pracy pomiaru i ograniczania ryzyka, red teamers pomagają odkryć i zidentyfikować szkody, a z kolei włączyć strategie pomiaru w celu zweryfikowania skuteczności środków zaradczych.
Podczas gdy firma Microsoft przeprowadziła ćwiczenia związane z czerwonym tworzeniem zespołu i zaimplementowały systemy bezpieczeństwa (w tym filtry zawartości i inne strategie ograniczania ryzyka) dla modeli usługi Azure OpenAI Service (zobacz to omówienie praktyk dotyczących odpowiedzialnej sztucznej inteligencji), kontekst każdej aplikacji LLM będzie unikatowy, a także należy 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 czerwone tworzenie zespołu 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 wydajnego czerwonego ćwiczenia tworzenia zespołu.
Przed rozpoczęciem testowania
Planowanie: KtoTo przeprowadzi testy
Zmontuj zróżnicowaną grupę czerwonych zespołów
Określ idealną kompozycję czerwonych zespołów pod względem doświadczenia ludzi, demografii i wiedzy w różnych dyscyplinach (na przykład ekspertów w dziedzinie sztucznej inteligencji, nauk społecznych, zabezpieczeń) dla domeny 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 czerwonych zespołów zarówno z łagodnymi i niepożądanymi umysłami
Red teamers with an adversarial mindset and security-testing experience is essential for understanding security risks, but red teamers who are ordinary users of your application system and have't been involved in its development can bring valuable perspectives on harms that regular users might encounter.
Przypisywanie czerwonych zespołów do szkód i/lub funkcji produktu
Przypisz red teamers RAI z określoną wiedzą, aby zbadać konkretne rodzaje szkód (na przykład eksperci ds. zabezpieczeń mogą sondować jailbreaki, wyodrębnianie meta monitów i zawartość związaną z cyberatakami).
W przypadku wielu rund testowania zdecyduj, czy zmienić czerwone przypisania zespołu w każdej rundzie, aby uzyskać zróżnicowane perspektywy na poszczególne szkody i utrzymać kreatywność. W przypadku przełączania przypisań poczekaj na przyspieszenie instrukcji dotyczących nowo przypisanych szkód przez red teamers.
W późniejszych etapach, kiedy aplikacja i jej interfejs użytkownika są opracowywane, możesz przypisać red teamers do określonych części aplikacji (tj. funkcji), aby zapewnić pokrycie całej aplikacji.
Zastanów się, ile czasu i nakładu pracy powinien przeznaczyć każdy czerwony zespół (na przykład te testy dla łagodnych scenariuszy mogą potrzebować mniej czasu niż testy w scenariuszach niepożądanych).
Przydatne może być zapewnienie czerwonym zespołom:
- Wyczyść instrukcje, które mogą obejmować:
- Wprowadzenie opisujące cel i cel danej rundy czerwonej drużyny; produkt i funkcje, które zostaną przetestowane i jak uzyskać do nich dostęp; jakiego rodzaju problemy należy przetestować; obszary fokusu red teamers, jeśli testowanie jest bardziej ukierunkowane; ile czasu i wysiłku każdego czerwonego zespołu powinien poświęcić na testowanie; jak rejestrować wyniki; i kto ma się skontaktować z pytaniami.
- 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:
Model podstawowy LLM z systemem bezpieczeństwa w celu zidentyfikowania wszelkich luk, które mogą być konieczne do rozwiązania w kontekście systemu aplikacji. (Testowanie odbywa się zwykle za pośrednictwem punktu końcowego interfejsu API).
Aplikacja. (Testowanie najlepiej wykonać za pośrednictwem interfejsu użytkownika).
Zarówno podstawowy model LLM, jak i aplikacja, przed i po ich zastosowaniu zostaną wprowadzone środki zaradcze.
Poniższe zalecenia pomagają wybrać, co należy przetestować w różnych punktach podczas czerwonego tworzenia zespołu:
Możesz rozpocząć od przetestowania modelu podstawowego, aby zrozumieć powierzchnię ryzyka, zidentyfikować szkody i poprowadzić rozwój środków zaradczych RAI dla produktu.
Przetestuj wersje produktu iteracyjne za pomocą środków zaradczych RAI i bez nich, aby ocenić skuteczność środków zaradczych RAI. (Należy pamiętać, że ręczne tworzenie zespołu czerwonego może nie być wystarczające — należy również używać pomiarów systematycznych, ale dopiero po zakończeniu początkowej rundy ręcznego czerwonego tworzenia zespołu).
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ą red teamers RAI eksplorowanie i dokumentowanie wszelkich problematycznych treści (zamiast prosić ich o znalezienie przykładów konkretnych szkód) pozwala im twórczo zbadać szeroką gamę problemów, odkrywając martwe plamy w zrozumieniu powierzchni ryzyka.
Utwórz listę szkód na podstawie testów zakończonych otwarciem.
- 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ź red teaming and iterate: Kontynuuj sondowanie pod kątem szkód na liście; zidentyfikować nowe szkody, które powierzchnię.
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 szkodzą priorytetowi testowania iteracyjnego. Kilka czynników może poinformować o priorytetyzacji, w tym, ale nie tylko, o ważności szkód i kontekście, w którym są one bardziej narażone na powierzchnię.
Plan: Jak rejestrować dane
Zdecyduj, jakie dane chcesz zebrać i jakie dane są opcjonalne.
Zdecyduj, jakie dane będą musiały rejestrować czerwoni członkowie zespołu (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 i inne notatki).
Bądź strategiczny dzięki zbieranych danych, aby uniknąć przytłaczających czerwonych zespołów, a jednocześnie nie brakuje ich na krytycznych informacjach.
Tworzenie struktury zbierania danych
Udostępniony arkusz kalkulacyjny programu Excel jest często najprostszą metodą zbierania czerwonych danych zespołu. Zaletą tego udostępnionego pliku jest to, że czerwoni członkowie zespołu mogą przeglądać przykłady, aby zdobyć twórcze pomysły na własne testowanie i uniknąć duplikowania danych.
Podczas testowania
Planowanie aktywnego wstrzymania, gdy trwa czerwone tworzenie zespołu
- Przygotuj się do pomocy red teamers z instrukcjami i problemami z dostępem.
- Monitoruj postęp arkusza kalkulacyjnego i wysyłaj przypomnienia terminowe do czerwonych zespołów.
Po każdej rundzie testowania
Dane raportu
Udostępnij krótki raport w regularnych odstępach czasu kluczowym uczestnikom projektu, który:
Wyświetla listę najważniejszych zidentyfikowanych problemów.
Udostępnia link do danych pierwotnych.
Wyświetla podgląd planu testowania dla nadchodzących rund.
Potwierdza czerwone zespoły.
Zawiera wszelkie inne istotne informacje.
Rozróżnianie identyfikacji i pomiaru
W sprawozdaniu należy wyjaśnić, że rola red teamingu RAI polega na uwidacznieniu i podniesieniu zrozumienia powierzchni ryzyka i nie jest zamiennikiem systematycznego pomiaru i rygorystycznej pracy zaradczej. 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 prawne lub prawne, które mają zastosowanie do 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.