Визитки без облака: PaddleOCR в React Native ускорили с 7,8 до 3 секунд

Сканер визиток выглядит как задача на один вечер: сфотографировал, отправил в API, получил имя и телефон. Но визитка принадлежит не вам, а постороннему человеку. Его имя, номер и должность попадают на сервер без его ведома, и в российской практике это упирается в 152-ФЗ. Команда, о которой рассказывает автор статьи на Хабре, решила проблему радикально: фото вообще не покидает телефон.

Что собрали и почему без LLM

Стек такой: PaddleOCR v5, который запускается через ONNX Runtime внутри приложения на React Native под Android. То есть модель распознавания лежит на устройстве, а сеть для обработки снимка не нужна.

Автор отдельно упоминает, что от LLM отказались. Подробности в анонсе не раскрыты, но причины обычно понятны. Большая модель на телефоне тяжёлая и медленная. Если же вызывать её в облаке, мы возвращаемся к исходной проблеме: фото уходит наружу. Для визитки, где нужно вытащить несколько коротких полей, классический OCR плюс правила разбора часто оказываются практичнее. Это не вывод статьи, а общий инженерный ориентир, но он хорошо объясняет выбор.

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

От 7,8 до 3 секунд

Самая наглядная цифра в анонсе: обработка снимка ускорилась с 7,8 до 3 секунд. Разница принципиальна для продукта. Почти восемь секунд ожидания после съёмки пользователь воспринимает как зависшее приложение. Три секунды ещё терпимы, хотя до мгновенного отклика далеко.

Как именно добились ускорения, в анонсе не сказано, за деталями придётся идти в полный текст. Но у локального OCR на телефоне обычные места для оптимизации: размер входного изображения, число запусков моделей в цепочке, формат весов и способ передачи данных между JavaScript и нативным кодом. В React Native последний пункт нередко оказывается узким местом.

Скрытая телеметрия ONNX Runtime

Самая полезная для практиков деталь не про скорость, а про приватность. Автор пишет, что ONNX Runtime по умолчанию что-то отправляет в Microsoft. Что именно и в каких сборках, анонс не уточняет, поэтому точный масштаб утечки оценить нельзя. Но сам урок важен: слова «модель работает локально» не гарантируют, что приложение вообще не ходит в сеть.

Для продукта, который строится на аргументе «данные не покидают устройство», это критично. Если в политике конфиденциальности вы обещаете одно, а библиотека втихую делает другое, вы получаете и юридический риск, и потерю доверия.

Что делать разработчику и продакту

• Проверьте сетевой трафик приложения на реальном устройстве, а не только код. Прокси вроде mitmproxy покажет, куда уходят запросы.
• Изучите настройки и сборки каждой зависимости, которая работает с пользовательскими данными, особенно с фото и документами. Отключите всё, что не нужно.
• Закладывайте скорость в метрики продукта. Локальная обработка почти всегда медленнее облачной, и разница между 7,8 и 3 секундами решает, будут ли функцией пользоваться.
• Не берите LLM по умолчанию. Для узкой задачи с понятной структурой лёгкий OCR на устройстве может выиграть по приватности, цене и предсказуемости.

Ограничения

Мы видели только анонс: полных замеров, моделей телефонов, точности распознавания и сравнения с облачными решениями в нём нет. Цифры 7,8 и 3 секунды относятся к конкретной конфигурации команды и на другом железе могут отличаться. Юридическая трактовка 152-ФЗ тоже зависит от вашего случая, так что вопрос стоит обсудить с юристом.

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