Маршрутизируйте по сложности, а не по умолчанию

В перестройке Siri зарыто решение об архитектуре, достойное большего внимания, чем заголовок про Gemini. Новая Siri использует трёхуровневую систему маршрутизации, которая решает, где обработать каждый запрос. Простое — поставить таймер, включить песню — работает целиком в телефоне, данные с устройства не уходят. Умеренно сложные запросы идут в собственный Private Cloud Compute Apple, обрабатываются и тут же забываются. И только самое тяжёлое рассуждение уходит в гигантскую модель Gemini в облаке Google.

Заметьте, чего Apple не сделала: не выбрала одну модель и не направила в неё всё. И это урок, потому что выбрать одну модель на всё — ровно то, что делает большинство строящих ИИ-продукты, — и это тихо неверный дефолт сразу по двум осям.

Одна модель на всё неверна дважды

Отправьте каждый запрос в одну большую модель — и сделаете две ошибки одновременно.

Первая — стоимость. Большинство запросов лёгкие. «Переформатируй дату», «спам ли это письмо», «суммируй один абзац» — им передовая модель нужна не больше, чем сложению нужен суперкомпьютер. Маршрутизировать их в самую дорогую модель — значит платить премиальные цены за тривиальную работу, на каждом вызове, вечно. Исследования о маршрутизации по сложности показывают, что вызовы к большой модели можно срезать примерно на 40% без падения качества, просто отправляя лёгкое в маленькую модель и эскалируя, только когда правда сложно. Это идея дешёвой модели на бо́льшую часть работы, превращённая в инфраструктуру.

Вторая ошибка — экспозиция. Часть ваших запросов содержит чувствительные данные — здоровье, финансы, личные сообщения. Отправлять их в стороннюю облачную модель нормально для поиска рецепта и серьёзная проблема для медкарты. Одна модель на всё значит, что самые чувствительные данные едут той же дорогой, что и самые тривиальные, — наружу к тому, кто хостит модель. Весь смысл Apple в том, что таймер и приватный запрос не должны ехать одной дорогой.

Маршрутизация чинит и то и другое разом. А две оси — насколько это сложно и насколько чувствительно — это и есть весь дизайн.

Два вопроса, которые решают маршрут

Прежде чем запрос попадёт в модель, спросите о нём две вещи:

Насколько он сложный? Маршрутизируйте по сложности. По умолчанию отправляйте всё в самую дешёвую и быструю модель, что правдоподобно справится, и эскалируйте к большей только когда маленькой не хватает. Это паттерн «каскад»: сначала локальная или дешёвая, повышение к дорогой при неудаче — а не наоборот. Дорогая модель становится исключением, а не дефолтом, и счёт следует за этим.

Насколько он чувствительный? Маршрутизируйте по данным, а не только по цене. По-настоящему чувствительные запросы должны оставаться на самом приватном уровне, что у вас есть, — на устройстве или своей инфраструктуре — и, что важно, никогда молча не откатываться в публичное облако, если приватный путь занят. Дисциплина здесь — «fail closed»: не можете обработать чувствительное приватно — отказывайте, а не тихо шлите третьей стороне. Apple обеспечивает это анонимизацией и контрактами, запрещающими Google учиться на запросах пользователей; ваша версия может быть проще, но принцип тот же — чувствительность решает путь, а безопасный отказ — это «не надо», а не «всё равно отправь».

Почему большинство строителей это пропускают

Маршрутизация — больше работы, чем вызов одного эндпоинта, так что честная причина пропуска в том, что одна модель на всё легко отгружается. Подключил передовую модель, она обрабатывает каждый случай, готово. Работает — просто дорого и дырявит так, что не видишь, пока не придёт счёт или утечка.

Но трёх уровней Apple для выгоды вам не нужно. Окупается даже грубая версия: дешёвая модель как дефолт, эскалация к сильной, когда проверка уверенности или тип задачи говорит «это сложно», и жёсткое правило, что помеченные чувствительными запросы остаются на пути, который контролируете вы. Это несколько часов сантехники, которые ощутимо режут стоимость и одновременно сжимают вашу поверхность экспозиции. Изощрённость придёт позже; важна форма — по умолчанию дёшево и приватно, эскалация намеренно.

Суть

Яркая часть истории Siri — что Apple арендовала мозг Google. Полезная часть — что Apple поставила перед этим мозгом: маршрутизатор, отправляющий каждый запрос в наименьшее и самое приватное место, что справится, и тянущийся к большой дорогой облачной модели, только когда приходится. Это не роскошь Apple. Это паттерн, который выпадает в тот миг, когда всерьёз относишься к стоимости и приватности, и масштабируется до сольного проекта.

Так что перестаньте по умолчанию слать всё в одну модель. Задайте два вопроса — насколько сложно, насколько чувствительно — и пусть ответы выберут маршрут. Бо́льшая часть вашего трафика лёгкая и ничем не примечательна, и маршрутизировать её соответственно — это разница между ИИ-продуктом, дешёвым и безопасным по дизайну, и дорогим и открытым по случайности. Одна модель на всё — это не простота. Это дефолт, который вы на самом деле не выбирали.