Автоматична побудова графа знань з текстів під ключ

Чому граф знань не збирається з текстів сам

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

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

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

Без нормалізації та розв'язання збігів сутностей граф знань з текстів розсипається на незв'язані фрагменти.

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

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

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

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

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

Що дає автоматичне вилучення сутностей і зв'язків

Конвеєр вилучення розбирає документ на речення, виділяє сутності та зв'язки між ними, після чого нормалізація сутностей зводить варіанти написання до одного вузла: «ТОВ Ромашка», «Ромашка» і друкарська помилка з латинською літерою стають одним записом з історією джерел.

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

Повнота вилучення залежить не від моделі, а від схеми зв'язків: ми фіксуємо типи відношень заздалегідь (постачальник, власник, філія, конфлікт) і проганяємо корпус двома незалежними проходами.

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

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

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

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

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

Практичний ефект: корпус у десятки тисяч документів обробляється за одну ніч замість тижнів ручної розмітки, частка зв'язків з підтвердженим джерелом сягає 0,9 на контрольній вибірці, а клас помилок «різні написання однієї сутності» зникає на етапі нормалізації, а не спливає у звітах.

Способи побудови: порівняння підходів та обмеження

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

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

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

Жоден із варіантів не дає готового графа «з коробки» — обмеження методів знімаються тільки їхнім поєднанням. Тому на старті ми фіксуємо схему відношень, збираємо еталонну розмітку на 200–300 фрагментах і за нею обираємо, де достатньо правил, а де потрібна модель.

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

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

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

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

2. Проєктування схеми зв'язків. Узгоджуємо перелік типів сутностей і типів зв'язків, обмеження та правила успадкування, спірні випадки розбираємо з вашими аналітиками.

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

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

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

5. Перевірка на реальних запитах. Проганяємо типові питання ваших фахівців і звіряємо шляхи в графі з тим, як їх будує людина. Це ловить розриви зв'язків, яких метрики на вибірці не бачать.

6. Передача рішення. Віддаємо схему зв'язків, словники, правила, скрипти перезбирання графа і регламент оновлення; проводимо розбір із вашою командою, щоб граф можна було розширювати без нас.

Що передаємо на руки: артефакти та регламенти супроводу

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

Схема, словники, права та регламенти лежать у вашому репозиторії з контролем версій — їх можна читати, правити й передавати новим інженерам.

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

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

Кейс: граф знань за архівом технічної документації

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

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

Ми зібрали конвеєр: розмітка структури документів, вилучення сутностей і відношень, нормалізація термінів (один вузол під п'ятьма написаннями — один запис), вибіркова перевірка людиною.

Зв'язки лягли в графову базу Neo4j — обхід на 3-5 переходів перестав бути ручним збиранням і виконується запитом.

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

Окремо про валідацію: автоматику ми не вважали істиною в останній інстанції.

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

Чим відрізняється вилучення зв'язків від розмітки сутностей?

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

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

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

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

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

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

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

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

Технічні сумніви: якість, обсяг і супровід

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

Як граф позбавляється дублів?

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

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

Чи доведеться відмовлятися від своєї онтології?

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

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

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

Повне перезбирання потрібне лише при зміні схеми — іде з перевіркою на еталонній вибірці, щоб метрики не просіли.

Обговоримо задачу: що потрібно для старту робіт

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

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

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

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

Опишіть задачу і додайте приклади документів — повернемося з розрахунком термінів, етапами та складом перевірок на пілоті.