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

Привет, Хабр! На связи команда 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 — это всплывет на техническом интервью. А иногда это лишь подтвердит, что человек умеет пользоваться ИИ-инструментами и готов быстрее выполнять задачи с их помощью.

Архитектура: два агента, один пайплайн

Система построена по линейной схеме (pipeline). Три агента передают данные по цепочке: Триггер-сообщение → Агент-скринер → Агент отправки email

Если открыть проект на Agent Platform, вы увидите несколько типов блоков:

• Зеленый блок «Сообщение» — триггер диалога (агент запускается по сообщению пользователя)

• Желтый блок кода — предзаполнение баз данных (вакансии, вопросы); здесь не нужно быть программистом, но кастомная логика поддерживается

• Синие блоки — сами агенты (основной скринер и агент email)

• Фиолетовые блоки с меткой «Инструмент» — тулы, которые агенты вызывают: чтение из базы данных, запись кандидата, отправка письма

Агент сам решает, какой инструмент вызвать и когда. 

Агент-скринер

Агент принимает сообщение кандидата и ведет диалог через шесть этапов:

 1. Приветствие — кандидат заходит на карьерный сайт, видит чат-виджет и пишет. Агент отвечает мгновенно. Честно представляется как AI-помощник.

2. Сбор персональных данных — имя, email (нужно для фиксации и дедупликации откликов).

3. Показ каталога вакансий — агент извлекает из базы данных доступные позиции. Кандидат выбирает — или агент помогает определиться.

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

5. Оценка языковой моделью — LLM считает баллы по системе флагов, формирует вердикт. Оценивается глубина, конкретика, релевантность требованиям.

Фрагмент промпта агента-скринера из шаблона Agent Platform:

👍 «Есть совпадения» — перечисли конкретные навыки и технологии кандидата, которые соответствуют требованиям вакансии.⚠️ «Требует улучшения» — укажи навыки или технологии, которых не хватает, и дай практическую рекомендацию по развитию.💡 «Подходит» — кратко объясни, почему кандидат в целом релевантен позиции, не повторяя конкретные навыки из блока 👍⚡ «Точки роста» — кратко опиши основные пробелы кандидата без повторения пунктов из блока ⚠️

6. Приглашение к отклику — предлагает подать заявку независимо от результата.

 Агент-шаблон работает с тремя базами данных:

• Вакансии — предзаполняется вручную

• Вопросы — привязаны к вакансиям, тоже предзаполняются

• Кандидаты — заполняется агентом автоматически в процессе диалога

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

Агент отправки email

Принимает контекст от агента-скринера и формирует письмо рекрутеру. Письмо включает в себя:

• Имя кандидата и email

• Вакансию, на которую откликался

• Итоговый процент

• Рекомендацию («Очень сильная заявка, рекомендую рассмотреть в первую очередь»)

• Точки роста и совпадения

• Ответы на ключевые вопросы

Все это формируется автоматически — рекрутер открывает письмо и за 30 секунд понимает, стоит ли идти дальше.

Технологический стек 

Агент собран на 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-сообщество для разработчиков. Там обсуждаем реальные кейсы, помогаем друг другу в настройке и делимся новостями платформы.