Зачем нужен отдельный контроль конвертации

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

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

Что на самом деле показывают оценки Docling

Начиная с версии 2.34.0 Docling возвращает в `ConversionResult` отчёт `confidence`. Он содержит оценки по страницам и документу и качественные категории `POOR`, `FAIR`, `GOOD`, `EXCELLENT`. Разработчики прямо советуют опираться прежде всего на агрегированные `mean_grade` и `low_grade`. Числа от 0 до 1 названы внутренними: способ их расчёта и веса могут измениться. Поэтому трактовка «0,91 означает 91% точности» неверна и опасна.

Состав отчёта тоже важен. `layout_score` относится к распознаванию элементов страницы, `ocr_score` — к тексту OCR, `parse_score` акцентирует проблемные области цифрового текста. `table_score`, согласно текущей документации, ещё не реализован. Следовательно, высокая общая оценка не является проверкой каждой ячейки таблицы, номера счёта или суммы. У Docling есть средства извлечения таблиц, но их результат нужно тестировать отдельно на реальных документах организации.

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

Архитектура без автоматического доверия

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

Дальше нужен собственный маршрутизатор, а не слепая запись в CRM:

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

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

Данные и инфраструктура пилота

Для первого опыта не нужен полный архив. Соберите 80–150 документов из тех типов, которые действительно создают нагрузку: хорошие цифровые PDF, плохие сканы, многостраничные договоры, формы с таблицами и документы на русском языке. Число здесь — ориентир пилота, не статистическая гарантия. Важно не среднее качество, а присутствие сложных случаев. Уберите или защитите персональные данные в тестовом наборе по собственным правилам доступа.

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

Развёртывание внутри сети потребует Python-среды, хранилища исходников и результатов, очереди заданий при пакетной обработке, журналирования без лишних персональных данных и разграничения доступа. Для OCR могут понадобиться дополнительные движки и языковые пакеты; Docling документирует несколько вариантов, поэтому русский язык и качество конкретных сканов проверьте фактически. CPU может быть достаточен для небольшого пилота, а потребность в GPU, память и пропускную способность следует измерить на собственных файлах и выбранной конфигурации. «Локально» не означает «без зависимостей и затрат».

Как посчитать экономику, не придумав эффект

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

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

Где границы и что сделать за неделю

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

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

Фото: Sue Brink / U.S. Navy, опубликовано NAVFAC, CC BY 2.0. Для квадратной обложки выполнен кроп без дорисовки; изображение иллюстрирует процесс оцифровки, а не конкретное внедрение Docling.