Red teaming tervezése nagy nyelvi modellekhez (LLM-ekhez) és alkalmazásaikhoz

Ez az útmutató néhány lehetséges stratégiát kínál a red teaming for responsible AI (RAI) kockázatok beállításának és kezelésének megtervezéséhez a nagy nyelvi modell (LLM) termék életciklusa során.

A red teaming kifejezés korábban a biztonsági rések tesztelésére irányuló rendszeres támadásokat ismertette. Az LLM-k növekedésével a kifejezés túlnyúlt a hagyományos kiberbiztonságon, és a gyakori használatban fejlődött, hogy leírják az AI-rendszerek tesztelésének, tesztelésének és támadásának számos típusát. Az LLM-ekkel a jóindulatú és a rosszindulatú használat potenciálisan káros kimeneteket eredményezhet, amelyek számos formában lehetnek, beleértve a káros tartalmakat, például a gyűlöletbeszédet, az erőszak felbujtását vagy dicsőítését vagy a szexuális tartalmakat.

A red teaming ajánlott eljárás a rendszerek és funkciók LLM-eket használó felelős fejlesztésében. Bár nem helyettesíti a szisztematikus mérési és kárenyhítési munkát, a vörös csapattagok segítenek feltárni és azonosítani az ártalmakat, és lehetővé tenni a mérési stratégiákat a mérséklés hatékonyságának ellenőrzéséhez.

Bár a Microsoft vörös csapatépítő gyakorlatokat végzett, és biztonsági rendszereket (beleértve a tartalomszűrőket és más kockázatcsökkentési stratégiákat) vezetett be az Azure OpenAI-szolgáltatásmodelljeihez (lásd a felelős AI-eljárások áttekintését), az egyes LLM-alkalmazások kontextusa egyedi lesz, és a következő célokra is érdemes vörös csapatokat végeznie:

• Tesztelje az LLM alapmodellt, és állapítsa meg, hogy vannak-e hiányosságok a meglévő biztonsági rendszerekben az alkalmazás kontextusának megfelelően.

• A meglévő alapértelmezett szűrők vagy kárenyhítési stratégiák hibáinak azonosítása és elhárítása.

• Visszajelzés küldése a hibákról a fejlesztések érdekében.

• Vegye figyelembe, hogy a vörös összevonás nem helyettesíti a szisztematikus mérést. Az ajánlott eljárás a manuális vörös összevonás kezdeti körének elvégzése, mielőtt szisztematikus méréseket végeznénk és kockázatcsökkentéseket vezetnénk be. Ahogy fentebb kiemeltük, a vörös RAI-összevonás célja az ártalmak azonosítása, a kockázati felület megismerése és az olyan ártalmak listája, amelyek tájékoztatják a mérendő és enyhítendő tényezőket.

Az alábbiakban bemutatjuk, hogyan kezdheti el és tervezheti meg a vörös összevonási LLM-eket. Az előzetes tervezés kritikus fontosságú a hatékony red teaming gyakorlathoz.

A vörös csapattagok változatos csoportjának összeállítása

Határozza meg a vörös csapattagok ideális összetételét az emberek tapasztalata, demográfiai adatai és szakértelme szempontjából a termék tartományában (például az MI szakértői, a társadalomtudományok és a biztonság területén). Ha például egy csevegőrobotot tervez, amely segít az egészségügyi szolgáltatóknak, az egészségügyi szakértők segíthetnek azonosítani az adott területen jelentkező kockázatokat.

Vörös csapattagok toborzása jóindulatú és támadó gondolkodásmóddal

A biztonsági kockázatok megértéséhez elengedhetetlen, hogy a vörös csapattagok ellenszenves gondolkodásmóddal és biztonsági tesztelési tapasztalattal rendelkeznek, de azok a vörös csapattagok, akik az alkalmazásrendszer szokásos felhasználói, és még nem vettek részt a fejlesztésben, értékes perspektívákat hozhatnak a rendszeres felhasználók által tapasztalt károkkal kapcsolatban.

Piros csapattagok hozzárendelése ártalmakhoz és/vagy termékfunkciókhoz

• Az RAI vörös csapattagjait speciális szakértelemmel rendelheti hozzá bizonyos típusú károk mintavételéhez (például a biztonsági szakértők ki tudják szondázni a kibertámadásokat, a metaadat-kinyerést és a kibertámadásokkal kapcsolatos tartalmakat).

• Több tesztelési kör esetén döntse el, hogy váltson-e piros csapatos feladatokat minden fordulóban, hogy különböző perspektívákat kapjon az egyes ártalmakról, és fenntartsa a kreativitást. Ha feladatokat vált, hagyjon időt a piros csapattagoknak, hogy felgyorsítsák az újonnan hozzárendelt károkra vonatkozó utasításokat.

• A későbbi szakaszokban, amikor az alkalmazás és a felhasználói felülete fejlesztésre kerül, érdemes lehet piros csapattagokat hozzárendelni az alkalmazás bizonyos részeihez (azaz szolgáltatásokhoz), hogy biztosítsa a teljes alkalmazás lefedettségét.

• Gondolja át, hogy mennyi időt és erőfeszítést kell fordítania az egyes vörös csapattagoknak (például a jóindulatú forgatókönyvek teszteléséhez kevesebb időre lehet szükség, mint a támadói forgatókönyvek teszteléséhez).

Hasznos lehet, ha a vörös csapattagokat a következőkkel adhatja meg:

• Törölje a következő utasításokat:
  • A piros csapat adott fordulójának célját és célját ismertető bevezető; a tesztelni kívánt termék és funkciók, valamint azok elérésének módját; milyen típusú problémákat kell tesztelni; a vörös csapattagok fókuszterülete, ha a tesztelés célzottabb; mennyi időt és erőfeszítést kell fordítania minden piros csapattagnak a tesztelésre; az eredmények rögzítése; és kivel forduljon a kérdésekhez.
• A példák és megállapítások rögzítésére szolgáló fájl vagy hely, beleértve az olyan információkat is, mint például:
  • A példa felszínre lépésének dátuma; a bemeneti/kimeneti pár egyedi azonosítója, ha rendelkezésre áll, reprodukálhatósági célból; a bemeneti kérés; a kimenet leírása vagy képernyőképe.

Mivel egy alkalmazás alapmodellel van fejlesztve, előfordulhat, hogy több különböző rétegben kell tesztelnie:

• Az LLM alapmodellje a biztonsági rendszerével, amely azonosítja azokat a hiányosságokat, amelyeket az alkalmazásrendszer kontextusában esetleg meg kell oldani. (A tesztelés általában API-végponton keresztül történik.)

• Az alkalmazás. (A tesztelés a legjobb megoldás egy felhasználói felületen keresztül.)

• Mind az LLM alapmodellje, mind az alkalmazás, a kockázatcsökkentések előtt és után.

Az alábbi javaslatok segítenek kiválasztani, hogy mit teszteljen a különböző pontokon a piros összevonás során:

• Első lépésként tesztelheti az alapmodellt a kockázati felület megértéséhez, az ártalmak azonosításához és a termék RAI-kockázatcsökkentéseinek fejlesztéséhez.

• Tesztelje a termék verzióit iteratív módon RAI-kockázatcsökkentésekkel és azok nélkül, hogy értékelje az RAI-mérséklések hatékonyságát. (Vegye figyelembe, hogy a manuális piros összevonás nem feltétlenül elegendő értékelés – szisztematikus méréseket is használjon, de csak a manuális piros összevonás első fordulójának befejezése után.)

• A lehető legnagyobb mértékben végezze el az alkalmazás(ok) tesztelését az éles felhasználói felületen, mert ez a leginkább hasonlít a valós használatra.

Az eredmények jelentésekor tisztázza, hogy mely végpontokat használták a teszteléshez. Ha a tesztelés nem termék végponton történt, érdemes lehet újra tesztelni az éles végponton vagy a felhasználói felületen a későbbi fordulókban.

Végezzen nyílt végű tesztelést a károk széles körének feltárásához.

Az RAI vörös csapattagjainak előnye, hogy feltárják és dokumentálják a problémás tartalmakat (ahelyett, hogy konkrét károkat keresnének) lehetővé teszi számukra, hogy kreatívan felfedezzék a problémák széles körét, és vakfoltokat fedjenek fel a kockázati felület megértésében.

Hozzon létre egy listát a nyílt végű tesztelésből származó károkról.

• Érdemes lehet létrehozni a károk listáját definíciókkal és példákkal a károkra.
• Adja meg ezt a listát útmutatóként a vörös csapattagok számára a tesztelés későbbi fordulóiban.

Irányított piros összevonás és iterálás: Folytassa a listában szereplő ártalmak feltárását; új károkat azonosíthat a felszínen.

Ha elérhető, használjon kárlistát, és folytassa az ismert károk és a kockázatcsökkentések hatékonyságának tesztelését. A folyamat során valószínűleg új károkat fog azonosítani. Ezeket integrálhatja a listába, és nyitottnak kell lennie a mérési és kárenyhítési prioritások eltolására az újonnan azonosított károk kezelése érdekében.

Tervezze meg, mely árt az iteratív tesztelés rangsorolásának. Számos tényező tájékoztathatja a rangsorolást, beleértve, de nem kizárólagosan a károk súlyosságát és azt a kontextust, amelyben nagyobb a valószínűsége annak, hogy felszínre kerülnek.

Döntse el, hogy milyen adatokat kell gyűjtenie, és milyen adatok nem kötelezőek.

• Döntse el, hogy a vörös csapattagoknak milyen adatokat kell rögzíteniük (például az általuk használt bemenetet; a rendszer kimenetét; egy egyedi azonosítót, ha vannak ilyenek, a példa későbbi reprodukálásához; és egyéb jegyzeteket).)

• Legyen stratégiai fontosságú a gyűjtött adatokkal, hogy elkerülje a vörös csapattagok túlterheltségét, és ne hagyjon ki kritikus fontosságú információkat.

Struktúra létrehozása adatgyűjtéshez

A megosztott Excel-számolótábla gyakran a legegyszerűbb módszer a piros összevonási adatok gyűjtésére. A megosztott fájl előnye, hogy a vörös csapattagok áttekinthetik egymás példáit, hogy kreatív ötleteket szerezzenek saját tesztelésükhöz, és elkerülhessék az adatok duplikálását.

Tervezze meg, hogy aktív készenléti állapotban legyen, amíg a vörös összevonás folyamatban van

• Készüljön fel arra, hogy segítséget nyújtson a vörös csapattagoknak az utasításokhoz és a hozzáféréssel kapcsolatos problémákhoz.
• Figyelje a számolótábla állapotát, és küldjön időben emlékeztetőket a vörös csapattagoknak.

Jelentésadatok

Rendszeres időközönként megoszt egy rövid jelentést a főbb érdekelt felekkel, amelyek:

1. Felsorolja a leggyakoribb problémákat.

2. A nyers adatokra mutató hivatkozást tartalmaz.

3. A közelgő fordulók tesztelési tervének előzetes verziója.

4. Elismeri a piros csapattagokat.

5. Minden egyéb releváns információt tartalmaz.

Az azonosítás és a mérés megkülönböztetése

A jelentésben mindenképpen tisztázzuk, hogy a vörös RAI-összevonás szerepe a kockázati felület felfedése és megértése, és nem helyettesíti a szisztematikus mérést és a szigorú kockázatcsökkentési munkát. Fontos, hogy az emberek ne értelmezzék a konkrét példákat a kár áthatóságának metrikájaként.

Emellett ha a jelentés problémás tartalmakat és példákat tartalmaz, fontolja meg egy tartalomértesítettség-figyelmeztetést is.

A jelen dokumentumban szereplő útmutatás nem jogi tanácsadásnak szánt és nem értelmezhető. A működési joghatóság különböző szabályozási vagy jogi követelményekkel rendelkezhet, amelyek az AI-rendszerre vonatkoznak. Vegye figyelembe, hogy nem minden javaslat felel meg minden forgatókönyvnek, és ezzel szemben előfordulhat, hogy ezek a javaslatok bizonyos forgatókönyvekhez nem elegendőek.