Yuki Tanaka, ML Engineer

Все по умолчанию берут самую большую модель. GPT-4, Claude Opus, Gemini Ultra — предположение в том, что больше параметров означает лучшие результаты. Я тоже так думала. Потом начала реально измерять.

Последний год я запускала продакшн ML-системы в трёх разных компаниях. Паттерн консистентен: маленькие модели превосходят большие в большинстве реальных применений. Не потому что они умнее, а потому что "лучше" в продакшне означает что-то другое, чем "лучше" на бенчмарках.

Налог на латентность

Большие модели медленные. Не драматически медленные — мы говорим о секундах, не минутах. Но эти секунды накапливаются.

Я работала над ботом клиентской поддержки в прошлом году. Мы начали с GPT-4, потому что хотели лучшие ответы. Среднее время ответа: 3.2 секунды. Удовлетворённость пользователей была посредственной. Мы предположили, что AI-ответы недостаточно хороши, и потратили недели на твикинг промптов.

Потом попробовали GPT-3.5. Качество ответов упало может на 10% по нашим evals. Время ответа упало до 0.8 секунд. Удовлетворённость пользователей выросла на 34%.

Пользователям было плевать на тонкие улучшения качества от GPT-4. Им было важно ожидание. Слегка худший ответ, доставленный быстро, побил слегка лучший ответ, доставленный медленно.

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

Реальность расходов

Позвольте поделиться реальными числами из пайплайна обработки документов.

Начальная имплементация: GPT-4 для всего. Месячная стоимость: $12,400. Мы обрабатывали около 50,000 документов в месяц, каждый требовал извлечения, классификации и суммаризации.

Оптимизированная имплементация: GPT-4 только для сложных edge cases (~8% документов), GPT-3.5 для стандартной обработки, и fine-tuned маленькая модель для классификации. Месячная стоимость: $1,100.

Влияние на качество: по сути никакого. Edge cases, которым нужен был GPT-4, всё ещё получали GPT-4. Рутинные cases не выигрывали от большей capability — они уже решались хорошо меньшими моделями.

Это 91% снижение расходов без измеримой потери качества. Экономия профинансировала всю нашу ML-инфраструктуру за квартал.

Когда больше реально хуже

Вот что-то контринтуитивное: большие модели иногда работают хуже на узких задачах.

У нас была задача извлечения структурированных данных — вытаскивание конкретных полей из инвойсов. GPT-4 был креативным. Он выводил пропущенные значения, экстраполировал из контекста, делал educated guesses. Отличные capabilities для общего reasoning. Ужасные для извлечения данных, где нам нужно точно то, что на документе, не больше.

Маленькая, fine-tuned модель извлекала поля механически. Никакой креативности, никакого inference. Просто pattern matching. Точность была выше, потому что она не пыталась быть умной.

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

Преимущество fine-tuning

У маленьких моделей есть ещё одна суперсила: их можно fine-tune дёшево.

Fine-tuning GPT-4 недоступен. Fine-tuning Claude недоступен. Для самых больших моделей ты застрял с prompting. Промпты мощны, но ограничены — есть предел того, сколько поведения можно специфицировать в context window.

Маленькие модели можно fine-tune на твоих конкретных данных. Модель на 7B параметров, fine-tuned на 10,000 примерах твоего точного use case, часто бьёт модель на 175B с общими инструкциями в промпте. Маленькая модель буквально выучила твою задачу; большая модель импровизирует.

Мы fine-tuned Llama 2 7B для задачи медицинского кодирования. Из коробки она работала ужасно — медицинское кодирование требует специализированных знаний, которых у неё не было. После fine-tuning на 50,000 размеченных примерах она превзошла GPT-4 на нашем test set, работая на одной GPU.

Стоимость fine-tune: около $200 вычислений. Стоимость запуска: доля от API-pricing. Производительность: лучше моделей в 25 раз больше.

Когда реально использовать большие модели

Я не говорю, что большие модели бесполезны. У них есть реальные преимущества в конкретных ситуациях.

Сложное рассуждение с новыми проблемами. Если задача требует многошагового reasoning о вещах, которые модель раньше не видела, больше параметров помогает. Юридический анализ необычного пункта контракта, креативное решение инженерной проблемы, нюансированная интерпретация неоднозначного текста — это выигрывает от масштаба.

Низкий объём, высокие ставки решения. Если ты обрабатываешь десять документов в день и каждый значительно важен, разница в стоимости между моделями пренебрежима. Используй лучшее доступное.

Bootstrapping перед fine-tuning. Большие модели отличны для генерации обучающих данных для меньших моделей. Используй GPT-4 для разметки примеров, fine-tune маленькую модель на этих метках, деплой маленькую модель. Большая модель enables маленькую.

User-facing разговоры, требующие широких знаний. Чатботы, которым нужно обсуждать всё, что пользователь может спросить, выигрывают от общей capability. Ты не можешь fine-tune для разговоров, которые не предвидел.

Framework для решений

Вот как я выбираю модели для новых проектов:

Начни с самой маленькой модели, которая может сработать. Для большинства задач это что-то типа GPT-3.5 или Claude Haiku. Запусти свой evaluation suite. Если производительность приемлема, ты закончил.

Если производительность не приемлема, диагностируй почему. Это проблема capability (модель не может делать задачу) или проблема knowledge (модель недостаточно знает о твоём домене)? Проблемы capability нужны большие модели. Проблемы knowledge нужен fine-tuning.

Рассмотри гибридные подходы. Направляй лёгкие cases на маленькие модели, тяжёлые cases на большие модели. Это требует построения классификатора, но простой часто работает. "Если input длиннее X или содержит Y, используй большую модель" может захватить большинство edge cases.

Измеряй что важно. Бенчмарк-производительность нерелевантна, если твоим пользователям важна латентность. Стоимость за транзакцию важнее стоимости за токен. End-to-end точность важнее component-level производительности.

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

Некомфортная правда

Большинство AI-систем over-provisioned. Команды по умолчанию берут самую большую модель, потому что не хотят быть обвинёнными в проблемах качества. "Мы использовали GPT-4" — это защита от критики. Никого не увольняют за выбор премиум-опции.

Но команды, которые шипят лучшие продукты, не оптимизируют defensibility. Они оптимизируют user experience и бизнес-результаты. Иногда это означает самую большую модель. Часто это означает самую маленькую модель, которая работает.

Вопрос не "какая модель лучше?" Вопрос "какая модель лучше для этой конкретной задачи, в этом масштабе, с этими ограничениями?" Ответ редко самая большая из доступных.

Yuki Tanaka — ML Engineer, которая строила продакшн AI-системы для fintech, healthcare и e-commerce компаний. Она фокусируется на том, чтобы делать AI практичным и cost-effective, а не впечатляющим на бенчмарках.