Каждый день появляются новые LLM, OCR, мультимодальные модели и агенты.
В новостях — одни заголовки: «Модель X побила все бенчмарки». Руководство хочет «самое новое и передовое», команда — «самое лучшее по метрикам». А вот как понять, что конкретно для вашего кейса это действительно лучше — обычно не очень понятно.

В этой статье расскажем, как мы пришли к подходу, который внутри называем Benchmark Driven Development (BDD) — разработка, движимая бенчмарками на своих данных.
(Да, мы знаем, что BDD — это ещё и Behavior Driven Development, тут у нас своя расшифровка ?)

---

Задача из практики: документы в одном длинном PDF

У нас есть реальный кейс.
В продакшене к нам прилетает один большой PDF, внутри которого подряд лежат:

• сканы совершенно разных документов (паспорта, договоры, заявления и целая куча других документов),

• фото документов, «сфотканных на коленках» (буквально, вместе с коленями),

• с перегибами, заломами, шумом, кривыми углами.

Нужно:

1. Определить границы каждого документа внутри PDF.

2. Определить тип документа (что это: договор, паспорт, заявление и т.д.).

На словах задача простая. На практике же вариантов решения — десяток (и это только первые, что приходят в голову):

• Через OCR (распознавание текстов) + текстовую классификацию

  • Выбрать один из множества OCR:

    • дальше классифицировать текст регулярками;

    • или через TF‑IDF + (CatBoost / логрег / любая другая модель);

    • или через BERT‑подобные модели;

    • или вообще отправить всё в LLM (Qwen, DeepSeek, GigaChat и т.д., разных размеров: 1B, 7B, 30B…).

• Через CV‑классификацию по картинке — классифицируем документ до распознавания текста.

• Через мультимодальные LLM — «весь pdf или страница на вход, а на выход сразу тип документа».

• Через агента — собрать цепочку шагов, дать ему инструменты и пусть структурирует документы.

• (В комментариях наверняка сможете добавить ещё варианты ?)

Возникает естественный вопрос:

Какой из подходов реально лучше именно для нашего кейса?
У кого лучше метрики? У кого быстрее обработка? Что дешевле масштабируется?

---

Наивное решение: выбрать всё «самое лучшее по бенчмаркам»

Допустим, мы решили задачу «жадно»:

1. Берём популярный бенчмарк для OCR.

2. Выбираем модель с вершины таблицы (с учётом лицензии и ресурсов).

3. Ставим её первым шагом нашего пайплайна.

4. Далее берём лидерборд LLM нужного размера.

5. Выбираем модель с лучшими метриками, используем для классификации текста.

На бумаге получается прекрасное решение:

«У нас лучший OCR + лучшая LLM по бенчмаркам — значит, мы получили лучшее решение».

Но в реальности всплывают проблемы.

---

Почему опираться только на чужие бенчмарки — опасно

1. Модели тестировались не на ваших данных

Если вы не копались в датасетах бенчмарка, вполне может оказаться, что:

• там чистые, ровные сканы;

• другой язык (или другая доля языков);

• другие типы документов;

• другие артефакты (меньше шумов, изгибов, теней).

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

2. Нечем честно сравнивать разные подходы

Даже если вы собрали пайплайн «OCR -> LLM», остаётся куча вопросов:

• А если вместо LLM использовать простой классический классификатор — будет ли хуже?

• А если выкинуть OCR совсем и попробовать CV‑классификатор по картинке?

• А если взять мультимодальную LLM?

• Как изменится качество если вместо 30B модели взять 7B?

Без единого своего бенчмарка вы сравниваете решения «на ощущениях».

---

Идея: свой бенчмарк как точка опоры

Решение обеих проблем одно и то же:

Нужен свой бенчмарк на своих данных, максимально похожих на реальные продовые кейсы.
Все решения сравнивать в первую очередь на нём.

Звучит вроде очевидно. Но на практике этим очень часто пренебрегают.
Типичные аргументы против:

• «Это неприоритетно, давайте сначала MVP, потом разберёмся».

• «У нас релиз горит, не до бенчмарков».

• «Вот есть же огромный публичный бенчмарк, его делали умные люди на сотнях тысяч кейсов — нам такой не потянуть, давайте ему доверимся».

• «Руководству нужны не бенчмарки, а готовое решение».

Звучит знакомо? Ровно то же самое обычно говорят и про тесты в разработке ПО.

Отсюда и аналогия: Benchmark Driven Development по отношению к Test Driven Development.

---

Benchmark Driven Development по‑нашему

Под BDD (в нашем смысле) мы понимаем следующее:

1. Сначала формируем свой бенчмарк: 1.1. под реальные данные, 1.2. под свои бизнес‑метрики (качество, скор��сть, ресурсы).

2. Потом проектируем и реализуем решения.

3. Каждое существенное изменение пропускаем через бенчмарк: 3.1. новую модель, 3.2. новый инструмент, 3.3. новую архитектуру пайплайна. (прошу прощения за такую нумерацию, md Хабра победить иначе не удалось)

4. Решения принимаются не «по ощущениям», а по числам на своём стенде.

5. Всегда держим в уме, что маленький бенчмарк - это не про достаточные условия, а про необходимые.

---

Наш кейс: свой OCR‑бенчмарк на реальных данных

Начали мы с самого первого шага — OCR.

Как мы собрали бенчмарк

• Взяли 60 реальных изображений документов из нашего продакшена:

  • русский язык;

  • документы с перегибами, изгибами, заломами страниц;

  • фото, сделанные в «полевых условиях» (телефон, неидеальный свет и т.п.).

• Ручная разметка — подготовили корректные эталонные тексты.

• Определили, какие метрики нам важны (качество распознавания, устойчивость к шуму и т.д.).

• Настроили треккинг экспериментов в MLflow, чтобы:

  • быстро запускать тесты нескольких систем;

  • визуально сравнивать результаты и параметры.

60 кейсов кажется очень мало, но на самом деле даже на этом объеме можно сделать очень много полезных наблюдений. А дальше уже каждая команда решает сама нужно ли расширять бенч.

Что показали результаты

На популярных бенчмарках один из OCR‑инструментов (назовём его условно Dots OCR) выглядел очень достойно.

Но на наших данных оказалось, что:

Для наших кейсов Dots OCR показывает результаты до 100 раз хуже, чем PaddleOCR или Surya OCR.

Даже многообещающий DeepSeek OCR со своими инновационными идеями ощутимо уступил тому же PaddleOCR.

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

• посмотрели на общие метрики,

• и прошлись глазами по нескольким конкретным кейсам из бенчмарка.

Что это нам дало

• Теперь у нас есть быстрый стенд:

  • любой новый OCR можно прогнать на наборе своих картинок;

  • за один день получить честное сравнение.

• Не нужно спорить «эта модель лучше, потому что статья на неё нашлась на Хабре» — есть свои цифры.

• Когда выходит «ещё один новый SOTA‑OCR», мы не спорим, а просто добавляем его в бенчмарк.

---

Бенчмарк для второй задачи: границы + тип документа

Дальше стало понятно, что одного OCR‑бенчмарка мало.
Если мы хотим сравнить архитектуры решений, нужно покрывать весь процесс целиком, а не только отдельный шаг.

Что мы сделали

• Взяли реальные PDF с продакшена.

• Разметили:

  • границы документов внутри PDF;

  • тип каждого документа.

• Определили метрики:

  • качество нахождения границ;

  • точность классификации типов;

  • время обработки (latency);

  • потребление ресурсов (CPU/GPU/память).

• Написали скрипты прогона разных решений.

• Настроили интеграцию с MLflow, чтобы:

  • сравнивать пайплайны «под ключ»;

  • видеть, как одна и та же модель ведёт себя в разных конфигурациях.

Почему важно отделить бенчмарк от конкретной идеи

Классическая ловушка:

«Мы решили, что документы можно нормально классифицировать только после OCR -> давайте сделаем бенчмарк только для OCR‑подхода».

В итоге вы автоматически отсекаете альтернативы, которые могут:

• быть быстрее,

• проще масштабироваться,

• и в некоторых кейсах давать не хуже качество.

В нашем случае такой полезной альтернативой оказалась CV‑классификация по изображению.
Для части сценариев:

• она быстрее;

• отлично параллелится;

• требует меньше ресурсов;

• и на некоторых типах документов даёт качество, сравнимое или лучше, чем вариация «OCR + LLM».

Если бенчмарк заточен только под один пайплайн, вы просто не увидите такие варианты.

---

Как внедрить Benchmark Driven Development у себя

Краткий чеклист, который можно адаптировать под свой проект.

1. Чётко сформулируйте задачу и метрики

• Что именно вы хотите оптимизировать?

  • качество (accuracy, F1, WER и т.д.);

  • время ответа;

  • стоимость вычислений;

  • потребление ресурсов.

2. Соберите минимальный, но репрезентативный датасет

Не обязательно начинать с десятков тысяч примеров.

• 50–100 правильно подобранных кейсов могут уже:

  • вскрыть разницу между решениями на порядки;

  • показать слабые места моделей.

• Главное — чтобы данные были максимально похожи на ваши реальные.

3. Разметьте данные руками

Да, это скучно. Но:

• разовая инвестиция сильно окупается;

• только так вы получите честный «золотой стандарт»;

• наконец внимательно посмотрите на свои данные (это, вообще говоря, самое важное).

4. Определите метрики и порог «приемлемо»

• Какие метрики считаются ключевыми?

• Что для вас «достаточно хорошо»?

• Где граница, ниже которой решение явно не годится?

• Маленький бенчмарк не будет достаточным, но будет необходимым для решения.

5. Сделайте воспроизводимый скрипт прогона

• Один скрипт / ноутбук, который:

  • запускает все выбранные модели/пайплайны;

  • считает метрики;

  • сохраняет результаты.

6. Подключите трекинг экспериментов

Мы используем для этого MLflow. Важно:

• хранить:

  • конфигурацию эксперимента;

  • версии моделей / параметров / промптов;

  • метрики;

  • для дебага полезно видеть не только интегральные метрики по всему бенчмарку, но и "пофайловые" результаты;

• иметь возможность быстро сравнить «подход A против подхода B» на одном и том же бенчмарке.

7. Прогоняйте через бенчмарк всё новое

• новую LLM -> сначала в бенчмарк;

• новый OCR -> в бенчмарк;

• новую архитектуру пайплайна -> в бенчмарк.

Через пару итераций команда привыкает, что:

«Аргумент “давайте возьмём X, он модный” не работает без цифр на нашем бенче».
Реализация одного частного случая ничего не значит. Необходимо проскориться на бенчмарке.

8. Используйте бенчмарк в разговорах с руководством

Бенчмарк — это не “внутренняя игрушка инженеров”, а:

• прозрачный способ объяснить:

  • почему вы не взяли “самый модный инструмент”;

  • почему выбранный вариант лучше для бизнеса;

• база для:

  • roadmap’а по улучшениям;

  • оценки эффекта от внедрения новой технологии.

---

Ограничения и то, чего мы пока не показываем

Сами бенчмарки мы, к сожалению, публиковать не можем — внутри реальные документы с персональными данными.

Но если тема окажется интересной, мы можем в отдельной статье:

• подробнее разобрать процесс построения OCR‑бенчмарка, включая отбор кейсов, выбор метрик, сложности разметки;

• показать, как устроен бенчмарк по классификации документов;

• поделиться структурой датасета и примером метрик (на синтетических или обезличенных данных).

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

---

Выводы

• Чужие бенчмарки полезны, но они не знают вашу предметную область.

• Один и тот же «SOTA‑инструмент» на ваших данных может вести себя на порядки хуже, чем более «скромные» решения.

• Свой компактный бенчмарк на десятках хорошо подобранных примеров даёт:

  • честное сравнение разных подходов;

  • аргументы в общении с бизнесом;

  • устойчивость к хайпу вокруг новых моделей.

• Benchmark Driven Development — это по сути:

  «Сначала бенчмарк на своих данных, потом всё остальное».

Если у вас есть похожий опыт (с OCR, LLM или любой другой задачей) — расскажите в комментариях:

• Делали ли вы свои бенчмарки?

• Какие сюрпризы вскрылись, когда прогнали «топовые» модели на своих данных?

• Как вы убеждали руководство вкладываться в бенчмарки?

p.s. Когда-нибудь у нашей компании оживет корп аккаунт и статья будет опубликована на нем со скриншотами из mlflow и подобным.