Привет, Хабр! Меня зовут Олег Милосердов, я руковожу проектами по компьютерному зрению в ВТБ. В июле мы с коллегами приняли участие в научно-технологической программе «Большие вызовы» от образовательного центра «Сириус» в качестве наставников. Мы предложили школьникам спроектировать и внедрить автономный модуль распознавания MRZ-зоны документов, удостоверяющих личность, прямо на мобильном устройстве под Android, которое работает без интернета, серверов и облака. В этой статье расскажу, как талантливые старшеклассники справились с задачей, какой опыт получили и какие выводы мы можем сделать как наставники.
О программе
«Большие вызовы» — ежегодная программа образовательного центра «Сириус», где школьники в командах в течение нескольких недель решают реальные научно-технологические задачи. Итог работы — прототип или готовый продукт.
ВТБ участвует в проекте не первый год. В прошлый раз команда под руководством наших экспертов исследовала методы построения универсального представления локаций для бизнес-прогнозирования (об этом мы уже писали на Хабре).
В этом году мы предложили прикладную задачу компьютерного зрения: спроектировать on-device пайплайн распознавания MRZ — небольшой, но важный модуль в общем контуре распознавания документов, удостоверяющих личность. Основной фокус — офлайн-работа на бюджетных Android-устройствах: компактные модели, быстрый отклик и устойчивость к «полевым» условиям. В кейсе сходятся сразу несколько задач CV: детекция MRZ-зоны и строк, выравнивание, распознавание текста и постобработка с валидацией контрольных сумм.
Для нас это вклад в развитие инженерного мышления у школьников и возможность совместно протестировать подходы, которые потенциально могут быть полезны в банке.
Почему именно распознавание документов
Обработка документов — одна из самых прикладных и востребованных задач в компьютерном зрении. Готовые решения есть, но у них свои ограничения: Open Source требует глубокой адаптации под домен финансовых документов и кириллицу, а коммерческие SDK дороги и часто завязаны на облако, что неприемлемо в «полевых» сценариях.
Поэтому банку чаще всего нужен собственный пайплайн. Он объединяет широкий спектр задач на стыке ML/CV/NLP, от классификации типов документов и коррекции геометрии (deskew/rectification и dewarping) до layout-анализа структуры и содержания страницы (зоны → порядок чтения → таблицы → ключ-значение → шаблоны) и сопоставления с базовыми справочниками.
Конечно, охватить их все за три недели в «Сириусе» мы не смогли — формат накладывает ограничения:
Данные. Мы не можем отдавать ребятам внутренние корпуса. Значит, обучаемся на данных, которые удалось найти в открытых источниках.
Время. На весь цикл — около трех недель. Это сразу отсеивает «большие» модели, требующие долгого дообучения и мощной инфраструктуры.
Реальные ограничения продакшена. Работа офлайн, на бюджетных Android-устройствах, без серверов и платных SDK.
Почему именно MRZ
В 2025 году среди прикладных задач банка — офлайн-распознавание документов, удостоверяющих личность (ДУЛ), прямо на мобильных устройствах. Это критично для «полевых» сценариев, например, когда выездной менеджер оформляет карту у клиента дома, где связь нестабильна. Дополнительная сложность — разные паспорта стран СНГ (Кыргызстан, Узбекистан, Таджикистан и др.) с уникальными шаблонами и алфавитами. Это делает универсальные облачные сервисы и SDK либо недоступными офлайн, либо дорогими.
MRZ (Machine Readable Zone) оказался оптимальным решением:
единый стандарт ICAO (две или три строки с фиксированной структурой) присутствует на паспортах, визах и ID-картах;
содержит ключевые поля анкеты (ф. и. о. латиницей, номер документа, даты, гражданство);
встроенные контрольные суммы позволяют офлайн проверять корректность;
фиксированный алфавит MRZ упрощает задачу по сравнению с полнотекстовым OCR на разных языках;
один модуль MRZ снимает большую часть риска ошибок и ускоряет онбординг.
Иными словами, MRZ — важная часть большого пайплайна document understanding, которая решается в несколько этапов и хорошо ложится на условия проекта конкурса: ограниченные данные, короткий срок, жесткие требования по ресурсам и офлайн-режим.
Чем это ценно для участников
Мы хотели, чтобы ребята прошли весь цикл работы ML-инженера, от постановки задачи заказчиком и разметки до метрик, оптимизации и интеграции в приложение. MRZ дает отличный учебный полигон для инженерных компромиссов:
подбор архитектуры под мобильные ограничения (скорость, размер, устойчивость);
построение конвейера от детекции до постобработки;
проектирование постобработки с парсингом и проверкой контрольных сумм;
работа с реальными артефактами: искажения, шумы, углы, слабое освещение.
Такие задачи учат системному мышлению, командной разработке и позволяют увидеть, как набор исследовательских блоков превращается в полезный продукт на реальном устройстве.
Постановка задачи: проект с прицелом на внедрение
Мы задумывали проект не как «игру с нейросетями», а как инженерный вызов с прицелом на внедрение. Цель — создать систему, которая получает на входе фото документа, находит MRZ-зону, распознает текст и возвращает структурированные данные. Все это должно работать на обычном смартфоне, без облака, GPU и задержек. Система должна справляться с плохим освещением, наклоном, шумами, разными типами паспортов, содержащих MRZ-зону.
Так что мы задали жесткие рамки:
офлайн-режим, никаких внешних API и приватность «из коробки»;
бюджетный Android, CPU-only, end-to-end ≤5 с.;
суммарный вес моделей ≤50 МБ;
устойчивость к «полевым» условиям: перспектива, шум/блики, слабый свет, разные ракурсы;
разные паспорта со всего мира, латиница MRZ, разная верстка, корректность — через контрольные суммы ICAO;
мобильная интеграция: TensorFlow Lite и Chaquopy для упрощения интеграции некоторых модулей в учебных целях.
Мы обсудили с участниками, как выглядит путь от идеи до продакшена: исследование, реализация прототипа, тестирование, сбор метрик, работа над UX, обеспечение безопасности, интеграция. Ребята не просто занимались программированием, но и продумывали, как это будет использоваться, какие могут быть нюансы и как действовать с возможными ошибками.
Кто принял вызов: об участниках и наставниках
В команде школьников было пять участников, каждый из которых отвечал за свой участок разработки. При этом все активно участвовали в подготовке презентации, демо и Q&A на защите, от сценария и прогонов до live-сканирования на смартфоне и разборчивых ответов на технические вопросы.
Константин Титко (11 класс, Находка) обучил детектор MRZ-зоны, настроил CI-тестирование и интеграцию моделей.
Ярослав Блинков (11 класс, Казань) обучил детектор для отдельных MRZ-строк, участвовал в финальной сборке пайплайна и визуализации результатов.
Тимур Тютрин (11 класс, Находка) обучал различные рекогнайзеры, осваивал экспорт в ONNX/TFLite.
Ульяна Ноздрачева (11 класс, Курск) собрала прототип приложения на Android, подключила Chaquopy и камеру, провела inference на устройстве и довела до работающего MVP.
Матвей Сорокин (10 класс, Курск) занимался анализом архитектур, визуализацией пайплайна, подготовкой демо, лендинга и презентации.
Проект MRZVision ребята выбрали сами, так как хотели пройти полный путь от идеи до продукта на фестивале проектов «Больших вызовов», который прошел в начале смены.
Со стороны ВТБ в качестве наставников, помимо меня, были мои коллеги:
Артем Певцов — ведущий специалист команды CV ВТБ, занимается нейросетевыми методами обработки изображений, имеет опыт преподавания и наставничества в олимпиадном программировании и анализе данных;
Даниил Ушаков — главный специалист команды NLP ВТБ, специализируется на MLOps и Full Stack разработке, сам дважды побеждал в «Больших вызовах». На проекте он отвечал за техническое сопровождение и формирование бизнес-компетенций участников.
Мы сопровождали проект на всех этапах до финальной презентации, помогая ребятам мыслить инженерно и держать фокус на реальных ограничениях.
Как школьники решали задачу
Мы начали не с кода, а с данных. Участники получили датасет — более 2000 размеченных MRZ-зон паспортов разных стран, собранных из открытых источников. Ребята провели инвентаризацию корпуса и того, что можно оперативно дособрать в Cети: паспорта, визы, ID-карты, снятые под углами, с шумами, бликами и в низком разрешении. На этом шаге зафиксировали ограничения, выявили особенности датасета и сузили круг подходящих алгоритмов.
Мы предложили не готовый пайплайн, а исследовательский формат — команда сама строила дерево решений. Рассматривали два state-of-the-art подхода:
Детектировать MRZ-строки сразу на полном кадре обычными текстовыми детекторами. Этот путь кажется наиболее очевидным, но на реальных фото ловит много «шума» от остального макета документа, длинные узкие строки часто обрезаются по краям, и он, как правило, требует более тяжелых детекторов.
Идти в два этапа: сперва найти MRZ-зону, выровнять ее, а уже внутри аккуратно детектировать строки. На практике этот маршрут дает меньше ложных срабатываний и стабильнее готовит вход для OCR.
В итоге утвердили двухэтапный вариант: MRZ-зона — на YOLO от Ultralytics, строки — на YOLO или PPOCRv5-det. Для распознавания текста протестировали несколько легких рекогнайзеров от PaddleOCR и классический CRNN; на нашем корпусе после дообучения CRNN показал лучшую устойчивость EM (Exact Match) / CER (Character Error Rate) при сопоставимом весе, поэтому стал основным. PaddleOCR остался «планом Б». Контур дополнили строгой постобработкой: парсинг MRZ по спецификации ICAO и проверка контрольных сумм (номер, даты и т. п.) — это заметно гасит единичные ошибки распознавания.
Важно: решение сознательно подстраховано альтернативами: если один узел в процессе разработки «падает» на сложном кейсе, его можно заменить без пересборки всего конвейера.
Параллельно шла работа с корпусом: ребята добрали недостающие типы паспортов, доразметили и расширили набор до 2200+ документов (паспорта, визы, ID; 50+ стран), подготовили train/val/test и унифицировали форматы под этапы (Ultralytics и PaddleOCR). После базовой подготовки Константин Титко обучил детектор MRZ-зон, Ярослав Блинков и Матвей Сорокин — детектор строк. Тимур Тютрин запустил baseline-OCR: сначала предобученный PPOCRv5 и CRNN, а затем сфокусировался на дообучении CRNN под MRZ. Существенная доля времени ушла именно на сборку датасетов, обучение нейросетей, борьбу с ошибками и доводку этапов пайплайна.
Чтобы все жило не «на слайде», а в реальности, Константин собрал end-to-end-скрипт пайплайна. Тимур выполнил экспорт моделей в ONNX/TFLite и квантизацию до FP16/INT8 — модели уложились в мобильные лимиты и ускорили инференс на CPU.
Параллельно Ульяна Ноздрачева поднимала Android-часть. На Chaquopy и TFLite она собрала фронт «камера → детектор → OCR → JSON» прямо на смартфоне, полностью офлайн. К финалу смены у нас была полная версия пайплайна на Android, показанная на фестивале проектов. Основные сложности пришлись на перенос питоновской логики на Java/Kotlin и замену библиотек, но все блоки встали.
Финишная неделя ушла на качество и UX: обновляли датасеты, шлифовали эвристики по краям строк, подкручивали постобработку (ICAO + контрольные суммы). Итог на тестовой выборке в 200 сэмплов — Word Acc ≈ 80 %, EM ≈ 0,71 на строках, суммарный вес моделей <15 МБ, end-to-end < 4 с. (в пике) на бюджетном Android’е.
На финальной защите, а после и на фестивале проектов команда показала результат: сканирование паспорта на смартфоне, стабильное извлечение MRZ-строк, разбор на поля и проверку контрольных сумм.
Какие софт-скилы мы прокачали
Неожиданным (и приятным) открытием стало то, насколько внимательно на «Больших вызовах» относятся не только к хардам, но и к развитию коммуникации, командной работы и публичных выступлений. За три недели у ребят было пять защит и финальный фестиваль проектов, каждый шаг сложнее предыдущего.
Первые две защиты проходили перед кураторами, они задавали жесткие, иногда каверзные вопросы: «Почему не этот бенчмарк?», «Как поведет себя модель при более сложных условиях?». Цель была не завалить, а научить мыслить шире, аргументировать и защищать свои решения. Еще две защиты ближе к финалу ребята проводили уже перед приглашенными экспертами, которые приехали специально, чтобы усилить проекты и технически, и продуктово. Ребята учились говорить на языке «стейкхолдеров»: не только про метрики, но и про UX, приватность, стоимость владения и риски.
Финальная защита — большой зал, много новых экспертов, плотный Q&A. К этому моменту у команды были отточены и структура рассказа, и тайминг, и навык отвечать быстро и по делу. Было видно, что команда уже не просто показывает пет-проект, а умеет защищать продукт: объяснять компромиссы, признавать ограничения и предлагать дорожную карту улучшений.
Последний день — фестиваль проектов. Два с лишним часа у стенда: непрерывные мини-питчи, живые демо и разговоры с гостями. Мы показывали пайплайн с веб-камеры ноутбука и на Android-устройстве, использовали распечатанные паспорта из открытых источников. Среди посетителей были желающие, которые предлагали продемонстрировать работу на собственных документах — мы сразу оговаривали, что обработка идет офлайн на устройстве, без сохранения и передачи данных. Алгоритм отлично отрабатывал и на таких кейсах, что только добавляло уверенности команде.
Итог — сильный апгрейд софт-скилов: сторителлинг, публичные выступления, Q&A-навыки, умение отстаивать решения и командная координация. Это тот случай, когда технический проект стал школой коммуникации — и именно поэтому в финале все выглядели взрослее, чем в первый день.
Что думают школьники и наставники об этом опыте
Нам было интересно узнать, как ребята оценивают тот опыт, который получили. Мы поговорили с участниками, и вот что они отметили.
Самым неожиданным для них стало то, насколько глубоко пришлось погружаться в коммуникацию: обсуждать архитектуру, спорить о метриках, договариваться о форматах вывода. Ко многому они оказались не готовы, например к столкновению с реальными ограничениями. Слабые устройства, реальные изображения с искажениями, отсутствие GPU на инференсе — всё это заставило их переосмыслить подход к разработке. Но, пожалуй, главный инсайт: в реальном проекте «вайбкодинг» не работает. Без глубоких доменных знаний и погружения в область красивый код не превращается в продукт.
Мы в свою очередь увидели, как школьники воспринимают инженерные задачи, и взглянули на привычные процессы под новым углом.
Взгляд в будущее
Команда собрала устойчивый on-device пайплайн, и на этом кейсе мы с коллегами еще раз убедились: даже при жестких ограничениях по данным и ресурсам можно получить рабочее решение. При этом участники успели прокачать и харды, и софты, от работы с данными, квантизации и мобильной интеграции (TFLite/ONNX, CI) до командной коммуникации и продуктового мышления. Ребята могут продолжить работу на хакатонах и олимпиадах, развивать идеи в смежных задачах и проверять их в конкурентной среде. Мы со своей стороны видим для них другие траектории: стажировки и проектные треки с наставниками ВТБ, участие в корпоративных R&D-инициативах, оформление результатов в публикации и open-source. Этот опыт станет бонусом при поступлении на профильные программы в вузах. И я уверен: у ребят из команды есть все необходимое, чтобы двигаться дальше и достигать новых высот.
Напоследок вопрос к вам, Хабр: участвовали ли вы в подобных образовательных программах как участники или наставники? Что думаете о нашей постановке, подходе и компромиссах? Делитесь опытом и идеями в комментариях!