OCR на пристрої у Flutter: чого це коштує

Очевидний вибір, якого ми не зробили

Найпростіший спосіб зробити сканер чеків — завантажувати фото на сервер. Хмарний OCR точніший, покращується без релізів застосунку, і підключається за один вечір.

Для Qivvo, нашого трекера витрат, ми зробили навпаки: розпізнавання тексту працює на телефоні через google_mlkit_text_recognition, а розібраний результат лягає в локальну базу SQLite через drift. Фото вашого чека не покидає пристрій.

Ця стаття про те, чого таке рішення коштує, бо переваги — легша половина.

Від чого доводиться відмовитись

Точність на складних кадрах. Хмарні моделі більші й новіші. На зім'ятому термочеку, знятому в напівтемному ресторані, серверна модель виграє. Розпізнавання на пристрої дуже добре працює на рівному тексті при пристойному світлі й деградує швидше за хмарне.

Цикл покращення. Коли розпізнавання підводить у хмарній схемі, можна подивитись на зображення, донавчити модель — і завтра всім стане краще. Ми так не можемо. У нас немає зображень, щоб на них дивитись, — за побудовою. Покращення приходять лише коли Google випускає кращу модель або коли ми пишемо кращу підготовку кадру.

Розмір бінарника й холодний старт. Модель розпізнавання їде разом із застосунком. Це реальні мегабайти й реальна ініціалізація при першому запуску — у кожного, включно з тими, хто ніколи нічого не сканує.

Що отримуєш натомість

Немає витоку, який міг би статись. Найнадійніший спосіб захистити базу з витратами всіх користувачів — не мати такої бази. Немає ендпоінта завантаження, немає сховища з фото чеків, немає політики зберігання, яку треба писати й можна написати неправильно.

Працює без звʼязку. Сканування в літаку, в підвальному ресторані чи за кордоном без роумінгу поводиться так само, як удома. Для інструмента, до якого тягнуться в момент оплати, це важливіше за кілька відсотків точності.

Твердження про приватність структурне, а не процедурне. «Ми не дивимось на ваші чеки» — це обіцянка. «Чек до нас не потрапляє» — це архітектура. Тільки друге переживає зміну власника компанії, судовий запит або неправильно налаштоване сховище — та сама логіка, за якою побудовано Kvit.

Куди насправді йдуть інженерні зусилля

Коли модель зафіксована, якість береться з усього, що навколо неї:

1. Захоплення кадру, а не розпізнавання. Більшість помилок — це погані кадри. Підказати ракурс, знайти краї, попросити не рухати телефон, відкинути змазаний кадр до розпізнавання — дає більше за будь-яку постобробку. 2. Парсинг — складніша половина. ML Kit повертає блоки тексту з координатами, а не чек. Перетворити це на продавця, дату, позиції й суму — це евристики розкладки, і саме тут живе продукт. 3. Виправлення має бути приємним. На пристрої означає, що жоден сервер потім тихо не виправить помилку, тож змінити неправильну суму має коштувати два тапи, а не форму.

Коли ми все ж обрали б хмару

Ми не ставили б цю архітектуру в кожен застосунок. Хмарний OCR — правильна відповідь там, де документи різнорідні й критичні для бізнесу: інвойси в десятках форматів, юридичні документи, усе де пропущена цифра дорого коштує, а користувач готовий зачекати на обробку.

Тест, який ми застосовуємо: чи засмутився б користувач, якби це зображення лежало на чиємусь сервері? Для ресторанного чека в особистому бюджеті відповідь «так», і це вирішує питання.