ГЛАВА 6. ПЕРСПЕКТИВНЫЕ АРХИТЕКТУРЫ: ОТ МОНОЛИТА К ОРКЕСТРУ

6.1 Проблема одной модели

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

ПОЧЕМУ ОДНА МОДЕЛЬ НЕЭФФЕКТИВНА

Итак, монолитная модель, пытающаяся объять необъятное, упирается в железобетонный потолок: простые запросы она обрабатывает с избыточной роскошью, а сложные - с трудом. Выход?

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

Это роутинг моделей - первая ступень эволюции от монолита к оркестру.

Вы ставите лёгкий классификатор перед пулом моделей, и он решает: «Эту задачку решит малыш на 1 млрд параметров, а эту пусть разбирает монстр на 70 млрд». Звучит просто, но дьявол - в деталях. Например, где взяли обещанные 70% экономии и всегда ли они достижимы? Давайте честно разберём цифры, сюрпризы и то, как не промахнуться с порогом.

6.2 Роутинг моделей (Model Routing)

Перед запросом ставится классификатор (роутер), который оценивает:

· сложность задачи;

· необходимую длину контекста;

· требуемую специализацию (код, логика, креатив).

И направляет запрос к наиболее подходящей модели. Это даёт экономию ресурсов до 70%.

Цифра 70% звучит красиво, но инженер внутри вас должен спросить: откуда она взялась и применима ли она к моему случаю? Давайте разберёмся честно.

70% экономии - это не магия и не гарантия. Это порядковая оценка для идеализированного сценария, где:

· 80% запросов - простые (приветы, погода, простые факты)

· 15% - средней сложности (работа с документами)

· 5% - сложные (математика, кодинг, логистика)

И где у вас есть роутер, который безошибочно определяет сложность запроса.

Цифра 70% достигается, когда:

· Роутер работает с высокой точностью (>95%)

· Есть кэширование частых запросов

· Лёгкая модель достаточно хороша для большинства задач

Реальность: цифры могут быть скромнее

На практике вас ждут сюрпризы:

Сюрприз 1: Роутер ошибается

Даже хороший классификатор ошибается в 5–10% случаев. Отправить сложный запрос в лёгкую модель - получить плохой ответ и испортить пользовательский опыт. Отправить простой запрос в тяжёлую модель - съесть бюджет. Реальная экономия с учётом ошибок падает до 40–50%.

Сюрприз 2: Доля сложных запросов выше

Если вы делаете продукт для программистов, у вас может быть не 5% сложных запросов, а 50%. Тогда экономия будет совсем другой.

Сюрприз 3: Стоимость лёгкой модели не так уж мала

GPT-3.5 стоит дешевле GPT-4, но не бесплатно. А если вы используете open-source модель на своих серверах, у вас появляются фиксированные расходы на железо.

Сюрприз 4: Длинные контексты убивают экономию

Простой запрос, но с длинным контекстом (например, «переведи этот 100-страничный документ») может съесть бюджета больше, чем сложный, но короткий.

Поэтому 70% - это ориентир, к которому можно стремиться, но не гарантия. Ваша реальная экономия зависит от:

· Распределения запросов по сложности (измеряйте!)

· Точности роутера (тестируйте!)

· Разницы в цене между лёгкой и тяжёлой моделью (считайте!)

· Доли длинных контекстов (учитывайте!)

Лучший подход: соберите лог реальных запросов, разметьте 1000 примеров, постройте ROC-кривую вашего роутера и только потом считайте экономию. Тогда цифры будут вашими, а не с потолка.

ROC-кривая (Receiver Operating Characteristic) - это график, который показывает, как часто ваш роутер ошибается в зависимости от выбранного порога срабатывания. Представьте, что вы решаете, при каком уровне сложности отправлять запрос на лёгкую модель. Если порог слишком низкий, вы отправите на лёгкую модель много сложных запросов - качество упадёт. Если порог слишком высокий, вы отправите на тяжёлую модель много простых запросов - бюджет улетит в космос. ROC-кривая помогает найти золотую середину. Чем ближе кривая к левому верхнему углу графика, тем лучше роутер. Построить её можно с помощью любого инструмента для машинного обучения (sklearn, scikit-learn) на ваших размеченных данных.

КАК УСТРОЕН УМНЫЙ РОУТЕР

Роутер - это только начало.

Если вы присмотритесь, то увидите, что задача разделения запросов между моделями поразительно напоминает проблему, которую веб-разработка решила лет десять назад: переход от монолитного бэкенда к микросервисам. Там тоже был один большой сервер, который делал всё - и тоже страдал от неэффективности.

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