Command R 08-2024 und seine Sicherheitsmodi: Welche Kontrolle sie bieten und was Sie testen sollten

Was safety_mode steuert – und was nicht

Command R 08-2024 ist eine Version des Cohere-Modells, die anhand der Modellbezeichnung command-r-08-2024 identifiziert wird. Bei Aufrufen der Chat-Endpunkte von Cohere ermöglicht der Parameter safety_mode die Auswahl zwischen Modi, die die in die Anfrage aufgenommenen Sicherheitsanweisungen verändern. Anders gesagt: Die Einstellung beeinflusst, wie das Modell während der Interaktion angeleitet wird. Sie ist weder eine unabhängige Zertifizierung des Modells noch eine Garantie dafür, dass eine Anwendung sicher ist.

Diese Unterscheidung ist in der Praxis wichtig. Ein akzeptables Ergebnis bei einem einfachen Test beschreibt nur die konkrete Kombination aus Modell, Endpunkt, Parametern und Anweisungen. Daraus folgt nicht, dass eine Anwendung adversarialen Eingaben standhält, nicht vertrauenswürdige Dokumente korrekt behandelt oder sämtliche schädlichen Ausgaben verhindert. Solche Eigenschaften müssen am Gesamtsystem geprüft werden, ergänzt durch geeignete, dem jeweiligen Risiko entsprechende Produktkontrollen.

Die verfügbare Dokumentation des Anbieters sollte nicht als Beleg dafür verstanden werden, dass ein Modus alle problematischen Inhalte ausschließt. Die Modellkarte liefert Kontext zu Sicherheitsbewertungen und Einschränkungen, belegt aber nicht die Wirksamkeit jedes Modus für command-r-08-2024. Beschreiben Sie die Modi deshalb besser als eine zu evaluierende Konfigurationsoption und nicht als vollständige Schutzmaßnahme.

STRICT, CONTEXTUAL und NONE: Unterschiede und Bezeichnungen je Endpunkt

In der Referenz für Chat V1 sind die Werte STRICT, CONTEXTUAL und NONE dokumentiert; dort ist safety_mode als Beta gekennzeichnet. Die aktuelle Referenz für Chat V2 führt STRICT, CONTEXTUAL und OFF auf. NONE und OFF sind also Bezeichnungen, die in unterschiedlichen Referenzen vorkommen. Gehen Sie nicht davon aus, dass sie innerhalb eines einzelnen Aufrufs austauschbare Werte sind: Prüfen Sie vor der Konfiguration einer Integration die Spezifikation des tatsächlich verwendeten Endpunkts.

Cohere stellte die Modi historisch als unterschiedliche Abstufungen der Sicherheitsanleitung vor. STRICT priorisiert eine strengere Anwendung dieser Anweisungen; CONTEXTUAL wendet sie unter Berücksichtigung des Anfragekontexts an; NONE steht für die Option, bei der dieses vom Modus hinzugefügte Anweisungspaket nicht eingesetzt wird. Das bedeutet nicht, dass NONE das Modell in ein System ohne jeglichen Schutz verwandelt: Laut Ankündigung des Anbieters lassen sich bestimmte Schutzmaßnahmen nicht deaktivieren.

Der Zweck von CONTEXTUAL besteht darin, Sicherheit nicht auf eine mechanische Reaktion auf einzelne Wörter zu reduzieren. Der Name allein belegt jedoch nicht, dass das Modell stets richtig zwischen einer legitimen und einer schädlichen Anfrage unterscheidet. Ein Team sollte dies anhand von Beispielen aus dem eigenen Einsatzgebiet überprüfen – einschließlich Fällen, bei denen eine Unterscheidung tatsächlich schwierig ist.

Die Beta-Kennzeichnung von V1 ist für das Änderungsmanagement relevant: Sie spricht dafür, die Dokumentation regelmäßig zu prüfen und Tests vor einer Aktualisierung der Integration zu wiederholen. Die V2-Referenz führt ihre eigenen Werte auf. Die bereitgestellten Quellen klären aber nicht hinreichend, ob der Beta-Status von V1 fortbesteht oder ob die Verfügbarkeitsdetails in allen Bereitstellungskanälen identisch sind. Übertragen Sie den Status eines Endpunkts daher nicht automatisch auf den anderen.

Die Einschränkung für tools und documents verändert, was ein Test belegt

Die Chat-V1-Referenz dokumentiert, dass safety_mode nicht zusammen mit tools, tool_results und documents verwendet werden kann. Die Referenz für Chat V2 weist ebenfalls auf eine Einschränkung bei der Kombination mit tools und documents hin. Für Teams, die Retrieval-Augmented Generation (RAG) oder Tool-Aufrufe einsetzen, ist das eine operative Grenze: Ein isolierter Test des Modus sollte nicht als direkter Nachweis für das Verhalten des vollständigen Ablaufs dargestellt werden.

Aus der dokumentierten Inkompatibilität folgt weder, dass Tools oder Dokumente unsicher sind, noch, dass das Modell sie in keiner Konfiguration nutzen kann. Die Referenzen besagen, dass die aufgeführten Parameter in dem dort beschriebenen Aufruf nicht kombiniert werden können. Die Integration muss die vom Endpunkt unterstützte Form einhalten; Komponenten und ihr Zusammenspiel müssen gesondert geprüft werden.

Eine aussagekräftige Evaluation trennt mindestens zwei Fragen. Erstens: Wie antwortet das Modell mit safety_mode in einem unterstützten, kontrollierten Aufruf? Zweitens: Was geschieht in der tatsächlichen Anwendung, wenn Dokumente abgerufen, Tool-Ergebnisse übermittelt oder eigene Anweisungen eingebunden werden? Die Antwort auf die erste Frage ersetzt die Antwort auf die zweite nicht. Außerdem kann abgerufener Text Anweisungen, fehlerhafte Informationen oder schädliche Inhalte enthalten. Die Anwendung sollte ihn als zu bewertenden Inhalt behandeln und nicht als Sicherheitsrichtlinie.

Die bereitgestellten Quellen beschreiben Parameterbeschränkungen in den Referenzen für Chat V1 und Chat V2. Sie führen nicht alle verfügbaren Kombinationen für jeden Bereitstellungskanal auf und erlauben auch nicht die Aussage, dass jeder mit Cohere kompatible Dienst identische Funktionen anbietet. Prüfen Sie vor der Testplanung die für Ihre konkrete Umgebung geltende Spezifikation.

Ein reproduzierbares Prüfverfahren

Bei einem Vergleich müssen Sie vorab festlegen, welches Ergebnis für jeden Testfall als korrekt gilt. Werden die Kriterien erst nach Sichtung der Antworten geändert, besteht die Gefahr, dass am Ende der Modus bevorzugt wird, der die vorherigen Erwartungen bestätigt. Führen Sie einen gekennzeichneten Testsatz samt Begründung für die jeweilige Einstufung und testen Sie jeden Fall mit derselben Modellversion, demselben Endpunkt und denselben Parametern – außer bei der Variable, die Sie vergleichen möchten.

Nehmen Sie erlaubte, aber sensible Anfragen auf: etwa eine präventive Erklärung zu einem Sicherheitsthema, eine Bildungsanfrage zu einem Risikothema oder eine Bitte um Unterstützung, die einen sorgfältigen Ton erfordert. Ergänzen Sie eindeutig schädliche Anfragen gemäß den Richtlinien des Produkts sowie mehrdeutige Fälle, in denen das Modell nachfragen, die Antwort begrenzen oder einen Teil ablehnen sollte. Diese Beispiele dienen dem Aufbau eines eigenen Testsatzes; die Quellen veröffentlichen keinen speziellen Testsatz zur Messung der Modi für Command R 08-2024.

Prüfen Sie sprachliche und formale Varianten: Paraphrasen, Rechtschreibfehler, indirekte Formulierungen und für die Zielgruppe relevante Sprachwechsel. Es reicht nicht, einen einzelnen Fall wortgetreu zu übersetzen, denn beim Wechsel der Sprache kann sich die beabsichtigte Bedeutung verändern. Wenn das Produkt Inhalte in mehreren Sprachen verarbeitet, bewerten Sie jede Sprache mit sprachkundigen Personen oder anhand von Kriterien, die von Fachleuten geprüft wurden.

Wiederholen Sie jeden Testfall mehrmals. Antworten können von einem Durchlauf zum nächsten variieren; eine einzelne Stichprobe reicht nicht aus, um die Konsistenz zu messen. Bewahren Sie die exakten Eingaben, das erwartete Ergebnis, die vollständige Antwort, die Bewertungsentscheidung und den Kontext des Aufrufs auf. Ändern sich Modell, API oder Anweisungen der Anwendung, führen Sie den Testsatz erneut aus und vergleichen Sie die Versionen.

Metriken, die bei der Einordnung der Ergebnisse helfen

Zählen Sie korrekte Ablehnungen: Fälle, die laut Ihren Kriterien abgelehnt werden sollten und auf die das Modell mit einer Ablehnung oder einer sicheren Antwort reagiert hat. Erfassen Sie ebenso falsche Ablehnungen: erlaubte Anfragen, die blockiert oder so stark eingeschränkt wurden, dass sie nicht mehr sinnvoll nutzbar waren. Eine hohe Ablehnungsrate ist für sich genommen kein Beleg für bessere Sicherheit, wenn sie dadurch erreicht wird, dass zahlreiche legitime Aufgaben abgelehnt werden.

Protokollieren Sie auch unsichere Antworten: Fälle, die abgelehnt oder begrenzt werden sollten, bei denen das System aber nicht erlaubte Inhalte geliefert hat. Untersuchen Sie außerdem die Befolgung der Produktanweisungen, die Konsistenz zwischen Wiederholungen und Unterschiede zwischen den Modi. Ist eine Antwort nur teilweise korrekt, sollten Sie vorab definierte Zwischenkategorien verwenden, statt sie künstlich als „bestanden“ oder „abgelehnt“ einzuordnen.

Schlüsseln Sie Ergebnisse nach Anfragetyp, Sprache, Modus und Konfiguration auf. Ein zusammengefasster Durchschnitt kann verbergen, dass das System bei erlaubten sensiblen Fragen anders funktioniert als bei mehrdeutigen Anfragen. Protokollieren Sie bei Abläufen mit Dokumenten oder Tools zusätzlich, welche Inhalte abgerufen, welche Tools aufgerufen und welche Informationen an das Modell zurückgegeben wurden – unter Einhaltung der Datenschutz- und Aufbewahrungsvorgaben Ihrer Organisation.

Metriken liefern Anhaltspunkte für eine Entscheidung, aber kein allgemeingültiges Zertifikat. Eine kleine Stichprobe, ein zu leicht vorhersehbarer Testsatz oder unpräzise Bewertungskriterien können einen falschen Eindruck von Zuverlässigkeit erzeugen. Legen Sie Umfang und Zusammensetzung des Testsatzes, die Zahl der Wiederholungen und Uneinigkeiten bei der Bewertung offen. Sind die Ergebnisse mehrdeutig oder können sie erhebliche Auswirkungen auf Menschen haben, beziehen Sie fachkundige menschliche Prüferinnen und Prüfer ein.

Dokumentieren Sie die Umgebung und behalten Sie externe Kontrollen bei

Damit sich Ergebnisse sinnvoll interpretieren lassen, halten Sie die genaue Modellkennung – einschließlich command-r-08-2024, falls zutreffend –, den Endpunkt, den Wert von safety_mode und das Datum fest. Ergänzen Sie die übrigen Generierungsparameter, System- und Anwendungsanweisungen, die Sprache der Eingabe sowie die Angabe, ob Dokumente, Tools oder Tool-Ergebnisse einbezogen wurden. Datum und Integrationsversion helfen dabei, zu erkennen, wenn zwei scheinbar vergleichbare Durchläufe tatsächlich nicht dieselbe Umgebung verwendet haben.

Die Dokumentation des Anbieters beantwortet nicht alle Fragen zu den hier angesprochenen Bereitstellungen. Insbesondere reichen die verfügbaren Belege nicht aus, um zu bestätigen, ob der Beta-Status von V1 auch für V2 gilt, ob die Kombinationsbeschränkung in allen Kanälen denselben Umfang hat oder ob sich ein Prüfverfahren in allen kompatiblen Umgebungen unverändert reproduzieren lässt. Prüfen Sie diese Punkte in der aktuellen Referenz Ihres Endpunkts und in der tatsächlichen Konfiguration, bevor Sie Ergebnisse einordnen.

Behalten Sie eigene Schutzmaßnahmen bei, auch wenn ein Test für einen Modus spricht. Dazu können die Festlegung erlaubter Verwendungszwecke, Zugriffskontrollen für Tools, Datenvalidierung, Aktionsbegrenzungen, Überwachung, Verfahren zur Reaktion auf Vorfälle und menschliche Prüfung bei Entscheidungen mit hohen Auswirkungen gehören. Welche Kontrollen nötig sind, hängt vom Produkt und seinem Risiko ab. Allein aus dem Namen eines Modus lässt sich keine ausreichende Konfiguration ableiten.

Wählen Sie in der Praxis den Modus, der die Richtlinien Ihrer Anwendung erfüllt und dabei ein für Ihren Einsatzbereich akzeptables Verhältnis zwischen unsicheren Antworten und falschen Ablehnungen bietet – gestützt auf repräsentative Tests. Wenn das Ergebnis von der Verwendung von Dokumenten oder Tools abhängt, bewerten Sie den Produktionsablauf gesondert und bestätigen Sie, welche Parameter der Endpunkt unterstützt. Wiederholen Sie die Evaluation, sobald sich Modell, Endpunkt, Anweisungen oder Architektur ändern. So beruht die Entscheidung zu Command R 08-2024 auf Belegen für das tatsächlich eingesetzte System und nicht allein auf der Bezeichnung eines Modus.

Weiter entdecken

Korrekturen und Transparenz

Wenn du falsche oder veraltete Angaben findest, sende uns die Seite und die zu prüfende Quelle.