Erst die einfachste passende Architektur
| Bedarf | Startpunkt | GenAI erst wenn … |
|---|---|---|
| Exakter Begriff/Status | SQL, Filter, Regel oder strukturierte API | freie Sprache echten Zusatznutzen bringt. |
| Dokument finden | Keyword-/semantische Suche mit Snippets | Zusammenfassung über mehrere Treffer geprüft nötig ist. |
| Klasse extrahieren | Regel, Parser oder klassisches Modell | offene Formulierungen Baselines belastbar schlagen. |
| Antwort formulieren | Vorlage plus freigegebene Textbausteine | Groundedness, Rechte, Review, Latenz und Kosten akzeptabel sind. |
NIST bezeichnet überzeugend falsche oder intern inkonsistente generative Inhalte als confabulation; statistisch plausible Ausgabe ist nicht automatisch faktisch korrekt.[1]
RAG als zwei getrennte Systeme
- Ingest: Quelle, Version, Gültigkeit, Sensitivität und ACL erfassen.
- Chunk/Index: Segmentierung und Repräsentation nur mit erlaubten Inhalten.
- Retrieve: Query gegen berechtigungsgefilterten Index; Top-k mit Quelle.
- Generate: Antwort ausschließlich aus Kontext, Zitate und Abstention verlangen.
- Validate: Output-Schema, Quellenbezug, sensible Inhalte und erlaubte Aktion prüfen.
Retrieval-Evaluation: Bei 50 vorab gelabelten Fragen enthält Top-5 für 42 mindestens einen relevanten Beleg: Recall@5=42/50=0,84. Von 250 zurückgegebenen Chunks sind 70 relevant: Precision@5=70/250=0,28. Hoher Recall kann also viel irrelevanten Kontext erkaufen; danach separat Antwortkorrektheit, Belegtreue, Zitiergenauigkeit, Abstention, Latenz und Kosten messen.
Eval-Set und Rubrik
- Reale, synthetisch ergänzte und adversarielle Fragen nach Zweck, Sprache, Dokumenttyp und Schwierigkeit stratifizieren.
- Goldquellen versionieren; keine Train-/Prompt-Tuning-Beispiele im finalen Test.
- Answer correctness gegen fachliche Referenz und groundedness gegen tatsächlich gelieferte Chunks getrennt bewerten.
- Unbeantwortbare, mehrdeutige, veraltete und berechtigungswidrige Fragen einschließen.
- Human Review mit klarer Rubrik, Doppelbewertung und Konfliktklärung; keine Einzelbeispiele als Gütenachweis.
Prompt Injection ist eine Vertrauensgrenzenfrage
Direkte Eingaben und indirekte Inhalte aus Webseiten oder Dokumenten können Modellverhalten manipulieren. OWASP betont, dass RAG oder Fine-Tuning Prompt Injection nicht vollständig beseitigen.[2]
Begrenzen
- Dokumentinhalt immer als untrusted data, nie als Instruktion.
- Least privilege, ACL vor Retrieval, kurzlebige Tokens.
- Keine freie Toolwahl; erlaubte Aktionen typisieren und bestätigen.
- Ausgabe validieren; Code/HTML/Links nicht ungeprüft ausführen.
Testen & reagieren
- Direkte/indirekte Injection, Datenexfiltration, Cross-User-Leakage.
- Attack Success Rate plus False Refusal und Aufgabennutzen.
- Logs datensparsam; Security Incident, Sperre und manueller Fallback.
- Model-, Prompt-, Index- und Policy-Version gemeinsam rückrollbar.
Interview-Fallen
- „RAG löst Halluzination“ statt Retrieval und Generation getrennt zu testen.
- LLM-Zitat als Beleg behandeln, ohne Zielquelle zu prüfen.
- Systemprompt als Sicherheitsgrenze verwenden.
- Automatische Aktion erlauben, obwohl ein Entwurf mit Review das Ziel erfüllt.
Hochsensibler Kontext
Für Gesundheits- oder Leistungsinformationen wäre eine APKV-Anwendung hier nur ein hypothetisches Interview-Szenario. Ohne belegten Zweck, Rechts-/Datenschutzprüfung, strikt durchgesetzte Rechte, robuste Evaluation, menschliche Zuständigkeit, Fallback und Incidentpfad: nicht einsetzen oder auf nicht-sensitive Suche/Entwurfshilfe eingrenzen. NIST fordert kontextbezogene Lifecycle-Messung und Reaktion statt pauschaler Vertrauensaussagen.[3]
Belege auf dieser Seite
- Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile · geprüft 2026-09-02
- OWASP Top 10 for LLM Applications 2025 · geprüft 2026-09-02
- AI RMF Core · geprüft 2026-09-02