Przewodniki
Pułapy ryzyka
Pułap ogranicza, jak często lub jak bardzo coś idzie źle: niebezpieczne odpowiedzi, wycieki danych, udane ataki, koszt albo opóźnienie. Oloproof mierzy pułapy, które deklaruje Twoja polityka, na przypadkach, które zawiera Twój zestaw. Nie pisze ataków i nie szuka nowych niepowodzeń; jeśli robi to inne narzędzie, Oloproof odczytuje wyniki tego narzędzia dla poszczególnych przypadków i na ich podstawie rozstrzyga pułap.
Dwa rodzaje pułapu
version: 1
rules:
# A rate: the share of answers a check flags as unsafe, at most 2%.
- id: unsafe-ceiling
metric: unsafe
max: 0.02
# A count: no case in this suite may leak a customer's data.
- id: no-leak
metric: no_leak
max_failures: 0max: rozstrzyga na podstawie przedziału. Reguła jest spełniona, gdy górna granica przedziału jest na poziomie pułapu lub poniżej, niespełniona, gdy jego dolna granica jest powyżej pułapu, a pomiędzy tymi sytuacjami daje INSUFFICIENT_EVIDENCE. Przedział jest dwustronny na poziomie confidence_level polityki, domyślnie 95%, a pułap odczytuje tylko jego górny koniec, więc system, którego rzeczywisty odsetek przekracza pułap, przechodzi nie częściej niż w 2.5% prób, gdy jego przypadki są niezależne (zestaw, który deklaruje klastry, jest odczytywany z przedziałem, który je uwzględnia, Klastry). Dla kryterium pass lub fail odsetek to udział przypadków, które przechodzą, więc kryterium musi przechodzić wtedy, gdy wydarzyło się to, co ma zostać ograniczone (unsafe przechodzi przy niebezpiecznej odpowiedzi). Próg minimalny na przeciwnym kryterium rozstrzyga tak samo: min: 0.98 na kryterium, które przechodzi przy bezpiecznej odpowiedzi, to ta sama reguła co max: 0.02 na kryterium, które przechodzi przy niebezpiecznej.
max_failures: liczy. Odczytuje przypadki, które nie przeszły w zestawie w takiej postaci, w jakiej został wykonany, bez przedziału, i nie twierdzi niczego poza tymi przypadkami. Reguła staje się niespełniona, gdy tylko liczba przekroczy limit; przypadek bez werdyktu liczy się przeciwko limitowi, dopóki go nie otrzyma, więc zestaw z brakującymi werdyktami, które mogłyby wyprowadzić go ponad limit, daje INSUFFICIENT_EVIDENCE, a nie pass. Używaj tego do tego, co nigdy nie może się wydarzyć w zestawie napisanym celowo, gdzie odsetek w populacji nie miałby żadnego znaczenia.
Ilu przypadków potrzebuje pułap
Niski pułap wymaga wielu przypadków, nawet gdy nic nie idzie źle. Przy 95%, z dokładnym przedziałem, którego Oloproof używa dla odsetka pass lub fail:
| Pułap | Brak zaobserwowanych niepowodzeń | Jedno niepowodzenie | Dwa niepowodzenia |
|---|---|---|---|
| 5% | 72 przypadki | 110 przypadków | 142 przypadki |
| 2% | 183 przypadki | 277 przypadków | 359 przypadków |
| 1% | 368 przypadków | 555 przypadków | 720 przypadków |
Bez zaobserwowanego niepowodzenia potrzeba około 3.7 podzielone przez pułap. Zestaw mniejszy niż to nie może spełnić reguły, cokolwiek zrobi system, i bramka to mówi: nierozstrzygnięty pułap daje INSUFFICIENT_EVIDENCE, z wierszem mówiącym, ile jeszcze przypadków by go rozstrzygnęło.
Odczytywanie wyników narzędzia red team
Narzędzie red team pisze ataki i ocenia każdą odpowiedź. Jego oceny dla poszczególnych przypadków są tym, czego potrzebuje pułap, a oloproof scores import je wczytuje (Druga opinia). Folder recipes/ przykładu zawiera przepis dla promptfoo:
oloproof init --example second-opinion second-opinion
cd second-opinion
promptfoo redteam generate
promptfoo eval -c redteam.yaml --output before.jsonl
python recipes/promptfoo_redteam.py before.jsonl before.csvKażdy atak staje się jednym przypadkiem, a jego ocena staje się resisted, które przechodzi, gdy cel się obronił. Wiersze, których promptfoo nie zdołało ocenić, nie mają werdyktu i liczą się jako brakujące. Polityka dla tych wyników:
version: 1
rules:
- id: attacks-resisted
metric: resisted
min: 0.98
- id: no-successful-attack
metric: resisted
max_failures: 0oloproof scores import before.csv --policy release.yamlpromptfoo ocenia za pomocą modelu, a Oloproof traktuje je tak jak każdego sędziego: dopóki ludzie nie oznaczą etykietami próbki jego ocen, nie może ono decydować o wydaniu, a reguły zatrzymują się na evaluator_not_validated (Sprawdzanie sędziego). Aby porównać dwie wersje, uruchom ten sam redteam.yaml na obu: przypadek to miejsce ataku w tym pliku, a ponowne wygenerowanie ataków tworzy inne przypadki.
Czego pułap nie mówi
- Pułap na odsetek dotyczy populacji, z której Twój zestaw pobiera próbę. Zestaw red team to ataki, które ktoś napisał, a nie próbka prawdziwego ruchu, więc jego odsetek jest odsetkiem w obrębie tych ataków; liczność jest tam często bardziej przejrzystą regułą.
- Żaden z tych rodzajów nie obejmuje niepowodzenia, którego nie sprawdza żaden przypadek. Granica dotyczy tego, co zostało wykonane.
- Spełniony pułap to dowód dla Twojej decyzji o wydaniu, a nie certyfikat bezpieczeństwa.
Co dalej
- Bramkowanie CI: plik polityki, block i warn oraz kody wyjścia.
- Druga opinia: plik wyników, który zapisuje każdy przepis.
- Sędziowie: mierzenie oceniającego względem ludzi, zanim będzie mógł decydować.