Когда дообучение оправдывает затраты, а промпт уже нет

Где промпт уже не тянет

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

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

Один из самых заметных сигналов - рост few-shot блока. Команда сначала добавляет 2 примера, потом 5, потом 12. Запрос становится дороже, медленнее и хрупче. Стоит убрать один пример или поменять порядок, и ответ меняется сильнее, чем должен.

Обычно это выглядит так:

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

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

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

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

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

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

Какие задачи чаще выигрывают от дообучения

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

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

Хороший пример - поддержка или бэк-офис. Компания получает тысячи похожих обращений, и каждое нужно отнести к одной из 10-20 меток, указать приоритет и отправить в нужную очередь. Если оператор потом исправляет даже 2-3% ответов, потери быстро становятся заметными.

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

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

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

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

Когда few-shot еще стоит пробовать

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

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

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

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

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

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

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

Как принять решение по шагам

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

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

Дальше прогоните один и тот же набор через три варианта: базовую модель, ту же модель с длинным промптом и ту же схему с few-shot. Сравнивать разные наборы нельзя. Иначе вы будете мерить не подход, а удачу.

Хорошая проверка выглядит просто:

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

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

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

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

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

Пример на задаче поддержки

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

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

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

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

Когда такие ошибки повторяются каждый день, дообучение уже выглядит не как эксперимент, а как рабочий шаг. Допустим, банк получает 6 000 обращений в сутки, и операторы исправляют даже 10% маршрутизации вручную. Если на одну правку уходит 30-40 секунд, команда теряет много часов в неделю только на перекладывание тикетов между темами.

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

Хороший момент для старта выглядит так: промпт и few-shot подняли точность до приемлемого уровня, но дальше движение почти остановилось. Например, база с примерами дала 86%, потом 87%, а ручных правок все еще слишком много. Если после дообучения точность растет до 93-95%, эффект виден сразу: очередь движется быстрее, повторной маршрутизации меньше, а нагрузка на операторов падает.

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

Что подготовить до старта

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

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

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

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

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

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

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

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

Ошибки, из-за которых проект не окупается

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

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

Другая частая ошибка - смотреть только на среднюю метрику. Рост с 88% до 91% может выглядеть хорошо, но не говорить почти ни о чем, если модель все так же ошибается в дорогих случаях. Для банка ошибка в обычном вопросе клиента и ошибка в ответе по KYC стоят по-разному. Для клиники перепутанный служебный тег и неверная маршрутизация обращения тоже не равны по цене.

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

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

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

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

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

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

Перед стартом полезно коротко ответить на пять вопросов.

• Есть ли у вас тест, на котором промпт и few-shot уже стабильно не дотягивают до нужного уровня?
• Даст ли разница в качестве заметный эффект для бизнеса?
• Кто будет обновлять датасет, следить за версиями и проверять деградацию?
• Можно ли откатиться за один день, а лучше за один час?
• Зафиксированы ли бюджет и срок пилота заранее?

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

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

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

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

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

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

Рабочая последовательность простая. Сначала прогоните один и тот же набор через 3-5 моделей. Потом доведите промпт до нормального состояния: четкая инструкция, few-shot, строгий формат ответа. После этого посчитайте, сколько ошибок остается и сколько они стоят бизнесу. Если все разумные промпты уперлись в потолок, запускайте пилот дообучения. В конце сравните итог не только по качеству, но и по цене, задержке и сложности поддержки.

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

Если вам нужен open-weight вариант ради низкой задержки, data residency или собственной настройки модели, сравните его с frontier-моделями на том же наборе. На одних задачах open-weight модель после дообучения выигрывает по цене и скорости. На других сильная внешняя модель дает тот же результат без обучения, и это честно дешевле.

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

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