Promptra Team for Promptra

Posted on Jul 19

Обновление Acrobat вызвало жалобы на OCR: почему enterprise-функции надо проверять на реальных документах. Adobe Acrobat OCR…

#ai #llm #api #chatgpt

10 июля 2026 года в сообществе r/Acrobat появился пост с прямым заголовком: последнее обновление "полностью сломало" распознавание текста в Acrobat. Автор описывает резкое ухудшение OCR после апдейта - того самого модуля, который у многих в документообороте стоит в начале конвейера: скан пришёл, OCR прогнал, дальше поиск, индексация, извлечение полей. Если первый шаг деградирует, дальше едет мусор, и заметить это можно уже на отчётности.

Разберём это без паники и без обвинений. Одна жалоба - это сигнал, а не диагноз. Но сигнал полезный: он показывает, где у большинства команд нет процесса. Обновления клиентского софта прилетают тихо, enterprise-функции вроде OCR никто не проверяет на своих же документах, а когда качество падает, нет ни зафиксированного номера сборки, ни воспроизводимого теста, ни плана отката. Эта статья - про то, как закрыть все три дыры.

Если ты уже автоматизируешь обработку документов и OCR у тебя лишь одно звено в цепочке, держи под рукой запасной способ прогнать распознанный текст через модель без VPN - к этому вернёмся ниже, когда дойдём до кросс-проверки.

Что именно произошло 10 июля

Факты по источникам такие. Есть независимое свидетельство - пост в r/Acrobat от 10 июля 2026 года, где пользователь заявляет о заметном падении качества OCR после обновления. Есть первичный источник - официальная страница Adobe "What's new in Acrobat desktop", то есть журнал изменений, по которому можно сопоставить жалобу с текущей веткой Acrobat.

Чего в источниках нет - и что я не буду додумывать. Нет подтверждения, что дефект массовый. Нет разбора корневой причины от Adobe. Нет конкретного списка символов, языков или типов документов, на которых распознавание просело. Adobe как вендор описывает, что нового в сборке, но не подтверждает регресс OCR как признанный дефект. Поэтому корректная формулировка простая: сообщество сообщает об ухудшении, официальный журнал даёт способ привязать это к версии. Всё остальное - твоя задача проверить у себя.

Именно из-за этого зазора между "кто-то в интернете пожаловался" и "у нас на проде сломалось" и нужен процесс. Он превращает чужой анекдот в твой воспроизводимый факт: либо ты повторяешь деградацию на своих сканах и получаешь основание откатиться и написать в поддержку, либо не повторяешь - и спокойно катишь обновление дальше.

Почему одна жалоба - это ещё не дефект

Соблазн после такого поста - сразу запретить обновления во всей организации. Это гиперреакция. Отдельная жалоба может быть чем угодно: повреждённый профиль, конфликт со шрифтами, конкретный кривой скан, локальная сборка, региональные языковые пакеты. Пост в r/Acrobat ценен не как приговор, а как гипотеза, которую можно проверить за час.

Чтобы жалоба стала пригодной к работе, ей не хватает трёх вещей, и ровно их ты и добираешь у себя: воспроизводимого набора документов, точного номера сборки и метрики, по которой "стало хуже" перестаёт быть ощущением и становится числом. Без набора ты споришь мнениями. Без сборки ты не понимаешь, что откатывать. Без метрики ты не докажешь ни себе, ни вендору, что регресс есть.

Дальше - три практических блока ровно про это: набор, сборка, откат. Начнём с набора, потому что без него остальное бессмысленно.

Как собрать воспроизводимый тестовый набор для OCR

Тестовый набор - это не "пара пдфок с рабочего стола". Это зафиксированная, версионированная папка документов, которая покрывает твои реальные кейсы. Собери 15-40 файлов и держи их отдельно от рабочих данных.

Что положить внутрь:

чистый машинный скан 300 dpi - базовая линия, тут OCR обязан быть идеальным;
шумный скан с телефона, с перекосом и тенью - реальность бухгалтерии;
документ с таблицами и мелким шрифтом - счета, спецификации;
смешанный русско-английский текст - договоры с латинскими терминами;
рукописные пометки и печати поверх текста;
многостраничный PDF на 20+ страниц - проверка стабильности;
скан с колонками и сложной вёрсткой.

Рядом с каждым файлом храни эталон - "ground truth", то есть заранее вычитанный правильный текст. Не обязательно весь документ; достаточно контрольных фрагментов: пять-десять строк, номера, суммы, реквизиты. По ним потом считается точность.

Метрика для OCR - это не "на глаз лучше или хуже". Бери CER (Character Error Rate) и WER (Word Error Rate): доля неверных символов и слов относительно эталона. Считать можно любой библиотекой расстояний Левенштейна. Правило простое: до обновления прогнал набор, записал числа; после обновления прогнал тот же набор, сравнил. Если CER на многих файлах вырос - это регресс, а не настроение.

Вот компактный каркас harness на Python. Он не привязан к Acrobat: он сравнивает распознанный текст с эталоном и выдаёт CER по каждому файлу.

import Levenshtein
from pathlib import Path

def cer(pred: str, truth: str) -> float:
    truth = truth.strip()
    if not truth:
        return 0.0
    return Levenshtein.distance(pred, truth) / len(truth)

def run(pred_dir: str, truth_dir: str):
    rows = []
    for t in sorted(Path(truth_dir).glob("*.txt")):
        p = Path(pred_dir) / t.name
        if not p.exists():
            print(f"MISS {t.name}")
            continue
        score = cer(p.read_text("utf-8"), t.read_text("utf-8"))
        rows.append((t.name, round(score, 4)))
    rows.sort(key=lambda r: -r[1])
    for name, score in rows:
        flag = "  <-- REGRESS" if score > 0.03 else ""
        print(f"{score:.4f}  {name}{flag}")

# run("out_after_update", "ground_truth")

Порог 0.03 здесь условный - подбери свой по базовой линии на чистых сканах. Смысл в том, чтобы одной командой получить отсортированный список "где стало плохо", а не листать документы глазами.

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

Как зафиксировать номер сборки и сопоставить с журналом Adobe

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

Где смотреть версию в Acrobat: меню "Справка" -> "О программе Adobe Acrobat" покажет полную строку версии и номер сборки. Запиши её целиком, а не "последняя". Дальше открывай официальный журнал Adobe "What's new in Acrobat desktop" и находи запись, соответствующую твоей ветке. Это первичный источник: он говорит, что вендор менял в сборке. Сопоставление "у меня сборка X, в журнале для X заявлено то-то" - и есть мост между жалобой и фактом.

Практический протокол фиксации выглядит так:

записал строку версии "до" и "после" дословно;
для каждой прогнал тестовый набор, сохранил CER-таблицы рядом с версией;
отметил в журнале Adobe даты и записи, попадающие между двумя версиями;
сложил всё в один тикет: версии, различие CER по файлам, ссылки на записи журнала, ссылку на пост r/Acrobat как внешний контекст.

Важная оговорка про источники. Журнал Adobe описывает изменения с позиции вендора; он не подтверждает и не опровергает регресс OCR сам по себе. Пост сообщества - независимое свидетельство, но одиночное. Твоя CER-таблица - твоё собственное воспроизводимое доказательство. Держи эти три уровня раздельно и в тикете, и в голове: claim вендора, реакция сообщества, твоя проверка. Смешаешь - получишь красивую, но недоказуемую историю.

Такой тикет полезен вдвойне. Внутри он оправдывает откат перед менеджментом ("вот числа"). Наружу, в поддержку Adobe или в тот же тред, он превращает "у меня всё сломалось" в воспроизводимый баг-репорт с версией и данными - на такое реагируют быстрее.

Как откатить обновление и заморозить версию

Допустим, регресс подтвердился на твоём наборе. Дальше две задачи: вернуться на рабочую сборку и не дать новой прилететь снова, пока проблему не починят.

Adobe для корпоративных развёртываний даёт инструменты управления обновлениями. Ключевая идея - не давать клиенту обновляться самому, а централизованно управлять тем, какая сборка стоит. Практический смысл шагов такой:

отключить автоматические обновления Acrobat на управляемых машинах, чтобы фиксация версии не сбрасывалась;
держать под рукой установщик предыдущей рабочей сборки (тот самый "золотой" билд, который прошёл твой набор);
разворачивать откат через привычный тебе механизм: групповые политики, MDM, пакетный менеджер или скрипт развёртывания;
после отката повторно прогнать тестовый набор и убедиться, что CER вернулся к базовой линии.

Отдельно про соблазн "заморозить навсегда". Замороженная версия копит собственные риски: незакрытые уязвимости, несовместимость с новыми форматами, отставание от остальной инфраструктуры. Заморозка - это пауза, а не решение. Правильный цикл: заморозил проблемную ветку, поставил на мониторинг журнал Adobe, дождался записи о фиксе, прогнал новый билд через набор, разморозил. Без последнего шага ты просто меняешь один долг на другой.

И ещё честная оговорка про масштаб. Всё описанное - это управление клиентским десктопным приложением. Если у тебя OCR встроен в серверный конвейер через сторонние движки, эти шаги не заменят тестирования самого конвейера; они лишь снимают риск с той части, где стоит Acrobat.

Стратегии контроля обновлений: короткая таблица решений

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

Сценарий	Контроль обновлений	Тестовый набор OCR	План отката	Кому подходит
1-3 рабочих места	Ручная проверка версии перед апдейтом	Мини-набор 10 файлов	Установщик прошлой сборки на диске	Небольшая студия, ИП
Отдел 10-50 машин	Отключить авто-апдейт, катить волнами	Набор 20-40 файлов + CER	Централизованный откат по группе	Бухгалтерия, юротдел
Enterprise 100+	Пилотная группа -> кольца раската	Полный набор + метрики в тикете	GPO/MDM, золотой билд	Крупный документооборот
Серверный OCR-конвейер	Версионирование движка отдельно	Набор + регресс в CI	Rollback образа/пакета	Продуктовые команды

Общий принцип во всех строках один: обновление enterprise-функции не катится "в прод" раньше, чем проходит через реальные документы. Разница только в масштабе оснастки.

Где сюда встраивается кросс-проверка распознанного текста

OCR почти никогда не финальный шаг. После него текст обычно куда-то едет: нормализация, извлечение полей, классификация, поиск. И вот тут удобно иметь второй, независимый от Acrobat взгляд на результат - чтобы падение качества ловилось не только твоим CER-набором, но и на этапе разбора.

Практический приём: распознанный фрагмент отдаёшь языковой модели и просишь вернуть структурированные поля (номер, дата, сумма, контрагент) плюс флаг уверенности. Если после обновления Acrobat модель вдруг начинает массово спотыкаться о битые символы и возвращать "не смогла разобрать" там, где раньше всё парсилось, это ещё один сигнал регресса - на живом трафике, а не только на тестовом наборе.

Чтобы такой слой не превращался в квест с зарубежными картами и VPN, через provod.ai можно дергать Claude, GPT, Gemini, DeepSeek и Qwen по одному API с оплатой в рублях. По заявлению сервиса, API совместим с SDK OpenAI и Anthropic: меняешь ключ и base_url - код остаётся прежним. Для российской команды это снимает главную боль постобработки OCR: не нужно ни иностранной карты, ни обхода блокировок.

Минимальный пример постобработки одного OCR-фрагмента:

from openai import OpenAI

client = OpenAI(
    api_key="ВАШ_КЛЮЧ",
    base_url="https://api.provod.ai/v1",
)

ocr_text = "ООО Ромашка ИНН 7701234567 сумма 154 200,00"

resp = client.chat.completions.create(
    model="claude-opus-4-8",
    messages=[
        {"role": "system", "content": "Верни JSON: контрагент, инн, сумма. Если текст битый - поле confidence=low."},
        {"role": "user", "content": ocr_text},
    ],
)
print(resp.choices[0].message.content)

Честная граница: это не замена самому OCR и не признак дефекта Acrobat. Модель не распознаёт скан вместо Acrobat - она разбирает уже распознанный текст. И массовые "confidence=low" - это повод посмотреть в CER-набор, а не готовое доказательство. Кросс-проверка усиливает твой процесс, но не заменяет ни воспроизводимый набор, ни фиксацию сборки.

Что это не решает

Честно про границы, чтобы не создать ложного ощущения контроля.

Тестовый набор не гарантирует, что регресс не проявится на документе, которого в наборе нет. Он снижает риск, но покрытие всегда конечно. Расширяй набор каждый раз, когда живой документ ломает распознавание.

Откат не чинит первопричину. Ты возвращаешься на старую сборку и живёшь с её собственными ограничениями и уязвимостями, пока Adobe не выпустит фикс. Заморозка версии - это управляемый долг, а не победа.

Ни набор, ни откат, ни кросс-проверка моделью не заменяют официального ответа вендора. Только Adobe может подтвердить дефект в своей сборке и починить движок распознавания. Твой процесс даёт основание требовать этого предметно, с версией и числами, но не заменяет саму починку.

Кросс-проверка через языковую модель не распознаёт документы вместо OCR и не является заменой Acrobat. Это слой поверх уже полученного текста. И provod.ai здесь - способ дотянуться до моделей из России без VPN и иностранных карт, а не автоматизация документооборота, не on-prem решение и не замена внедрению. Интеграцию, серверный конвейер и регламенты всё равно строишь ты.

И последнее: одиночная жалоба из r/Acrobat остаётся одиночной, пока ты не воспроизвёл её у себя. Не превращай чужой пост в корпоративную панику. Превращай его в прогон набора.

FAQ

Это точно баг Adobe?
Источники этого не утверждают. Есть жалоба сообщества от 10 июля 2026 и официальный журнал версий Adobe. Подтвердить регресс можешь только ты - на своём наборе и своей сборке. Дефект как таковой признаёт лишь вендор.

Какой номер сборки затронут?
В источниках конкретной сборки нет, поэтому её здесь и не называю. Свою версию смотри в "Справка" -> "О программе" и сопоставляй с журналом Adobe.

Сколько документов класть в набор?
Для отдела достаточно 20-40 файлов, покрывающих реальные типы: чистые и шумные сканы, таблицы, смешанный RU/EN, печати, многостраничники. Важнее разнообразие, чем количество.

Чем мерить деградацию?
CER и WER относительно эталонного текста. Это превращает "стало хуже" в число, которое можно защитить перед менеджментом и приложить к баг-репорту.

Короткий чек-лист

Собрал воспроизводимый набор с эталонами. Настроил harness, считающий CER. Зафиксировал версию "до" и "после" через "О программе". Сопоставил с журналом Adobe. При подтверждённом регрессе - откатился на золотой билд, отключил авто-апдейт, поставил журнал вендора на мониторинг. Добавил кросс-проверку распознанного текста моделью как второй сигнал. И держишь в голове, что это управляемый процесс, а не разовая реакция на пост в интернете.

Именно так июльская история 2026 года из "у кого-то сломался OCR" превращается в твой рабочий контур: обновление enterprise-функции не доезжает до сотен машин раньше, чем проходит через реальные документы.

Собери тестовый набор сегодня, а постобработку распознанного текста подключи к моделям через provod.ai - один ключ, base_url, оплата картой или по счёту без VPN.

Источники

Adobe (первичный, журнал версий): helpx.adobe.com/acrobat/desktop/whats-new/whats-new-acrobat-desktop.html
Reddit r/Acrobat (независимое свидетельство, 10 июля 2026): пост о резком ухудшении OCR после обновления.

provod.ai — Russian LLM API aggregator. One OpenAI-compatible endpoint to all flagship models: OpenAI (GPT-5.6, GPT-5.5), Anthropic (Claude Opus 4.8, Sonnet 4.6), Google (Gemini 3.1 Pro, 3.5 Flash), DeepSeek V4 Pro, Qwen 3.6 Plus. Provider prices at the CBR rate, no token markup. Pay in rubles to a Russian legal entity with full closing documents.

Try: provod.ai · model catalog · docs