OCR-продукты состоят из нескольких моделей, потому что это позволяет им обрабатывать документы в высоком разрешении. Детектор сжимает изображение, находит области текста, после чего строит ббоксы для оригинального разрешения. Модель-распознаватель получает на вход кусочки с текстом из изображения с оригинальным разрешением. Таким образом и качество текста сохраняется, и модель не захлёбывается при обработке высокого разрешения.
Как вы обошли (если обошли) это ограничение, если у вас одна модель? Вот я подаю на вход скан страницы с разрешением 1200*2400, условно, как вы его обработаете?
Выигрыш в скорости: Наша модель обрабатывает документ за 752 мс, тогда как конкуренты — почти в два раза дольше (~1400-1500 мс).
На одном и том же железе? А под документом подразумевается страница? А какое разрешение у документа, что его можно трансформерами с такой скоростью обработать?
Ответ простой: нашелся другой человек, который тоже ответил на 5+, и у него либо больше стаж в резюме, либо он работал с технологиями из вакансии (не надо учить).
Такое решение доступно лишь единицам. Огромное количество ресурсов для распознавания одного типа документов. Большой объем данных, команда разметки, отдельная модель на каждый этап.
Кстати, в статье опущен момент производительности - насколько получившийся пайплайн медленнее/быстрее опенсорсных решений?
Можно добавить сравнение с обычной классификацией изображения.
Было бы интересно также поглядеть фактические цифры: сколько времени уходит на такой-то датасет и сколько видеопамяти для этого нужно. Тут же можно добавить, как сильно размер батча влияет на скорость обработки датасета. Поскольку сравниваются пары изображение-текст, то это должно влиять очень сильно.
OCR-продукты состоят из нескольких моделей, потому что это позволяет им обрабатывать документы в высоком разрешении. Детектор сжимает изображение, находит области текста, после чего строит ббоксы для оригинального разрешения. Модель-распознаватель получает на вход кусочки с текстом из изображения с оригинальным разрешением. Таким образом и качество текста сохраняется, и модель не захлёбывается при обработке высокого разрешения.
Как вы обошли (если обошли) это ограничение, если у вас одна модель? Вот я подаю на вход скан страницы с разрешением 1200*2400, условно, как вы его обработаете?
На одном и том же железе? А под документом подразумевается страница? А какое разрешение у документа, что его можно трансформерами с такой скоростью обработать?
Для EasyOCR надо было подобрать подходящее разрешение входного изображения, потому что "из коробки" он обучен под определенный масштаб.
Так обычно отвечают в духе: "очень жаль, вы нам не подошли". Никто не скажет, что взяли другого человека, потому что у него больше стаж в резюме.
Ответ простой: нашелся другой человек, который тоже ответил на 5+, и у него либо больше стаж в резюме, либо он работал с технологиями из вакансии (не надо учить).
Не думали, что дообучение PaddleOCR могло бы быть более эффективным решением в плане общих затрат и скорости инференса?
Такое решение доступно лишь единицам. Огромное количество ресурсов для распознавания одного типа документов. Большой объем данных, команда разметки, отдельная модель на каждый этап.
Кстати, в статье опущен момент производительности - насколько получившийся пайплайн медленнее/быстрее опенсорсных решений?
Можно добавить сравнение с обычной классификацией изображения.
Было бы интересно также поглядеть фактические цифры: сколько времени уходит на такой-то датасет и сколько видеопамяти для этого нужно. Тут же можно добавить, как сильно размер батча влияет на скорость обработки датасета. Поскольку сравниваются пары изображение-текст, то это должно влиять очень сильно.