Публичные OCR-лидерборды врут вашему RAG-пайплайну — вот как это проверить
Публичные лидерборды не учитывают русский язык и структуру документов. Разбираем, как Cloud.ru собрал собственный OCR-бенчмарк для RAG-пайплайна — и что из этого вышло.
Команда Cloud.ru выбирала OCR-модель для RAG и обнаружила: модель с отличным CER на публичных датасетах ломала пайплайн на реальных русских документах. Они собрали собственный бенчмарк — и это оказалось не лишней работой, а обязательным шагом.
Почему OCR для RAG — это не «просто достать текст»
В классическом документообороте OCR решает одну задачу: превратить скан в машиночитаемый текст. Для RAG (Retrieval-Augmented Generation) это только первый шаг, от которого зависит всё остальное.
Если OCR ошибся — сплиттер разрежет документ посередине логической единицы. В индекс попадут мусорные обрывки. На этапе retrieval поисковик найдёт нужный чанк, но текст в нём оборван на полусло... и языковая модель честно ответит по этому обрывку. Никто не заметит, пока кто-то не проверит ответ вручную.
Важный момент: плохой OCR в контексте RAG — это не обязательно опечатки и перепутанные символы. Это может быть потеря структуры: таблица расплылась в абзац, заголовок потерялся, порядок строк перепутался. CER (Character Error Rate — доля ошибочно распознанных символов) при этом выглядит прилично, а пайплайн уже сломан: поисковик не находит нужные строки таблицы, потому что структурно они перестали существовать.
Где публичные бенчмарки подводят
Команда начала с публичных лидербордов — OCRBench, PubTabNet, Nougat-style. Они помогли сузить список кандидатов, но дальше не справились по трём причинам.
Русского языка почти нет. Русская типографика — отдельная история: кавычки-«ёлочки», буква «ё» и её отсутствие, длинные составные слова. Модель, которая хорошо читает англоязычные абстракты, может провалиться на статье на русском.
Фокус на среднем. Публичные бенчмарки сваливают в одну кучу простые сканы, диаграммы, рукописи и таблицы — на выходе одно агрегированное число. По нему невозможно понять, как модель поведёт себя именно с расчётным листком сотрудника или сканом паспорта.
Структура документа не измеряется так, как нужно RAG. Классические метрики CER, WER, BLEU говорят про символьную и словарную точность. Табличные бенчмарки вроде PubTabNet проверяют восстановление таблиц, но не отвечают на главный вопрос: сохранит ли модель весь документ как связную Markdown-структуру с заголовками, таблицами и логической иерархией.
Как собрать датасет без ручной разметки
Ключевой вопрос любого OCR-бенчмарка — откуда взять честный Ground Truth. Ручная разметка сканов дорогая, медленная и сама вносит ошибки.
Команда Cloud.ru пошла от обратного: брали документы с уже существующим текстовым исходником и из него рендерили одновременно PDF (вход для модели) и Markdown (эталон для сравнения). Текст никогда не размечается руками — это принципиально. Такой подход даёт большой датасет без риска «замусорить» эталон человеческими ошибками.
Итоговый состав датасета:
| Источник | Что внутри | Зачем | |---|---|---| | Русская Википедия (дамп MediaWiki XML) | Отфильтрованные статьи | Сложная вёрстка, таблицы, инфобоксы | | Академические лекции | LaTeX-исходники | Формулы, многоуровневые заголовки | | arXiv | LaTeX научных публикаций | Сложные таблицы, ссылки | | Excel | Финансовые таблицы | Широкие таблицы | | MIDV (сканы паспортов РФ) | JPG + эталонный текст из датасета | Чистая OCR-метрика на коротком сложном тексте |
Паспорта из датасета MIDV стоят особняком: вход уже в виде JPG, а эталонный текст идёт вместе с датасетом — дополнительная разметка не нужна.
Как рендерить документы и собирать пайплайн
Для LaTeX-исходников с arXiv команда использовала fallback-цепочку: сначала latexmk, потом pdflatex, потом tectonic. Статьи с arXiv часто требуют разные пакеты, и такой каскад заметно повышает долю успешно собранных документов.
```bash
Попытка 1
latexmk -pdf -interaction=nonstopmode document.tex
Попытка 2, если latexmk упал
pdflatex -interaction=nonstopmode document.tex
Попытка 3 — tectonic как запасной вариант
tectonic document.tex ```
Wiki XML парсится с фильтрацией служебных страниц и шаблонов — иначе в датасет попадает технический мусор MediaWiki, который ни одна OCR-модель не должна уметь читать.
Для рендеринга Markdown-эталона из LaTeX удобно использовать pandoc:
``bash pandoc input.tex -o output.md --wrap=none ``
Флаг --wrap=none отключает автоперенос строк — иначе pandoc добавляет переносы, которых нет в оригинале, и метрики искажаются.
Чем мерить: метрики для RAG-специфичного OCR
Для символьной точности — стандартный CER. Для структуры — отдельные проверки по типам элементов: заголовки сохранились, таблицы не расплылись в абзацы, иерархия не нарушена.
Практичный подход: считать метрики отдельно по каждому типу документов из датасета, а не агрегировать в одно число. Модель может отлично читать паспорта и плохо восстанавливать таблицы — агрегат это скроет.
```python from jiwer import cer
def evaluate_ocr(predicted: str, ground_truth: str) -> dict: return { "cer": cer(ground_truth, predicted), "has_tables": "| " in predicted, "heading_count": predicted.count("\n#"), } ```
Это минимальный скелет — в реальном бенчмарке к нему добавляются структурные метрики по таблицам (сравнение числа строк и столбцов) и проверка сохранности заголовков через diff.
Где это ломается
LaTeX с нестандартными пакетами. Даже каскад из трёх компиляторов не спасает, если статья использует проприетарный или устаревший пакет. Такие документы нужно отфильтровывать до попадания в датасет, иначе получите PDF с ошибками компиляции в качестве «входа».
Сканы с низким разрешением. Если исходный скан ниже 150 DPI, большинство моделей деградирует независимо от качества на чистых PDF. Это не баг бенчмарка — это честный сигнал о реальных ограничениях.
Таблицы с объединёнными ячейками. Большинство open-source OCR-моделей плохо справляются с colspan/rowspan. Если у вас много таких документов — закладывайте это как отдельную категорию в датасет, иначе проблема утонет в среднем.
Метрика CER не видит структурных потерь. Модель может набрать CER = 2% и при этом полностью потерять все заголовки документа. Без структурных проверок вы об этом не узнаете.
Что попробовать дальше
Если хотите повторить подход: начните с датасета MIDV для паспортов — он публичный, эталоны уже есть, быстрый старт без разметки. Для LaTeX-документов arXiv — выбирайте статьи с тегом cs.CL или cs.AI, там меньше экзотических пакетов. Структурные метрики по таблицам удобно считать через библиотеку table-transformer или простым подсчётом строк в Markdown-таблице. И главное: не агрегируйте результаты в одно число раньше времени — разбивка по типам документов скажет о модели в разы больше.