Парсинг резюме с помощью ИИ: компромиссы между регулярными выражениями, NLP и LLM
Эволюция парсинга резюме (и его следы)
Парсинг резюме когда-то был действительно ужасным. Десятилетиями лучшим решением было нанять компанию типа Sovren, которая применяла регулярные выражения к PDF и извлекала name, email, phone, experience. Шаблоны срабатывали в 60% случаев — на хорошо отформатированных резюме с предсказуемой структурой. Исключительные случаи (нестандартные макеты, международные форматы, эмодзи, таблицы, заголовки) выпадали из процесса.
Этот компромисс был приемлем, потому что альтернатив не было. Поэтому команды рекрутеров создавали обходные пути: ручная проверка извлеченных данных, проверки качества на бэкенде, валидация номеров телефонов и неохотное согласие с тем, что данные 15% кандидатов будут повреждены.
Затем NLP (spaCy, StanfordNLP) обещал лучшие результаты. Распознавание именованных сущностей в сыром тексте, без регулярных выражений. Это срабатывало — для задач распознавания сущностей. Но парсинг резюме — это не просто распознавание сущностей. Резюме — это семантический документ: «2020–2022» под заголовком — это не просто дата, это дата начала и окончания работы. Модель NLP, обученная на статьях новостей, не захватывает этот контекст.
Теперь LLM (Claude, GPT) могут читать семантический контекст. Но LLM являются вероятностными. Без структуры они галлюцинируют поля, придумывают должности и иногда пропускают целые разделы опыта. Вопрос в том: как заставить LLM парсить надежно?
Где каждый подход дает сбой
Регулярные выражения (эпоха Sovren):
- Дают сбой на: Нестандартном форматировании (горизонтальная временная шкала вместо маркеров), заголовках секций разными шрифтами, международных форматах имен, артефактах извлечения из PDF (лишние пробелы, разорванные переносы строк).
- Срабатывают на: Хорошо отформатированных, одноколончатых, англоязычных резюме выпускников или работников корпоративных компаний.
- Проблема: Хрупкость. Один PDF из Canva сломает шаблон.
NLP (spaCy, StanfordNLP):
- Дают сбой на: Семантическом понимании. «2020–2022» выглядит датой для NLP. Но почему она на этом резюме? Под какой должностью? Это дата начала/окончания или отдельное достижение?
- Срабатывают на: Извлечении сущностей, если документ чистый и четко помечен.
- Проблема: Отсутствие семантического контекста. Модель NLP не знает, что «Python» под «Skills» отличается от «Python» в «Python consulting firm» (инструмент против названия компании).
LLM без структуры:
- Дают сбой на: Галлюцинациях. «Извлеките опыт работы кандидата» возвращает:
[{ title: "Senior Software Engineer", company: "Google", start: "2018", end: "2022" }, { title: "Principal Engineer", company: "Apple", start: "2015", end: "2018" }]— но только один из них есть в резюме. Или полностью пропускают секции, потому что контекстное окно модели было ограничено. - Срабатывают на: Открытых резюме и интерпретациях.
- Проблема: Отсутствие ограничений. Модель может придумать правдоподобные данные.
LLM со структурированным промптированием (Zod/JSON Schema):
- Дают сбой на: Сложных граничных случаях (кандидат с 15 должностями, резюме на смешанном английском/других языках, необычный формат сертификата). Но редко на галлюцинациях.
- Срабатывают на: ~95% резюме, которые не являются противодействующими.
- Проблема: Требует предварительного определения схемы и настройки промпта.
Что действительно решает структурированное промптирование
Структурированное промптирование + валидация (Zod, JSON Schema) заставляет LLM оставаться в пределах ограничений:
Extract resume data into this schema:
{
name: string,
email: string,
phone: string,
experience: [{ title, company, start, end, summary }],
skills: [string],
education: [{ degree, field, school, graduationYear }]
}
Rules:
- If a field is missing, return null, not a fabricated value.
- Dates must be YYYY or YYYY-MM, not fuzzy strings.
- Skills should be tools/languages mentioned, not vague adjectives.
Схема + валидация ловят галлюцинации. Если модель придумает шестую должность, когда в резюме четыре, валидатор может это отметить. Если она вернет start: "early 2020" (невалидно), схема отклонит это и попросит модель соответствовать формату.
Это не устраняет ошибки — LLM все еще может неправильно прочитать «2020–2022» как «2020–2023» — но это предотвращает типы ошибок, которые регулярные выражения и NLP не могут предотвратить: семантическую переупорядочивание, контекстное извлечение и парсинг многодокументных наборов.
Компромиссы по точности
| Подход | Точность* | Задержка | Стоимость | Надежность |
|---|---|---|---|---|
| Регулярные выражения | 60–70% | <100ms | $0.01/резюме (локально) | Хрупкая |
| NLP | 70–80% | 200–500ms | $0.02/резюме | Средняя |
| LLM (без структуры) | 80–90% | 1–3s | $0.10–0.50/резюме | Склонна к галлюцинациям |
| LLM + структура + валидация | 92–98% | 1–3s | $0.10–0.50/резюме | Надежная |
*Точность = извлеченные поля совпадают с оригинальным резюме (имя, электронная почта, даты работы, навыки). Варьируется в зависимости от формата и сложности резюме.
Когда использовать каждый
- Стартап в подборе кадров с 50 резюме/месяц: LLM + структура. Стоимость незначительна, точность имеет значение для опыта кандидата.
- Корпоративная ATS с 10 000 резюме/месяц: Гибридный подход. LLM для новых поступлений, но валидировать против существующей базы данных сотрудников. Если LLM дает сбой, откатиться на ручной просмотр.
- Высокообъемный низкозатратный поиск: Регулярные выражения на вашем собственном стеке парсинга PDF. Примите 20% ошибок и используйте нижестоящие фильтры для их перехвата.
- Соответствие/юридические требования: Никогда не полагайтесь на автоматическое извлечение в одиночку. Всегда проверяйте вручную перед архивированием.
Как ClarityHire обрабатывает парсинг резюме
Когда кандидат загружает или вставляет резюме, ClarityHire извлекает структурированные данные, используя Claude + Zod валидацию. Извлечение включает имя, контактную информацию, историю работы, образование и навыки. Затем кандидаты проверяют и корректируют извлеченные данные перед тем, как они попадают в пайплайн — человек в цикле снижает риск от вывода LLM.
Этот подход компромирует стоимость (вызовы API) за точность и опыт кандидата. Кандидат видит свои извлеченные данные и знает, что они верны перед оценкой. Это также предотвращает сюрпризы «у нас неправильные ваши данные» позже, когда письмо-оферта имеет неправильно написанное имя или ваша система HR показывает, что они работали где-то, где они не работали.