Дистилляция промптов: когда меньшая модель держит результат

Где вы переплачиваете за сложный промпт

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

Так бывает в поддержке, модерации, разборе обращений, классификации лидов и извлечении полей из текста. Промпт занимает полстраницы: роль, правила, запреты, формат JSON, примеры. А ответ простой - выбрать категорию, поставить приоритет, вернуть 3-5 полей. Для такой работы крупная модель часто избыточна.

Это особенно заметно там, где системе нужен строгий формат, а не длинное объяснение. Если задача сводится к аккуратному ответу по инструкции, дорогая модель начинает напоминать грузовик для доставки одного пакета. Доедет без проблем, но счет будет лишним.

Обычно на переплату указывают несколько признаков:

• сценарий почти не меняется от запроса к запросу;
• вход короткий и похожий по структуре;
• на выходе нужен фиксированный JSON, тег или короткий текст;
• важна точность по правилам, а не стиль формулировки;
• один и тот же промпт уходит в модель много раз за день.

Представьте поддержку интернет-магазина. Пользователь пишет: "Где мой заказ? Оплатил вчера". Внутри у вас длинный промпт на 700-1000 токенов с правилами маршрутизации, метками срочности и форматом ответа. Большая модель читает весь этот текст, а потом возвращает что-то вроде {"category":"delivery","priority":"medium","needs_human":false}. Если таких обращений 10 000 в день, цена растет быстрее, чем польза от каждого ответа.

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

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

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

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

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

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

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

Простой пример - обращение в поддержку: "Списали деньги дважды, номер заказа 54182". Малой модели можно поручить сразу две вещи: поставить метку "двойное списание" и вытащить номер заказа. Если тексты похожи друг на друга, качество обычно держится ровно.

То же самое с переписыванием. Когда нужно сократить ответ с 700 символов до 250, убрать канцелярит и не потерять смысл, большая модель редко дает заметный плюс. Разница в цене при этом бывает очень заметной.

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

Если у вас есть маршрутизация моделей через единый API, типовые сценарии удобно сразу отправлять на более дешевые open-weight модели, а спорные запросы оставлять крупным. Такой подход не требует ломать весь стек и обычно дает внятный баланс цены и качества.

Ориентир простой: если два человека по инструкции быстро договорятся о правильном ответе, малая модель тоже часто справится. Если им придется долго спорить, экономить рано.

Когда качество остается на месте

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

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

Лучше всего переносятся классификация, извлечение полей, нормализация текста, короткий роутинг запросов и проверки по простым правилам. Ошибку в таких задачах видно сразу. Она не прячется в красивой формулировке.

Проверка тоже несложная. Возьмите 100-200 реальных примеров и посмотрите, можно ли описать правильный ответ без вкусовщины. Если эксперт быстро говорит: "тут метка A, тут B, тут нужен только номер договора", задача подходит. Если два сильных сотрудника спорят почти о каждом пятом кейсе, меньшая модель начнет ошибаться еще чаще.

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

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

Как перенести сценарий по шагам

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

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

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

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

Затем прогоните набор через 2-3 меньшие модели и смотрите не только на средний балл, а на профиль ошибок. Одна модель чаще путает классы, другая ломает JSON, третья слишком охотно отказывает. Для дистилляции это важнее, чем абстрактное "на 2% лучше".

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

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

Пример с поддержкой и классификацией

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

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

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

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

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

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

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

Где схема ломается

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

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

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

Технически перенести трафик на другую модель легко. Но простое переключение маршрута не означает, что сценарий готов к дешевой модели. Узкое место почти всегда в данных и проверке, а не в API.

Частая ошибка - смотреть только на средний балл. Среднее скрывает хвост дорогих ошибок. Если из 1000 запросов только 3% стали хуже, это может выглядеть терпимо. Но если именно в этих 3% лежат жалобы, возвраты, VIP-кейсы или обращения с персональными данными, потери окажутся заметнее экономии.

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

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

Если после снижения цены команда тратит лишние 20 минут на каждые 50 обращений, экономия, скорее всего, мнимая. Дешевая модель окупается только там, где вы держите под контролем редкие ошибки, длину контекста и стоимость ручного разбора.

Как считать цену без самообмана

Цена запроса почти никогда не равна цене ответа. Когда сценарий переносят на меньшую модель, команда часто смотрит только на тариф за токены и делает слишком ранний вывод. Реальная стоимость складывается из мелочей: длинного входа, многословного выхода, ретраев, проверок и эскалации части трафика на большую модель.

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

Что входит в честную цену

Удобнее считать не один вызов, а тысячу рабочих запросов. В честную цену входят:

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

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

Пример простой. Допустим, малая модель обработала 1000 запросов поддержки. 150 раз случился ретрай, 90 ответов не прошли JSON-валидацию, еще 60 кейсов оператор разбирал вручную по две минуты, а 180 запросов система отправила на большую модель. На бумаге малая модель почти бесплатна. В полной цепочке экономия уже может оказаться не 70%, а 25%.

Смотрите и на задержку. Среднее в 1,4 секунды может выглядеть хорошо, но p95 в 8 секунд ломает всю картину: пользователи жмут кнопку повторно, фронт ловит таймауты, очередь растет, а число ретраев увеличивает счет. Для онлайн-сценариев p95 часто важнее средней цифры.

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

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

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

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

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

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

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

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

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

Что делать дальше в проде

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

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

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

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

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

Если вы сравниваете несколько моделей через один эндпоинт, процесс идет заметно быстрее. Для таких проверок RU LLM удобен тем, что можно менять base_url на api.rullm.com и продолжать использовать те же SDK, код и промпты. Это упрощает эксперименты с маршрутизацией и помогает быстрее понять, где малая модель действительно окупается, а где экономия только кажется.

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