Йоав Наве, співзасновник і співгенеральний директор Reindeer, — серія інтерв’ю

Йоав Наве — співзасновник і співгенеральний директор Reindeer. Він має досвід створення технологічних компаній, масштабування бізнесу та інвестування в засновників. До Reindeer він створив ConvertMedia, продовжив роботу в Taboola та інвестував через INT3. Сьогодні він допомагає підприємствам перейти від ізольованого впровадження ШІ до агентів, здатних виконувати складні операційні завдання, навчатися на основі людського досвіду й залишатися надійними в міру змін бізнес-процесів.

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

Після створення ConvertMedia, масштабування бізнесу в Taboola та інвестування в інших засновників через INT3, яка проблема спонукала вас знову взятися за створення компанії та як вона вплинула на ваше рішення стати співзасновником Reindeer?

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

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

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

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

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

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

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

У робочих процесах підприємств часто трапляються недокументовані винятки й суперечливі практики в різних командах. Як Reindeer з’ясовує, як насправді виконують роботу, і водночас відрізняє корисні інституційні знання від звичок, які не слід автоматизувати?

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

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

Ми не прагнемо автоматизувати кожну звичку. Наша мета — перетворити цінні інституційні знання на надійний інтелект, не вимагаючи від інженерів заздалегідь передбачати кожен можливий сценарій.

Більшість компаній, що працюють з агентним ШІ, починають із документування, а потім кодують процес, опитуючи людей і ретельно аналізуючи попередні дані. Але насправді найефективніше процес засвоюється щоразу, коли до команди долучається новий працівник: він не запам’ятовує дані за цілий рік чи стандартну операційну процедуру (SOP) на 3 000 сторінок. Він опановує кілька навичок, розглядає кілька прикладів, береться до роботи, ставить запитання, коли стикається з чимось незрозумілим, і поступово накопичує знання. Саме такий процес ми й створили.

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

Коли ви кажете, що агенти Reindeer постійно навчаються під час роботи, що саме змінюється: ваги моделі, пам’ять, логіка робочого процесу чи чітко визначені політики? Чи могли б ви навести приклад винятку, який навчає агента інакше обробляти подібні випадки в майбутньому?

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

Уявімо агента для обробки рахунків-фактур. Він отримує рахунок-фактуру, сума якого на 4% перевищує суму в замовленні на закупівлю, і не знаходить політики, яка охоплювала б цей випадок. Замість того щоб обробити рахунок, агент передає його експерту. Експерт пояснює, що для цього постачальника затверджено виняток щодо надбавок за пальне. Агент вирішує цей випадок, а пояснення зберігається як контекст лише для цього постачальника.

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

Рішення працівника може бути доречним для одного клієнта чи однієї операції, але не підходити як загальне правило. Як ви визначаєте, коли відгук має залишитися одноразовим винятком, а коли — стати пропозицією змінити політику?

Ми розмежовуємо вирішення окремого випадку та зміну подальшої роботи агента.

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

Якщо є підстави для ширших змін, ми запускаємо агента на нашій платформі оцінювання — свого роду «Шоу Трумана» для агентів — і пропонуємо оновлення на затвердження людиною.

Мета — навчатися в людей, а не бездумно відтворювати їхні рішення. Інакше ви просто автоматизуєте помилки.

Агент може краще справлятися з нещодавніми випадками, але водночас менш надійно обробляти ситуації, з якими раніше давав раду. Яке тестування та затвердження має пройти запропонована зміна, перш ніж потрапити у виробниче середовище, і як ви виявляєте та усуваєте регресії?

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

Спершу проводимо тестування, і це складніше, ніж здається, адже в операційній роботі немає єдиного правильного набору відповідей. Ми відбираємо репрезентативні випадки на основі відгуків експертів, визначаємо критерії порівняння результатів і повторно проганяємо ці випадки через поточну та запропоновану версії агента. Дії з побічними ефектами, як-от надсилання електронного листа, виконуються в симуляторі, створеному на основі попередніх запусків, а тестові випадки, які більше не відповідають чинній політиці, вилучаються. Ми можемо виміряти реальний ефект змін; водночас агенти мають вважати, що діють у реальному світі, а їхні дії мають реальні наслідки — наприклад, створення запису в SAP або надсилання листа клієнту. Лише так можна створити повноцінну систему оцінювання для кожного агента.

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

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

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

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

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

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

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

Чи могли б ви розповісти про одне з упроваджень у Hellmann Worldwide Logistics або Papaya Global і пояснити, що змінилося від запуску до подальшої роботи? Як змінилися точність, частота винятків, час опрацювання та обсяг необхідного втручання людей?

Hellmann Worldwide Logistics — чудовий приклад того, як агенти можуть з часом покращувати реальні операційні процеси. Команда з ціноутворення витрачала надзвичайно багато часу на ручне опрацювання запитів на перевезення, що надходили електронною поштою, у таблицях та інших документах, і часто готувала комерційну пропозицію кілька днів.

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

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

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

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

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

Найочевидніший висновок із наших упроваджень полягає в тому, що в компаніях формується нова функція — так само, як із появою CRM виникла функція управління доходами, а з розвитком хмарних технологій — Dev Ops. Коли компанії переходять від кількох агентів до їхнього цілого рою, їм потрібна людина або команда, яка керуватиме агентами так само, як керівник підрозділу керує колективом: відповідатиме за їхні KPI та ROI, вирішуватиме, які завдання доручати агентам, а які — ні, і затверджуватиме зміни в їхній роботі. Компанії, які вже створюють таку функцію, розвиваються найшвидше й мають найкращі шанси на успіх.

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

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

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

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

Але створити агента — не те саме, що забезпечити його надійну роботу в складній компанії впродовж тривалого часу.

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

Моделі дешевшатимуть. Створювати агентів ставатиме легше.

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

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