Инструкции

Когда в день вам присылают 400 резюме на одну вакансию, «посмотреть всех» физически не получится. Зато это выглядит прямо как задача под автоматизацию! Итак, у меня есть вакансия и огромная пачка PDF-файлов с резюме. Надо понять, в каких из них действительно подтверждаются нужные компетенции, где информации не хватает и кого стоит посмотреть в первую очередь. Мы не будем автоматизировать сам найм или отправку отказов. В кейсе ниже LLM будет составлять техническую выжимку и помогать разобрать очередь. Но финальное решение останется за человеком. По идее можно было бы открыть любую ИИшницу, загрузить туда пачку резюме и собрать результаты. Но это не автоматизация, а ерунда. Поэтому мне нужен API, который можно подключить и встроить в собственный процесс проверки резюме. Для меня тут важен именно уровень абстракции. Я не хочу искать GPU, скачивать веса модели, подбирать версию CUDA, поднимать vLLM, рассчитывать, влезет ли модель в видеопамять, настраивать масштабирование, мониторить отдельный ML-зоопарк и выяснять, почему после обновления драйвера все снова упало. Дисклеймер: в статье описывается один из возможных сценариев применения ИИ, а не готовое решение для рекрутинга. Перед внедрением в продакшен убедитесь, что не нарушаете 152-ФЗ и другие регуляторные требования, а также не поручаете ИИ принятие решений, которые лучше оставить за человеком. В Selectel мы не доверяем ИИ даже первичную оценку резюме. Идея и подготовка Да, у меня есть домашний LLM-стек, собранный до всех этих кризисов с памятью, но это решение мне не подошло. Оно требует постоянно держать эту махину включенной, а я частенько нахожусь в перелетах и сильно тревожусь, если оставил дома «включенный утюг». Поэтому выбор пал на Dedicated inference. Все работает в одном из московских дата-центров Selectel, не потребляет мое электричество и доступно в любое время и в любом месте. То что нужно! Self-hosted — это хорошо, но под некоторые задачи все же лучше выбирать инструмент, который будет комфортнее. Интеграция модели в мой проект и бизнес-логика остаются на моей стороне, сервис разделяет эти зоны. То есть Selectel дает мне работающий эндпоинт, а я уже решаю, как использовать его в своем коде. Наша задача — взять описание конкретной вакансии, извлечь текст из резюме, проверить наличие подтвержденного опыта по заранее заданным критериям и собрать понятный отчет для HR. Важно — не улучшать резюме, не оценивать человека, не анализировать фотографию, возраст или семейное положение. А именно сопоставить профессиональный опыт из документа с требованиями конкретной вакансии. В результате вместо папки с 400 резюме я хочу получить таблицу: КандидатСоответствиеИтогresume-001.pdf88/100соответствует профилюresume-002.pdf61/100требуется ручная проверкаresume-003.pdf34/100недостаточно подтвержденийresume-004.pdf42/100много ключевых слов, мало доказательствresume-005.pdf84/100соответствует профилю При этом по каждому баллу должны быть видны доказательства из исходного текста: Если доказательства нет, модель должна честно написать: «В тексте резюме подтверждение не найдено», а не додумывать опыт кандидата. Для анализа резюме подойдет обычная text-to-text-модель. На вход отправляем вакансию, критерии и извлеченный текст, на выходе ожидаем структурированный JSON. Никакие model tools для этого не потребуются. Последовательностью действий управляет Python: Модель не должна сама открывать файл, выполнять команды или менять статус кандидата в кадровой системе. Она решает только одну задачу — делает структурированную оценку по заданным критериям на основе текста из резюме. Для эксперимента я взял t-tech/T-pro-it-2.1. Модель доступна в актуальном каталоге Dedicated inference вместе с T-lite, Qwen, Gemma и другими text-to-text-моделями. Почему именно она? Потому что входные данные у меня русскоязычные. При этом в резюме встречаются английские названия технологий, команды, аббревиатуры и описание технических проектов. От модели мне нужен не творческий текст, а строгое следование инструкции: обработать заранее заданный список критериев, не придумывать отсутствующий опыт, привести доказательства, вернуть валидный JSON, не рассчитывать итоговый балл самостоятельно. Последний пункт тут очень важен. Модель определяет уровень подтвержденного опыта, итоговую математику выполняет Python. Иначе одинаковые оценки критериев однажды могут превратиться в 78 баллов, а в другой раз — в 83. Модели, конечно, виднее, но меня такой гидрометцентр не устраивает. По архитектуре получилась следующая схема: LLM находится примерно в середине конвейера. Она не управляет процессом, не принимает кадровое решение и не формирует итоговый балл. Все опасные операции остаются в обычном коде. Роботу отдаем только самую рутину, все остальное реализуем самостоятельно. Для эксперимента я придумал вакансию DevOps-инженера уровня middle. Так мне будет проще проверить модель самостоятельно, если она вдруг решит, что человек с четырьмя годами Django и одним домашним Docker Compose идеально подходит на эксплуатацию кластера Kubernetes. Мок с описанием вакансии (чуть позже закинем его в /vacancies/middle-devops.yaml): Сумма всех весов 100. Каждый критерий модель оценивает от 0 до 4. Python переводит уровень в баллы: баллы критерия вес × уровень / 4. Например: Почему нельзя просто искать ключевые слова? Изначально я хотел решить это регулярными выражениями: Но тогда возникнет неувязочка с кандидатом, у которого есть такой блок: Он всех обманет и получит максимальный балл, хотя из текста вообще не ясно: использовал ли он эти инструменты в работе, настраивал ли что-нибудь самостоятельно, видел ли продакшен, отвечал ли за результат, или просто скопировал список из вакансии. С другой стороны, сильный SRE может не использовать Ansible, но несколько лет управлять конфигурацией через SaltStack. Поиск по ключевым словам скажет: «Ansible не найден — ноль баллов». А нормальный анализ должен выявить, что SaltStack решает тот же класс задач и подтверждает опыт автоматизации конфигурации. Вот здесь модель будет прям полезна и в тему. Для статьи я не стал брать настоящие резюме. Вместо этого подготовил пять синтетических PDF с заранее известными особенностями. Так я сразу проверю работу пайплайна без слива персональных данных и буду понимать, что моя система должна найти. Ну или как говорят в простонародье — использую моки. Если модель занимается только поиском ключевых слов, она занижает оценку. Так, болванки готовы, теперь рисуем структуру проекта, у меня получилось так: Создаем сервис в облаке Теперь надо создать инференс-сервис. Идем в панель управления → Продукты → Foundation Models Catalog и выбираем: Для теста я выбрал: Модель: t-pro-it-2-1, Инстансы: 1, Масштабирование: фиксированное, GPU: 4 x NVIDIA L4 (24 ГБ), Контекст: 16 384. Конфигурацию после создания изменить нельзя, а количество инстансов можно масштабировать потом отдельно. Создание сервиса может занимать около 15 минут, так что наберитесь терпения и попейте кофейку. Кстати, дополнительно можно взгромоздить WebUI. Но в моей задаче оно не требуется, поэтому этот шаг пропускаю. После запуска сервис выдал креды: Создаем .env-файл и заполняем его полученными кредами: И сразу добавляем его в .gitignore, API-ключу делать в Git нечего. Перед написанием приложения отправляем банальный запрос через curl, чтобы сразу все проверить и не городить огород с багами. Тестовый запрос прошел, давайте сделаем еще один и смажем JQ: Ожидаемый результат получен, можно ехать дальше. Если получаете 401 Unauthorized, то проверяйте креды. Вот для этого тесты и нужны, чтобы потом вся задумка не превратилась в тыкву. Теперь устанавливаем зависимости: Далее устанавливаем пакеты: Набор пакетов я выбрал, потому, что: pymupdf извлекает текст из PDF, requests обращается к Dedicated inference, pydantic проверяет ответ модели, pyyaml читает описание вакансии, jinja2 формирует HTML-отчет, python-dotenv загружает настройки. Дальше будет много кода. На роль Python-разработчика я не претендую, поэтому для профильного специалиста код может выглядеть как лапша. В любом случае код рабочий и меня он вполне устраивает. Создаем src/pdf_parser.py: Проверяем: В результате получаем: PyMuPDF не выполняет OCR. Если PDF состоит из отсканированных изображений, текстового слоя там может не быть. В этом случае я не отправляю пустой документ в модель, а помещаю резюме в очередь ручной проверки: Теоретически можно подключить Tesseract или отдельную OCR-модель, но я предпочитаю, чтобы под один проект была одна модель. Поэтому в эксперименте я использую PDF с нормальным текстовым слоем. Обезличиваем документ В настоящем резюме содержатся персональные данные: имя; телефон; почта; адрес; дата рождения; ссылки на соцсети. Для проверки профессионального соответствия они не нужны, да и трудовое законодательство запрещает ограничения и преимущества по обстоятельствам, не связанным с деловыми качествами кандидата. Это часть цитаты из Консультанта. Создаем src/anonymizer.py: Оговорюсь, что здесь у меня демонстрационный фильтр, а не продакшен-система обезличивания. Фильтр удалит очевидный телефон и email, но может не распознать имя или необычно записанный адрес. В продакшене такой этап придется усиливать и отдельно проверять с юристами и специалистами по ИБ. Но для синтетических документов этого достаточно. Описываем ожидаемый ответ Создаем src/models.py: Библиотека pydantic проверяет: наличие всех полей, типы значений, диапазон уровня от 0 до 4, допустимые статусы, максимальное количество доказательств и вопросов. Модель может вернуть вот такой результат: Тогда проверка завершится ошибкой. Создаем промпт Теперь пришло время создать промт. Создаем файл src/fmc_client.py и сначала пишем системную инструкцию: Пользовательский промт будет содержать: Так модель знает, какие именно поля мы будем проверять. Запускаем Dedicated inference Дополняем файл src/fmc_client.py: Параметр temperature я устанавливаю в ноль, чтобы снизить случайность ответа. Но даже при нулевой температуре полная повторяемость не гарантируется. Поэтому позже отдельно проверим стабильность на нескольких запусках. Не доверяем цитатам модели В ответе модель должна приводить доказательства из резюме. Но что мешает ей меня обмануть или вообще придумать красивую цитату? Чтобы избежать этого, создаем функцию: Если модель вернула Самостоятельно спроектировал Kubernetes-кластер, а в резюме такой строки нет, доказательство помечается как неподтвержденное. Это не идеальная проверка: модель может убрать знак препинания или сократить цитату. Но для первого варианта я специально сделал дословные фрагменты, чтобы результат можно было проверить обычным поиском по строке. Считаем итоговый балл Создаем файл src/scoring.py: Как трактовать результаты: match — в резюме достаточно подтверждений, чтобы посмотреть кандидата в приоритетном порядке. manual_review — есть спорные места, проблемы с извлечением текста или неполное покрытие требований. Такое резюме нужно проверить вручную. no_match — в документе недостаточно подтверждений по текущему профилю вакансии. В общем, no_match не должен автоматически отправлять кандидату отказ. Это результат сопоставления текста с конкретной рубрикой, который HR может проверить и изменить. Загружаем вакансию Проверка суммы весов спасет от ситуации, когда после добавления нового критерия максимальный результат становится 115 из 100. Нам такое, естественно, не подходит, поэтому тут лучше переборщить со внимательностью к деталям. Собираем HTML-отчет Создаем templates/report.html: Рендерим отчет Создаем src/report.py: Собираем все в один запуск Создаем src/main.py: Итого получаем такую структуру: Запускаем сервис Спустя пару минут, в папке results видим новые файлы и сам результат в консоли: Можно сказать, это успех. Оно работает! Теперь можно посмотреть красивые отчеты по каждому резюме: Не стал бы утверждать, что это прям готовая ATS, которую можно внедрять к себе в CRM и пачками отсеивать вайбкодеров. Вот что получается по кандидату №5, который набрал 78 баллов: Рисуем табличку, чтобы нагляднее было: Итого: 2 совпадения из 5 (40%). два кандидата получили match, два отправлены на ручную проверку и один получил no_match. При этом модель не спрятала потенциально подходящих кандидатов в no_match, выбрав для спорных случаев более осторожный manual_review. Идем уверенно! Самые интересные здесь два последних резюме. Кандидат №4 проверяет, даст ли модель высокий балл за красивый список технологий без доказательств. Кандидат №5 показывает, способна ли модель учитывать альтернативный стек, а не искать только точные совпадения с вакансией. Проверяем стабильность Одно и то же резюме прогоняю пять раз: Сравниваю итоговый балл, verdict, уровни критериев, доказательства и вопросы для интервью. Результат полностью стабилен: разброс 0 баллов, совпадение вердиктов 5 из 5, уровни всех критериев совпали, доказательства совпали дословно, вопросы для интервью совпали дословно. Тут важно, что если балл гуляет на два-три пункта, с этим еще можно жить. Если один запуск говорит match, а другой no_match, такой инструмент использовать нельзя, пока не будет стабильности. Тоже учитывай этот момент. Что еще можно измерить Валидность JSON valid_json_rate успешно проверенные ответы / все ответы. То есть, например, при 49 валидных ответах из 50 valid_json_rate 98%. Достоверность доказательств evidence_match_rate дословно найденные цитаты / все цитаты. Если модель придумала цитату, результат должен быть помечен для ручной проверки. Время обработки Для каждого PDF сохраняется latency_seconds: Оценка времени для 400 резюме При последовательной обработке общее время будет равно среднему времени на проверку одного резюме × 400. То есть если одно резюме обрабатывается 12 секунд, то 12 × 400 4 800 секунд ≈ 80 минут. Но это пока только арифметическая оценка. Реальное время зависит от размера резюме, конфигурации инференс-сервиса, нагрузки, количества одновременных запросов, лимитов сервиса и повторных запросов после ошибок. После последовательного теста можно аккуратно добавить два или четыре worker-потока и сравнить throughput. Сразу запускать 50 параллельных запросов только потому, что это все надо срочно и вчера — плохая идея. Ложные отрицательные результаты Главный вопрос для такой системы — не спрятали ли мы сильного кандидата в хвост выдачи? Если HR вручную отметил 20 подходящих кандидатов, а система поместила 18 из них в приоритетную очередь, то recall 18 / 20 0.9. В этом сценарии лучше показать человеку несколько лишних резюме, чем потерять одного подходящего специалиста. Поэтому пороги я бы настраивал в сторону manual_review, а не агрессивного no_match. Если опасаетесь, что это будет слишком затратно для бюджета на инфраструктуру, то нет. Dedicated inference использует модель оплаты по потреблению облачных ресурсов, а не токенов. То есть средства списываются за ресурсы инференс-сервера: GPU, vCPU, RAM и диск, а количество токенов отдельно не тарифицируется. Здесь еще важный момент в том, что модель оценивает не только ключевые слова. Это важно, чтобы сильный SRE-инженер с SaltStack и Argo CD не получил ноль баллов за отсутствие Ansible и GitLab CI. К тому же, по каждому критерию есть объяснение. Так что благодаря настройке в сторону manual_review повышается шанс, что HR увидит не абстрактные «88 баллов», а конкретные фрагменты из резюме. Например, что кандидат снизил MTTR с 50 до 20 минут. Итоговый балл считается обычным кодом, LLM не занимается математикой и не определяет пороги. Уровни критериев всегда дают одинаковый результат. PDF не отправляется в модель целиком, сначала локально извлекается текст, затем удаляются очевидные персональные данные. Модель получает только очищенную текстовую версию. Tools не нужны, их отсутствие вообще не мешает. Все действия заранее определены: Где начались неожиданности PDF — это не всегда текст. Красивое резюме может извлекаться в странном порядке. Таблица навыков иногда перемешивается с опытом, а скан вообще не содержит текстового слоя. Поэтому я сохраняю извлеченный текст, чтобы самому посмотреть, что конкретно уйдет в модель. Ключевые слова продолжают влиять на результат. Даже с хорошим промптом модель может завышать кандидата, у которого перечислено 20 технологий. Поэтому в инструкции явно написано: Упоминание без применения — не больше 1 балла. Именно для этого нужен отдельный тест с keyword stuffing, на случай, когда кандидат пытается обмануть подобную систему распознавания. Еще модель иногда переформулирует доказательства, поэтому я требую дословные цитаты. Но тут выясняется, что LLM может слегка переписать исходную фразу. Тогда простая проверка подстроки считает цитату неподтвержденной. Можно перейти к нечеткому сравнению, но я бы сначала оставил строгий режим. Лучше получить лишнее предупреждение, чем принять придуманное доказательство за настоящее. Порог 75 баллов — не истина, настоящие пороги надо подбирать на размеченном наборе резюме и отдельно для каждой вакансии. Резюме не описывает человека полностью, так что если технология не указана, это еще не означает, что кандидат с ней не работал. Поэтому статусы я назвал not_found, а не candidate_does_not_know. Но это уже детали и шлифовка напильником. Чего нет в этом сервисе Описанный мной сервис: не отправляет отказы, не пишет кандидатам, не назначает встречи, не меняет статусы в ATS, не удаляет резюме, не принимает решение о найме, не оценивает личность человека, не анализирует возраст, пол или фотографию. В реальном использовании HR по итогу просто получает список кандидатов и открывает оригинальные документы. Моя автоматизация помогает добраться до сильного кандидатов быстрее, но не убирает человека из процесса. Итоги сего мероприятия Начиналось все с простой картины: одному HR нужно было за день разобрать 400 резюме в PDF, не отсеять сильных кандидатов и не пропустить слабых. Вся механика выполняется на обычном Python. Модель отвечает только за смысловую часть: ищет в резюме подтверждения профессионального опыта и сопоставляет их с требованиями вакансии. Я выбрал text-to-text-модель, создал сервис и получил готовый эндпоинт, не разворачивая GPU-инфраструктуру самостоятельно. Самое важное — я не старался превратить LLM в цифрового HR-директора. Она не решает судьбу кандидата, но помогает человеку разобрать входящий поток и показывает, на какие резюме стоит посмотреть в первую очередь. По-моему, это как раз нормальная автоматизация — не заменить специалиста, а забрать у него рутину, от которой он уже плачет кровавыми слезами. Конец!