Multi-Model-Workflows

Was ist ein Multi-Model-Workflow?

Statt den gesamten Arbeitsablauf mit einem Modell zu bewältigen, teilt der Multi-Model-Workflow die Aufgabe in Rollen auf und weist jede Rolle einem anderen Modell zu. Der Klassiker: ein Modell draftet einen Anspruch, ein zweites Modell prüft den Entwurf gegen den Stand der Technik. Typische Varianten sind Analyse plus laientaugliche Kommunikation, lange Akte plus Kurzfassung, oder Formulierung plus Gegenposition.

Der entscheidende Unterschied zum „einmal draften, einmal vom selben Modell prüfen lassen" liegt in der Modellvielfalt. Ein Modell findet seine eigenen Fehler schlecht, weil dieselben Trainingsdaten Schwachstellen an denselben Stellen erzeugen. Ein fremdes Modell bringt andere Trainingsdaten und damit andere Blickwinkel mit.

Warum das funktioniert

• Unterschiedliche blinde Flecken. Modelle von verschiedenen Anbietern haben unterschiedliche Trainingsdaten, unterschiedliche Feinabstimmung und unterschiedliche Sicherheitsfilter. Ein juristisches Detail, das Claude übersieht, fällt GPT auf, und umgekehrt.
• Keine KI-Schmeichelei (Sycophancy-Bias). Wenn ein Modell seinen eigenen Entwurf prüft, neigt es dazu, zu bestätigen statt zu widerlegen. Ein fremdes Modell hat diesen Reflex nicht: es sieht den Entwurf zum ersten Mal und hat keinen Anreiz, ihn zu verteidigen.
• Kontextfreiheit im Review. Der Reviewer-Chat kennt nur den Entwurf und den Maßstab, gegen den geprüft wird. Er weiß nicht, was der Drafter „eigentlich sagen wollte". Das deckt Fälle auf, in denen der Drafter einen Gedanken angenommen hat, der im Text gar nicht steht.
• Trennung der Arbeitsschritte. Drafter und Reviewer dürfen verschiedene Systemprompts, verschiedene Fachperspektiven und verschiedene Qualitätskriterien haben. Diese Trennung ist in einem einzigen Chat schwerer durchzuhalten.

Patent-spezifische Muster

Wie man es umsetzt

Vertraulichkeits-Implikationen

Zwei Modelle heißt zwei Datenflüsse. Wenn die Aufgabe vertraulich ist (nicht veröffentlichte Erfindung, interne Mandantendokumente), müssen die berufsrechtlichen Verschwiegenheitsanforderungen für BEIDE Modelle erfüllt sein.^* Ein Cloud-Review einer vertraulichen Drafter-Ausgabe über eine nicht abgesicherte API ist derselbe Verstoß wie eine Cloud-Verarbeitung der Ursprungsdaten.

• Veröffentlichte Arbeit (Prosecution, Opposition, FTO mit publizierten Treffern): Cloud + Cloud möglich. Claude als Drafter, GPT als Reviewer. Maximale Modellvielfalt.
• Vertrauliche Arbeit (Drafting, Erfindungsmeldung): Beide Modelle müssen die Verschwiegenheitsanforderungen erfüllen, z.B. lokal im selben Ollama- oder LM-Studio-Setup (Gemma 4 27B als Drafter, Qwen 3 32B als Reviewer) oder über eine vertrauenswürdige Cloud-Instanz.
• Gemischt (FTO mit vertraulicher Produktbeschreibung + publizierten Treffern): Der vertrauliche Teil bleibt lokal, der veröffentlichte Teil darf Cloud. Nicht durch den falschen Split mischen.

Wann sich der Aufwand nicht lohnt

Multi-Model-Workflows kosten Zeit und (bei Cloud-Modellen) API-Budget. Für Routine-Aufgaben mit geringem Risiko reicht oft ein einzelnes Modell plus Self-Reflexion. Der Zusatzaufwand lohnt sich vor allem, wenn:

• die Aufgabe einen Fehler teuer macht (Bescheidserwiderung kurz vor Zurückweisung, Patent-Anspruch vor Erteilung, FTO-Freigabe vor Produkt-Launch),
• die Aufgabe Belegpflicht hat und jede Fundstelle nochmal unabhängig geprüft werden muss,
• der Drafter-Output in eine andere Zielgruppe übersetzt werden muss (juristisch → Mandant),
• die Gegenposition strukturell gesucht wird (Advocatus Diaboli vor einer mündlichen Verhandlung).

Verbindung zu den anderen Säulen

Multi-Model-Workflows verstärken die vier Säulen für Prompt Engineering in der Patentpraxis, ersetzen sie aber nicht:

• Context Engineering: Der Reviewer-Chat muss sauber starten. Ohne Kontextdisziplin zerfällt der Vorteil der zweiten Meinung.
• Belegpflicht: Der Reviewer prüft die Belege des Drafters gegen die Quelle. Jedes Zitat, das der Drafter liefert, muss der Reviewer verifizieren können.
• Absatz-für-Absatz-Durchsuchung: Der Reviewer kann das parallel machen: während der Drafter den Entwurf liefert, prüft der Reviewer die Quellen, die der Drafter nicht zitiert hat.
• Self-Reflexion + Advocatus Diaboli: Statt reiner Selbstprüfung liefert Multi-Model eine echte Zweitmeinung.