Идея
Резервная LLM-модель может вернуть ответ по той же JSON-схеме, но иначе выполнить задачу и тем самым изменить поведение продукта. Поэтому совместимость API недостаточна: качество моделей нужно проверять отдельно для каждой задачи на собственных тестовых данных. Допустимость переключения следует задавать в политике конкретного маршрута, а не в глобальной настройке или адаптере провайдера. Если ухудшение качества неприемлемо, лучше вернуть ошибку; если переключение разрешено, ответ должен сообщать, какая модель его подготовила и было ли качество снижено. Повторный запрос к той же модели и переход на другую модель также нужно учитывать раздельно.
Вывод
Автор предлагает такой подход разработчикам AI-сервисов, особенно там, где ответы влияют на документы, деньги или автоматические решения. В статье приведены иллюстративные примеры и проект архитектуры, но нет данных о внедрении или достигнутых результатах. Главный вывод: доступность нельзя повышать ценой скрытого изменения качества ответа; резервные модели нужно проверять и применять по правилам конкретной задачи.