Как построить AI-скрининг резюме на Node.js: разбор пайплайна и его ограничений

Почти каждое демо AI-рекрутинга устроено одинаково: Python-монолит, пара ноутбуков, красивый график. В продакшене тяжелее не модель, а слой оркестрации на Node.js. Он принимает входящие резюме, считает соответствие профилю роли и решает, когда в процесс обязан вмешаться человек.

Если вы делаете что-то рядом с ATS, эта часть съедает больше времени, чем выбор модели. Ниже — из чего состоит такой пайплайн, где он ломается и какие ограничения стоит заложить заранее.

Что пайплайн должен делать

1. Принять резюме в PDF или DOCX и привести его к структурным полям: навыки, стаж, образование.
2. Сравнить эти поля с профилем вакансии — через эмбеддинг описания роли или рубрику ключевых слов.
3. Собрать шортлист, где у каждого кандидата есть понятная причина попадания в него.
4. Отдать спорные случаи рекрутеру до любого автоматического контакта с кандидатом.

В Talynce скрининг рассматривают как продуктовую поверхность, а не как одноразовый ноутбук: тот же пайплайн дальше питает этапы телефонного и видеоинтервью. Это поднимает планку — данные должны быть пригодны к переиспользованию, а не только к одному прогону.

Форма пайплайна на Node.js

• Приём. multipart-загрузка → объектное хранилище → очередь задач (Redis).
• Парсинг. извлекатели документов в рабочих процессах; результат складывается в PostgreSQL.
• Скоринг. близость по эмбеддингам (OpenAI или Gemini) плюс фильтры по правилам: обязательные навыки, локация, годы опыта.
• Консоль рекрутера. Next.js или React, рядом с каждым кандидатом — фрагменты, из которых видно обоснование оценки.

Связка Redis для очередей и Postgres для долговременного состояния кандидатов делает ретраи и аудит скучными. Это комплимент: скучный ретрай — тот, о котором вы не вспоминаете ночью.

Два способа оценивать кандидата

Скоринг — самая спорная часть пайплайна. Держите перед глазами это сравнение, когда будете решать, что положить в основу шортлиста.

Рабочая схема — держать оба сигнала вместе: правила убирают явные несоответствия по обязательным требованиям, эмбеддинги ранжируют тех, кто остался. Ни один из сигналов не должен быть единственным основанием для отказа.

Тормоза, которые стоит встроить сразу

• Автоматический отказ только на основании дистанции эмбеддинга — так делать нельзя.
• Каждый балл должен оставлять след: какие признаки его сформировали. Иначе рекрутеру нечего переопределять.

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

Где чаще всего ошибаются

• Строят шортлист на одном сигнале — только на эмбеддинге или только на ключевых словах.
• Запускают автоматический контакт с кандидатом, не показав спорные случаи человеку.
• Не логируют признаки, из которых собран балл, и теряют возможность оспорить решение.
• Хранят PII без явной политики и срока.
• Сразу берутся за широкую систему найма вместо узкой петли скрининга.
• Не закладывают ретраи и аудит — потом не могут объяснить, почему конкретное резюме ушло в отказ.

С чего начать

1. Опишите обязательные требования роли так, чтобы их можно было проверить правилами.
2. Поднимите приём файлов, хранилище и очередь — без них не будет ни ретраев, ни порядка.
3. Вынесите парсинг в отдельный воркер и складывайте результат в Postgres.
4. Добавьте скоринг эмбеддингами поверх, как ранжирование оставшихся.
5. Соберите консоль, где рядом с кандидатом видно, почему он здесь.
6. Прогоните первый десяток резюме руками и проверьте, объясняется ли результат за две минуты.

Если логику скрининга не получается пересказать менеджеру по найму за две минуты, система пока не готова к работе. Узкая петля, которую можно защитить словами, обычно обгоняет эффектный пайплайн, которому никто не доверяет.