Prompt Engineering Patterns für Patentarbeit

1. Role · Task · Format · Context

Das Grund-Framework, auf dem alle anderen Pattern aufbauen. Vier Abschnitte, in dieser Reihenfolge. Rolle setzt die Expertise-Perspektive. Task ist die konkrete Arbeitsanweisung. Format legt fest, wie die Antwort strukturiert sein soll. Context enthält die Eingabedaten, typischerweise am Ende, damit das Modell beim Lesen zuerst den Auftrag versteht und dann die Daten einsortieren kann.

# Role
Du bist European Patent Attorney mit 20 Jahren EPA-Erfahrung.

# Task
Fasse die folgende Patentbeschreibung zusammen.

# Format
Schreibe in flüssigem Deutsch, als Fließtext, ohne Aufzählungen.

# Context
[Der Beschreibungstext]

Der Reihenfolgen-Trick: Rolle und Task kommen oben, damit das Modell weiß, wie es den darunter folgenden Kontext lesen soll. Umgedreht würde das Modell zuerst die Patentbeschreibung verarbeiten und erst am Ende erfahren, welche Frage es eigentlich beantworten soll.

2. Prompt Chaining

Eine komplexe Aufgabe in mehrere kleine Prompts zerlegen, deren Ausgaben sich ergänzen. Wird in der Patentarbeit täglich gebraucht: „Finde das Unterscheidungsmerkmal gegenüber D1" ist ein anderer Prompt als „Welchen technischen Effekt hat dieses Merkmal", und beide ergeben nur zusammen eine vollständige Argumentation.

Beispiel für die Aufgabe-Lösungs-Entwicklung:

• Prompt 1: Was ist das Unterscheidungsmerkmal gegenüber D1?
• Prompt 2: Welcher technische Effekt ergibt sich aus diesem Merkmal?
• Prompt 3: Formuliere daraus die objektive technische Aufgabe.

Prompt Chaining wird zur Evolution namens Context Engineering, wenn die Schritte in getrennte Chats wandern. Siehe dazu den Context-Engineering-Artikel.

3. Chain of Thought

Das Modell zum schrittweisen Denken zwingen, bevor es die Antwort gibt. Bei komplexen Fragen wie Anspruchsauslegung, Äquivalenz-Bewertung oder Offenbarungsprüfung hebt das die Qualität spürbar.

Zur Beantwortung gehe schrittweise vor:
1. Welches Merkmal unterscheidet den Anspruch von D1?
2. Welcher technische Effekt ergibt sich aus diesem Merkmal?
3. Formuliere daraus die objektive technische Aufgabe.
Erst danach gib die finale Aufgabe-Lösungs-Analyse aus.

Bei modernen Reasoning-Modellen (GPT-5 Thinking, Claude Opus mit extended thinking, DeepSeek r1) ist das teils implizit. Bei Standard-Modellen macht das explizite „Step by step" den Unterschied zwischen Bauchgefühl-Antwort und nachvollziehbarer Argumentation.

4. Few-Shot Prompting

Zwei oder drei ausgearbeitete Beispiele voranstellen, bevor die eigentliche Frage kommt. Wirkt besonders bei Mustern, die sich schwer in Worte fassen lassen, zum Beispiel dem Stil einer Merkmalsgliederung, dem Aufbau einer Claim-Chart-Zeile oder der Formulierung einer Problem-Lösungs-Aufgabe.

Beispiel 1:
Merkmal M1: "ein Gehäuse"
Offenbarung in D1: Spalte 3, Zeile 5: "a housing"
Bewertung: wörtlich offenbart ✓

Beispiel 2:
Merkmal M2: "thermisch leitend"
Offenbarung in D1: keine Erwähnung
Bewertung: nicht offenbart ✗

Jetzt für Merkmal M3:
[...]

Drei Beispiele sind meistens genug. Mehr kostet nur Token und verbessert das Ergebnis kaum noch. Die Beispiele sollten die Variationsbreite der echten Aufgabe abdecken, nicht einfach dreimal dasselbe zeigen.

5. Self-Reflection

Nachdem das Modell geantwortet hat, fragst Du es, ob es sicher ist. Im selben Chat. Das klingt trivial, fängt aber erstaunlich viele Fehler ab, weil das Modell den zweiten Durchgang aus einer anderen Perspektive startet.

Bist Du sicher, dass das Merkmal nicht in Dokument D1 offenbart ist,
weder explizit noch implizit? Prüfe Deine eigene Antwort noch einmal
kritisch.

Self-Reflection hat eine Grenze: das Modell prüft seine eigene Antwort, nicht die Welt. Für harte Fact-Checks braucht es einen frischen Chat mit dem Quelldokument, siehe Pattern 7.

6. Advocatus Diaboli

Man bittet das Modell, seine eigene Antwort oder den zu prüfenden Entwurf mit maximaler Härte anzugreifen. Die Aufforderung muss scharf genug sein, dass das Modell nicht in Höflichkeit flüchtet.

Nenne die fünf wichtigsten Gründe, warum dieser Anspruchssatz
Murks ist. Nichts beschönigen, keine Höflichkeits-Floskeln.

Einsatzbereiche: Anspruchsentwurf (eigene Schwachstellen finden), Einspruchsvorbereitung (Gegner-Argumente antizipieren), FTO (Design-Around-Risiken), Bescheidserwiderung (Schwächen der eigenen Argumentation). Besonders stark, wenn der Angriffs-Chat getrennt vom Entwurfs-Chat läuft.

7. Fact-Checking mit Verbatim-Zitaten

Das wichtigste Anti-Halluzinations-Pattern der Patentarbeit. Jede Aussage, die sich auf ein Dokument bezieht, muss durch ein wörtliches Zitat samt Fundstelle belegt sein. Das Modell zu zwingen, diese Zitate zu liefern, hebt den Qualitätsunterschied zwischen „klingt plausibel" und „steht tatsächlich dort".

Ist Merkmal M3 in Dokument D1 offenbart? Stütze Deine Antwort
mit wörtlichen Zitaten aus dem Dokument. Wenn Du kein Zitat
findest, sage "nicht offenbart". Keine Paraphrasen.

Follow-up-Prompt:
Überprüfe Deine vorherige Antwort kritisch. Stimmen die angegebenen
Zitate wörtlich mit dem Dokument überein? Nenne jedes Zitat
nochmals mit Absatznummer.

Siehe auch den eigenen Artikel zur Belegpflicht und zur Absatz-für-Absatz-Durchsuchung, die das Pattern in die Breite tragen.

8. Strukturierte Ausgabe

Man schreibt dem Modell vor, in welchem Format die Antwort zu kommen hat. XML-Tags, Markdown-Tabellen, JSON-Schema. Das macht die Ausgabe maschinell weiterverarbeitbar, aber auch menschlich leichter zu scannen.

Verwende folgendes Ausgabeformat:
<UM>Gib das Unterscheidungsmerkmal im Originalwortlaut an,
beginne mit: "Anspruch 1 unterscheidet sich von D1 dadurch, dass..."</UM>
<Reason>Begründung für Deine Entscheidung</Reason>
<Cite>Fundstelle in D1</Cite>

Je enger das Format, desto weniger kann das Modell ausweichen. Bei Merkmalsgliederungen, Claim Charts, Offenbarungs-Matrizen und Risiko-Tabellen erzwingt das eine Vollständigkeit, die bei Fließtext unbemerkt wegrutschen würde.

Pattern-Kombinationen in der Praxis

Die Pattern lassen sich stapeln. Eine typische Bescheidserwiderungs-Analyse kombiniert Role-Task-Format-Context mit Prompt Chaining (jede Entgegenhaltung einzeln), Chain of Thought (Argumentation schrittweise entwickeln), Few-Shot (Beispiele für den gewünschten Argumentations-Stil), Advocatus Diaboli (Schwächen der eigenen Erwiderung antizipieren), Fact-Checking mit Verbatim-Zitaten (jede Behauptung belegen) und Strukturierter Ausgabe (als Tabelle mit Anspruch, Einwand, Erwiderung, Quelle).

Die Reihenfolge ist nicht beliebig. Role-Task-Format-Context steht immer am Anfang. Chain of Thought und Strukturierte Ausgabe wirken zusammen besonders gut. Self-Reflection und Advocatus Diaboli sind Verifikations-Schritte und kommen am Ende. Fact-Checking läuft parallel zu allem, bevorzugt in einem separaten Chat.

Verbindung zu den anderen Artikeln

• Context Engineering: wie die Pattern zwischen mehreren Chats orchestriert werden.
• Context Engineering: warum ein frischer Kontext mehr bringt als ein raffiniertes Pattern in vergiftetem Kontext.
• Multi-Model-Workflows: Self-Reflection und Advocatus Diaboli in der Extremform, mit getrennten Modellen.
• Belegpflicht: die Disziplin hinter Pattern 7.