Метрики в Redis и выбор по P95 уже полноценный circuit breaker, а не простой fallback. Синхронизация между инстансами решается через Redis же, но тогда добавляется задержка на каждый запрос. Компромисс, обновлять метрики асинхронно, а для выбора использовать кэшированную статистику с небольшим TTL. Тогда инстансы не ходят в Redis на каждый запрос, но данные остаются согласованными в пределах, скажем, 5-10 секунд

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

Нет, помню, что эмбеддинги разных моделей не совместимы. У разных LLM свои пространства представлений, и векторы одной модели нельзя просто скормить другой.

Поинтересовался у самой ИИ. Для RAG-подхода это не проблема. Вы не подставляете эмбеддинги одной модели в другую. Вы храните эмбеддинги, полученные одной выбранной моделью (например, OpenAI text-embedding-3-small), а при смене модели генерации используете те же самые эмбеддинги для поиска по базе. Модель генерации получает уже найденные текстовые фрагменты, а не чужие векторы. Так совместимость не требуется.

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