Моніторинг якості даних з AI: 5 перевірок, що ловлять 90% поломок

Коли COO логістичної компанії на 200 людей зателефонувала про pricing-рішення, яке виявилось базованим на джойні, що тихо двоїв замовлення шість тижнів, я запитав, який моніторинг даних у них стоїть. Її відповідь чесна: "Ми припускали, що warehouse правильний". Це припущення коштує SMB більше, ніж усі інші помилки даних разом.

Чому SMB-пайплайни падають тихо?

Бо ніхто за ними не платить дивитися. Пайплайн зробили, він шипить у дашборд, далі — без нагляду. Коли upstream змінюється (vendor перейменував поле, webhook дропнув колонку, API rate-limit) — пайплайн не падає. Він просто доставляє неправильні числа, і дашборд тихо бреше.

Визначення: Silent failure — результат пайплайна, де consumer'и отримують правдоподібні, але матеріально неправильні дані без жодної помилки.

Silent failures — найдорожчі, бо розмивають довіру повільно. Поки хтось помітить — тижні рішень посилаються на неправильні числа. Recovery — це не "перезапусти пайплайн", це "аудит кожного рішення з останнього known-good дня".

Які пʼять перевірок потрібні кожному SMB-пайплайну?

Ці пʼять generic перевірок після кожного завантаження ловлять ~90% поломок у SMB-масштабі. Жодна не вимагає спеціаліста; усі пʼять — SQL.

1. Volume check

Сьогоднішня кількість рядків у розумних межах проти trailing baseline? Імплементація: row count сьогодні vs 4-тижнева DoW-matched медіана, алерт якщо за межами ±40%.

Volume ловить найбільшу категорію — feed напівдійшов, webhook дропнув, backfill пробіг двічі. Найдешевша перевірка для написання, найкорисніша у роботі.

2. Freshness check

Останній рядок достатньо свіжий? Імплементація: max(timestamp) у таблиці vs поточний час, алерт якщо старіший за SLA (напр. 2 години для hourly, 26 годин для daily).

Визначення: Freshness SLA — максимально допустимий лаг між подією в source і моментом, коли подію можна запитати в warehouse.

Freshness ловить застряглі пайплайни, що не дають помилки, але перестали доставляти нові дані. Шокуюче під-імплементована: команди припускають, що "немає помилки" = "дані свіжі", що майже ніколи не правда.

3. Schema check

Колонки і типи змінилися проти вчора? Імплементація: snapshot schema після кожного завантаження, diff проти вчорашнього, алерт на будь-яку додану/видалену/перетипізовану колонку.

Schema drift — тихий вбивця дашбордів. Vendor перейменує client_name у customer_name, ваш JOIN тихо null'иться. Schema-check ловить це у день 1, не у наступному квартальному review.

4. Distribution check

Форма даних зрушила? Імплементація: відстежуйте distribution кількох ключових категоріальних і числових полів (categories: counts per value; numeric: median + IQR) day over day. Алерт на зрушення вище порогу.

Це перевірка, що ловить "vendor змінив семантику поля без попередження" — коли status означав одне, а тепер інше. Volume проходить; freshness проходить; дані просто неправильні по-новому.

5. Uniqueness check

Primary-key поля все ще унікальні? Імплементація: count(*) vs count(distinct primary_key), алерт якщо розходяться.

Дублікати — причина кожного silent double-counting бага. Прокрадаються коли upstream-системи ретраять, коли JOIN ненавмисно many-to-many, коли backfill гоняє паралельно з live. Uniqueness — найдешевша страховка від найдорожчого класу багів.

Шаблон визначення перевірки

Пайплайн: [назва]
Частота: [hourly / daily]
Власник: [команда / людина]

Перевірки (після кожного завантаження):
1. Volume: row count у ±40% від 4-тижневої DoW-matched медіани?
2. Freshness: max(timestamp) у межах SLA [N годин]?
3. Schema: колонки і типи без змін проти вчорашнього snapshot?
4. Distribution:
   - [поле A]: top-5 value share у ±10pp від baseline?
   - [поле B]: median + IQR у ±20% від baseline?
5. Uniqueness: count(*) = count(distinct primary_key)?

Маршрутизація failure:
- Volume / Freshness / Schema fail → пейдж власника пайплайна
- Distribution / Uniqueness fail → notify власника + #data-quality канал

Розділення маршрутизації важливе. Volume/freshness/schema — зазвичай upstream-проблеми, пейджити. Distribution/uniqueness — часто semantic, потрібна людська розмова, не пейдж о 3 ранку.

Де AI вписується?

У трьох конкретних місцях, не у володінні детекцією.

1. Пропозиція порогів. Дайте AI 6 тижнів метрики і попросіть розумні volume/distribution діапазони. Перша чернетка зазвичай у межах 20% від людської — достатньо близько, щоб шипнути і тюнити.
2. Пояснення аномалії. Коли перевірка падає, згодуйте її + recent operational context (deploys, vendor-анонси, holidays) LLM і запитайте "найімовірніша причина?" — це суттєво ріже triage-час.
3. Plain-language alert summaries. Перетворіть distribution check failed on status field: enterprise share dropped from 18% to 4% на "Enterprise tier signups, схоже, різко впали з учора — імовірно зміна upstream фільтра".

Tool tip (AIAdvisoryBoard.me): Data quality checks найкорисніші, коли failures маршрутизуються у той самий Plan → Fact → Gap loop, який команда вже використовує для операційних метрик. Провалена freshness-перевірка на revenue-feed — це Gap на кожну метрику нижче за течією, і назвати це Gap'ом — змусити accountability. Наша операційна система робить цю маршрутизацію автоматично, тож зламаний пайплайн видно як Gap у ранковому огляді засновника, не як алерт, який ніхто не читає. 7-денна діагностика показує, які з ваших пайплайнів мають найбільший blast radius. На https://aiadvisoryboard.me/?lang=en.

Manager scan (2-хвилинний digest)

• Кожен пайплайн має пʼять generic перевірок до того, як виходить у прод
• Volume / freshness / schema падіння — пейдж власника; distribution / uniqueness — notify
• Пороги — AI-перша чернетка з 6 тижнів історії, тюнінг місячний
• Пайплайн без власника — на павзі; orphan-фіди не живуть у проді
• Schema snapshot щодня — recovery з drift — це grep, не археологія
• Distribution охоплює не більше 3-5 полів на таблицю — ширше це шум
• Провалені перевірки чіпляються до downstream-метрик у дашборді
• Alert summaries — AI переписує у звичайну мову, не сирий SQL-output
• Місячно: які перевірки стріляли, які реальні, які затюнили геть
• Квартально: будь-який пайплайн із нулем падінь весь квартал — або ідеальний, або не моніториться, перевірити

Micro-case (що змінюється за 7-14 днів)

Ecommerce SMB на 130 людей мала 14 пайплайнів і нуль моніторингу якості, окрім "did cron exit zero". Підʼєднали пʼять перевірок до всіх 14, AI намалював перші пороги з 6 тижнів історії, налаштували page/notify розділення. У перший тиждень система спіймала три проблеми, що тихо псували downstream метрики: vendor webhook доставляв ~30% менше подій із TLS-зміни два тижні тому (freshness + volume); marketing-attribution пайплайн дев'ять днів двоїв campaign source через JOIN-зміну (uniqueness); customer status field зрушив distribution після CRM-апдейту, про який нікому не сказали (distribution). Усі три тривали б тижні без перевірок. Реакція засновника наприкінці тижня 2 показова: "Ми не йшли наосліп, ми йшли по брехні, і не знали".

Note on this case: Приклад ілюстративний — на основі типових патернів у компаніях 30-500 людей, не конкретний клієнт. Числа — округлені діапазони, не гарантії.

Tool tip (AIAdvisoryBoard.me): Робота над якістю даних зазвичай застрягає в SMB бо ніхто не звʼязує її з бізнес-наслідком. Провалена перевірка йде як "engineering issue", дашборд продовжує брехати. Наша операційна система показує data quality failures як Gap-items на постраждалих бізнес-метриках — тож "наш пайплайн зламався" стає "ми недорахували revenue минулого тижня", і розмова міняється. Старт 7-денної діагностики на https://aiadvisoryboard.me/?lang=en.

FAQ

Хіба не потрібен інструмент типу Monte Carlo? Може, з часом — і лише на масштабі. Для 30-500-людної SMB пʼять перевірок вище імплементуються у SQL + scheduler за день. Купуючи інструмент до того, як маєте дисципліну, ви купуєте дорожчі сліпі плями.

А якість на рівні рядка (per-record)? Це інший шар — належить ingestion-коду, не моніторингу. Пʼять перевірок тут — на рівні таблиці; per-row — раніше. Не плутайте.

Мій пайплайн перезавантажує всю таблицю щоночі. Перевірки все одно? Так — особливо. Full reloads найсхильніші до silent volume drops бо немає incremental delta. Volume + uniqueness — найкраща протекція.

Як заbaseline'ити новий пайплайн? Запустіть у shadow mode 2-3 тижні, зберіть baseline, потім AI намалює пороги з цього вікна. Не пробуйте baseline'ити з дня 1; ловитимете шум.

Як це повʼязано з anomaly detection на бізнес-метриках? Перевірки якості захищають визначення метрики; anomaly detection захищає значення. Потрібні обидва в цьому порядку — якщо якість зламана, детекція на зламаній метриці безглузда.

Висновок

Моніторинг якості даних у SMB — не покупка платформи. Це пʼять generic перевірок після кожного завантаження, AI допомагає з порогами і plain-language summaries, дисципліна маршрутизації відрізняє пейджі від notify.

Виберіть пайплайн із найбільшим blast radius першим. Підʼєднайте пʼять перевірок. Тюньте два тижні. Додавайте наступний.

Якщо хочете систему, що автоматично показує Plan → Fact → Gap — включно з Gap, коли пайплайн вам бреше — дивіться, як працює 7-денна діагностика на https://aiadvisoryboard.me/?lang=en.