Relation Extraction на реальних текстах: де втрачається точність
У договорах, протоколах і технічних описах семантичні зв'язки між сутностями є завжди: хто кому підпорядковується, що на що посилається, яка умова обмежує поставку. Поки вилучення зв'язків із тексту робиться вручну, ці зв'язки живуть лише в голові аналітика та в його виписках.
Ручний розбір документів не масштабується: на корпусі в десятки тисяч сторінок він перетворюється на окремий напрям роботи зі своїми строками та чергою.
Перший очевидний крок — шаблони й регулярні вирази — ламається на живих формулюваннях. «Поставка здійснюється до», «не пізніше», «у строк, погоджений сторонами» описують те саме відношення, а шаблон ловить лише перший варіант і далі видає хибні спрацювання.
Чим більше типів зв'язків, тим складніше підтримувати правила: кожне нове слово вимагає нового винятку, а винятки починають конфліктувати між собою.
Але головна втрата точності відбувається не в моделі, а до неї — у якості розмітки. Зв'язок потрібно позначити окремим об'єктом: тип, напрямок, точні межі учасників.
Тому розмітка ведеться в інструменті, який зберігає зв'язок як самостійну сутність, — наприклад, Label Studio, — інакше модель вчиться вгадувати зв'язок за близькістю слів і додає власні хибні спрацювання поверх тих, що вже є.
Далі розбираємо, як це закривається: схема типів зв'язків під предметну область, регламент розмітки, вимірювання згоди між розмітниками й звіт щодо точності окремо за кожним типом зв'язку — замість однієї середньої цифри, яка на живих текстах нічого не пояснює.
Ефект впровадження: швидкість розбору, повнота й точність зв'язків
Перший вимірюваний ефект — швидкість обробки документів. Модуль вилучення зв'язків розбирає типовий договір або протокол за секунди, тоді як ручна розмітка того самого тексту займає в аналітика десятки хвилин.
На однотипних документах потік іде пакетом: правило, налаштоване на шаблон, далі застосовується без участі людини.
Повноту вилучення зв'язків вважаємо на відкладеній вибірці, яку модель не бачила під час навчання. Фіксуємо не одну цифру, а профіль: частка зв'язків, знайдених без ручної правки, окремо за типами відношень — «постачальник — товар», «співробітник — роль», «документ — підстава».
Точність моделі налаштовується порогом спрацювання: вищий поріг — менше хибних зв'язків, але більше пропусків, і цей баланс ми підбираємо під задачу, а не під гарну метрику.
Частка ручної правки — головний робочий показник. На старті вона може сягати половини знайдених зв'язків, після донавчання на розмітці замовника опускається до одиниць відсотків на знайомих типах текстів.
Зростання частки правок ми читаємо як сигнал: змінився формат вхідних документів або з'явився новий постачальник з іншою версткою.
Стійкість на нових типах текстів тримається на циклі: непокриті приклади йдуть у розмітку, модель донавчається, якість звіряється з контрольним набором.
Розмітку сутностей і зв'язків ведемо на відкритому стеку — spaCy і сумісних із ним форматах, тому дані залишаються переносними й не прив'язані до одного постачальника.
Підходи до Relation Extraction: правила, моделі, гібридні схеми
Вибір схеми визначається структурою корпусу та ціною помилки, а не модністю методу. Якщо формулювання однотипні й потрібно пояснити кожне спрацювання — працюють правила та словники.
Якщо тексти живі, з перефразуваннями та одруківками — ні правила, ні навчена на малій вибірці модель не тримають якість на рідкісних типах зв'язків.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Правила та словники | Вузький домен, стійкі формулювання, потрібна пояснюваність кожного спрацювання | Підтримуються вручну; ламаються на перефразуваннях; зі зростанням кількості правил з'являються конфлікти між ними |
| Навчена модель на власній розмітці | Є кілька тисяч розмічених зв'язків, домен стабільний, типи зв'язків фіксовані | Потрібна узгоджена розмітка; у разі зміни домену або формату документів якість падає й потребує перенавчання |
| Попередньо навчена мовна модель із донавчанням | Мало розмітки, різноманітні формулювання, довгі тексти | Слабша на рідкісних класах; важча в експлуатації, потрібен контроль утеч і регулярне оновлення на нових даних |
| Гібридна схема: правила плюс модель | Змішаний корпус, де частина зв'язків задається жорсткими умовами | Складніша у зневадженні: два джерела помилок і потрібен окремий шар розв'язання конфліктів |
На практиці частіше виграє гібридна схема: правила відсікають вочевидь хибні спрацювання й закривають зв'язки з жорстким контекстом, модель добирає перефразування.
Якість при цьому вимірюється окремо за кожним типом зв'язку — середня цифра приховує провал на рідкісному класі, який якраз і визначає застосовність рішення.
Як будується проєкт: від аудиту корпусу до передачі моделі
Зв'язки між сутностями задає не текст, а схема: якщо типи зв'язків описані приблизно, модель вивчить шум і буде впевнено помилятися на нових документах. Тому робота йде від вимірювання корпусу до передачі, і кожен етап закінчується перевірюваним результатом.
- Аудит корпусу. Рахуємо реальний обсяг, дублі та наявні типи сутностей, відзначаємо, яких зв'язків для навчання не вистачає.
- Схема розмітки. Фіксуємо типи зв'язків, їхній напрямок і правила спірних випадків — заперечення, переліки, згадки в дужках. Схему узгоджуємо до розмітки, інакше інструкції переписують разом із готовим матеріалом.
- Розмітка й контроль якості. Частину документів розмічають двоє незалежно, розбіжності уточнюють інструкцію. Згоду рахуємо у відсотках: низьке значення означає, що задачу по-різному розуміють і людина, і модель.
- Навчання. Модель на попередньо навченому мовному представленні донавчається на корпусі; окремо дивимося рідкісні типи зв'язків, які губляться першими.
- Перевірка на відкладеній вибірці. Метрики рахуємо на документах поза навчанням і за кожним типом зв'язку окремо — середня оцінка приховує провал на рідкісних класах.
- Вбудовування в процес. Підключаємо модель до поточного контуру: пакетна обробка, оцінка впевненості за кожним зв'язком, ручна перевірка сумнівних випадків. Поріг упевненості налаштовуємо так, щоб потік на перевірку не зростав швидше, ніж команда його розбирає.
- Передача. Віддаємо ваги, конфігурацію розгортання, схему розмітки й розбір метрик — донавчання на нових даних команда веде сама.
Що передаємо на руки: схема розмітки, модель, регламент роботи
Рішення з вилучення зв'язків марне, якщо логіка розмітки живе в голові одного інженера, а модель не можна перенавчити без автора.
Тому разом із робочою моделлю ми передаємо команді замовника набір артефактів — за ними новий фахівець відтворює результат, а relation extraction продовжує працювати на даних, які з'являються після запуску.
- Схема розмітки. Типи сутностей і допустимі зв'язки між ними, правила меж, пріоритет при перетині та розбір спірних випадків, на яких розмітники розходяться найчастіше.
- Інструкція для розмітників. Порядок роботи, приклади «правильно / неправильно» на реальних фрагментах і критерій узгодженості — частка збіжних зв'язків у двох розмітників.
- Документація щодо моделі. Які типи зв'язків вилучаються, на яких даних навчена модель, де межа застосовності й якого класу помилки вона припускає на коротких і неповних текстах.
- Набір контрольних прикладів. Розмічені фрагменти з еталонними зв'язками: прогін за ними після кожного донавчання показує, чи не деградувала модель.
- Регламент донавчання. Коли збирати нові дані, як розмічати їх за тією ж схемою, як перевіряти якість до викочування й у який момент відкочувати попередню версію.
- Звіт щодо якості та пороги. Точність і повнота за кожним типом зв'язку окремо, плюс поріг упевненості, нижче якого зв'язок іде на ручну перевірку, а не в систему.
Кейс: вилучення зв'язків між сторонами в договорах і заявках
Задача надійшла з юридичного сервісу: кілька тисяч договорів і заявок на місяць, зв'язки між сторонами витягували евристиками за шаблонами. Ролі плуталися, а нетипова застереження ламала розбір документа цілком.
Контрольний корпус зібрали з розмічених документів і звірили розмітку з відкритим набором CUAD — метрики рахували лише за ним, щоб результат не залежав від одного вивантаження.
Класи помилок і що з ними зробили
| Клас помилки | Причина | Що змінили | Частка до → після |
|---|---|---|---|
| Зв'язок іде на сусідню сторону | Розмітка не розділяла ролі платника й поручителя | Окремі мітки ролей і словник тригерів за типами застережень | 18% → 4% |
| Обрив зв'язку між абзацами | Вікно аналізу обривалося на межі абзацу | Урахування внутрішніх посилань за всім текстом документа | 12% → 3% |
| Хибні зв'язки в реквізитах | Шапка розбиралася як тіло договору | Фільтр за смисловими секціями та структурою документа | 9% → 1% |
Точність за зв'язками на контрольному корпусі зросла з 0,74 до 0,92, частка документів, що йшли на ручну перевірку, — з 41% до 9%.
Вирішальним було не ускладнення моделі, а розділення ролей у розмітці: прив'язка сторони до зобов'язання перестала залежати від порядку згадок у тексті.
Контрольний корпус залишився в проєкті як регрес-набір: кожна ітерація проганяється за ним цілком, а новий тип зв'язку додається через розмітку, а не правкою коду. Це дає передбачуваний відкат — при падінні метрики видно, на яких саме документах розійшлася розмітка.
Чим вилучення зв'язків відрізняється від пошуку за ключовими словами
Пошук за ключовими словами відповідає на питання, у яких документах трапляється слово, і повертає список файлів за релевантністю. Цього достатньо, щоб знайти першоджерело, але не щоб зрозуміти, як пов'язані люди, компанії та події.
Документ залишається для системи закритим: відповідь лежить усередині, а назовні виходить лише назва файлу.
Вилучення зв'язків працює глибше. Модель розмічає в тексті сутності — організації, персони, дати, юридичні ролі — і визначає зв'язок між сутностями: хто кому підпорядковується, хто кому постачає, хто з ким підписав договір.
Вихід — не список документів, а трійки «сутність — відношення — сутність», тобто структуровані дані.
Із цих трійок збирається граф знань: вузли — сутності, ребра — типи зв'язків із зазначенням документа й фрагмента, звідки зв'язок вилучено.
За графом проходять ланцюжки, недоступні пошуку: два контрагенти можуть бути пов'язані через спільного керівника в третій компанії, хоча разом в одному тексті вони не згадуються.
Особливо помітна різниця в аналітиці за документами. Ключовий пошук дає частку текстів, де трапилася згадка, граф відповідає на питання, скільки контрагентів пов'язано з організацією і через який тип відношень.
Перше вимірює присутність слова, друге — структуру предметної області, і тільки на ньому будуються запити виду «хто пов'язаний з X не напряму».
Сумніви щодо даних, розмітки та підтримки моделі
Сумніви перед стартом зазвичай ті самі: чи вистачить даних, що робити з уже розміченим корпусом, чи потягне модель різнорідні тексти й хто відповідає за якість після запуску. Розбираємо типові випадки.
У нас мало розмічених даних — моделі вистачить?
Обсяг рахуємо не в абсолютних числах, а за покриттям типів зв'язків. Йдемо ітераціями: стартова розмітка, замір на відкладеній вибірці, добір прикладів лише там, де модель помиляється. Тексти без розмітки теж працюють — формулювання, яких немає у вибірці, модель усе одно бачить.
Розмітка частково є, але зроблена під іншу задачу
Наявну схему зв'язків зіставляємо з цільовою онтологією — заново розмічаємо лише відсутні типи, а їх зазвичай меншість. Відношення, які надійно виводяться правилами, у ручну розмітку не потрапляють.
Документи різнорідні: договори, листування, скани, таблиці
Кілька типів документів розводимо на окремі гілки підготовки, але приводимо до єдиної онтології зв'язків — інакше результати непорівнювані між собою. Модель навчаємо на вибірці з кожного типу, щоб один формат не перетягнув передбачення на себе.
Що відбувається з моделлю після запуску?
Підтримка — це цикл, а не разовий замір: стежимо за часткою впевнених вилучень і новими формулюваннями, помилки йдуть у наступну ітерацію донавчання. Версіонуємо модель і розмітку, тому відкат на попередню робочу версію — питання хвилин.
Залишкові питання — про доступи, формати вивантаження результату та критерії приймання — знімаємо до старту, щоб не переробляти розмітку в процесі.Обговорімо вашу задачу вилучення зв'язків і обсяг корпусу
Розмова по суті починається з корпусу, а не з обговорення моделі.
Вилучення зв'язків перевіряється тільки на ваших текстах: на однотипних документах будь-яка схема виглядає робочою, а на реальних договорах, звітах або листуванні відразу видно, яких типів зв'язків не вистачає і де правило не спрацьовує.
Від вас корисно показати:
- 20–50 реальних документів або вивантаження — як є, разом із шумом, сканами й нестандартним оформленням;
- перелік сутностей і зв'язків, які потрібні на виході: типи, напрямок, кратність;
- один документ із ручною розміткою — еталон, за яким будемо рахувати якість;
- звідки беруться дані й куди повертається результат: сховище, база, внутрішні системи;
- обмеження щодо доступів: де можна обробляти тексти і що не можна виносити за ваш контур.
Зі свого боку уточнюємо критерії приймання: яку частку зв'язків потрібно вилучати на ваших документах, який рівень хибних спрацювань допустимий, що вважаємо пропуском, а що — зайвим зв'язком. Від цього залежить і обсяг робіт, і порядок етапів.
Далі готуємо план проєкту з точками перевірки: де ви дивитеся результат на своїх текстах і що можна скоригувати до фінальної здачі. Опишіть задачу й обсяг корпусу — повернемося з оцінкою та планом.
