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.
Mi az a vörös összevonás?
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.
Miért fontos az RAI piros összevonása?
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.
Tesztelés előtt
Terv: Ki fogja elvégezni a tesztelést
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.
Terv: Mit kell tesztelni?
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.
Terv: Tesztelés
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.
Terv: Adatok rögzítése
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.
A tesztelés során
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.
A tesztelés minden egyes fordulója után
Jelentésadatok
Rendszeres időközönként megoszt egy rövid jelentést a főbb érdekelt felekkel, amelyek:
Felsorolja a leggyakoribb problémákat.
A nyers adatokra mutató hivatkozást tartalmaz.
A közelgő fordulók tesztelési tervének előzetes verziója.
Elismeri a piros csapattagokat.
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.