PDF-резюме аккуратно выглядит только для человека. Для машины это набор координат, переносов строк и колонок, которые при извлечении текста рассыпаются в кашу. Если через вас проходят десятки откликов на одну вакансию, чтение глазами превращается в отдельную работу, которую никто не планировал. Talynce строит платформу вокруг этой задачи: парсинг резюме, скрининг кандидатов, AI-интервью по телефону и видео. Ниже — как выглядит такой конвейер, если стек у вас на JavaScript.
Почему сырой PDF нельзя сравнивать
Отбор начинается не с разговора, а со сравнения. Чтобы сравнивать, у всех кандидатов должны быть одинаковые поля: навыки, последние роли, сколько человек просидел на каждом месте, образование, география. Из PDF это не достаётся напрямую. Текстовый слой есть не в каждом файле — иногда это просто отсканированная картинка. Порядок блоков не гарантирован: вёрстка в две колонки ломает логическую последовательность абзацев.
Дальше начинается путаница в терминах. Для фильтра Node, NodeJS и Node.js — три разных строки, хотя речь об одном. То же с должностями: «Senior Backend Engineer» и «ведущий бэкенд-разработчик» описывают похожий опыт, но поиск по ключевому слову найдёт только одного из двух.
Конвейер из пяти шагов
- Принять файл и сохранить оригинал. Оригинал — единственный источник правды, когда парсер ошибся. Держите его отдельно от извлечённого текста: без этого невозможно переразобрать архив после того, как вы улучшили схему или словарь.
- Извлечь текст и разложить по схеме в PostgreSQL. Схема фиксированная и узкая: контакты, навыки, опыт с датами, образование, локация. Всё, что не извлеклось, помечается пустым значением. Придуманное отчество в базе хуже, чем честный null.
- Нормализовать навыки и названия должностей по контролируемому словарю. Самый скучный и самый полезный этап. Он превращает свободный текст в набор идентификаторов, по которым можно фильтровать и считать.
- Оценить кандидата по рубрике открытой роли. Рубрика — заранее описанные критерии с весами, а не список слов из описания вакансии.
- Отдать шорт-лист людям — при необходимости после AI-скрина по телефону или видео.
Порядок именно такой: словарь и рубрика появляются раньше, чем что-то автоматизируется. Иначе вы получите быстрый парсер, который быстро выдаёт мусор.
Чем извлекать данные
Выбор подхода определяет, сколько ручной работы останется после. Детерминированный код предсказуем, языковые модели гибче, но требуют проверки.
| Подход | Что даёт | Где ломается | Когда брать |
|---|---|---|---|
| Регулярки и эвристики | Быстро, бесплатно, результат воспроизводим | На нестандартной вёрстке и синонимах | Узкая схема: только email, телефон, годы опыта |
| Извлечение через LLM (OpenAI, Gemini) | Понимает свободный текст, вытаскивает опыт и навыки из абзаца | Может дописать несуществующее поле, стоит денег на каждый файл | Разнообразные резюме, готовность валидировать ответ |
| Гибрид | Код отвечает за структуру и проверки, модель — за смысл | Нужен слой валидации и лимиты на вызовы | Продакшен, где важны и качество, и цена ошибки |
На практике рабочий вариант — третий. Схема в PostgreSQL описана вами, модель заполняет поля, а код проверяет типы, даты и не даёт записать навык, которого нет в словаре. Redis в этом стеке удобен для очередей и кэша: разбор файла — операция на секунды, и держать её в том же запросе, что и загрузку, не стоит.
Где обычно спотыкаются
- Проектируют таблицы под конкретное резюме, а не под класс резюме. Потом добавление поля превращается в миграцию с перезабором архива.
- Хранят только извлечённый текст и удаляют PDF. Переразбор становится невозможен.
- Нормализуют навыки в момент показа в интерфейсе. Каждый запрос начинает тянуть гору преобразований.
- Доверяют ответу модели без валидации: если поле не прошло проверку — оно пустое, а не «примерно такое».
- Скорят по ключевым словам из вакансии. Кандидат, который дважды упомянул нужный термин, обходит того, кто реально работал с ним четыре года.
Когда автоматизация не нужна
Если у вас одна вакансия и двадцать откликов в месяц, таблица с ручным заполнением дешевле любого конвейера. Разбор окупается, когда сравнение идёт постоянно, по одной и той же рубрике, а кандидатов приходит больше, чем вы готовы читать внимательно. Второй сценарий — несколько рекрутеров на потоке: тут ценность не в скорости, а в том, что все смотрят на одни и те же поля.
Что делать по порядку
- Опишите рубрику роли: критерии и веса. Без неё скоринг бессмыслен.
- Нарисуйте схему профиля в PostgreSQL: навыки, роли, даты, образование, локация.
- Соберите словарь синонимов по вашим реальным резюме, а не по фантазиям.
- Подключите извлечение — сначала на десятке файлов вручную, глазами сверяя результат.
- Добавьте очередь и валидацию, и только потом показывайте шорт-лист команде.
Самое дорогое в этой работе — не парсинг. Это схема профиля и словарь терминов: они определяют, можно ли кандидатов сравнивать между собой. Модель можно поменять за вечер, а плохо спроектированную схему — уже нет.
Fluxs
Комментарии (0)
Войдите, чтобы комментировать.
Пока нет комментариев. Будьте первым.