KI-Lebenslauf-Parsing: Genauigkeits-Abwägungen zwischen Regex, NLP und LLMs
Die Entwicklung des Lebenslauf-Parsing (und seine Fußspuren)
Lebenslauf-Parsing war lange Zeit wirklich schrecklich. Jahrzehntelang war die beste Lösung, ein Unternehmen wie Sovren zu mieten, um Regex-Muster auf PDFs auszuführen und name, email, phone, experience zu extrahieren. Die Muster funktionieren für 60 % der Fälle – gut formatierte Lebensläufe mit vorhersehbaren Strukturen. Ausreißer (unkonventionelle Layouts, internationale Formate, Emoji, Tabellen, Überschriften) fielen durch die Risse.
Dieser Kompromiss war akzeptabel, weil es keine Alternative gab. Also bauten Einstellungsteams Workarounds auf: manuelle Überprüfung der geparsten Daten, Backend-Qualitätsprüfungen, Telefonnummern-Validierung, und eine widerwillige Akzeptanz, dass 15 % der Kandidaten-Daten zerstört würde.
Dann versprachen NLP (spaCy, StanfordNLP) besser. Named-Entity-Erkennung auf Rohtex, kein Regex nötig. Es funktionierte – für Entity-Identifikations-Aufgaben. Aber Lebenslauf-Parsing ist nicht nur Entity-Identifikation. Ein Lebenslauf ist ein semantisches Dokument: "2020–2022" unter einer Überschrift ist nicht nur ein Datum, es ist ein Arbeitsstart- und Enddatum. Ein NLP-Modell, das auf Nachrichten trainiert wurde, erfasst diesen Kontext nicht.
Jetzt können LLMs (Claude, GPT) semantischen Kontext lesen. Aber LLMs sind probabilistisch. Ohne Struktur halluzinieren sie Felder, erfinden Job-Titel, und springen manchmal über ganze Experience-Abschnitte. Die Frage ist: Wie bringen Sie ein LLM dazu, zuverlässig zu parsen?
Wo jeder Ansatz bricht
Regex (Sovren-Ära):
- Bricht bei: Non-Standard-Formatierung (horizontale Timeline statt Bullet Points), Überschriften in verschiedenen Schriften, internationale Name-Formate, PDF-Extraktions-Artefakte (extra Spaces, gebrochene Zeilenumbrüche).
- Funktioniert bei: Gut formatiert, einzelne Spalte, englische Lebensläufe von Hochschul-Absolventen oder Corporate-Hintergründen.
- Problem: Sprödheit. Ein PDF aus Canva bricht das Muster.
NLP (spaCy, StanfordNLP):
- Bricht bei: Semantische Verständnis. "2020–2022" sieht für NLP wie ein Datum aus. Aber warum ist es auf diesem Lebenslauf? Unter welchem Job? Ist es ein Start/End-Datum oder ein eigenständiges Zertifikat?
- Funktioniert bei: Entity-Extraktion, falls das Dokument sauber ist und klar gekennzeichnet.
- Problem: Kein semantischer Kontext. Ein NLP-Modell weiß nicht, dass "Python" unter "Skills" anders ist als "Python" in "Python-Beratungsfirma" (Werkzeug vs. Firmenname).
LLM ohne Struktur:
- Bricht bei: Halluzination. "Extrahiere die Arbeits-Experience des Kandidaten" gibt zurück:
[{ title: "Senior Software Engineer", company: "Google", start: "2018", end: "2022" }, { title: "Principal Engineer", company: "Apple", start: "2015", end: "2018" }]– aber nur eine davon ist auf dem Lebenslauf. Oder fehlende Abschnitte völlig, weil das Modells Kontextfenster abgeschnitten wurde. - Funktioniert bei: Offene Zusammenfassungen und Interpretationen.
- Problem: Keine Schutzschienen. Das Modell kann plausibel klingende Daten erfinden.
LLM mit strukturiertem Prompting (Zod/JSON Schema):
- Bricht bei: Komplexe Randgeräusche (Kandidat mit 15 Jobs, Lebenslauf in gemischtem Englisch/Non-Englisch, ungewöhnliche Zertifikats-Format). Aber selten Halluzination.
- Funktioniert bei: ~95 % der Lebensläufe, die nicht adversariell sind.
- Problem: Benötigt Upfront-Schema-Definition und Prompt-Tuning.
Was strukturiertes Prompting tatsächlich löst
Strukturiertes Prompting + Validierung (Zod, JSON Schema) zwingt das LLM, innerhalb von Schutzschienen zu bleiben:
Extrahiere Lebenslauf-Daten in dieses Schema:
{
name: string,
email: string,
phone: string,
experience: [{ title, company, start, end, summary }],
skills: [string],
education: [{ degree, field, school, graduationYear }]
}
Regeln:
- Falls ein Feld fehlt, gibt null zurück, nicht einen erfundenen Wert.
- Daten müssen YYYY oder YYYY-MM sein, nicht verschwommene Strings.
- Skills sollten Werkzeuge/Sprachen erwähnt sein, nicht vage Adjektive.
Das Schema + Validierung fängt Halluzinationen. Falls das Modell einen sechsten Job erfindet, wenn der Lebenslauf vier listet, kann ein Validator es flaggen. Falls es start: "early 2020" (nicht gültig) zurückgibt, lehnt das Schema ab und bittet das Modell, sich anzupassen.
Das eliminiert Fehler nicht – ein LLM kann immer noch "2020–2022" als "2020–2023" falsch lesen – aber es verhindert die Arten von Fehlern, die Regex und NLP nicht fangen können: semantische Neuordnung, kontextuelle Extraktion, und Multi-Dokument-Parsing.
Die Genauigkeits-Abwägungen
| Ansatz | Genauigkeit* | Latenz | Kosten | Robustheit |
|---|---|---|---|---|
| Regex | 60–70% | <100ms | $0.01/Lebenslauf (Onsite) | Spröde |
| NLP | 70–80% | 200–500ms | $0.02/Lebenslauf | Mittel |
| LLM (unstrukturiert) | 80–90% | 1–3s | $0.10–0.50/Lebenslauf | Neigung zu Halluzination |
| LLM + Struktur + Validierung | 92–98% | 1–3s | $0.10–0.50/Lebenslauf | Robust |
*Genauigkeit = Extrahierte Felder stimmen mit Ground-Truth-Lebenslauf überein (Name, E-Mail, Arbeitsdates, Skills). Variiert nach Lebenslauf-Format und Komplexität.
Wann jeden nutzen
- Recruiting-Startup mit 50 Lebensläufen/Monat: LLM + Struktur. Kosten sind vernachlässigbar, Genauigkeit ist wichtig für Kandidaten-Erfahrung.
- Enterprise-ATS mit 10.000 Lebensläufen/Monat: Hybrid. LLM für neue Aufnahme, aber Validierung gegen bestehende Mitarbeiter-Datenbank. Falls LLM scheitert, Rückfall zur manuellen Überprüfung.
- High-Volume Low-Touch Sourcing: Regex auf eigenem PDF-Parsing-Stack. Akzeptieren Sie 20 % Fehler und nutzen Sie Downstream-Filter, um es abzufangen.
- Compliance/Rechtlich: Verlassen Sie sich nie alleine auf automatisierte Extraktion. Immer human-verifizieren, bevor archiviert.
Wie ClarityHire Lebenslauf-Parsing handhabt
Falls ein Kandidat einen Lebenslauf hochlädt oder einfügt, extrahiert ClarityHire strukturierte Daten mit Claude + Zod-Validierung. Die Extraktion umfasst Name, Kontaktinfo, Arbeits-Historie, Bildung, und Fähigkeiten. Kandidaten überprüfen und korrigieren dann die extrahierten Daten, bevor sie in die Pipeline gehen – menschliche-In-The-Loop-Derisking der LLM-Ausgabe.
Dieser Ansatz wechselt Kosten (API-Aufrufe) gegen Genauigkeit und Kandidaten-Erfahrung aus. Ein Kandidat sieht seine geparsten Daten und weiß, dass es richtig ist, bevor er evaluiert wird. Es verhindert auch die "Wir haben deine Daten falsch" Überraschung später, wenn ein Angebots-Brief seinen Namen falsch geschrieben hat oder dein HR-System zeigt, dass er irgendwo arbeitete, wo er nicht arbeitete.