Задача: выбрать OCR для RAG-пайплайна

Однажды нам понадобилось выбрать OCR-модель для RAG-пайплайна. RAG (Retrieval-Augmented Generation) — архитектура, при которой языковая модель перед формированием ответа обращается к внешнему хранилищу документов: сканам, PDF-файлам, таблицам. Без надёжного OCR вся цепочка работает плохо. Казалось бы, задача простая: смотришь на лидерборды, берёшь лучшую, PROFIT.

Проблема первая: чужой домен, чужой язык

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

Проблема вторая: OCR-точность ≠ качество ответа

Вторая проблема оказалась тоньше. Даже если крутой по всем параметрам бенчмарк для оценки качества распознавания говорит «всё прочитали правильно, я проверил», точность ответов пользователю, который совершает запрос к чат-боту с RAG под капотом, может страдать. OCR-точность и downstream-качество ответов — это разные метрики, и разрыв между ними в реальном продукте оказывается значительно больше, чем следует из таблицы результатов.

Что дальше

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