Rode koppeling plannen voor grote taalmodellen (LLM's) en hun toepassingen
Deze handleiding biedt een aantal mogelijke strategieën voor het plannen van het instellen en beheren van rode koppeling voor verantwoorde AI -risico's (RAI) gedurende de levenscyclus van het grote taalmodel (LLM).
Wat is rode koppeling?
De term rode koppeling heeft in het verleden systematische adversarial aanvallen beschreven voor het testen van beveiligingsproblemen. Met de opkomst van LLM's is de term uitgebreid tot meer dan traditionele cyberbeveiliging en ontwikkeld in gemeenschappelijk gebruik om veel soorten testen, testen en aanvallen van AI-systemen te beschrijven. Met LLM's kan zowel goedaardig als kwaadwillend gebruik potentieel schadelijke uitvoer produceren, die veel vormen kan aannemen, waaronder schadelijke inhoud zoals haatspraak, aansporing of verheerlijking van geweld of seksuele inhoud.
Waarom is RAI red teaming een belangrijke praktijk?
Red Teaming is een best practice in de verantwoorde ontwikkeling van systemen en functies met behulp van LLM's. Hoewel ze geen vervanging zijn voor systematische meet- en beperkingswerkzaamheden, helpen rode teamers bij het ontdekken en identificeren van schade en kunnen ze op hun beurt meetstrategieën inschakelen om de effectiviteit van risicobeperking te valideren.
Hoewel Microsoft rode teamoefeningen heeft uitgevoerd en veiligheidssystemen (inclusief inhoudsfilters en andere risicobeperkingsstrategieën) heeft uitgevoerd voor de Azure OpenAI-servicemodellen (zie dit overzicht van verantwoorde AI-procedures), is de context van elke LLM-toepassing uniek en moet u ook rode teaming uitvoeren voor:
Test het LLM-basismodel en bepaal of er hiaten zijn in de bestaande veiligheidssystemen, gezien de context van uw toepassing.
Identificeer en beperk tekortkomingen in de bestaande standaardfilters of risicobeperkingsstrategieën.
Feedback geven over fouten om verbeteringen aan te brengen.
Houd er rekening mee dat rode koppeling geen vervanging is voor systematische meting. Een best practice is om een eerste ronde van handmatige rode koppeling te voltooien voordat systematische metingen worden uitgevoerd en oplossingen worden geïmplementeerd. Zoals hierboven is gemarkeerd, is het doel van RAI rode koppeling om schade te identificeren, het risicooppervlak te begrijpen en de lijst met schades te ontwikkelen die kunnen informeren wat er moet worden gemeten en verzacht.
Hier ziet u hoe u aan de slag kunt gaan en uw proces van rode team-LLM's kunt plannen. Het plannen van de planning is essentieel voor een productieve rode teamoefening.
Voordat u gaat testen
Plan: Wie voert de test uit
Een diverse groep rode teamers samenstellen
Bepaal de ideale samenstelling van rode teamers in termen van de ervaring van mensen, demografische gegevens en expertise in verschillende disciplines (bijvoorbeeld experts in AI, sociale wetenschappen, beveiliging) voor het domein van uw product. Als u bijvoorbeeld een chatbot ontwerpt om zorgverleners te helpen, kunnen medische experts helpen bij het identificeren van risico's in dat domein.
Rekruteren rode teamers met zowel goedaardige als adversarial mindsets
Het hebben van rode teamers met een adversarial mindset en beveiligingstestervaring is essentieel voor het begrijpen van beveiligingsrisico's, maar rode teamers die gewone gebruikers van uw toepassingssysteem zijn en die niet betrokken zijn bij de ontwikkeling, kunnen waardevolle perspectieven opleveren op schade die gewone gebruikers kunnen tegenkomen.
Rode teamers toewijzen aan schadelijke en/of productfuncties
Wijs RAI rode teamers met specifieke expertise toe om te onderzoeken op specifieke soorten schade (bijvoorbeeld experts op het gebied van beveiliging kunnen onderzoeken op jailbreaks, metapromptextractie en inhoud met betrekking tot cyberaanvallen).
Voor meerdere testrondes moet u beslissen of u in elke ronde rode teamertoewijzingen wilt overschakelen om diverse perspectieven te krijgen op elke schade en creativiteit te behouden. Als u van opdracht wisselt, kunt u tijd geven voor rode teamers om de instructies voor hun zojuist toegewezen schade te volgen.
In latere fasen, wanneer de toepassing en de gebruikersinterface zijn ontwikkeld, kunt u rode teamers toewijzen aan specifieke onderdelen van de toepassing (bijvoorbeeld functies) om de dekking van de hele toepassing te garanderen.
Overweeg hoeveel tijd en moeite elke rode teamer moet besteden (bijvoorbeeld die tests voor goedaardige scenario's hebben mogelijk minder tijd nodig dan die voor adversarial scenario's).
Het kan handig zijn om rode teamers te voorzien van:
- Duidelijke instructies die kunnen bestaan uit:
- Een inleiding met een beschrijving van het doel en doel van de gegeven ronde rode koppeling; het product en de functies die worden getest en hoe ze kunnen worden gebruikt; op welke soorten problemen moet worden getest; de focusgebieden van rode teamers, als de test gerichter is; hoeveel tijd en moeite elke rode teamer moet besteden aan het testen; hoe resultaten te registreren; en met wie u contact moet opnemen met vragen.
- Een bestand of locatie voor het vastleggen van voorbeelden en bevindingen, waaronder informatie zoals:
- De datum waarop een voorbeeld werd weergegeven; een unieke id voor het invoer-/uitvoerpaar, indien beschikbaar, voor reproduceerbaarheidsdoeleinden; de invoerprompt; een beschrijving of schermopname van de uitvoer.
Plan: Wat te testen
Omdat een toepassing is ontwikkeld met behulp van een basismodel, moet u mogelijk op verschillende lagen testen:
Het LLM-basismodel met het bijbehorende veiligheidssysteem om eventuele hiaten te identificeren die mogelijk moeten worden aangepakt in de context van uw toepassingssysteem. (Testen wordt meestal uitgevoerd via een API-eindpunt.)
Uw toepassing. (Testen wordt het beste uitgevoerd via een gebruikersinterface.)
Zowel het LLM-basismodel als uw toepassing, vóór en na de beperking zijn geïmplementeerd.
Met de volgende aanbevelingen kunt u kiezen wat u op verschillende punten wilt testen tijdens rode koppeling:
U kunt beginnen met het testen van het basismodel om inzicht te hebben in het risicooppervlak, schade te identificeren en de ontwikkeling van RAI-risicobeperking voor uw product te begeleiden.
Test versies van uw product iteratief met en zonder RAI-risicobeperking om de effectiviteit van RAI-risicobeperking te beoordelen. (Opmerking: handmatige rode koppeling is mogelijk niet voldoende beoordeling: gebruik ook systematische metingen, maar pas na het voltooien van een eerste ronde handmatige rode koppeling.)
Voer zo veel mogelijk tests uit van toepassingen in de productiegebruikersinterface, omdat dit het meest lijkt op het werkelijke gebruik.
Wanneer u resultaten rapporteert, moet u duidelijk maken welke eindpunten zijn gebruikt voor het testen. Wanneer het testen is uitgevoerd in een ander eindpunt dan het product, kunt u overwegen om in toekomstige rondes opnieuw te testen op het productie-eindpunt of de gebruikersinterface.
Plan: Testen
Voer open-end tests uit om een breed scala aan schade te ontdekken.
Het voordeel van RAI rode teamers die eventuele problematische inhoud verkennen en documenteren (in plaats van hen te vragen om voorbeelden van specifieke schade te vinden) stelt hen in staat om creatief een breed scala aan problemen te verkennen en blinde vlekken te ontdekken in uw begrip van het risicooppervlak.
Maak een lijst met schadelijke effecten op basis van de open-end test.
- Overweeg een lijst met schadelijke effecten te maken, met definities en voorbeelden van de schade.
- Geef deze lijst op als richtlijn voor rode teamers in latere testrondes.
Begeleide rode koppeling uitvoeren en herhalen: Doorgaan met onderzoeken op schade in de lijst; nieuwe schade aan het oppervlak identificeren.
Gebruik indien beschikbaar een lijst met schades en blijf testen op bekende schade en de effectiviteit van hun risicobeperking. In het proces zult u waarschijnlijk nieuwe schade identificeren. Integreer deze in de lijst en wees open voor het verschuiven van meet- en beperkingsprioriteiten om de zojuist geïdentificeerde schade aan te pakken.
Plan welke schadelijke gevolgen hebben voor iteratieve tests. Verschillende factoren kunnen uw prioriteitsaanduiding informeren, waaronder, maar niet beperkt tot, de ernst van de schade en de context waarin ze waarschijnlijker worden weergegeven.
Plan: Gegevens vastleggen
Bepaal welke gegevens u moet verzamelen en welke gegevens optioneel zijn.
Bepaal welke gegevens de rode teamers moeten opnemen (bijvoorbeeld de invoer die ze hebben gebruikt; de uitvoer van het systeem; een unieke id, indien beschikbaar, om het voorbeeld in de toekomst te reproduceren; en andere notities.)
Wees strategisch met welke gegevens u verzamelt om overweldigende rode teamers te voorkomen, terwijl u geen kritieke informatie mist.
Een structuur maken voor gegevensverzameling
Een gedeeld Excel-spreadsheet is vaak de eenvoudigste methode voor het verzamelen van rode teamgegevens. Een voordeel van dit gedeelde bestand is dat rode teamers elkaars voorbeelden kunnen bekijken om creatieve ideeën te verkrijgen voor hun eigen tests en duplicatie van gegevens te voorkomen.
Tijdens het testen
Plannen om actief stand-by te zijn terwijl rode teaming wordt uitgevoerd
- Wees voorbereid om rode teamers te helpen met instructies en toegangsproblemen.
- Bewaak de voortgang van het werkblad en stuur tijdige herinneringen naar rode teamers.
Na elke testronde
Rapportgegevens
Deel een kort rapport over een regelmatig interval met belangrijke belanghebbenden die:
Een lijst met de belangrijkste geïdentificeerde problemen.
Biedt een koppeling naar de onbewerkte gegevens.
Bekijk een voorbeeld van het testplan voor de komende rondes.
Erkent rode teamers.
Biedt alle andere relevante informatie.
Onderscheid maken tussen identificatie en meting
Zorg ervoor dat u in het verslag duidelijk maakt dat de rol van RAI rode koppeling bestaat uit het blootleggen en begrijpen van het risicooppervlak en geen vervanging is voor systematische meting en strenge beperkingswerkzaamheden. Het is belangrijk dat mensen specifieke voorbeelden niet interpreteren als een metrische waarde voor de pervasiviteit van die schade.
Als het rapport problematische inhoud en voorbeelden bevat, kunt u ook een inhoudswaarschuwing opnemen.
De richtlijnen in dit document zijn niet bedoeld en mogen niet worden geïnterpreteerd als juridisch advies. De jurisdictie waarin u werkt, kan verschillende wettelijke of wettelijke vereisten hebben die van toepassing zijn op uw AI-systeem. Houd er rekening mee dat niet al deze aanbevelingen geschikt zijn voor elk scenario en, omgekeerd, deze aanbevelingen mogelijk onvoldoende zijn voor sommige scenario's.