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

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

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

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

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

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

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

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

Зачем мы за это взялись

У нас была вакансия, на которую пришло больше четырёхсот откликов за неделю. Я посмотрел, как это разбирается, и понял, что мы физически не сможем прочитать всех: HR честно разбирал первые полсотни, дальше начинался случайный отбор. Мы нанимали не лучшего кандидата, а того, кто удачно попал наверх списка.

Меня это разозлило: мы платим за размещение, тратим время команды на собеседования — и при этом главную часть работы, отбор, делаем наугад. Отсюда и появился этот контур. Я не искал «внедрить ИИ», я искал способ не выбрасывать людей, за показ которых уже заплачено.

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

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

Как устроен отбор резюме: API, таблица, агент

Дальше — сборка, которую вы можете повторить у себя. Если у вас есть площадка с откликами и таблица, вам понадобится вечер. Никакого специального софта покупать не нужно, и это тот случай, когда ваш HR справится без ИТ-отдела.

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

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-канал: «синхронизация не удалась, данные могли устареть».

Что видно в таблице и в боте

Обратите внимание, что попадает вам на глаза, а что — вашему HR. Руководителю не нужен весь список: вам нужны отобранные кандидаты и причина отбора, чтобы вы могли спорить с логикой, а не пересматривать четыреста откликов.

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

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

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

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-бота с уведомлениями заняла два дня.

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

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

Это то же самое, что составление резюме или услуги кадрового агентства?

Нет, это другая сторона стола. Здесь разбирается работа работодателя с входящим потоком откликов на свою вакансию: как прочитать все 400, а не первые 30. Инструкций для соискателя — как написать резюме и что указать в опыте — тут нет. Кадровое агентство продаёт закрытие вакансии под ключ и забирает отбор себе; описанная связка оставляет отбор внутри компании и снимает с менеджера только ручной просмотр.

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