OCR математических формул: Pix2Tex, Mathpix, TrOCR

Почему распознавание формул ломается на реальных документах

Распознавание формул ломается не на уровне символов, а на уровне структуры. Формула — это двумерная вёрстка: положение глифа относительно базовой линии задаёт, индекс это, показатель или множитель. Модели, читающие строку слева направо, теряют эту геометрию и возвращают корректную разметку, которая описывает другое выражение.

Наложенные индексы — первый класс ошибок распознавания: вложенные степени и двойные подстрочные знаки схлопываются в один уровень. Дроби в несколько ярусов и матрицы добавляют вторую ось, где границы строк и столбцов определяются по зазорам, а скобки переменной высоты мешают восстановить разметку. Рукописные формулы усугубляют картину: почерк не даёт стабильных пропорций, а правки поверх печатного текста читаются как часть выражения.

Качество сканов работает как множитель ко всем этим сбоям. Перекос страницы, неравномерная засветка, артефакты сжатия и тонкие штрихи превращают индекс в шум, поэтому порог бинаризации приходится подбирать постранично — иначе часть знаков сливается с фоном. Даже сильные на печатных выражениях решения проседают на таких файлах.

Отдельная категория — контекст вокруг выражения. Сквозная нумерация внутри абзаца, ссылки вида «см. (14)», разрыв формулы между строками или колонками требуют не распознавания символов, а разбора структуры документа. Поэтому мы оцениваем долю полностью совпавших выражений, а не точность по отдельным знакам: последняя метрика маскирует сдвинутый индекс и потерянную скобку.

Измеримый эффект: точность, скорость, доля ручной правки

Точность распознавания считаем не по «числу угаданных символов», а по формуле целиком: нормализуем разметку и сравниваем с эталоном, который подготовил методист. На контрольной выборке типовых учебных материалов одиночные дроби и степени распознаются почти без ошибок, а весь остаток погрешности концентрируется в многострочных системах, матрицах с индексами и дробях с вложенными скобками — там и появляется доля ручной правки, которую видно в отчёте.

Работаем через локальный распознаватель Pix2Tex: он идёт по нашей инфраструктуре, страницы не уходят во внешние сервисы, а на выходе мы получаем оценку уверенности по каждому фрагменту. Формула ниже порога не попадает в готовый документ автоматически — она уходит в очередь на проверку с подсветкой сомнительных мест. Так закрывается самый дорогой класс отказов: тихо неверная формула, которая доходит до редактора и живёт в макете до вёрстки.

Скорость обработки архива определяется не распознаванием, а верификацией. Пакетный режим разбирает тысячи страниц за часы, узкое место смещается на проверку: инженеры сами размечают сложные случаи, а простые проходят по правилу уверенности без участия человека. На выходе — доля ручной правки в процентах от числа формул, распределение ошибок по типам и набор сложных формул заказчика, на котором принимаем результат и отслеживаем регресс после любых изменений.

Варианты разбора формул: сравнение подходов и режимов

Выбор режима распознавания формул определяют три вещи: характер исходников (печатный набор, рукопись, сканы низкого качества), требования к конфиденциальности и допустимая доля ошибок на выходе. Формулы нельзя «поправить по смыслу» — потерянный индекс степени или граница дроби меняют результат, поэтому режим подбирают под задачу, а не «самый точный вообще». Отдельно фиксируем формат вывода: LaTeX для вставки в редакторы и MathML для веба — от него зависит, что дальше делает конвейер.

Гибридную схему и дообучение не противопоставляем: размеченные правки из интерфейса проверки становятся корпусом для следующей итерации, и доля формул, прошедших без правки, растёт от запуска к запуску. Перед постановкой потока в работу мы прогоняем ваш набор документов и сверяем рендер LaTeX и MathML в том редакторе, где формулами будут пользоваться, — так несовместимость вывода выясняется на тесте, а не на середине выгрузки.

Этапы внедрения распознавания формул в конвейер документов

Распознавание формул ломается не на модели, а на разрыве между демонстрационным примером и реальным корпусом. В одном потоке идут сканы с шумом и перекосом, векторные PDF, где глифы разложены по координатам, и фотографии с доски. Поэтому работы идут фиксированной последовательностью: сначала измеряем корпус, потом строим схему разбора, затем настраиваем и передаём.

1. Аудит корпуса документов. Считаем долю страниц с формулами, типы источников, шрифты, языки выкладок. Фиксируем, что встречается: дроби, матрицы, индексы, многострочные выводы. На выходе — карта: где разбор идёт сразу, а где нужна предобработка.
2. Эталонная выборка. Несколько сотен страниц, размеченных вручную, с балансом по типам формул. Метрика — доля выкладок, распознанных целиком и с верной структурой: точность по символам скрывает потерянный индекс или вложенность.
3. Схема разбора. Задаём порядок: поиск областей формул, вырезание с запасом, нормализация масштаба и контраста, распознавание, сборка обратно в разметку документа. Движок выбираем по результату на выборке, а не по описанию.
4. Настройка разбора. Под ваш корпус: порог детекции областей, словарь команд, пост-обработка — восстановление скобок и служебных команд, разрешение конфликтов с текстовым слоем страницы.
5. Проверка на эталонной выборке. Прогоняем конвейер целиком, разбираем ошибки по классам: слипшиеся индексы, потерянные знаки, неверная вложенность. Отдельный слепой набор страниц, не участвовавших в настройке, отделяет реальную точность от подгонки.
6. Передача решения. Отдаём код, конфигурацию, словари и регламент эксплуатации: как подключать новые типы формул, что проверять при просадке точности, где смотреть журналы и как обновлять выборку.

Что остаётся у заказчика: артефакты и регламенты

Решение передаём не как сервис, работающий на нашей стороне, а как комплект, который ваша команда сопровождает без нас. Каждый материал проверяется на приёмке: если процесс нельзя воспроизвести по документам, передача не закрыта.

• Конфигурации распознавания: параметры предобработки страниц, пороги уверенности, правило отправки фрагмента на ручную проверку.
• Схемы разбора: как изображение превращается в структуру формулы — границы блоков, дроби, индексы, матрицы, многострочные выражения.
• Словарь обозначений: соответствие символов принятой у вас нотации, чтобы результат совпадал с тем, как формула пишется в ваших материалах.
• Протокол качества: набор эталонных страниц с разметкой и метрика точности, к которой решение обязано возвращаться после каждой правки.
• Инструкции для редакторов: что делать с неуверенными фрагментами, как помечать правки и какие ошибки считать системными, а какие — единичными.
• Регламент изменений: новый тип формул проходит через тот же протокол качества, а не правит конфигурацию по месту.
• Порядок передачи: доступы, окружение, журнал обращений и ответственный инженер на период сопровождения.

Перед закрытием приёмки комплект прогоняется на вашей стороне: ваш специалист поднимает окружение и повторяет эталонный прогон. Совпадение результата с нашим и есть доказательство, что решение действительно передано.

Кейс: научное издательство и поток рукописных статей

Академическое издательство принимало рукописи сканами и фотографиями: авторские правки, пометки на полях, формулы от руки в две строки. Каждое выражение редактор сверял с изображением и набирал заново — статья на 40–60 формул забирала почти рабочий день, а очередь вычитки растягивалась на недели.

Что собрали

Конвейер распознавания формул: детекция областей с выражениями на странице, распознавание, приведение к LaTeX, затем структурная валидация — баланс скобок, вложенность дробей, парность индексов, сверка символов со словарём и с исходным растром. Ручной вычитке остаются только фрагменты, где валидатор не сошёлся с картинкой. На старте брали сервис Mathpix как эталон качества и на его фоне подбирали модель под рукописные сканы: для печатных страниц хватало одной ветки, для черновиков — дообучения на разметке самой редакции.

Метрики до и после

Полностью ушли классы ошибок, которые раньше ловились только на корректуре: перепутанные верхние и нижние индексы, потерянные дробные черты и скобки, подмена похожих символов. Их отсекает валидация до попадания выражения в макет — редактор тратит время на смысл, а не на сверку знаков.

Чем отличается разбор формул от обычного распознавания текста?

Строчный распознаватель исходит из того, что текст линейный: знаки идут слева направо, а связь между ними задаётся только порядком. Формула так не устроена — числитель стоит над знаменателем, индекс уходит вверх или вниз от базы, радикал накрывает выражение чертой, матрица задаёт сетку. Одни и те же знаки в разной геометрии читаются как разные выражения, поэтому распознавание текста отдаёт строку символов, но не смысл.

Отсюда три слоя работы поверх обычного распознавания. Первый — детекция и классификация знаков: тонкие штрихи, засечки и наклонное начертание мешают так же, как рукописный ввод. Второй — разметка структуры выражения: по относительным позициям и размерам определяются границы дроби, степень корня, пределы суммирования, вложенность скобок. Сдвинутая граница дроби меняет смысл целиком, поэтому структуру восстанавливают и проверяют отдельно от символов.

Третий слой — словарь символов и грамматика записи. Распознанные знаки сопоставляются с известными операторами, греческими буквами и функциями, переменные связываются со своими индексами, а собранная структура проверяется на синтаксис. Так снимаются классические неоднозначности: «l» и единица, буква x и знак умножения, ноль и заглавная O. Словарь ограничивает пространство гипотез, а проверка отсекает ветви, которые формально собраны, но математически бессмысленны.

Контекст добирает остаток неоднозначности: соседние знаки и общая форма выражения подсказывают, предел перед нами или индекс. Модели, которые видят выражение целиком, а не скользят по строке, ошибаются в таких местах заметно реже. На выходе обычное распознавание даёт текст, который остаётся перечитать и перепечатать, а разбор формул — дерево выражения, готовое к отрисовке и вычислению.

Технические сомнения: качество, проверка, внедрение

Печатная вёрстка и рукописные выкладки — два разных режима, и одним конвейером их не закрыть. Для печатных формул подходит готовый сервис разбора вроде Mathpix, но он отправляет страницу на внешний сервер — для закрытого контура это неприемлемо. В закрытом контуре разворачиваем модель на ваших мощностях: документы не покидают периметр, журнал обработки остаётся у вас.

Рукописный ввод дообучаем на ваших образцах: несколько сотен размеченных страниц дают прирост именно там, где базовая модель путает — похожие индексы, строчная и прописная, знак производной. Ручная вычитка не исчезает, а становится точечной: редактор смотрит не всё подряд, а фрагменты ниже порога уверенности, которые система подсвечивает сама.

Нужна ли сплошная ручная вычитка?

Нет. Уверенность считается по каждому фрагменту, редактор проверяет только спорные места — обычно доли процента от объёма. Сплошной проход оставляем на финальную сверку.

Что делать, когда модель ошибается на новых формулах?

Правки редактора автоматически становятся разметкой и попадают в набор для дообучения модели. После нескольких циклов класс ошибок закрывается, доля ручных правок падает.

Обсудим задачу: что уточнить до начала работ

Чем точнее вводные, тем меньше допущений в оценке и тем быстрее мы возвращаемся с планом работ. Перечисленные ниже пункты определяют архитектуру распознавания формул — если данных по какому-то из них нет, зафиксируем допущение прямо в оценке.

• Типы источников: сканы печатных изданий, фотографии рукописных записей, PDF с текстовым слоем, скриншоты. От этого зависит предобработка — выравнивание, очистка от шума, бинаризация — и выбор модели.
• Объём корпуса: сколько страниц, какая доля из них содержит формулы, сколько уже размечено вручную. Это определяет трудоёмкость подготовки данных и режим обучения.
• Целевые метрики: точность на уровне символа и доля формул, распознанных целиком без правки. Эталонный набор в несколько сотен страниц позволяет измерять качество численно, а не на глаз.
• Требования к контуру: закрытый сервер заказчика, облако или гибридная схема; нужен ли офлайн-режим, что можно передавать наружу, что писать в журналы доступа.
• Формат результата: LaTeX, MathML или собственная разметка; нужны ли координаты формулы на странице и связь с исходным изображением.
• Что происходит с распознанным дальше: ручная проверка оператором, автоматическая проверка синтаксиса, поиск по формулам. Это задаёт порог качества, ниже которого результат не принимается.
• Формат передачи: развёрнутый контур, обученная модель, скрипты обучения, размеченный эталонный набор, документация и инструкция для поддержки.

Опишите задачу в этих границах — вернёмся с оценкой, планом работ и вариантами архитектуры.