Мануель Ромеро, співзасновник і головний науковий директор у Maisa – інтерв’ю серії

Мануель Ромеро, співзасновник і головний науковий директор у Maisa, — дослідник та інженер у галузі штучного інтелекту, який зосереджений на розробці надійних, корпоративних систем штучного інтелекту. Він співзаснував Maisa у 2024 році, щоб створювати відповідальний ШІ, здатний виконувати складні бізнес-процеси з прозорістю та контролем. До Maisa Ромеро обіймав старші інженерні посади в галузі ШІ та машинного навчання в таких компаніях, як Clibrain і Narrativa, де спеціалізувався на обробці природної мови та масштабних системах ШІ. На початку кар’єри він працював full-stack розробником програмного забезпечення та фахівцем DevOps, перш ніж перейти до передових досліджень і розробок у галузі ШІ, ставши активним учасником екосистеми відкритого ШІ. Maisa AI розробляє автономних “цифрових працівників” — агентів ШІ, призначених для автоматизації складних корпоративних робочих процесів з одночасним забезпеченням відстежуваності, управління та надійності. Платформа дозволяє організаціям створювати та впроваджувати агентів ШІ за допомогою природної мови, забезпечуючи автоматизацію в різних внутрішніх системах та джерелах даних без необхідності обширного програмування. Зосереджуючись на перевіреному міркуванні та структурованому виконанні, Maisa прагне подолати типові обмеження, пов’язані з генеративними системами ШІ, і допомогти підприємствам безпечно впроваджувати автономний ШІ у великих масштабах. Ви часто зосереджуєтесь на розумінні глибшої “причини” роботи систем ШІ. З технічної точки зору, що спонукало вас співзаснувати Maisa у 2024 році, і яку прогалину в архітектурі корпоративного ШІ, на вашу думку, не вирішували? Мотивацією для заснування Maisa стало усвідомлення того, що більшість корпоративних стеків ШІ будувалися навколо моделей, а не систем. Під час буму генеративного ШІ багато компаній зосередилися на інтеграції великих мовних моделей у існуючі робочі процеси. Однак ці системи часто виявлялися крихкими, непрозорими та складними для масштабування. Їм бракувало:

• детермінованого виконання там, де це важливо.
• сильної спостережності, відстежуваності
• відтворюваності

Прогалина, яку ми побачили, полягала у відсутності справжньої інфраструктури ШІ для підприємств. Компанії будували додатки навколо API LLM, але їм бракувало чогось, еквівалентного архітектурі комп’ютера для роботи зі знаннями. Maisa була створена, щоб заповнити цю прогалину, розробивши архітектуру, зосереджену навколо Блоку обробки знань (Knowledge Processing Unit, KPU) — системи, яка дозволяє ШІ надійно працювати в реальних корпоративних робочих процесах. Ви працювали в галузі передової обробки природної мови та генеративних систем до заснування Maisa. Як цей досвід вплинув на архітектурні рішення, що лежать в основі платформи? Мій досвід роботи в NLP та NLG, особливо в тренуванні та попередньому навчанні мовних моделей, а згодом і великих мовних моделей (сотень їх), дуже чітко показав одну річ при спробі побудувати реальні системи на їх основі. Архітектура трансформера надзвичайно потужна, але має принаймні три фундаментальні обмеження, які необхідно подолати, щоб надійно використовувати її в продакшені. Перше — це галюцинації. Ці моделі генерують текст імовірнісно і можуть видавати результати, які звучать правильно, але не ґрунтуються на перевіреній інформації. Друге — обмеження контексту. Навіть з більшими контекстними вікнами моделі працюють в обмеженому просторі токенів, що ускладнює міркування над великими або складними масивами знань. Третє — актуальність інформації. Попередньо навчені моделі представляють знімок знань на момент навчання, тоді як корпоративне середовище вимагає систем, здатних міркувати над постійно змінюваною інформацією. Усвідомлення цих обмежень сформувало багато архітектурних рішень Maisa. Замість того, щоб покладатися лише на модель, ми зосередилися на побудові системи, яка забезпечує структурований доступ до знань, механізми перевірки та контрольоване виконання, щоб ШІ міг надійно працювати в реальних корпоративних робочих процесах. Багато підприємств експериментують з генеративним ШІ, але намагаються вийти за межі пілотних проектів. З точки зору дизайну систем, яка основна причина того, що масштабування не вдається в такій кількості організацій? Багато підприємств не можуть вийти за межі пілотних проектів з генеративним ШІ, тому що більшість впроваджень будуються як експерименти, а не як надійні системи. Ранні прототипи часто базуються на промпт-інжинірингу, легкій оркестрації та простих пайплайнах пошуку, які можуть продемонструвати цінність, але не забезпечують надійності, спостережності чи контролю, необхідних для продакшен-середовищ. Коли організації намагаються масштабувати ці системи, вони стикаються з такими проблемами, як нестабільні результати, відсутність відстежуваності, складність інтеграції з корпоративними робочими процесами та обмежене управління поведінкою ШІ. В основі проблема полягає в тому, що великі мовні моделі є імовірнісними генераторами, тоді як корпоративні процеси вимагають передбачуваної та контрольованої поведінки. Без архітектури, яка додає структуру навколо міркування, перевірки, виконання та моніторингу, генеративні системи ШІ залишаються складними для масштабування за межі ізольованих випадків використання. Цифрові працівники Maisa розроблені бути контрольованими та структурованими, а не суто імовірнісними. Що це означає на практиці для підприємств, які оцінюють ШІ для виробничого використання? Коли ми говоримо, що Цифрові працівники Maisa є контрольованими та структурованими, а не суто імовірнісними, ми маємо на увазі, що ШІ працює в контрольованій системі, де його дії та міркування можна відстежити та керувати ними. Замість того, щоб дозволяти моделі вільно генерувати результати та рішення, система структурує взаємодію ШІ з даними, інструментами та робочими процесами. Кожен крок у процесі може бути залогований, перевірений та підтверджений, а дії виконуються через визначені інтерфейси, а не безпосередньо з виводу моделі. Для підприємств це означає, що системи ШІ можна моніторити, аудитувати та інтегрувати в критичні процеси з більшою впевненістю. Це перетворює ШІ з чорної скриньки-помічника на систему, поведінку якої можна зрозуміти, контролювати та довіряти їй у виробничих середовищах. Як архітектор Блоку обробки знань, чим він відрізняється від типового шару оркестрації або рушія робочих процесів, побудованого навколо великих мовних моделей? Блок обробки знань відрізняється від типових шарів оркестрації тим, що він розроблений для керування повним життєвим циклом міркувань на основі ШІ, а не просто для координації промптів та викликів моделей. Більшість фреймворків оркестрації діють як менеджери робочих процесів, які об’єднують такі етапи, як пошук, промптинг та виконання інструментів. KPU працює на глибшому архітектурному рівні, структуруючи доступ до знань, виконання міркувань та виконання дій у системі. Він розглядає обробку знань як основний обчислювальний шар, інтегруючи пам’ять, перевірку та контрольоване виконання, щоб ШІ міг надійно працювати в складних корпоративних робочих процесах, а не просто генерувати відповіді. У регульованих галузях толерантність до ризиків низька. Які конкретні дизайнерські рішення ви прийняли, щоб гарантувати надійність результатів ШІ та запобігти поширенню помилок у складних робочих процесах? У регульованих галузях надійність і контроль є важливими, тому ми розробили систему з кількома захисними механізмами, щоб гарантувати достовірність результатів ШІ. Один ключовий принцип — це структуроване виконання, коли ШІ не може безпосередньо запускати критичні дії без проходження через контрольовані інтерфейси. Ми також включаємо шари перевірки, які контролюють вихідні дані моделі на відповідність схемам, правилам або вторинним механізмам, перш ніж вони будуть прийняті. Крім того, система підтримує повну спостережність, записуючи кроки міркувань, взаємодію з інструментами та рішення, щоб їх можна було відстежити та проаудитувати. Разом ці дизайнерські рішення допомагають запобігти поширенню помилок через робочі процеси та дозволяють організаціям експлуатувати системи ШІ з рівнем надійності та управління, необхідним у регульованих середовищах. Які найбільш переконливі ранні випадки використання, де ви бачили, як Цифрові працівники переходять від навігаційної допомоги до повноцінного виконання на основі ШІ? Деякі з найбільш переконливих ранніх випадків використання з’являються в робочих процесах, інтенсивних за знаннями, де процеси чітко визначені, але все ще вимагають значного аналізу та прийняття рішень. У таких сферах, як перевірка відповідності вимогам, операції технічної підтримки та внутрішнє управління знаннями, Цифрові працівники можуть вийти за межі простої допомоги людям і почати виконувати структуровані завдання від початку до кінця. Вони можуть отримувати та аналізувати великі обсяги внутрішньої інформації, застосовувати визначені процедури, взаємодіяти з корпоративними системами через контрольовані інструменти та продукувати результати, які безпосередньо надходять у операційні робочі процеси. Ключова зміна відбувається, коли ШІ не лише генерує пропозиції, але й здатний надійно виконувати визначені дії в керованій системі, дозволяючи організаціям автоматизувати частини складної роботи зі знаннями, а не просто доповнювати її. У міру посилення регуляторного нагляду за ШІ у всьому світі, як ви бачите еволюцію основної інфраструктури ШІ для відповідності вимогам без обмеження інновацій? У міру посилення регуляторного нагляду за ШІ, я вважаю, ми побачимо відхід від архітектур, які просто викликають API постачальників моделей і сліпо довіряють результату. Підприємства та регулятори все більше вимагатимуть систем, де поведінка ШІ є спостережуваною, контрольованою та керованою. Саме тут набувають важливості архітектури на кшталт Блоку обробки знань. Такий тип архітектури дозволяє організаціям застосовувати контроль, відстежувати рішення та гарантувати надійність результатів ШІ, перш ніж вони вплинуть на реальні процеси.