Продукты класса ContentCapture работают с большими объемами документов, и для бизнеса критична скорость их обработки. Но как убедиться, что система не замедлится после выхода очередного релиза? Здесь на помощь приходит тестирование: наши QA-инженеры регулярно проводят замеры скорости распознавания — например, при обновлении технологии или перед запуском нового проекта.

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

Наши тестировщики шутят, что перед релизом достаточно сказать «что-то стало медленно», чтобы запустить цепную реакцию паники среди продактов и разработчиков. Однако в 90% случаев проблема оказывается не в технологиях, а в том, как проводятся замеры. Клиенты паникуют из-за «замедлений», а при проверке выясняется, что причина — в человеческих ошибках или неочевидных нюансах работы с системой.

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

Некорректный подход к тестированию

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

Многопоточное тестирование имитирует реальную рабочую нагрузку, когда система обрабатывает множество документов параллельно. Этот подход незаменим для оценки общей производительности и проверки соблюдения SLA, но имеет существенное ограничение. В частности, он не подходит для точной диагностики проблемы. Если в таком тесте обнаруживается замедление, невозможно сразу определить: виноваты ли новые алгоритмы распознавания, изменения в логике бизнес-правил или просто возросшая нагрузка на дисковую подсистему.

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

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

Измерение времени распознавания отдельно от других этапов позволяет объективно сравнивать настройки гибких описаний или версии технологий. Это особенно важно при внедрении новых нейросетей или изменении логики обработки. Только так можно понять, где именно возникло замедление и как его исправить.

Замеры на виртуалках

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

Физическая машина обеспечивает стабильность и воспроизводимость результатов. Если тестирование проводится на одном и том же оборудовании, можно быть уверенным, что изменения в производительности связаны именно с обновлениями продукта, а не с внешними факторами. Это особенно важно при сравнении разных версий или настройке гибких описаний.

Запуск в продакшен на быстрых машинах, а тестирование на медленных

Иногда заказчики делегируют тестирование техническим специалистам, которые могут использовать неподходящее оборудование. Например, продукт запускают на машине с 128 ГБ оперативной памяти, хотя для однопоточных замеров достаточно 1-1,5 ГБ. Избыточные ресурсы не ускоряют обработку, но создают ложное впечатление «мощности». При этом важно понимать, что для распознавания критична не столько мощность, сколько стабильность окружения.

Характеристики железа также играют ключевую роль. Например, SSD значительно быстрее HDD, особенно при работе с изображениями. Оперативная память DDR4 предпочтительнее DDR3, а процессор должен иметь высокую однопоточную производительность, так как основной поток обработки не распараллеливается. Если эти параметры не учитывать, замеры будут несопоставимыми.

В таблице ниже собрали рекомендации, которыми руководствуемся сами при выборе железа для тестирования.

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

Расчет только среднего времени распознавания

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

Среднее время — это сумма всех значений, деленная на их количество. Оно полезно для расчета SLA, но может сильно искажаться из-за выбросов. Например, если 4 документа обработались за 3-6 секунд, а один — за 100 секунд, среднее время составит 23,6 секунды, что не отражает реальную картину. Медиана в этом случае покажет 5 секунд — что гораздо ближе к типичной производительности.

Выбросы — это документы, которые не распознались или обрабатывались слишком долго. Чтобы понять, насколько они критичны, нужно запускать тесты на больших выборках. Например, если из 50 документов 5 не распознались, стоит проверить 500 документов. Если процент выбросов будет низким (1-2%), их можно игнорировать при анализе медианного времени.

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

Боевые тесты продукта на паре документов

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

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

Форматы документов тоже имеют значение. PDF с текстовым слоем обрабатывается быстрее, чем JPEG или TIFF, так как этап OCR для него можно пропустить. Если не учитывать этот фактор, замеры будут несопоставимыми. Поэтому важно заранее определить  — какие типы документов будут использоваться, и включать их в тестовую выборку.

А какие грабли при тестировании скорости распознавания документов попадались вам? Делитесь в комментариях!