Wskazówki dotyczące bezpieczeństwa

Modele generatywnej sztucznej inteligencji to zaawansowane narzędzia, ale mają pewne ograniczenia. Ich wszechstronność i możliwość zastosowania mogą czasami prowadzić do nieoczekiwanych wyników, takich jak nieprawdziwe, stronnicze lub obraźliwe treści. Przetwarzanie końcowe i dokładna ocena ręczna są niezbędne, aby ograniczyć ryzyko szkód wynikających z takich danych wyjściowych.

Modele udostępniane przez Gemini API można wykorzystywać w różnych aplikacjach generatywnej AI i przetwarzania języka naturalnego (NLP). Korzystanie z tych funkcji jest możliwe tylko za pomocą Gemini API lub aplikacji internetowej Google AI Studio. Korzystanie z Gemini API podlega też zasadom dotyczącym niedozwolonych zastosowań generatywnej AI i warunkom korzystania z usługi Gemini API.

Duże modele językowe (LLM) są tak przydatne, ponieważ są kreatywnymi narzędziami, które mogą wykonywać wiele różnych zadań związanych z językiem. Niestety oznacza to również, że duże modele językowe mogą generować nieoczekiwane dane wyjściowe, w tym tekst, który jest obraźliwy, nieodpowiedni lub niezgodny z faktami. Co więcej, niesamowita wszechstronność tych modeli utrudnia przewidywanie, jakie niepożądane wyniki mogą one generować. Interfejs Gemini API został zaprojektowany z uwzględnieniem zasad AI Google, ale to na deweloperach spoczywa odpowiedzialność za stosowanie tych modeli w odpowiedzialny sposób. Aby pomóc deweloperom w tworzeniu bezpiecznych i odpowiedzialnych aplikacji, interfejs Gemini API ma wbudowane filtrowanie treści oraz dostosowywane ustawienia bezpieczeństwa w 4 kategoriach szkodliwych treści. Więcej informacji znajdziesz w przewodniku po ustawieniach bezpieczeństwa.

Ten dokument ma na celu zapoznanie Cię z niektórymi zagrożeniami, które mogą wystąpić podczas korzystania z LLM, oraz przedstawienie nowych zaleceń dotyczących projektowania i opracowywania zabezpieczeń. (Pamiętaj, że przepisy prawa mogą również nakładać ograniczenia, ale te kwestie wykraczają poza zakres tego przewodnika).

Podczas tworzenia aplikacji z modelami LLM zalecamy wykonanie tych czynności:

• Omówienie zagrożeń związanych z bezpieczeństwem aplikacji
• Rozważanie zmian w celu ograniczenia zagrożeń dla bezpieczeństwa
• przeprowadzanie testów bezpieczeństwa odpowiednich do Twojego przypadku użycia;
• zbieranie opinii użytkowników i monitorowanie korzystania z usługi;

Fazy dostosowywania i testowania powinny być powtarzane, aż osiągniesz wydajność odpowiednią dla Twojej aplikacji.

Poznaj zagrożenia związane z bezpieczeństwem aplikacji

W tym kontekście bezpieczeństwo jest definiowane jako zdolność dużego modelu językowego do unikania wyrządzania szkód użytkownikom, np. poprzez generowanie toksycznego języka lub treści promujących stereotypy. Modele dostępne w Gemini API zostały zaprojektowane zgodnie z zasadami Google dotyczącymi AI, a korzystanie z nich podlega zasadom dotyczącym niedozwolonych zastosowań generatywnej AI. Interfejs API udostępnia wbudowane filtry bezpieczeństwa, które pomagają rozwiązywać niektóre typowe problemy związane z modelami językowymi, takie jak toksyczne wypowiedzi i mowa nienawiści, oraz dbać o inkluzywność i unikanie stereotypów. Każda aplikacja może jednak stanowić inne zagrożenie dla użytkowników. Jako właściciel aplikacji ponosisz odpowiedzialność za poznanie swoich użytkowników i potencjalnych szkód, jakie może wyrządzić Twoja aplikacja, oraz za zapewnienie, że korzysta ona z dużych modeli językowych w bezpieczny i odpowiedzialny sposób.

W ramach tej oceny należy wziąć pod uwagę prawdopodobieństwo wystąpienia szkody, określić jej powagę i podjąć odpowiednie działania. Na przykład aplikacja, która generuje eseje na podstawie faktów, musi bardziej uważać na to, aby nie rozpowszechniać nieprawdziwych informacji, niż aplikacja, która generuje fikcyjne historie dla rozrywki. Dobrym sposobem na rozpoczęcie badania potencjalnych zagrożeń jest przeprowadzenie analizy użytkowników końcowych i innych osób, na które mogą mieć wpływ wyniki działania aplikacji. Może to przybierać różne formy, np. analizowanie najnowszych badań w zakresie Twojej aplikacji, obserwowanie, jak użytkownicy korzystają z podobnych aplikacji, przeprowadzanie badań opinii użytkowników, ankiet lub nieformalnych wywiadów z potencjalnymi użytkownikami.

Rozważ wprowadzenie zmian, aby zmniejszyć ryzyko związane z bezpieczeństwem

Teraz, gdy znasz już ryzyko, możesz zdecydować, jak je ograniczyć. Określenie, którym zagrożeniom należy nadać priorytet i jak wiele należy zrobić, aby im zapobiec, jest kluczową decyzją, podobnie jak w przypadku nadawania priorytetów błędom w projekcie oprogramowania. Po ustaleniu priorytetów możesz zacząć zastanawiać się nad rodzajami działań, które będą najbardziej odpowiednie. Często proste zmiany mogą przynieść korzyści i zmniejszyć ryzyko.

Podczas projektowania aplikacji weź pod uwagę te kwestie:

• Dostrajanie danych wyjściowych modelu, aby lepiej odzwierciedlały to, co jest akceptowalne w kontekście Twojej aplikacji. Dostrajanie może sprawić, że dane wyjściowe modelu będą bardziej przewidywalne i spójne, a tym samym pomoże ograniczyć pewne zagrożenia.
• Zapewnianie metody wprowadzania danych, która ułatwia uzyskiwanie bezpieczniejszych wyników. Dokładne dane wejściowe podane do LLM mogą mieć wpływ na jakość wygenerowanych treści. Eksperymentowanie z promptami wejściowymi, aby znaleźć te, które są najbezpieczniejsze w Twoim przypadku, jest warte wysiłku, ponieważ możesz wtedy zapewnić UX, który to ułatwia. Możesz na przykład ograniczyć użytkownikom możliwość wyboru tylko z listy rozwijanej z promptami lub oferować wyskakujące sugestie z opisowymi frazami, które w kontekście Twojej aplikacji są bezpieczne.

• Blokowanie niebezpiecznych danych wejściowych i filtrowanie danych wyjściowych przed wyświetleniem ich użytkownikowi. W prostych sytuacjach listy blokowania można wykorzystać do identyfikowania i blokowania niebezpiecznych słów lub fraz w promptach lub odpowiedziach albo do wymagania od weryfikatorów ręcznego zmieniania lub blokowania takich treści.

• Używanie wytrenowanych klasyfikatorów do otagowania każdego promptu z potencjalnie szkodliwymi lub złośliwymi sygnałami. Wtedy można zastosować różne strategie obsługi żądań bazujące na typie wykrytych szkód. Jeśli na przykład dane wejściowe są ewidentnie szkodliwe lub mają charakter nadużycia, mogą zostać zablokowane, a jako dane wyjściowe pojawi się przygotowana wcześniej odpowiedź.

  Wskazówka dla zaawansowanych

  • Jeśli sygnały wskazują, że dane wyjściowe są szkodliwe, aplikacja może zastosować te opcje:
    • wyświetlić komunikat o błędzie lub przygotowane dane wyjściowe,
    • Spróbuj ponownie, aby sprawdzić, czy wygeneruje alternatywne bezpieczne dane wyjściowe, ponieważ czasami ten sam prompt daje różne wyniki.

• Wprowadzanie zabezpieczeń przed celowym nadużywaniem, np. przypisywanie każdemu użytkownikowi unikalnego identyfikatora i nakładanie limitu na liczbę zapytań użytkowników, które można przesłać w danym okresie. Kolejnym zabezpieczeniem jest ochrona przed możliwym wstrzykiwaniem promptów. Wstrzykiwanie promptów, podobnie jak wstrzykiwanie kodu SQL, to sposób, w jaki złośliwi użytkownicy mogą tworzyć prompt wejściowy, który manipuluje danymi wyjściowymi modelu, np. wysyłając prompt wejściowy, który nakazuje modelowi zignorowanie wszystkich poprzednich przykładów. Szczegółowe informacje o celowym niewłaściwym wykorzystaniu znajdziesz w zasadach dotyczących niedozwolonych zastosowań generatywnej AI.

• Dostosowanie funkcji do czegoś, co z natury wiąże się z mniejszym ryzykiem. Zadania o węższym zakresie (np. wyodrębnianie słów kluczowych z fragmentów tekstu) lub te, które są poddawane większej kontroli przez człowieka (np. generowanie krótkich treści, które będą sprawdzane przez człowieka), często wiążą się z mniejszym ryzykiem. Na przykład zamiast tworzyć od zera aplikację do pisania odpowiedzi na e-maile, możesz ograniczyć jej działanie do rozwijania konspektu lub sugerowania alternatywnych sformułowań.

Przeprowadzanie testów bezpieczeństwa odpowiednich do danego przypadku użycia

Testowanie jest kluczowym elementem tworzenia niezawodnych i bezpiecznych aplikacji, ale zakres, zasięg i strategie testowania mogą się różnić. Na przykład generator haiku dla zabawy prawdopodobnie stwarza mniejsze ryzyko niż aplikacja przeznaczona dla kancelarii prawnych do podsumowywania dokumentów prawnych i pomagania w tworzeniu umów. Jednak generator haiku może być używany przez szersze grono użytkowników, co oznacza, że potencjał prób ataku lub nawet niezamierzonych szkodliwych danych wejściowych może być większy. Kontekst wdrożenia również ma znaczenie. Na przykład aplikacja, której wyniki są sprawdzane przez ekspertów przed podjęciem jakichkolwiek działań, może być uznana za mniej podatną na generowanie szkodliwych wyników niż identyczna aplikacja bez takiego nadzoru.

Nawet w przypadku aplikacji o stosunkowo niskim ryzyku często trzeba wprowadzić kilka zmian i przeprowadzić kilka testów, zanim będzie można mieć pewność, że aplikacja jest gotowa do wprowadzenia na rynek. W przypadku aplikacji AI szczególnie przydatne są 2 rodzaje testów:

• Testy porównawcze bezpieczeństwa polegają na opracowaniu wskaźników bezpieczeństwa, które odzwierciedlają sposoby, w jakie aplikacja może być niebezpieczna w kontekście prawdopodobnego sposobu jej używania. Następnie za pomocą zbiorów danych do oceny testuje się, jak dobrze aplikacja radzi sobie z tymi wskaźnikami. Przed rozpoczęciem testów warto zastanowić się nad minimalnymi akceptowalnymi poziomami wskaźników bezpieczeństwa, aby 1) móc ocenić wyniki testów na podstawie tych oczekiwań i 2) zebrać zbiór danych do oceny na podstawie testów, które oceniają wskaźniki, na których najbardziej Ci zależy.

  Wskazówki dla zaawansowanych

  • Uważaj na nadmierne poleganie na gotowych rozwiązaniach, ponieważ prawdopodobnie będziesz musiał(-a) utworzyć własne zbiory danych testowych przy użyciu oceniających, aby w pełni dostosować je do kontekstu aplikacji.
  • Jeśli masz więcej niż 1 rodzaj danych, musisz zdecydować, jak będziesz dokonywać kompromisów, gdy zmiana przyniesie korzyści w przypadku jednego rodzaju danych, ale pogorszy wyniki w przypadku innego. Podobnie jak w przypadku innych działań związanych z optymalizacją wydajności warto skupić się na najgorszych wynikach w zbiorze oceniającym, a nie na średnich wynikach.

• Testy z użyciem szkodliwych danych wejściowych polegają na proaktywnym próbowaniu uszkodzenia aplikacji. Celem jest zidentyfikowanie słabych punktów, aby można było podjąć odpowiednie kroki w celu ich wyeliminowania. Testy negatywne mogą wymagać od oceniających z doświadczeniem w zakresie Twojej aplikacji dużo czasu i wysiłku, ale im więcej ich przeprowadzisz, tym większa szansa na wykrycie problemów, zwłaszcza tych, które występują rzadko lub dopiero po wielokrotnym uruchomieniu aplikacji.

  • Testy z użyciem szkodliwych danych wejściowych to metoda systematycznej oceny modelu ML z zamiarem ustalenia, jak się on zachowuje, gdy celowo lub nieumyślnie wprowadzimy do niego szkodliwe dane wejściowe:
    • Dane wejściowe mogą być złośliwe, gdy ewidentnie mają za zadanie wygenerować niebezpieczne lub szkodliwe dane wyjściowe – na przykład gdy prosisz model generujący teksty o stworzenie wypowiedzi szerzącej nienawiść do określonej religii.
    • Dane wejściowe są nieumyślnie szkodliwe, gdy one same są nieszkodliwe, ale powodują wygenerowanie szkodliwych danych wyjściowych. Może to być na przykład prośba, aby model generujący teksty opisał osobę o określonym pochodzeniu etnicznym, co spowoduje, że model generuje rasistowską odpowiedź.
  • Testowanie z użyciem szkodliwych danych wejściowych różni się od standardowej oceny składem danych używanych do testowania. W przypadku testów z użyciem szkodliwych danych wejściowych wybierz dane testowe, które najprawdopodobniej wywołają problematyczne dane wyjściowe z modelu. Oznacza to sprawdzanie zachowania modelu pod kątem wszystkich rodzajów możliwych szkód, w tym rzadkich lub nietypowych przykładów i przypadków brzegowych, które są istotne z punktu widzenia zasad bezpieczeństwa. Powinien on również obejmować różnorodność w różnych wymiarach zdania, takich jak struktura, znaczenie i długość. Więcej informacji o tym, co należy wziąć pod uwagę podczas tworzenia zbioru danych testowych, znajdziesz w zasadach Google dotyczących odpowiedzialnego stosowania AI w zakresie sprawiedliwości.

    Wskazówki dla zaawansowanych

    • Zamiast tradycyjnej metody polegającej na angażowaniu osób w „zespoły czerwone”, które próbują włamać się do aplikacji, używaj testów automatycznych. W testach automatycznych „czerwony zespół” to kolejny model językowy, który znajduje tekst wejściowy wywołujący szkodliwe dane wyjściowe z testowanego modelu.

Monitorowanie problemów

Bez względu na to, ile testów przeprowadzisz i jak bardzo zminimalizujesz ryzyko, nigdy nie możesz zagwarantować doskonałości, dlatego z wyprzedzeniem zaplanuj, jak będziesz wykrywać i rozwiązywać pojawiające się problemy. Typowe podejścia obejmują utworzenie monitorowanego kanału, na którym użytkownicy mogą dzielić się opiniami (np. oceniać za pomocą kciuka w górę lub w dół), oraz przeprowadzenie badania opinii użytkowników, aby aktywnie pozyskiwać opinie od różnych użytkowników – jest to szczególnie przydatne, jeśli wzorce użytkowania różnią się od oczekiwań.

Dalsze kroki

• Więcej informacji o dostosowywanych ustawieniach bezpieczeństwa dostępnych w interfejsie Gemini API znajdziesz w przewodniku dotyczącym ustawień bezpieczeństwa.
• Aby zacząć pisać pierwsze prompty, zapoznaj się z wprowadzeniem do promptów.