Привет, Хабр! На связи команда Just AI. Мы занимаемся разработкой 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 ответить за него?

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

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

Система построена по линейной схеме (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. Заполните базы данных

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

Срок хранения данных и уровни доступа должны соответствовать внутренним HR‑процессам компании и политике обработки персональных данных.

Шаг 3. Настройте агентов

На холсте Agent Platform — два агента: скринер и отправщик email. Для каждого: модель, роль, цель, инструкции. Настройте тулы: чтение из БД, запись, отправка письма — их функционал можно доработать и кастомизировать под запрос.

Шаг 4. Протестируйте на нескольких сценариях

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

Шаг 5. Интегрируйте на карьерный сайт

Agent Platform поддерживает разные каналы: веб‑виджет, Telegram, WhatsApp. Для карьерного сайта — можно использовать виджет.

Результаты

Запуск AI‑рекрутера принес измеримые результаты как для кандидатов, так и для команды. Посмотрим на показатели:

• Доходимость кандидатов до конца скрининга — около 98%. Это выше, чем при стандартных веб‑формах, потому что диалог воспринимается естественнее.

• Реакция кандидатов — преимущественно позитивная. Особенно среди опытных специалистов, которые ценят скорость и не хотят тратить время на формальный звонок.

• Экономия рекрутерского времени — рекрутер в первую очередь смотрит на тех кандидатов, кто набрал ≥65 баллов, и читает уже готовую сводку по каждому. Не нужно слушать одинаковые ответы от огромного количества кандидатов в день.

• Скорость реакции — кандидат, написавший в 11 вечера, получает результат мгновенно. К утру рекрутер видит список квалифицированных кандидатов, а не входящие сообщения, ждущие ответа.

Что дальше

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

Шаблон «Текстовый AI‑рекрутер» мы выложили в открытый доступ в библиотеке Agent Platform. Можно зарегистрироваться, найти его и кастомизировать под свои вакансии — без написания кода с нуля.

Если работаете над похожей задачей или уже пробовали автоматизировать HR‑процессы — пишите в комментарии, интересно сравнить опыт.

Если работали над подобными агентными системами, делитесь опытом в комментариях. А если интересно глубже погрузиться в архитектуру — заходите в наше Telegram‑сообщество для разработчиков. Там обсуждаем реальные кейсы, помогаем друг другу в настройке и делимся новостями платформы.