Wskazówki dotyczące bezpieczeństwa

Modele generatywnej sztucznej inteligencji to zaawansowane narzędzia, ale nie mają ograniczeń. Ich uniwersalność i zastosowanie mogą czasem prowadzić do nieoczekiwanych wyników, np. niedokładnych, stronniczych lub obraźliwych. Przetwarzanie końcowe i rygorystyczna ocena ręczna są kluczowe w ograniczaniu ryzyka szkód spowodowanych z takich wyników.

Modele dostarczane przez Gemini API mogą być wykorzystywane w wielu różnych zastosowaniach związanych z generatywną AI i przetwarzaniem języka naturalnego (NLP). Z tych funkcji można korzystać tylko w interfejsie Gemini API lub aplikacji internetowej Google AI Studio. Korzystanie z Gemini API podlega też Zasadom niedozwolonym zastosowań generatywnej AI oraz Warunkom korzystania z Gemini API.

Częścią przydatności dużych modeli językowych (LLM) jest to, że są to narzędzia kreatywne, które pozwalają wykonywać wiele różnych zadań językowych. Niestety oznacza to również, że duże modele językowe mogą generować nieoczekiwane wyniki, w tym tekst obraźliwy, niestosowny lub niepoprawny merytorycznie. Co więcej, niesamowita uniwersalność tych modeli również sprawia, że trudno jest przewidzieć, jakie dokładnie niepożądane efekty mogą wytworzyć. Chociaż interfejs Gemini API został zaprojektowany z myślą o zasadach Google dotyczących AI, spoczywa na deweloperach odpowiedzialne stosowanie tych modeli. Aby pomóc deweloperom w tworzeniu bezpiecznych i odpowiedzialnych aplikacji, interfejs Gemini API ma wbudowane funkcje filtrowania treści i możliwe do dostosowania ustawienia bezpieczeństwa w 4 wymiarach szkód. Więcej informacji znajdziesz w przewodniku po ustawieniach bezpieczeństwa.

Ten dokument przedstawia niektóre zagrożenia bezpieczeństwa, które mogą wystąpić podczas korzystania z LLM, oraz rekomendacje dotyczące nowych zaleceń dotyczących projektowania i rozwijania zabezpieczeń. (Pamiętaj, że przepisy i regulacje prawne również mogą nakładać ograniczenia, ale nie są one objęte zakresem tego przewodnika).

Podczas tworzenia aplikacji przy użyciu LLM zalecamy wykonanie tych czynności:

• Zapoznanie z zagrożeniami związanymi z bezpieczeństwem aplikacji
• Rozważanie korekt w celu ograniczenia ryzyka związanego z bezpieczeństwem
• przeprowadzanie testów bezpieczeństwa dostosowanych do konkretnego przypadku użycia;
• Zbieranie opinii użytkowników i monitorowanie użycia

Etapy dostosowywania i testowania powinny odbywać się iteracyjnie aż do osiągnięcia wydajności odpowiedniej dla aplikacji.

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

W tym kontekście bezpieczeństwo definiuje się jako zdolność LLM do unikania krzywdzenia użytkowników, np. przez generowanie toksycznego języka lub treści promujących stereotypy. Modele dostępne w interfejsie Gemini API zostały zaprojektowane z myślą o zasadach Google dotyczących AI, a ich używanie podlega Zasadom dotyczącym niedozwolonych zastosowań generatywnej AI. Udostępnia on wbudowane filtry bezpieczeństwa, które pomagają rozwiązywać niektóre typowe problemy z modelami językowymi, takie jak toksyczny język i szerzenie nienawiści, oraz dążąc do promowania integracji społecznej i unikania stereotypów. Każda aplikacja może jednak stwarzać inne ryzyko dla użytkowników. Jako właściciel aplikacji odpowiadasz za poznanie swoich użytkowników i potencjalnych szkód, które może powodować aplikacja, oraz za bezpieczne i odpowiedzialne używanie modeli LLM.

W ramach tej oceny należy wziąć pod uwagę prawdopodobieństwo możliwej szkody i określić jej powagę oraz działania naprawcze. Na przykład aplikacja generująca wypracowania na podstawie rzeczywistych wydarzeń musi być bardziej ostrożna, aby unikać nieprawdziwych informacji niż aplikacja, która generuje fikcyjne historie rozrywkowe. Dobrym sposobem na rozpoczęcie badania potencjalnych zagrożeń jest zbadanie użytkowników i innych osób, na które mogą mieć wpływ wyniki aplikacji. Może to obejmować różnego rodzaju badania, w tym badania nad najnowszymi osiągnięciami w domenie Twojej aplikacji, obserwowanie, jak użytkownicy korzystają z podobnych aplikacji, przeprowadzanie badań opinii użytkowników lub ankiet albo przeprowadzanie nieformalnych rozmów z potencjalnymi użytkownikami.

Rozważ wprowadzenie poprawek, aby ograniczyć ryzyko związane z bezpieczeństwem

Znasz już zagrożenia, możesz więc zdecydować, jak je zminimalizować. Ustalenie, jakie zagrożenia należy traktować priorytetowo i jakie działania należy podjąć, aby im zapobiegać, jest kluczowe, podobnie jak ocenianie błędów w projekcie programowym. Gdy ustalisz priorytety, możesz pomyśleć o typach środków zaradczych, które będą najbardziej odpowiednie. Proste zmiany często mogą przynieść efekty i zmniejszyć ryzyko.

Podczas projektowania aplikacji warto na przykład wziąć pod uwagę te kwestie:

• Dostosowujemy dane wyjściowe modelu, aby lepiej odzwierciedlały to, co jest akceptowalne w kontekście aplikacji. Dostrajanie może sprawić, że dane wyjściowe modelu będą bardziej przewidywalne i spójne, a tym samym pomóc zminimalizować niektóre zagrożenia.
• Udostępniamy metodę przesyłania, która zapewnia bezpieczniejsze dane wyjściowe. Konkretne dane wejściowe, które podasz LLM, mogą mieć wpływ na jakość danych wyjściowych. Warto eksperymentować z promptami dotyczącymi danych wejściowych, aby znaleźć najbezpieczniejsze rozwiązanie w Twoim przypadku użycia, ponieważ później możesz stworzyć UX, który pomoże to zrobić. Możesz na przykład umożliwić użytkownikom wybór tylko z menu z promptami do wprowadzania danych lub oferować wyskakujące sugestie z opisowymi wyrażeniami, które okazały się bezpieczne w kontekście aplikacji.

• Blokowanie niebezpiecznych danych wejściowych i filtrowanie danych wyjściowych, zanim zostaną wyświetlone użytkownikowi. W prostych sytuacjach listy zablokowanych mogą służyć do identyfikowania i blokowania niebezpiecznych słów lub wyrażeń w promptach lub odpowiedziach. Mogą też wymagać od weryfikatorów ręcznego modyfikowania lub blokowania takich treści.

• Używanie wytrenowanych klasyfikatorów do oznaczania poszczególnych promptów potencjalnymi zagrożeniami lub wrogimi sygnałami. Można wtedy zastosować różne strategie postępowania z żądaniem w zależności od typu wykrytej szkody. Jeśli na przykład dane wejściowe są jawnie wrogie lub obraźliwe, mogą zostać zablokowane i zamiast tego wyświetlić gotową odpowiedź.

  Wskazówka dla zaawansowanych

  • Jeśli sygnały stwierdzą, że dane wyjściowe są szkodliwe, aplikacja może stosować te opcje:
    • Podaj komunikat o błędzie lub gotowe dane wyjściowe.
    • Na wypadek, gdyby zostały wygenerowane alternatywne bezpieczne dane wyjściowe, spróbuj wykonać prompt ponownie, ponieważ czasami ten sam prompt zwraca różne wyniki.

• Stosuj środki ochrony przed celowym niewłaściwym użyciem, takie jak przypisywanie każdemu użytkownikowi unikalnego identyfikatora czy ograniczenie liczby zapytań, które można przesłać w danym okresie. Innym środkiem ochronnym jest próba ochrony przed możliwym wstrzykiwaniem promptów. Wstrzykiwanie promptów, podobnie jak wstrzykiwanie SQL, umożliwia szkodliwym użytkownikom zaprojektowanie promptu wejściowego, który manipuluje danymi wyjściowymi modelu. Na przykład przez wysyłanie promptu wejściowego, który instruuje model do zignorowania poprzednich przykładów. Szczegółowe informacje o celowym nadużywaniu generatywnej AI znajdziesz w zasadach dotyczących niedozwolonych zastosowań generatywnej AI.

• Dostosowywanie funkcjonalności do działania, które z natury zmniejsza ryzyko. Zadania o węższym zakresie (np. wyodrębnianie słów kluczowych z fragmentów tekstu) lub nadrzędne 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ć aplikację do pisania odpowiedzi e-mail od zdrapki, możesz ograniczyć ją do rozwijania konspektu lub sugerowania alternatywnych sformułowań.

Przeprowadzaj testy bezpieczeństwa odpowiednio do swojego przypadku użycia

Testowanie to kluczowy element tworzenia solidnych i bezpiecznych aplikacji, ale zakres, zakres i strategie testowania mogą być różne. Na przykład generator haiku do swobodnego doboru treści może wiązać się z mniejszym ryzykiem niż na przykład aplikacja przeznaczona do użytku przez kancelarie prawne do tworzenia podsumowań dokumentów prawnych i pomocy przy pisaniu umów. Z generatora haiku może jednak korzystać większa grupa użytkowników, co oznacza, że ryzyko kontrowersyjnych prób, a nawet niezamierzonych szkodliwych danych wejściowych może być większe. Znaczenie ma również kontekst implementacji. Na przykład aplikacja, której wyniki są sprawdzane przez ekspertów przed podjęciem jakichkolwiek działań, może zostać uznane za mniej prawdopodobne, że aplikacja wygeneruje szkodliwe wyniki niż sama aplikacja bez takiego nadzoru.

Nierzadko poprzedza kilka iteracji wprowadzania zmian i testowania, zanim zyskasz pewność, że wszystko jest gotowe do uruchomienia, nawet w przypadku aplikacji, które są stosunkowo niewielkie pod względem ryzyka. W przypadku aplikacji AI szczególnie przydatne są 2 rodzaje testów:

• Analiza porównawcza bezpieczeństwa obejmuje projektowanie wskaźników bezpieczeństwa, które odzwierciedlają potencjalne zagrożenia dla aplikacji w kontekście prawdopodobieństwa jej użycia, a następnie testowanie wydajności aplikacji pod kątem wskaźników przy użyciu zbiorów danych do oceny. Przed rozpoczęciem testowania dobrze jest zastanowić się nad minimalnymi dopuszczalnymi poziomami wskaźników bezpieczeństwa, aby 1) ocenić wyniki testu pod kątem tych oczekiwań oraz 2) zgromadzić zbiór danych do oceny na podstawie testów oceniających najważniejsze dla Ciebie wskaźniki.

  Wskazówki dla zaawansowanych

  • Uwaga: nie możesz nadmiernie polegać na sprawdzonych metodach, ponieważ może się okazać, że będziesz potrzebować własnych testowych zbiorów danych z pomocą weryfikatorów, aby w pełni dopasować się do kontekstu Twojej aplikacji.
  • Jeśli masz więcej niż 1 wskaźnik, musisz określić, jak wyeliminujesz różnicę w sytuacjach, gdy zmiana prowadzi do poprawy jednego wskaźnika, ale szkodzi drugiego. Podobnie jak w przypadku innych metod inżynierii wydajności, w obrębie zestawu ocen możesz skupić się na najgorszym przypadku wydajności, a nie na średniej wydajności.

• Testy kontradyktoryjne obejmują proaktywne próby uszkodzenia aplikacji. Celem jest zidentyfikowanie słabych punktów, aby można było podjąć odpowiednie kroki, aby im przeciwdziałać. Testy kontradyktoryjne mogą wymagać dużo czasu lub wysiłku ze strony weryfikatorów mających doświadczenie w kontekście danej aplikacji. Jednak im bardziej się to udaje, tym większe ryzyko wychwytywania problemów, zwłaszcza tych występujących rzadko lub tylko po wielokrotnym przebiegu aplikacji.

  • Testy kontradyktoryjne to metoda systematycznej oceny modelu ML z myślą o ustaleniu, jak zachowuje się on, gdy otrzyma złośliwe lub przypadkowo szkodliwe dane wejściowe:
    • Dane wejściowe mogą być złośliwe, jeśli wyraźnie zostały zaprojektowane w taki sposób, aby generować niebezpieczne lub szkodliwe dane wyjściowe – na przykład prosić model generowania tekstu do wygenerowania nienawiści wobec konkretnej religii.
    • Dane wejściowe są nieumyślnie szkodliwe, gdy same dane wejściowe mogą być nieszkodliwe, ale dają szkodliwe wyniki, np. prosząc model generowania tekstu, aby opisał osobę z określonej grupy etnicznej lub o treści rasistowskiej.
  • Tym, co odróżnia test kontradyktoryjny od standardowej oceny, jest struktura danych używanych do testowania. W przypadku testów kontradyktoryjnych wybierz dane testowe, które z największym prawdopodobieństwem wywołają problematyczne dane wyjściowe z modelu. Oznacza to sondowanie zachowania modelu pod kątem wszystkich możliwych zagrożeń, w tym rzadkich lub nietypowych przykładów oraz przypadków skrajnych istotnych dla zasad bezpieczeństwa. Powinien też uwzględniać 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 testowego zbioru danych, znajdziesz w naszych metodach Google dotyczących odpowiedzialnej AI.

    Wskazówki dla zaawansowanych

    • Zamiast tradycyjnej metody zapraszania ludzi do „czerwonych zespołów” do testowania awarii, korzystaj z testów automatycznych. W testach automatycznych „czerwony zespół” to kolejny model językowy, który znajduje tekst wejściowy, który wywołuje szkodliwe dane wyjściowe testowanego modelu.

Monitoruj pod kątem problemów

Bez względu na to, jak bardzo się testujesz i eliminujesz, nie możesz nigdy zagwarantować doskonałości, dlatego z góry zaplanuj sposób wykrywania pojawiających się problemów i rozwiązywania problemów. Typowe metody to skonfigurowanie monitorowanego kanału, na którym użytkownicy mogą wyrażać swoje opinie (np. ocenę kciuka w górę/w dół), oraz przeprowadzanie badania opinii użytkowników w celu proaktywnego pozyskiwania opinii wśród zróżnicowanej grupy użytkowników, co jest szczególnie przydatne, jeśli wzorce użytkowania różnią się od oczekiwań.

Dalsze kroki

• Informacje o możliwych do dostosowania ustawieniach bezpieczeństwa dostępnym w interfejsie Gemini API znajdziesz w przewodniku po ustawieniach bezpieczeństwa.
• Zapoznaj się ze wprowadzeniem do promptów, aby zacząć pisać pierwsze prompty.