Что выпустил OpenBMB: парсер MiniCPM-OCR 1.0 и валидатор Jev
OpenBMB выпустила две модели для работы с документами: MiniCPM-OCR 1.0 на 1.3B параметров, которая парсит китайские и английские документы, и MiniCPM-OCR Jev на 2B параметров, которая проверяет результат распознавания. Роли разделены буквально: первая читает документ, вторая смотрит на фрагмент изображения вместе с тем, что из него извлекли, и ставит оценку от 0 до 1. Сообщение о релизе появилось в сабреддите r/LocalLLaMA.
Jev получает фрагмент изображения и соответствующий ему результат OCR, а возвращает числовую оценку качества. Модель работает с текстом, формулами и таблицами. Для тех, у кого OCR-пайплайн уже собран на другом движке, важна ещё одна деталь: Jev может оценивать результаты сторонних парсеров, парсер OpenBMB при этом не обязателен.
Код и веса обеих моделей распространяются под Apache 2.0. В GitHub-репозитории лежат инструкции по локальному развёртыванию и ссылки на квантованные веса. Точных бенчмарков, даты выхода и полного списка поддерживаемых форматов документов в исходном сообщении нет, поэтому дальше речь идёт о том, что подтверждено, и отдельно о том, что придётся проверять самому.
Чем валидатор отличается от OCR-парсера
Парсер решает задачу перевода изображения в текст: страница PDF или скан превращаются в разметку с заголовками, таблицами и формулами. Валидатор эту задачу не решает, он её проверяет. Похоже на код-ревью: автор пишет код, ревьюер читает диф и говорит, насколько результат похож на правду. Только здесь ревьюер смотрит на картинку и сверяет с ней распознанный текст.
Вторая модель тяжелее первой: 2B против 1.3B. Это отдельная нагрузка на железо, и она умножается на число фрагментов. Если документ нарезан на 200 кропов, валидатор вызывается 200 раз, тогда как парсер может обработать страницу целиком. Бюджет VRAM и времени стоит считать по обеим моделям сразу, а не только по той, что делает основную работу.
Что известно о лицензии и где брать веса
Apache 2.0 разрешает коммерческое использование при выполнении условий лицензии: нужно сохранять уведомления об авторских правах и текст лицензии, а также не использовать товарные знаки правообладателя без отдельного разрешения. Для проекта, который планирует зарабатывать на обработке документов, это заметно свободнее, чем некоммерческие лицензии, часто встречающиеся у vision-моделей.
Имена файлов, размеры квантов и команды запуска в сообщении о релизе не приводятся: за ними нужно идти в GitHub-репозиторий, ссылка на который там указана. Практически стоит готовиться к тому, что готового пайплайна под вашу задачу не будет. Обвязку придётся писать самому: нарезку документов на кропы, сопоставление кропов с фрагментами распознанного текста, вызов валидатора и агрегацию оценок.
Как Jev оценивает качество OCR: вход, выход и шкала 0–1
Схема вызова простая: фрагмент изображения плюс распознанный текст этого фрагмента на входе, одно число от 0 до 1 на выходе. Модель работает с текстом, формулами и таблицами. Скор показывает, насколько распознанный фрагмент соответствует картинке, и этого достаточно, чтобы ранжировать участки документа по подозрительности.
Трактовка зависит от порога, а готового порога нет. В материалах о релизе не раскрыто, на каких данных обучался Jev и как откалибрована его шкала. Означает ли 0,7 «скорее плохо» или «почти хорошо» на ваших документах, заранее неизвестно. Порог придётся подбирать эмпирически: взять 50-100 фрагментов, где ответ OCR вы уже проверили вручную, и посмотреть, как скоры распределяются между верными и неверными.
Гипотетический пример, не результат измерений: если из 10 000 фрагментов отсортировать результат по скору и первыми смотреть нижние 5%, ручная проверка сузится с 10 000 участков до 500. Насколько реалистично такое сокращение, зависит от качества скоринга на вашем корпусе.
Почему фрагменты, а не документ целиком
Оценка по всему документу смешала бы хорошие и плохие участки в одно среднее число, и по нему нельзя было бы понять, что именно править. Фрагментная проверка даёт локализацию: не «документ плохой», а «вот эта таблица на странице N подозрительна». Дальше в эту таблицу смотрит человек, а не перечитывает весь файл.
Как именно OpenBMB нарезает документы, в сообщении не сказано. Общий принцип очевиден: кроп должен покрывать смысловой блок (ячейку таблицы, строку формулы, абзац), тогда оценка относится к проверяемому фрагменту, а не размывается по странице. Если кроп слишком большой, скор теряет чувствительность: одна битая ячейка утонет в общем хорошем тексте.
Текст, формулы и таблицы: где ошибки дороже всего
Числа в таблицах и формулы опаснее всего, потому что выглядят правдоподобно и попадают в ответ как факт. В исходном сообщении приведён именно такой риск: таблица с неверным числом, доехавшая до индекса, позволяет чат-боту услужливо процитировать это неверное число пользователю.
Опечатка в обычном абзаце чаще бросается в глаза при чтении, и цена её ниже: она портит поиск по ключевому слову, но редко становится основанием для вывода. Спутанная цифра в таблице живёт в ответе как утверждение, на которое ссылаются при принятии решения. Отсюда приоритет проверки: сначала таблицы и формулы, сплошной текст можно просматривать выборочно или по высокому скору.
Зачем валидатор OCR в локальном RAG-пайплайне
Цепочка выглядит так: PDF, затем OCR, затем Markdown или текст, затем чанки, индекс и ответы чат-бота. Слабое место спрятано на втором шаге. Превращение PDF в чистый Markdown само по себе не гарантирует, что все числа выжили по дороге: конвертация может аккуратно сверстать таблицу и так же аккуратно потерять строку или переставить разряды.
Отдельный валидатор даёт способ пометить сомнительные участки для проверки до того, как они попадут в индекс. Это рекомендация автора материала, а не результат измерений: сколько ошибок ловит Jev и какую долю от общего числа они составляют, в источниках не сказано. Пользу придётся оценивать на своём корпусе.
Как ошибка OCR превращается в неверный ответ чат-бота
Типовой сценарий отказа. В PDF таблица с показателями за квартал. OCR путает 8 и 3 или склеивает две строки. Чанк с неверным числом уходит в индекс. Пользователь спрашивает, сколько составила выручка в третьем квартале, retrieval находит именно этот чанк, и бот отвечает с цитатой и ссылкой на документ.
Ответ выглядит обоснованным: есть источник, есть формулировка, есть число. Проверить его можно только вручную, сверив с исходным PDF, или после жалобы пользователя. Ошибка при этом не остаётся единичной: один и тот же чанк может попасть в десятки ответов, и каждый раз бот будет уверенно повторять неверное число.
Схема проверки до индексации: OCR → скоринг → порог → ручная проверка
- Прогнать документы через OCR-парсер и сохранить кропы, по которым он работал: без них валидатору нечего сверять.
- Для каждого кропа вызвать Jev с парой «изображение плюс распознанный фрагмент» и записать скор рядом с текстом.
- Задать порог, ниже которого участок считается сомнительным. Порог подбирается на своих документах: калибровка шкалы 0–1 в релизе не описана.
- Отправить сомнительные фрагменты на ручную проверку или в карантин, не допуская их в индекс.
- Индексировать остальное и хранить скор в метаданных чанка, чтобы при спорном ответе быстро находить первоисточник проблемы.
Проверять всё подряд дорого. Каждый вызов валидатора на 2B, это вычисления и задержка, а на большом архиве счёт идёт на сотни тысяч фрагментов. Разумный компромисс: обязательный скоринг для страниц с таблицами и формулами, выборочный для остальных и полный прогон при повторной индексации критичных документов.
Jev и сторонние OCR-парсеры: валидатор без привязки к OpenBMB
Jev может оценивать результаты других OCR-парсеров, то есть использовать парсер OpenBMB не обязательно. Практический смысл в том, что валидатор добавляется независимым слоем контроля поверх уже выбранного решения. Если текущий парсер устраивает по скорости и формату вывода, менять его не нужно: достаточно поставить проверку после него.
Ограничение стоит держать в голове. В сообщении о релизе нет данных о том, на каких документах обучался Jev, а разные парсеры ошибаются по-разному: один теряет строки таблиц, другой ломает формулы, третий путает языки в смешанном тексте. Утверждать, что Jev одинаково хорошо работает с любым OCR, нельзя, это не подтверждено.
Первый тест строится просто: взять 20-30 фрагментов, где правильный ответ вы знаете заранее, прогнать через свой парсер и через Jev и посмотреть, отделяет ли скор верные фрагменты от неверных. Если распределение оценок не разделяет две группы, валидатор на этих документах бесполезен независимо от заявленных возможностей.
Как развернуть локально: репозиторий, квантованные веса и требования
Код и веса обеих моделей распространяются под Apache 2.0, инструкции по локальному развёртыванию и ссылки на квантованные веса собраны в GitHub-репозитории. Квантованные варианты снижают требования к VRAM, а для домашней GPU или небольшого сервера это часто единственный способ уложиться в доступную память. Точные размеры квантов, требования к VRAM и версии CUDA в сообщении о релизе не приводятся: их нужно смотреть в самом репозитории.
Ресурсы считайте сразу на две модели: парсер на 1.3B и валидатор на 2B. Их можно держать на одном устройстве последовательно или разнести по разным GPU, если железо позволяет. При последовательной схеме вызов валидатора идёт после парсера, и пиковая память определяется большей из двух моделей, при параллельной складываются обе.
Скорость локального инференса редко растёт от одной настройки. Эксперимент по ускорению MoE-инференса в llama.cpp на RTX 4080 показывает, что часть низкоуровневых патчей даёт прирост только в узких конфигурациях, а где-то приводит к регрессии. Планируя пропускную способность пайплайна, опирайтесь на замеры на своём железе.
Ограничения релиза и чего не хватает для внедрения
- Дата выхода моделей в исходном сообщении не указана.
- Нет точных метрик качества: ни по распознаванию, ни по тому, насколько скор Jev совпадает с реальными ошибками OCR.
- Языки ограничены китайским и английским, другие форматы документов и языки не перечислены.
- Не раскрыто, на каких данных обучался Jev и как откалибрована его оценка от 0 до 1.
- Нет данных о поведении валидатора на рукописном тексте, плохих сканах и сложной многоколоночной вёрстке.
Вывод трезвый: перед нами инструмент с понятной архитектурой, но с неподтверждённым на независимых данных качеством. Проблема не в самой идее отдельного валидатора, а в отсутствии публичных замеров: вы не знаете заранее, поймает ли Jev ту самую переставленную цифру в вашей таблице.
Независимые замеры стоит ждать от сообщества. Отслеживать свежие обсуждения и публикации по моделям удобно через Daily Papers на Hugging Face: там видно, какие работы и релизы активно обсуждают, и оттуда проще перейти к карточкам моделей и замерам.
Кому подходит связка MiniCPM-OCR 1.0 + Jev и с чем её сравнивать
Связка уместна там, где ошибка в числе дороже задержки на проверку: локальный RAG по PDF с таблицами и формулами, домашний AI-сервер с документами по работе, проекты с финансовой отчётностью, прайсами и техническими паспортами. Общий признак один: извлечённые числа потом цитируют и на них опираются.
Для простых задач без таблиц и формул дополнительный валидатор скорее избыточен. Он добавляет 2B к нагрузке на VRAM, вызов на каждый фрагмент и ещё один шаг в пайплайне, который нужно поддерживать. При частой полной переиндексации больших архивов стоимость проверки становится заметной статьёй расходов.
Прямых альтернатив с той же ролью, отдельной моделью-валидатором OCR с открытыми весами, в материалах о релизе не упоминается, сравнительных бенчмарков тоже нет. Сравнивать уместно с открытыми vision-language моделями, которые берут OCR вместе с другими задачами: например, SenseNova-Vision-7B-MoT закрывает детекцию, OCR, глубину и сегментацию одним чекпоинтом, но распространяется по некоммерческой лицензии весов. Это другой класс задач: одна модель делает много всего, а не проверяет чужую работу.
Разумный первый шаг: пилот на 100-200 страницах своего корпуса. Прогнать OCR, посчитать скор Jev по всем фрагментам, вручную проверить нижние 5-10% и для контроля верхние 5%, замерить время и VRAM на фрагмент. Если сомнительные участки совпадают с реальными ошибками, интеграция имеет смысл. Если скор на ваших документах хаотичен, экономия обернётся лишней ручной работой и второй моделью в обслуживании.