Plánování červeného seskupování pro velké jazykové modely (LLM) a jejich aplikace

  • Článek

Tato příručka nabízí některé potenciální strategie plánování nastavení a správy červených seskupování pro zodpovědná rizika AI (RAI) v průběhu životního cyklu produktu ve velkém jazykovém modelu (LLM).

Co je červené seskupování?

Termín červené seskupování má historicky popsaný systematický nežádoucí útoky pro testování ohrožení zabezpečení. S nárůstem LLM se termín rozšířil nad rámec tradiční kybernetické bezpečnosti a vyvinul se ve společném používání, aby popsal mnoho druhů sondování, testování a útoku na systémy AI. U LLM mohou neškodné i nežádoucí použití vést k potenciálně škodlivým výstupům, které mohou mít mnoho forem, včetně škodlivého obsahu, jako je nenávistná řeč, vyvolání nebo vyvolání násilí nebo sexuálního obsahu.

Proč je red RAI důležitou praxí?

Červené seskupování je osvědčeným postupem při zodpovědném vývoji systémů a funkcí pomocí LLM. I když nejsou náhradou za systematickou práci na měření a zmírnění rizik, red teamers pomáhají odhalit a identifikovat škody a zároveň umožnit strategie měření, aby ověřily účinnost zmírnění rizik.

I když Microsoft pro své modely služby Azure OpenAI (viz tento přehled zodpovědných postupů AI) provedl červené seskupování a implementoval bezpečnostní systémy (včetně filtrů obsahu a dalších strategií pro zmírnění rizik) pro své modely azure OpenAI (viz tento přehled zodpovědných postupů AI), kontext každé aplikace LLM bude jedinečný a měli byste také provádět červené seskupování pro:

  • Otestujte základní model LLM a určete, jestli existují mezery v existujících bezpečnostních systémech vzhledem k kontextu vaší aplikace.

  • Identifikujte a zmírněte nedostatky ve stávajících výchozích filtrech nebo strategiích omezení rizik.

  • Poskytněte nám zpětnou vazbu k chybám, abyste mohli vylepšit.

  • Všimněte si, že červené seskupování není náhradou za systematická měření. Osvědčeným postupem je dokončit počáteční kolo ručního červeného seskupování před provedením systematických měření a implementací zmírnění rizik. Jak je uvedeno výše, cílem červeného seskupování RAI je identifikovat škody, pochopit plochu rizika a vyvinout seznam škod, které můžou informovat, co je potřeba měřit a zmírnit.

Tady je postup, jak začít a naplánovat proces červených seskupování LLM. Pokročilé plánování je důležité pro produktivní červené seskupování cvičení.

Před testováním

Plán: Kdo provede testování.

Sestavení různorodé skupiny červených teamerů

Určete ideální složení červených týmů z hlediska zkušeností lidí, demografických údajů a odborných znalostí napříč disciplínami (například odborníky na AI, sociální vědy, zabezpečení) pro doménu vašeho produktu. Pokud například navrhujete chatovacího robota, který pomáhá poskytovatelům zdravotní péče, můžou lékaři pomoct identifikovat rizika v této doméně.

Nábor červených týmů s neškodnými i nežádoucími názory

Pro pochopení bezpečnostních rizik je nezbytné mít červené týmy s nežádoucím myšlením a prostředím pro testování zabezpečení, ale red teamers, kteří jsou běžnými uživateli vašeho aplikačního systému a nebyli zapojeni do vývoje, můžou přinést cenné pohledy na škody, se kterými se můžou setkat běžní uživatelé.

Přiřazení červených teamerů k poškození a/nebo funkcím produktu

  • Přiřaďte červené týmy RAI s konkrétními odbornými znalostmi k sondám konkrétních typů škod (například odborníci na danou problematiku zabezpečení můžou testovat jailbreaky, extrakci meta výzvy a obsah související s kybernetickými útoky).

  • U více kol testování se rozhodněte, jestli chcete v každém kole přepínat červené zadání seskupovacího týmu, abyste získali různorodé pohledy na každou škodu a zachovali kreativitu. Pokud přepnete zadání, umožněte red teamerům zrychlit pokyny pro jejich nově přiřazené škody.

  • V pozdějších fázích, kdy se aplikace a jeho uživatelské rozhraní vyvíjejí, můžete chtít přiřadit červené teamery ke konkrétním částem aplikace (tj. funkcím), aby se zajistilo pokrytí celé aplikace.

  • Zvažte, kolik času a úsilí by měl každý červený teamer vyhradit (například testování neškodných scénářů může potřebovat kratší dobu než testování nežádoucích scénářů).

Může být užitečné poskytnout červeným týmům:

  • Jasné pokyny, které by mohly zahrnovat:
    • Úvod popisující účel a cíl daného kola červeného seskupování; produkt a funkce, které budou testovány a jak k nim přistupovat; jaké druhy problémů, pro které se mají testovat; oblasti zaměření červených týmů, pokud je testování cílenější; kolik času a úsilí by měl každý červený tým strávit na testování; jak zaznamenávat výsledky; a koho kontaktovat s otázkami.
  • Soubor nebo umístění pro zaznamenávání příkladů a zjištění, včetně informací, jako jsou:
    • Datum, kdy byl příklad povrchován; jedinečný identifikátor vstupního/výstupního páru, pokud je k dispozici, pro účely reprodukovatelnosti; vstupní výzva; popis nebo snímek obrazovky s výstupem

Plán: Co otestovat

Vzhledem k tomu, že aplikace je vyvinuta pomocí základního modelu, budete možná muset testovat na několika různých vrstvách:

  • Základní model LLM se svým bezpečnostním systémem, který identifikuje případné mezery, které je potřeba řešit v kontextu vašeho aplikačního systému. (Testování se obvykle provádí prostřednictvím koncového bodu rozhraní API.)

  • Vaše aplikace. (Testování se nejlépe provádí prostřednictvím uživatelského rozhraní.)

  • Základní model LLM i vaše aplikace jsou zavedeny před a po zmírnění rizik.

Následující doporučení vám pomůžou vybrat, co se má testovat v různých bodech během červeného seskupování:

  • Můžete začít testováním základního modelu, abyste porozuměli rizikům, identifikovali škody a provedli vývoj zmírnění rizik rai pro váš produkt.

  • Otestujte verze vašeho produktu iterativním způsobem s omezeními rizik rai a bez něj, abyste posoudili efektivitu zmírnění rizik RAI. (Ruční červené seskupování nemusí být dostatečné – používejte také systematická měření, ale až po dokončení počátečního kola ručního seskupování červených).)

  • Proveďte testování aplikací v produkčním uživatelském rozhraní co nejvíce, protože se nejvíce podobá skutečnému využití.

Při vytváření výsledků vymažte, které koncové body se použily k testování. Po dokončení testování v jiném koncovém bodu než produktu zvažte další testování v produkčním koncovém bodu nebo uživatelském rozhraní v budoucích kolech.

Plán: Testování

Proveďte otevřené testování, abyste odhalili širokou škálu škod.

Výhodou red teamerů RAI, kteří prozkoumávají a dokumentují jakýkoli problematický obsah (místo toho, aby hledali příklady konkrétních škod), jim umožňuje kreativní zkoumání široké škály problémů a odhalení slepých míst ve vašem pochopení rizikové plochy.

Vytvořte seznam škod z otevřeného testování.

  • Zvažte vytvoření seznamu škod s definicemi a příklady škod.
  • Tento seznam uveďte jako vodítko pro červené týmy v pozdějších kolech testování.

Vedení červeného seskupování a iterace: Pokračovat v testování škod v seznamu; identifikovat nové škody na povrchu.

Seznam škod použijte, pokud je k dispozici, a pokračujte v testování známých škod a účinnosti jejich zmírnění. V procesu pravděpodobně identifikujete nové škody. Integrujte je do seznamu a buďte otevřeni pro posun priorit měření a zmírnění rizik, aby se vyřešily nově zjištěné škody.

Naplánujte, které škodí stanovení priorit iterativního testování. Několik faktorů může informovat o stanovení priority, včetně závažnosti škod a kontextu, ve kterém se s větší pravděpodobností zobrazí.

Plán: Jak zaznamenávat data

Rozhodněte se, jaká data potřebujete shromáždit a jaká data jsou volitelná.

  • Rozhodněte se, jaká data budou muset červení členové týmu zaznamenat (například vstup, který použili, výstup systému, jedinečné ID, pokud je k dispozici, pro reprodukci příkladu v budoucnu a další poznámky.)

  • Buďte strategická s tím, jaká data shromažďujete, abyste se vyhnuli zahlcení červených teamerů, a přitom nezmeškáte důležité informace.

Vytvoření struktury pro shromažďování dat

Sdílená excelová tabulka je často nejjednodušší metodou shromažďování červených dat seskupování. Výhodou tohoto sdíleného souboru je, že red teamers si můžou prohlédnout příklady ostatních, aby získali kreativní nápady na vlastní testování a vyhnuli se duplikaci dat.

Během testování

Plánování aktivního pohotovostního režimu, zatímco probíhá seskupování červeným seskupováním

  • Připravte se na pomoc červeným teamerům s pokyny a problémy s přístupem.
  • Sledujte průběh tabulky a posílejte včasné připomenutí červeným týmům.

Po každém kole testování

Data sestavy

Sdílejte krátkou zprávu o pravidelném intervalu s klíčovými zúčastněnými stranami, které:

  1. Uvádí seznam nejčastějších identifikovaných problémů.

  2. Poskytuje odkaz na nezpracovaná data.

  3. Zobrazí náhled testovacího plánu pro nadcházející kola.

  4. Bere na vědomí červené týmy.

  5. Poskytuje všechny další důležité informace.

Rozlišení mezi identifikací a měřením

Ve zprávě nezapomeňte objasnit, že úkolem červeného seskupování RAI je zveřejnit a zvýšit porozumění rizikům a není náhradou za systematická měření a důkladnou práci na zmírnění rizik. Je důležité, aby lidé neinterpretovali konkrétní příklady jako metriku pro trvalost této škody.

Pokud sestava obsahuje problematický obsah a příklady, zvažte také zahrnutí upozornění na obsah.

Pokyny v tomto dokumentu nejsou určeny a neměly by být považovány za poskytování právního poradenství. Jurisdikce, ve které provozujete, může mít různé zákonné nebo právní požadavky, které platí pro váš systém AI. Mějte na paměti, že ne všechna tato doporučení jsou vhodná pro každý scénář a naopak tato doporučení nemusí být pro některé scénáře dostatečná.