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