Когда AI-фича упирается не в модель, а в маршрут

Microsoft сегодня довольно прямо пишет то, о чем в продуктовых командах часто вспоминают только после первого инцидента: у AI-сервиса есть обычные backend-ограничения. Стоимость. Доступность. Латентность.

В свежем посте про Microsoft.Extensions.AI они добавили примитивы для маршрутизации и failover: можно отправлять запросы по содержимому сообщения, переключаться на другой провайдер, если первый упал, и собирать собственную политику поверх IChatClient. Источник: Routing and Failover for Microsoft.Extensions.AI

И это, на мой взгляд, важнее самой новости про новые типы. Потому что в проде почти никогда не бывает "одной идеальной модели". Бывает дешевый провайдер для простых запросов, более дорогой для сложных, отдельный путь для медленных операций, отдельный fallback на случай деградации. А еще бывают лимиты, очереди, сетевые сбои и очень неприятная привычка AI отвечать медленнее именно тогда, когда система уже под нагрузкой.

Я бы смотрел на это так: AI в backend перестает быть "фичей в чате" и становится частью архитектуры. А значит, к нему применяются старые правила. Нужны таймауты. Нужны метрики качества. Нужны тесты на выбор маршрута. Нужен явный ответ на вопрос, что делать, если основной провайдер недоступен.

Самая частая ошибка здесь, как обычно, не в модели, а в попытке сделать "умно" без правил. Тогда роутинг начинает жить своей жизнью, а команда узнает о проблеме уже на реальном трафике.

Для меня это хороший маркер: AI в .NET наконец-то начинает выглядеть не как демонстрация, а как инженерная задача.

Вы в своих проектах уже разделяете AI-запросы по риску и стоимости, или пока все еще идет в один универсальный клиент?

#dotnet #backend #AI #архитектура