OXR 1.0 (Optical Everything Recognition) - открытая модель от команды SoMark, которая превращает PDF и изображения документов в пригодные для агентов данные: Markdown или JSON с координатами элементов разметки. У модели 1.3 млрд параметров, её обучили с нуля, а на посттренинге прогнали через цикл рекурсивного самоулучшения (RSI). В анонсе проекта команда заявляет первые места на olmOCR-Bench, OmniDocBench и DocParsingBench и лидерство по скорости среди открытых моделей парсинга документов в тестах на RTX PRO 6000.
Практическая ценность в выходном формате. Классический OCR отдаёт строку текста, из которой потом нужно восстанавливать таблицы, заголовки и порядок чтения. OXR отдаёт структуру сразу: тип элемента, содержимое и bounding box. Такой результат уходит агенту или в RAG-индекс без промежуточного слоя эвристик.
Одну оговорку стоит держать в голове с самого начала. Все рекорды из анонса - это заявления SoMark. Независимых замеров в источнике нет, а численные результаты вынесены в docs/benchmark.md вместе с инструкциями по воспроизведению. Дальше разобрано, что именно обещает команда, как устроен пайплайн и как проверить модель на своих документах.
Что такое OXR 1.0 и какую задачу она решает
Название расшифровывается как Optical Everything Recognition, то есть распознавание всего, что есть на странице. На вход подаётся PDF или картинка, на выходе получается документ с сохранённой структурой. Markdown удобен для чтения и для загрузки в контекст LLM. JSON с координатами нужен для программной обработки: подсветить фрагмент в исходном PDF, показать, откуда взялось число в ответе агента, отфильтровать элементы по типу.
Чем OXR отличается от обычного OCR и парсеров PDF
Классический OCR (Tesseract, PaddleOCR и их аналоги) возвращает текст с координатами слов или строк. Дальше начинается ручная склейка: собрать таблицу из строк, определить заголовок, восстановить порядок чтения в многоколоночной вёрстке. Парсеры, читающие структуру самого PDF-файла, работают быстрее, но ломаются на сканах и на документах со сложной графикой.
OXR делает этот шаг сама: в выводе есть тип элемента и его границы. Команда заявляет 13 типов элементов, среди них формулы, таблицы, химические уравнения, химические структуры и блоки кода. Для агентного сценария это означает, что таблицу можно отправить в одну ветку обработки, формулу в другую, блок кода в третью, не разбирая предварительно весь текст регулярками.
Разница видна и в единице работы. OCR оперирует строками и словами, OXR оперирует элементами документа. Когда агенту нужно сослаться на источник, ему нужен не абстрактный текст со страницы 4, а конкретный блок с координатами, который можно показать пользователю.
Кому это нужно: сценарии для агентов и RAG
- Подготовка корпуса для RAG: структурированный Markdown режет документ на осмысленные чанки, а координаты позволяют вернуть ссылку на страницу и область.
- Извлечение таблиц из отчётов и финансовых документов, где важны связи между заголовками и ячейками, а не только значения.
- Разбор научных статей с формулами и таблицами в отдельных блоках, а не в виде каши из символов.
- Сканы и рукописные вставки, документы со сложной вёрсткой: газеты, экзаменационные листы A3, вертикальный текст.
- Проверка ответов: JSON с bounding box позволяет подсветить место в документе, откуда взят фрагмент, и это дешевле, чем поднимать вторую модель для верификации.
Бенчмарки и скорость: что именно заявляет SoMark
Заявленные результаты выглядят так: при 1.3B параметров OXR занимает первое место на olmOCR-Bench, OmniDocBench и DocParsingBench. Отдельно команда подчёркивает особенно широкий отрыв в распознавании таблиц и первое место по скорости среди открытых моделей парсинга в тестах на RTX PRO 6000. Абсолютных значений (баллов, страниц в секунду) в описании нет, полные таблицы и инструкции по воспроизведению лежат в docs/benchmark.md.
Размер 1.3B здесь важнее, чем кажется. Меньше параметров означает ниже требования к памяти, выше пропускная способность и дешевле инференс. Обратная сторона тоже очевидна: запаса по «пониманию» экзотических документов у компактной модели меньше, чем у крупных VLM, и проверять это нужно на своих данных, а не по сводной таблице. Для сравнения: часть открытых OCR-моделей идёт в диапазоне 0.7-3B параметров, и разброс качества между ними на конкретной задаче бывает больше, чем между соседними строчками рейтинга.
Почему отрыв в таблицах - главный аргумент
Таблицы исторически слабое место OCR-пайплайнов. Объединённые ячейки, многострочные заголовки, вложенные таблицы, отсутствие видимых границ в сканах: всё это ломает восстановление структуры. Ошибка в одной ячейке обходится дорого, потому что число уезжает в отчёт, в индекс или в ответ чат-бота, и там его уже никто не перепроверит.
SoMark заявляет особенно широкий отрыв именно в table parsing. Принимать это на веру не стоит: публичный бенчмарк редко повторяет вёрстку внутренних форм, а «сложная таблица» в вашем случае может означать совсем не то, что в датасете. Как открытые OCR-модели соотносятся по таблицам, формулам и мультиязычности, разбирается в сравнении открытых OCR-моделей 2026 года.
Скорость на RTX PRO 6000: что это значит на практике
Первое место по скорости получено на RTX PRO 6000, карте профессиональной линейки, а не на потребительской GeForce из домашней сборки. Эти цифры не описывают пропускную способность на 24 ГБ видеопамяти, на CPU или на Apple Silicon, поэтому переносить выводы на своё железо без замеров нельзя. Команда объясняет прирост переработкой архитектуры обработки на уровне задач (task-level redesign), чтобы парсинг шёл быстрее без потери точности; деталей этого решения в описании не раскрывается.
Для планирования нагрузки полезна самая общая логика: 1.3B параметров позволяют держать модель на одной GPU и обрабатывать поток документов батчами, а не по одному. Конкретный потолок страниц в секунду зависит от разрешения рендера страницы, длины вывода и настроек батча, и его придётся измерять самому.
Как устроен пайплайн OXR: от изображения до Markdown и JSON
Пайплайн, который описывает SoMark, складывается из нескольких слоёв: обучение с нуля, посттренинг с циклом RSI, переработанная на уровне задач архитектура обработки, распознавание 13 типов элементов с bounding box и отдельный подключаемый модуль layout-анализа. Число слоёв, тип энкодера и разрешение входа в материалах не раскрываются, поэтому дальше только то, что подтверждено описанием проекта.
RSI на посттренинге: что это даёт и чего не гарантирует
Recursive self-improvement, или рекурсивное самоулучшение, это цикл, в котором модель на этапе посттренинга дообучается на результатах собственной работы. Упрощённо схема выглядит так: модель размечает данные, варианты отбираются по заданному критерию и возвращаются в обучение, цикл повторяется. Смысл в том, чтобы поднять качество там, где ручной разметки мало или она слишком дорогая.
SoMark называет это первым применением RSI в парсинге документов. Проверить первенство сложно: формулировка описывает приоритет команды, независимого подтверждения в источнике нет. Практический вывод проще. Самоулучшение работает на том распределении данных, которое попало в цикл. Если ваши документы заметно отличаются от бенчмарочных, RSI ничего не гарантирует, и нужен собственный тест.
13 типов элементов и координаты разметки
Модель размечает формулы, таблицы, химические уравнения, химические структуры, блоки кода и другие типы, всего 13, и прикладывает к каждому координаты bounding box. Отсюда два практических следствия. Можно маршрутизировать обработку по типам: таблицы в один индекс, формулы в другой, код в третий. И можно привязать ответ к оригиналу, показав пользователю конкретную область страницы.
Химические уравнения и структуры в списке типов выглядят неожиданно, но объяснимо: научные публикации и патенты часто содержат и то, и другое, а обычные OCR-парсеры превращают их в нечитаемый набор символов. Если ваш корпус состоит из юридических договоров, эти типы просто не будут срабатывать, а на качестве текста это не отразится.
Подключаемый layout-анализ: главная архитектурная особенность
Layout-анализ отвечает за то, как страница нарезана на блоки и в каком порядке их читать. Обычно эта часть вшита в парсер: ошиблась модель на вашей вёрстке, и менять приходится весь инструмент. OXR, по заявлению SoMark, первой сделала модуль анализа разметки независимым и подключаемым.
Схема такая: встроенную layout-модель заменяют собственной, при этом OXR продолжает отвечать за распознавание контента и порядок чтения. Разделение задач ускоряет парсинг и позволяет адаптировать модель под конкретные документы с минимальными усилиями по интеграции.
Когда стоит заменять встроенную layout-модель
- Документы с нестандартной вёрсткой, где встроенная сегментация стабильно режет блоки не там: бланки, формы с врезками, многослойные макеты.
- У вас уже есть проверенная layout-модель, обученная на вашем домене, и вы не хотите терять её качество.
- Нужен контроль над сегментацией под конкретный пайплайн, например чтобы блоки определённого типа уходили на отдельную обработку.
Замена не бесплатное улучшение. Свою layout-модель нужно иметь, обучить или хотя бы настроить, а потом интегрировать. Если встроенный анализ разметки справляется с вашими документами, менять нечего.
Что сохраняется при замене layout-модели
По заявлению SoMark, при замене layout-модели OXR сохраняет распознавание контента и определение порядка чтения. Меняется только сегментация, весь остальной пайплайн переписывать не нужно. Это и есть основной аргумент в пользу модульной схемы: вы подменяете слабое звено, а не собираете парсер заново.
Конкретные интерфейсы, формат передачи блоков и требования к выходу собственной модели в анонсе не описаны, их нужно смотреть в документации и репозитории проекта. Перед тем как планировать замену, стоит убедиться, что ваша layout-модель отдаёт данные в ожидаемом виде.
Сложные документы: где OXR заявляет сильные стороны
В описании проекта перечислены экзаменационные листы формата A3, газеты, вертикальный текст и рукопись. Каждый пункт - отдельная головная боль для парсера. Газета требует корректного порядка чтения при многоколоночной вёрстке с врезками. Лист A3 часто содержит несколько колонок заданий и таблицы, которые легко перепутать с основным текстом. Вертикальный текст ломает базовое предположение о горизонтальных строках. Рукописные пометки поверх печатного текста сбивают модели, обученные на чистых сканах.
Именно для таких случаев и пригодится подключаемый layout-анализ: если встроенная модель неверно делит страницу на блоки, её можно заменить, не отказываясь от распознавания контента. Гарантий идеального качества здесь нет, есть заявление команды о хорошей работе на этих типах документов. Проверять придётся на своих образцах, желательно на тех, где текущий парсер уже ошибался.
Как оценить OXR под свою задачу: практический чек-лист
- Прочитать документацию и
docs/benchmark.md: там полные результаты и инструкции по воспроизведению оценок. - Взять
somark-py(Python SDK и CLI) илиsomark-js(JS/TS SDK и CLI), чтобы не собирать обвязку вручную. - Собрать небольшой набор своих документов, обязательно с таблицами и хотя бы одним сложным макетом.
- Сравнить с текущим парсером по структуре вывода, а не только по тексту: сохранился ли порядок чтения, совпадают ли границы таблиц.
- Проверить, удобен ли JSON с координатами вашему агенту или RAG-пайплайну, и не придётся ли переписывать слой постобработки.
Что смотреть в документации и docs/benchmark.md
Ищите четыре вещи: полные результаты по olmOCR-Bench, OmniDocBench и DocParsingBench, инструкции по воспроизведению оценок, описание форматов вывода Markdown и JSON, а также раздел про подключаемый layout-модуль. Воспроизведение бенчмарка остаётся единственным способом проверить заявления команды, не полагаясь на маркетинг.
Минимальный тест на своих документах
Хватит 10-20 документов, но набор должен быть неудобным. Возьмите минимум несколько таблиц с объединёнными ячейками, один сложный макет (многоколоночная вёрстка, газетная страница, вертикальный текст) и один скан или документ с рукописными пометками. Дальше смотрите на четыре критерия: сохранён ли порядок чтения, корректны ли границы и содержимое таблиц, не потерялись ли формулы и блоки кода, пригоден ли JSON с координатами для дальнейшей обработки.
Если сравниваете с другой компактной моделью, полезно поставить рядом опыт с Surya OCR 2.5 на 689M параметров: там тоже есть layout с порядком чтения и таблицы, но другой набор ограничений и другая схема лицензирования весов.
Ограничения и на что обратить внимание перед запуском
- Все результаты и «первые места» - заявления команды SoMark. Независимого подтверждения в источнике нет, численные значения тоже не приведены.
- Первенство RSI в парсинге документов и первенство подключаемого layout-анализа сформулированы самой командой, а не внешними исследователями.
- Тест скорости проведён на RTX PRO 6000 и только среди открытых моделей парсинга. Для потребительской GPU, CPU или кластера цифры нужно получать заново.
- Замена layout-модели требует собственной модели и её интеграции. Это работа, а не переключатель в конфиге.
- Лицензия весов, требования к видеопамяти и точные форматы вывода в предоставленных материалах не указаны. Их нужно смотреть в репозитории и документации, а не додумывать.
- 1.3B параметров - компромисс: меньше ресурсов и выше скорость, но меньше запаса на экзотические документы. Проверяется только эмпирически.
Место OXR в экосистеме SoMark и вывод
OXR - ядро распознавания, вокруг него команда собрала инструменты для работы с результатом и интеграции.
| Инструмент | Назначение |
|---|---|
| SoMarkDown | Официальная библиотека парсинга и рендеринга Markdown для SoMark и OXR |
| SoMarkDownViewer | Приложение для живого редактирования SoMarkDown |
| SoPDF | Высокопроизводительная библиотека обработки PDF с открытой лицензией |
| Docision | MultiModal Jev for Document |
| somark-py | Официальный Python SDK и CLI для SoMark и OXR |
| somark-js | Официальный JS/TS SDK и CLI для SoMark и OXR |
Смотреть в сторону OXR 1.0 имеет смысл, если нужен открытый парсинг PDF и изображений в Markdown или JSON с координатами для агентов и RAG, важны скорость и компактный размер 1.3B, а возможность подменить layout-модель закрывает вашу специфику вёрстки. Если задача ограничивается извлечением plain text из простых документов, выгода от структурного вывода и координат будет неочевидной: обычный OCR справится дешевле.
Порядок действий простой. Откройте docs/benchmark.md, проверьте, на каких данных получены первые места, затем прогоните модель через somark-py на десятке своих документов и сравните структуру вывода с тем парсером, который использует ваш пайплайн сегодня. Если структура и координаты действительно экономят слой постобработки, модель остаётся в проекте. Новые релизы в этой нише выходят часто, отслеживать их удобно через Daily Papers на Hugging Face.