AI-рекрутер, который никогда не устает: как мы автоматизировали скрининг кандидатов

Страницы:  1

Ответить
 

Professor Seleznov


pic
Привет, Хабр! На связи команда Just AI. Мы занимаемся разработкой AI-агентов, и в какой-то момент решили автоматизировать собственный процесс найма. В итоге сделали агента, который проводит первичный скрининг кандидатов: задает вопросы, оценивает ответы и отправляет рекрутеру письмо с готовым вердиктом.
В этой статье разобрали, зачем мы это сделали, как устроена система изнутри, с какими проблемами столкнулись и что получилось в итоге.
Откуда взялась задача
Наш карьерный сайт начал приносить около 60 откликов в неделю — это 240 в месяц. Казалось бы, хорошая новость. Но за каждым откликом стоит много ручной одинаковой работы: написать кандидату, спросить про опыт, стек, зарплатные ожидания, готовность выйти.
Мы подсчитали: один рекрутер физически может провести 8–10 скрининговых звонков в день. При этом большую часть этих разговоров можно описать алгоритмически: есть фиксированный набор вопросов, есть критерии оценки, есть типовой вердикт. То что нужно для автоматизации.
Мы поняли это, когда сели разбирать карьерный сайт перед редизайном. Посмотрели на цифры, переглянулись — и пошли с командой разработки диалоговых систем собирать агента.
Почему именно скрининг
Прежде чем лезть в архитектуру, стоит объяснить, почему скрининг — хорошая точка входа в автоматизацию HR. Вот несколько причин:
  • Предсказуемый процесс. Одни и те же вопросы, одни и те же критерии оценки. Агент не устает, не отвлекается, не меняет настроение. Он задает пятый вопрос так же внимательно, как первый — хоть на пятидесятом кандидате за день. А уставший рекрутер, как бы он не любил людей, может упустить важную деталь или вопрос — это человеческий фактор.
  • Высокий объем рутины.50+ скрининговых сессий в день — нормальная нагрузка для агента, недостижимая для человека.
  • Понятный измеримый результат. После скрининга рекрутер видит оценку и резюме ответов — вместо того чтобы вручную разбирать заметки или переслушивать записи обычных скрининговых звонков.
  • Быстрый запуск. Не нужна команда разработчиков на несколько месяцев. Интеграция на карьерный сайт — дело нескольких недель.
Как мы проектировали: шесть вопросов, которые пришлось решить
Прежде чем писать промпты и собирать схему агента, мы ответили на несколько неочевидных вопросов. Давайте по порядку.
1 вопрос: захотят ли кандидаты разговаривать с AI?
Это был не технический, а скорее психологический вопрос. Мы поставили себя на место кандидата: заходишь на сайт компании, хочешь найти работу — а тебя встречает не человек, а бот.
Мы решили сразу выстраивать отношения на искренности и правде — и не стали выдавать агента за человека. Он честно представляется ИИ-помощником, но при этом общается живо и дружелюбно — без надоедливого «Заполните форму» и «Мы свяжемся в течение пяти рабочих дней».
В последствии мы заметили один эффект: многим кандидатам психологически проще общаться именно с ботом. Меньше стресса и неловкости, можно спокойно обдумать ответ перед отправкой. Для интровертных кандидатов или тех, кто не любит созвоны, такой формат оказался даже комфортнее обычного первичного контакта с рекрутером.
В итоге доходимость кандидатов — то есть процент тех, кто дошел до конца скрининга — составила около 98%. Особенно позитивно реагировали Senior-специалисты. Мы связываем это с тем, что опытные разработчики ценят свое время и не хотят тратить его на стандартный звонок с вопросом «расскажите о себе». Они хотят быстро понять, стоит ли компания их внимания.
2 вопрос: что спрашивать?
Первый идея — взять стандартные вопросы из скрипта скрининга и загрузить их в агента. Мы так и начали. Но быстро поняли, что это не очень работает.
Проблема в том, что в эпоху LLM теоретические вопросы легко закрываются сгенерированными ответами. «Знаете ли вы React?» — конечно знает, он только что прочитал об этом у Chat GTP или Claude. «Использовали ли вы Python?» — разумеется, судя по резюме.
Настоящий опыт раскрывается через кейсы: «Расскажите про проект, где вы использовали React. С чем столкнулись? Как решили?».
Конечно, кандидат может сгенерировать ответы и в этих ситуациях. Но чем подробнее и предметнее вопросы, тем проще потом проверить реальный опыт уже на следующем этапе — техническом интервью или обсуждении кейсов. Поэтому мы сознательно сместили фокус с теории на реальные рабочие ситуации: каждая вакансия получила свой набор вопросов. В итоге у нас получилось 14 активных вакансий — и под каждую свой сценарий скрининга. 
3 вопрос: как оценивать?
Мы перебрали несколько подходов, включая оценку по шкале от 1 до 10, но с числовой оценкой все не так просто. LLM регулярно пыталась натянуть баллы даже слабым ответам: цеплялась за общие формулировки, отмечала мотивацию или интерес к вакансии, хотя по факту конкретного опыта в ответе вообще не было.
В результате похожие ответы могли оцениваться по-разному, а сама шкала получалась слишком размытой. Поэтому вместо абстрактных баллов мы перешли на систему зеленых и красных флагов для каждой вакансии.
🟢  Зеленые флаги — признаки сильного кандидата
✔️ Называет конкретные инструменты и технологии
✔️ Приводит реальный пример из практики
✔️ Объясняет свое решение и логику выбора
✔️ Говорит о результате — в цифрах или качественно
✔️ Понимает бизнес-контекст задачи
🔴  Красные флаги — признаки слабого кандидата
✔️ Только общие слова без конкретики
✔️ Слышал, но не пробовал
✔️ Нет описания реальных кейсов
✔️ Не может объяснить плюсы/минусы решений
✔️ Только учебные проекты, нет продакшн-опыта

LLM делала не тест с правильными и неправильными ответами, а анализ реального опыта кандидата, модель оценивала глубину ответа, наличие конкретики, соответствие требованиям вакансии. 
Итоговая оценка — это процент соответствия. Порог прохождения: 65%.
4 вопрос: что показывать кандидату в конце?
Здесь мы потратили немало времени, чтобы определиться. В итоге пришли к такой логике:
  • Набрал≥65 баллов — кандидат видит свой процент и получает приглашение двигаться дальше.
  • Набрал <65 баллов — результат не показываем (зачем ранить цифрой?), зато даем развернутую обратную связь: что уже получается хорошо и куда расти. И все равно предлагаем откликнуться — через мотивационное письмо.
Те, кто написал мотивационное письмо, попадают в отдельную базу. Для нас это дополнительный сигнал, что человек готов потратить время, нормально сформулировать свои аргументы и явно заинтересован в позиции. Такие кандидаты иногда оказываются вполне релевантными для других ролей или начальных позиций.
Ну и сам скор мы не воспринимаем как абсолютную истину. По мере накопления данных пороги можно спокойно регулировать под конкретные роли и реальную воронку найма.
5 вопрос: как хранить данные?
Вакансии постоянно обновляются, вопросы меняются, критерии оценки тоже. Сначала мы хранили все в Google Таблицах, но довольно быстро уперлись в ограничения такого подхода.
Во-первых, это не самый надежный вариант для системы, где несколько кандидатов могут одновременно проходить скрининг: интеграция с таблицами плохо масштабируется под нагрузку. Во-вторых, не хватало нормальной структуры данных — например, связей между вакансиями, вопросами и критериями оценки, которые можно настроить в обычной БД.
В итоге мы вынесли всю информацию во встроенную базу данных. Там хранятся: список вакансий, вопросы для скрининга, зеленые и красные флаги, критерии оценки.
Агент обращается к этой базе во время диалога и получает актуальные данные под конкретную вакансию. Благодаря такому подходу рекрутер может обновить вопросы или критерии без участия разработчиков и без перезапуска системы.
6 вопрос: как не дать кандидату сгенерировать свою кандидатуру на роль?
Как защититься от того, что кандидат просто попросит ChatGPT ответить за него?
К сожалению, полностью — никак. Но то же самое справедливо для телефонного скрининга: кандидат может читать с экрана заготовленные ответы, а вы не узнаете. При этом агент снимает с рекрутера прослушивание всех нерелевантных кандидатов — а значит, время тратится только на тех, кто потенциально подходит. И даже если кто-то прошел с помощью GPT — это всплывет на техническом интервью. А иногда это лишь подтвердит, что человек умеет пользоваться ИИ-инструментами и готов быстрее выполнять задачи с их помощью.
💡 Важно уточнить: описанный выше агент — это наш внутренний кейс, который сейчас активно тестируется и дорабатывается параллельно с обновлением карьерного портала.
А дальше, начиная с архитектуры, мы покажем уже универсальный шаблон AI-скрининг-агента, который мы выложили вAgent Platform. Именно его можно взять как отправную точку и адаптировать под свои процессы.

Архитектура: два агента, один пайплайн
Система построена по линейной схеме (pipeline). Три агента передают данные по цепочке: Триггер-сообщение → Агент-скринер → Агент отправки email
pic
Схема агента на холсте Agent Platform, шаблон агента уже доступен на платформе
Если открыть проект на Agent Platform, вы увидите несколько типов блоков:
  • Зеленый блок «Сообщение» — триггер диалога (агент запускается по сообщению пользователя)
  • Желтый блок кода — предзаполнение баз данных (вакансии, вопросы); здесь не нужно быть программистом, но кастомная логика поддерживается
  • Синие блоки — сами агенты (основной скринер и агент email)
  • Фиолетовые блоки с меткой «Инструмент» — тулы, которые агенты вызывают: чтение из базы данных, запись кандидата, отправка письма
Агент сам решает, какой инструмент вызвать и когда. 
Агент-скринер
Агент принимает сообщение кандидата и ведет диалог через шесть этапов:
 1. Приветствие — кандидат заходит на карьерный сайт, видит чат-виджет и пишет. Агент отвечает мгновенно. Честно представляется как AI-помощник.
2. Сбор персональных данных — имя, email (нужно для фиксации и дедупликации откликов).
3. Показ каталога вакансий — агент извлекает из базы данных доступные позиции. Кандидат выбирает — или агент помогает определиться.
4. Скрининг — агент обращается к базе данных и получает вопросы, созданные под выбранную вакансию. Пять вопросов про реальный опыт: конкретные ситуации, инструменты, решения, результаты.
5. Оценка языковой моделью— LLM считает баллы по системе флагов, формирует вердикт. Оценивается глубина, конкретика, релевантность требованиям.
Фрагмент промпта агента-скринера из шаблона Agent Platform:
👍 «Есть совпадения» — перечисли конкретные навыки и технологии кандидата, которые соответствуют требованиям вакансии.
⚠️ «Требует улучшения» — укажи навыки или технологии, которых не хватает, и дай практическую рекомендацию по развитию.
💡 «Подходит» — кратко объясни, почему кандидат в целом релевантен позиции, не повторяя конкретные навыки из блока 👍
⚡ «Точки роста» — кратко опиши основные пробелы кандидата без повторения пунктов из блока ⚠️
6. Приглашение к отклику — предлагает подать заявку независимо от результата.
pic
Скриншоты переписки с агентом на тестовом виджете
 Агент-шаблон работает с тремя базами данных:
  • Вакансии — предзаполняется вручную
  • Вопросы — привязаны к вакансиям, тоже предзаполняются
  • Кандидаты — заполняется агентом автоматически в процессе диалога
pic
Набор интеграций в Agent Platform
Модель проверяет результат скрининга перед тем, как он уходит дальше. Анализирует ответы кандидата, считает финальный балл, формирует резюме для HR: что сильно, что является точкой роста.
Агент отправки email
Принимает контекст от агента-скринера и формирует письмо рекрутеру. Письмо включает в себя:
  • Имя кандидата и email
  • Вакансию, на которую откликался
  • Итоговый процент
  • Рекомендацию («Очень сильная заявка, рекомендую рассмотреть в первую очередь»)
  • Точки роста и совпадения
  • Ответы на ключевые вопросы
Все это формируется автоматически — рекрутер открывает письмо и за 30 секунд понимает, стоит ли идти дальше.
pic
Скриншот письма, которое HR получает по итогам скрининга — с именем кандидата, вакансией, процентом, рекомендацией и точками роста.
Технологический стек 
Агент собран на Just AI Agent Platform. Вот из чего состоит система:
Встроенные БД —хранение вакансий, вопросов, критериев и системы флагов. В шаблоне используются встроенные БД платформы, но архитектуру можно адаптировать под любое внешнее хранилище. 
Мульти-LLM — платформа не привязана к одной модели. Мы используем GPT-4.1, но при необходимости можно переключиться на YandexGPT, GigaChat или другую — без переписывания архитектуры.
Редактируемые промпты — вся логика агента настраивается через интерфейс платформы. Промпты, критерии оценки, система флагов — все можно кастомизировать под проект.
Виджет на сайте — агент может быть размещен прямо на странице с вакансиями. Кандидат не переходит никуда — просто начинает диалог там, где уже находится.
Несколько вещей, которые мы поняли в процессе настройки промптов
Структура промпта важнее его размера.Мы заметили, что лучше работают понятные и структурированные инструкции без попытки запихнуть всю логику в один гигантский промпт. Если сценарий становится слишком сложным, часто проще декомпозировать задачу: разделить ответственность между несколькими агентами или вынести часть логики в отдельные тулы. 
Система флагов работает лучше числовых шкал. Когда мы пробовали оценивать ответы по шкале от 1 до 10, агент давал непредсказуемые результаты. Флаги — конкретнее: либо кандидат называет реальный инструмент, либо нет.
Инструкции по подсчету баллов — это отдельная большая задача. Нужно было сделать так, чтобы агент штрафовал за красные флаги и добавлял очки за зеленые — и делал это стабильно.
Проблемы, которые пришлось решать
Как и в любом проекте с LLM, мы столкнулись с рядом нетривиальных задач. Рассказываем, где пришлось подумать и поэкспериментировать.
Стабильность подсчета баллов и отладка инструкций агента
Первые версии агента плавали в оценках: на один и тот же ответ могли выдавать разный результат. Мы уточняли инструкции, добавляли примеры правильной и неправильной оценки, явно прописывали, что считается зеленым флагом для конкретной вакансии.
Как и в большинстве LLM-систем, даже небольшие изменения в формулировках инструкций влияли на качество результата. Поэтому стабильное поведение получилось не с первого раза, а через серию тестов и правок. Сейчас система работает более стабильно.
Передача контекста между агентами
В пайплайне из нескольких модулей важно обеспечить бесшовную передачу данных. Каждый следующий агент должен помнить весь предыдущий диалог. Это потребовало внимательного проектирования архитектуры и управления состоянием диалога.
Регулирование количества инструментов
Чем больше инструментов у агента, тем вероятность, что модель начнет путаться: забывать часть инструкций, делать лишние вызовы или тратить больше токенов на выбор действия.
Мы пришли к тому, что одному агенту лучше давать ограниченный набор инструментов — примерно до 5 тулов с четко разделенными задачами.
Как запустить у себя
В первую очередь рекомендуем оценить, насколько имеет смысл такая автоматизация, мы выделили несколько критериев, когда это имеет смысл, а когда — нет.
 Стоит автоматизировать, если:
  •  У вас больше 20–30 откликов в неделю на повторяющиеся вакансии
  •  Скрининг предсказуем: одни и те же вопросы, понятные критерии
  •  Рекрутер тратит больше трех часов в день на первичные контакты
  •  Есть потребность в 24/7-доступности, потому что кандидаты пишут вечером
Не стоит, если:
  •  Вакансии штучные и уникальные — каждый кандидат требует индивидуального подхода
  •  Процесс слишком нерегулярный, чтобы формализовать критерии
  •  Нет ответственного, который будет обрабатывать входящие от агента
 Если все же хотите повторить, рассказываем короткий путь:
 Шаг 1. Подготовьте data-сет
Сформулируйте для каждой вакансии 4–6 вопросов, проверяющих реальный опыт, а не теорию. Составьте список зеленых и красных флагов. Лучше делать это вместе с нанимающим менеджером.
Шаг 2. Заполните базы данных
Загрузите вакансии, вопросы и критерии в базу данных, чтобы агент мог обращаться к ним. Кандидаты пишутся туда автоматически в процессе диалога.
Шаг 3. Настройте агентов
На холсте Agent Platform — два агента: скринер и отправщик email. Для каждого: модель, роль, цель, инструкции. Настройте тулы: чтение из БД, запись, отправка письма — их функционал можно доработать и кастомизировать под запрос.
Шаг 4. Протестируйте на нескольких сценариях
Пройдите скрининг сами — за сильного кандидата и за слабого. Проверьте письмо, которое получает рекрутер. Убедитесь, что система флагов работает правильно на ваших сценариях. При необходимости скорректируйте промпт, критерии оценки и и логику начисления баллов под специфику вакансий.
Шаг 5. Интегрируйте на карьерный сайт
Agent Platform поддерживает разные каналы: веб-виджет, Telegram, WhatsApp. Для карьерного сайта — можно использовать виджет.
Результаты
Запуск AI-рекрутера принес измеримые результаты как для кандидатов, так и для команды. Посмотрим на показатели:
•   Доходимость кандидатов до конца скрининга — около 98%. Это выше, чем при стандартных веб-формах, потому что диалог воспринимается естественнее.
•   Реакция кандидатов — преимущественно позитивная. Особенно среди опытных специалистов, которые ценят скорость и не хотят тратить время на формальный звонок.
•   Экономия рекрутерского времени — рекрутер смотрит только на тех, кто набрал ≥65 баллов, и читает уже готовую сводку по каждому. Не нужно слушать одинаковые ответы от огромного количества кандидатов в день.
•   Скорость реакции — кандидат, написавший в 11 вечера, получает результат мгновенно. К утру рекрутер видит список квалифицированных кандидатов, а не входящие сообщения, ждущие ответа.
Что дальше
Сейчас мы доделываем боевую версию: добавляем парсинг резюме, чтобы агент мог сразу работать с загруженным документом, расширяем базу вакансий, дорабатываем систему хранения кандидатов для повторных откликов.
Шаблон «Текстовый AI-рекрутер» мы выложили в открытый доступ в библиотеке Agent Platform. Можно зарегистрироваться, найти его и кастомизировать под свои вакансии — без написания кода с нуля.
Если работаете над похожей задачей или уже пробовали автоматизировать HR-процессы — пишите в комментарии, интересно сравнить опыт.
Если работали над подобными агентными системами, делитесь опытом в комментариях. А если интересно глубже погрузиться в архитектуру — заходите в наше Telegram-сообщество для разработчиков. Там обсуждаем реальные кейсы, помогаем друг другу в настройке и делимся новостями платформы.-Источник
 
Loading...
Error