Исследование Microsoft показало, что на ликвидацию последствий инцидентов в облачных сервисах генеративного ИИ (GenAI) уходит значительно больше времени, чем в других сервисах, сообщает портал The New Stack.

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

Поэтому семь исследователей Microsoft (пять из США и двое из Китая) объединились с еще тремя исследователями из китайских университетов и двумя из Иллинойского университета Урбана-Шампейн и подготовили так называемое «комплексное исследование инцидентов с облачными сервисами GenAI» (все они взяты из практики Microsoft), посвященное изучению «симптомов, основных причин и стратегий их устранения».

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

Четыре года после выхода GPT-3

Используя данные из системы управления инцидентами Microsoft за четыре года, исследователи проанализировали производственные инциденты в облачных сервисах GenAI на предмет их «общих характеристик», включая влияние на доступность и другие проблемы качества обслуживания (к которым относятся, в частности, «проблемы качества генерируемого контента»). В итоге они обнаружили два принципиальных отличия таких сервисов:

  • они требуют больше времени для устранения;
  • они в основном вызваны инфраструктурой.

Общий анализ охватил период с июня 2020 г. (дата выхода GPT-3) до февраля 2024 г. В исследовании отмечается, что Microsoft размещает у себя объемную инфраструктуру обучения OpenAI, а также ее публичные API. (На графике ниже показаны всплески после внедрения GPT-3.5, ChatGPT и GPT-4). Microsoft также предоставляет такие сервисы, как Azure OpenAI.

Используя почти четырехлетнюю статистику реальных инцидентов для выявления фактических проблем, с которыми сталкиваются производственные системы, исследователи надеялись найти способы повышения надежности крупномасштабных облачных сервисов GenAI. К счастью, система Microsoft фиксировала основные причины и меры по их устранению (вместе с обсуждениями инженеров), что «позволило провести всесторонний и сравнительный анализ инцидентов с облачными сервисами GenAI...». Важно отметить, что исследователи также смогли тщательно классифицировать инциденты, не связанные с GenAI, что позволило им провести сравнение. Система Microsoft также фиксировала степень серьезности инцидента — высокую, среднюю или низкую.

Исследователи сосредоточились на "значительных"/"высокой серьезности" инцидентах с подробным описанием первопричины, что «способствовало глубокому качественному анализу». Но помимо обычного внимания к надежности, сервисы GenAI также сталкиваются со своими уникальными проблемами, включая «ухудшение качества ответа» (например, неадекватный ответ на простую подсказку или «генерация неверного контента, когда модель не может понять подсказку пользователя») и нарушение конфиденциальности конечного пользователя (а также свои собственные уникальные проблемы с производительностью).

Даже фильтры вредоносного контента могут давать сбои, генерируя ложные сигналы тревоги или пропуская действительно вредоносный контент. Могут возникать проблемы с сетью, хранилищем и даже с реальными вычислительными ресурсами. Но есть и уникальные виды «сбоев развертывания», например, проблемы с доступностью больших языковых моделей (LLM) или даже с API для выбора модели или настройки параметров (а также API для загрузки или скачивания данных).

Исследователи назвали их «GenAI-инцидентами».

Выводы

Проблемы разделились на три четкие категории:

  • снижение производительности (49,8%);
  • неудачное развертывание (35,7%);
  • неверные выводы (14,5%).

Но что важно, в облачных сервисах GenAI значительно выше процент инцидентов, обнаруженных людьми (а не автоматическими мониторами):

  • облачные сервисы GenAI: 38,3%;
  • другие сервисы: 13,7%.

В исследовании отмечается, что 45,9% облачных сервисов GenAI «все еще находятся в стадии разработки или предварительного просмотра» (при этом 54,1% находятся в «общем доступе»). Инциденты, о которых сообщали люди, приходилось позже переназначать более подходящей команде чаще, чем автоматизированные отчеты. (Хотя исследователи отмечают, что одной из возможных причин является взаимозависимость с другими сервисами. Разрешение инцидента может превышать возможности одной команды, поэтому необходимы совместные усилия различных служб.)

По этой и другим причинам инциденты, о которых сообщали люди, требовали на 72% больше времени для устранения последствий. (Автоматизированные отчеты, что важно, часто поставляются с предлагаемыми руководствами по устранению неполадок.)

Авторы исследования предлагают поставщикам сервисов улучшить наблюдаемость «для более эффективного обнаружения и диагностики проблем..... Автоматические мониторы и руководства по устранению неполадок могут значительно ускорить процесс устранения неполадок и сократить время на устранение инцидентов GenAI». Хотя еще одна проблема заключается в том, что мониторинг сервисов GenAI в настоящее время, похоже, имеет более высокий процент ложных срабатываний, чем инциденты, обнаруженные человеком — 11,0 против 6,6%, причем оба эти показателя выше, чем у сервисов, не относящихся к GenAI (3,8 и 4,8% соответственно).

Исследователи обнаружили, что все инциденты GenAI также требуют больше времени на устранение, чем инциденты не-GenAI; они объясняют это тем, что инциденты GenAI являются более сложными (с их «обширными и взаимосвязанными слоями инфраструктуры, зависимостей и конфигураций... Один симптом может быть вызван несколькими первопричинами, что усложняет отладку»). Исследователи предлагают одно очевидное решение: наблюдаемость с более детальным пониманием того, что является причиной инцидентов, с помощью средств автоматизации или агентов. Еще одно их предложение — практика Infrastructure as Code (IaC), «чтобы эффективнее управлять сложной облачной инфраструктурой GenAI».

Исследователи смогли количественно оценить ситуацию: «Облачные системы GenAI требуют в 2,5 раза больше исправлений инфраструктуры, в 3,0 раза больше изменений кода и в 3,0 раза больше обновлений конфигурации по сравнению с сервисами, не относящимися к GenAI».

Противостояние сложности

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

Но часть проблемы, похоже, заключается в реальной сложности поддержки GenAI. Для облачных сервисов, не относящихся к GenAI, в 54,7% случаев защита — это быстрые «специальные исправления», определяемые как «импровизированные, специфические для конкретной ситуации шаги» для первого реагирования на симптомы, например, блокирование злоумышленников, обходящих ограничения на размер с помощью дополнительных строк в коде проверки. Но только 22,4% исправлений GenAI являются специальными. Исследователи полагают, что облачные сервисы GenAI, находящиеся на ранней стадии развития, требуют «более разнообразных, сложных и трудоемких методов».

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

Однако устранение последствий инцидентов с облачными сервисами GenAI оказалось уникальным и в другом отношении, поскольку «конкретная первопричина не привязана к одному типу исправлений..... Учитывая сжатые сроки для дежурных инженеров, для сокращения времени простоя приоритет отдается быстрым подходам, таким как откат». (Это приводит к показательной статистике: «В то время как на ошибки в коде приходится 21,5% инцидентов GenAI, только 7,6% исправлений — это изменения кода...».)

Исследователи приводят и другие интересные наблюдения об уникальных проблемах инфраструктуры GenAI, например о том, что инциденты низкой степени серьезности «демонстрируют значительно большее время на устранение по сравнению с другими уровнями серьезности, поскольку эти низкоприоритетные инциденты GenAI часто остаются нерешенными в течение длительного времени из-за их низкого воздействия». А 14,5% зарегистрированных инцидентов были связаны с «неверными результатами», такими как галлюцинации или нерелевантные ответы, которые «сложно обнаружить» и которые нуждаются в автоматизированных проверках.

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

В то же время в их исследовании содержится интересная оговорка. Поскольку все рассмотренные инциденты произошли в облачных системах Microsoft, в которых уже развернуты автоматизированные инструменты для предотвращения некоторых инцидентов до их возникновения, этот набор данных «может не полностью отражать поведение других облачных сервисов GenAI». Что означает необходимость проведения более широкой оценки с использованием облачных сервисов GenAI нескольких компаний.