Моніторинг якості даних на виробництві

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