Вышел последний необходимый кирпичик для OCR (первая OCR-Jev модель)
Короче, пишу (вайбкожу) программу для OCR, чтобы она распознавала без ошибок месиво из формул с древних пережатых в мясо djvu. Типа такого
Для полного файнридиума не хватало одного компонента - модели, которая бы быстро проверяла распознанное (модели для OCR и исправления неправильного уже давно подобраны и процесс налажен).
Я недели 3 экспериментировал с моделями типа decision, подбирая формулировки в запросе (а агенты всё это время гоняли A/B тесты). Но результаты были не очень - слишком много ложноположительных и ложноотрицательных срабатываний. Я даже пошёл на поклон к большим моделям (fable, asta, argon) и выложил все наработки в надежде, что они помогут, но ответ везде был примерно такой:
12% FN - это 12% пропущенных ошибок распознавания. А в отношении формул не может быть немного неправильного OCR.
И тут выходит ОНА:
Малюсенькая узкоспециализированная моделька на 2B параметров. По принципу работы она отличается от всех других decision моделей. Ей нужно подавать две картинки без текстового промпта (исходный кроп и рендер кандидата), она только говорит, согласуется ли OCR текст второй картинки с первой.
То есть после OCR надо отрендерить результат в изображение (формулы и таблицы придётся тоже корректно отработать) и подать его вместе с кропом исходного. К счастью, рендер у меня уже был налажен для предпросмотра, надо было немного его доработать для получения изображения конкретного блока.
Естественно, на рендере будут другие шрифты, строки будут выглядеть иначе, но для модели это не важно - она смотрит по фактическому тексту, который есть на обоих изображениях. И это первая модель среди всей группы decision, которая реально видит ошибки в OCR. Включая мелкие недочёты - ошибки в индексах формул, галлюцинации OCR модели (когда подставляется похожее по написанию, но неправильное по смыслу слово), перепутанные греческие и латинские символы (види разницу даже между ρ и p), которые пропускали обычные decision модели на 8-9B параметров.
У модели заявлена поддержка только английского и китайского языков, но ошибки в русском она прекрасно ловит. По сути, это первая и единственная модель этого типа (вижн-десижн), которая показывает нормальный результат на реальной задаче.
Сейчас прогоняется корпус A/B тестов (на моём чайнике займёт пару дней), но по первым 15% видно, что можно добиться околонулевого FN детектирования (когда есть ошибка распознавания а модель говорит, что ошибки нет) при приемлемом уровне FP - 10-20% (когда ошибки нет, а модель говорит, что есть). Причём задачи OCR и проверки теперь полностью помещаются в 6 GB VRAM или вообще на CPU благодаря маленьковости моделей. GPU нужен будет только чтобы на 100% автоматизировать процесс корректировки ошибок.
Так что этот вопрос полностью закрывается. Дальше полировка, вырезание не оправдавших себя фич и версия 1.0.
Единственное, что реально теперь улучшит процесс - появление новой маленькой vision-модели для исправления результата. Последние, что выходили - gemma-4 и qwen3.5 (всякие lfm на 2-3B не в счёт, они для этой задачи мелковаты и туповаты), справляются, но работают медленно, требуют очень специфических промтов, которые могут дать неправильный результат на некоторых специфических текстах. Очень жду, что команда XHToken добавит в свою Spark vision модуль, потому что в плане text to text их модель на 4b параметров рвёт всех, включая gemma4-12b, которая в 3 раза больше и медленнее.