Про квантизацию: осознанно держали единый bfloat16 на всех VLM. Логика в том, что это бенчмарк с одной осью, скоростью, и квантизация добавила бы вторую ось, качество, по которой мы в этой итерации ничего не контролировали. Ускорение мы бы увидели, а регрессию распознавания нет.
Про возраст Qwen2.5 выше в комментариях уже спрашивали, поэтому коротко, чтобы не повторяться. Он тут потому, что это общепринятая точка отсчёта: почти все публичные OCR-сравнения имеют замеры с ним, и это делает наши цифры сопоставимыми с чужими. 3.5 и 3.6 прогнать нужно, согласен, это в планах.
Интересный кейс, но совсем не наш: у нас документы, а у вас поток кадров и короткая строка поверх меняющегося фона. Так что цифры из статьи вам ничем не помогут, и про грузинский мы ничего не мерили.
Если рассуждать в общем: сам язык у Tesseract, насколько я знаю, есть, значит дело не в его отсутствии. Для языков с небольшим корпусом модели обучены на меньшем наборе шрифтов, а субтитры могут быть очень разные, возможно причина в этом.
Qwen2.5 у нас в роли опорной точки, а не претендента на первое место. Причина в том, что это в некотором роде стандарт сравнения: на неё ссылается большинство OCR-бенчмарков и таблиц OmniDocBench, и она же чаще всего оказывается той самой general-VLM, которая у команды уже развёрнута, когда возникает вопрос, потянет ли она ещё и распознавание документов. За счёт этого наши цифры можно приложить к чужим замерам, не перепроверяя чужие.
Что до 3.5 и 3.6, спорить не буду: линейка новее, и заявленный прирост там есть. Соглашусь, прогон на том же стенде и том же датасете нужен, он в планах.
Честно, из нашей статьи для личных задач выводы не переносятся почти никак. Мы мерили серверные связки под поток документов, batch=1 на A100, и оптимизировали выбор под «сколько страниц в минуту переварит сервис». Для личных задач на пару десятков (примерно) страниц в неделю, узкое место совсем другое: удобство, PDF на выходе, правка распознанного текста, работа без возни с докером.
FineReader при этом не устарел, развитие там идёт, просто основное усилие ушло в корпоративный сегмент и в подготовку документов для языковых моделей. Так что если он вас устраивает, менять его на модели из нашей таблицы смысла нет: почти всё, что мы гоняли, это не приложения, а модели, которые надо самому поднимать и обвязывать кодом.
Единственное, что реально стоит попробовать бесплатно, это распознавание, встроенное в операционную систему. В соседнем комментарии https://habr.com/ru/companies/mts_ai/articles/1065182/#comment_30286584 человек как раз показал встроенное в Windows 11 на исходнике слабого качества, и результат приличный. На macOS и на телефонах то же самое давно есть в системных инструментах. Мы это не замеряли, наш бенчмарк совсем про другое, но для пары десятков страниц в неделю этого часто достаточно, и проверяется довольно быстро.
Анекдот по адресу, спорить не буду. Это осознанно бенчмарк скорости, и в оговорках у нас отдельным пунктом стоит, что CER и WER мы не считали. Мы тут скорее отвечаем на вопрос «какая связка модель плюс движок сколько выдаёт», а не «кто распознаёт лучше».
Что мы всё-таки померили в сторону вашего вопроса: полноту вывода, символы и токены на страницу. Именно из-за неё первый результат в статье не про то, что Tesseract быстрее всех, а про то, что он быстрее всех потому, что возвращает меньше: 411 символов на страницу против 1193 токенов у PaddleOCR-VL. Это, конечно, не качество, но уже показывает, что голая скорость без второй оси вводит в заблуждение.
Добавление CER и WER в планах в следующих итерациях.
Про виды ошибок согласен отдельно. У разных классов моделей профиль ошибок разный: традиционные OCR чаще молчат, VLM чаще додумывают. Это разбор, который стоит делать вместе с метриками качества.
Отличный срез, спасибо, что принесли сразу с кодом и результатом. On-device на NPU у нас полностью за скобками: стенд серверный, A100 и три движка инференса, поэтому такой сценарий мы не трогали.
Блок классических OCR задумывался как CPU-бейзлайн, потому что Tesseract и RapidOCR обычно так и разворачивают, без видеокарты. Но вы правы в своем замечании, для PaddleOCR такой режим невыгоден, и его строка в таблице описывает CPU-режим, а не потолок модели. Читать её как «PaddleOCR медленный» нельзя, и такая оговорка в статье должна была стоять.
Про стр/мин. Да, это расчётное значение на 15 изображениях, а не замер на потоке.
Про warmup замечание действительно важное, тут поясню подробнее. Прогрев был не «5 раз все 15», а первые 5 изображений по одному разу. И тут вылезло то, чего мы не закладывали: выборка собрана как 5 чистых сканов, потом 5 тёмных, потом 5 светлых, а значит первые пять это ровно вся группа сканов. То есть на замер сканы шли уже знакомыми движку, а тёмные и светлые впервые.
Если бы прогрев прошёл по всем пятнадцати, как вы и предположили, эффект распределился бы ровно и его можно было бы считать общим сдвигом для всей выборки. У нас же он лёг только на одну треть: движки кешируют уже обработанное, поэтому сканы могли получить фору, которой у тёмных и светлых не было. Отдельного холодного замера мы не делали, так что снять этот эффект цифрами сейчас не могу.
Про промпт. Да, один на всех, это был осознанный выбор ради одинаковых условий. Но вы правы в последствиях: у PaddleOCR-VL, Dots.OCR и DeepSeek-OCR есть свои рекомендованные промпты, и они влияют в том числе на формат вывода, а формат тянет за собой tok/page, которое у нас идёт отдельной метрикой. Честнее было бы прогонять в двух режимах, унифицированном и родном для каждой модели.
Про перенос на печатные. Согласен, наша формулировка получилась сильнее, чем позволяют данные. Рукопись это worst-case по распознаванию символов, но не worst-case по разбору вёрстки, а на печатных документах как раз вёрстка, таблицы и Markdown-режим решают. Так что отдельный тест на печатных нужен, спорить не буду.
Про «сколько на нём текста»: прикладываю страницу из нашей выборки для примера
За ссылки на LightOnOCR-2-1B и HunyuanOCR-1.5 отдельное спасибо, заберём. Первая по вашему описанию интересна как раз для сценариев с малой памятью.
Согласны, скорость без качества половина картины, поэтому мы это отдельно и вынесли в оговорки. Эталонную разметку уже сделали: те же 15 страниц размечены вручную, по ним посчитаем CER и WER на тех же моделях и движках. Смысл именно в этом: чтобы качество легло на уже опубликованные цифры скорости, а не на новый отдельный прогон, где непонятно, что с чем сравнивать.
Мобильные не тестировали, весь стенд серверный, A100 и три движка инференса, ничего про on-device сказать не можем. Whiteboard вообще отдельный домен: перспектива, блики от маркера, неравномерная подсветка. Наши «тёмные» и «светлые» семплы рядом, но это не то же самое.
Из того, что было на стенде и что теоретически поедет на устройстве это PaddleOCR-VL 1.7B. По размеру в мобильный бюджет вписывается, но мы его в этом режиме не гоняли, так что это не рекомендация, а направление, куда смотреть.
Про FineReader специально не следим, но если судить по новостям, рынок они не потеряли, а сместились в сторону обработки документов под LLM-пайплайны.
Информация
В рейтинге
313-й
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
Про квантизацию: осознанно держали единый
bfloat16на всех VLM. Логика в том, что это бенчмарк с одной осью, скоростью, и квантизация добавила бы вторую ось, качество, по которой мы в этой итерации ничего не контролировали. Ускорение мы бы увидели, а регрессию распознавания нет.Про возраст Qwen2.5 выше в комментариях уже спрашивали, поэтому коротко, чтобы не повторяться. Он тут потому, что это общепринятая точка отсчёта: почти все публичные OCR-сравнения имеют замеры с ним, и это делает наши цифры сопоставимыми с чужими. 3.5 и 3.6 прогнать нужно, согласен, это в планах.
Интересный кейс, но совсем не наш: у нас документы, а у вас поток кадров и короткая строка поверх меняющегося фона. Так что цифры из статьи вам ничем не помогут, и про грузинский мы ничего не мерили.
Если рассуждать в общем: сам язык у Tesseract, насколько я знаю, есть, значит дело не в его отсутствии. Для языков с небольшим корпусом модели обучены на меньшем наборе шрифтов, а субтитры могут быть очень разные, возможно причина в этом.
Qwen2.5 у нас в роли опорной точки, а не претендента на первое место. Причина в том, что это в некотором роде стандарт сравнения: на неё ссылается большинство OCR-бенчмарков и таблиц OmniDocBench, и она же чаще всего оказывается той самой general-VLM, которая у команды уже развёрнута, когда возникает вопрос, потянет ли она ещё и распознавание документов. За счёт этого наши цифры можно приложить к чужим замерам, не перепроверяя чужие.
Что до 3.5 и 3.6, спорить не буду: линейка новее, и заявленный прирост там есть. Соглашусь, прогон на том же стенде и том же датасете нужен, он в планах.
Честно, из нашей статьи для личных задач выводы не переносятся почти никак. Мы мерили серверные связки под поток документов, batch=1 на A100, и оптимизировали выбор под «сколько страниц в минуту переварит сервис». Для личных задач на пару десятков (примерно) страниц в неделю, узкое место совсем другое: удобство, PDF на выходе, правка распознанного текста, работа без возни с докером.
FineReader при этом не устарел, развитие там идёт, просто основное усилие ушло в корпоративный сегмент и в подготовку документов для языковых моделей. Так что если он вас устраивает, менять его на модели из нашей таблицы смысла нет: почти всё, что мы гоняли, это не приложения, а модели, которые надо самому поднимать и обвязывать кодом.
Единственное, что реально стоит попробовать бесплатно, это распознавание, встроенное в операционную систему. В соседнем комментарии https://habr.com/ru/companies/mts_ai/articles/1065182/#comment_30286584 человек как раз показал встроенное в Windows 11 на исходнике слабого качества, и результат приличный. На macOS и на телефонах то же самое давно есть в системных инструментах. Мы это не замеряли, наш бенчмарк совсем про другое, но для пары десятков страниц в неделю этого часто достаточно, и проверяется довольно быстро.
Анекдот по адресу, спорить не буду. Это осознанно бенчмарк скорости, и в оговорках у нас отдельным пунктом стоит, что CER и WER мы не считали. Мы тут скорее отвечаем на вопрос «какая связка модель плюс движок сколько выдаёт», а не «кто распознаёт лучше».
Что мы всё-таки померили в сторону вашего вопроса: полноту вывода, символы и токены на страницу. Именно из-за неё первый результат в статье не про то, что Tesseract быстрее всех, а про то, что он быстрее всех потому, что возвращает меньше: 411 символов на страницу против 1193 токенов у PaddleOCR-VL. Это, конечно, не качество, но уже показывает, что голая скорость без второй оси вводит в заблуждение.
Добавление CER и WER в планах в следующих итерациях.
Про виды ошибок согласен отдельно. У разных классов моделей профиль ошибок разный: традиционные OCR чаще молчат, VLM чаще додумывают. Это разбор, который стоит делать вместе с метриками качества.
Отличный срез, спасибо, что принесли сразу с кодом и результатом. On-device на NPU у нас полностью за скобками: стенд серверный, A100 и три движка инференса, поэтому такой сценарий мы не трогали.
Блок классических OCR задумывался как CPU-бейзлайн, потому что Tesseract и RapidOCR обычно так и разворачивают, без видеокарты. Но вы правы в своем замечании, для PaddleOCR такой режим невыгоден, и его строка в таблице описывает CPU-режим, а не потолок модели. Читать её как «PaddleOCR медленный» нельзя, и такая оговорка в статье должна была стоять.
Спасибо, вопросы отличные, отвечу по порядку.
Про стр/мин. Да, это расчётное значение на 15 изображениях, а не замер на потоке.
Про warmup замечание действительно важное, тут поясню подробнее. Прогрев был не «5 раз все 15», а первые 5 изображений по одному разу. И тут вылезло то, чего мы не закладывали: выборка собрана как 5 чистых сканов, потом 5 тёмных, потом 5 светлых, а значит первые пять это ровно вся группа сканов. То есть на замер сканы шли уже знакомыми движку, а тёмные и светлые впервые.
Если бы прогрев прошёл по всем пятнадцати, как вы и предположили, эффект распределился бы ровно и его можно было бы считать общим сдвигом для всей выборки. У нас же он лёг только на одну треть: движки кешируют уже обработанное, поэтому сканы могли получить фору, которой у тёмных и светлых не было. Отдельного холодного замера мы не делали, так что снять этот эффект цифрами сейчас не могу.
Про промпт. Да, один на всех, это был осознанный выбор ради одинаковых условий. Но вы правы в последствиях: у PaddleOCR-VL, Dots.OCR и DeepSeek-OCR есть свои рекомендованные промпты, и они влияют в том числе на формат вывода, а формат тянет за собой tok/page, которое у нас идёт отдельной метрикой. Честнее было бы прогонять в двух режимах, унифицированном и родном для каждой модели.
Про перенос на печатные. Согласен, наша формулировка получилась сильнее, чем позволяют данные. Рукопись это worst-case по распознаванию символов, но не worst-case по разбору вёрстки, а на печатных документах как раз вёрстка, таблицы и Markdown-режим решают. Так что отдельный тест на печатных нужен, спорить не буду.
Про «сколько на нём текста»: прикладываю страницу из нашей выборки для примера
За ссылки на LightOnOCR-2-1B и HunyuanOCR-1.5 отдельное спасибо, заберём. Первая по вашему описанию интересна как раз для сценариев с малой памятью.
Согласны, скорость без качества половина картины, поэтому мы это отдельно и вынесли в оговорки. Эталонную разметку уже сделали: те же 15 страниц размечены вручную, по ним посчитаем CER и WER на тех же моделях и движках. Смысл именно в этом: чтобы качество легло на уже опубликованные цифры скорости, а не на новый отдельный прогон, где непонятно, что с чем сравнивать.
Мобильные не тестировали, весь стенд серверный, A100 и три движка инференса, ничего про on-device сказать не можем. Whiteboard вообще отдельный домен: перспектива, блики от маркера, неравномерная подсветка. Наши «тёмные» и «светлые» семплы рядом, но это не то же самое.
Из того, что было на стенде и что теоретически поедет на устройстве это PaddleOCR-VL 1.7B. По размеру в мобильный бюджет вписывается, но мы его в этом режиме не гоняли, так что это не рекомендация, а направление, куда смотреть.
Про FineReader специально не следим, но если судить по новостям, рынок они не потеряли, а сместились в сторону обработки документов под LLM-пайплайны.