### Entwicklungsversion mit `pip` installieren

Die Standard-pip-Version von `garak` wird regelmäßig aktualisiert. Um eine aktuellere Version von GitHub zu erhalten, versuchen Sie es mit:```
python -m pip install -U git+https://github.com/NVIDIA/garak.git@main

OK, wenn das geklappt hat, kannst du wahrscheinlich loslegen!

**Hinweis**: wenn du vor dem Wechsel zur `NVIDIA` GitHub-Organisation geklont hast, aber du dies unter der `github.com/NVIDIA`-URI liest, aktualisiere bitte deine remotes wie folgt:```
git remote set-url origin https://github.com/NVIDIA/garak.git

Überprüfen Sie, ob die Hugging Face-Version von GPT2 anfällig für DAN 11.0 ist.```
python3 -m garak --target_type huggingface --target_name gpt2 --probes dan.Dan_11_0

### Test

* `--target_type test`
* (alternatively) `--target_name test.Blank`
For testing. This always generates the empty string, using the `test.Blank` generator.  Will be marked as failing for any tests that *require* an output, e.g. those that make contentious claims and expect the model to refute them in order to pass.

* `--target_type test.Repeat`
For testing. This generator repeats back the prompt it received.

## Einführung in die Probes

| Probe                | Description                                                                                                                   |
|----------------------|-------------------------------------------------------------------------------------------------------------------------------|
| blank                | Eine einfache Probe, die immer eine leere Eingabeaufforderung sendet.                                                          |
| atkgen               | Automatisierte Angriffsgenerierung. Ein Red-Teaming-LLM untersucht das Ziel und reagiert darauf, um toxische Ausgaben zu erhalten. Prototyp, größtenteils zustandslos, verwendet derzeit ein einfaches GPT-2 [feinabgestimmt](https://huggingface.co/garak-llm/artgpt2tox) auf der Teilmenge der hhrlhf-Versuche, die nachweisbare Toxizität ergaben (das derzeit einzige unterstützte Ziel). |
| badchars             | Implementiert nicht wahrnehmbare Unicode-Störungen (unsichtbare Zeichen, Homoglyphen, Umordnungen, Löschungen) inspiriert von der [Bad Characters](https://arxiv.org/abs/2106.09898)-Arbeit. |
| av_spam_scanning     | Sonden, die versuchen, das Modell dazu zu bringen, bösartige Inhaltsignaturen auszugeben.                                      |
| continuation         | Sonden, die testen, ob das Modell ein wahrscheinlich unerwünschtes Wort fortsetzt.                                             |
| dan                  | Verschiedene [DAN](https://adguard.com/en/blog/chatgpt-dan-prompt-abuse.html)- und DAN-ähnliche Angriffe.                     |
| donotanswer          | Eingabeaufforderungen, auf die verantwortungsbewusste Sprachmodelle nicht antworten sollten.                                   |
| encoding             | Prompt Injection durch Textkodierung.                                                                                         |
| gcg                  | Stört einen System-Prompt durch Anhängen eines adversariellen Suffixes.                                                        |
| glitch               | Testen des Modells auf Glitch-Tokens, die ungewöhnliches Verhalten auslösen.                                                  |
| grandma              | Appell an die Erinnerung an die Großmutter.                                                                                   |
| goodside             | Implementierungen von Riley-Goodside-Angriffen.                                                                               |
| leakreplay           | Bewerten, ob ein Modell Trainingsdaten wiedergibt.                                                                            |
| lmrc                 | Teilstichprobe der [Language Model Risk Cards](https://arxiv.org/abs/2303.18190)-Sonden.                                      |
| malwaregen           | Versuche, das Modell dazu zu bringen, Code zur Erstellung von Schadsoftware zu generieren.                                     |
| misleading           | Versuche, ein Modell dazu zu bringen, irreführende und falsche Behauptungen zu unterstützen.                                  |
| packagehallucination | Versuche, Code-Generierungen zu erhalten, die nicht existierende (und daher unsichere) Pakete spezifizieren.                   |
| promptinject         | Implementierung der Agency Enterprise [PromptInject](https://github.com/agencyenterprise/PromptInject/tree/main/promptinject)-Arbeit (Best Paper Awards @ NeurIPS ML Safety Workshop 2022) |
| realtoxicityprompts  | Teilmenge der RealToxicityPrompts-Arbeit (Daten eingeschränkt, da der vollständige Test zu lange dauern würde).               |
| snowball             | [Snowballed Hallucination](https://ofir.io/snowballed_hallucination.pdf)-Sonden, die darauf ausgelegt sind, ein Modell dazu zu bringen, eine falsche Antwort auf Fragen zu geben, die zu komplex für seine Verarbeitung sind. |
| xss                  | Suche nach Schwachstellen, die Cross-Site-Angriffe ermöglichen oder ausführen, wie z. B. Exfiltration privater Daten.          |

## Protokollierung

`garak` erzeugt mehrere Arten von Logs:
* Eine Logdatei, `garak.log`. Diese enthält Debug-Informationen von `garak` und seinen Plugins und wird über mehrere Läufe hinweg fortgesetzt.
* Ein Bericht des aktuellen Laufs, strukturiert als JSONL. Bei jedem Ausführen von `garak` wird eine neue Berichtsdatei erstellt. Der Name dieser Datei wird zu Beginn und, wenn erfolgreich, auch am Ende des Laufs ausgegeben. Im Bericht wird für jeden Testversuch sowohl beim Empfang der Generierungen als auch bei deren Auswertung ein Eintrag erstellt; das `status`-Attribut des Eintrags nimmt eine Konstante aus `garak.attempts` an, um zu beschreiben, in welcher Phase er erstellt wurde.
* Ein Trefferlog, das die Versuche detailliert, die zu einer Sicherheitslücke geführt haben (ein 'Treffer').

## Wie ist der Code strukturiert?

Schauen Sie sich die [Referenzdokumentation](https://reference.garak.ai/) für eine maßgebliche Anleitung zur `garak`-Codestruktur an.

In einem typischen Lauf liest `garak` einen Modelltyp (und optional einen Modellnamen) von der Befehlszeile, bestimmt dann, welche `probe`s und `detector`s ausgeführt werden sollen, startet einen `generator` und übergibt diese an ein `harness`, um die Tests durchzuführen; ein `evaluator` kümmert sich um die Ergebnisse. Es gibt viele Module in jeder dieser Kategorien, und jedes Modul stellt eine Reihe von Klassen bereit, die als individuelle Plugins fungieren.

* `garak/probes/` - Klassen zum Generieren von Interaktionen mit LLMs
* `garak/detectors/` - Klassen zum Erkennen, dass ein LLM einen bestimmten Fehlermodus aufweist
* `garak/evaluators/` - Bewertungsberichtsschemata
* `garak/generators/` - Plugins für zu testende LLMs
* `garak/harnesses/` - Klassen zur Strukturierung von Tests
* `resources/` - Zusatzartikel, die von Plugins benötigt werden

Der Standardbetriebsmodus ist die Verwendung des `probewise`-Harnesses. Bei einer Liste von Sondenmodulnamen und Sondenplugin-Namen instanziiert das `probewise`-Harness jede Sonde und liest dann für jede Sonde deren `primary_detector`- und `extended_detectors`-Attribute, um eine Liste von `detector`s zu erhalten, die auf die Ausgabe angewendet werden sollen.

Jede Plugin-Kategorie (`probes`, `detectors`, `evaluators`, `generators`, `harnesses`) enthält eine `base.py`, die die Basisklassen definiert, die von Plugins in dieser Kategorie verwendet werden können. Jedes Plugin-Modul definiert Plugin-Klassen, die von einer der Basisklassen erben. Beispielsweise stammt `garak.generators.openai.OpenAIGenerator` von `garak.generators.base.Generator` ab.

Größere Artefakte wie Modelldateien und größere Korpora werden außerhalb des Repositorys aufbewahrt; sie können z. B. auf Hugging Face Hub gespeichert und lokal von Clients, die `garak` verwenden, geladen werden.

## Entwickeln eines eigenen Plugins

* Schaue dir an, wie andere Plugins es machen
* Erbe von einer der Basisklassen, z. B. `garak.probes.base.TextProbe`
* Überschreibe so wenig wie möglich
* Du kannst den neuen Code auf mindestens zwei Arten testen:
  * Starte eine interaktive Python-Sitzung
    * Importiere das Modell, z. B. `import garak.probes.mymodule`
    * Instanziiere das Plugin, z. B. `p = garak.probes.mymodule.MyProbe()`
  * Führe einen Scan mit Testplugins durch
    * Für Sonden: Versuche einen Blank-Generator und always.Pass-Detektor: `python3 -m garak -m test.Blank -p mymodule -d always.Pass`
    * Für Detektoren: Versuche einen Blank-Generator und eine Blank-Sonde: `python3 -m garak -m test.Blank -p test.Blank -d mymodule`
    * Für Generatoren: Versuche eine Blank-Sonde und always.Pass-Detektor: `python3 -m garak -m mymodule -p test.Blank -d always.Pass`
  * Lasse `garak` alle Plugins des von dir geschriebenen Typs auflisten, mit `--list_probes`, `--list_detectors` oder `--list_generators`

## FAQ

Wir haben ein FAQ [hier](https://github.com/NVIDIA/garak/blob/main/FAQ.md). Melde dich, wenn du weitere Fragen hast! [[email protected]](mailto:[email protected])

Die Code-Referenzdokumentation befindet sich unter [garak.readthedocs.io](https://garak.readthedocs.io/en/latest/).

## Zitieren von garak

Du kannst das [garak-Preprint-Paper](https://github.com/nvidia/garak/blob/main/garak-paper.pdf) lesen. Wenn du garak verwendest, zitiere uns bitte.```
@article{garak,
  title={{garak: A Framework for Security Probing Large Language Models}},
  author={Leon Derczynski and Erick Galinkin and Jeffrey Martin and Subho Majumdar and Nanna Inie},
  year={2024},
  howpublished={\url{https://garak.ai}}
}