Розробка AI-системи парсингу резюме з сайтів з пошуку роботи

Чому парсинг резюме ламається на потоці відгуків

Парсинг резюме здається простим завданням, поки на вході десяток охайних PDF. На потоці відгуків картина інша: сайти вакансій надсилають PDF, DOCX, RTF, текст у тілі листа й скани, а верстка в кожного документа своя.

Двоколонкові шаблони, таблиці, шапки з логотипом і контакти у футері ламають вилучення раніше, ніж закінчується перша сотня файлів.

Далі починаються помилки вилучення полів. Періоди роботи склеюються, дати вигляду «березень’19 — дотепер» не розбираються, назва компанії підтягується з посади, а блок досвіду обривається на першій таблиці. Помилки тихі: поле начебто заповнене, але неправильно, і спливає це вже на дзвінку з кандидатом.

Звідси — ручний розбір відгуків. Рекрутер тримає файл поруч із формою й переносить поля руками, і на неструктуровані резюме йде основна частина зміни.

Частка відгуків, які проходять без правок, рідко дотягує до половини, а час на картку кандидата рахується хвилинами, а не секундами.

Найдорожче обходиться втрата даних кандидата: нерозпізнаний контакт, досвід, що випав із вигрузки, відгук, який не дійшов до воронки. У звітності такі втрати не видні — кандидат просто не відповідає, а вакансія висить відкритою довше. Розбираємо, як це закривається.

Що змінюється після автоматизації відбору кандидатів

Швидкість обробки відгуків змінюється першою, бо саме на вході накопичується черга. Поки рекрутер відкриває вкладення по одному, потік відгуків зростає швидше, ніж команда встигає його розбирати, і сильні кандидати холонуть у чужих процесах.

Автоматичний розбір забирає файл, приводить його до машинозчитуваного вигляду й віддає в базу без ручного кроку — відгук перестає чекати в черзі.

Єдиний формат даних знімає головне джерело розбіжностей: те саме поле з різних джерел приходить то текстом, то картинкою, то вкладенням із нестандартною розміткою.

На виході резюме розкладається на зіставні атрибути — досвід, стек, тривалість роботи, освіта, контакти, — і за ними вже можна будувати вибірки й порівняння, а не читати кожне резюме очима.

Повнота картки кандидата вимірюється часткою коректно вилучених полів, і це перше, за чим варто стежити після запуску. Якщо поле розпізнано з помилкою, воно потрапляє в картку як пропуск, а не як сміття: рекрутер бачить, чого бракує, і точково дозапитує дані. Такий підхід тримає точність вилучення на заданому порозі замість ефекту «приблизно працює».

Зняття рутини з рекрутера — це не абстракція, а вивільнені години на розмову з кандидатом.

Копіювання, перейменування, зведення таблиць і розбір однотипних листів зникають повністю, а разом із ними зникає й клас відмов, який майже не видно у звітності: загублені між папками резюме, дублі однієї людини з різних джерел, відгуки, на які просто не відповіли вчасно.

Масштабування потоку відгуків перестає впиратися в чисельність команди. Подвоєння вхідного обсягу більше не вимагає подвоєння ручних операцій — зростає навантаження на розбір, а не на людей, і це той запас, який дозволяє спокійно проходити періоди активного найму.

Формати парсингу резюме: пакетно та в потоці

Парсинг резюме з job-сайтів запускають або пакетно, або в потоці, і цей вибір визначає вимоги до дедуплікації, повторів і зберігання сирих даних.

Пакетна обробка забирає вигрузку цілком і дає передбачуване навантаження на джерело, потокова — читає нові документи в міру появи й вимагає ідемпотентності на кожному кроці.

Усередині будь-якого режиму є другий вибір — чим вилучати поля. Розбір за шаблоном швидкий і точний на стабільній верстці, розбір моделлю витягує сенс із вільного тексту, але потребує перевірки результату. Нижче — як ці варіанти співвідносяться за завданнями і де ламаються.

Змішаний режим зазвичай і стає робочим: документи з відомою розміткою йдуть за шаблоном, решта — моделлю, а розбіжності потрапляють у чергу ручної перевірки.

Як ми будуємо вилучення полів із відгуків

Порядок робіт тут важливіший за вибір інструментів: якщо почати з вилучення, а не з аудиту джерел, те саме поле буде збиратися з вебформи й вкладення по-різному — розбіжність спливе лише на прийманні. Кожну сходинку ми закриваємо результатом, який можна перевірити.

1. Аудит джерел. Збираємо всі канали, звідки надходять відгуки: вебформи, вкладення в листах, вигрузки з облікових систем. За кожним фіксуємо формати, обсяг і частоту правок верстки — від цього залежить, де вистачить правил розбору, а де потрібен розбір за структурою документа.

2. Схема полів. Узгоджуємо перелік і типи: контакти, місто, посада, зайнятість, місця роботи з періодами, освіта, навички. Поля, які не можна отримати однозначно, описуємо правилами й позначаємо як такі, що потребують перевірки, а не домислюємо на ходу.

3. Вилучення та нормалізація. Розбираємо документи й сторінки, потім приводимо значення до єдиного вигляду: телефони й адреси пошти до канонічної форми, дати до одного стандарту, компанії та посади — до довідника. На виході — структурований запис за узгодженою схемою.

4. Розмічена вибірка. Кілька сотень реальних відгуків розмічаємо вручну й звіряємо з тим, що віддає система. Вибірка покриває всі джерела й типи документів, тому слабкі місця видно до запуску на потоці.

5. Приймання результату. Рахуємо точність і повноту окремо за кожним полем і задаємо поріг допустимих розбіжностей. Окремо перевіряємо биті файли, дублі й неповні анкети — ці випадки дають найбільше помилок.

6. Передача та супровід. Віддаємо схему полів, правила, розмітку й звіти про якість, фіксуємо регламент прогонів. При зміні верстки на боці майданчика оновлюємо правила й проганяємо регресію за збереженою вибіркою.

Що залишається у вас: схеми полів і регламенти

Парсер — не одноразовий скрипт. Верстка джерел і структура самих резюме змінюються, і без описів розбір деградує тихо: частина записів перестає доходити до бази, поки хтось не помітить провал по воронці. Тому віддаємо не лише працюючий сервіс, а й комплект документів, за яким ви ведете його самостійно.

• Схема полів — довідник атрибутів резюме: обов’язкові та опціональні, типи, значення за замовчуванням і правило пріоритету джерела при розбіжності даних.
• Правила нормалізації — телефони, дати й міста до єдиних довідників, досвід у місяцях, склейка дублів одного кандидата, що прийшов з різних джерел.
• Конфігурації розбору — частота обходу, пріоритет джерел, ліміти та винятки за кожним job-сайтом: новий підключається правкою конфігурації, без переписування коду.
• Регламент розбору — порядок робіт: як описується джерело, хто перевіряє перші вигрузки, хто підтверджує запуск у постійну роботу.
• Описи інтеграцій — формат і розклад передачі даних, умови повторного надсилання, захист від дублів і поведінка при недоступності приймача.
• Журнал помилок — відмови з контекстом: бита верстка, порожні обов’язкові поля, розбіжності з попередніми даними; рівні критичності й адресати оповіщень.
• Технічна документація — карта сервісу, схема сховища, інструкції з перезапуску й відкату на попередню версію правил.

Передаємо комплект разом із розбором на живих даних — ваші інженери проганяють нове джерело й правлять правила самі.

Кейс: розбір потоку відгуків для кадрової агенції

Точка старту

Агенція вела 30 відкритих вакансій і отримувала 900–1200 відгуків на місяць. Резюме надходили з різних джерел: частина — з кадрових майданчиків на кшталт HeadHunter, частина — вкладеннями з пошти, частина — посиланнями на профілі.

Рекрутер розбирав кожен відгук вручну, переносячи в таблицю досвід, навички, освіту й очікування щодо доходу, — близько 4 хвилин на картку, і черга до кінця дня все одно не закривалася.

При ручному перенесенні 29% полів виявлялися порожніми або з помилками: губилися блоки досвіду, назви посад писалися врознобій, дублікати кандидатів спливали повторно.

Готова картка з’являлася в середньому через добу після відгуку, коли частина кандидатів уже була працевлаштована.

Що змінили

Побудували конвеєр обробки: прийом відгуку з джерела, вилучення структури, нормалізація за довідниками — посади, міста, навички, навчальні заклади.

Спірні поля система не вгадує, а позначає: періоди роботи, що перетинаються, неоднозначний стаж, розмиті формулювання навичок ідуть рекрутеру окремою чергою із зазначенням, що перевірити. Дублікати склеюються за сукупністю ознак — контакт і зв’язка місць роботи.

Метрики після

• Частка коректних полів — 96% проти 71% до впровадження; перевіряли ручною звіркою на вибірці з 500 карток.
• Час до готової картки — 8–12 хвилин замість доби: відгук потрапляє в роботу майже одразу після надходження.
• Навантаження на рекрутера — розбір займав 60% робочого часу, залишилося 15%; вивільнені години пішли на співбесіди й роботу з наймачами.
• Потік оброблюваних відгуків зріс удвічі без розширення команди — черга перестала бути вузьким місцем.

Чим відрізняється розбір за шаблоном від модельного

Шаблонний розбір іде від структури сторінки: інженер описує селектори й правила для кожного поля, далі вилучення працює детерміновано. Однаковий вхід дає однаковий результат, усе перевіряється за логами, а витрати на обробку картки мінімальні.

Ламається такий розбір на нестандартних резюме: навички перелічені всередині блоку «Про себе», досвід зведено в таблицю або віддано вкладеним файлом. Кожна зміна верстки — ручна правка правил.

Модельний розбір іде від сенсу, а не від розташування: вилучення сутностей знаходить досвід, навички та освіту там, де правило їх не чекає.

Плата за гнучкість — невизначеність: поля потрібно валідувати, пороги впевненості калібрувати, а саму модель — утримувати від добудовування фактів, яких у тексті немає. Для контактів і дат така вільність неприпустима.

Тому робоча схема — гібридна. Якірні поля (ім’я, контакти, місто) закриває шаблонний розбір: вони передбачувані, і помилка в них коштує найдорожче. Вільні блоки — навички, описи досвіду, освіта — віддаємо модельній частині, наприклад на spaCy, з постобробкою за довідниками. Якщо два проходи розходяться, поле позначається сумнівним і йде на перевірку, а не в базу.

Вибір диктує частка нестандартних резюме в потоці. Поки вона мала, достатньо шаблону з відкатом на модель; коли джерел десятки й розмітка змінюється постійно, пріоритет перевертається.

Налаштовуємо схему за двома метриками: точність на якірних полях і частка карток, що доходять до ручної перевірки. Обидві видно в логах вилучення.

Технічні сумніви щодо якості та доступів

Нижче — питання, які найчастіше ставлять інженери замовника, і відповіді щодо будови системи.

Що робити, якщо джерело змінює верстку?

Розбір сторінки спирається на ознаки: структуру блоків, підписи полів, смислові орієнтири, а не на жорсткі шляхи до елементів. Контрольну вибірку проганяємо щодня й порівнюємо з попереднім результатом — розбіжність вище за поріг дає оповіщення раніше, ніж дані почнуть губитися.

Як вирішується питання з доступом до джерел?

Три схеми: штатний інтерфейс джерела, вигрузки самого сервісу або збір відкритих сторінок у межах правил джерела й закону. Схему підбираємо під конкретний список джерел і обсяг; облікові записи роботодавця залишаються у вас.

Як обробляються персональні дані кандидатів?

Доступ розмежовано за ролями, зберігання зашифровано, ведеться журнал звернень до запису, діють строки зберігання та видалення за регламентом, тестові прогони йдуть на обезлічених даних. Схему обробки фіксуємо документом, який перевірить ваша служба безпеки.

Як система підключається до нашої системи підбору?

Картки йдуть у потрібні поля за ідентифікатором кандидата, без створення дублів; за відсутності інтерфейсу — обмін файлами узгодженого формату за розкладом. Перед запуском проганяємо тестовий обмін на копії бази.

Обговоримо завдання: з чого почнемо розбір відгуків

Старт — це розбір завдання, а не одразу оцінка: які майданчики й типи резюме потрібні, які поля обов’язкові, як відгуки потрапляють у вашу систему зараз.

Від відповідей залежить обсяг — сотні записів на тиждень або безперервний потік, і це різні схеми збору, зберігання й дедуплікації.

Далі йде пілот на реальній вибірці: беремо ваш список джерел і кілька тисяч резюме, проганяємо через розбір і показуємо, яка частка полів вилучена коректно, де повтори, а де пропуски.

За результатом повертаємося з оцінкою обсягу й планом робіт — етапами, порядком і тим, що перевіряється на кожному кроці.

Що потрібно від замовника, щоб почати:

• список майданчиків і пріоритет за ними — з яких джерел починаємо;
• перелік полів і правил: що вважається дублем, які значення обов’язкові, що можна відкинути;
• два-три приклади «сирих» карток і те, як їх читає ваш рекрутер;
• доступ або легальний спосіб отримання даних, якщо майданчик закритий;
• точка приймання: хто і на якій вибірці перевіряє якість розбору;
• контакт на вашому боці, хто відповідає на питання щодо даних і форматів.

Опишіть завдання у вільній формі — за ним повернемося з оцінкою обсягу, планом робіт і межами пілоту на вашій вибірці.