Генеративные облачные сервисы AI (Genai) уникальны в своих интенсивных требованиях по аппаратному обеспечению, а также на вычислительных ресурсах, работающих над ним. Тем не менее, несмотря на необходимость надежности, в нем проходили почти никаких исследований, или о том, как управляются инциденты Cloud Genai.
Таким образом, семь исследователей Microsoft (в том числе два базирующихся в Китае) объединились с еще тремя исследователями из китайских университетов и двумя из Университета Иллинойса Урбана-Шампейн и опубликовали то, что они называют «всесторонним исследованием инцидентов из облачных сервисов Genai»-все они взяты из Microsoft и изучали «симптомы, основные причины и стратегии смягчения».
Их вывод? С точки зрения инфраструктуры эти услуги действительно различны. «Как и любой крупномасштабный облачный сервис, сбои неизбежны в облачных сервисах Genai»,-начинается статья.
Но Genai уникален, и «понимание характеристик этих инцидентов, включая обнаружение, сортировку, диагностику и смягчение, имеет решающее значение для повышения качества облачных услуг Genai».
Через четыре года после GPT-3
Используя данные из системы управления инцидентами Microsoft примерно в течение четырех лет, они проанализировали инциденты Genai Cloud Production для своих «общих характеристик», включая их влияние на доступность и другие проблемы с качеством обслуживания (которые, помимо прочего, включают в себя «созданные проблемы качества контента»). И в конечном итоге они обнаружили два важных различия в «эмпирическом исследовании инцидентов производства в генеративных облачных сервисах ИИ»:
- Они занимают больше времени, чтобы смягчить.
- Они в основном вызваны инфраструктурой.
Их общий анализ начался с июня 2020 года (дата выпуска GPT-3) и продлен до февраля 2024 года. Их в статье отмечается, что Microsoft проводит объемную обучающую инфраструктуру Openai, а также ее общедоступные API. (График показывает шипы после введения GPT-3.5, CHATGPT и GPT-4.) Microsoft также размещает такие услуги, как Azure OpenAI.
Используя почти четыре года реальных инцидентов для выявления фактических проблем, с которыми сталкиваются в производственных системах, они надеялись выявить способы повышения надежности крупномасштабных облачных сервисов Genai. И, к счастью, система Microsoft захватила коренные причины и этапы смягчения (наряду с обсуждениями вовлеченных инженеров), которые исследователи рассматривали как «обеспечение всестороннего и сравнительного анализа инцидентов облачного обслуживания Genai…». В значительной степени они также смогли кропотливо классифицировать, какие инциденты не связаны с Genai, что позволяет им сравниваться. Система Microsoft также захватила, была ли серьезность инцидента высокой, средней или низкой.
Исследователи сосредоточились на «значимых»/инцидентах с высокой чувствительностью с подробными описаниями первопричин, «облегчающим проницательный качественный анализ». Но помимо обычного внимания к надежности, услуги Genai также сталкиваются с собственными уникальными проблемами, включая «деградацию качества ответа» (например, неуместный выход из простых подсказок или «генерацию недопустимого контента, где модель не может понять подсказку пользователя») и соображения конфиденциальности конечного пользователя (а также их собственные уникальные проблемы производительности).
Даже фильтры для вредного содержания могут неисправности, либо генерировать ложные тревоги, либо позволить фактическому вредному содержанию проскользнуть. Могут быть проблемы с сетью, проблемы с хранением и даже проблемы с фактическими вычислительными ресурсами. Но существуют также уникальные виды «сбоев развертывания», такие как проблемы с доступностью моделей крупных языков (LLMS) или даже с API для выбора модели или параметров настройки (а также API для загрузки или загрузки данных).
Исследователи назвали эти «инциденты Геная».
Выводы
Проблемы разбились на три четкие категории:
- Деградация производительности: 49,8%
- Отказ развертывания: 35,7%
- Неверный вывод: 14,5%
Но важно, что облачные сервисы Genai имели гораздо более высокий уровень инцидентов, обнаруженных людьми (а не автоматизированными мониторами):
- Облачные сервисы Genai: 38,3%
- Другие услуги: 13,7%
В их статье отмечается, что 45,9% облачных сервисов Genai «все еще находятся в стадии разработки или на этапе предварительного просмотра» (с 54,1% в «общей доступности»). Эти инциденты, сообщенные человеком, должны были быть переназначены позже более подходящей команде, чем автоматизированные отчеты. (Хотя исследователи отмечают, что одной из возможных причин является «взаимозависимость в других услугах. Решение инцидента может превышать возможности одной команды, и необходимы совместные усилия в разных областях обслуживания».)
По этим и другим причинам инциденты, о которых сообщалось, потребовалось на 72% больше времени для смягчения. (В конце концов, автоматизированные отчеты часто поставляются с предлагаемыми руководствами по устранению неполадок.)
В отчете предполагается, что поставщики услуг должны повысить наблюдаемость «для более эффективного обнаружения и диагностики проблем…. Автоматические мониторы и руководства по устранению сбоев могут значительно повысить процесс смягчения и сократить время для смягчения последствий для инцидентов в Генае». Хотя другая проблема заключается в том, что мониторинг услуг Genai в настоящее время, по-видимому, имеет более высокий уровень ложной тревоги, чем инциденты, определенные человеком,-11,0% против 6,6%-при этом оба числа выше, чем то, что испытывали услуги, не имеющие геная (3,8% и 4,8%).
Но все инциденты в Генае также потребовались дольше, чтобы смягчить, чем инциденты, не являющиеся генаями, обнаружили исследователи, что позволяет предположить, что инциденты Геная являются более сложными (с их «обширными и взаимосвязанными слоями инфраструктуры, зависимостей и конфигураций… единственный симптом может возникнуть из-за множественных основных причин, таким образом, усложняют отладку»). Они предлагают одно очевидное решение: наблюдение с более гранулированным пониманием того, что вызывает инциденты, из инструментов автоматизации или агентов. Но другое предложение — это инфраструктура как практика кода (IAC), «чтобы более эффективно управлять сложным облачным облаком Genai».
На самом деле они смогли количественно оценить, как это разыгрывается в реальном мире.
«Облачные системы Genai требуют в 2,5 раза больше исправлений инфраструктуры, в 3,0x больше изменений кода и в 3,0x обновления конфигурации по сравнению с услугами, не являющимися генайными службами».
Столкнувшись с сложностью
Они также предполагают, что поставщики услуг должны предоставить пользователям услуг Genai лучшую поддержку и документацию, чтобы помочь им «ориентироваться в сложностях интеграции и управления услугами Genai». Разработчики могут помочь снизить количество инцидентов Геная, внедрив более строгие процессы проверки ввода и «динамические» стратегии ограничения скорости, «которые адаптируются к условиям в реальном времени».
Но часть проблемы, по -видимому, является истинной сложностью поддержки Genai. Для негенайских облачных сервисов 54,7% их смягчения представляют собой быстрые «специальные исправления», определяемые как «импровизированные, специфичные для ситуации шаги», для первого смягчения симптомов, таких как блокирование злонамеренных пользователей, обходящих ограничения по размеру с дополнительными линиями в коде проверки. Но только 22,4% фиксаций Геная являются специальными. Исследователи предполагают, что облачные сервисы Genai, находясь на стадии раннего развития, требуют «более разнообразных, сложных и трудоемких методов».
Они ожидают, что инструменты мониторинга для инцидентов Геная улучшатся, что поможет сократить время до смягчения последствий.
Но смягчение инцидентов с облачным сервисом Genai было уникальным по-другому, поскольку «конкретная основная причина не привязана к одному типу исправления…. Учитывая жесткие сроки для инженеров по вызову, быстрые подходы, такие как откат, приоритеты для сокращения времени простоя». (Это приводит к показательной статистике: «В то время как кодовые ошибки составляют 21,5% инцидентов Геная, только 7,6% исправлений — это изменения кода…»)
Были и другие интересные наблюдения об уникальных проблемах инфраструктуры Genai, например, как «инциденты с низким уровнем высокого уровня» демонстрируют значительно более длительное время для получения последствий по сравнению с другими уровнями тяжести, поскольку эти инциденты с более низким приоритетом в Генае часто остаются нерешенными в течение длительного периода из-за их низкого воздействия ». И 14,5% зарегистрированных инцидентов были «недействительными результатами», такими как галлюцинации или не относящиеся к делу, которые они описывают как «сложные для обнаружения» и нуждаются в автоматических проверках.
Текущие методы обнаружения представляют собой собственную «самоосуждение» LLM, вычисляющие оценки согласованности после нескольких попыток или использование моделей, настраиваемых с данными, меченными на людях, но ни один из этих методов не является полностью эффективным-или экономичным. «Для устранения этих ограничений необходимы более надежные исследования и разработка масштабируемых алгоритмов проверки…»
Но их отчет также содержит это интересное предостережение. Поскольку все инциденты поступили из облачных систем Microsoft, которые уже развертывают автоматизированные инструменты, чтобы остановить некоторые инциденты до того, как они произойдут, этот набор данных только Microsoft «может не полностью представлять поведение других облачных сервисов Genai».
Таким образом, исследователи уже планируют более широкую оценку с использованием облачных сервисов нескольких компаний.
Trending Stories youtube.com/thenewstack Tech движется быстро, не пропустите эпизод. Подпишитесь на наш канал YouTube, чтобы транслировать все наши подкасты, интервью, демонстрации и многое другое. Группа подпишитесь с эскизом. Дэвид Кассель — гордый житель района залива Сан -Франциско, где он освещал технологические новости более двух десятилетий. За эти годы его статьи появлялись повсюду от CNN, MSNBC и The Wall Street Journal Interactive … Подробнее от Дэвида Касселя
