ШІ не вирішить проблеми з даними: ключ – інженерія даних

Інвестиції в ШІ та проблема контексту

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

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

Чому контекст є критичним

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

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

Від аналітики до операційних рішень

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

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

Нова роль інженерів даних

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

Коли системи ШІ приймають операційні рішення, метою більше не є створення даних, які можна запитувати. Метою є створення контексту, достатньо надійного для дії системи, і це різні проблеми з різними вимогами. Це починається з розв'язання сутностей (entity resolution) між системами, забезпечуючи послідовну та надійну відповідь у кожному джерелі даних, яке їх торкається. Це також означає явну обробку даних, що надходять із запізненням, оскільки агенти не можуть діяти на основі стану світу, який більше не є актуальним. Пороги актуальності повинні бути відкалібровані до типу рішення, оскільки рекомендація персоналізації може толерувати дані про використання шестигодинної давності, тоді як робочий процес відшкодування — ні. Походження даних (lineage) має витримувати зміни схем та реорганізації, щоб можна було відстежити походження будь-якого фрагмента контексту, коли щось йде не так. Нічого з цього не є проблемою моделі, і це не вирішується за допомогою промпт-інженерії. Це робота інженерії даних, і організації, які розглядають це інакше, витрачатимуть багато часу на налагодження виробничих збоїв, які виглядають як проблеми ШІ, але є проблемами інфраструктури.

Координація та управління агентами

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

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

Майбутнє розгортання ШІ-агентів

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

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

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

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

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

Більшість інвестицій у ШІ зосереджені на моделях, обчисленнях та інструментах, але це часто призводить до невдач.
Моделі ШІ, навчені на публічних даних, не мають контексту внутрішніх корпоративних систем.
Ранні ініціативи ШІ стикаються з труднощами через відсутність внутрішнього контексту, а не через слабкість моделей.
Інженерія даних є ключем до надання ШІ необхідного контексту (історія клієнта, платіжні записи, дані про використання продукту).
На відміну від людей, ШІ-системи не мають судження і приймають тонко неправильні рішення на основі неповного або непослідовного контексту.