Быстрый OCR на основе Paddle

[badsynt]

Есть люди, которых закон обязывает раскрывать некоторые чувствительные данные, и они, скрепя сердце, вынуждены выкладывать толстенные отчеты в публичный доступ. Но они не хотят, чтобы эти данные кем-то анализировались, попадали в базы данных и т.п., по крайней мере бесплатно. (За деньги еще куда ни шло). Для достижения этой цели есть простые и дешевые средства, доступные почти всем. А противодействия этому со стороны госорганов пока совсем нет... Называется data poisoning. И OCR к этому особенно чувствителен. Какие-то меры принимаете?

[Alexandrova007]

Спасибо за крутой вопрос - он намного фундаментальнее и шире темы статьи, постараюсь всё же прокомментировать.

При подаче на вход в OCR изображения (JPEG, PNG, BMP, TIFF), оно представляется как матрица пикселей, в которой нет ничего тайного. Поэтому OCR видит картинку примерно так же, как и человек, и детектирует только те символы, на которых обучалась модель. Управляющие символы (например, tab, конец строки) не могут быть прочитаны, так как у них нет графического представления. Нелегитимные техники вроде ‘белым по белому’ тоже потеряют контраст и станут невидимы как для глаза, так и для OCR.

При оцифровке возможна подмена букв визуально схожими символами (как в слове P@ssw0rd). Тогда можно в исходном файле словаря в ручном режиме заменить спорные символы на более приоритетные. Например, заменить греческие символы на латиницу.

А вот риски, связанные с data poisoning, могут возникнуть на этапе конвертации PDF в картинку. Если в pdf есть скрытые слои, они могут проявиться: в исходном pdf не видны, а на изображении уже есть. Тогда OCR читает их как обычную картинку. Если в результате схлопывания слоёв после pdf на картинке возникло много шума, можно попытаться очистить его, повысить контраст... Но серебряной пули словно нет.

В данном алгоритме никаких мер защиты не предусмотрено - просто читаем текст с картинки. Но есть о чём задуматься, спасибо!

[badsynt]

У термина "data poisoning" много значений и Вы, скорее всего, меня не правильно поняли.

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

Что-то вроде этого:

https://github.com/andylow-wl/Adversarial

У меня был неприятный опыт с GlmOCR. Это маленькая нейросетка, gguf которой сделан в недрах GGML, поэтому она очень быстро работает с llama.cpp на всем. Нужно было распознать таблицу из 50 строк и 5 колонок с числами, которые все используются в расчете. (Процедура получения таблицы непосредственно в XML стоит где-то 150 тыс. руб в год, платить столько за один раз не хотелось, а вручную делать - лень). Пайплайн был такой: подаем на вход картинку jpeg, результат конвертируем в csv другой нейросеткой( одна из gemma 4). Оказалось, что одно из 250 чисел распознается неправильно. Но как другое число. Стабильно. Исходное число выглядит так, что кажется и ResNet бы справилась. В результате весь расчет неправильный. Свежеиспеченный Qwen (часа три прошло с момента появления на HuggingFace) распознал и сделал csv за один проход совершенно правильно, но медленно. Допускаю, что все это результат паранойи. А если нет? Тут я даже вспомнил про старый добрый Abby FineReader, который не умел складно врать...

[Mavito]

Спасибо за публикацию. Несколько вопросов:

• Каков оптимальный DPI изображений для этой модели (144/200/300…)?

• Означает ли “Для v5 это 960 пикселей”, что размер наибольшей стороны изображения во время “Шаг 3. Детекция текстовых блоков” не должен превышать 960px? Т.е. эта модель не сможет распознать текстовые блоки со страниц pdf журналов, например NYT или FT т.к. при сохранении читаемости стороны таких изображений более 2 (или 4) тыс. пикселей.

• “модель распознавания ожидает фиксированную высоту H” - т.е. блоки с вырезанным текстом надо всегда преобразовывать в изображение с высотой h = 48 (из заметок в конце публикации), а если блок будет содержать несколько строк друг под другом (когда текст на исходном изображении расположен в колонках)?

• Подойдет ли для “Масштабирование изображения с добавлением паддинга для кратности сторон 32” такая функция smart_resize с factor=32?

• Будет ли на обычном настольном компьютере/ноутбуке (6-8 ядер по ~4 ГГц и 8-16 Гб RAM) CPU вариант укладываться в 5 секунд на изображение?