Никундж Баджай, сооснователь и генеральный директор TrueFoundry – Серия интервью

Вы работали над исследованиями в области машинного обучения, производством искусственного интеллекта в Facebook (META ) и крупномасштабными системами рекомендаций до основания TrueFoundry — какие опыт и проблемы побудили вас создать корпоративную инфраструктуру искусственного интеллекта, и какую боль вы не видели решенной в то время?

В Meta мы рассматривали машинное обучение как особый случай программного обеспечения, а генеративный искусственный интеллект — как особый случай машинного обучения, что привело к вертикальному стеку с программным обеспечением внизу, машинным обучением в середине и генеративным искусственным интеллектом вверху. В этой схеме, если я являюсь разработчиком машинного обучения, модели, которые я создаю, следуют тому же шаблону развертывания, что и остальное программное обеспечение, что делает масштабирование систем очень простым.

Однако большинство корпоративных организаций развертывали параллельные стека, то есть имели отдельные стека для программного обеспечения, машинного обучения и генеративного искусственного интеллекта. Как только у вас есть эти параллельные стека, масштабирование становится более сложным из-за необходимости передачи данных между миром машинного обучения и миром программного обеспечения.

Наша команда всегда работала на пересечении создания моделей машинного обучения и инфраструктуры машинного обучения, поэтому у нас был уникальный взгляд, который мы могли принести в корпоративный мир, адаптируя вертикальные стека для их конкретных требований. У нас также была гипотеза в конце 2021 года, что машинное обучение приближалось к точке бифуркации, и когда это произошло, больше компаний будут нуждаться в вертикально интегрированном стеке для эффективного развертывания и масштабирования этих систем. Это в конечном итоге привело нас к созданию TrueFoundry, и наша гипотеза оказалась правильной. Внедрение искусственного интеллекта ускорилось после запуска ChatGPT в конце 2022 года.

Когда системы искусственного интеллекта переходят от экспериментов к повседневной эксплуатации, что изменилось в том, как организации должны думать о надежности и сбоях?

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

Кроме того, сбоям больше не являются бинарными. Вместо того, чтобы системы просто вышли из строя или не вышли, многие проблемы появляются как частичные сбоя или скрытые ухудшения. Системы могут отвечать с большей задержкой, ухудшением качества или неправильным поведением со временем. Во многих случаях эти ухудшения могут быть более трудными для обнаружения и иногда даже более вредными, чем полный сбой.

Организации должны думать о надежности не только в терминах времени безотказной работы, но и о ухудшении производительности со временем.

TrueFailover был запущен во время волны высокопрофильных сбоев облачных и сервисов искусственного интеллекта. Какие недавние события показали, что надежность искусственного интеллекта сместилась от “хорошо иметь” к основному архитектурному требованию?

Один из наших клиентов в сфере здравоохранения, который обрабатывает запросы на рецепты в режиме реального времени, был затронут сбоями, вызванными сбоями моделей. Их рабочие процессы генерируют тысячи долларов дохода в секунду, и сбой нарушил некоторые из этих критических рабочих процессов. Как один из первых клиентов TrueFailover, мы смогли помочь с быстрым восстановлением, и воздействие было локализовано.

Инциденты, подобные этому, поднимают важный вопрос. Когда ставки систем генеративного искусственного интеллекта продолжают расти, почему процессы восстановления по-прежнему в значительной степени ручные? Это подкрепило идею о том, что системы должны быть построены с учетом того, что сбоям будут происходить, и они должны быть спроектированы так, чтобы автоматически исправлять себя. Надежность также должна быть встроена в сам стек искусственного интеллекта посредством использования шлюзов искусственного интеллекта, которые могут обеспечить централизованное маршрутизацию, наблюдаемость, ограничители и интеллектуальное переключение моделей между поставщиками.

Многие сбои искусственного интеллекта все еще представлены как технические сбои. Где вы видите реальные экономические и человеческие затраты, начинающие появляться, когда системы искусственного интеллекта выходят из строя?

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

Когда системы искусственного интеллекта глубже интегрируются в операционные рабочие процессы, сбои больше не являются только техническими проблемами. Они все чаще имеют прямые бизнес-, клиентские и репутационные последствия.

В критически важных средах, таких как аптеки, операции здравоохранения или службы поддержки клиентов, как быстро может сбой искусственного интеллекта эскалировать в операционный или репутационный риск?

В критически важных средах эскалация происходит почти сразу, поскольку эти системы поддерживают рабочие процессы в режиме реального времени. Даже короткий сбой может остановить критические процессы, задержать доставку услуг или прервать системы, которые зависят от этих выходов, создавая каскадные операционные эффекты по всей организации.

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

Вы сказали, что многие команды проектируют для возможности, а не для непрерывности. Почему вы думаете, что устойчивость исторически была отодвинута на второй план в проектировании систем искусственного интеллекта?

Это в основном связано со стимулами внутри организаций. Новые возможности видны и интересны. Они открывают демонстрации, функции и возможности продукта, которые руководство может сразу увидеть.

Непрерывность, по определению, невидима, когда все работает хорошо. Из-за этого системы вознаграждения склонны быть смещены в сторону разработки новых возможностей, а не обеспечения того, чтобы ничего не сломалось. В результате организации часто вкладывают непропорционально больше в разработку возможностей, чем в инженерию по надежности.

Когда предприятия все чаще полагаются на внешние модели и API, какие новые хрупкости вводятся в стек искусственного интеллекта, которые лидеры могут еще не полностью оценить?

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

Поскольку большие языковые модели являются общими ресурсами, задержка может вспыхнуть, потому что другой потребитель этих моделей совершает определенное действие. Есть много таких точек сбоя, которые вводятся из-за фундаментальной природы больших языковых моделей, и предприятия в этом новом мире просто не имеют полного контроля. Без полного контроля лучшее, что может сделать предприятие, — это создать достаточно системных избытков, чтобы спроектировать устойчивую систему.

Не фокусируясь на конкретных продуктах, как должны организации переосмыслить архитектуру искусственного интеллекта, чтобы предполагать сбой, а не рассматривать сбои как редкие исключительные случаи?

Организации должны вернуться к основным принципам проектирования распределенных систем. Системы программного обеспечения были построены на предположении, что компоненты сети и машины могут выйти из строя, и что整个 регион может выйти из строя.

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

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

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

Глядя вперед, что означает “производственно готовый” искусственный интеллект в мире, где искусственный интеллект ожидается быть постоянно доступным, а не только иногда полезным?

Системы искусственного интеллекта, готовые к производству, должны быть наблюдаемыми, контролируемыми и восстанавливаемыми. Все три этих коробки должны быть отмечены.

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

Для того, чтобы системы были контролируемыми, это включает в себя формирование трафика, ограничение скорости, ограничители, обеспечение политики и интеллектуальное маршрутизацию между моделями и поставщиками. Это место, где шлюз искусственного интеллекта становится фундаментальным, действуя как централизованная плоскость управления, которая обеспечивает ограничители, предоставляет последовательное управление и ermögляет динамическое переключение моделей, когда производительность или надежность снижаются.

И, наконец, когда речь идет о восстановлении, системы должны быть построены с учетом того, что компоненты могут быть частично или полностью сломаны, будь то из-за сбоя поставщика, ухудшения качества модели, ограничения скорости или неожиданных входных данных от злонамеренных акторов. Автоматические механизмы отработки сбоя и самоисцеления должны быть родными для архитектуры, а не ручными справочниками, запускаемыми после того, как что-то пошло не так.

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