Чому ШІ помиляється впевнено? Проблема в інженерії даних

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

Прихована природа помилок

Проблема полягає в тому, що збій є невидимим за своєю суттю. ШІ-додаток не розрізняє, чи отримує він дані з векторного сховища, індексу документів або API-виклику. Жоден стандартний конвеєр отримання даних не перевіряє, чи є те, що він надає, все ще коректним. Застарілий документ з цінами буде отриманий так само впевнено, як і актуальний, оскільки система оцінює релевантність або доступність, а не коректність. Запис з відсутнім полем проходить так само чисто, як і повний. Таким чином, застарілі або неповні дані все ще отримують високі оцінки релевантності. Модель відповідає з повною впевненістю, оскільки отриманий контекст виглядає авторитетним. Панелі моніторингу залишаються "зеленими", створюючи ілюзію працездатності системи, хоча вона надає невірні дані.

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

Чому це проблема інженерії даних

Команди, які стикаються з цим збоєм, схильні неправильно його діагностувати. Перший інстинкт — звинувачувати модель, спробувати іншу велику мовну модель (LLM) або налаштувати промпт. Однак справжня проблема лежить вище за течією, на рівні інженерії даних. Після виключення моделі, наступний інстинкт — звинувачувати рівень отримання даних або контексту та придбати краще рішення. Хоча такі рішення, як знанняві графи AWS або Horizon Context/Cortex Sense від Snowflake, є відповіддю на симптом, вони знаходяться на один рівень вище справжньої проблеми, оскільки знаннявий граф все ще залежить від того, що його живить. Справжня проблема полягає в тому, що команди перевіряють, чи виконалося завдання, а не чи є дані, які воно перемістило, все ще правдивими. Моніторинг створюється для конвеєра, а не для даних.

Рішення: Спостережуваність даних

Відсутнім елементом є спостережуваність даних (Data Observability) — добре відома концепція, яка не отримує достатньої уваги у своїй реалізації. Важливою метрикою є не відсоток, а покриття: яка частка критичних наборів даних має відстежувану лінію походження, а не лише ту, що існує в голові когось. Спостережуваність даних охоплює чотири виміри:

Коректність: Чи відповідає кожен запис своїй формі та правилам (типи полів, відсутність неочікуваних нульових значень, значення в діапазоні).
Свіжість: Чи є дані актуальними відносно свого джерела, а не лише станом на останню перевірку.
Узгодженість: Чи одні й ті ж факти читаються однаково скрізь, де вони зберігаються або індексуються.
Лінія походження (Lineage): Можливість відстежити будь-який вихід до його джерела та всіх перетворень, через які він пройшов.

Приклади з індустрії

Uber створив спеціалізовану платформу якості та спостережуваності даних задовго до появи генерації з доповненим отриманням (RAG). Їхня платформа Unified Data Quality підтримує понад 2000 критичних наборів даних і виявляє близько 90% інцидентів якості даних до того, як вони досягнуть кінцевих споживачів. Netflix вирішив іншу частину тієї ж проблеми, побудувавши загальнокорпоративну систему лінії походження даних, щоб будь-хто міг відповісти, звідки походить набір даних і що його торкалося. Ця платформа стала ще важливішою з розвитком ШІ/LLM-додатків. Наприклад, у Socure було побудовано систему, яка ідентифікувала некоректні дані клієнтів до їхнього поширення. Вона включала перевірку схеми та діапазону при прийомі, угоди про рівень обслуговування (SLA) для свіжості, міжсистемні перевірки узгодженості та лінію походження на рівні файлів. Це призвело до підвищення точності у звітності, моделях машинного навчання та ШІ-отриманні даних.

Що робити

Якщо ви використовуєте ШІ-системи на основі отримання даних у виробництві, діагностичне питання не полягає в тому, яку модель спробувати далі або на яку архітектуру отримання даних мігрувати. Замість цього, варто поставити чотири конкретні питання:

Чи перевіряються базові дані відповідно до стандартів, необхідних їхнім споживачам?
Який найстаріший фрагмент контенту зараз надається з високою впевненістю?
Чи можуть два фрагменти з одного джерела коли-небудь суперечити один одному в одному результаті отримання?
Чи можете ви відстежити, звідки він походить, якщо виявиться, що він невірний?

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

Висновок

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

Що це означає для розробників

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

Ключові факти

ШІ-агенти можуть надавати "впевнено невірні" відповіді через застарілі або неповні дані, а не через проблеми з моделлю чи промптами.
Стандартні конвеєри отримання даних перевіряють релевантність, а не коректність, роблячи збої невидимими.
Справжня проблема лежить на рівні інженерії даних, де моніторинг зосереджений на конвеєрі, а не на якості самих даних.
Рішенням є спостережуваність даних, що охоплює коректність, свіжість, узгодженість та лінію походження даних.
Компанії, такі як Uber та Netflix, вже впровадили платформи для якості та лінії походження даних, що є критичним для надійності ШІ-систем.