Останні звіти щодо рівня невдач проєктів зі штучним інтелектом (ШІ) порушують незручні питання для організацій, які активно інвестують у цю галузь. Значна частина дискусій зосереджена на технічних факторах, таких як точність моделей та якість даних. Однак, спостерігаючи за запуском десятків ініціатив у сфері ШІ, я помітив, що найсуттєвіші можливості для вдосконалення часто криються у культурних, а не технічних аспектах.
Внутрішні проєкти, які стикаються з труднощами, як правило, мають спільні проблеми. Наприклад, інженерні команди створюють моделі, якими менеджери продуктів не знають, як користуватися. Науковці з даних розробляють прототипи, які команди з експлуатації важко підтримувати. А застосунки ШІ залишаються невикористаними, тому що люди, для яких вони створювалися, не брали участі у визначенні того, що насправді означає “корисний”.
На противагу цьому, організації, які досягають значної цінності завдяки ШІ, зуміли налагодити належний рівень співпраці між відділами та встановили спільну відповідальність за результати. Технології мають значення, але готовність організації є не менш важливою.
Ось три практики, які, на мою думку, допомагають подолати культурні та організаційні бар’єри, що можуть перешкоджати успіху ШІ.
Розширюйте ШІ-грамотність за межі інженерії
Коли лише інженери розуміють, як працює система ШІ та на що вона здатна, співпраця руйнується. Менеджери продуктів не можуть оцінювати компроміси, яких не розуміють. Дизайнери не можуть створювати інтерфейси для можливостей, які вони не можуть чітко сформулювати. Аналітики не можуть перевіряти результати, які вони не можуть інтерпретувати.
Рішення полягає не в тому, щоб зробити всіх вченими з даних. Це допомога кожній ролі зрозуміти, як ШІ застосовується до їхньої конкретної роботи. Менеджери продуктів повинні розуміти, який тип згенерованого контенту, прогнози чи рекомендації є реалістичними, враховуючи наявні дані. Дизайнери повинні розуміти, що саме може робити ШІ, щоб вони могли проєктувати функції, які користувачі вважатимуть корисними. Аналітики повинні знати, які результати ШІ потребують людської перевірки, а яким можна довіряти.
Коли команди мають цей спільний робочий словниковий запас, ШІ перестає бути чимось, що відбувається у відділі інженерії, і стає інструментом, який може ефективно використовувати вся організація.
Встановіть чіткі правила автономії ШІ
Другий виклик полягає у визначенні того, де ШІ може діяти самостійно, а де потрібне схвалення людини. Багато організацій вдаються до крайнощів: або створюють вузьке горлечко для кожного рішення ШІ через людський огляд, або дозволяють системам ШІ працювати без запобіжників.
Необхідна чітка структура, яка визначає, де і як ШІ може діяти автономно. Це означає встановлення правил заздалегідь: чи може ШІ затверджувати рутинні зміни конфігурації? Чи може він рекомендувати оновлення схеми, але не впроваджувати їх? Чи може він розгортати код у середовищах тестування, але не у виробничих?
Ці правила повинні включати три елементи: аудитованість (чи можете ви відстежити, як ШІ дійшов свого рішення?), відтворюваність (чи можете ви відтворити шлях прийняття рішення?) та спостережуваність (чи можуть команди моніторити поведінку ШІ в реальному часі?). Без цієї структури ви або сповільнюєтеся до такої міри, що ШІ не дає переваги, або створюєте системи, які приймають рішення, які ніхто не може пояснити чи контролювати.
Створюйте міжфункціональні плейбуки
Третій крок – це кодифікація того, як різні команди фактично працюють із системами ШІ. Коли кожен відділ розробляє власний підхід, ви отримуєте неузгоджені результати та дублювання зусиль.
Міжфункціональні плейбуки працюють найкраще, коли команди розробляють їх спільно, а не нав’язують зверху. Ці плейбуки відповідають на конкретні запитання, такі як: Як ми тестуємо рекомендації ШІ перед виведенням їх у виробництво? Яка наша процедура резервного копіювання, коли автоматичне розгортання зазнає невдачі – чи передає воно завдання операторам-людям, чи спочатку пробує інший підхід? Хто повинен бути залучений, коли ми скасовуємо рішення ШІ? Як ми враховуємо зворотний зв’язок для покращення системи?
Мета – не додавати бюрократії. Це забезпечення того, щоб кожен розумів, як ШІ вписується в їхню поточну роботу, і що робити, коли результати не відповідають очікуванням.
Рухаємося вперед
Технічна досконалість у сфері ШІ залишається важливою, але підприємства, які надмірно зосереджуються на продуктивності моделей, ігноруючи організаційні фактори, наражають себе на уникнені труднощі. Успішні впровадження ШІ, які я бачив, ставляться до культурних перетворень та робочих процесів так само серйозно, як і до технічної реалізації.
Питання не в тому, чи достатньо витончена ваша технологія ШІ. Питання в тому, чи готова ваша організація з нею працювати.
Аді Полак є директором з адвокації та досвіду розробників у Confluent.
Ласкаво просимо до спільноти VentureBeat!
Наша програма гостьових публікацій дозволяє технічним експертам ділитися своїми знаннями та надавати нейтральні, незацікавлені глибокі аналізи ШІ, інфраструктури даних, кібербезпеки та інших передових технологій, що формують майбутнє підприємств.
Читайте більше з нашої програми гостьових публікацій – і ознайомтеся з нашими рекомендаціями, якщо ви зацікавлені у внесенні власної статті!
Прогноз ІТ-Блогу: Очікується, що компанії, які зможуть ефективно інтегрувати культурні зміни з технічними аспектами ШІ, отримають значну конкурентну перевагу. У майбутньому ми побачимо зростання попиту на ШІ-тренерів та консультантів, які допоможуть організаціям подолати саме ці культурні бар’єри.
Подробиці можна знайти на сайті: venturebeat.com