AI Prompt Engineering · Lekcja

Pomiar odporności

Ocena odporności na ataki

Pomiar odporności to bezpłatna lekcja AI Prompt Engineering na CoddyKit. To lekcja 4 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej AI Prompt Engineering, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs AI Prompt Engineering zawiera 4 lekcji w sumie.

Odporność jako mierzalna wielkość

Odporność to opór systemu wobec adwersarialnych danych wejściowych wyrażony liczbami, które można śledzić, porównywać i wykorzystywać jako kryteria dopuszczania wydań. „System wydaje się bezpieczny” nie jest pomiarem; pomiarem jest wskaźnik skuteczności ataków wraz z przedziałem ufności.

Ta lekcja pokazuje, jak przekształcić ustalenia z testów red-teamowych w rygorystyczne metryki.

Wskaźnik skuteczności ataku

Najważniejszą metryką jest wskaźnik skuteczności ataku (ASR): odsetek przypadków ataków, które pokonują zabezpieczenia. Im niższy, tym lepiej. Należy raportować go ogółem oraz w podziale na kategorie i techniki, aby wiedzieć, gdzie system jest słaby.

def asr(results):
    breaks = sum(1 for r in results if not r['safe'])
    return breaks / len(results)
# also compute per-category ASR for diagnosis

Ważenie według dotkliwości

Surowy wskaźnik ASR traktuje drobny wyciek i ujawnienie dużej ilości danych osobowych jednakowo. Należy obliczać wynik ważony dotkliwością, aby krytyczne błędy miały największy wpływ na metrykę, a kilka przełamań o dużym wpływie nie zostało ukrytych przez wiele błędów o małym wpływie.

W = {'low':1,'medium':3,'high':7,'critical':15}
def weighted_risk(results):
    return sum(W[r['severity']] for r in results if not r['safe'])

Przedziały ufności zamiast estymat punktowych

ASR jest estymatą uzyskaną z ograniczonej próby, dlatego należy raportować niepewność. Przy małych zestawach przedział jest szeroki; spadek z 8% do 6% może być szumem. Należy używać dwumianowego przedziału ufności i reagować tylko na zmiany, które wykraczają poza ten przedział.

from statsmodels.stats.proportion import proportion_confint
low, high = proportion_confint(breaks, n, method='wilson')
print(f'ASR {breaks/n:.3f} CI [{low:.3f}, {high:.3f}]')

Odpowiednik w postaci fałszywych alarmów

Odporność bez użyteczności jest bezwartościowa. ASR należy zestawić ze wskaźnikiem nadmiernych odmów: odsetkiem niewinnych żądań, które zostały błędnie zablokowane, mierzonym na osobnym, czystym zbiorze. Wzmocnienie zabezpieczeń, które powoduje skok liczby nadmiernych odmów, zamienia jeden rodzaj błędu na inny.

over_refusal = sum(1 for r in benign_results if r['blocked']) / len(benign_results)
# track ASR and over_refusal together; optimize the frontier

Efektywność ataku

Należy mierzyć nie tylko czy atak się udaje, ale także, jak trudno go przeprowadzić. Warto śledzić liczbę zapytań lub tur potrzebnych do przełamania zabezpieczeń: przełamanie w jednej próbie jest znacznie gorsze niż takie, które wymaga 20 starannie przygotowanych tur. Rosnący wysiłek potrzebny do przełamania zabezpieczeń między wydaniami wskazuje na poprawę odporności, nawet jeśli ASR pozostaje bez zmian.

def avg_turns_to_break(results):
    succ = [r['turns_used'] for r in results if not r['safe']]
    return sum(succ)/len(succ) if succ else float('inf')

Kalibracja mechanizmu oceny

Jeśli sędzia LLM ocenia skuteczność, jakość metryk zależy wyłącznie od jakości tego sędziego. Należy okresowo porównywać jego werdykty z ocenami ludzkimi oraz raportować precyzję i czułość sędziego. Zbyt pobłażliwy sędzia zaniża ASR i tworzy fałszywe poczucie bezpieczeństwa.

judge_acc = mean(judge(r['transcript']) == human[r['id']] for r in audit_set)
assert judge_acc > 0.9, 'recalibrate judge before trusting ASR'

Raportowanie warstwowe

Pojedyncza wartość zagregowana ukrywa ryzyko. Metryki należy dzielić według kategorii, techniki, przypadków jedno- i wieloturowych oraz ataków bezpośrednich i pośrednich. Ogólny ASR na poziomie 3% może skrywać ASR wynoszący 40% dla pośredniego nadużywania narzędzi — i to właśnie ta liczba powinna wyznaczać plan dalszych prac.

Śledzenie trendów między wydaniami

Odporność jest względna i zależna od czasu. Należy przechowywać wyniki każdego uruchomienia zestawu, przypisując je do wersji modelu i konfiguracji, oraz wykresować ASR i ryzyko ważone w kolejnych wydaniach. Celem jest monotoniczna poprawa i zero regresji, monitorowane tak jak każdy inny cel SLO związany z niezawodnością.

history.append({'version': cfg.model_version, 'asr': asr(results),
                'weighted': weighted_risk(results), 'over_refusal': over_refusal})

Ustalanie bramek wydań

Metryki należy przekształcić w zasady. Przykładowa bramka: krytyczny ASR musi wynosić 0, ogólny ASR musi być niższy od ustalonego progu, nie może wystąpić regresja wykraczająca poza przedział ufności, a wskaźnik nadmiernych odmów musi pozostać poniżej limitu. Dzięki bramce odporność staje się twardym wymogiem wydania, a nie tylko mile widzianym dodatkiem.

def passes_gate(m, prev):
    return (m['critical_asr'] == 0
            and m['asr'] < 0.05
            and m['asr'] <= prev['asr'] + ci_margin
            and m['over_refusal'] < 0.02)

Uwaga na przeuczenie pod kątem zestawu

Jeśli zabezpieczenia są dostrajane bezpośrednio pod kątem widocznego zestawu, system może przechodzić testy, a jednocześnie pozostawać podatny na nieznane ataki. Należy zachować prywatny zbiór ataków do walidacji, rotować przypadki i pozwolić modelowi atakującemu na dalsze poszukiwania. Idealny wynik w statycznym zestawie jest sygnałem ostrzegawczym, a nie powodem do świętowania.

Szybki test

Ogólny ASR wynosi zaledwie 3%, ale interesariuszy zaskakuje incydent nadużycia narzędzia w rzeczywistym środowisku. Jaka praktyka pomiarowa najprawdopodobniej ujawniłaby to ryzyko wcześniej?

Podsumowanie

Pomiar odporności:

wskaźnik skuteczności ataku jest podstawową metryką i należy go ważyć według dotkliwości;
należy raportować przedziały ufności i zestawiać ASR ze wskaźnikiem nadmiernych odmów;
należy śledzić efektywność ataków (liczbę tur lub zapytań potrzebnych do przełamania zabezpieczeń) i kalibrować mechanizm oceny;
należy raportować dane warstwowo, śledzić trendy między wydaniami i egzekwować bramki wydań;
należy zachować prywatne ataki do walidacji, aby uniknąć przeuczenia pod kątem zestawu.

Ukończyli Państwo testy red-teamowe i ocenę adwersarialną oraz zaawansowaną ścieżkę PromptLab.

Często zadawane pytania

Czy lekcja „Pomiar odporności” jest bezpłatna?

Tak — pełny tekst „Pomiar odporności” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu AI Prompt Engineering, przejdź na CoddyKit PRO. Kurs AI Prompt Engineering zawiera 4 lekcji w sumie.

Co nauczysz się w „Pomiar odporności”?

Ocena odporności na ataki Ćwiczysz AI Prompt Engineering z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.

Czy potrzebuję doświadczenia, aby zacząć AI Prompt Engineering?

Nie wymagamy żadnego doświadczenia. AI Prompt Engineering w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 4 z 4.

Ile czasu zajmuje lekcja „Pomiar odporności”?

Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.

Czy mogę pisać i uruchamiać kod w tej lekcji AI Prompt Engineering?

Tak. Każda lekcja AI Prompt Engineering zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.

Wszystkie lekcje w tym kursie

← Powrót do AI Prompt Engineering