Пошук дублікатів за допомогою машинного навчання

Data Quality / Machine Learning / Master Data Management

Чому традиційних правил перевірки корпоративних даних уже недостатньо

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

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

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

Наприклад, система може перевірити, чи заповнено код контрагента, чи відповідає дата встановленому формату, чи існує товар у корпоративному довіднику.

Такі перевірки залишаються необхідними.

Проте вони мають обмеження.

Уявімо, що в CRM зберігаються записи:

• ТОВ «Альфа Трейд»
• «Альфа-Трейд», товариство з обмеженою відповідальністю
• Alfa Trade LLC
• Альфа Трейд, Київ

Чи описують вони одну юридичну особу?

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

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

Однак машинне навчання не повинно повністю замінювати формальні правила якості.

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

Data Quality як постійний процес

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

Наприклад, підприємство готується перейти на нову ERP.

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

Причина полягає в тому, що проблему вирішували лише на рівні наявного набору даних, не змінивши процес їх створення.

Тому Data Quality повинно бути частиною постійного управління корпоративною інформацією.

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

Основні характеристики якості

Математичні моделі можуть допомагати оцінювати деякі з цих характеристик. Проте не всі вимоги можна достовірно вивести з історичних даних.

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

Від звичайного Matching до машинного навчання

Пошук дубльованих записів — один із найбільш практичних напрямів використання машинного навчання в Data Quality.

У традиційному MDM застосовуються детерміновані та ймовірнісні методи зіставлення.

Детерміноване зіставлення

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

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

Нечітке порівняння

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

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

Jaro-Winkler орієнтований на оцінювання схожості текстових значень і може бути корисним для імен та назв.

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

Наприклад, назви двох різних компаній можуть бути майже однаковими.

Машинне навчання

Замість одного фіксованого правила можна сформувати набір характеристик пари записів.

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

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

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

Як побудувати модель пошуку дублікатів

Розглянемо умовний корпоративний реєстр контрагентів, який містить записи з ERP і CRM.

Підприємство хоче автоматично знаходити можливі дублікати.

Перший етап: нормалізація

Назви приводяться до єдиного регістру.

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

Наприклад, «ТОВ» і «Товариство з обмеженою відповідальністю» можуть бути зіставлені за відповідним словником. Проте не можна безконтрольно видаляти всі юридичні позначення.

У деяких випадках вони допомагають відрізняти різні організації.

Другий етап: формування кандидатів

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

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

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

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

Третій етап: формування ознак

Для кожної пари розраховуються числові характеристики.

Наприклад:

Ці значення використовуються як вхідні характеристики для моделі.

Четвертий етап: навчання

Для навчання можуть використовуватися логістична регресія, дерева рішень або Random Forest.

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

П’ятий етап: перевірка

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

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

Шостий етап: застосування

Модель може розподіляти пари на три категорії:

• висока впевненість у збігу;
• неоднозначний випадок для Data Steward;
• низька ймовірність збігу.

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

Чому Precision і Recall важливіші за загальну Accuracy

Для задачі пошуку дублікатів загальна точність класифікації може вводити в оману.

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

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

Тому доцільно використовувати Precision та Recall.

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

Recall характеризує, яку частку фактичних дублікатів виявлено.

Для корпоративного MDM особливо важливе правильне співвідношення цих показників.

Наприклад, якщо автоматичне об’єднання може вплинути на договори та фінансову історію, підприємство може вимагати дуже високого Precision.

Натомість для формування списку потенційних дублікатів на ручну перевірку доцільно прагнути вищого Recall.

Важливо, щоб тестовий набір відображав реальні труднощі, а не складався переважно з очевидно різних записів.

scikit-learn 0.19: інструменти для виявлення аномалій

12 серпня 2017 року було представлено scikit-learn 0.19.

Серед нововведень — LocalOutlierFactor для виявлення аномалій, QuantileTransformer, а також розширені можливості оцінювання моделей. У жовтні вже стала доступною коригувальна версія 0.19.1.

Для Data Quality особливо цікавим є Local Outlier Factor (LOF).

Алгоритм оцінює, наскільки об’єкт відрізняється за локальною щільністю від сусідніх записів.

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

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

Велика закупівля може бути пов’язана з реальним виробничим проєктом.

Тому такі результати повинні використовуватися як сигнал для перевірки.

Приклад Python

Для умовного числового набору можна застосувати:

from sklearn.neighbors import LocalOutlierFactor
from sklearn.preprocessing import StandardScaler

# X містить підготовлені числові ознаки.
X_scaled = StandardScaler().fit_transform(X)
model = LocalOutlierFactor(n_neighbors=20, contamination=0.02)
labels = model.fit_predict(X_scaled)

Цей приклад відповідає основному API scikit-learn 0.19.

Він демонструє виявлення аномалій усередині аналізованого набору. Необхідно враховувати, що в цій версії LocalOutlierFactor не слід описувати як універсальний готовий інструмент оцінювання довільних нових записів за пізнішим API novelty=True.

Для потокової перевірки нових операцій може знадобитися інший алгоритм або спеціально організоване перенавчання.

Також значення contamination=0.02 у прикладі є умовним параметром, а не твердженням, що 2% корпоративних записів обов’язково містять помилки.

Які помилки можна шукати статистичними методами

Машинне навчання може бути корисним для виявлення різних категорій нетипових записів.

Помилки одиниць виміру

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

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

Правильне значення потрібно підтвердити за первинними документами.

Невідповідність цін

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

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

Відхилення може бути наслідком реальної знижки або зміни ринку.

Неправильна класифікація товару

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

Наприклад, обладнання з певним набором ознак може бути помилково віднесене до категорії витратних матеріалів.

Нетипові комбінації атрибутів

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

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

Однак остаточна перевірка повинна ґрунтуватися на бізнесових правилах і документах.

Apache Spark MLlib для великих корпоративних реєстрів

Не всі задачі Data Quality можна ефективно виконувати на одному сервері.

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

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

11 липня 2017 року вийшла Apache Spark 2.2.0. Станом на листопад вона залишається актуальною гілкою 2.2: коригувальна Spark 2.2.1 з’явиться лише 1 грудня.

Spark MLlib містить алгоритми класифікації, регресії, кластеризації та інші засоби машинного навчання.

Для побудови процедур можуть застосовуватися DataFrame API і ML Pipelines.

Розподілена підготовка ознак

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

Після цього розраховуються числові ознаки.

Навчання моделі

Для підтримуваних алгоритмів навчання може виконуватися з використанням ресурсів кластера.

Обмеження

Spark не усуває складності задачі пошуку дублікатів.

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

Тому Blocking та інші способи скорочення кількості кандидатів залишаються необхідними. Крім того, не кожен алгоритм, доступний у scikit-learn, має безпосередній еквівалент у MLlib.

Тому вибір платформи повинен визначатися конкретним завданням.

TensorFlow 1.4 і перспективи складних моделей

7 листопада 2017 року Google оголосила про вихід TensorFlow 1.4.

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

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

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

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

Важливо також враховувати потребу в навчальних прикладах і ресурсах для обчислень.

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

Informatica та розвиток інтелектуального управління даними

У 2017 році постачальники корпоративних платформ розширюють використання машинного навчання у сфері Data Management.

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

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

Для MDM і Data Quality залишаються необхідними затверджені правила, Data Stewardship і контроль результатів.

Тому інтелектуальні можливості слід розглядати як засоби підвищення ефективності роботи відповідальних спеціалістів.

Як включити модель у процес Data Quality

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

Наприклад, під час реєстрації нового контрагента система може виконувати кілька етапів.

• Новий запис із ERP або CRM
• Перевірка обов’язкових реквізитів
• Нормалізація та пошук кандидатів
• Оцінка схожості ML-моделлю
• Автоматичне рішення або Data Steward
• Затвердження корпоративного запису
• Поширення через MDM та інтеграції

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

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

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

Feedback Loop: навчання на рішеннях Data Steward

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

Data Steward підтверджує частину та відхиляє решту. Ці рішення зберігаються як навчальні приклади.

Після накопичення достатньої кількості перевірених записів модель може бути перенавчена. Однак необхідно враховувати якість самих рішень.

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

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

Чому автоматичне виправлення небезпечніше за автоматичне виявлення

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

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

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

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

Для простих формальних помилок можуть використовуватися детерміновані правила. Для складних неоднозначних випадків — рекомендації моделі.

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

Практичний сценарій: очищення реєстру постачальників

Розглянемо умовний холдинг із чотирма дочірніми підприємствами. Кожне має окрему ERP й власний довідник постачальників.

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

Етап 1. Data Profiling

Команда аналізує структуру довідників, кількість пропусків і дубльованих ідентифікаторів.

Етап 2. Нормалізація

Назви, адреси й реєстраційні характеристики приводяться до визначених форматів.

Етап 3. Blocking

Формуються групи потенційно схожих постачальників.

Етап 4. Побудова моделі

На основі підтверджених прикладів навчається класифікатор відповідностей.

Етап 5. Незалежне тестування

Оцінюються Precision, Recall та помилки небезпечного об’єднання різних юридичних осіб.

Етап 6. Перевірка Data Steward

Неоднозначні пари передаються відповідальним спеціалістам.

Етап 7. Golden Record

Для підтверджених відповідностей MDM формує єдиний корпоративний ідентифікатор.

Етап 8. Інтеграція з DWH

Аналітичне сховище використовує узгоджені ключі для консолідації закупівель.

Етап 9. Моніторинг

Підприємство контролює появу нових дублікатів і зміни якості моделі.

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

Data Governance та відповідальність за інтелектуальні перевірки

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

Data Steward перевіряє складні випадки та підтверджує правильність рішень. Data Scientist розробляє й оцінює модель.

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

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

Також необхідно визначати процедуру виправлення помилкових об’єднань. Особливо якщо відповідні ідентифікатори вже поширені до кількох корпоративних систем.

Компетенції Intecracy Group в інтелектуальному Data Quality

Застосування Machine Learning для підвищення якості даних потребує поєднання спеціалізованих компетенцій. Data Management IG спеціалізується на ETL, MDM, Data Quality, DWH та корпоративній аналітиці. Ці напрями безпосередньо пов’язані з профілюванням даних, пошуком дублікатів, формуванням Golden Record і контролем результатів моделей.

IQusion IT працює у сферах системної інтеграції, електронного документообігу та BPM. Такі компетенції важливі для включення інтелектуальних перевірок до процесів створення й погодження корпоративних записів. SL Global Service спеціалізується на хмарній інтеграції, віртуалізації та гібридній інфраструктурі. Ці напрями можуть використовуватися для розміщення обчислювальних ресурсів і поєднання локальних та хмарних середовищ обробки.

При цьому правила якості й допустимі рівні автоматизації повинні затверджуватися підприємством.

Практичні орієнтири для впровадження

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

scikit-learn 0.19, Apache Spark MLlib і TensorFlow 1.4 надають різні технологічні інструменти для таких завдань. Проте статистична модель не є універсальним джерелом істини.

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

Для критичних записів необхідно зберігати Data Stewardship і затверджені правила MDM.

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