директор и машина · люди · запись № 008 · 19 июня 2026 · Давид Герштейн

Скрининг резюме нейросетью: 400 откликов за вечер без потери адекватных

Менеджер по подбору персонала свёл статистику на конец дня: портал показывает несколько десятков откликов на вакансию, в таблице автоматизированной системы — заметно меньше. Не два-три резюме потерялось, а ощутимый кусок потока. Первая мысль — агент занижает оценки, и часть кандидатов не проходит порог. Вторая, более неприятная — агент вообще не забирает эти резюме с портала, до всякой оценки. Разница принципиальная: одно чинится правкой критериев, второе — это дыра, через которую утекают кандидаты, которых никто даже не увидел.

До автоматизации менеджер вручную открывал портал, листал отклики, сверял с описанием вакансии, копировал подходящих в отдельный файл. При потоке в несколько сотен откликов на вакансию это часы каждый день — оценочно около 3 часов на вакансию при работе с массовым потоком, то есть больше трети восьмичасового рабочего дня только на просмотр резюме, без единого звонка кандидату. И это в лучшем случае: часть откликов при ручном разборе просто не открывают — до них не доходят руки, и адекватный кандидат уходит со статусом «не рассмотрено» без единого взгляда на резюме.

Зачем вообще автоматизировать скрининг резюме ИИ

Ручной скрининг не масштабируется линейно. Если на вакансию приходит 400 откликов за вечер — обычное дело для массового найма, — просмотреть каждое резюме за разумное время физически нельзя. Начинается выборочная проверка: смотрят первые пятьдесят, остальное закрывают статусом «отклонено» без просмотра. Часть адекватных кандидатов теряется не потому, что они не подходят, а потому что до них не дошла очередь.

Задача автоматизации здесь конкретная — не заменить решение человека, а гарантировать, что каждый отклик хотя бы попал в поле зрения с предварительной оценкой. Дальше менеджер смотрит не 400 резюме подряд, а список, отсортированный по баллам, и тратит время на тех, у кого оценка высокая или пограничная.

Механика по шагам: API, таблица, агент

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

1. Структурированная таблица мониторинга вакансий. Поля под просмотры, клики, отказы, статус резюме по критериям — до всякого API. Без таблицы некуда складывать данные, которые потом принесёт агент.
2. Подключение через API-ключи к базе данных портала. Без него всё осталось бы ручным копированием — механика та же, только медленнее.
3. Агент, который ежедневно обращается к порталу и вытягивает новые отклики. Работает по расписанию, не по запросу человека.
4. Автоматическое заполнение таблицы резюме с оценкой по заданным критериям. Тут в дело вступает модель — она читает текст резюме и критерии вакансии, а не просто копирует поля.

На начальном этапе все решения по кандидатам остаются за менеджером. Агент не приглашает и не отклоняет — он готовит материал для решения. Это не временная перестраховка, а рабочая логика: система должна накопить обратную связь от человека, прежде чем ей можно доверить действие, а не только оценку.

ИИ-связка целиком: промпт, модель, обвязка

Конвейер выглядит так: портал вакансий → агент по расписанию (cron) → API портала отдаёт новые отклики → текст резюме и критерии вакансии уходят в модель на скоринг → результат пишется в Google Sheets → менеджер видит отсортированный список → решение по кандидату вручную → обратная связь возвращается в систему для донастройки критериев.

Для скоринга резюме взяли дешёвую модель уровня GPT-4o-mini. Не потому что дешевле — значит лучше по умолчанию, а потому что задача формальная: сверить текст с чётким списком критериев, не рассуждать, не сочинять. Дорогая модель с расширенным рассуждением здесь просто сжигает бюджет без прироста качества — разница в точности на этом шаге не окупает разницу в цене токена.

Структура входных данных, которую агент собирает по API портала и передаёт в модель:

Ты — ассистент по первичному скринингу резюме.
Тебе дан текст резюме кандидата и список критериев вакансии.

Задача:
1. Оцени соответствие каждому критерию по шкале 0/1/2
   (0 — не подтверждено, 1 — частично, 2 — подтверждено явно).
2. Не додумывай факты, которых нет в тексте резюме.
3. Если критерий невозможно оценить по тексту — ставь 0
   и указывай причину в поле flags.
4. Верни только JSON, без пояснений вне JSON.

Вакансия: {{vacancy_id}}
Критерии: {{criteria}}
Текст резюме: {{resume_text}}

Формат ответа (строго JSON):
{
  "candidate_id": "строка",
  "scores": {"название критерия": 0-2, ...},
  "total_score": число,
  "flags": ["короткая причина", ...],
  "recommendation": "смотреть в приоритете" | "смотреть в очереди" | "низкий приоритет"
}

Пример ответа модели на реальный вызов:

{
  "candidate_id": "resp-58831",
  "scores": {"опыт продаж от 1 года": 2, "английский от B1": 1, "готовность к переезду": 0},
  "total_score": 3,
  "flags": ["переезд не упомянут в резюме"],
  "recommendation": "смотреть в очереди"
}

Второй промпт — для короткого уведомления в Telegram, когда балл кандидата высокий. Тут тоже дешёвая модель: задача — переформулировать структурированные данные в две строки человеческого текста, а не анализировать.

Сформулируй короткое уведомление в Telegram (не больше 2 строк)
о кандидате с высоким баллом скрининга. Без канцелярита,
без вводных фраз, сразу суть.

Данные кандидата (JSON): {{candidate_json}}

Формат ответа: обычный текст, без JSON и пояснений.

{
  "candidate_id": "resp-58902",
  "notification_text": "Новый кандидат 92/100 по вакансии «Менеджер по продажам». Есть опыт в отрасли и английский B2."
}

Инженерная обвязка. Агент крутится по расписанию (cron-задача, вызов раз в час), пишет результат в Google Sheets через API — таблица одновременно и хранилище, и интерфейс для менеджера. Telegram-бот подписан на изменения таблицы и присылает сводку и точечные уведомления по высоким баллам. Отдельный лист в таблице фиксирует время последнего успешного прогона агента — если метка не обновлялась дольше цикла (больше часа), это видно сразу, без сверки вручную. При сбое запроса к API портала агент делает до трёх повторных попыток с задержкой, а после третьей неудачи отправляет отдельное сообщение в служебный Telegram-канал: «синхронизация не удалась, данные могли устареть».

Что видно в таблице и в боте: цифры и диаграмма

Два листа таблицы решают разные задачи: один показывает здоровье вакансии в целом, второй — конкретных кандидатов.

Так выглядит лист «Отчётность по вакансиям» на практике — с теми же цифрами, что и в примере выше: несколько десятков откликов на портале, из них большая часть уже попала в таблицу агента, и метка синхронизации, по которой сразу видно, отстали данные или нет.

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

180 минут (~3 часа) — оценочное время ручного просмотра всех откликов на активную вакансию в день; 40 минут — время на проверку уже отобранных агентом кандидатов. Обе цифры — оценка, основанная на потоке в несколько сотен откликов на вакансию.

Экономия по времени не означает, что кандидатов начали смотреть меньше — их смотрят все, просто в отсортированном порядке с готовой предварительной оценкой, а не листая ленту откликов подряд.

Где автоматизация сломалась в первый раз

Расхождение между числом откликов на портале и меньшим числом в таблице — не единичный сбой, а системный риск любой интеграции через API. Портал обновляется в своём темпе, агент забирает данные в своём, и если между ними разрыв, менеджер об этом не узнаёт, пока не сверит вручную. А сверка вручную — это ровно та рутина, от которой хотели уйти.

Решение — не «почини баг один раз», а встроить показатель, который сразу говорит: данные свежие или устарели. Добавили метку времени последнего обновления таблицы. Если метка отстаёт от текущего момента больше, чем на один цикл работы агента, значит синхронизация сбилась, и таблице пока верить нельзя.

Второй уровень контроля: Telegram вместо второй таблицы

Когда появилась метка синхронизации, вскрылась вторая проблема — поведенческая, не техническая. Менеджер не доверял таблице до конца и продолжал параллельно заглядывать на портал. Логика простая: пока нет уверенности, что системе можно доверять, приходится смотреть и там, и там — а это уже не рабочий инструмент, а ещё одна табличка, куда надо смотреть.

Инструмент, который требует постоянной сверки с другим источником, не экономит время — он его удваивает. Дело было не в том, чтобы уговорить менеджера довериться таблице, а в том, чтобы вынести уведомления туда, где человек и так проверяет входящее — в мессенджер.

Спроектировали Telegram-бота: раз в час — сводка по новым откликам, отдельное уведомление — каждый раз, когда появляется кандидат с высокой оценкой. Из чата можно сразу посмотреть резюме, перейти на портал, пригласить на собеседование или отклонить. Так выглядит лента уведомлений в реальном чате бота:

Срок на доработку — два дня, потому что база (API, таблица, агент) уже была готова, добавлялся только слой уведомлений.

Здесь важна оговорка про смешение эффектов: экономию времени (3 ч → 40 мин) даёт связка API + таблица + скоринг — она сокращает сам просмотр резюме. Telegram-бот отдельно не сокращает время просмотра, он убирает необходимость параллельной сверки с порталом «на всякий случай». Этот эффект в часах отдельно не измерялся, но именно он превращает таблицу из «ещё одной таблички» в рабочий инструмент — без него часть сэкономленного времени менеджер тратил бы обратно на ручную проверку.

Что остаётся за человеком — и что забрать себе

Скрининг резюме ИИ в этой схеме не принимает решений — он готовит материал для решения. Агент обучается на обратной связи: если менеджер регулярно отклоняет кандидатов с высоким баллом по одному критерию и принимает с низким по другому, это сигнал, что критерии оценки настроены неточно. Без ручной проверки этот сигнал никто бы не увидел, и система продолжала бы штамповать оценки, не совпадающие с реальными решениями по найму.

Полная автоматизация приглашений на собеседование — следующий этап, и переходить к нему стоит только после того, как накопится достаточно решений менеджера для сверки с оценками агента. Тут же встаёт вопрос данных: резюме — это персональные данные кандидатов, и что из них можно передавать в сторонние ИИ-инструменты, а что нет, разобрано отдельно в статье про персональные данные и нейросети.

Экономика: что это стоит и что даёт

Разработка базовой связки — таблица, API-подключение, агент со скорингом — заняла порядок нескольких дней работы одного человека, обучающегося работе с API и серверными инструментами по ходу. Доработка с Telegram-ботом добавила ещё два дня — примерно треть от времени на саму базовую связку. В пересчёте на трудозатраты разработчика весь проект укладывается в объём одной рабочей недели. Эксплуатация — вызовы дешёвой модели на скоринг и уведомления — при потоке в несколько сотен резюме в день обходится на порядок дешевле одного рабочего дня менеджера в месяц, без учёта стоимости самого API портала, если он платный.

Эффект считаем отдельно от прочих инициатив по найму — это вклад именно скрининга, без учёта, например, параллельного обновления курса адаптации новых сотрудников. Формула для своего случая считается так: (часы ручного просмотра в день минус часы проверки после автоматизации) × ставка часа менеджера × число одновременно открытых вакансий × число рабочих дней в месяце = месячный эффект в деньгах.

Подставим пример: отдел закрывает 3 вакансии в месяц с потоком по 300–400 откликов на вакансию. Ручной просмотр — оценочно 3 часа в день на активную вакансию, автоматизация сокращает это время до 40 минут проверки отобранных кандидатов. Разница — около 2 часов 20 минут в день на вакансию, то есть время сокращается более чем в 4 раза. При трёх параллельных вакансиях в активной фазе это суммарно около 7 часов высвобожденного рабочего времени в день — больше, чем целый рабочий день одного менеджера, — а за 20 рабочих дней набегает объём, сопоставимый примерно с тремя-четырьмя дополнительными рабочими неделями менеджера в месяц (оценка, при условии, что вакансии действительно идут параллельно и поток стабилен).

Окупаемость считается прямым делением: разовые затраты на внедрение делим на дневную экономию рабочего времени, пересчитанную в деньги по ставке менеджера. В примере верхняя, консервативная граница затрат делится на консервативную дневную экономию — получаем около 10–11 рабочих дней. Даже с консервативными допущениями по обе стороны формулы срок окупаемости укладывается в пару недель, а не месяцы.

Это не чистая экономия бюджета — высвобожденное время менеджер тратит на звонки и интервью, то есть эффект выражается не в снижении расходов на зарплату, а в ускорении цикла закрытия вакансии и в том, что меньше адекватных кандидатов теряется из-за физической нехватки времени на просмотр. Похожая логика перевода часов в деньги разобрана в статье про реальные расходы на ИИ в месяц — стоит свериться, прежде чем закладывать бюджет на подписки моделей под несколько процессов сразу.

С чего начать в понедельник

• Проверить, есть ли у портала вакансий открытый API или хотя бы экспорт откликов — без этого шаг с агентом невозможен, и придётся начинать с ручного экспорта.
• Собрать таблицу мониторинга с двумя листами — отчётность по вакансии и реестр откликов с критериями — до подключения любого агента.
• Сформулировать критерии оценки резюме в виде короткого списка, а не общих формулировок вроде «опытный специалист» — модель оценивает буквально то, что написано.
• Добавить в таблицу отдельную ячейку с меткой времени последнего обновления — это дешевле, чем разбирать расхождения в данных постфактум.
• Запустить агента в режиме «только предлагает», без права приглашать или отклонять, минимум на несколько недель, чтобы накопить обратную связь менеджера.
• Настроить хотя бы одно уведомление вне таблицы — почта или мессенджер, — чтобы не создавать вторую систему, которую придётся проверять параллельно с первой.

Что из этого переносится на другие процессы найма

Автоматизация подбора персонала здесь строилась не как единая «умная система», а как последовательность простых блоков: сбор данных, структурирование, контроль синхронизации, уведомления. Каждый блок можно проверить отдельно и обкатать до того, как строить следующий. Похожая логика описана в статье о том, почему внедрение ИИ не работает, хотя технически всё запустилось: система, которую не с чем сверить и некому проверить, быстро превращается в фон, на который никто не смотрит.

Из этого кейса при переносе на другой найм стоит забрать не саму технологию, а три привычки, на которых она держится. API и таблица дают скорость, но не гарантируют полноту данных

Частые вопросы

Может ли ИИ полностью заменить менеджера по подбору персонала?

На старте — нет. Агент собирает отклики и считает баллы по критериям, решение по каждому кандидату проверяет человек. Полная автоматизация приглашений — следующий этап, после того как система накопит обратную связь.

Сколько времени занимает внедрение скрининга резюме через ИИ?

Базовая связка — таблица, API, ежедневный сбор откликов — разворачивается за несколько дней. Доработка вроде Telegram-бота с уведомлениями заняла два дня.

Какую модель ИИ использовать для скоринга резюме?

Дешёвую. Задача формальная — сверить текст резюме с критериями вакансии, а не рассуждать. Дорогая модель здесь просто сжигает бюджет без прироста качества.

#автоматизация #ии и нейросети #деньги