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

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

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

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

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

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

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

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

Найпростіший підхід: витягти ключові слова з опису вакансії, перевірити їх наявність у профілі кандидата. “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-матчинг потужний, але дорогий і іноді ненадійний для базових перевірок.

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

Відповідь — не вибір між ключовими словами та 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 секунд — ви отримуєте структуровану картку оцінки:

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

Поле	Значення
Бал	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	Обидва шари
Відсутнє обов’язкове ключове слово	✅ Ловить	✅ Ловить	✅ Ловить
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 — нюансований, контекстний і пояснює свої міркування. Разом вони створюють картку оцінки, якій можна довіряти і яку можна використовувати.

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

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

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

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

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

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

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

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

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

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

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