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

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

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

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

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

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

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

Тревожные признаки обычно выглядят так:

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

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

Что проверить в данных до старта

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

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

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

Где данные ломают результат

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

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

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

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

Когда задачу закрывает промпт

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

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

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

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

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

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

Когда лучше помогает роутинг моделей

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

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

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

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

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

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

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

Как принять решение за один спринт

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

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

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

Потом прогоните базовый промпт на 2-3 моделях. Это полезнее, чем неделями спорить, какая модель лучше в теории. Если у команды уже есть совместимый с OpenAI шлюз вроде AI Router, такой тест проходит быстро: меняется модель, а код и SDK остаются теми же.

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

Для каждого варианта полезно записать четыре вещи:

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

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

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

Пример: обращения банка на русском и казахском

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

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

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

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

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

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

Ошибки, которые ведут в лишний цикл обучения

Лишний цикл обучения почти всегда начинается не с плохой модели, а с плохой диагностики. Команда видит просадку по ответам и сразу собирает датасет для fine-tuning. Через две недели выясняется, что модель училась на сырых логах с дублями, шумом, личными данными и противоречивой разметкой. Такой запуск закрепляет хаос, а не исправляет его.

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

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

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

Тревожный набор обычно выглядит так:

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

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

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

Быстрый чек-лист перед стартом

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

Пройдите по этому списку до старта:

1. Сформулируйте одну ошибку, которую хотите убрать. Не "модель отвечает слабо", а "путает тип обращения" или "не держит JSON в 18% случаев".
2. Соберите чистый набор для оценки. Достаточно 100-300 примеров, если они размечены одинаково и отражают живой поток.
3. Дайте модели нормальную опору: хороший системный промпт, несколько сильных примеров и жесткий формат ответа.
4. Сравните хотя бы 2-3 модели на одном и том же наборе. Иногда задаче не нужно дообучение, ей нужна другая модель или простой роутинг.
5. Посчитайте цену решения. Если обучение съест две недели работы команды, а прирост будет на пару пунктов, обмен слабый.

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

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

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

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

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

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

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

Если нужно быстро сравнить провайдеров и модели без переписывания кода, тот же тестовый набор можно прогнать через AI Router. Это единый совместимый с OpenAI API-шлюз: меняется только base_url, а SDK, код и промпты можно оставить без изменений. Для команд в Казахстане и Центральной Азии это еще и удобный способ проверить сценарии с хранением данных внутри страны, маскированием PII, аудит-логами и локально размещенными моделями с открытыми весами, если такие требования есть у бизнеса.

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