Почему автоматическая классификация документов ломается на потоке
Пока входящий поток однородный, автоматическая классификация документов держится на правилах: отправитель, имя файла, набор ключевых слов, регулярное выражение по шапке. Схема читается глазами и правится за минуты, а метрики на исторических данных выглядят почти идеально — на стабильном потоке этого действительно хватает.
Рост входящего потока ломает главное допущение — однородность. Приходят новые контрагенты, сканы без текстового слоя, переехавшие шаблоны, файлы с двумя основаниями сразу. Правило, искавшее одну строку, молча перестаёт срабатывать, а фиксированный порог уверенности пропускает дальше всё, что отдалённо похоже на знакомый образец.
Дальше включается каскад. Ошибки маршрутизации уводят счёт в согласование договоров, а акт — в бухгалтерию, и обнаруживается это через сутки, когда срок уже горит. Каждый промах добавляет документ в очередь ручной сортировки, и она становится узким местом обработки: оператор разбирает не исключения, а весь объём, который не поймали правила.
Разбираем, как это закрывается: классификатор смотрит на содержимое, а не на формальные признаки, обучается на ваших размеченных примерах и отдаёт документ в маршрут вместе с оценкой уверенности — спорные случаи уходят не в общую очередь, а к конкретному специалисту.
Что даёт классификация на практике: скорость, точность, риски
Эффект измеряем на трёх метриках: скорость разбора потока, доля ошибок на размеченном контроле и объём ручной проверки. Считаем их на реальном входящем потоке, а не на показательной выборке — тогда видно и пиковые дни, и нетипичные документы.
- Скорость разбора. Очередь входящих обрабатывается непрерывно: ночные поступления готовы к утру, а пик разбирается минутами, а не сменой операторов.
- Доля ошибок. По массовым типам точность держится выше 95%; основная часть промахов — редкие типы и плохие сканы. Чтение текста идёт через распознавание на Tesseract, поэтому качество исходного изображения остаётся главным ограничением.
- Ручная проверка. Под неё уходит только часть документов с низкой уверенностью модели: оператор видит топ-гипотезы и подтверждает одну, а не вводит реквизиты с нуля.
- Простой процесса. Узкое место смещается с разбора на поступление: ожидание в очереди сокращается с часов до минут, зависшие документы видны в мониторинге сразу.
- Устранённые отказы. Уходит класс ошибок «неверный тип»: документ, попавший не в тот маршрут, больше не застревает в согласовании.
- Обратная связь. Правки операторов собираются в разметку, следующая итерация обучения снижает долю ошибок и добавляет новые типы без переписывания правил.
Границы фиксируем честно: типы, которые модель различает неуверенно, закрываем явным правилом или подтверждением человеком, а не догадкой.
Подходы к разбору: правила, обучение на разметке, гибрид
Разбор начинается с решения, какой сигнал считать признаком типа: структуру бланка, устойчивые якоря в шапке, состав реквизитов или сам текст. Пока поставщики не меняют макеты, этого достаточно. Как только поток меняется — приходит новый контрагент, обновился бланк, появилась сканированная копия вместо файла с текстовым слоем, — правила начинают срабатывать ложно, и качество разбора проседает незаметно для отчётности.
Мы не выбираем схему заранее: считаем метрики на выгрузке реальных документов заказчика. Если 70–80% потока однотипны, их дешевле и надёжнее закрыть правилами — каждое решение объяснимо, ошибку видно в конкретном условии. Остаток отдаём модели.
Три схемы и цена их сопровождения
| Подход | Когда подходит | Ограничения |
|---|---|---|
| Правила и шаблоны по якорям | Поток однородный, формы фиксированы, важна объяснимость каждого решения | Ломается при смене макета: правки бланка дают ложные срабатывания, список исключений растёт быстрее, чем правила |
| Обучение на разметке | Типы документов разнородны, полезный признак — содержание, а не внешний вид | Нужна размеченная выборка и её регулярное пополнение; на новых классах качество падает, нужен контроль смещения данных |
| Гибрид | Есть стабильное ядро форм и длинный хвост нестандартных документов | Два слоя версионируются и отлаживаются вместе, ошибка приходит из правил, из модели или из их приоритета |
Как мы внедряем разбор входящего потока: этапы работ
Порядок работ выстроен так, чтобы качество разбора было измеримо до запуска в рабочий контур. Поэтому начинаем не с модели, а с описания потока: какие типы документов приходят, в каком объёме и где сейчас возникает ручная работа.
- Аудит потока. Считаем объём по типам, смотрим источники поступления — почта, сканы, файловый обмен, интеграции — и фиксируем долю документов, которые сегодня разбирает человек.
- Схема классов. Согласуем закрытый список типов и правила для спорных случаев: документ попадает ровно в одну категорию, иначе качество невозможно измерить.
- Разметка выборки. Собираем представительную выборку по всем типам, включая редкие и пограничные, размечаем по согласованным правилам и делим на обучающую и отложенную части.
- Настройка разбора. Учим модель на размеченной части, добавляем распознавание текста из сканов и извлечение реквизитов, качество проверяем отдельно по каждому типу.
- Проверка на отложенной выборке. Оцениваем точность по классам, матрицу ошибок и поведение на плохих сканах — этих данных модель не видела. Доля ошибок здесь и есть критерий готовности.
- Порог уверенности. Документы с низкой уверенностью уходят оператору, а не в автоматическую обработку; модель дообучаем на его правках.
- Приёмка решения. Согласуем метрики, прогоняем поток на реальном объёме и передаём конфигурацию, правила разметки и регламент контроля качества.
Что остаётся у вас после внедрения: конфигурации и регламенты
Передаём не «работающую модель в вашем контуре», а полный комплект документации, по которому ваша команда сопровождения сможет вести систему без нас. Ниже — что именно остаётся у вас на руках после сдачи.
- Схема решения — от точки входа документа до записи результата: какие этапы проходит файл, где проверяется качество распознавания, что происходит при отказе узла и куда уходит уведомление. По ней новый инженер входит в систему без разбора чужого кода.
- Карта типов — реестр классов с примерами и описанием признаков, по которым тип отличается от соседнего (например, счёт и акт с похожей шапкой). При появлении нового типа документа видно, куда его добавить и какие правила затронуть.
- Регламент обработки — что делать с ответами низкой уверенности: порог передачи на ручную проверку, очередь оператора, сроки разбора, маршрутизация по подразделениям.
- Инструкции для операторов — как подтверждать и отклонять результат, как помечать ошибку, чтобы она попала в следующую разметку, и какие типы ошибок важнее остальных.
- Порядок обновления модели — правила разметки новых примеров, требования к объёму выборки на класс, порядок прогона проверок на отложенном наборе перед публикацией.
- Метрики и отчёты — доля верных ответов в разрезе типов, а не общая цифра: видно, какой класс деградирует первым и когда нужно вмешаться.
- Журнал версий и откат — какая версия сейчас в работе, чем отличается от предыдущей и как вернуться к ней, если качество просело.
Такой комплект закрывает главный риск внедрения: система, которую умеет сопровождать только её автор. Передаём материалы вместе с разбором вашей команде — опишите задачу, и мы вернёмся с оценкой и планом.
Кейс: разбор входящего потока в учётной системе
Где стоял поток
Входящий поток учётной системы — счета, акты, договоры, накладные, сканы и фотографии — разбирался операторами вручную: открыть файл, определить тип, разложить по маршрутам обработки. На объёме около 4 000 документов в сутки механическая разметка съедала до 60% времени смены, а в пиковые дни регламентные сроки срывались.
Что изменили в конвейере
Собрали последовательность: извлечение текста через Tesseract для сканов и разбор структуры для «цифровых» файлов, затем классификатор по типу документа с порогом уверенности. Всё, что ниже порога, не отбрасывается и не угадывается — уходит в очередь ручной проверки с уже предзаполненным типом, оператору остаётся подтвердить или поправить.
Метрики на том же потоке
Точность определения типа выросла с 78% до 96%, доля ручной проверки упала с 100% до 21% — и эти проценты приходятся в основном на мятые сканы и смешанные пакеты. Среднее время от поступления файла до разложенного документа сократилось с 38 минут до 2,5 минуты.
Отдельно разобрали класс ошибок: неверная маршрутизация счёта в блок актов раньше всплывала на сверке через неделю, теперь конфликт типов ловится на входе. Нагрузка на смену снизилась примерно вчетверо, пиковые дни перестали быть узким местом, а освободившееся время ушло на спорные документы вместо механической сортировки.
Что делать, если уже настроены правила и скрипты отбора?
Отключать правила не нужно — модель запускается рядом с ними и первое время работает в теневом режиме: документ проходит оба сценария, а решение правила остаётся действующим, пока мы сравниваем результаты на живом потоке. На этой выборке видно, где условия ошибаются, а где модель ведёт себя неуверенно, — и появляется реальный запас точности, а не обещанный.
Дальше включается маршрутизация по уверенности. Если модель размечает класс уверенно, решение принимается сразу; если ниже порога — документ уходит по старым условиям или оператору. Порог настраивается отдельно для каждого класса, поэтому на критичных типах правила остаются единственным источником решения, а модель на них только учится.
Правила часто живут прямо в учётной системе — 1С:Документооборот и похожих контурах, где каждое изменение согласуется. Отсюда и порядок перехода: сначала теневой прогон, затем один тип документа, потом остальные, и лишь после этого условия отключаются по одному.
Главная слабость правил — новые типы документов: каждый новый шаблон или контрагент требует очередного набора условий, и поддержка растёт быстрее самого потока. Модель закрывает это дообучением: несколько сотен размеченных примеров нового класса, проверка на зафиксированном наборе, и класс вводится без переписывания логики. Спорные документы попадают в очередь разметки — она же становится материалом для следующего дообучения.
Технические сомнения: точность, разметка, дообучение
Вопросы на этапе сравнения подрядчиков повторяются: как измеряется качество, кто размечает данные, как классификатор стыкуется с учётной системой и что меняется после запуска. Ниже — ответы без презентационных формулировок.
Какую точность считать достаточной и на чём её измеряете?
Точность считаем по каждому типу документа отдельно: на потоке редкий класс весит мало, а ошибка в нём дороже всего. Замер на отложенной выборке с матрицей ошибок показывает, какие близкие формы модель путает. Порог согласуем до старта, а неуверенные ответы уходят на ручную проверку.
Сколько документов нужно разметить и кто это делает?
Разметка ограничивает проект сильнее, чем код. Хватает нескольких сотен примеров на класс, редкие типы добираем переносом и синтетикой. Размечает сотрудник заказчика, знающий предметную область, а правила и спорные случаи фиксируем в реестре решений.
Как решение стыкуется с учётной системой?
Учётную систему не переписываем: классификатор — отдельный сервис, который забирает документ из папки, почтового шлюза или шины и отдаёт тип, уверенность и распознанные поля. Обмен по открытому интерфейсу, повторный вызов не создаёт дубль записи. Сначала тестовый контур, затем параллельная работа, потом автопроводка.
Что происходит после запуска и как выглядит дообучение?
Модель деградирует: меняются формы, поставщики, регламенты. Мониторим долю верных ответов на потоке, исправления операторов собираем в обучающий набор, дообучение запускаем по расписанию или по падению метрики. Версии модели храним — откат на предыдущую занимает одну операцию.
Обсудим задачу и вернёмся с оценкой и планом
Чтобы оценка была точной, а не взятой с потолка, нужен срез вашего реального потока — выгрузка целиком не требуется, достаточно представительной выборки. Соберите то, что уже есть под рукой, остальное уточним в разговоре.
- 200–300 документов каждого типа в исходном виде: сканы, DOCX, фотографии — так видно, с каким качеством съёмки и вёрсткой придётся работать;
- перечень классов, по которым документы должны раскладываться, с примерами спорных случаев — где граница между «договором поставки» и «счётом», определяете вы;
- как документы приходят сейчас: почта, сканер, папка, выгрузка из учётной системы — и объём за день;
- примеры ручной разметки, если она велась: ускоряет обучение модели;
- требования к ответу системы: метка класса, степень уверенности, что делать с неуверенными документами;
- ограничения по доступам: нужно ли обрабатывать данные внутри вашего контура.
Вернёмся с тремя вещами: оценкой проекта по этапам, планом работ с составом команды и сроками и прогнозом эффекта в измеримых величинах — доля документов, разобранных без человека, точность на вашей выборке, время обработки одного документа. Дальше предлагаем пилот на ограниченном потоке: один-два типа документов или одно подразделение, зато на живых данных и с замером метрик до и после — по результату видно, масштабировать ли решение на весь объём.
Опишите задачу в свободной форме и приложите выборку — вернёмся с оценкой и планом.
