Django/LLM, fallback при падении провайдера и подмене модели
Один из практических узлов в LLM-агрегаторе находится в точке, где выбранная модель не отвечает. Пока интеграция идет по счастливому сценарию, кажется, что достаточно просто отправить запрос в провайдера и вернуть текст. Но реальная система живет хуже. Модель может оказаться временно недоступной, провайдер может вернуть ошибку маршрута, а иногда ответ вообще приходит уже от другого внутреннего варианта.
В этот момент у продукта есть два плохих пути. Либо уронить запрос и отдать ошибку пользователю. Либо сделать fallback, но не сообщить фронту, какая модель реально сработала. Первый вариант делает систему хрупкой. Второй ломает согласованность между интерфейсом, backend и аналитикой.
fallback должен жить на backend, переключение должно идти по управляемому пулу живых моделей, а ответ должен содержать фактическую модель, которая реально отработала. Именно это превращает деградацию из скрытой проблемы в нормальную часть архитектуры.
Витрина проекта: AI Chat github
Проект: AI Chat
Stepik: AI на Django и Next II