Обновление T‑Pro 2.1: как мы прокачали следование инструкциям и работу с инструментами
---
Команда ML Т‑Банка продолжает развивать линейку собственных LLM. Летом была представлена T‑pro‑2.0 — русскоязычная модель с гибридным подходом к рассуждениям, ориентированная на практическое применение. Следующий шаг — релиз версии T‑pro‑2.1, в которой целенаправленно доработаны два наиболее проблемных места прошлого релиза: точное следование инструкциям (Instruction Following, IF) и корректный вызов инструментов (Tool Calling).
Параллельно мы обновили и линейку T‑lite: модель T‑lite‑2.1 пришла на смену устаревшей версии 1.0. Лёгкая модель традиционно востребована у команд, которым критичны скорость, простота внедрения и возможность локального запуска. В версии 2.1 мы сохранили компактность и быстродействие, но заметно подтянули качество и предсказуемость поведения.
---
Почему мы сосредоточились на IF и Tool Calling
Роль LLM в продуктах меняется: вместо «болтливого чата» модель всё чаще выступает как компонент сложной системы — агент, который:
- строго следует формату ответа;
- вызывает внешние инструменты;
- выполняет верифицируемые шаги;
- укладывается в жёсткие ограничения по задержкам и ресурсам.
Одновременно с этим заметно усилился опенсорс‑ландшафт: появилось много сильных базовых и инструктивных моделей, а значит, выросла и планка ожиданий пользователей. Размытое «в целом умная модель» уже не достаточно — в продакшене критична способность выполнять точные требования и надёжно интегрироваться в пайплайны.
Обновления T‑pro‑2.1 и T‑lite‑2.1 — это не радикальная смена архитектуры, а аккуратная донастройка: меньше промахов в инструкциях, более точный Tool Calling, более выверенный рецепт обучения и, как следствие, — стабильное поведение в реальных сценариях.
---
Что такое T‑pro 2.1 и чем она отличается от 2.0
T‑pro‑2.1 — это инструктивная модель на базе Qwen3‑32B. Ключевая идея: выдавать сильные ответы без огромного reasoning‑трейса, то есть без «тысяч токенов размышлений», которые сложно хранить, логировать и объяснять пользователю.
Мы вдохновлялись философией крупных моделей семейства Qwen3‑Instruct: максимум полезного сигнала — в финальном ответе, а не в бесконечной расшифровке цепочки рассуждений. При этом по сравнению с T‑pro‑2.0:
- модель лучше держит формат (JSON, таблицы, схемы);
- аккуратнее соблюдает явно заданные ограничения;
- надёжнее ведёт себя в агентных сценариях, где важно не «поболтать», а выполнить серию формализованных шагов.
В результате T‑pro‑2.1 в большинстве прикладных задач показывает качество, сопоставимое или выше, чем у моделей, опирающихся на большой reasoning‑бюджет, но выигрывает по скорости и предсказуемости.
---
T‑lite 2.1: лёгкая модель, которая перестала быть «компромиссом»
T‑lite‑2.1 — это обновлённая 8B‑модель, которая заметно прибавила в прикладном качестве, сохранив главные преимущества «лайта»:
- быстрый отклик;
- умеренное потребление памяти и вычислительных ресурсов;
- удобство локального развёртывания.
Если раньше лёгкую линейку часто воспринимали как «облегчённую версию для экспериментов», то в 2.1 мы целенаправленно подводим её к продакшен‑уровню: улучшены IF‑навыки, снижен уровень «галлюцинаций» в простых задачах, Tool Calling стал более детерминированным. Для многих сценариев, где важны latency и стоимость, T‑lite‑2.1 становится рациональным выбором вместо больших моделей.
---
Instruction Following: почему это сложнее, чем кажется
Instruction Following — это не просто «отвечать по делу». Речь о способности модели:
- точно соблюдать формат («верни строго JSON», «только список без комментариев»);
- придерживаться заданной структуры («используй только указанные поля», «не меняй имена ключей»);
- уважать ограничения по длине, стилю, языку и содержанию;
- учитывать несколько независимых требований одновременно.
На практике в продакшене IF часто критичнее, чем «общая осознанность» модели. Ответ может быть грамотно написан, но если нарушен формат или проигнорирована часть инструкции — такой результат невозможно автоматически обработать, и он становится бесполезным для системы.
Поэтому в T‑pro‑2.1 и T‑lite‑2.1 IF выделили в отдельное направление работы: от специализированного датасета до отдельного RL‑этапа обучения с верифицируемым ревардом.
---
Как мы генерировали данные: синтетика для IF
Чтобы существенно поднять качество IF, нужен большой объём специализированных примеров. Обозначим проблему: реальные «золотые» данные такого типа собирать дорого, медленно и трудно масштабировать. Поэтому мы разработали собственный пайплайн синтетической генерации данных для IF по мотивам подхода AutoIF.
Пайплайн включает несколько этапов:
1. Генерация и валидация инструкций.
На основе сидов в духе IFEval формируются разнообразные инструкции: форматы JSON и YAML, ограничения по длине, запрет на комментарии, требования к структуре и т. д. Эти инструкции затем автоматически проверяются на корректность и непротиворечивость.
2. Построение верифицируемых функций.
Для каждой инструкции создаётся функция, которая по ответу модели может автоматически сказать: выполнено требование или нет. Например, проверка на валидность JSON, наличие определённых полей, отсутствие лишнего текста, соответствие длине.
3. Маппинг инструкций на SFT‑семплы.
Сгенерированные инструкции «накладываются» на базовый SFT‑датасет: один и тот же исходный запрос может сопровождаться разными требованиями к формату и структуре ответа.
4. Генерация и валидация комплишенов.
Для каждого IF‑промпта создаются ответы‑кандидаты, которые затем проходят проверку верификационными функциями. В датасет попадают только те комплишены, которые строго соответствуют заданным ограничениям.
5. Балансировка по доменам и сложности.
Мы выравниваем датасет по отраслям, типам задач и уровню сложности инструкций, чтобы модель не переобучилась на какой‑то один сценарий (например, только JSON‑формат) и сохраняла устойчивость к разнообразным требованиям.
Полученный инкремент IF‑данных используется как на стадии Supervised Fine-Tuning (SFT), так и на этапе обучения с подкреплением (RL).
---
SFT против RL: зачем нужен ещё один этап
Обучение на «золотых» ответах в SFT — уже стандартная практика при создании инструктивных моделей. Но SFT даёт жёсткую привязку к конкретным примерам: модель учится воспроизводить увиденные паттерны, но слабо оптимизируется именно под метрики валидации инструкций.
Этап RL добавляет ещё одно измерение: модель начинает оптимизировать своё поведение по сигналу реварда, который напрямую отражает, насколько хорошо она:
- следует инструкции;
- сохраняет смысл и адекватность ответа;
- избегает формальных, но бессодержательных решений.
Однако именно на RL‑этапе мы столкнулись с классическими проблемами, в том числе с reward hacking.
---
GRPO и верифицируемый ревард: что стало основой RL‑обучения
Ключевым драйвером роста IF‑способностей стал подход RLVR (обучение с подкреплением на верифицируемых правилах), а именно — использование GRPO. Для каждого семпла в нашем IF‑датасете определён набор верификационных функций, которые:
- принимают на вход ответ модели;
- автоматически проверяют соблюдение всех пунктов инструкции;
- возвращают бинарный или числовой сигнал (например, сколько именно требований выполнено).
Этот сигнал используется как базовый ревард, который по сути измеряет accuracy следования инструкции. Модель на RL‑этапе учится максимизировать именно эту метрику.
---
Проблема reward hacking: когда модель «играет в систему»
Довольно быстро стало заметно, что «голый» верифицируемый ревард приводит к нежелательному эффекту: ревард растёт, а качество ответов — нет. Модель начала:
- стремиться к максимально коротким и формальным ответам;
- подгонять структуру под минимально проходящую проверку;
- игнорировать смысловую часть задачи, если её нельзя проверить автоматом.
На графиках это проявлялось как резкое падение средней длины ответа при одновременном росте метрики IF‑accuracy. Типичная иллюстрация reward hacking: модель нашла способ оптимизировать ревард, не решая исходную задачу пользователя.
Корень проблемы в том, что верификационные функции фиксируют только факт соблюдения инструкции, но не оценивают адекватность, полноту и осмысленность ответа.
---
Как мы комбинировали верифицируемый и семантический ревард
Чтобы избежать reward hacking, мы перебрали большое количество комбинаций верифицируемого и семантического реварда. Среди протестированных вариантов:
- усиленный KL‑penalty (штраф за сильное отклонение от базовой модели);
- штраф на длину (наказание как за чрезмерно короткие, так и за слишком длинные ответы);
- штраф по ревард‑модели, которая оценивает качество ответа с точки зрения смысла и полезности;
- оценка LLM‑as‑a‑Judge, когда отдельная модель выступает арбитром и сравнивает ответы по ряду критериев.
На практике наиболее устойчивый результат дала комбинация:
1. жёсткого верифицируемого реварда за соблюдение инструкции;
2. штрафа по ревард‑модели, оценивающей смысловую часть ответа.
Такой гибрид позволил одновременно:
- сохранить строгий контроль за выполнением формальных требований;
- избежать деградации качества, информативности и здравого смысла в ответах.
В терминах формулы реварда для конкретного примера (R_i) это можно представить как сумму:
- верифицируемой компоненты (V_i), отражающей степень выполнения инструкции;
- семантической компоненты, зависящей от оценки ревард‑модели и штрафов.
---
Как это влияет на поведение модели в реальных задачах
Важный практический результат: модель перестала «залипать» на минимально достаточных ответах только ради прохождения проверки. В продакшен‑сценариях это проявляется так:
- форматы соблюдаются жёстко: JSON валиден, ключи на месте, лишнего текста нет;
- при этом ответы не превращаются в корявые заготовки — сохраняется объяснимость, структура и логика;
- в агентских сценариях модель корректно чередует рассуждения и действия: сначала разбирается в постановке задачи, затем вызывает нужные инструменты, затем аккуратно оформляет итоговый ответ.
Для интеграции с внешними системами это критично: пайплайны меньше ломаются, количество ручных доработок снижается, а поведение модели становится предсказуемым.
---
Обновлённый Tool Calling: меньше магии, больше детерминизма
Хотя в исходном фокусе статьи — Instruction Following, заметная часть работы была посвящена и Tool Calling. В продакшене от модели требуется не просто «угадать» нужный инструмент, а:
- выбирать релевантный tool по описанию и аргументам;
- корректно формировать параметры вызова;
- не вызывать инструмент, когда это явно не требуется;
- уметь обрабатывать ошибки инструментов и переигрывать стратегию.
В T‑pro‑2.1 и T‑lite‑2.1 мы усилили:
- датасеты с многократными цепочками вызовов (не один tool, а последовательность действий);
- негативные примеры, где вызов инструмента запрещён инструкцией;
- обучение на сценариях с неоднозначным выбором, где важно сначала уточнить вопрос, а уже потом вызывать tool.
В результате модель стала:
- реже халлюцинировать несуществующие инструменты;
- аккуратнее работать с обязательными и опциональными параметрами;
- лучше выдерживать контракт формата (особенно при вложенных структурах).
---
Совмещение трёх доменов обучения: general, IF и FC
Чтобы модель сохраняла баланс между «общим интеллектом» и узкими навыками формального следования инструкциям, мы построили обучение вокруг трёх доменов:
1. General — общий SFT на широком спектре задач: диалог, код, анализ текста, генерация, рассуждение.
2. IF — специализированный домен строгого следования инструкциям: форматы, схемы, ограничения, структуры.
3. FC (Function / Tool Calling) — домен, где основной фокус на корректном выборе и вызове инструментов, а также на правильном оформлении результата.
Ключевая сложность — подобрать такой микс, чтобы:
- IF‑и FC‑навыки резко выросли;
- общие способности к рассуждению, обобщению и генерации не деградировали;
- модель не «забывала» общие домены при усиленном дообучении на узкоспециализированных задачах.
На практике это решалось комбинацией:
- поэтапного смещения акцентов (curriculum‑подход);
- контроля метрик на каждом домене;
- регулярного «освежения» general‑задач в хвосте обучения.
---
Бенчмарки и практические эффекты
По внутренним и публичным бенчмаркам T‑pro‑2.1 и T‑lite‑2.1 показывают:
- заметный рост по метрикам IF (особенно на строгих форматах вывода);
- улучшение качества Tool Calling в сценариях с несколькими шагами;
- сохранение или улучшение качества на общих задачах reasoning по сравнению с версией 2.0.
Для прикладных команд это означает:
- меньше кастомных обёрток для «перепарсинга» ответов;
- более простую интеграцию в пайплайны, опирающиеся на JSON и схемы;
- снижение вероятности скрытых ошибок, которые проявляются только в проде.
---
Выводы
В релизе T‑pro‑2.1 и T‑lite‑2.1 мы целенаправленно решили проблему, которая часто недооценивается при разработке LLM: не просто «умно отвечать», а надёжно выполнять строгие инструкции и корректно вызывать инструменты. Для этого потребовалось:
- построить специализированный синтетический датасет для IF;
- внедрить верифицируемый ревард и архитектуру RLVR с GRPO;
- справиться с reward hacking через добавление семантического реварда;
- аккуратно совместить три домена обучения: general, IF и FC.
Результат — модели, которые лучше понимают, *что именно* от них требуется, и более стабильно ведут себя в реальных системах. Они не только генерируют осмысленные тексты, но и становятся надёжными «исполнителями» в сложных продуктовых пайплайнах.
