Чому охайні на вигляд дані все одно ламають ШІ: семантична неузгодженість

«Сміття на вході — сміття на виході» — одна з найзатертіших фраз у data science, і вона правдива: навчіть модель на поганих даних, і добрих результатів чекати не варто. Біда в тому, що фраза така звична, що затуляє підступніший випадок. А якщо дані не сміття? Якщо вони виглядають чистими? Колонки заповнені, формати валідні, явних дублікатів немає, пайплайн відпрацьовує, дашборди в нормі, перевірки якості даних проходять, а ШІ-система все одно ухвалює ненадійні рішення.

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

Чисті дані теж можуть вводити в оману

Візьмімо поле, яке в якомусь вигляді є в кожній компанії:

customer_status

У CRM його значення можуть означати ось що:

Active = Customer currently purchasing
Inactive = Customer hasn't purchased recently

Білінг читає ті самі слова інакше:

Active = Account is financially open
Inactive = Account is closed

А в підтримки третє прочитання:

Active = Customer currently has an open support relationship
Inactive = No active support case

У кожній системі можуть бути валідні значення, однакове форматування, повні записи й жодних видимих помилок, тож традиційна перевірка якості даних нічого не знайде. Але якщо об'єднати набори даних, не з'ясувавши, що означають слова, ШІ отримає три визначення «active». Дані не брудні. У них неузгоджена семантика, а її помітити значно важче.

Семантичний дрейф

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

System A:
Revenue = Invoiced amount

Ще дві системи розходяться:

System B:
Revenue = Collected amountSystem C:
Revenue = Contract value

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

Зміст змінюється з часом

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

customer_segment

З 2022 по 2024 рік значення такі:

Enterprise
Mid-Market
SMB

Потім бізнес змінює стратегію сегментації, і з 2025 року значення стають такими:

Strategic
Growth
Core

У базі досі одне поле, пайплайн досі працює, тип даних не змінився. Модель бачить приблизно це:

2022 → Enterprise
2023 → Enterprise
2024 → Enterprise
2025 → Strategic
2026 → Strategic

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

Структурна та семантична узгодженість

Їх легко сплутати, тож варто розмежувати.

Структурна узгодженість означає, що дані дотримуються очікуваних технічних правил:

customer_id → string
revenue → decimal
created_at → timestamp
status → allowed values

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

revenue

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

Чому звичайні перевірки цього не бачать

Більшість пайплайнів добре ловлять технічні збої:

NULL values
Duplicate rows
Invalid data types
Missing columns
Unexpected formats
Broken joins
Out-of-range values

Ці перевірки корисні. Але уявіть таблицю з клієнтами 101, 102 і 103, усі з позначкою Active, з виручкою 50000, 72000 і 31000. Усе виглядає розумно. А тепер припустімо, що Active у системі A означає клієнта, який купує, у системі B — фінансово відкритий рахунок, а в системі C — клієнта, якого зараз обслуговує підтримка. Стандартне правило валідації все одно пройде, бо невалідні не значення. Невалідний їхній зміст.

ШІ робить усе гіршим

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

if customer_status == "Active":
    allow_action()

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

Historical Data
      ↓
Different Business Definitions
      ↓
Combined Dataset
      ↓
Model Training
      ↓
Learned Relationships
      ↓
Predictions

Модель не обов'язково знає, яке визначення головне. Вона вчиться на тому, що їй дали.

RAG хворіє на те саме

Це стосується не лише класичного ML. Уявіть три документи компанії. У довіднику з продажів сказано, що кваліфікований лід — це потенційний клієнт, який відповідає критеріям BANT. У документації маркетингу — що кваліфікований лід взаємодіяв щонайменше з трьома кампаніями. У документації CRM — що це лід, якого менеджер із продажів вручну позначив як кваліфікованого.

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

Проблеми, які не схожі на поломки

Тому «сміття на вході — сміття на виході» надто спрощує справу для сучасного ШІ. Сміття очевидне, а неузгодженість може бути невидимою. Кілька її форм:

Одна назва з різними змістами. Ця мітка:

"Revenue"

може бути виставленою в рахунках виручкою в одній системі й отриманою виручкою в іншій.

Одне значення в різних контекстах. Ось це:

"Active"

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

Одна метрика, порахована по-різному. Ось ця:

"Churn"

може рахуватися однією командою щомісяця, а іншою — за рік.

Одна часова мітка в різних часових поясах. Це значення:

2026-08-20 10:00

може бути місцевим часом в одній системі й UTC в іншій.

Один клієнт під різними ідентифікаторами:

Customer ID: 10482
Account ID: C10482
External ID: 10482-IN

Жоден із цих записів не обов'язково поганий. Це неузгоджені подання бізнес-реальності.

Поставте інше запитання

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

Напишіть семантичний контракт

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

Field:
customer_status

Потім запишіть його зміст і допустимі значення:

Business Definition:
Current commercial relationship with the customer.Allowed Values:
active
inactive
prospectOwner:
Customer OperationsSource of Truth:
CRMEffective From:
2026-01-01Rules:
"active" requires an active commercial relationship.
"prospect" cannot have completed customer status.

Тепер ШІ-системи нижче за потоком мають явну опору. Якщо інша система використовує ось таке визначення:

active = account has an open invoice

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

Ставтеся до визначень як до API

Інженери й так знають ціну контрактів між системами. Коли API обіцяє ось це:

{
  "customer_id": "string",
  "status": "active | inactive"
}

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

Field
↓
Type
↓
Allowed Values
↓
Business Meaning
↓
Owner
↓
Source of Truth
↓
Effective Date
↓
Change History

Так семантичні припущення стають видимими, а видимі припущення простіше перевіряти.

Додайте до пайплайну перевірки змісту

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

Incoming Data
      ↓
Schema Validation
      ↓
Data Quality Checks
      ↓
Semantic Validation
      ↓
Business Rule Validation
      ↓
AI Readiness Check
      ↓
Model / RAG Pipeline

Валідація схеми ловить «колонка зникла». Семантична валідація ловить «колонка на місці, але її бізнес-зміст змінився». Це дуже різні класи проблем.

Моніторте визначення, а не лише значення

Припустімо, пайплайн відстежує середній чек, і дашборд показує:

Average Order Value
₹4,850

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

Агенти відчувають це сильніше

ШІ-агенти дедалі частіше працюють одразу з кількома інструментами й джерелами даних:

Agent
 ├── CRM
 ├── Billing
 ├── Analytics
 ├── Knowledge Base
 └── Support System

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

CRM:
Customer = Active

А білінг і підтримка повідомляють інше:

Billing:
Account = DelinquentSupport:
Relationship = Closed

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

Словник даних має працювати

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

Definition
    ↓
Data Contract
    ↓
Validation Rule
    ↓
Pipeline Check
    ↓
AI Readiness

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

Що перевіряти

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

1. Структурну: чи узгоджені поля й типи?
2. Узгодженість значень: чи подано значення однаково?
3. Семантичну: чи означає поле те саме всюди?
4. Часову: чи змінювалося визначення з часом?
5. Міжсистемну: чи сходяться різні системи щодо базової бізнес-сутності або метрики?

Це дає реалістичнішу картину якості даних.

Точніша ментальна модель

Звична картина така:

Bad Data → Bad AI

Точніша містить додатковий крок:

Bad Data
    ↓
Inconsistent Data
    ↓
Ambiguous Business Meaning
    ↓
Unreliable AI Context
    ↓
Unreliable AI Output

А іноді шлях виглядає так:

Clean-looking Data
        ↓
Hidden Semantic Differences
        ↓
Model Learns False Relationships
        ↓
Production Reliability Degrades

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

Іноді найважче — домовитися

Є незручна можливість: в організації може взагалі не бути проблеми з даними, а бути проблема з визначеннями. Фінанси визначають клієнта так, продажі — інакше, маркетинг — по-третьому, а в операційного відділу своє тлумачення. Кожен певен, що його версія правильна, і від ШІ чекають, що він їх примирить. Він не може — принаймні надійно — без явних бізнес-правил. Перш ніж питати, як очистити дані, корисніше буває спитати, чи може бізнес домовитися про те, що ці дані означають.

Подивіться до моделі

Коли ШІ-система видає ненадійні результати, перший порив — звинуватити модель: перевірити промпт, змінити модель, підкрутити параметри, додати пошук, збільшити контекст. Іноді модель просто вчиться на неузгодженій картині бізнесу. Жоден апгрейд не розв'яже проблему невизначеного бізнес-поняття. Якщо три системи не згодні, що таке активний клієнт, потужніша модель цієї прогалини в управлінні не закриє. Вона лише дасть переконливішу відповідь на двозначне питання.

Підсумок

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