Что сделала Sminex: суть кейса в двух абзацах
Sminex разработала внутренний продукт Sminex Start, который автоматизирует онбординг: новый сотрудник загружает документы в приложение, а система сама извлекает из них кадровые поля и передаёт их дальше. Вместо классического OCR здесь работает локально развёрнутая vision-language-модель семейства Qwen. Она получает изображение целиком, определяет тип документа и возвращает структурированный набор полей: данные паспорта, адрес регистрации, реквизиты СНИЛС, сведения из диплома.
Цифры, которые приводит компания: оформление одного человека занимало 30 минут и сократилось минимум на 10 минут, общая скорость процесса выросла примерно вдвое. Второй эффект даёт параллельная работа: новые сотрудники проходят этапы одновременно, а не выстраиваются в очередь. Обе оценки даны самой Sminex, независимого подтверждения нет. Версию Qwen, конфигурацию железа и масштаб внедрения компания не раскрывает, поэтому дальше разбираем архитектуру и логику решения, а не догадки про стек.
Почему OCR перестал справляться с кадровыми документами
Классический OCR решает одну задачу: превратить пиксели в текст. Всё остальное начинается после. Паспорт, СНИЛС, трудовая книжка, диплом, ИНН - у каждого документа своя структура и своя логика полей. Пайплайн на OCR требует шаблона под каждый тип: где искать номер, как отличить серию от кода подразделения, что делать с двусторонней печатью на одном листе.
Шаблоны ломаются на поворотах скана, бликах от ламината, мятых страницах и рукописных пометках. Чем шире поток, тем больше исключений приходится дописывать руками, и тем чаще оператор перепроверяет результат за моделью. Для простых однотипных форм это нормальный компромисс: OCR дешёвый, быстрый и предсказуемый, а открытые OCR-модели 2026 года держат точность выше 90% на стандартных бенчмарках при 8-12 GB VRAM (сравнение открытых моделей распознавания документов). Для кадрового пакета из пяти документов с разными стандартами оформления этого уже мало.
Vision-language-модель меняет точку входа. Она получает изображение и вопрос, а отвечает структурой: какой это документ и какие поля на нём есть. Отдельный классификатор типов в такой схеме не обязателен, и шаблон под каждый бланк тоже. Понимание разметки страницы и извлечение значений идут одним шагом.
Как устроен Sminex Start: архитектура и логика обработки
Пайплайн выглядит так. Сотрудник загружает документы в приложение. Модель определяет тип каждого документа и извлекает поля по строгому бланку. Затем данные проходят нормализацию, и один из самых сложных участков - приведение адреса регистрации к виду, который принимает 1С:ЗУП. На выходе кадровая система получает запись, готовую к записи в карточку сотрудника.
Поведение системы задают два архитектурных решения. Первое: отказ от универсального промпта в пользу отдельного бланка полей под каждый тип документа. Второе: отдельный маршрут обработки для каждого типа со своим запасным сценарием на случай сбоя.
Вся обработка идёт во внутреннем контуре. Модель развёрнута локально и не обращается к внешним AI-сервисам, а сами документы в приложении не хранятся. Для кадровых данных это принципиально: паспорт и СНИЛС относятся к персональным данным, и передавать их изображения в сторонний облачный API без правовых оснований нельзя.
Почему отказались от универсального промпта
Идея «попросим модель вытащить всё нужное» выглядит соблазнительно, но даёт нестабильный результат. На одном документе модель вернёт лишние поля, на другом пропустит обязательные, на третьем перепутает тип и подставит значения из чужого бланка. Причина простая: у свободного промпта нет границ, а у кадрового документа они есть.
Строгий бланк с фиксированным списком полей сужает пространство ответов. Для паспорта это один набор полей, для СНИЛС другой, и смешивать их в одном запросе не стоит. Подход ближе к constrained extraction, чем к диалогу с моделью: схему ответа описывают заранее, а модель заполняет её по изображению. Побочный эффект приятный: результат проще валидировать, потому что список полей известен и проверяется формально.
Запасной сценарий: что происходит при сбое
Для каждого маршрута предусмотрен запасной сценарий на случай сбоя. Что именно это за сценарий, Sminex не раскрывает: это может быть ручная проверка оператором, повторная обработка с другими параметрами или эскалация. Значение имеет сам факт наличия ветки. Автоматизация кадровых документов без fallback рискует тем, что первый же нестандартный скан остановит оформление, и никто не поймёт, на каком шаге процесс встал.
Встраивать VLM в процесс с людьми стоит с допущением, что модель иногда ошибается. Дальше вопрос инженерии: как быстро обнаружить ошибку, куда её отдать и кто её закроет.
Нормализация адреса под ФИАС и 1С:ЗУП: самый нетривиальный участок
Распознать адрес - половина дела. Паспортная строка адреса это свободный текст: сокращения («г.», «ул.», «д.»), разный порядок элементов, вариации написания населённых пунктов, точки и пробелы там, где их не ждёшь. 1С:ЗУП ожидает структурированный объект с конкретными полями по уровням. Между строкой из паспорта и объектом в кадровой системе лежит отдельный инженерный слой.
Sminex описывает его как четыре шага:
- токенизация распознанной строки;
- нечёткое сопоставление с госреестром (ФИАС);
- обогащение результата GUID;
- декомпозиция под объектную модель 1С:ЗУП.
Каждый шаг закрывает свою проблему. Токенизация разбивает строку на части, с которыми можно работать по отдельности. Fuzzy-match вытягивает совпадение, даже если в паспорте опечатка или нестандартное сокращение. GUID даёт однозначный идентификатор адресного объекта в госреестре. Декомпозиция раскладывает адрес на уровни, которые ожидает кадровая система: регион, район, город, улица, дом.
Почему распознанной строки недостаточно
Если ограничиться распознаванием, все расхождения уедут в кадровую систему и всплывут позже: при выгрузке отчётности, сверке с ФНС, оформлении документов. Тогда адрес придётся править вручную, и автоматизация сэкономит меньше, чем обещала. Нормализация переносит эту работу на этап ввода, где ошибку ловит система, а не кадровик через месяц.
GUID ФИАС как ключ к однозначности
GUID - уникальный идентификатор адресного объекта в ФИАС. Он связывает запись в кадровой системе с конкретным адресом независимо от того, как тот записан в документе. Один и тот же адрес можно написать десятком способов, а идентификатор у него один. Это снижает риск дублей и расхождений при интеграции. Конкретные форматы и примеры GUID Sminex не приводит, так что ограничимся принципом.
Приватность и внутренний контур: почему модель не уходит в облако
Кадровые документы содержат персональные данные, и обработка во внутреннем контуре становится условием проекта, а не архитектурной роскошью. Облачный AI-сервис означает передачу изображений паспорта и СНИЛС третьей стороне, а это требует правовых оснований и отдельной оценки рисков. Нормативные требования к защите информации в информационных системах задают рамку, внутри которой приходится проектировать такие процессы (документ по обеспечению информационной безопасности).
Локальный запуск влияет на выбор модели. Нужна vision-language-модель, которую можно поднять на своём железе, и семейство Qwen подходит под это требование: открытые веса позволяют развернуть модель внутри периметра. Конкретную версию и конфигурацию в кейсе не раскрывают, но класс требований понятен: GPU с достаточным объёмом VRAM, свой inference-сервер и полный контроль над тем, куда уходят данные.
Локальный контур не закрывает вопрос безопасности целиком. Остаются логирование, разграничение доступов, сроки хранения промежуточных файлов, защита самого сервера с моделью. Отсутствие внешних вызовов убирает один класс рисков, а не все сразу.
Что именно ускорилось: разбор цифр
В кейсе фигурируют две оценки:
- оформление одного человека: 30 минут, сокращение минимум на 10 минут;
- общая скорость процесса: примерно вдвое.
Это два разных эффекта, и складывать их нельзя. Минус 10 минут на человеке даёт автоматическое извлечение полей и нормализация адреса: кадровик не набирает данные руками и не сверяет адрес вручную. Рост вдвое относится к процессу целиком и опирается на параллельную работу: новые сотрудники проходят этапы одновременно.
Обе оценки даны Sminex. Независимых замеров, методики подсчёта и данных о том, сколько человек оформляется одновременно, в открытых материалах нет. Использовать эти цифры как ориентир для своего проекта можно только с поправкой на масштаб и на то, что «скорость онбординга» каждая компания измеряет по-своему.
Ограничения кейса и что осталось за кадром
Кейс описывает архитектуру и результат, но обходит инженерные детали. Не раскрыто:
- версия и конфигурация Qwen, режим квантизации, объём VRAM;
- масштаб внедрения, число обработанных документов, срок эксплуатации;
- точность извлечения полей и доля документов, уходящих в запасной сценарий;
- стоимость инфраструктуры и трудозатраты на поддержку;
- техническая реализация интеграции с 1С:ЗУП.
Без этих данных сложно оценить, во что обойдётся повторение. Локальная VLM требует GPU, а значит железа, электричества и человека, который будет обновлять модель и разбираться с ошибками. Для потока в сотни документов в месяц это может окупиться, для десяти - вряд ли.
Кейс остаётся полезным как архитектурный ориентир. Переносить его выводы на свой проект без пилота на собственных документах не стоит.
Кому подходит такой подход: практический чек-лист
Условия, при которых схема «VLM + строгие бланки + нормализация» имеет смысл:
- есть повторяющийся поток типовых документов: паспорта, СНИЛС, дипломы, трудовые;
- есть кадровая система с интеграцией, например 1С:ЗУП, и понятная объектная модель для записи;
- есть требования к приватности, из-за которых облачные AI-сервисы не подходят;
- есть железо под локальный запуск VLM и человек, который будет это поддерживать;
- есть готовность настраивать отдельный маршрут и бланк под каждый тип документа.
Последний пункт обычно недооценивают. Универсального промпта, который одинаково хорошо вытащит поля из паспорта и диплома, в этом кейсе не нашлось. Настройка бланков это ручная работа на старте, и она окупается при достаточном объёме документов.
Отдельное условие: запасной сценарий. Если модель ошибётся, а процесса ручной проверки нет, оформление встанет. Планировать fallback-ветку нужно до запуска, а не после первого инцидента.
Экономику стоит считать заранее. У современных моделей семейства Qwen расход входных токенов в многошаговых задачах может отличаться на десятки процентов, и это прямо влияет на нагрузку и стоимость инференса (разбор эффективности токенов у Qwen 3.8 Max Preview). Перед запуском полезно сравнить варианты по VRAM, контекстному окну и цене инференса: разница между открытыми моделями в этих параметрах часто важнее места в таблице лидеров (сравнение Qwen, GLM и DeepSeek для локального запуска).
Главное о кейсе Sminex
VLM вместо OCR даёт понимание типа документа и сразу структурированные поля, а не только текст на изображении. Строгие бланки под каждый тип документа и отдельные маршруты обработки оказались важнее поиска одного универсального промпта. Нормализация адреса под ФИАС и 1С:ЗУП - отдельная инженерная задача с токенизацией, нечётким сопоставлением, обогащением GUID и декомпозицией по уровням. Внутренний контур с локальной моделью закрывает требования к работе с персональными данными. Цифры ускорения приведены со слов компании.
Практический шаг, если хотите повторить: возьмите 50-100 своих реальных документов, прогоните их через выбранную VLM с бланками под каждый тип, замерьте долю записей, которые проходят без правки, и сравните с текущим временем ручного ввода. Такой пилот на своих данных даст больше, чем перенос чужих цифр. И сразу заложите ветку ручной проверки: она понадобится в первый же месяц.