Как стать автором
Обновить

Как декомпозиция повышает точность распознавания текста: опыт с фотографиями СТС

Уровень сложностиСредний
Время на прочтение9 мин
Количество просмотров4.7K
Всего голосов 31: ↑31 и ↓0+31
Комментарии4

Комментарии 4

Такое решение доступно лишь единицам. Огромное количество ресурсов для распознавания одного типа документов. Большой объем данных, команда разметки, отдельная модель на каждый этап.

Кстати, в статье опущен момент производительности - насколько получившийся пайплайн медленнее/быстрее опенсорсных решений?

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

Насчет производительности: не ставили перед собой задачу сделать быстрее чем в опенсорсе, однако по таймингам подскажу, например время ответа PaddleOCR - 150мс, наше - 300 мс на 1 картинке. Нас устроило наше время ответа, поэтому не занимались ускорением пока. Мы часто используем для ускорения и экономии гпу в продакшене наш фреймворк Акведук, который позволяет получать меньшее время ответа под нагрузкой, тут мы тоже в него обернули, не настраивали максимально, тк пока нет необходимости.

Не думали, что дообучение PaddleOCR могло бы быть более эффективным решением в плане общих затрат и скорости инференса?

Думали, мы стояли на распутье тогда, для дообучения PaddleOCR точно так же нужно было бы размечать данные. Нужно было думать как это делать, ведь он размечает весь документ, то есть нам нужно было либо тоже размечать весь документ, либо придумывать, как переобучать только под нужные нам боксы для нужных номеров, а затем думать как из всех боксов выбирать нужные уже для OCR. У нас тогда были ресурсы на разметку и мы решили попробовать сделать свой пайплайн с нуля, который архитектурно будет проще, чем у PaddleOCR и нам проще будет его внедрять и поддерживать. А в качестве второго варианта, если бы первый не заработал держали дообучение PaddleOCR.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий