Як насправді працює AI-підбір кандидатів: двошаровий підхід

Ви чули цей пітч сотні разів: “AI-підбір кандидатів.” Але що це насправді означає? Більшість інструментів дають вам відсоток — “78% відповідності” — і очікують, що ви просто повірите. Жодних доказів. Жодних пояснень. Жодного способу зрозуміти, чи AI справді влучний, чи просто галюцинує.

Це не підбір. Це магічне число.

Справжній підбір кандидатів потребує двох речей: швидкості та пояснюваності. Вам треба оцінювати 20+ кандидатів на день, не витрачаючи 10 хвилин на кожного — але також розуміти чому кандидат отримав саме таку оцінку, щоб приймати обґрунтовані рішення та проводити змістовні скринінг-дзвінки.

Ось як двошаровий підхід вирішує обидві проблеми.

Проблема одношарового підбору

Коротко: Більшість систем підбору використовують або ключові слова (швидко, але сліпо до синонімів, контексту та перенесених навичок), або тільки AI (нюанси є, але дорого, повільно та непослідовно). Обидва підходи мають критичні вади окремо — ключові слова пропускають все цікаве, а чистий AI надмірний для очевидних перевірок.

Більшість систем підбору використовують один із двох підходів, і обидва мають критичні вади.

Тільки ключові слова

Найпростіший підхід: витягти ключові слова з опису вакансії, перевірити їх наявність у профілі кандидата. “React” у JD? Шукаємо “React” у резюме. Знайшли? Бал зараховано.

Це швидко ламається:

Синоніми невидимі. Кандидат, який вказав “React.js”, не збігається з пошуком “ReactJS.” Хтось із “frontend development” не збігається з “front-end engineering.”
Контекст втрачено. “5 років Python” у профілі кандидата може означати 5 років написання маленьких скриптів автоматизації — а не 5 років побудови продакшн бекенд-систем.
Рівень — це здогадка. Ключові слова не можуть сказати, чи кар’єрна траєкторія кандидата йде в правильному напрямку. Senior Engineer у стартапі з 5 людей і Senior Engineer у Google мають однакову назву, але дуже різний досвід.
Перенесених навичок не існує. Scala-інженер даних із 6 роками досвіду розподілених систем не збігається з пошуком “Python data engineer” — навіть якщо він, ймовірно, може виконати цю роботу.

Ключові слова ловлять очевидне. Все цікаве — пропускають.

Тільки AI

Протилежний підхід: надіслати повний профіль кандидата і опис вакансії в LLM, запитати “наскільки ця людина підходить?”, і розібрати відповідь.

Це краще працює з нюансами — AI розуміє, що “Series A company” означає “стартап” — але створює нові проблеми:

Вартість накопичується. Якщо ви надсилаєте повні профілі до мовної моделі для кожного кандидата — це $0.05-0.15 за оцінку. При 20 кандидатах на день — $1-3 лише на матчинг.
Затримка помітна. Повний AI-аналіз займає 5-15 секунд. Коли ви переглядаєте пайплайн із 30 кандидатів, ці секунди накопичуються.
Надмірність для очевидних невідповідностей. Якщо JD вимагає 8+ років досвіду, а кандидат має 2 роки — вам не потрібен AI, щоб це зрозуміти. Потрібне просте порівняння чисел.
Непослідовність. Задайте тій самій LLM те саме питання двічі — і ви можете отримати різні оцінки.

AI-матчинг потужний, але дорогий і іноді ненадійний для базових перевірок.

Двошарове рішення

Коротко: Шар 1 (детерміністичний) обробляє збіг ключових слів, роки досвіду, локацію, зарплату та обов’язкові вимоги миттєво без витрат. Шар 2 (AI) додає аналіз кар’єрної траєкторії, релевантність домену, розпізнавання перенесених навичок та генерує цільові скринінгові питання — все за менш ніж 5 секунд.

Відповідь — не вибір між ключовими словами та AI. А використання обох — у правильному порядку.

Шар 1: Детерміністичний підбір (безкоштовний, миттєвий)

Перший шар обробляє все, що можна оцінити правилами та порівняннями. Без AI. Нульова вартість. Миттєві результати.

Що перевіряє Шар 1:

Збіг ключових слів. Витягує навички та технології з вимог JD. Перевіряє кожну в парсених даних резюме кандидата. Розраховує відсоток збігу. Це не семантичне — це буквальне зіставлення рядків із деякою нормалізацією (React = React.js = ReactJS).

Роки досвіду. JD каже “5+ років бекенд-розробки.” Резюме кандидата показує, що перша бекенд-роль почалася у 2021 році. Проста математика: 5 років. Перевірено.

Відповідність локації. Роль — “Берлін, гібрид.” Кандидат у “Мюнхені, відкритий до релокації.” Шар 1 позначає це як часткову відповідність — та сама країна, інше місто, релокація згадана.

Зарплатна відповідність. Бюджет — €70-85k. Очікування кандидата (з профілю або попередніх нотаток) — €80k. Зелений прапорець — в межах діапазону.

Обов’язкові вимоги. JD має 3 обов’язкові вимоги: React, TypeScript і 3+ роки. Шар 1 перевіряє кожну незалежно та дає бінарний результат: пройшов/не пройшов.

Результат — базова оцінка, що миттєво виявляє очевидні невідповідності. Якщо кандидат не пройшов 3 з 5 обов’язкових вимог у Шарі 1, вам, напевно, не потрібен Шар 2, щоб зрозуміти, що це слабка відповідність. Але Шар 1 також знає свої обмеження — він позначає все, що не може оцінити, як “потребує AI-перегляду.”

Шар 2: AI-аналіз нюансів (швидкий, контекстний)

Шар 2 починає працювати там, де закінчуються правила і починається судження.

Аналіз кар’єрної траєкторії. Чи росте кандидат у правильному напрямку? Хтось, хто пройшов шлях від Junior Frontend → Mid Frontend → Senior Frontend → Lead Frontend, на чіткому IC-треку. Хтось, хто пройшов від Developer → Team Lead → Engineering Manager — на менеджерському треку. Якщо JD на Staff Engineer, AI розпізнає, яка траєкторія краще підходить.

Релевантність домену. JD для фінтех-компанії. Кандидат 4 роки працював у платіжному стартапі. Шар 1 не зловив би “payments” як релевантне до “fintech” — але Шар 2 розуміє, що платежі — це фінтех-піддомен, і оцінює відповідно.

Перенесені навички. Кандидат із 6 роками досвіду Scala та Apache Spark подається на роль “Python + PySpark.” Шар 1 бачить нульовий збіг ключових слів для мовної вимоги. Шар 2 розпізнає, що перехід Scala → Python — це поширений і відносно легкий перехід для інженерів даних, і що досвід Apache Spark переноситься безпосередньо, незалежно від мовної обгортки.

Ідентифікація прогалин зі скринінговими питаннями. Ось де Шар 2 справді сяє. Замість того, щоб просто позначити “відсутній: досвід Kubernetes,” він генерує уточнювальне питання: “Резюме кандидата не згадує Kubernetes, але він має 3 роки досвіду Docker та AWS ECS. Запитайте: Чи працювали ви з Kubernetes у будь-якому вигляді, навіть для особистих проєктів чи сертифікацій?”

AI не просто оцінює. Він підказує, що запитати далі.

Як виглядає картка оцінки

Коротко: Двошарова картка оцінки дає загальний бал з вердиктом, розбивку по вимогах із зазначенням, який шар оцінив кожен пункт з обґрунтуванням, кольорові прапорці (зелений/жовтий/червоний) та готові питання для скринінгу — все генерується за менш ніж 5 секунд.

Коли обидва шари завершують роботу — зазвичай менш ніж за 5 секунд — ви отримуєте структуровану картку оцінки:

Загальна оцінка

Поле	Значення
Бал	82 / 100
Вердикт	Сильна відповідність
Рекомендація	Провести скринінг цього кандидата

Розбивка за вимогами

Вимога	Статус	Джерело	Обґрунтування
React, 3+ роки	✅ Зелений	Шар 1	”React” знайдено у 3 ролях, найраніше 2022 (4 роки)
TypeScript	✅ Зелений	Шар 1	Вказано в навичках, використовується у 2 останніх ролях
Node.js бекенд	🟡 Жовтий	Шар 2	Node.js не вказано, але є Express.js в одній ролі — ймовірно має досвід Node
Фінтех домен	✅ Зелений	Шар 2	4 роки у PayTech (платіжний стартап) — сильна фінтех-релевантність
Лідерство в команді	🟡 Жовтий	Шар 2	Керував командою з 2 осіб на проєкті, але без формальної лідерської ролі
Kubernetes	🔴 Червоний	Шар 1	Не знайдено в резюме. Є досвід Docker + ECS — може мати перенесені знання

Прапорці

Зелені прапорці:

Сильна фронтенд-траєкторія (Junior → Mid → Senior за 5 років)
Досвід у фінтех-домені відповідає ролі
Зарплатне очікування (€78k) в межах бюджету (€70-85k)

Жовті прапорці:

Досвід Node.js бекенду незрозумілий — потребує скринінгу
Лідерський досвід неформальний — уточнити очікування

Червоні прапорці:

Kubernetes не згадується — якщо це жорстка вимога, може бути блокером

Питання для скринінгу

“У вашому резюме великий досвід Docker та AWS ECS. Чи мали ви будь-який досвід з Kubernetes — на роботі, в сайд-проєктах або через сертифікації?”
“Я бачу, ви керували командою з 2 осіб у проєкті міграції платежів. Чи цікавить вас перехід на більш формальну роль технічного ліда?”
“У вас вказано Express.js у ролі в Acme Corp. Скільки бекенд-роботи на Node.js ви робили щодня порівняно з фронтенд-роботою на React?”

Чому жоден шар окремо не працює

Коротко: Шар 1 окремо відхиляє хороших кандидатів із перенесеними навичками та не бачить доменну релевантність. Шар 2 окремо повільніший, дорожчий та надмірний для простих перевірок. Разом вони коштують $0.01 за оцінку, працюють за 3-5 секунд та ловлять як очевидні невідповідності, так і приховані можливості.

Ось швидке порівняння:

Сценарій	Тільки Шар 1	Тільки Шар 2	Обидва шари
Відсутнє обов’язкове ключове слово	✅ Ловить	✅ Ловить	✅ Ловить
Scala-інженер на Python-роль	❌ Немає збігу → відхилено	✅ Бачить перенесені навички	✅ Ш1 позначає прогалину, Ш2 додає нюанс
Кандидат має 2 роки, JD вимагає 5	✅ Проста математика	✅ Але повільніше і дорожче	✅ Ш1 ловить миттєво, AI не потрібен
”Платіжний стартап” для фінтех-ролі	❌ Ключові слова не збігаються	✅ Розуміє домен	✅ Ш2 додає доменну релевантність
Вартість за оцінку	$0.00	$0.01-0.02	$0.01 (Ш1 безкоштовний)
Швидкість	Миттєво	3-5 секунд	3-5 секунд загалом

Шар 1 — швидкий, безкоштовний і надійний для структурних перевірок. Шар 2 — нюансований, контекстний і пояснює свої міркування. Разом вони створюють картку оцінки, якій можна довіряти і яку можна використовувати.

Перевага пояснюваності

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

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

Кожна оцінка в двошаровій картці підкріплена конкретним доказом із профілю кандидата. “82/100” не означає, що AI “відчув”, що це 82. Це означає:

5 з 6 вимог пройшли перевірки Шару 1 ✅
Шар 2 знайшов сильну доменну релевантність (+бали)
Шар 2 виявив 2 прогалини, що потребують скринінгу (−бали, але відновлювані)
Зарплата та локація — обидва зелені прапорці (+бали)

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

Ось різниця між AI-підбором, що корисний, і AI-підбором, що лише число.

Що це означає для вашого робочого процесу

Коротко: Двошаровий підбір скорочує перегляд кандидата з 5-15 хвилин до 30 секунд. Ви сортуєте за кольором (зелений/жовтий/червоний), починаєте з сильних відповідностей, перевіряєте відновлювані прогалини жовтих та пропускаєте червоних з впевненістю — заощаджуючи 2+ години щодня.

З двошаровим підбором ваш щоденний перегляд кандидатів змінюється кардинально:

Відкрийте пайплайн — бачите 15 кандидатів, призначених на роль
Оцініть бали — 3 зелені (85+), 7 жовтих (60-84), 5 червоних (нижче 60)
Почніть із зелених — відкрийте картку, перегляньте прапорці, запишіть питання для скринінгу
Перевірте жовтих — картка каже, що саме відсутнє і чи це відновлювано
Пропустіть червоних із впевненістю — Шар 1 зловив невідповідність жорстких вимог, без здогадок

Те, що раніше займало 5-15 хвилин на кандидата, тепер займає 30 секунд перегляду картки. При 20 кандидатах на день — це 2+ години заощаджені — не на AI-хайпі, а на структурованому, обґрунтованому робочому процесі.

Хочете побачити двошаровий підбір у дії? Спробуйте Recrudoc CRM безкоштовно — призначте кандидата на вакансію та отримайте першу картку оцінки менш ніж за 5 секунд.