Ваш AI чатбот не зламаний. Зламаний ваш конвеєр даних.

Ключові моменти

• Більшість корпоративних пілотних проектів AI зупиняються до запуску, а проблеми якості даних в базовому конвеєрі частіше є причиною, ніж обмеження моделі.
• Система RAG, яка означає retrieval-augmented generation і передбачає програмне забезпечення, яке вводить реальні бізнес-дані у відповіді AI-моделі, не може самостійно виправити зламані або суперечливі вихідні дані.
• Передача невідновленої інформації в векторну базу даних — тип індексу, який AI-системи використовують для пошуку — прямо вносить ці погані дані у відповіді AI.
• Заходи безпеки мають бути вбудовані в саму інфраструктуру даних, а не передані AI-моделі через письмові інструкції.
• Інженери даних стверджують, що дисципліна побудови надійних конвеєрів даних тепер така ж важлива, як вибір AI-моделі.

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

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

Висловлюючись у VentureBeat, Айала стверджує, що модель майже ніколи не є корінною причиною. Проблема в даних, які передаються в неї. Він називає цю схему «Пасткою очищення»: помилкове переконання, що ви можете залити безладні, суперечливі, погано організовані бізнес-дані в AI-систему і очікувати, що AI це впорядкує.

Так не працює.

Чому AI не може просто сама виправити дані?

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

Багато корпоративних AI-систем використовують установку RAG. Простими словами: коли ви ставите AI запитання, вона спочатку шукає великий індекс ваших власних документів та записів компанії, витягує релевантні частини та використовує їх для формування своєї відповіді. Цей індекс називається векторною базою даних.

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

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

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

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

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

На що слід звернути увагу, якщо ваша організація розгортає AI-інструменти:

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