Wskazówki dotyczące bezpieczeństwa

Inną cechą dużych modeli językowych (LLM) jest to, że są to narzędzia kreatywne, które mogą realizować wiele różnych zadań językowych. Niestety to oznacza również, że duże modele językowe mogą generować dane wyjściowe, których nie oczekujesz, w tym tekst, który jest obraźliwy, niewrażliwy lub niepoprawne pod względem merytorycznym. Co więcej, niesamowita wszechstronność tych modeli sprawia też, że trudno jest przewidzieć dokładnie, jakie rodzaje niepożądanych efektów mogą wygenerować. Interfejs Gemini API został zaprojektowany z myślą o zasadach Google dotyczących AI, ale obowiązkiem deweloperów jest odpowiedzialne stosowanie tych modeli. Aby pomóc deweloperom w tworzeniu bezpiecznych, odpowiedzialnych aplikacji, interfejs Gemini API ma wbudowane filtrowanie treści oraz możliwość dostosowania ustawień bezpieczeństwa w 4 wymiarach. Więcej informacji znajdziesz w przewodniku dotyczącym ustawień bezpieczeństwa.

Ten dokument przedstawia pewne zagrożenia, które mogą wystąpić podczas korzystania z LLM, oraz rekomenduje nowe rekomendacje dotyczące projektowania i tworzenia bezpieczeństwa. (Należy pamiętać, że przepisy i regulacje prawne mogą też nakładać ograniczenia, ale tego rodzaju kwestie nie są uwzględnione w tym przewodniku).

Podczas tworzenia aplikacji za pomocą LLM zalecamy wykonanie tych czynności:

• Omówienie zagrożeń bezpieczeństwa związanych z Twoją aplikacją
• Rozważanie dostosowań w celu ograniczenia zagrożeń bezpieczeństwa
• Przeprowadzanie testów bezpieczeństwa odpowiednich dla danego przypadku użycia
• Zbieranie opinii użytkowników i monitorowanie użytkowania

Etapy dostosowywania i testowania powinny być iteracyjne, aż do osiągnięcia wydajności odpowiedniej dla aplikacji.

Omówienie zagrożeń bezpieczeństwa związanych z Twoją aplikacją

W tym kontekście bezpieczeństwo definiuje się jako zdolność LLM do unikania szkód dla użytkowników, na przykład przez generowanie toksycznego języka lub treści promujące stereotypy. Modele dostępne w interfejsie Gemini API zostały zaprojektowane z myślą o zasadach Google dotyczących 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ązać niektóre typowe problemy z modelami językowymi, takie jak toksyczny język i szerzenie nienawiści, a także dążenie do integracji społecznej i unikania stereotypów. Każda aplikacja stwarza jednak inne ryzyko dla użytkowników. Jako właściciel aplikacji odpowiadasz za zapoznanie się z użytkownikami i potencjalnymi zagrożeniami, jakie może spowodować ta aplikacja, a także za to, by używać modeli LLM w bezpieczny i odpowiedzialny sposób.

W ramach tej oceny należy wziąć pod uwagę prawdopodobieństwo wystąpienia szkody oraz określić jej wagę i działania, jakie należy podjąć. Na przykład aplikacja, która pisze wypracowania na podstawie faktów, powinna z większym prawdopodobieństwem unikać dezinformacji, a nie aplikacji, które generują fikcyjne historie rozrywkowe. Dobrym sposobem na rozpoczęcie badania potencjalnych zagrożeń jest przeanalizowanie użytkowników i innych osób, na które mogą mieć wpływ wyniki Twojej aplikacji. Może to być np. badanie najnowszych badań w domenie Twojej aplikacji, obserwacja, jak użytkownicy korzystają z podobnych aplikacji, przeprowadzenie badania opinii użytkowników, przeprowadzenie ankiet lub nieformalne wywiady z potencjalnymi użytkownikami.

Rozważ dostosowania, aby ograniczyć zagrożenia dla bezpieczeństwa

Wiesz już, na czym polegają zagrożenia, więc czas je ograniczyć. Ustalenie, które zagrożenia należy traktować priorytetowo i jak bardzo starać się im zapobiegać, to decyzja kluczowa, podobnie jak klasyfikowanie błędów w projekcie związanym z oprogramowaniem. Po ustaleniu priorytetów możesz zacząć się zastanawiać, jakie środki zaradcze będą najbardziej odpowiednie. Często proste zmiany mogą pomóc w rozwiązaniu ryzyka i zmniejszyć ryzyko.

Na przykład podczas projektowania aplikacji weź pod uwagę te kwestie:

• Dostrój dane wyjściowe 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 mogą pomóc ograniczyć pewne ryzyko.
• Zapewnianie metody wprowadzania, która zapewnia bezpieczniejsze dane wyjściowe. Dokładne dane wejściowe, które podasz do LLM, mogą mieć wpływ na jakość danych wyjściowych. Eksperymentowanie z podpowiedziami dotyczącymi danych wejściowych w celu znalezienia tego, co sprawdza się najlepiej w Twoim przypadku użycia, jest warte wysiłku, ponieważ możesz dzięki temu zadbać o wrażenia użytkownika. Możesz np. ograniczyć użytkownikom możliwość wyboru tylko z listy z listą promptów lub oferować wyskakujące sugestie z opisowymi wyrażeniami, które Twoim zdaniem działają bezpiecznie w kontekście aplikacji.

• Blokuje niebezpieczne dane wejściowe i filtrowane dane wyjściowe, zanim wyświetlą się użytkownikowi. W prostych sytuacjach listy zablokowanych mogą służyć do identyfikowania i blokowania niebezpiecznych słów i wyrażeń w promptach lub odpowiedziach. Mogą też wymagać ręcznego zmodyfikowania lub zablokowania takich treści przez weryfikatorów.

• Za pomocą przeszkolonych klasyfikatorów do oznaczania każdego promptu potencjalnymi zagrożeniami lub sygnałami wrogimi. Następnie w zależności od rodzaju wykrytej szkody można wykorzystać różne strategie postępowania z żądaniem. Jeśli na przykład dane wejściowe są jawnie przeciwnie

  Wskazówka dla zaawansowanych

  • Jeśli sygnały wykażą, że dane wyjściowe są szkodliwe, aplikacja może stosować te opcje:
    • Podaj komunikat o błędzie lub wymagane dane wyjściowe.
    • Spróbuj ponownie, jeśli zostanie wygenerowane alternatywne, bezpieczne dane wyjściowe, ponieważ czasami ten sam prompt wywołuje inne dane wyjściowe.

• Wprowadzanie środków ochrony przed celowym niewłaściwym wykorzystaniem, np. przypisywanie każdemu użytkownikowi unikalnego identyfikatora i narzucanie limitu liczby zapytań, które można przesłać w danym okresie. Kolejnym zabezpieczeniem jest zapewnienie ochrony przed możliwym wstrzykiwaniem promptów. Wstrzykiwanie promptów, podobnie jak wstrzykiwanie SQL, umożliwia szkodliwym użytkownikom zaprojektowanie promptu, który manipuluje danymi wyjściowymi modelu, np. przez wysyłanie promptu, który nakazuje modelowi zignorowanie poprzednich przykładów. Szczegółowe informacje o celowym nadużyciom znajdziesz w zasadach dotyczących niedozwolonych zastosowań generatywnej AI.

• Dostosowanie funkcji do elementu, który z natury wiąże się z niższym ryzykiem. Zadania o węższym zakresie (np. wyodrębnianie słów kluczowych z fragmentów tekstu) lub wymagające większego nadzoru człowieka (np. generowanie krótkich treści do sprawdzenia przez człowieka) często wiążą się z mniejszym ryzykiem. Na przykład zamiast tworzyć aplikację do pisania odpowiedzi e-mail z serii, możesz ograniczyć ją do rozwijania konspektu lub sugerowania alternatywnych fraz.

Wykonaj testy bezpieczeństwa odpowiednie do Twojego przypadku użycia.

Testowanie to kluczowy element tworzenia solidnych i bezpiecznych aplikacji, ale zakres, zakres i strategie testowania mogą się różnić. Na przykład generator haiku do zabawy stwarza mniej poważne ryzyko niż aplikacja przeznaczona dla kancelarii prawniczych do podsumowywania dokumentów prawnych i ułatwiania przygotowań do umów. Z generatora haiku może korzystać jednak znacznie więcej osób. W związku z tym większe możliwości w przypadku wrogich prób, a nawet niezamierzonych szkodliwych danych wejściowych. 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żna uznać za mniejsze, niż w przypadku identycznej aplikacji bez nadzoru.

Często zdarza się, że kilka razy firma przechodzi przez kilka etapów wprowadzania zmian i testowania, zanim nabierze pewności, że jest gotowa do uruchomienia, nawet w przypadku aplikacji o stosunkowo niskim ryzyku. W przypadku aplikacji AI szczególnie przydają się 2 rodzaje testów:

• Analizy porównawcze zabezpieczeń obejmują zaprojektowanie wskaźników bezpieczeństwa, które pokazują, w jaki sposób aplikacja może być niebezpieczna w kontekście prawdopodobieństwa jej wykorzystania, a następnie przetestowanie wydajności aplikacji w zakresie wskaźników za pomocą zbiorów danych do oceny. Dobrą praktyką jest zastanowienie się przed rozpoczęciem testów o minimalnych dopuszczalnych poziomach bezpieczeństwa. Dzięki temu 1) będziesz mieć możliwość oceny wyników testów pod kątem tych oczekiwań oraz 2) możesz zebrać zbiór danych oceny na podstawie testów oceniających najważniejsze dla Ciebie wskaźniki.

  Wskazówki dla zaawansowanych

  • Wystrzegaj się przesadnego uzależniania się od gotowych rozwiązań, ponieważ najprawdopodobniej konieczne będzie stworzenie własnych testowych zbiorów danych z pomocą osób weryfikatorów, które w pełni pasują do kontekstu aplikacji.
  • Jeśli masz więcej niż 1 wskaźnik, musisz zdecydować, w jaki sposób Twoja zmiana wpłynie na poprawę jednego z nich. Podobnie jak w przypadku innych metod inżynierii wydajności, koncentruj się na najgorszych wynikach w całym zestawie oceny, a nie na ich średniej skuteczności.

• Testy zaawansowane obejmują proaktywne próby uszkodzenia aplikacji. Chodzi o wykrycie słabych punktów i podjęcie działań w celu ich wyeliminowania. Testy wrogie mogą wymagać dużo czasu i wysiłku ze strony weryfikatorów mających doświadczenie w Twojej aplikacji, ale im więcej wykonujesz testów, tym większe ryzyko wystąpienia problemów, zwłaszcza tych, które występują rzadko lub występują tylko po kilkukrotnych uruchomieniach aplikacji.

  • Testy wrogie to metoda systematycznej oceny modelu ML w celu poznania jego zachowania w przypadku wprowadzenia szkodliwych lub niezamierzonych szkodliwych danych wejściowych:
    • Dane wejściowe mogą być szkodliwe, jeśli jasno zostały zaprojektowane w taki sposób, aby generować niebezpieczne lub szkodliwe dane wyjściowe – np. prośba o model generowania tekstu ma na celu wzbudzenie nienawiści w związku z konkretną religią.
    • Dane wejściowe są nieumyślnie szkodliwe, gdy same dane mogą być nieszkodliwe, ale wiązać się z szkodliwymi danymi. Przykładem może być poproszenie modelu generowania tekstu o opisanie osoby z określonej grupy etnicznej i otrzymywanie rasistowskich wypowiedzi.
  • To, co odróżnia test kontradyktoryjny od oceny standardowej, to skład danych używanych do testowania. W przypadku testów kontradyktoryjnych wybierz dane testowe, które z największym prawdopodobieństwem wygenerują problematyczne dane wyjściowe modelu. Oznacza to badanie działania modelu pod kątem wszystkich możliwych szkód, w tym rzadkich lub nietypowych przykładów oraz przypadków skrajnych, które mają związek z zasadami bezpieczeństwa. Powinny też obejmować różnorodność w odniesieniu do różnych wymiarów zdania, np. struktury, znaczenia i długości. Więcej informacji o tym, co należy wziąć pod uwagę podczas tworzenia testowego zbioru danych, znajdziesz w opisie praktyk Google w zakresie odpowiedzialnej AI.

    Wskazówki dla zaawansowanych

    • Aby spróbować rozwiązać problem, użyj testowania automatycznego zamiast tradycyjnej metody dodawania osób do „czerwonych zespołów”. W przypadku testów automatycznych „czerwony zespół” to kolejny model językowy, który znajduje tekst wejściowy, który generuje szkodliwe dane wyjściowe z testowanego modelu.

Monitoruj pracę pod kątem problemów

Bez względu na ilość testów i ograniczeń nigdy nie możesz zagwarantować doskonałości, dlatego zaplanuj z wyprzedzeniem, jak wykryć i rozwiązać ewentualne problemy. Typowe metody obejmują skonfigurowanie kanału, na którym użytkownicy mogą dzielić się opiniami (np. ocenianie kciuka w górę i w dół) oraz przeprowadzanie badań opinii użytkowników z różnych grup, co jest szczególnie przydatne, jeśli wzorce korzystania z usługi są odbiegające od oczekiwań.

Dalsze kroki

• Informacje o możliwościach dostosowania ustawień bezpieczeństwa dostępnych w interfejsie Gemini API znajdziesz w przewodniku po ustawieniach bezpieczeństwa.
• Przeczytaj wprowadzenie do promptów, by zacząć pisać pierwsze prompty.