Автоматичне вилучення фактів: LLM і NLP-пайплайни

Чому вилучення фактів із тексту ламається на реальних документах

На десяти тестових документах вилучення фактів із тексту виглядає розв'язаною задачею, а на потоці в пару тисяч — половина полів порожня або заповнена сміттям.

Причина в тому, що реальні документи неструктуровані: один контрагент верстає рахунок таблицею, другий — суцільним текстом, третій надсилає скан із перекосом.

Шаблон, під який налаштовували правила, трапляється щонайбільше в третині випадків. Скани додають свій клас помилок вилучення: розпізнавання плутає цифри в сумах і номерах, губить рядки у вузьких колонках, склеює сусідні комірки.

На такому вході система впевнено видає неправильні значення — а це гірше за порожнє поле, бо помилку не видно на око.

Вкладені таблиці розвалюються в плоский список, і зв'язок між позицією, її кількістю та підсумком губиться — на виході набір чисел без адреси.

Синоніми добивають правила за словником: «номер платника податків», «ІПН», «ІПН/КПП» — це одне поле в трьох написаннях, і кожне нове формулювання вимагає правки.

Коли збої накопичуються, команда повертається до ручного перенесення даних: оператор звіряє поля очима і додає їх в облікову систему. Точність відновлюється, але пропускна здатність упирається в людей, а помилки переїжджають у ті поля, які ніхто не перевіряє двічі.

Далі розбираємо, як це закривається — контролем на кожному кроці розбору документів, а не лише на виході.

Ефект від автоматичної розмітки: що змінюється в процесі

Розмітка перестає бути ручною там, де поле вилучається однозначно: реквізити, дати, суми, номери договорів, посилання на сторони. Робоча схема — гібридна: детерміновані правила й словники для регулярних полів, модель для формулювань у вільній формі.

Такий конвеєр тримає точність вилучення на рівні, який перевіряється вибіркою, а не суцільним переглядом, і головною метрикою стає частка документів, що пройшли без ручного розбору.

Швидкість обробки документів задає не модель, а організація черги: пакет розпаралелюється за документами, важкі сторінки йдуть в окремий потік, збій на одному файлі не зупиняє інші.

Пачка в кілька тисяч сторінок проходить за години замість тижнів, а повторний прогін після правки правил займає хвилини — можна змінювати логіку й одразу бачити ефект.

Контроль якості даних будується на перевірках, а не на довірі до моделі: валідація за схемою, крос-звірка пов'язаних полів, поріг упевненості, нижче якого запис іде на верифікацію.

Додатково ведемо еталонний набір і проганяємо на ньому кожну зміну — регресії ловляться до вивантаження, тому зниження ручної роботи не купується падінням точності.

Знімаються й цілі класи відмов: розбіжності форматів у постачальників, загублені під час копіювання поля, дублі однієї сутності під різними назвами.

Підхід до якості даних вибудовуємо за практикою DAMA-DMBOK — з власником поля, правилом перевірки та журналом правок, щоб результат розмітки можна було пояснити й відкотити.

Порівняння режимів розбору: правила, моделі, гібрид

Режим розбору обирають не за смаком, а за структурою даних.

Там, де значення задано формально — номер договору, дата, код, сума прописом, — виграють правила; там, де сенс тримається на контексті — сторона угоди, умова розірвання, застереження про підсудність, — без моделі не обійтися.

Крайнощі однаково дорогі: словники ламаються на першій перефразуванні, а модель без перевірки видає правдоподібне, але неправильне значення, і відрізнити його від правильного нічим.

Людина в контурі перевірки замикає схему: кожен факт приходить із посиланням на фрагмент-джерело, спірні випадки йдуть оператору за порогом упевненості, а його правки потрапляють у словники та в приклади для дообучення.

Вибір підходу — це вибір точки докладання зусиль: правила лагодять швидко, модель дообучують рідше, але вона тримає формулювання, яких у словнику ніколи не було.

Впровадження за кроками: від аудиту корпусу до передачі

Вилучення фактів ламається не на моделі, а на корпусі документів: єдиного формату немає, одне й те саме поле називається по-різному, частина значень є лише в сканах.

Тому роботи йдуть від аудиту даних до передачі — кожен етап закривається артефактом, який перевіряємо до переходу до наступного.

1. Аудит корпусу документів. Розбираємо вибірку за всіма типами: які поля трапляються, як часто відсутні, де лежить значення — у таблиці, виносці чи підписі. Підсумок — перелік полів із реалістичною оцінкою повноти вилучення.
2. Схема розмітки полів. Для кожного поля задаємо тип, допустимі варіанти запису та правило приведення до єдиного вигляду. Спірні випадки описуємо явно, щоб ручна розмітка й модель трактували їх однаково.
3. Розмітка еталонної вибірки. Кілька сотень документів розмічаємо вручну й ділимо на дві частини: одна йде на налаштування, друга залишається закритою до перевірки.
4. Налаштування вилучення. Підбираємо формулювання запитів і правила обробки результату, звіряючись із розміченою частиною. Окремо розбираємо поля, де система впевнено видає неправильний формат.
5. Перевірка на відкладеній вибірці. Проганяємо готовий контур на документах, яких він не бачив, і рахуємо за кожним полем частку правильних значень, пропусків і хибних спрацювань. Пороги приймання фіксуємо до замірів, а не після.
6. Передача в експлуатацію. Віддаємо робочий контур, журнал обробки, інтерфейс розбору спірних випадків і регламент: як підключати нові типи документів і коли переглядати схему полів.

Комплект передачі: правила, схеми та регламенти перевірки

Комплект передачі збирається паралельно з розробкою, а не в кінці проєкту: кожен артефакт перевіряють на реальному потоці документів.

Замовник отримує не опис рішення, а робочі матеріали, за якими вилучення фактів можна вести своїми силами або передати іншому інженеру без переказу «на словах».

• Схема даних — перелік сутностей і атрибутів, які витягуються з тексту: тип значення, обов'язковість, джерело, правила нормалізації, зв'язок факту з вихідним фрагментом. За нею видно, що робити при появі нового типу факту, не перебудовуючи весь контур.
• Регламент перевірки — як формується вибірка для ручного контролю, яка частка розбіжностей вважається допустимою і за якого порогу правило повертається на доопрацювання. Без нього якість тримається на пам'яті одного інженера.
• Правила вилучення з історією змін — що змінювалося, на якому зрізі корпусу перевірялося, які класи фактів зачеплено і як відкотитися на попереднє налаштування.
• Політики доступу — хто бачить вихідні документи, хто лише вилучені факти, як розділені ролі, де ведеться журнал звернень і як обробляються персональні дані.
• Документація рішення — архітектурна схема, точки стикування з обліковими системами, опис поведінки при недоступності моделі: що йде в чергу, що відкидається, як довантажується втрачене.
• Інструкції операторів — як розмітити спірний випадок, які ознаки вказують на помилку вилучення, куди ескалувати збій і що вважається інцидентом, а що штатним сумнівом.
• Журнал метрик — точність і повнота за кожним класом фактів до і після правок, щоб деградацію було видно в моменті, а не за скаргами користувачів.

Комплект супроводжується короткою передачею: розбір на живих прикладах і відповіді на запитання команди. Обсяг залежить від кількості типів документів і класів фактів — на старті обговоримо задачу й повернемося зі складом артефактів і планом робіт.

Кейс: розбір договорів із контролем якості на виході

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

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

Вилучення фактів зібрали у два шари: виписки у форматі УФЭБС і текстові договори розбирали зі структури, скани — через розпізнавання з прив'язкою до блоку на сторінці.

Кожне значення модель повертає за описаною схемою — сторони, номер, дата, сума, графік платежів, предмет — і обов'язково з посиланням на фрагмент-джерело.

Контур контролю якості

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

Поле, що не пройшло перевірку або надійшло з низькою впевненістю, іде в чергу на ручний розбір, а не в базу «як вийшло». Поруч — журнал рішень: версія схеми, фрагмент-джерело, автор правки; архів переперевіряється після зміни правил без втрати історії.

Метрики до та після

• частка документів із ручним введенням: 100% → 9–12%;
• час обробки пакета: 2–3 дні → 40–60 хвилин;
• помилки в критичних полях: 4–6% → менше 0,5%;
• повторний прогін корпусу: переобробка за новою схемою без операторів.

Ефект не лише у швидкості: у кожного факту є джерело й перевірка, тому спірний договір розбирається за фрагментом, а не за пам'яттю співробітника.

Що робити, якщо розмітка фактів уже ведеться вручну?

Накопичену ручну розмітку не потрібно викидати — це найцінніший актив проєкту. Оператори вже зафіксували межі фактів, їхні типи та зв'язки між ними, тобто створили еталон, на якому можна перевіряти будь-який автоматичний розбір.

Тому перехід починається не із впровадження моделі, а з ревізії того, що розмічено: які типи фактів реально трапляються, де формулювання розходяться, які сутності описані непослідовно.

Далі ручну розмітку приводять до машинозчитуваного вигляду: один запис — один факт, із зазначенням фрагмента тексту, типу, атрибутів і посилань на пов'язані сутності.

Паралельно фіксується схема — закритий перелік типів і правил їх виділення, щоб різні розмітники не трактували одне й те саме по-різному. Така схема стає водночас і технічним завданням для автоматики, і словником для перевірки результату.

Автоматизація запускається на готових даних, а не з нуля: модель або правила вилучення навчаються й налаштовуються на розміченому корпусі, після чого їхній результат порівнюють з еталоном вручну на відкладеній частині.

Розбіжності показують, де схема неоднозначна, а де бракує прикладів — це і є план доопрацювання. Частину розмітки свідомо залишають поза навчанням: вона потрібна як незалежний контроль якості при кожному оновленні.

Сам перехід роблять поступовим. Автоматика обробляє весь потік, а оператори підключаються лише до спірних випадків — тих, де впевненість нижча за поріг або спрацювали конфліктні правила.

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

Технічні сумніви: якість даних і дообучення

Якість вилучення упирається не в розмір моделі, а в дані, на яких її налаштовують. Якщо в розмітці змішані різні редакції договорів, а спірні поля розмічені «на око», модель впевнено видає неправильний факт — і це дорожче, ніж пропуск, бо помилку ніхто не перевіряє.

Тому дообучення ми ведемо на цільовому корпусі замовника, а не на універсальних наборах: спочатку фіксуємо схему полів і правила їх розбору, потім збираємо приклади, і лише згодом чіпаємо ваги.

Другий момент — закритий контур. Замовники справедливо не хочуть надсилати договори та персональні дані в зовнішні сервіси, тому навчання й вивід моделі розгортаємо всередині периметра. Нижче — відповіді на те, що найчастіше уточнюють до старту.

Що відбувається при зміні шаблону документів?

Змінюється верстка — втрачаються прив'язки полів і падає повнота вилучення. Схему розбору ми тримаємо окремо від моделі: правила й шаблони винесені в конфігурацію, тому правка під нову форму — це не перенавчання з нуля.

Далі додаємо кілька десятків розмічених зразків нового вигляду, дообучаємо адаптер і перевіряємо на історичному наборі, щоб не втратити якість на старих документах.

Як ви поводитеся зі спірними випадками?

Поля з низькою впевненістю моделі не йдуть у вивантаження, а потрапляють у чергу ручної перевірки з підсвічуванням фрагмента-підстави. Оператор підтверджує або виправляє значення, і ця правка повертається в навчальний набір.

Так спірні випадки поступово переходять у розряд типових, а частка ручної перевірки знижується від ітерації до ітерації.

Як ви контролюєте якість даних для дообучення?

Розмічаємо за письмовою інструкцією, ключові поля — двома виконавцями незалежно, розбіжності розбираємо окремо. Тримаємо відкладений набір прикладів, який не бере участі в навчанні, і рахуємо точність і повноту за кожним полем, а не однією загальною цифрою. Якщо метрика просідає на конкретному типі документа, це видно до викочування.

Обговоримо задачу й повернемося зі схемою та оцінкою

Щоб оцінка та план робіт спиралися на факти, а не на здогадки, достатньо надіслати зразок корпусу — сотню-другу реальних документів у тому вигляді, в якому вони надходять у систему, і перелік полів, які потрібно вилучати: типи сутностей, зв'язки між ними, допустимі формати значень.

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

• Карту типів фактів і зв'язків під ваш предметний домен: що вважаємо самостійним фактом, що атрибутом запису, а що відкидаємо як шум.
• Схему конвеєра обробки: розбір документа, нормалізація, виділення кандидатів моделлю, перевірка правилами та довідниками, зведення до канонічних записів.
• Протокол розмітки еталона й правила розв'язання спірних випадків, щоб різні розмітники трактували одне й те саме однаково.
• Метрики на ваших документах: повнота й точність за кожним типом поля, частка записів, що пішли на ручну перевірку, поведінка на нетипових форматах.
• План пілотного етапу з явними межами: обсяг вибірки, набір типів фактів і поріг якості, за якого схему можна передавати в промислову експлуатацію.
• Регламент розширення: як додавати нові типи фактів і правила без перезбирання моделі.
• Комплект документації: конфігурації, схеми потоків, інструкції з супроводу та порядок відкату на попередню версію.

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

Ми повернемося з оцінкою та планом робіт, а передача документації йде разом із результатом, а не окремим фінальним актом.