LLM-Extraktionsvorlagen

Unter Einstellungen → KI/LLM → LLM Extraktionsvorlagen lösen Sie ein Kernproblem produktiver LLM-Extraktion: regressionssichere Prompt-Pflege bei sehr vielen Datenpunkten.

Das Problem

Komplexe LLM-Datenextraktionen umfassen pro Akte teils hunderte Datenpunkte, die jeweils über einen Prompt abgefragt, als JSON zurückgegeben und in Platzhalter umgesetzt werden. Diese Prompts verbessern Nutzer im Laufe der Zeit immer weiter. Das Risiko dabei: Eine Verbesserung an einer Stelle reißt an anderer Stelle etwas ein – eine klassische Regression, die ohne Tests oft erst spät auffällt.

Die Lösung: getestete Extraktions-Sets

Eine Extraktionsvorlage ist ein JSON-basiertes Set, in dem jeder Datenpunkt mit seinem Platzhalter und seinem Prompt hinterlegt ist. Dazu wählen Sie Testfälle aus – echte Dokumente, bei denen die Soll-Werte je Datenpunkt bekannt sind.

Ändern Sie später einen Prompt, halten Sie ihn per Klick gegen dutzende Testfälle und sehen sofort: Werden die bisherigen Ergebnisse weiterhin erreicht – und wurde z. B. ein Edge Case zusätzlich verbessert, ohne den Rest zu beschädigen? So erreichen Sie sehr hohe Qualität auch bei komplexen Extraktionsaufgaben.

Voraussetzung: getaggte Dokumente

Eine Extraktionsvorlage findet ihre Dokumente ausschließlich über Tags. Ein Dokument ohne den passenden Tag wird nie gelesen – und dafür gibt es keine Fehlermeldung: Das Ergebnis ist dann einfach leer oder ohne Dokumentinhalt. Das Dokument muss also getaggt sein, bevor die Vorlage läuft. Am besten in dieser Reihenfolge:

1. Schon beim Eingang taggen (bevorzugt): über den Tag der Upload-Komponente im Formular (Dokument hochladen, Zip-Upload), im Posteingang oder über _tags an der Aufgabe, die das Dokument erzeugt (z. B. NewLetter).
2. Ein einzelnes eingehendes Dokument ohne Tag (z. B. über ein Catch-Event angestoßen): erst per PromptToLLM den Text klassifizieren, dann mit SetCaseFileTag den Tag an genau diesem Dokument setzen.
3. Viele Dokumente auf einmal: ClassifyCaseFiles ist nur für die erstmalige Massenklassifizierung bei der Fallanlage gedacht – solange die Akte noch im Anfangsstatus ist und keine ausgehenden Schreiben enthält. Mehr dazu unter Dokumentenklassifizierung.

Ist nicht sicher, dass der Tag existiert, prüfen Sie das im Workflow vorher mit HasDocumentTag.

Aufbau der Vorlage

Datenpunkte (JSON-Attribute)

Jeder Datenpunkt ist ein JSON-Attribut mit:

Beim Prompt je Datenpunkt gilt: genau beschreiben, was gesucht wird, wo es steht, womit es nicht verwechselt werden darf, in welchem Format es zurückkommen soll – und was passiert, wenn nichts gefunden wird („Gib nichts zurück, wenn du keine findest.“). Das verhindert erfundene Werte.

Datenpunkte oder freier Prompt

Eine Vorlage kann auf zwei Arten arbeiten:

Mit JSON-Attributen – Datenpunkte extrahieren. Jedes Attribut ist ein Datenpunkt (Key + Prompt), das Antwortformat ist JSON. Dann muss zusätzlich ein Prompt-Suffix gesetzt sein: Er schließt die Attributliste ab und leitet zum Dokumenttext über – bewährt hat sich Dokumente: . Ohne Suffix kann die Antwort unvollständig werden oder der Dokumenttext „klebt“ an der Attributliste. Der Prompt setzt sich so zusammen:

System:  <System Prompt>
User:    <User Prompt Präfix>
         <Liste der JSON-Attribute: Key + Prompt>
         <Prompt-Suffix, z. B. "Dokumente: ">
         <Text aller Dokumente, die zum Tag-Filter passen>

Ohne JSON-Attribute – einen Prompt ausführen. Die Attributliste bleibt leer, die Vorlage führt einfach den Prompt aus und gibt das Ergebnis zurück – wahlweise als JSON oder als Text (Antwortformat). Typisch für Zusammenfassungen oder Einschätzungen, etwa „Fasse den Widerspruch gegen den Mahnbescheid in höchstens fünf Sätzen zusammen“. Vergleichstyp und Regex stellen Sie dann direkt an der Vorlage ein, nicht je Attribut.

Fallvariablen im System Prompt

Im System Prompt können Sie mit FEEL Werte aus dem Fall einbauen, etwa die Namen der Beteiligten. Der System Prompt beginnt dann mit = und ist ein FEEL-Text: Textteile in "…", mit + verbunden, Zeilenumbrüche als \n.

="Die Mandantschaft heißt: " + (if MANDANT_VORNAME != null then MANDANT_VORNAME else "") + " " + (if MANDANT_NACHNAME_FIRMA != null then MANDANT_NACHNAME_FIRMA else "nicht vorhanden") + "\n\nExtrahiere nur Fakten, die explizit im Text stehen."

Neben Standard-FEEL stehen hier auch die DEPLAW-eigenen FEEL-Funktionen zur Verfügung, z. B. (if FORDERUNG_OFFEN != null then euro(bigDecimal(FORDERUNG_OFFEN)) else "unbekannt") – die != null-Prüfung steht auch dann immer zuerst. Im Fließtext des Prompts keine doppelten Anführungszeichen verwenden (stattdessen ' oder „…“). Die Namen der Platzhalter müssen exakt stimmen.

Pseudonymisierung

Ist Pseudonymisieren eingeschaltet, passiert Folgendes:

1. Kurz vor dem Abschicken des Prompts werden die Daten der Beteiligten aus der Akte durch fiktive Daten ersetzt.
2. Das Sprachmodell arbeitet nur mit den fiktiven Daten.
3. Die Antwort wird wieder depseudonymisiert – im Ergebnis stehen also wieder die echten Namen.

Am Prompt selbst müssen Sie dafür nichts anpassen. Personenbezogene Daten anderer Personen, die nicht als Beteiligte in der Akte stehen, werden nicht ersetzt. Ob die Option an sein soll, ist eine Datenschutz-Entscheidung – bewusst festlegen, nicht einfach übernehmen. Grundlagen im Kapitel Pseudonymisierung.

Dokumentfilter

Der Dokument Tag Filter legt fest, welche Dokumente in den Prompt kommen. Er besteht aus einer Bedingung, deren Teile mit UND / ODER verknüpft sind – jeder Teil prüft einen Tag:

• ODER – Dokumente mit einem der Tags, z. B. verschiedene Bezeichnungen derselben Dokumentart („Mahnbescheid“ oder „MB“).
• UND – nur Dokumente, die alle Tags tragen, z. B. „Widerspruch“ und „Gegenseite“.

Bei einer reinen ODER- oder reinen UND-Kette setzen Sie an allen Teilen denselben Operator. Gemischte Bedingungen werden nacheinander von links nach rechts ausgewertet, wie eine Bedingung ohne Klammern – „UND vor ODER“ gibt es nicht: 1. ODER 2. UND 3. bedeutet (1. ODER 2.) UND 3.. Wählen Sie die Reihenfolge entsprechend; „Widerspruch UND (Gegenseite ODER Gericht)“ bauen Sie als „Gegenseite“, „Gericht“ (ODER), „Widerspruch“ (UND). Eine Logik wie „(A UND B) ODER (C UND D)“ lässt sich in einem Filter nicht abbilden.

Schreiben Sie die Tags genau so, wie sie an den Dokumenten stehen. Der Filter prüft, ob ein Tag enthalten ist; ein Filter nach Datum ist in Extraktionsvorlagen aktuell nicht möglich.

Regressionssicher testen

Rechts im Editor pflegen Sie unter Testfall Konfiguration einzelne Testfälle (Fall + Dokument + bekannter Soll-Wert), unter Testfälle sehen Sie die gespeicherte Sammlung. Ausführen testet den aktuellen Fall, Alle testen prüft die Vorlage auf einen Schlag gegen alle Testfälle. Die Statistik (Laufzeit, Token, Token/Sekunde) hilft zusätzlich, Kosten und Tempo im Blick zu behalten. Die Testfälle liegen in der Plattform und sind nicht Teil eines Exports der Vorlage.

Semantischer Ergebnisvergleich (semantic-compare)

Bei Freitext-Datenpunkten liefert ein LLM selten zweimal denselben Wortlaut – der Inhalt soll aber gleich bleiben. Der KI-Konnektor mit dem reservierten Namen semantic-compare vergleicht die Ausgabe inhaltlich statt zeichengenau. Als Vergleich eines Attributs gewählt, gilt ein Freitext-Ergebnis damit auch dann als korrekt, wenn es anders formuliert, aber inhaltlich identisch zum Soll-Wert ist.

Welcher Vergleich passt, wann ein Regex?

• Texte (Gerichtsname, Zusammenfassung, Beschreibung) → semantisch.
• Zahlen, Beträge, Daten, Aktenzeichen und feste Werte (Ja/Nein) → exakt. Wer Freitext exakt vergleicht, bekommt fehlschlagende Tests bei inhaltlich richtigen Ergebnissen.
• Regex-Validator nur bei Werten, die immer gleich aufgebaut sind (z. B. ein Datum ^\d{2}\.\d{2}\.\d{4}$) – und nur, wenn Sie das ausdrücklich wollen. Der Regex gilt nicht nur im Test, sondern auch zur Laufzeit: Passt ein extrahierter Wert nicht zum Muster, bricht LlmExtractionTemplateRun mit dem Fehler regex-validation-error ab (siehe unten).

Direkt im Workflow einsetzen

Eine fertige, getestete Vorlage ist zugleich ein Workflow-Schritt: Der Servicetask LlmExtractionTemplateRun führt sie über ihren _templateName aus – ein eingegangenes Dokument wird so vollautomatisch ausgelesen und in Folgeschritten (Platzhalter befüllen, Gateways, weitere Aktionen) verwendet.

<bpmn:serviceTask id="Activity_0k4x9wd" name="Mahnbescheid-Daten extrahieren">
  <bpmn:extensionElements>
    <zeebe:taskDefinition retries="2" type="LlmExtractionTemplateRun"/>
    <zeebe:taskHeaders>
      <zeebe:header key="_templateName" value="MAHNBESCHEID_DATEN"/>
    </zeebe:taskHeaders>
    <zeebe:ioMapping>
      <zeebe:output source="=_extractionJson.mb_geschaeftsnummer" target="wf_mb_geschaeftsnummer"/>
    </zeebe:ioMapping>
  </bpmn:extensionElements>
</bpmn:serviceTask>

• _templateName muss zeichengenau dem Namen der Vorlage entsprechen, sonst findet die Aufgabe die Vorlage nicht.
• Antwortformat JSON → das Ergebnis steht in _extractionJson als ein Objekt; die Felder lesen Sie direkt mit _extractionJson.<key> (kein parseToJson nötig). Antwortformat Text → das Ergebnis steht als Text in _extraction.
• Die Werte landen nicht automatisch in der Akte. Was in die Akte soll, legen Sie per Output-Mapping auf einen GROSSGESCHRIEBENEN Platzhalter; was nur im Workflow gebraucht wird, auf eine wf_-Variable.
• Mögliche Fehler: json-invalid, prompt-error und regex-validation-error. Alle drei lassen sich im Modell mit einem Fehler-Boundary-Event an der Aufgabe abfangen (siehe Vorfälle); hat die Vorlage einen Regex, sollten Sie regex-validation-error immer abfangen.

Häufige Fehler

Vorlagen per Textbefehl erzeugen

Der DEPLAW-Skill für Claude Code erzeugt auch Extraktionsvorlagen als importfertige Datei: Sie beschreiben, welche Datenpunkte Sie aus welchen Dokumenten brauchen, der Skill setzt Name, Prompts, Suffix, Vergleichstypen und Dokumentfilter nach den Regeln dieser Seite. Den KI-Konnektor wählen Sie nach dem Import selbst; die Testfälle legen Sie in der Oberfläche an.