DeepSeek-OCR извлекает текст из сканов и страниц PDF, восстанавливает структуру документа в Markdown, размечает заголовки, таблицы, формулы и изображения, а также отдельно разбирает диаграммы, геометрические схемы и другие встроенные иллюстрации. Пользователь управляет результатом коротким запросом, выбирает режим разрешения и получает обычный текст, координатную разметку, вырезанные изображения или PDF с подсвеченными блоками.

Основной рабочий процесс строится вокруг файла config.py и трёх точек запуска: один скрипт принимает отдельное изображение, второй последовательно переводит страницы PDF в изображения и собирает общий Markdown, а третий рассчитан на контрольные наборы. Вместо панели с кнопками здесь используются параметры пути, режима разрешения, запроса, числа одновременных задач и каталога вывода; поэтому перед первым запуском важно не только загрузить модель, но и явно проверить каждое значение конфигурации.

После обработки в папке результата появляются текстовые файлы .mmd, вариант с координатной разметкой, извлечённые иллюстрации и, для PDF, копия страниц с цветными рамками распознанных областей. Такой набор удобен не только для чтения: Markdown можно передать в поиск или базу знаний, координаты использовать для проверки происхождения фрагментов, а сохранённые рисунки направить на отдельный этап анализа.

Как устроен рабочий процесс

DeepSeek-OCR получает изображение страницы и формирует ответ в соответствии с текстовой инструкцией. Для полного разбора документа применяется запрос на преобразование в Markdown с включённой привязкой к областям страницы. Модель выделяет смысловые блоки, генерирует текст и вставляет служебные конструкции, по которым скрипт восстанавливает расположение заголовков, абзацев, таблиц и рисунков. Если задача сводится к буквальной транскрипции, запрос меняют на свободное OCR без требования воспроизводить макет.

Практическая последовательность начинается с выбора файла, проверки его ориентации и качества, затем указывается каталог вывода и режим изображения. После запуска движок подготавливает визуальные токены, декодер генерирует текст, а постобработка разбирает координаты и сохраняет дополнительные файлы. Пользователь оценивает не только читаемость Markdown, но и соответствие рамок исходным областям: это помогает быстро обнаружить пропущенную колонку, перепутанный порядок блоков или неправильно объединённую таблицу.

Для одиночных страниц удобнее скрипт изображения: он минимизирует подготовку и подходит для подбора запроса. Для многостраничных файлов лучше сценарий PDF, потому что он сам рендерит страницы, распределяет задания между рабочими потоками и объединяет результаты в порядке следования. Контрольный сценарий нужен, когда необходимо прогнать каталог с эталонными файлами и сравнить качество между режимами разрешения или настройками генерации.

Точки управления вместо графического окна

Рабочая поверхность проекта состоит из конфигурации и журналов выполнения. В config.py задаются путь к модели, путь к входным данным, каталог результата, текст запроса, режим разрешения, число параллельных последовательностей и правила обработки повторов. Это делает запуск воспроизводимым: конфигурацию можно сохранить рядом с проектом и повторить обработку той же коллекции без ручного восстановления параметров.

Отсутствие формы выбора файла означает, что ошибка в пути обнаруживается только при старте скрипта. Полезно заранее проверять существование входного файла, права на запись в каталог результата и свободное место для промежуточных изображений. Для PDF объём временных данных может заметно превышать размер исходника, поскольку каждая страница рендерится в растровый файл, а распознанные иллюстрации сохраняются отдельно.

Журнал vLLM показывает загрузку весов, резервирование памяти GPU, создание очереди и скорость генерации. При работе через Transformers диагностическая информация короче, зато проще связать ошибку с конкретной строкой загрузки модели или изображения. В обоих случаях полезно сохранять консольный вывод вместе с результатом: по нему можно отличить сбой зависимости от ошибки чтения PDF или переполнения видеопамяти.

Архитектура распознавания и её практический смысл

Визуальная часть преобразует страницу в компактную последовательность токенов, после чего языковой декодер восстанавливает текст и структуру. Для пользователя важен не сам внутренний граф, а следствие: одна и та же модель умеет переключаться между буквальным OCR, Markdown с макетом, разбором отдельной фигуры и поиском объекта по текстовой инструкции. Качество зависит от того, насколько режим разрешения сохраняет мелкие символы и одновременно удерживает страницу в допустимом числе визуальных токенов.

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

Подготовка среды без конфликтов зависимостей

Команды проекта проверялись в сочетании Python 3.12.9, CUDA 11.8, PyTorch 2.6.0, torchvision 0.21.0, torchaudio 2.6.0, vLLM 0.8.5 и flash-attn 2.7.3. Эти номера важны как совместимый ориентир, потому что vLLM, PyTorch и flash-attn содержат бинарные расширения и должны быть собраны для согласованных версий CUDA. Установка произвольных свежих пакетов поверх существующего окружения часто заканчивается ошибкой импорта или отсутствующим символом в библиотеке.

Надёжный способ подготовки — создать отдельное виртуальное окружение, установить PyTorch для выбранной CUDA, затем vLLM из рекомендованного колеса, зависимости проекта и только после этого flash-attn. Параметр установки flash-attn без изоляции сборки позволяет использовать уже установленный PyTorch. Перед загрузкой весов стоит выполнить короткую проверку: Python должен видеть CUDA, имя GPU и доступный объём памяти, а импорт vLLM и flash-attn не должен выдавать исключений.

Если компьютер использует другую ветку драйвера, сначала проверяют, поддерживает ли драйвер требуемую версию CUDA. Драйвер может быть новее среды выполнения, но не наоборот. На системах без NVIDIA код загрузки с cuda не выполнится без переработки, а официальные сценарии не предлагают готового CPU-профиля. Попытка заменить устройство на процессор формально может пройти отдельные этапы, но объём весов и операции внимания делают такой путь непрактичным для рабочего потока.

Порядок установки

1. Создайте чистое окружение Python и активируйте его перед каждой командой.
2. Установите PyTorch, torchvision и torchaudio из одного канала сборок для нужной CUDA.
3. Поставьте vLLM совместимым колесом, затем зависимости из файла проекта.
4. Соберите flash-attn после PyTorch и проверьте импорт в коротком тесте.
5. Загрузите модель в отдельный каталог или кэш и только затем запускайте OCR-скрипт.

Такой порядок упрощает восстановление после сбоя. Если flash-attn не собирается, не нужно переустанавливать весь стек: достаточно проверить компилятор, заголовки CUDA и соответствие PyTorch. Если vLLM не видит модельный класс, проблема обычно связана с несовместимым кодом модели или отключённым доверием к пользовательскому коду, а не с самим PDF.

Структура файлов и безопасные пути

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

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

Кириллица в путях обычно обрабатывается Python корректно, но сторонние сборочные инструменты и некоторые контейнерные образы могут иметь другую локаль. Если ошибка появляется только на файлах с национальными символами, сначала повторяют тест в коротком ASCII-пути. Это быстрее, чем менять параметры модели, поскольку распознавание ещё не началось и качество изображения здесь ни при чём.

Выбор режима разрешения

В конфигурации предусмотрены фиксированные режимы Tiny, Small, Base и Large, а также динамический Gundam. Tiny подаёт изображение 512×512 и использует около 64 визуальных токенов; Small — 640×640 и около 100 токенов; Base — 1024×1024 и около 256 токенов; Large — 1280×1280 и около 400 токенов. Динамический режим сочетает базовое представление 1024×1024 с несколькими фрагментами 640×640, сохраняя детали сложных страниц.

Tiny полезен для быстрых черновых проверок на слайдах, квитанциях с крупным шрифтом и простых одноколоночных страницах. Small даёт больше запаса для обычных офисных документов. Base разумно использовать как отправную точку для A4 со стандартным кеглем. Large и динамическая нарезка нужны там, где точность мелких элементов важнее пропускной способности: в формулах, патентах, финансовых таблицах и многоуровневых схемах.

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

Динамическая нарезка

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

Нарезка полезна для газетных полос, широких таблиц, мелкого двуколоночного текста и страниц с несколькими самостоятельными рисунками. Для простого письма она лишь замедляет обработку. Если в результате появляются повторяющиеся абзацы на границах фрагментов, сначала уменьшите число кропов или перейдите на фиксированный Large; изменение температуры не устраняет геометрическое перекрытие входных областей.

Запрос определяет форму результата

Модель не ограничивается единственным режимом OCR: команда в тексте запроса задаёт ожидаемое представление. Запрос на преобразование документа в Markdown заставляет сохранять иерархию и использовать координатные маркеры. Команда OCR изображения выдаёт транскрипцию без обязательной реконструкции сложного макета. Свободное OCR подходит для страниц, где важен текст, но расположение блоков не требуется.

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

Запрос лучше формулировать коротко и использовать проверенные шаблоны. Добавление длинных рассуждений, нескольких противоречивых задач или требований к произвольному формату увеличивает вероятность нестабильной разметки. Если нужен собственный JSON, надёжнее сначала получить Markdown или координатную разметку, затем преобразовать её отдельным валидатором. Так ошибка структуры не смешивается с ошибкой распознавания символов.

Когда выбирать Markdown

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

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

Когда выбирать свободное OCR

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

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

Распознавание отдельного изображения

Сценарий изображения подходит для PNG, JPEG и других форматов, которые открывает используемая библиотека обработки. Перед запуском скрипт получает путь к файлу, создаёт объект запроса и передаёт изображение модели. Результат выводится потоково и сохраняется в выбранный каталог; при включённой разметке дополнительно создаются изображения с рамками и вырезанные области.

Потоковый вывод полезен для диагностики длинных страниц: видно, начал ли декодер генерировать содержательный Markdown или зациклился на одном фрагменте. Однако частичный текст нельзя считать готовым файлом, пока не завершилась постобработка. Прерывание процесса после появления первых строк оставит координатные маркеры незакрытыми и не создаст полный набор картинок.

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

Обработка PDF по страницам

PDF-сценарий использует PyMuPDF: каждая страница открывается и рендерится примерно с разрешением 144 dpi, после чего изображение попадает в ту же очередь, что и обычный графический файл. Такой подход позволяет работать со сканами и цифровыми PDF одинаково, но не извлекает существующий текстовый слой напрямую. Даже если PDF уже содержит текст, модель анализирует визуальное представление страницы.

Рендеринг в 144 dpi — компромисс между детализацией и размером. Для стандартного шрифта этого часто достаточно, а мелкие индексы и тонкие линии могут потребовать отдельного предварительного рендера с большим dpi и запуска как изображений. Простое изменение числа dpi внутри скрипта увеличит ширину и высоту страницы, поэтому одновременно проверяют режим разрешения, число кропов и запас памяти.

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

Выходные файлы PDF-сценария

• основной файл .mmd с объединённым Markdown;
• вариант _det.mmd с координатными конструкциями и ссылками на области;
• каталог images с вырезанными иллюстрациями;
• файл _layouts.pdf с цветными рамками распознанных блоков;
• промежуточные изображения страниц, если их сохранение включено в рабочий сценарий.

Между страницами добавляется разделитель, поэтому последующий импорт может восстановить границы документа. Если целевая система не понимает расширение MMD, файл можно читать как обычный Markdown. Перед массовой загрузкой проверьте, как система обрабатывает встроенные HTML-элементы таблиц и относительные пути к картинкам.

Контроль порядка чтения

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

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

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

Markdown, координаты и разметка областей

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

Координаты относятся к тому изображению, которое реально было подано модели. Если страницу предварительно обрезали, повернули или масштабировали, перенос координат на исходный PDF требует обратного преобразования. Для поворота на 90 градусов меняются оси, а для кропа добавляется смещение. Без этого рамка окажется в другом месте, хотя текст распознан верно.

Вырезанные изображения сохраняются по порядку обнаружения. Для последующей обработки лучше переименовать их с идентификатором документа и страницы, потому что имена вроде 0.jpg повторяются в разных заданиях. Связь с Markdown поддерживают относительные пути; перемещение только текстового файла без каталога картинок сделает вложения недоступными.

Таблицы и финансовые страницы

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

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

Markdown-таблица удобна для простых сеток. Сложные объединённые ячейки могут представляться HTML-тегами, потому что обычный синтаксис Markdown не выражает rowspan и colspan. Перед импортом в табличную систему нужно разобрать HTML и нормализовать объединения. Прямое копирование в CSV потеряет иерархические заголовки.

Проверка числовых данных

1. Сравните заголовки строк и столбцов с исходной страницей.
2. Проверьте знаки минус, проценты, валюты и десятичные разделители.
3. Пересчитайте несколько итогов и долей независимо от модели.
4. Убедитесь, что сноски не попали в последнюю строку таблицы.
5. Сохраните координаты ячеек, которые используются в отчёте или расчёте.

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

Формулы и научная верстка

Запрос на Markdown позволяет передавать математические выражения в LaTeX-подобной форме. Научная страница часто сочетает обычный текст, формулы, номера уравнений и ссылки на них; модель должна отделить выражение от соседней подписи. Мелкие индексы и греческие буквы особенно чувствительны к разрешению, поэтому Base следует считать минимальной отправной точкой, а для плотной страницы проверять Large или динамический режим.

Ошибка в одной скобке или степени меняет смысл формулы сильнее, чем опечатка в prose. После OCR полезно прогнать математические фрагменты через парсер LaTeX и пометить синтаксически некорректные выражения. Успешный рендер не гарантирует математической верности, но быстро выявляет незакрытые скобки, неизвестные команды и сломанные окружения.

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

Разбор диаграмм и встроенных рисунков

Глубокий разбор использует второй запрос для уже найденной фигуры. Сначала страница превращается в Markdown и отдельные картинки, затем каждая картинка подаётся с командой разбора. Для диаграммы модель может извлечь подписи осей, легенду, категории и визуальные зависимости; для обычной фотографии — сформировать описание. Такой двухступенчатый процесс лучше контролируется, чем попытка одновременно получить весь документ и детальный анализ каждого рисунка одним ответом.

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

Для аналитики диаграмм нельзя считать сгенерированные значения измерением. Низкое разрешение, сглаживание линий и наложение меток делают точное считывание ненадёжным. Модель подходит для восстановления подписей и приблизительной структуры; числа, влияющие на решение, следует сверять с таблицей-источником или извлекать специализированным инструментом.

Геометрические схемы

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

Тонкие линии легко исчезают после уменьшения изображения. Для схем следует избегать Tiny и по возможности подавать кроп с высоким контрастом. Если подпись точки касается линии, модель может объединить символ с геометрией; увеличение полей вокруг кропа и более крупный режим часто помогают лучше, чем повышение резкости.

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

Химические структуры

Для химических документов глубокий разбор может преобразовать изображение структуры в строку SMILES и связать её с окружающим текстом. Это особенно полезно в патентах, где соединения встроены между абзацами и имеют номера примеров. Сначала модель находит область структуры, затем отдельный запрос анализирует графическое представление.

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

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

Изображения внутри документа

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

Описание изображения не следует смешивать с буквальной транскрипцией. Если на фотографии есть надписи, запрос на общее описание может пересказать их, но не гарантирует точность каждого символа. Для вывесок и схем сначала применяют OCR, затем отдельно формируют описание объекта. Разделение задач упрощает проверку и снижает риск того, что пересказ будет принят за точную цитату.

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

Многоязычные документы

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

На страницах справа налево особенно важен порядок блоков и направление таблиц. Визуальная рамка может быть правильной, а последовательность слов — переставленной. Проверку проводят носителем языка или специализированными метриками, которые учитывают направление письма. Автоматическая нормализация Unicode должна сохранять диакритические знаки и не менять символы, различающиеся только формой.

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

Общее визуальное понимание и поиск объектов

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

Для поиска объекта запрос должен называть различимый признак: конкретный предмет, человека по одежде или текстовую метку. Расплывчатые инструкции вроде важная часть не задают проверяемого критерия. Полученную рамку нужно наложить на исходное изображение и убедиться, что она охватывает объект, а не соседний контекст.

Общее описание полезно для индексации, но способно добавлять правдоподобные детали. Чем меньше объект или хуже видимость, тем осторожнее должна быть формулировка результата. Для доказательной задачи сохраняют исходный кроп и отделяют распознанные надписи от интерпретации сцены.

Пакетная обработка через vLLM

vLLM предназначен для очереди из многих страниц. Скрипт создаёт асинхронный движок, задаёт максимальную длину контекста 8192, долю видеопамяти и число параллельных последовательностей. Изображения поступают в очередь, а генерация выполняется с температурой 0, что уменьшает случайный разброс между повторными запусками. Ограничитель повторяющихся n-грамм помогает сдерживать зацикливание длинного Markdown.

Параметр MAX_CONCURRENCY управляет количеством задач, которые одновременно ожидают и выполняются, а MAX_NUM_SEQS ограничивает активные последовательности внутри движка. Увеличение очереди не всегда ускоряет работу: если GPU уже заполнен, дополнительные задания лишь расходуют память хоста и усложняют восстановление после сбоя. Настройку начинают с малого значения и повышают, наблюдая за загрузкой GPU и временем на страницу.

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

Управление очередью

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

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

Запуск через Transformers

Сценарий Transformers проще для одной картинки и отладки. Токенизатор и модель загружаются с разрешением пользовательского кода, модель переводится в BF16 на CUDA и использует flash-attention. Метод infer принимает токенизатор, запрос, путь к изображению, каталог вывода, базовый размер и размер изображения. Эти параметры позволяют проверить режим без запуска серверного движка.

Преимущество такого пути — прозрачная точка отказа. Если не загружается токенизатор, проблема в файлах модели; если не открывается изображение, проблема во входе; если ошибка возникает при переводе на CUDA, проверяют память и совместимость. Для массовой очереди этот путь обычно менее эффективен, поскольку повторная загрузка модели или последовательная обработка не используют возможности планировщика vLLM.

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

Память GPU и производительность

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

Если возникает CUDA out of memory, первым шагом уменьшают MAX_NUM_SEQS и число одновременных задач. Затем снижают верхнюю границу кропов или переходят с динамического режима на фиксированный. Уменьшение gpu_memory_utilization оставляет запас и может предотвратить фрагментацию, хотя слишком низкое значение не позволит движку создать нужный кэш.

Для сравнения скорости измеряют отдельно рендеринг PDF, предобработку изображения, ожидание очереди и генерацию. Один общий показатель скрывает причину задержки. Если GPU простаивает, узким местом может быть чтение сетевого диска или рендеринг страниц. Если загрузка GPU высокая, а очередь растёт, оптимизируют режим и параллелизм, а не число потоков CPU.

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

1. Выберите пять обычных и пять самых плотных страниц.
2. Запустите Base без динамической нарезки и измерьте качество и память.
3. Для страниц с пропусками сравните Large и динамический режим.
4. Найдите минимальный режим, сохраняющий критичные символы и структуру.
5. Подберите параллелизм по пиковому расходу, оставив запас для вариативности страниц.

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

Ограничение длины и длинные страницы

Движок задаёт максимальную длину 8192 токенов для совокупного контекста и результата. Плотная страница, длинная таблица или чрезмерно подробный запрос могут приблизиться к пределу. Признак — ответ обрывается на середине таблицы или не закрывает разметку. Увеличивать лимит без проверки памяти нельзя, поскольку KV-кэш растёт вместе с длиной.

Для длинного содержания надёжнее разделить страницу на логические области. Газетный разворот можно разрезать по колонкам, длинную ведомость — по горизонтальным диапазонам с повтором заголовка, а большой плакат — по панелям. После OCR фрагменты объединяют по координатам и удаляют перекрывающиеся строки. Небольшое перекрытие полезно, но его размер должен быть известен постобработке.

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

Повторы, зацикливание и нестабильный Markdown

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

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

Незакрытые HTML-теги и Markdown-таблицы исправляют валидатором. Он должен сохранять исходный ответ и записывать внесённые изменения, чтобы редактор видел разницу. Автоматически угадывать недостающие числа нельзя; безопаснее пометить ячейку как требующую проверки и сослаться на координату.

Качество исходного скана

Модель не отменяет базовую подготовку изображения. Сильный наклон нарушает строки, неравномерное освещение скрывает символы, а JPEG-артефакты превращают точки и запятые в шум. Для архивных сканов полезны выравнивание, удаление чёрных полей, мягкая коррекция контраста и подавление фона. Агрессивная бинаризация может уничтожить тонкие формулы и диакритику, поэтому исходник сохраняют и сравнивают оба варианта.

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

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

Поворот, перспектива и ориентация

PDF-страница обычно рендерится с правильным поворотом, но фотографии телефона могут содержать только EXIF-метку. Перед передачей модели изображение нужно физически повернуть по EXIF и сохранить нормализованную матрицу пикселей. Иначе библиотека просмотра покажет лист правильно, а скрипт обработает его боком.

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

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

Зашифрованные и повреждённые PDF

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

Повреждённый файл иногда открывается частично. В пакетном процессе нужно фиксировать номер страницы, на которой рендеринг завершился ошибкой, и продолжать остальные документы. Перезапись исходного PDF инструментом восстановления выполняется в копию; иначе можно потерять страницы, которые ещё читались.

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

Проверка результата по уровням

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

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

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

Минимальный протокол приёмки

• все страницы присутствуют и имеют явные разделители;
• ни одна колонка или таблица не пропущена целиком;
• порядок чтения проверен на сложных макетах;
• числа и формулы прошли отдельную сверку;
• пути к изображениям открываются после переноса результата;
• рамки соответствуют нормализованным изображениям;
• обрывы и повторяющиеся последовательности отсутствуют.

Интеграция в конвейер обработки документов

DeepSeek-OCR удобнее использовать как этап, который получает нормализованную страницу и возвращает структурированный черновик. Перед ним размещают загрузку, антивирусную проверку, рендеринг и коррекцию изображения. После него — валидацию Markdown, нормализацию таблиц, извлечение сущностей, полнотекстовый индекс и ручную проверку критичных полей.

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

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

Конфиденциальность и изоляция

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

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

Пользовательский код модели выполняется при загрузке, поэтому источник файлов имеет значение. Безопасная практика — загрузить модель на отдельном этапе, проверить контрольные суммы, просмотреть Python-файлы и затем перенести комплект в закрытую среду. Автоматическое получение новой ревизии при каждом запуске ухудшает воспроизводимость и усложняет аудит.

Типичные ошибки запуска

Сообщение или симптом	Вероятная причина	Что проверить
CUDA недоступна	Драйвер, сборка PyTorch или переменные окружения	Результат проверки CUDA, имя GPU и версию драйвера
Ошибка импорта flash-attn	Несовместимая бинарная сборка	Соответствие PyTorch, CUDA и компилятора
Неизвестный класс модели	Не загружен пользовательский код или неверный каталог	Полноту файлов и параметр доверия к коду
CUDA out of memory	Слишком много последовательностей или кропов	Параллелизм, режим, длину и долю памяти
Пустой либо оборванный ответ	Проблемный вход, лимит длины или сбой постобработки	Изображение, консольный поток и закрытие маркеров
Не создаются картинки	Нет прав записи или разметка не содержит областей	Каталог вывода, координатный запрос и журнал
PDF не открывается	Пароль, повреждение или необычный размер страницы	Рендер страницы отдельным тестом

Диагностику начинают с минимального примера: одна известная PNG-страница, короткий путь, Base и одиночная последовательность. Если он работает, постепенно возвращают PDF, динамическую нарезку и параллелизм. Такой порядок отделяет ошибку среды от ошибки конкретного документа.

Ошибки качества и способы исправления

Проблема результата	Сначала попробуйте	Когда нужен другой подход
Пропущен мелкий текст	Large или динамический режим	Повторный скан с лучшим разрешением
Перемешаны колонки	Markdown с координатами	Разрезание страницы и сортировка блоков
Повторяются строки	Уменьшить кропы и проверить вход	Постобработка повторов по координатам
Ломается таблица	Выделить таблицу отдельным кропом	Специализированный табличный парсер
Ошибки в формулах	Увеличить масштаб и проверить LaTeX	Ручная сверка критичных выражений
Неверный SMILES	Крупный кроп структуры	Химический OCR и экспертная проверка
Описание добавляет детали	Использовать буквальный OCR	Ограничить задачу и хранить исходный кроп

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

Сравнение DeepSeek-OCR с аналогами

Программа	Лучше подходит для	Главное ограничение
DeepSeek-OCR	PDF в Markdown, координатная разметка и глубокий разбор рисунков	Требует CUDA-среды и настройки кода
PDF Commander	Ручное распознавание, редактирование и сборка PDF в понятном окне	Не предназначен для модельного пакетного парсинга
PaddleOCR	Промышленные OCR-конвейеры, детекция текста и структурные задачи	Сложные документы требуют подбора нескольких модулей
MinerU	Преобразование научных и офисных PDF в структурированные форматы	Тяжёлый многоэтапный конвейер
GOT-OCR 2.0	Универсальное OCR изображений и форматированный вывод	Меньше акцент на экономии визуальных токенов
OCRmyPDF	Добавление поискового текстового слоя к сканированным PDF	Не разбирает фигуры и смысловую структуру как VLM

DeepSeek-OCR выбирают, когда нужен программируемый PDF-to-Markdown, координаты и отдельный анализ рисунков на GPU. PDF Commander удобнее для человека, которому важно открыть документ, исправить страницы и получить результат без настройки Python. PaddleOCR подходит для зрелого OCR-конвейера с отдельными детекторами и языковыми моделями. MinerU ориентирован на комплексный разбор PDF, GOT-OCR 2.0 — на универсальное распознавание изображений, а OCRmyPDF — на сохранение исходного вида PDF с добавленным поисковым слоем.

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

Где DeepSeek-OCR особенно полезен

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

Второй сценарий — научные и технические документы с формулами, диаграммами и схемами. Разделение страницы и глубокого разбора фигуры помогает создать связанный набор: основной текст, математические выражения, отдельные рисунки и их описания. Для формул, химии и чисел требуется предметная проверка, но автоматизация заметно сокращает объём ручного переноса.

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

Когда лучше выбрать другой инструмент

Если задача состоит в том, чтобы открыть несколько PDF, переставить страницы, внести правку и распознать текст вручную, инженерный конвейер DeepSeek-OCR создаёт лишнюю сложность. Здесь рациональнее редактор с графическими командами и предпросмотром. Он не даст модельной разметки рисунков, зато быстрее приведёт отдельный документ к нужному виду.

Если требуется только поисковый слой поверх неизменённого скана, OCRmyPDF сохраняет исходный PDF и добавляет скрытый текст. DeepSeek-OCR формирует Markdown и вспомогательные материалы, но не создаёт готовый PDF/A с текстовым слоем одной командой. Такой файл можно собрать отдельным этапом, однако это уже дополнительная разработка.

Если GPU недоступен, следует оценить классический OCR или облачный сервис с утверждённой политикой данных. Попытка выполнить тяжёлую модель на CPU редко оправдана. Для очень стабильных форм, где нужны фиксированные поля, шаблонный детектор и правила валидации могут быть точнее и проще в сопровождении, чем генеративный разбор всей страницы.

Практический сценарий: архив договоров

Для договоров сначала рендерят страницы, выравнивают ориентацию и отделяют пустые листы. Запрос на Markdown сохраняет разделы, нумерованные пункты и таблицы приложений. Координаты связывают найденные даты, суммы и стороны с исходными областями. Затем отдельный модуль извлекает поля, но не принимает значение без ссылки на страницу и рамку.

Титульные страницы и приложения обрабатываются разными профилями. Для титула достаточно Base, а мелкая таблица реквизитов может потребовать Large. Подписи и печати сохраняют как изображения; общее описание не используется как доказательство наличия подписи. Статус подписания подтверждает человек или специализированная система проверки электронной подписи.

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

Практический сценарий: научные статьи

Научную статью выгодно обрабатывать в два прохода. Первый создаёт Markdown страницы и выделяет рисунки. Второй разбирает каждый график, схему или химическую структуру подходящим запросом. Формулы проходят синтаксический контроль, а номера рисунков и ссылок сопоставляются с подписями.

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

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

Практический сценарий: каталоги и отчёты

Каталоги часто сочетают карточки товаров, таблицы характеристик и фотографии. Полную страницу распознают для заголовков и порядка карточек, затем каждую карточку выделяют по координатам. Фотографии сохраняют отдельно, а характеристики нормализуют по словарю единиц. Значение не принимается, если оно появилось только в описании изображения и отсутствует в текстовом блоке.

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

Регулярный выпуск удобно сравнивать с предыдущим: структура разделов, число таблиц и набор заголовков должны быть близкими. Резкое изменение может означать новый макет или ошибку OCR. Система направляет такие документы на повтор с другим режимом, а не молча смешивает несовместимые схемы данных.

Настройка воспроизводимого эксперимента

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

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

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

Подготовка результата к поиску и RAG

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

Каждый поисковый фрагмент должен содержать идентификатор документа, страницу и координату исходного блока. При ответе система показывает эту привязку, а не только сгенерированный текст. Для таблицы желательно хранить заголовки строк и столбцов вместе с каждой группой ячеек; иначе число окажется без единицы и периода.

Перед индексацией удаляют повторяющиеся колонтитулы и проверяют язык. Нельзя исправлять сомнительные слова языковой моделью без пометки: такая редактура может скрыть OCR-ошибку. Лучше хранить исходную транскрипцию и отдельное нормализованное поле, сохраняя связь между ними.

Формирование поискового PDF

DeepSeek-OCR не добавляет скрытый текстовый слой в исходный PDF автоматически. Если нужен поисковый PDF, используют координаты и текст для отдельной сборки либо передают исходник классическому OCR-инструменту. При сборке важно сохранить размеры страницы и преобразовать координаты из растровой системы в PDF-пункты.

Текстовый слой должен совпадать с видимыми строками. Если разместить весь Markdown одним блоком, поиск найдёт слова, но выделение на странице будет неправильным. Для качественного слоя нужны строки или слова с координатами, подходящий шрифт и направление письма. Координаты блоков DeepSeek-OCR полезны как начало, но могут быть недостаточно детальными для посимвольного наложения.

Для архивного стандарта дополнительно проверяют шрифты, метаданные и соответствие PDF/A. Это отдельная задача от распознавания содержания. Исходный скан не следует заменять перерисованным Markdown, потому что визуальная доказательность и подписи должны сохраниться.

Сопровождение рабочего контура

После настройки важно контролировать не только модель, но и библиотеки рендеринга, драйвер, формат входных файлов и свободное место. Изменение PyMuPDF может повлиять на размеры изображений, а изменение драйвера — на доступную память. Перед обновлением прогоняют эталонный набор и сравнивают структуру, время и ошибки.

Кэш весов защищают от частичной записи. Если загрузка оборвалась, файл может иметь правильное имя, но неверный размер. Проверка хэша до старта предотвращает труднообъяснимые ошибки чтения Safetensors. Для нескольких машин веса распространяют из одного проверенного хранилища, а не скачивают независимо при каждом запуске.

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

Языковые догадки и смысловые искажения

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

Риск особенно высок в серийных номерах, кодах, редких фамилиях, артиклах, формулах и текстах с намеренными подстановками символов. Эти поля нельзя принимать только по связному Markdown. Их проверяют посимвольно по координатному кропу, а при наличии контрольной суммы, справочника или регулярного формата — валидируют автоматически. Поле, которое не прошло проверку, сохраняют как неопределённое, а не исправляют по смыслу.

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

Для обнаружения правдоподобных подстановок полезно сравнивать два независимых представления. Первый проход выполняют в режиме Markdown, второй — свободным OCR на кропе критичного поля. Расхождение отправляют на проверку. Два совпавших ответа не являются абсолютным доказательством, но такой контроль лучше выявляет случаи, когда структурный запрос заставил модель достроить ожидаемое содержание.

Работа с нестандартными форматами страниц

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

Документы с прозрачностью, слоями и векторными объектами рендерят на белом или другом ожидаемом фоне. Иначе светлый текст может исчезнуть, а прозрачная маска превратиться в чёрную область. Контрольная миниатюра рендера обязательна: модель видит именно её, а не то, что интерактивный просмотрщик собирает из слоёв на экране.

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

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

• Окружение изолировано, CUDA и все бинарные расширения импортируются без ошибок.
• Весам и коду модели соответствуют сохранённые контрольные суммы.
• Входной каталог доступен только нужному процессу, а выходной имеет достаточный объём.
• На эталонных страницах выбран режим разрешения и предел числа кропов.
• Параллелизм оставляет запас видеопамяти для самой плотной страницы.
• Результат каждой страницы записывается атомарно и может быть возобновлён.
• Markdown, таблицы, формулы и координаты проходят автоматическую проверку.
• Критичные числа и специализированные структуры направляются на ручную сверку.
• Временные изображения и журналы подчиняются политике хранения данных.

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

Итоговый подход к работе

DeepSeek-OCR наиболее полезен как управляемый конвейер, который превращает визуальную страницу в проверяемый структурированный материал. Его сильная сторона — сочетание Markdown, координат, извлечения изображений и отдельных запросов для фигур. Эти возможности раскрываются только при точной конфигурации режима, памяти и формы запроса.

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

Для первой рабочей схемы достаточно выбрать Base, обработать одну типовую и одну трудную страницу, проверить Markdown и рамки, затем настроить динамическую нарезку только для проблемных макетов. После этого можно переходить к vLLM, очереди и автоматической приёмке. Такой порядок позволяет получить пользу от модели без потери контроля над числами, формулами и исходными страницами.