AI-агрегатор вакансий и резюме

Для клиента из сферы IT-рекрутинга команда eq.team разработала AI-агрегатор вакансий и резюме — систему, которая автоматически собирает и анализирует вакансии и резюме из 60+ IT-чатов и Telegram-каналов. В основе продукта — связка Telegram Bot API для сбора данных и OpenAI API для интеллектуальной обработки: система извлекает структурированные поля (стек технологий, грейд, зарплатная вилка, формат работы, локация) из неструктурированных текстовых сообщений и группирует дубликаты вакансий, опубликованных в разных источниках одновременно. Результат — единая, очищенная от повторов лента, в которой HR-специалист за минуты находит то, на что раньше уходили часы ручного мониторинга.

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

Клиент — рекрутинговая команда, специализирующаяся на подборе IT-специалистов: разработчиков, аналитиков, DevOps-инженеров, продакт- и проджект-менеджеров. Значительная часть релевантных вакансий и откликов кандидатов в этой нише публикуется не на классических job-бордах, а в профильных Telegram-чатах и каналах — там информация появляется быстрее, но живёт недолго и тонет в потоке сообщений.

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

HR-специалисты клиента тратили до 3 часов в день на просмотр 60+ IT-чатов в поиске подходящих кандидатов и вакансий. Каждое сообщение приходилось читать вручную, сверять требования, копировать контакты в отдельную таблицу — при этом часть релевантных откликов терялась из-за скорости обновления чатов и дублирования вакансий в нескольких каналах одновременно. Нужна была система, которая возьмёт на себя рутинный мониторинг и оставит HR-специалистам только финальное решение — кому писать.

Формально задача распадалась на несколько подзадач, каждая из которых по отдельности нетривиальна:

• Непрерывный сбор данных из множества источников. Нужно было в реальном времени получать новые сообщения из 60+ каналов и чатов, не нарушая ограничений Telegram и не теряя сообщения при пиковой нагрузке.
• Понимание неструктурированного текста. Вакансии и резюме пишут люди в свободной форме: где-то зарплата указана вилкой, где-то «по договорённости», стек может быть перечислен списком или упомянут в середине абзаца. Регулярными выражениями такое не разобрать надёжно.
• Устранение дублей. Одна и та же вакансия часто публикуется сразу в нескольких каналах с незначительными отличиями в тексте — система должна распознавать это как один объект, а не как несколько разных.
• Стабильность к изменению форматов. Каналы меняют шаблоны публикаций, появляются новые источники — решение не должно ломаться при каждом таком изменении.

Совместно с клиентом на старте зафиксировали измеримые цели, по которым оценивали результат:

• Сократить время ежедневного мониторинга источников минимум в 2–3 раза.
• Свести к единой ленте все отслеживаемые каналы с автоматическим удалением дублей.
• Обеспечить извлечение ключевых полей вакансии (стек, грейд, зарплата, локация, формат) с точностью, достаточной для фильтрации и поиска.
• Сделать добавление новых источников операцией уровня конфигурации, а не разработки.
• Удерживать стоимость обработки одного сообщения через LLM в предсказуемых рамках при объёме в сотни тысяч сообщений в месяц.

Проект начался с аудита источников: собрали список из 60+ Telegram-чатов и каналов по IT-найму, определили паттерны, по которым в сообщениях публикуются вакансии и резюме — они сильно различаются по формату между каналами. На основе этого аудита сформировали требования к структуре данных: какие поля извлекать, какие из них обязательные, а какие опциональные, и как нормализовать значения (например, приводить зарплату к диапазону в рублях с единым шагом).

Дальше разработку вели в три этапа:

• Сбор данных. Парсер подключается к Telegram API и собирает новые сообщения из отслеживаемых источников в реальном времени. Каждое входящее сообщение попадает в очередь на обработку, что позволяет сглаживать пиковые нагрузки и не терять данные при всплесках активности в каналах.
• Обработка через OpenAI API. Каждое сообщение проходит через LLM, которая определяет тип записи (вакансия/резюме), извлекает структурированные поля и приводит их к единому формату. Ответ модели запрашивается в структурированном виде (JSON), чтобы результат можно было напрямую сохранять в базу без дополнительного разбора.
• Дедупликация и агрегация. Система сравнивает новые записи с уже обработанными, объединяет дубликаты вакансий, опубликованных в нескольких каналах, и формирует единую ленту.

Пилотная версия была запущена на 15 источниках за 3 недели — это позволило проверить точность извлечения данных и доработать промпты до масштабирования на все 60+ каналов. Пилот сознательно ограничили небольшим числом каналов: на реальных данных быстро выявились крайние случаи (сообщения-«простыни» с несколькими вакансиями сразу, посты с картинками и минимумом текста, репосты), под которые донастроили логику обработки до того, как масштабировать систему и увеличить расход на API.

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

• Слой сбора. Коннекторы к Telegram, которые получают новые сообщения из отслеживаемых каналов и чатов и складывают их в очередь на обработку. Список источников хранится в конфигурации, поэтому добавление нового канала не требует изменения кода.
• Очередь и воркеры. Обработка сообщений вынесена в фоновые задания. Воркеры разбирают очередь, обращаются к LLM и сохраняют результат. Количество воркеров можно увеличивать под нагрузку, соблюдая при этом лимиты запросов к внешним API.
• Слой обработки (LLM). Отвечает за классификацию сообщения и извлечение структурированных полей. Здесь же реализована защита от некорректных ответов модели и повторные попытки при временных ошибках.
• Хранилище. PostgreSQL хранит нормализованные вакансии и резюме, историю источников и связи между дубликатами. Структурированная схема позволяет строить фильтры и поиск по любому из извлечённых полей.

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

• Классификация. Сначала модель определяет, что перед ней: вакансия, резюме или нерелевантное сообщение (реклама, обсуждение, оффтоп). Нерелевантные сообщения отсеиваются и не засоряют ленту.
• Извлечение полей. Для вакансий и резюме модель извлекает набор полей — должность, стек технологий, грейд, зарплатную вилку, формат работы (офис/удалёнка/гибрид), локацию, контакт для связи. Запрос к модели сформулирован так, чтобы она возвращала строго структурированный JSON с заранее определённой схемой полей.
• Нормализация. Извлечённые значения приводятся к единому виду: зарплата — к числовому диапазону в одной валюте, стек — к списку канонических названий технологий, грейд — к фиксированному перечню (junior/middle/senior/lead).

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

Одна и та же вакансия в IT-нише регулярно публикуется в нескольких каналах — иногда дословно, иногда с перефразированием и разными контактами. Без дедупликации лента быстро превращается в поток повторов, и ценность агрегатора теряется. Система сравнивает новые записи с уже обработанными по совокупности признаков — извлечённым полям вакансии и содержательному сходству текста — и связывает дубликаты в единый объект. HR-специалист видит одну запись с указанием всех источников, где она встречалась, а не десять почти одинаковых сообщений.

Агрегация решает и обратную задачу: собирает разрозненные публикации в связную ленту с фильтрами. Благодаря тому, что все поля извлечены и нормализованы на этапе обработки, поиск работает по структурированным критериям — например, «senior-разработчики на Go с удалёнкой и вилкой от определённой суммы», а не по подстроке в тексте.

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

• OpenAI API (GPT) — NLP-обработка: классификация сообщений и извлечение структурированных полей из свободного текста.
• Telegram Bot API — сбор сообщений из отслеживаемых каналов и чатов в реальном времени.
• PHP/Laravel — бэкенд, очереди и фоновая обработка сообщений. Laravel даёт готовую инфраструктуру очередей, планировщик задач и удобную работу с внешними API.
• PostgreSQL — хранение структурированных вакансий и резюме, истории источников и связей между дубликатами.

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

• Разнородность форматов. В каждом канале свой шаблон публикации. Регулярные выражения давали слишком много ошибок, поэтому разбор целиком отдали языковой модели — она устойчива к вариативности формулировок и структуры текста.
• Изменение шаблонов со временем. Каналы меняют оформление постов. Поскольку разбор делает LLM по смыслу, а не по жёсткому шаблону, при изменении формата достаточно донастроить промпт — код парсера остаётся неизменным.
• Контроль стоимости обработки. При сотнях тысяч сообщений в месяц расходы на API могли выйти за рамки. Стоимость держали под контролем за счёт предварительной фильтрации нерелевантных сообщений, компактных промптов и структурированного формата ответа, который не требует повторных обращений к модели.
• Ограничения внешних API. И Telegram, и OpenAI имеют лимиты на частоту запросов. Очередь с управляемым числом воркеров и повторными попытками при временных ошибках позволяет соблюдать эти лимиты и не терять сообщения при пиковой нагрузке.
• Достоверность извлечённых данных. Чтобы модель не подставляла отсутствующие данные, в промптах явно задано поведение для случаев «поле не указано». Это важнее для рекрутинга, где ошибочная зарплатная вилка или неверный грейд обесценивают запись.

• Сокращено время на поиск подходящих кандидатов и вакансий в 3 раза — с 3 часов до примерно 1 часа в день.
• Обработано более 1 000 000 сообщений с момента запуска.
• Устранено дублирование вакансий из разных каналов — HR-специалисты видят уникальные записи вместо повторов.
• Система работает без постоянного участия разработчиков — новые источники добавляются конфигурацией, без изменения кода.
• Единая лента с фильтрами по структурированным полям заменила ручной просмотр десятков разрозненных каналов.

Главный измеримый эффект — освобождённое время HR-специалистов. Экономия примерно 2 часов в день на человека — это высвобождение значительной доли рабочего времени, которое раньше уходило на механический мониторинг, а теперь тратится на оценку кандидатов и коммуникацию, то есть на работу, напрямую влияющую на закрытие вакансий. При этом качество покрытия источников выросло: система не «устаёт» и не пропускает сообщения из-за скорости ленты, а значит, релевантные кандидаты не теряются. Отдельно снижается зависимость процесса от конкретного сотрудника — знание о том, «где и что искать», зашито в систему, а не в голову отдельного рекрутёра.

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

После запуска в продакшн команда eq.team обеспечила период гарантийной поддержки: мониторинг стабильности парсинга, донастройку промптов при изменении формата сообщений в источниках и оперативное устранение сбоев интеграции с Telegram API. Гарантийная поддержка означает, что система не остаётся один на один с меняющейся средой — при появлении новых источников или изменении шаблонов публикаций мы оперативно адаптируем обработку, сохраняя точность извлечения данных.

Проект агрегатора прошёл тот же путь, что и большинство продуктов, которые делает eq.team:

• Аудит и постановка. Разбираемся в источниках данных и бизнес-процессе, фиксируем измеримые цели.
• Пилот на ограниченном объёме. Проверяем гипотезы на реальных данных до масштабирования, чтобы не тратить бюджет на нерабочие решения.
• Масштабирование. Расширяем систему на полный объём источников, следя за стабильностью и стоимостью обработки.
• Гарантийная поддержка и развитие. Сопровождаем систему в продакшене и адаптируем её к изменениям внешней среды.

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

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

Система работает с контактными данными кандидатов и деталями вакансий, поэтому к хранению и обработке данных подошли аккуратно. Доступ к собранным данным ограничен, данные хранятся в защищённой базе, а взаимодействие с внешними API построено так, чтобы через них проходил минимально необходимый объём информации. Подход к обработке персональных данных и защите информации в проектах eq.team описан в разделе о защите данных. Для рекрутингового продукта это не формальность: корректная работа с контактами кандидатов — часть репутации клиента.

Ключевое архитектурное решение проекта — отдать разбор неструктурированного текста языковой модели, а не жёстким правилам. Это принципиально меняет экономику масштабирования. В классическом парсере на регулярных выражениях каждый новый источник или изменение формата — это работа программиста: написать и протестировать новые правила. В подходе с LLM разбор идёт по смыслу, поэтому подключение нового канала сводится к добавлению его в конфигурацию, а адаптация к изменившемуся формату — к правке промпта. Стоимость поддержки при росте числа источников растёт медленно, тогда как в rule-based подходе она росла бы линейно с количеством уникальных форматов.

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

Агрегатор спроектирован так, чтобы его можно было развивать без переработки основы. Логичные направления развития, которые открывает текущая архитектура: подключение новых типов источников помимо Telegram (job-борды, корпоративные каналы, открытые API вакансий); добавление уведомлений — когда появляется вакансия или кандидат под заранее заданный профиль поиска, система может сама оповестить рекрутёра; расширение набора извлекаемых полей под меняющиеся потребности клиента; аналитика по рынку — поскольку данные нормализованы и накапливаются, на их основе можно строить срезы по спросу на технологии, динамике зарплат и активности каналов. Всё это надстраивается над уже работающим ядром сбора и обработки, а не требует нового проекта с нуля.

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

AI-агрегатор вакансий и резюме — характерный для eq.team пример продукта, где ценность создаётся на стыке нескольких компетенций: интеграции с внешними источниками, обработки естественного языка через большие языковые модели и надёжной продакшн-разработки на Laravel с очередями и структурированным хранилищем. Клиент получил инструмент, который сократил ежедневный мониторинг источников втрое, снял с HR-специалистов рутину и сделал покрытие рынка полнее и стабильнее. А главное — решение спроектировано так, что его дешево поддерживать и легко развивать под новые задачи.

Похожие задачи мы решаем в рамках услуг «Разработка ИИ-агентов», «Автоматизация процессов», «Чат-боты для бизнеса», «Внедрение ИИ в бизнес» и «Интеграции сервисов». Если нужна разработка бэкенда под подобную систему — смотрите «Разработку на Laravel».

Другие проекты eq.team на стыке ИИ и автоматизации: внутренний AI-ассистент для финансов, автоматизация онбординга разработчиков и логистическая платформа. Больше проектов — в разделе «Нейросети» и в разделе кейсов.