Когда маленькая модель лучше большой в рабочих задачах

Почему команды берут слишком большую модель

Команды часто выбирают самую сильную модель после пары удачных тестов. Логика простая: если она справилась со сложным примером, значит справится и со всем остальным. На старте это и правда выглядит безопасно.

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

Если у вас уже есть единый OpenAI-совместимый эндпоинт, соблазн еще сильнее. Поменяли base_url, все заработало, и трогать схему больше не хочется. Для запуска это удобно. Для реальной нагрузки - не всегда.

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

Из-за этого команды часто смотрят почти только на качество ответа в демо. Это полезно, но этого мало. Если не считать цену, задержку и длину ответа, картина выходит неполной. Дорогая модель нередко пишет больше, чем нужно. Лишние токены поднимают стоимость каждого запроса, а более долгая генерация увеличивает задержку. На маленьком пилоте это почти не видно. На большом потоке разница быстро становится дорогой.

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

Какие задачи маленькая модель закрывает без потерь

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

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

То же самое работает для извлечения полей. Если сообщение содержит номер заказа, дату, сумму или ИИН, маленькая модель обычно справляется не хуже большой, когда формат ответа задан заранее. Она не тратит токены на лишний текст. Она просто заполняет структуру.

Короткая проверка факта тоже редко требует большую модель. Например, в обращении нужно понять, упомянул ли клиент отмену платежа, приложил ли чек, назвал ли филиал, указал ли срок доставки. Это задача уровня "да/нет" или "найди фрагмент". Здесь важнее четкий промпт и хороший формат ответа, чем дорогой инференс.

Маленькая модель обычно подходит, если задача выглядит так:

• есть фиксированный набор классов
• нужно достать несколько полей из одного текста
• ответ должен быть коротким JSON без свободного текста
• ошибки чаще связаны с шумными данными, а не со слабым рассуждением

Простой пример: заявка в поддержке интернет-магазина - "Не пришел возврат по заказу 48391, сумма 12 500 тг, оплачивал 3 марта". Большой модели тут почти нечего делать. Маленькая быстро вернет тему обращения, сумму, дату и номер заказа в JSON. На тысячах таких запросов разница в цене и задержке уже заметна.

В таких сценариях команды часто разделяют поток: рутинные задачи отправляют на более дешевые модели, а сложные случаи оставляют более сильным. Если у вас есть единый шлюз вроде AI Router, это особенно удобно: можно менять маршрутизацию отдельно, не переписывая SDK, промпты и основной код.

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

Где большая модель все же нужна

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

Это особенно заметно в нескольких типичных случаях:

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

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

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

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

Объяснение решения тоже часто требует модель классом выше. Метка "отклонить" сама по себе мало помогает. Сотруднику нужен короткий и ясный разбор: какое правило сработало, где это видно в документе и чего не хватило. Если объяснение слабое, команда все равно уходит в ручную проверку.

На практике не нужно отправлять весь поток на дорогую модель. Намного разумнее держать короткие и типовые запросы на маленькой модели, а сложные случаи поднимать выше по маршруту. В AI Router это удобно делать через один OpenAI-совместимый эндпоинт: простые задачи можно направлять на более дешевые модели, а длинные документы, спорные кейсы и tool calling - только туда, где они действительно нужны.

Как проверить это на своей задаче

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

Начните с набора из 100-300 реальных примеров. Не берите только чистые случаи. Добавьте шум: короткие сообщения, опечатки, смешанный язык, неполные формы, спорные заявки. Если вы проверяете классификацию текстов LLM или извлечение полей LLM, именно такие примеры чаще всего ломают продакшен.

Дальше зафиксируйте один формат ответа для всех моделей. Для заявки в поддержку это может быть JSON с полями category, priority, language, need_human_review. Формат должен быть одинаковым, иначе вы сравните не модели, а разные способы ответа.

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

Смотреть стоит не только на качество. Обычно хватает четырех метрик:

• точность на вашем наборе
• стоимость инференса LLM на один запрос и на 1000 запросов
• p95 задержка, а не только среднее время
• доля случаев, где модель ломает формат ответа

Иногда вывод виден сразу. Большая модель ошибается чуть реже, но отвечает в 3-5 раз дольше и стоит заметно дороже. Для короткой задачи это плохой обмен.

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

Если у вас уже есть шлюз к нескольким моделям, тест становится проще: вы меняете модель, а код и формат запроса не трогаете. В AI Router для этого достаточно переключать маршрут на стороне шлюза, не меняя интеграцию. Но даже без него принцип тот же: сначала честный набор данных, потом одинаковый промпт, и только после этого выводы.

Пример: разбор заявок в поддержке

Представьте обычный поток писем в поддержку. Клиент пишет: "Не проходит списание по договору 458731, деньги на счете есть". Команде не нужен развернутый анализ письма. Ей нужно быстро понять тему обращения и вытащить номер договора в CRM.

На такой задаче хорошо видно, почему маленькая модель часто выгоднее большой. Большая reasoning-модель любит объяснять ход мысли, перечислять возможные причины и предлагать шаги для оператора. Звучит убедительно, но для очереди заявок это лишнее. Каждое длинное объяснение тратит время и деньги, а оператору все равно нужен короткий результат: "тема - платеж", "договор - 458731".

Маленькая модель обычно справляется с этим быстрее. Если промпт узкий, а формат ответа жесткий, она стабильно отдает тему письма и нужные поля. Для CRM этого достаточно. Когда заявок много, даже экономия в 1-2 секунды на письме быстро превращается в часы за неделю.

Рабочая схема здесь простая:

• маленькая модель читает письмо и возвращает тему обращения и номер договора
• система сразу записывает поля в CRM, если ответ полный и формат верный
• сложные письма уходят в большую модель только по явному правилу
• оператор видит готовую карточку, а не длинный текст от модели

Сложные письма, конечно, бывают. Клиент может прислать OCR-текст со скриншота, смешать две проблемы в одном сообщении или не указать номер договора явно: "проверьте мой прошлый договор, который продлевали весной". Вот тут большая модель действительно полезна. Она лучше держит контекст, аккуратнее разбирает двусмысленность и реже спешит с выводом.

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

Что считать кроме качества ответа

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

Сначала считайте не цену одного вызова, а цену всего потока. Если заявка проходит через классификацию, извлечение полей и короткую проверку, умножайте стоимость на всю цепочку. Потом переводите это в цену 1000 запросов и в месячный счет при вашем реальном объеме. На 50 000 запросов разница может выглядеть мелкой. На миллионах она уже меняет экономику сервиса.

Среднее время ответа тоже мало что говорит. Пользователь чувствует не среднее, а длинные задержки, когда система загружена. Поэтому полезнее смотреть p95 и p99 в пике: утром, после массовой рассылки, в конце рабочего дня. Модель, которая обычно отвечает за 1,2 секунды, но регулярно уходит в 8-10 секунд, ломает процесс сильнее, чем чуть менее точная, но более ровная.

Еще одна частая проблема - формат ответа. Если модель один раз из десяти портит JSON, меняет имя поля или добавляет лишний текст вокруг результата, вы платите дважды: за сам вызов и за повторный запрос. Для извлечения полей это нередко важнее, чем еще 1-2% качества на тестовом наборе.

По каждой модели полезно собирать один и тот же набор метрик:

• цену 1000 запросов на вашей средней длине промпта и ответа
• месячный счет при обычной и пиковой нагрузке
• p95 задержки
• долю ответов со сломанным JSON или пропавшим полем
• долю повторных запросов и их цену

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

Где чаще всего ошибаются

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

Для задач вроде классификации и извлечения это особенно заметно. На чистом наборе кажется, что маленькая модель почти не уступает по качеству и заметно выигрывает по цене. Но если в реальных данных есть пустые значения, русский и казахский в одном сообщении, кривой OCR или длинные хвосты переписки, результат может оказаться совсем другим.

В хороший тестовый набор стоит добавить:

• сообщения с опечатками и жаргоном
• пустые или частично пустые поля
• обрезанные тексты
• длинные заявки с лишними деталями
• редкие случаи, где ошибка дорого стоит

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

Средний балл тоже легко усыпляет. Допустим, модель верно извлекает поле "номер договора" в 97% случаев. Звучит хорошо. Но если оставшиеся 3% приходятся на длинные письма от крупных клиентов, средняя цифра мало о чем говорит. Смотрите не только на среднее, но и на хвост ошибок: где модель молчит, путает поля местами или дает уверенный, но неверный ответ.

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

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

Быстрая проверка перед запуском

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

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

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

Минимальный набор проверок можно оставить совсем коротким:

• одна схема ответа и автоматическая проверка обязательных полей
• плохие примеры в тесте: опечатки, пустые куски, сокращения, шум из чатов
• лимит на токены и длину ответа
• простое правило эскалации в большую модель
• отдельный журнал ошибок и ложных срабатываний

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

Журнал ошибок нужен с первого дня. Сохраняйте входной текст, ответ модели, ожидаемый результат и тип сбоя. Через неделю вы увидите не абстрактные проблемы качества, а повторяющиеся случаи: модель путает ИИН с номером договора, режет адрес, неверно определяет срочность. Это уже нормальный материал для доработки промпта, схемы и маршрутизации.

Что делать дальше

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

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

Рабочая схема проста:

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

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

Если нужно быстро сравнить много моделей без переписывания интеграции, помогает единый шлюз. В AI Router можно менять base_url на api.airouter.kz и продолжать работать с теми же SDK, кодом и промптами. Это удобно, когда вы хотите честно сравнить несколько маршрутов и понять, где маленькая модель уже закрывает нужный уровень качества, а где большая все еще оправдывает цену.

Самый полезный следующий шаг простой: возьмите одну реальную задачу, соберите 100-200 примеров, сравните маленькую и большую модель на одинаковом промпте и оставьте дорогой маршрут только там, где он действительно нужен.