Planen von Red Teaming für große Sprachmodelle (Large Language Models, LLMs) und deren Anwendungen

Dieser Leitfaden enthält einige potenzielle Planungsstrategien zur Einrichtung und Verwaltung von Red Teaming für Risiken im Zusammenhang mit verantwortungsvoller KI (Responsible AI, RAI) während des LLM-Produktlebenszyklus.

Was ist Red Teaming?

Der Begriff Red Teaming stand in der Vergangenheit für systematische Angriffe beim Testen von Sicherheitsrisiken. Mit dem Aufkommen von LLMs hat sich der Begriff über die herkömmliche Cybersicherheit hinaus erweitert und wird nun allgemein verwendet, um viele Arten von Überprüfungen, Tests und Angriffen von KI-Systemen zu beschreiben. Mit LLMs können sowohl die gutartige als auch die feindselige Nutzung zu potenziell schädlichen Ergebnissen führen, die viele Formen annehmen können, einschließlich schädlicher Inhalte wie Hassrede, Aufstachelung, die Verherrlichung von Gewalt oder sexuelle Inhalte.

Warum ist RAI Red Teaming eine wichtige Methode?

Red Teaming ist eine bewährte Methode bei der verantwortungsvollen Entwicklung von Systemen und Features, die LLMs verwenden. Obwohl es kein Ersatz für systematische Messarbeiten und Entschärfungsmaßnahmen ist, unterstützen „Red Teaming“-Mitglieder dabei, Schäden aufzudecken und zu identifizieren und wiederum Messstrategien zu ermöglichen, um die Wirksamkeit von Risikominderungen zu überprüfen.

Microsoft hat Red Teaming-Übungen durchgeführt und Sicherheitssysteme (einschließlich Inhaltsfiltern und anderen Entschärfungsstrategien) für seine Azure OpenAI Service-Modelle implementiert. (Eine Übersicht über verantwortungsvolle KI finden Sie hier.) Allerdings hat jede LLM-Anwendung ihren eigenen Kontext. Daher sollten auch Sie Red Teaming für folgende Zwecke durchführen:

• Testen des LLM-Basismodells und Ermitteln, ob angesichts des Kontexts Ihrer Anwendung Lücken in den vorhandenen Sicherheitssystemen vorhanden sind

• Mängel in den vorhandenen Standardfiltern oder Entschärfungsstrategien zu identifizieren und zu entschärfen.

• Bereitstellen von Feedback zu Fehlern, um Verbesserungen zu ermöglichen

• Beachten Sie, dass Red Teaming kein Ersatz für systematische Messungen ist. Eine bewährte Methode besteht darin, zunächst eine erste Red Teaming-Runde abzuschließen, bevor systematische Messungen durchgeführt und Entschärfungen implementiert werden. Wie bereits erwähnt, besteht das Ziel von RAI Red Teaming darin, Schäden zu identifizieren, die Risikooberfläche zu verstehen und die Liste der Schäden zu erarbeiten, die Aufschluss darüber geben kann, was gemessen und behandelt werden muss.

Hier erfahren Sie, wie Sie mit dem Red Teaming-Prozess für Ihre LLMs beginnen und den Prozess planen können. Eine vorausschauende Planung ist für eine produktive „Red Teaming“-Übung von entscheidender Bedeutung.

Vor dem Testen

Planung: Wer führt die Tests durch?

Stellen Sie eine breit gefächerte Gruppe von Red Teaming-Mitgliedern zusammen.

Bestimmen Sie die ideale Zusammensetzung der Red Teaming-Mitglieder in Bezug auf die Erfahrung, demografischen Daten und Kenntnisse in verschiedenen Fachrichtungen (z. B. Expert*innen in den Bereichen KI, Sozialwissenschaften und Sicherheit) für die Domäne Ihres Produkts. Wenn Sie beispielsweise einen Chatbot entwerfen, der Gesundheitsdienstleister unterstützen soll, können medizinische Experten dabei helfen, Risiken in dieser Domäne zu identifizieren.

Rekrutieren Sie Red Teaming-Mitglieder, die als Befürworter*innen oder Gegner*innen fungieren.

„Red Teaming“-Mitglieder mit einer feindseligen Denkweise und Erfahrung in Sicherheitstests sind von entscheidender Bedeutung für das Erkennen von Sicherheitsrisiken. Aber auch „Red Teaming“-Mitglieder, die gewöhnliche Benutzer Ihres Anwendungssystems sind und nicht an der Entwicklung beteiligt waren, können wertvolle Perspektiven auf Schäden einbringen, die normale Benutzer betreffen können.

Weisen Sie Red Teaming-Mitglieder Schäden und/oder Produktfeatures zu.

• Weisen Sie RAI Red Teaming-Mitglieder mit spezifischem Fachwissen zu, um bestimmte Arten von Schäden zu untersuchen. So können beispielsweise fachliche Ansprechpartner*innen aus dem Sicherheitsbereich nach Jailbreaks sowie nach der Extraktion von Meta-Eingabeaufforderungen und nach Inhalten im Zusammenhang mit Cyberangriffen suchen.

• Entscheiden Sie bei Verwendung mehrerer Testrunden, ob in jeder Runde die Zuweisungen von Red Teaming-Mitgliedern geändert werden sollen, um unterschiedliche Perspektiven für jeden Schaden zu erhalten und die Kreativität zu wahren. Wenn Sie die Zuweisungen ändern, lassen Sie den Red Teaming-Mitgliedern genügend Zeit, um sich bei den Anweisungen für ihren neu zugewiesenen Schaden auf den neuesten Stand zu bringen.

• Wenn in späteren Phasen die Anwendung und ihre Benutzeroberfläche entwickelt werden, empfiehlt es sich gegebenenfalls, Red Teaming-Mitglieder bestimmten Teilen der Anwendung (sprich: Features) zuzuweisen, um die Abdeckung der gesamten Anwendung sicherzustellen.

• Überlegen Sie, wie viel Zeit und Aufwand die einzelnen Red Teaming-Mitglieder investieren sollen. (Mitglieder, die positive Szenarien testen, benötigen möglicherweise weniger Zeit als Mitglieder, die negative Szenarien testen.)

Es kann hilfreich sein, Red Teaming-Mitglieder Folgendes bereitzustellen:

• Klare Anweisungen, die Folgendes umfassen können:
  • Eine Einführung, die den Zweck und das Ziel der jeweiligen Red Teaming-Runde beschreibt, das zu testende Produkt und die zu testenden Features sowie Informationen zum Zugriff auf das Produkt und die Features, die Arten von Problemen, auf die getestet werden soll, Fokusbereiche der Red Teaming-Mitglieder (im Falle zielgerichteter Tests), die Zeit und Arbeit, die jedes Red Teaming-Mitglied für die Tests investieren soll, die Vorgehensweise zum Erfassen der Ergebnisse sowie Ansprechpartner*innen für Fragen
• Eine Datei oder ein Speicherort für die Erfassung ihrer Beispiele und Ergebnisse, einschließlich Informationen wie:
  • Das Datum, an dem ein Beispiel entdeckt wurde, ein eindeutiger Bezeichner für das Eingabe-/Ausgabepaar (sofern verfügbar), um die Reproduktion zu ermöglichen, sowie die Eingabeaufforderung und eine Beschreibung oder ein Screenshot der Ausgabe

Planung: Was soll getestet werden?

Da eine Anwendung mit einem Basismodell entwickelt wird, müssen Sie möglicherweise auf verschiedenen Ebenen testen:

• Das LLM-Basismodell mit seinem Sicherheitssystem, um alle Lücken zu identifizieren, die möglicherweise im Kontext Ihres Anwendungssystems behoben werden müssen. (Der Test erfolgt in der Regel über einen API-Endpunkt.)

• Ihre Anwendung. (Zum Testen wird am besten eine Benutzeroberfläche verwendet.)

• Sowohl das LLM-Basismodell als auch Ihre Anwendung, bevor die Entschärfungen implementiert wurden.

Die folgenden Empfehlungen unterstützen Sie bei der Entscheidung, was beim Red Teaming an verschiedenen Punkten getestet werden soll:

• Sie können mit dem Testen des Basismodells beginnen, um die Risikooberfläche zu verstehen, Schäden zu identifizieren und die Entwicklung von RAI-Entschärfungen für Ihr Produkt zu leiten.

• Testen Sie Versionen Ihres Produkts iterativ mit und ohne RAI-Entschärfungen, um die Wirksamkeit von RAI-Entschärfungen zu bewerten. (Hinweis: Manuelles Red Teaming reicht möglicherweise nicht aus. Verwenden Sie daher auch systematische Messungen – aber erst nach Abschluss einer ersten manuellen Red Teaming-Runde.)

• Testen Sie Anwendungen möglichst über die Produktionsbenutzeroberfläche, da dies der tatsächlichen Nutzung am nächsten kommt.

Machen Sie beim Melden von Ergebnissen deutlich, welche Endpunkte zum Testen verwendet wurden. Wenn Tests mit einem anderen Endpunkt als dem Produkt durchgeführt wurden, sollte bei zukünftigen Runden der Produktionsendpunkt oder die Produktionsbenutzeroberfläche verwendet werden.

Planung: Wie soll getestet werden?

Führen Sie offene Tests durch, um ein breites Spektrum an Schäden zu entdecken.

Der Vorteil von RAI-Red Teaming-Mitgliedern, die problematische Inhalte untersuchen und dokumentieren (anstatt sie zu bitten, Beispiele für spezifische Schäden zu finden), besteht darin, dass sie kreativ eine Vielzahl von Problemen untersuchen und Schwachpunkte bei Ihrem Verständnis der Risikooberfläche aufdecken können.

Erstellen Sie auf der Grundlage der offenen Tests eine Liste von Schäden.

• Erstellen Sie ggf. eine Liste von Schäden mit Definitionen und Beispielen.
• Stellen Sie diese Liste in späteren Testrunden als Orientierungshilfe für Red Teaming-Mitglieder bereit.

Führen Sie zielgerichtetes Red Teaming und weitere Durchläufe durch: Fahren Sie mit der Suche nach Schäden in der Liste fort, und ermitteln Sie neue Schäden, die zutage treten.

Verwenden Sie eine Liste mit Schäden (falls verfügbar), testen Sie weiter auf bekannte Schäden, und überprüfen Sie die Wirksamkeit Ihrer Entschärfungen. Dabei stoßen Sie wahrscheinlich auch auf neue Schäden. Nehmen Sie diese in die Liste auf, und seien Sie offen für die Verschiebung von Mess- und Entschärfungsprioritäten, um die neu identifizierten Schäden zu behandeln.

Planen Sie, welche Schäden für iterative Tests priorisiert werden sollen. Mehrere Faktoren können Ihre Priorisierung beeinflussen – beispielsweise der Schweregrad der Schäden und der Kontext, in dem ihr Auftreten wahrscheinlicher ist.

Planung: Wie sollen Daten erfasst werden?

Entscheiden Sie, welche Daten Sie sammeln müssen und welche Daten optional sind.

• Entscheiden Sie, welche Daten die Red Teaming-Mitglieder erfassen müssen (z. B. die verwendete Eingabe, die Ausgabe des Systems, eine ggf. verfügbare eindeutige ID, um das Beispiel später zu reproduzieren, sowie andere Hinweise).

• Gehen Sie bei der Entscheidung, welche Daten gesammelt werden müssen, strategisch vor, um sicherzustellen, dass einerseits die Red Teaming-Mitglieder nicht überlastet werden und andererseits keine kritischen Informationen verloren gehen.

Erstellen Sie eine Struktur für die Datensammlung.

Eine gemeinsam genutzte Excel-Tabelle ist häufig die einfachste Methode zum Sammeln von Red Teaming-Daten. Eine solche gemeinsam genutzte Datei hat den Vorteil, dass Red Teaming-Mitglieder sich die Beispiele der jeweils anderen Mitglieder ansehen können, um kreative Ideen für ihre eigenen Tests zu gewinnen und die Duplizierung von Daten zu vermeiden.

Während des Tests

Planen Sie während des laufenden Red Teaming-Prozesses ein aktives Standby ein.

• Seien Sie bereit, Red Teaming-Mitglieder mit Anleitungen und bei Zugriffsproblemen zu unterstützen.
• Überwachen Sie den Fortschritt in der Tabelle, Kalkulationstabelle, und senden Sie rechtzeitig Erinnerungen an Red Teaming-Mitglieder.

Nach jeder Testrunde

Melden Sie Daten.

Teilen Sie regelmäßig einen kurzen Bericht mit wichtigen Projektbeteiligten, der folgende Anforderungen erfüllt:

1. Listet die wichtigsten identifizierten Probleme auf

2. Bietet einen Link zu den Rohdaten

3. Enthält eine Vorschau des Testplans für die kommenden Runden

4. Bestätigt Red Teaming-Mitglieder

5. Enthält ggf. weitere relevante Informationen

Unterscheiden Sie zwischen Identifizierung und Messung.

Machen Sie in dem Bericht deutlich, dass RAI Red Teaming dazu dient, die Risikooberfläche zu verdeutlichen und besser zu verstehen, aber kein Ersatz für systematische Messungen und sorgfältige Entschärfungsarbeit ist. Es ist wichtig, bestimmte Beispiele nicht als Metrik für die Verbreitung des zugehörigen Schadens zu interpretieren.

Sollte der Bericht problematische Inhalte und Beispiele enthalten, empfiehlt es sich außerdem gegebenenfalls, eine Inhaltswarnung hinzuzufügen.

Der Leitfaden in diesem Dokument stellt keine rechtliche Beratung dar und darf auch nicht als solche ausgelegt werden. In der Gerichtsbarkeit, in der Sie agieren, können verschiedene behördliche oder rechtliche Anforderungen für Ihr KI-System gelten. Beachten Sie, dass nicht alle hier bereitgestellten Empfehlungen für jedes Szenario geeignet sind und dass die Empfehlungen umgekehrt für einige Szenarien möglicherweise nicht ausreichen.