Анализ резюме с AI: компромиссы между Regex, NLP и LLM

Эволюция анализа резюме (и его отпечатки)

Анализ резюме когда-то был действительно ужасен. Десятилетиями лучшим решением было нанять компанию типа Sovren для запуска паттернов Regex на PDF и извлечения name, email, phone, experience. Паттерны работали в 60% случаев — хорошо отформатированные резюме с предсказуемыми структурами. Исключения (неконвенциональные макеты, международные форматы, эмодзи, таблицы, заголовки) выпадали.

Этот компромисс был приемлем, потому что альтернативы не было. Итак, команды найма построили обходные пути: ручной просмотр разобранных данных, проверки качества на основе, валидация номера телефона и недовольное принятие того, что 15% данных кандидата будут повреждены.

Затем NLP (spaCy, StanfordNLP) обещал лучшее. Распознавание именованных сущностей на необработанном тексте, без Regex. Это работало — для задач идентификации сущностей. Но анализ резюме — это не просто идентификация сущностей. Резюме — это семантический документ: «2020–2022» под заголовком — это не просто дата, это дата начала и окончания работы. Модель NLP, обученная на статьях новостей, не захватывает этот контекст.

Теперь LLM (Claude, GPT) могут читать семантический контекст. Но LLM вероятностны. Без структуры они галлюцинируют поля, придумывают названия должностей и иногда пропускают целые разделы опыта. Вопрос: как получить LLM для надежного анализа?

Где каждый подход ломается

Regex (эпоха Sovren):

• Ломается на: Нестандартное форматирование (горизонтальная временная линия вместо пуль), заголовки разделов в разных шрифтах, международные форматы имен, артефакты извлечения PDF (лишние пробелы, сломанные разрывы строк).
• Работает на: Хорошо отформатированные, одноколонные резюме на английском языке от недавних выпускников или корпоративного происхождения.
• Проблема: Хрупкость. Одно PDF из Canva ломает паттерн.

NLP (spaCy, StanfordNLP):

• Ломается на: Семантическое понимание. «2020–2022» выглядит как дата для NLP. Но почему это на этом резюме? Под какую работу? Это дата начала/окончания или автономные учетные данные?
• Работает на: Извлечение сущностей, если документ чистый и четко помечен.
• Проблема: Отсутствие семантического контекста. Модель NLP не знает, что «Python» под «Skills» отличается от «Python» в «Python consulting firm» (инструмент vs. название компании).

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 оставаться в пределах защиты:

Извлечь данные резюме в эту схему:
{
  name: string,
  email: string,
  phone: string,
  experience: [{ title, company, start, end, summary }],
  skills: [string],
  education: [{ degree, field, school, graduationYear }]
}

Правила:
- Если поле отсутствует, верните null, не сфабрикованное значение.
- Даты должны быть YYYY или YYYY-MM, не нечеткие строки.
- Навыки должны быть упомянутыми инструментами/языками, не неопределенными прилагательными.

Схема + валидация ловит галлюцинации. Если модель придумывает шестую работу, когда резюме список четыре, валидатор может это отметить. Если она возвращает start: "early 2020" (не действительно), схема отклоняет и просит модель соответствовать.

Это не исключает ошибки — LLM все еще может неправильно прочитать «2020–2022» как «2020–2023» — но предотвращает виды ошибок, которые Regex и NLP не могут поймать: семантическое переупорядочивание, контекстное извлечение и мультидокументный анализ.

Компромиссы в точности

*Точность = извлеченные поля соответствуют истинному резюме (имя, электронная почта, даты работы, навыки). Варьируется по формату резюме и сложности.

Когда использовать каждый

• Стартап рекрутинга с 50 резюме/месяц: LLM + структура. Стоимость пренебрежима, точность имеет значение для опыта кандидата.
• Корпоративная ATS с 10,000 резюме/месяц: Гибридная. LLM для нового приема, но валидируйте против существующей базы сотрудников. Если LLM не пройдет, вернитесь к человеческому обзору.
• Высокомерный низкосенсорный поиск: Regex на вашем собственном стеке разбора PDF. Примите 20% ошибку и используйте последующие фильтры, чтобы поймать.
• Соответствие/правовое: Никогда не полагайтесь на автоматизированное извлечение одному. Всегда человеческая проверка перед архивированием.

Как ClarityHire обрабатывает анализ резюме

Когда кандидат загружает или вставляет резюме, ClarityHire извлекает структурированные данные с помощью Claude + валидации Zod. Извлечение включает имя, контактную информацию, историю работы, образование и навыки. Кандидаты затем рецензируют и корректируют извлеченные данные перед тем, как они попадут в пайплайн — человек в цикле дерискируют вывод LLM.

Этот подход обменивает стоимость (вызовы API) на точность и опыт кандидата. Кандидат видит свои разобранные данные и знает, что они правильные до того, как их оценят. Это также предотвращает сюрприз «мы имеем ваши данные неправильно» позже, когда письмо оффера имеет неправильное написание их имени или ваша система HR показывает, что они работали где-то, где они не работали.

Попробуйте анализ резюме на ClarityHire