Prompt Engineering für lokale Sprachmodelle
Patterns und Anti-Patterns für gemma3, qwen, llama und ähnliche lokale LLMs
Artikel aktualisiert am 25. Juni 2026
Kernerkenntnis: Lokale Sprachmodelle können Musterabgleich, aber nur eingeschränkte Inferenz. Formuliere jede Anweisung so, dass ein Berufsanfänger am ersten Tag sie ohne Fachwissen mechanisch befolgen kann.
Cloud-LLM vs. Lokales LLM
| Aspekt | Cloud-LLM (GPT-4, Claude) | Lokales LLM (gemma3:27b) |
|---|---|---|
| Implizite Inferenz | Funktioniert | Unzuverlässig |
| Vage Anweisungen | Werden meist sinnvoll interpretiert | Werden ignoriert oder falsch ausgelegt |
| Beispielfreie Anweisungen | Oft ausreichend | Brauchen Few-Shot-Beispiele |
| Self-Verification | Hilft | Verschlechtert oft das Ergebnis |
| Konditionales Verhalten | Selbst-Inferenz reicht | Pfade müssen explizit als WENN-DANN ausformuliert sein |
| Format-Treue | Hoch | Nur bei expliziten Templates verlässlich |
WENN-DANN-Strukturierung: Der wichtigste Hebel
Wenn die richtige Ausgabe von einem Eingabeparameter abhängt, formuliere den Pfad explizit als WENN-DANN-Regel. Lokale Modelle können diese Entscheidung nicht selbst ableiten.
Vorher: Universalanweisung
Score: 3.62 (gemma3:27b, 5 Runs)
Nachher: WENN-DANN-Strukturierung
Score: 5.0 (gemma3:27b, 5 Runs)
Generisches Template
Wann WENN-DANN sinnvoll ist
| Eingabeparameter | WENN-DANN sinnvoll? |
|---|---|
| Anzahl unabhängiger Ansprüche | Ja |
| Vorhandensein von Figuren | Ja |
| Sprache des Dokuments | Ja |
| Anzahl Entgegenhaltungen | Ja |
| Stilistische Präferenzen | Nein, besser über Few-Shot-Beispiele |
Konditionierungs-Trade-off
Je stärker ein Prompt auf eine bestimmte Quelle drängt, desto eher gibt das Modell auf, wenn die Quelle fehlt. Die Lösung: beide Pfade explizit formulieren.
| Formulierung | Quelle vorhanden | Quelle fehlt |
|---|---|---|
| Schwach: “Nutze die Beschreibung” | Nutzt Quelle teilweise | Halluziniert frei |
| Stark: “Ausschließlich aus der Beschreibung” | Nutzt Quelle zuverlässig | Gibt leere oder minimale Ausgabe |
| Konditional: “IF Beschreibung vorhanden: daraus zitieren. ELSE: eigene Formulierung” | Nutzt Quelle zuverlässig | Fallback-Verhalten definiert |
Few-Shot statt Zero-Shot
Cloud-Modelle verstehen oft schon aus der Aufgabenbeschreibung, welches Format und welchen Stil du erwartest. Lokale Modelle brauchen konkrete Beispiele im Prompt, mindestens eines, besser zwei bis drei.
Zero-Shot (unzuverlässig)
Few-Shot (zuverlässig)
Je näher das Beispiel an deinem tatsächlichen Use Case ist, desto besser. Verwende nach Möglichkeit echte (anonymisierte) Texte aus deiner Praxis.
Explizite Output-Templates
Lokale Modelle halten sich nur dann an ein Format, wenn du es wörtlich vorgibst. Beschreibungen wie “gib eine strukturierte Antwort” reichen nicht.
Beispiel: Template mit Platzhaltern
Besonders wichtig bei Aufgaben, deren Ergebnis weiterverarbeitet wird (z.B. als JSON, CSV oder in tabellarischer Form).
Kürzer ist besser
Lokale Modelle haben ein kleineres Kontextfenster und sind anfällig für den Recency Bias: Je weiter vorne eine Anweisung steht, desto eher wird sie ignoriert. Daraus folgt:
- Aufgabe ans Ende. Kontext und Beispiele zuerst, die eigentliche Handlungsanweisung zuletzt.
- Keine langen Einleitungen. “Du bist ein erfahrener Patentanwalt mit 20 Jahren Erfahrung...” hat bei lokalen Modellen keinen messbaren Effekt.
- Redundanz vermeiden. Dieselbe Anweisung in drei Varianten formulieren verwirrt das Modell eher, als dass es hilft.
- Fokus auf eine Aufgabe. Mehrere Aufgaben in einem Prompt (z.B. “fasse zusammen UND bewerte”) führen zu schlechteren Ergebnissen als getrennte Aufrufe.
Temperature richtig wählen
Die Temperature steuert, wie “kreativ” das Modell antwortet. Bei lokalen Modellen ist der Effekt stärker als bei Cloud-Modellen:
| Temperature | Verhalten | Geeignet für |
|---|---|---|
| 0.0 – 0.3 | Deterministisch, wiederholbar | Claim Charts, Konsistenzprüfungen, Formatierung |
| 0.3 – 0.7 | Leichte Variation | Beschreibungsentwürfe, Zusammenfassungen |
| 0.7 – 1.0 | Kreativ, aber weniger vorhersagbar | Brainstorming, Alternativformulierungen |
Explizites Wissen statt implizitem
Eine Norm zu nennen heißt nicht, ihren Inhalt mitzuliefern. “Argumentiere unter Art. 54, 56, 84, 123(2) EPÜ” setzt voraus, dass das Modell weiß, was jede Vorschrift verlangt. Große Cloud-Modelle haben diese Zuordnung meist gelernt; kleinere lokale Modelle vertauschen Neuheit und erfinderische Tätigkeit oder erfinden eine plausibel klingende Anforderung. Nenne die Norm, aber schreibe die konkrete Anforderung dazu.
Vorher: nur die Fundstelle
Nachher: Fundstelle + Anforderung
Anti-Patterns: Was nicht funktioniert
| Anti-Pattern | Warum es schadet |
|---|---|
| Self-Verify (“Prüfe deine Ausgabe”) | Filtert echte Befunde weg, statt Fehler zu korrigieren |
| Rollen-Boilerplate (“Du bist ein erfahrener Patentanwalt”) | Kein messbarer Effekt bei lokalen Modellen |
| Offene Vermeidungsregeln (“Vermeide Wiederholungen”) | Werden ignoriert, konkrete WENN-DANN-Regeln nötig |
| Implizite Stilanweisungen (“Schreibe professionell”) | Modell kennt keine Konventionen, Few-Shot-Beispiele verwenden |
| Lange Begründungen vor der Aufgabe | Recency Bias, Modell gewichtet das Ende des Prompts stärker |
Praktische Empfehlungen
- Jede Bedingung explizit machen. Wenn das Ergebnis vom Input abhängt, WENN-DANN formulieren. Nie darauf vertrauen, dass das Modell die richtige Entscheidung selbst trifft.
- Beide Pfade ausformulieren. Nicht nur den Hauptpfad beschreiben, auch den Fallback explizit angeben. Sonst gibt das Modell bei fehlender Eingabe leere Antworten.
- Few-Shot-Beispiele nutzen. Gut formulierte Kanzleiarbeit (anonymisiert) ist das wirksamste Mittel, um die Ausgabequalität zu heben.
- Mit verschiedenen Eingaben testen. Ein Prompt, der bei Maschinenbau-Patenten funktioniert, kann bei Software-Patenten versagen.
- Aufgabe an das Ende des Prompts. Kontext und Beispiele zuerst, die eigentliche Handlungsanweisung zuletzt. So nutzt du den Recency Bias zu deinem Vorteil.