Часть первая.
Доброго времени суток.
Для тех кому лень читать первую часть. Был написан API на python для распознавания рабочих документов, так как платные сервисы слишком сильно платные. Tesseract был выбран основным OCR (программа для распознавания символов) так как он ещё жив, дорабатывается и даже работает. Идея алгоритма такова. OpenCV находит все возможные прямоугольники. Эти прямоугольники обрабатываю, группирую, формирую из них таблицы. Последовательно перебираю ячейки таблиц, а так как знаю координаты конкретной ячейки, вырезаю из начального изображения кусок и распознаю его с помощью OCR. После того как работа с таблицами окончена, формирую в блоки всё что осталось вовне, распознаю с помощью OCR. Собираю всё воедино в граф, отсылаю в формате JSON.
В итоге на одностраничный документ pdf ТОРГ-12 (см. часть 1) тратилось ~40 секунд, что слишком долго. Тупо добавлять железа - не вариант, так как ресурсы достаточно ограничены. Для улучшения показателя было 3 идеи:
Распараллелить процесс распознавания
Использовать другую библиотеку, которая потенциально быстрее
Поменять ОС, где API развернут
А теперь по порядку.
Распараллелить процесс распознавания
Это самое скучная часть. Чисто технически делается несложно, проблема в определении в какой момент запускать новый поток. Чисто эмпирически вывел, что для распознавания именно листов, не более 5 одновременных потоков. Каждый 6й лист формирует новый. В рамках 1 листа, каждое 40 распознавание формирует новый поток. Их не более 5. Очевидно, на один документ не более 25 потоков одновременно. Если увеличить ограничение, то время обработки документа уменьшается, но когда даже 2-3 документа одновременно распознаётся, то ресурсы быстро забиваются и среднее время увеличивается. Возможно есть более оптимальные настройки, но я и этим доволен. Улучшение по времени для малостраничных документов особо не видно, а вот для документов с десятками страниц, в 2-3 раза.
Использовать другую библиотеку, которая потенциально быстрее
Тут интереснее. Установлен tesseract 5, tessdata_fast. Если просто, то tessdata это те шаблоны, по которым tesseract определяет что за символ, что буква. Есть tessdata, которая даёт замечательный результат, но время тратит в разы больше. Tessdata_fast - золотая середина время/качество.
Изначально использовалась библиотека pytesseract, которая запускает отдельный процесс tesseract для распознавания конкретного куска картинки. Понятное дело отвратительная скорость, но приемлемое качество.
Нашёл библиотеку tesserocr, которая использует API методы tesseracta, что в теории должно давать увеличение скорости работы.
Небольшой оффтоп, что бы было понятно чего мне это всё стоило. Я пользователь windows с 25 летним стажем. Застал ещё 95. После выхода windows 7 уже стало привычкой: скачал дистрибутив, нажал 3 кнопки, программа установилась, программа работает. Были проблемы с совместимостью, но это эксцессы. Здесь же пытаюсь установить tesserocr, и начали сыпаться ошибки. Часы гугления, изучения Cygwin, сборка под ним лептоники, которая ничем не помогла и только привела к новым ошибкам. Изучение miniconda, которая оказалось удобной, но когда на тебя всё это сыпется в течении короткого времени, приводит к яростному кипению чайничка, не говоря что обычная работа никуда не делась. Забегая вперёд, такие же ощущения при переходе на linux mint. Каждый шажок в сторону даёт ошибку, а следом решение которой приводит к новой ошибке. Да, проблемы решаются достаточно быстро, но их количество превысило все пределы, не говоря о том что инфы по решениям много, но часто её настолько много и она написана таким языком, что ради внятного объяснения пришлось подтянуть английский и сильно улучшить навыки поиска. В общем, на всё изучение, отработки и прочее ушло несколько недель и сотни миллионов нервов. Только укрепилось мнение, что с точки зрения лояльности, интуитивности и юзабилити linux сильно уступает windows, но с другой стороны, если нужно просто сёрфить и набивать документы в офисе, то mint хорошая штука, даже захотел жене установить, а то 10 тормозит на ноуте достаточно сильно =)
Так вот, после установки tesserocr выяснилось, что время работы уменьшилось ~2 раза. Казалось бы победа, ан нет. Качество распознавания было отвратительным. Оказалось, что tesserocr работает с tesseract 4.1, поменять я это не смог. Попробовал tessdata_fast сменить на tessdata_best. Время вышло больше чем у pytesseract, но качество явно не дотягивало. К сожалению, этот метод не оправдал ожидания.
Следующая библиотека - pyocr. Должна также дёргать API методы tesseracta. Вот тут всё сильно не однозначно. Дёргает именно tesseract 5, после первых тестов время распознавания улучшилось в ~1.5 раза, качество такое же, нагрузка на ресурсы меньше. Казалось бы победа, ан нет. Это оказалась какая-то библиотека Шрёдингера. Первые тесты качество не уступает, потом абсолютно некорректно, вплоть до яростно-удивлённого "чёёёёёё". Пошёл смотреть в отладчик, там всё правильно. Вне отладчика - раз через раз. Так как через pytesseract таких проблем не было, то подозрения на саму библиотеку, хотя возможно это косяк именно tesseract 5, так как есть только альфа версия. В любом варианте, использовать данную библиотеку не получится. И да, на linux к тому моменту я уже перешёл, поэтому должна была работать стабильно.
В итоге, как я написал первый раз, так и получилось наиболее оптимально. Так как наибольшее время занимает именно работа OCR, то оптимизация остального кода не даст кардинального улучшения. Тут либо менять сам принцип работы, что нереально, либо ждать пока появится стабильный инструмент. На текущий момент, пришёл к выводу что чисто программно значительно улучшить показатели не получиться.
Поменять ОС, где API развернут
Сразу предупреждаю, что в детальном разборе железа я не силён, но хотя бы системный блок не называю процессором. Буду приводить характеристики как это указано в специально отведённых местах без залезания в недра и использования стороннего ПО. Все временные показатели будут собраны в таблицу внизу.
Изначально для моих тестов развернули отдельную ВМ (виртуальную машину) с windows сервер с 5 гб ОЗУ, Intel(R) Xeon(R) Silver 4116 CPU 2.1 Ghz 2.1 Ghz. Процессоров было много, конкретно сколько не скажу, так как ВМ уже удалена, но точно больше 10.
Нужен был linux. Так как из командной строки работать я пока не мог, то параллельно сделали ВМ последней ubuntu с gnome 3, с почти такими же характеристиками (6 гб ОЗУ, процессоров немного меньше). Подключался по rdp. Трудно описать благими словами эмоции от работы на жутко тормозной системе с откликом мыши 5-10 секунд и крайне неудобным интерфейсом. Через пол часа работы попросил снести и установить mint с xfce. Вот тут уже дело пошло. Протестировал.
От умных людей услышал, что нужен чистый linux. Так как на работе трогать сисадминов с просьбой "сделайте ещё одну мафинку" не хотелось, то решил завести в облаке свою ВМ. Пошёл в Google. За 25$ в месяц выбрал подходящую конфигурацию, 2 процессора, 6 гб ОЗУ. Всё установил, собрал, запускаю скрипт, и нет API по внешнему IP. У меня сделано на Flask, погуглил, сделал рекомендации, не получилось. Пошёл на Яндекс. Сделал ВМ: 2 процессора Intel Xeon Gold 6230 2.1 Ghz, гарантированная доля vCPU 100%, 6 гб ОЗУ, 2100р в месяц. И вот тут всё завелось. Сделал баш скрипт, сделал демона, который запускает питоновский скрипт. Результаты отличные.
Теперь самое важное, а что конкретно проверял. Было 3 файла pdf. Тестовый ТОРГ-12 из первой части. Реальный рабочий документ на 38 страниц, который я не могу показать, но каждый лист по структуре похож на счет на оплату: шапка, небольшая таблица. Ещё реальный рабочий документ на 11 страниц, 1 страница - шапка, 10 - страниц непрерывной таблицы, ~400 ячеек на 1 лист.
Время в секундах. На каждой конфигурации запускал по несколько раз. Все сравнения будут проходить по формуле k = 100*(1-y/x), где х время в Windows.
В итоге, пришёл к результатам, которые устраивают. Естественно, это не ABBYY Cloud, ни по качеству, ни по скорости, но это бесплатно, работает и сделано на коленке чайником из костылей и кода, а значит можно улучшать и дорабатывать алгоритм.
