Ваш ИИ-провайдер — это единая точка отказа
В прошлую пятницу Министерство торговли США направило письмо компании Anthropic. К тому же вечеру Fable 5 и Mythos 5 исчезли.
Их не выводили из эксплуатации. Их не ограничивали в использовании. Они просто исчезли.
API-запросы возвращали ошибки 404. Активные сессии прерывались прямо посреди диалога. Приложения, зависящие от этих моделей, перестали работать. Это произошло через три дня после запуска. Ни предупреждений, ни окна для миграции не было.
Нам повезло, потому что эти модели были новыми. Никто еще не выстроил на них глубоких зависимостей. Представьте, что подобное случилось с моделью, которую вы используете ежедневно на протяжении шести месяцев.
Если бы письмо от правительства могло отключить вашу основную базу данных, стали бы вы запускать её без системы отказоустойчивости? Нет. Тем не менее, большинство команд поступает именно так с ИИ.
Многие команды относятся к ИИ как к электричеству. Вы щелкаете выключателем и ожидаете света. Вы не задумываетесь об источнике или о том, что произойдет, когда питание отключится. Вы выбираете модель, жестко прописываете эндпоинт и выпускаете продукт.
Это не инженерия. Это архитектура, основанная на надежде.
Модели могут исчезнуть по следующим причинам:
- Регуляторные причины
- Изменения в политике
- Геополитические проблемы
Ситуация с Anthropic не была багом или сбоем инфраструктуры. Это был регуляторный «выключатель».
Вы должны закладывать отказоустойчивость на уровне слоя моделей. Используйте следующие паттерны:
- Абстрагируйте вызовы моделей. Используйте интерфейс, чтобы вашему приложению было неважно, какой провайдер предоставляет ответ.
- Используйте нескольких провайдеров. Смена провайдера должна быть изменением конфигурации, а не полной переработкой кода.
- Используйте модели с открытыми весами (open-weight). Если вы запускаете модель самостоятельно, никто не сможет отключить её удаленно. Такие модели работают как генератор, когда в сети гаснет свет.
- Реализуйте постепенную деградацию (graceful degradation). Меньшая или более старая модель лучше, чем неработающее приложение.
Отслеживайте уровень ошибок. Если он резко возрастает, «выбивайте пробки» и перенаправляйте трафик на резервный вариант (fallback).
Относитесь к своему ИИ как к любой другой критически важной производственной зависимости. Проектируйте систему с расчетом на сбои.
Предполагает ли ваша архитектура, что ваш провайдер может выйти из строя? Если нет, вы в зоне риска.
Встроили ли вы резервный вариант с несколькими провайдерами в свой стек? Расскажите в комментариях.
Источник: https://dev.to/aws/your-ai-provider-is-a-single-point-of-failure-26i2
Дополнительное обучающее сообщество: https://t.me/GyaanSetuAi