Обновление T-Pro 2.1: как мы улучшили Instruction Following и Tool Calling

Всем привет! На связи Толя Потапов и команда ML Т-Банка. Этим летом мы выпустили большую языковую модель T-pro-2.0 — эффективную русскоязычную модель с гибридным подходом к reasoning. Сегодня выпускаем обновление T-pro-2.1, в котором закрываем два самых заметных слабых места 2.0: следование инструкциям и tool calling.

Заодно мы обновили и T-lite-2.1. Лайт-линейка долго оставалась на версии 1.0, хотя именно ее чаще всего берут энтузиасты и команды, которым важны скорость и простота развертывания. В 2.1 мы приводим T-lite в актуальное состояние — без потери легкости, но с более современным качеством и поведением.

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

T-lite-2.1 и T-pro 2.1 — небольшое, но точечное обновление 2.0: меньше промахов в инструкциях, точнее вызов инструментов и более выверенный рецепт обучения.

Особенности релиза и процесс дообучения

T-pro 2.1 — инструктивная модель на базе Qwen3-32B, которая отвечает без «тысяч токенов рассуждений», но с качеством, которое в большинстве задач остается сопоставимым или выше, чем у подходов c большим reasoning-бюджетом. Мы вдохновлялись философией Qwen3-235B-2507-Instruct: максимум полезного сигнала в финальном ответе, а не в длинной трассировке мыслей. При этом по сравнению с 2.0 модель заметно лучше держит формат, аккуратнее выполняет требования и увереннее ведет себя в агентских сценариях.

T-lite 2.1 — обновленная 8B-модель: более сильная на прикладных задачах и при этом остается быстрой и практичной для продакшена и локального запуска.

Улучшение Instruction Following (IF) стало отдельным направлением при разработке T-pro-2.1 и T-lite-2.1.

IF — это способность LLM точно и последовательно выполнять инструкции пользователя, а не просто генерировать правдоподобный текст. Типичные примеры таких инструкций: «ответь строго в формате JSON», «не добавляй пояснений», «соблюдай заданную схему», «уложись в лимит длины» и так далее. На практике подобных требований может быть много, и сложность Instruction Following как раз в том, чтобы корректно учитывать их все одновременно.

Для продакшен-сценариев именно IF часто оказывается критичнее «общего качества» текста: ошибка в формате или игнорирование части требований делает ответ модели бесполезным.

Data: синтетика для IF. Для получения специализированных данных мы разработали собственный пайплайн генерации синтетики для IF на основе подхода AutoIF. Он включает в себя этапы:

• генерации и валидации инструкций на основе IFEval-like сидов;

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

• маппинга сгенерированных инструкций к семплам из SFT-датасета;

• генерации и валидации комплишенов, удовлетворяющих ограничениям в IF-промптах;

• балансировки данных по доменам и уровню сложности.

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

RLVR стал ключевым драйвером роста IF-способностей. А именно GRPO. Для каждого семпла у нас есть набор верификационных функций, позволяющих автоматически проверить корректность ответа модели. В качестве базового реварда мы использовали accuracy следования инструкции.

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

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

• усиленный KL-penalty;

• штраф на длину ответа;

• штраф на основе ревард модели;

• штраф на основе LLM-as-a-Judge.

На практике лучшим решением оказалась комбинация верификационных функций со штрафом на основе нашей ревард модели по аналогии с работой Generalizing Verifiable Instruction Following, которая позволила:

• сохранить строгий контроль за выполнением инструкции;

• предотвратить деградацию качества и осмысленности ответов.

Финальная формула реварда Ri с учетом верифицируемой части Vi и скора ревард модели Si выглядела так:

Отдельного внимания требует подбор порога ɑi для ревард модели. Мы задали его на уровне среднего качества ответов базовой модели Qwen3-235B-Instruct-2507 на конкретный промпт. Это позволяет обучать модели корректному следованию инструкциям и одновременно не допускать падения качества ниже базового уровня.

Благодаря такому подходу нам удалось значительно улучшить Instruction Following способности моделей, что отразилось в росте метрик на бенчмарке IFEval — нашем основном показателе качества IF. Кроме того, улучшения проявились и на других бенчмарках, таких как Arena-Hard, поскольку качественное следование инструкциям напрямую повышает способность модели эффективно решать широкий спектр задач.

Как мы учили модель работать с инструментами: от синтетики до RL

Мы начали улучшение function calling с ревью всех открытых датасетов на HuggingFace: отобрали наиболее качественные, перевели на русский, чтобы обучать модель сразу на RU/EN. Но SFT на этих данных не дал прироста на BFCL: примеры оказались слишком простыми — почти всегда single-turn-диалоги с тривиальными тулсетами. Чтобы это устранить, нужно было:

• расширить пространство инструментов;

• усложнить диалоги: добавить многошаговые, последовательные и параллельные вызовы.

Для обеих задач мы построили синтетические пайплайны.

Генерация синтетических инструментов. Для генерации разнообразных синтетических инструментов мы применили подход на основе self-instruct. Сначала собрали все доступные инструменты из открытых источников, после чего их описания кластеризовали для извлечения тематик. Далее запускался итеративный цикл расширения: генерация новых тем → кластеризация → обновление множества тематик с minhash-дедупликацией между кластерами.

По полученным тематикам генерировались функционально связанные наборы инструментов, имитирующие реальные инструменты. Например, те, что могут быть доступны в MCP, то есть инструменты, которые естественно использовать вместе в одном диалоге. Поскольку многие сгенерированные инструменты оказывались семантически близкими, мы добавили этап merge как в статье от ByteDance — объединение похожих инструментов через расширение описаний и сигнатур с последующим refine для уточнения аргументов и типов.

Для контроля длины JSON-описаний, подаваемых в контекст LLM, каждый инструмент дополнительно генеративно сжимался. В результате для каждого инструмента создавалось несколько вариаций: до и после refine, разной длины. Такой подход обеспечил покрытие разнообразных статистик в обучающих данных.

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

Фаза 1: планирование. На вход подаются несколько наборов инструментов, сгруппированных по тематике. Для каждой группы генерируется контекст, а на основе всех инструментов — пользовательская персона.

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

Фаза 2: Мультиагентная симуляция. На основе траектории запускается взаимодействие трех агентов:

• User-агент генерирует реплики по целям и персоне. На каждом шаге предлагает несколько вариантов — LLM-судьи выбирают лучший.

• Assistant-агент (целевая модель для дистилляции) имеет доступ к инструментам. Параллельно генерирует варианты действий: финальный ответ, уточняющий вопрос или вызов инструментов. Выбор по голосованию судей с дополнительными проверками формата и согласованности с траекторией.

• Tool-агент имитирует исполнение вызванных инструментов на основе траектории.

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

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

Результатом работы пайплайнов синтетики является завершенный диалог — полная история взаимодействия между пользователем и ассистентом для формирования датасетов для SFT- и GRPO-этапов обучения модели.

Tool calling post-training. Обучение на данных первой версии пайплайна продемонстрировало улучшение на бенчмарках BFCL v3, tau²-bench и ACEBench. Для дальнейшего прогресса мы проработали две ключевые гипотезы для формирования обучающих данных.

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

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

Для RL-этапа мы использовали бинарный ревард (tool-n1), сравнивающий JSON ответа модели с Ground Truth. ревард-функция учитывает:

• формат — структуру тегов и порядок элементов;

• корректность JSON для вызовов и полное соответствие вызовов эталону.

После первых экспериментов мы заметили рост по всем сабсетам BFCL, кроме Irrelevance и Multi Turn. Анализ показал: модель «захакала» ревард — в обучающем датасете не было примеров с финальной репликой ассистента, завершающей tool-вызовы, и мы разучились отвечать что-то кроме вызова инструмента.

Мы провели серию экспериментов по балансировке датасета, варьируя долю Irrelevance, сценарии, где ни один инструмент не релевантен запросу, и долю ответов ассистента. Дополнительно проверили влияние сложности тулов и баланса RU/EN.

Итоговый баланс RL-датасета:

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

Как мы совместили три домена обучения: general, IF и FC

Мы научились делать отдельные способности хорошими. Следующий шаг — совместить методологии для улучшения качества ответов модели с точки зрения instruction following и function calling. Нужно было построить единую модель, удовлетворяющую критериям качества в данных доменах и сохраняющую при этом общее качество ответов не хуже версии 2.0.

Мы зафиксировали три домена: general, IF и FC — каждый со своими данными, ревардами и бенчмарками. Взяли в качестве основы Qwen3 с улучшенным токенизатором из версии 2.0 и проделали шаги для подготовки модели:

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

• SFT на объединенных данных из трех доменов. Такой подход оказался эффективным: после этой стадии модель получилась сопоставима с аналогичными моделями, обученными на доменах в отдельности. А в ряде бенчмарков даже немного превосходила их.

• Обучение трех отдельных экспертов на основе SFT-модели с использованием алгоритма GRPO. Решение связано с тем, что в RL-стадии в разных доменах использовались реварды разной природы, с разным масштабом и разной скоростью роста в ходе обучения. Попытки объединять данные из нескольких доменов в одном запуске приводили к перекосу: один домен начинал доминировать над остальными. Ухудшалось итоговое качество модели, а выравнивание влияния доменов требовало неоправданно большого числа экспериментов и тонкой настройки.

• Слияние трех экспертов в единую модель. Мы экспериментировали с разными методами слияния весов и склонились к методу SLERP. Он позволяет объединить только две модели за одно применение, поэтому сначала из экспертов IF и FC построили одну модель, а затем полученную модель объединили с general-экспертом. Итоговая модель практически не уступала каждому из экспертов в целевом для него домене.

• «Полировка» — последняя стадия обучения с малым learning rate для устранения возможных артефактов генерации, возникающих после слияния моделей.

Данные для обучения в домене general мы подготовили на основе данных из версии 2.0. Дополнительно сгенерировали на основе диалогов оттуда ответы без рассуждений для SFT-стадии. Алгоритм DPO для стадии preference tuning из версии 2.0 уступил место алгоритму GRPO на основе той же ревард-модели. Это не только позволило достичь более высокого качества модели, но и дало нам возможность более гибко настраивать оптимизируемые свойства ответов.

Например, мы замечали, что после DPO-стадии средняя длина ответов растет, поскольку наша ревард-модель предпочитает более длинные ответы. Мы хотели научиться контролировать такое поведение, поэтому в GRPO-сетапе добавили мультипликативный length penalty (штраф за длину).

Помимо этого, длительное обучение GRPO на домене general приводило к существенной деградации на других доменах и росту энтропии ответов, хотя на базовом домене ревард стабильно увеличивался. Этот эффект связан с тем, что по ходу обучения распределение ответов, на котором обучалась ревард-модель, начинает удаляться от целевого распределения. Сильное отличие приводит к неопределенному поведению ревард-модели: ее оценки перестают отражать реальное качество ответов.

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

Бенчмарки

Диалоговые бенчмарки. Для оценки способностей моделей к ведению диалога, следованию инструкциям и решению задач мы традиционно использовали LLM-as-a-judge-арены: Arena Hard Ru, Arena Hard 2 и арену, основанную на данных, отобранных автором репозитория WildChat Hard Ru из реальных запросов пользователей. В последней мы использовали в качестве бейзлайна ответы модели o3-mini. В качестве судьи для всех арен используется DeepSeek V3.1 terminus.

Instruction Following бенчмарки. Мы локализовали на русский язык оригинальный IF-eval-бенчмарк, чтобы оценить способность моделей следовать инструкциям (instruction-following). Для этого с помощью переводчиков перевели критерии и сами запросы, при этом исходная методология вычисления метрик полностью сохранена. Метрика в таблице представляет собой среднее значение 4 показателей: prompt-level strict accuracy, instruct-level strict accuracy, prompt-level loose accuracy, instruct-level loose accuracy.

Tool calling бенчмарки. Для оценки способностей моделей к использованию инструментов (tool calling) мы опирались на существующие бенчмарки, покрывающие разную сложность задач: ruBFCL, оригинальный BFCL v3, ACEBench, ориентированный на более сложные вызовы инструментов, а также бенчмарк tau².

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

Для локализации BFCLv3 на русский язык ключевой задачей было сохранить однозначность и разрешимость каждого примера: перевод пользовательского запроса, целевого ответа и описаний инструментов не должен вносить противоречий или неоднозначностей. Сначала мы совместно переводили запрос и связанные с ним инструменты, используя structured output: автоматически генерировали схему, сохраняя оригинальную JSON-структуру инструментов. Затем ансамбль LLM-судей проверял корректность перевода по двум критериям: отсутствие логических противоречий и полнота перевода всех значимых полей.

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

Выводы

T-pro 2.1 — лучшая в своем размере среди открытых моделей для русскоязычных агентских сценариев, где важно использование инструментов. Она сильнее в instruction following и tool calling, при этом быстрая за счет уплотненного токенизатора и ориентации на «ответ сразу».

T-lite 2.1 — легковесная 8B-модель с достойными IF/tool calling, когда важны скорость, простота запуска и предсказуемые ответы.

Как и у любой LLM, могут быть ошибки и галлюцинации — для production рекомендуем RAG, валидацию форматов/вызовов инструментов и внешние safety-механизмы (при необходимости — дотюнинг под домен).

Полезные ссылки:

• T-lite и T-pro на huggingface

• T-pro 2.0 training report