Regex LLM-Output-Extraktor
Extrahiere strukturierte Daten (JSON, Code-Blöcke, Key-Value-Paare) aus unsauberen LLM-Antworten. Wähle aus gängigen Vorlagen oder schreib eigene Regex. Live-Vorschau.
Geben Sie oben eine Eingabe ein, um das Ergebnis zu sehen.
Wozu ist das gut?
Du hast das LLM nach JSON gefragt. Es hat dir JSON gegeben, eingewickelt in ```json-Fences mit „Hier bitte!"-Vorrede. Oder „die Antwort ist 42", wenn du nur 42 wolltest. Oder eine nummerierte Liste statt einer kommagetrennten Zeichenkette. Willkommen beim Parsing-Problem, das niemand richtig löst. Dieses Tool hat eine kleine Bibliothek typischer Extraktions-Patterns plus einen freien Regex-Editor, damit du das Muster gegen deinen echten Antworttext im Browser iterieren kannst.
Wann nützlich
- Output-Parser für eine Agent-Pipeline entwerfen. Ein paar echte Antworten reinwerfen, eine Regex bauen, die alle abdeckt, ab ins Codebase.
- Defekten Parser debuggen. Deine Prod-Pipeline kippt, weil das Modell plötzlich „Hier das JSON:" vor den Fence schreibt. Sieh genau, wo deine Regex aussteigt.
- Schnelle Einmal-Extraktion. Zehn LLM-Antworten in einem Doc; aus jeder den strukturierten Teil ziehen. Einfügen, matchen, kopieren, weiter.
Die Templates
- JSON in ```json-Fence — der Standardfall. Gruppe 1 = der Inhalt. Bei mehreren Fences das
g-Flag. - JSON in beliebigem Fence — wie oben, Sprach-Tag optional, Capture nur wenn Inhalt nach
{ … }/[ … ]aussieht. - YAML in Fence — wie JSON-Fence, aber
```yaml/```yml. - Beliebiger Fenced-Code-Block — captured Sprach-Tag + Inhalt. Wenn du nicht weißt, was drin ist.
- Reines JSON-Objekt — gieriger Match vom ersten
{bis zum letzten}. Sprödes Mittel, funktioniert für „nur JSON"-Antworten. - Nummerierte Listen-Items —
^\s*\d+[.)]\s*(.+)$mitgm. Text jedes Items ohne Nummer. - key: value-Paare — zeilenweise. Gruppe 1 = Key, Gruppe 2 = Wert. Stoppt am ersten Doppelpunkt.
- Single Classification Label — nützlich für Sentiment- / Safety-Klassifikatoren, die mit einem Wort antworten sollen.
- Custom Regex — Pattern leeren und selbst schreiben.
Die „Parsed JSON"-Zeile
Wenn die erste Capture-Gruppe (oder andernfalls der gesamte Match) als JSON parst, zeigt das Tool das Ergebnis unter den Gruppen an. Das beantwortet nicht nur „hat die Regex gematcht" sondern „hat sie den richtigen Teil JSON-dekodierbar gematcht". Parst es nicht, bleibt die Zeile leer.
Typische Stolperfallen
- JavaScript-Regex, kein PCRE. Kein
\K, keine Rekursion. Lookbehind nur in modernen Browsern (seit 2018 — hier fein, woanders aufpassen). - Das Modell verpackt sein JSON in Kommentare. Nicht
{am String-Anfang suchen — Fence finden oder toleranten non-greedy Capture. - Trailing Commas im „JSON". Manche Modelle schmuggeln Trailing Commas rein. Die Regex matched,
JSON.parsenicht. Vor dem Parsen strippen. - Einfache Anführungszeichen im „JSON". Sieht aus wie JSON, ist keins. Regex egal,
JSON.parsenicht. - Verschachtelte Fences. Wenn das Modell ein Markdown-Beispiel mit Fence innerhalb der Antwort liefert, gibt's Fehl-Treffer auf den inneren. Mit realistischen Daten testen.
- Regex ist kein Tool für ernstes Bracket-Parsing. Bei tief verschachtelten Objekten: lieber JSON-bewussten Extraktor schreiben — oder Fence-Form anfragen und Inhalt parsen.
- Privacy. Text und Pattern bleiben auf der Seite. Kein Upload, kein API-Call.