Дистиляція з м’якими мітками для агента SQL обсягом 0.8B: чому переміг слабший вчитель Qwen

Коротка версія

У попередньому експерименті агент обсягом 0,8 мільярда параметрів перейшов від виконання 1 завдання з 220 до 46, змушуючи його копіювати більший „вчительський“ промпт по одному токену за раз. Цього разу змінюється лише одна річ. Що станеться, якщо учень також побачить частину невизначеності „вчительського“ промпта, а не лише той токен, який він у підсумку обрав? Усе інше залишається незмінним: кріплення, оцінка 220 завдань, схема дій, учень обсягом 0,8 мільярда параметрів та налаштування фінтюнінгу LoRA. Змінюється лише сигнал навчання.

Заморожені дані „вчительського“ промпта були переоцінені. На кожній позиції зберігалися 20 найвищих ймовірностей токенів, а також невелика кількість „залишкової маси“, яка представляла все інше. Потім порівнювалося звичайне навчання з вагованими жорсткими токенами з методом дистиляції м’яких міток типу top-k. У найкращому варіанті було вирішено 55 з 220 завдань, порівняно з 46 у учня з жорсткими токенами та 49 у комбінованому варіанті з жорсткими токенами.

Основна цифра — це не найцікавіша частина. М’які мітки погіршили ситуацію під час двох із восьми тестів з одним джерелом даних. Найкращим викладачем також не був найсильніший. Qwen, модель слабша з тієї ж родини з оцінкою 96/220, значно точніше відтворювала власні дані, ніж сильніша модель GPT (115/220), тож її ймовірності давали учневі більш чіткі уроки. Справжній успіх прийшов від поєднання обох джерел.

Спочатку варто зазначити одну умовність: ймовірності токенів самої моделі GPT ніколи не були доступні. Дані GPT тут були оцінені моделлю Qwen, тож вони є лише апроксимацією, а не справжньою дистиляцією логітів GPT.

Що тестувалося

Ширшою метою є покращення здатності невеликих моделей виконувати спеціалізовані завдання. Агент залишається тим самим агентом для виправлення SQL, що й раніше. Він отримує проблему від користувача разом із пошкодженим SQL-кодом, може переглядати базу даних SQLite, виконувати діагностичні запити, читати результати та надсилати виправлений SQL-код. Оцінка здійснюється за допомогою прихованих детерміністичних тестів, без участі судді у вигляді LLM.

Попередні тести з використанням hard-tokenів вже показали, що невелика модель може працювати в цьому циклі. Неналаштована базова модель переважно повторювала дії та ніколи нічого не надсилала. Після SFT із використанням hard-tokenів вона значно частіше переглядала дані, виконувала запити та надсилала результати.

Навчання з використанням «жорстких» токенів є примітивним інструментом. Учня просять відтворити будь-який токен, який написав викладач, без жодних підказок щодо того, наскільки впевнений був викладач, що ще він враховував, чи була друга за якістю опція майже такою ж хорошою. Для SQL ця відсутня інформація може мати значення для назв таблиць та стовпців, умов, з’єднань, літеральних значень та синтаксису структурованих дій.

Отже, постало питання: чи покращує метод дистиляції з використанням «м’яких» міток типу top-k той самий агент об’ємом 0,8 мільярда параметрів, коли сліди та критерії оцінки залишаються незмінними.

Було порівняно два вихідні варіанти. Один з них — базова модель unsloth/Qwen3.5-0.8B. Інший — адаптер Qwen3.5-0.8B для «жорстких» токенів, який раніше навчався на успішних сценаріях роботи з моделі Qwen3.5-35B-A3B 8-бітної версії. Іншими словами: чи слід починати навчання з використанням «м’яких» міток з нуля чи продовжувати з варіанту, що використовує «жорсткі» токени?

Завдання для SQL-агента

Склад сценарію збігається з попереднім виконанням завдань із жорсткими токенами. Кожне завдання містить проблему користувача, пошкоджений запит та базу даних SQLite. Модель обирає серед структурованих дій: перевірити схему, виконати SQL-запит або надіслати остаточний SQL-запит. Завдання вважається вирішеним лише тоді, коли надісланий SQL-запит пройшов приховані тести.

Типове невелике, але реальне завдання: у базі даних chinook користувач хоче отримати найновіший значення track_id, а потім використати його для фільтрації рядків у таблиці track. Пошкоджений запит виглядає так:

WITH vars AS (SELECT COUNT(*) AS vars_id FROM track)
SELECT * FROM track WHERE track_id = vars_id

Ця проблема не пов’язана з форматуванням. COUNT(*) не є найновішим ідентифікатором, тому потрібна корекція у вигляді MAX(track_id). Модель має обробити це під час циклу інструментів: можливо, перевірити схему, запустити зондування, прочитати результати спостережень та нарешті надіслати SQL у точному структурованому форматі, який приймає система.

BAML, скорочення від Boundary Markup Language, все ще використовується як шар структурованого виводу для запитів. Він визначає форму рішення та формує запит, який надсилається до моделі. Вільний текст викладача ніколи не входить до даних для навчання студента; модель вчиться на канонічних JSON-рішеннях, які складаються з короткого draft та виконуваної дії output.

{"draft":"Need schema first.","output":{"action":"inspect_schema"}}
{"draft":"Test a candidate query.","output":{"action":"run_sql_query","sql":"SELECT ..."}}
{"draft":"Submit corrected SQL.","output":{"action":"submit_sql","sql":["SELECT ..."]}}

Кожна оцінка використовувала налаштування попереднього запуску, тому єдиним елементом, який змінювався, був сигнал навчання. Два налаштування заслуговують окремої уваги. Ліміт послідовностей у 8192 є загальним бюджетом для запиту та генерації разом: системний запит, завдання, попередні дії, схема, результати пошуку, інструкції щодо структурованого виводу та резерв для генерації — усі вони розділяють цей бюджет. Максимальна кількість генерованих токенів вказується окремо, оскільки вона обмежує кількість викликів моделі. Студент може отримувати довгу інформацію про стан, але все одно мусить виконувати одну компактну дію за кожен хід. Результати повідомляються через результати в терміналі та метрики поведінки, такі як кількість надісланих рішень, неправильні рішення, помилки SQL, зупинки через повторні дії та зупинки через максимальну кількість ходів.

Найкращі студенти не провалюються переважно через JSON. Вони без проблем доходять до етапу submit_sql. Складною є частина, пов’язана з оцінкою SQL-запитів та відновленням після невдалих спроб.

Ідея навчання

Дистиляція з використанням жорстких токенів дає учневі один цільовий токен на кожну позицію. Натомість дистиляція з використанням м’яких міток забезпечує невелике розподілення ймовірностей. Припустимо, що ціль викладача містить токен таблиці, як у ... FROM users .... Під час жорсткого навчання вважається, що наступним токеном є users. Під час навчання з використанням м’яких міток також можна визначити, яку ймовірність викладач надав кільком близьким альтернативам. Обраний токен все одно залишається актуальним, але учень додатково бачить, що деякі альтернативи були ближчими за інші.

Зберігання ймовірностей для всього словника є дорогим для великих мовних моделей. Словник може містити сотні тисяч токенів, а кожне рішення викладача стосується багатьох позицій цілей асистента. Практичним компромісом стала розріджена версія: 20 найвищих ймовірностей викладача для кожної позиції цілі асистента, плюс залишкова маса для всіх інших токенів.

Чому зберігати хвіст? Припустимо, сума 20 найвищих збережених ймовірностей дорівнює 0,996. Решта 0,004 все ще належить до розподілу викладача, і якщо підняти ці 20 значень до 1,0, у студента виникне надмірна впевненість у результаті. Тому цільове значення навмисно формується так, щоб пам’ятати про те, що частина інформації залишається поза межами того, що було збережено.

Цей підхід все ще є позаполітичним. Студент навчається на даних, зібраних раніше, і ніколи не діє під час процесу оцінювання.

Короткий огляд коду

Найпростіший спосіб дотримуватися цього методу — це простежити один рядок через весь процес обробки. Для „м’яких“ міток не створювалося нове середовище агента. Використовувалися ті самі ефективні рішення викладача з процесу обробки „твердих“ токенів; вони були пере використані у тому ж форматі запиту BAML та доповнені інформацією про ймовірності для токенів-цілей асистента.

Ось рядок для навчання з використанням жорстких токенів у режимі SFT. SFT — це процес навчання на парах вхід-вихід, де лише токени відповідей впливають на значення втрати:

row = {
    "messages": conversation_before_teacher_decision + [
        {"role": "assistant", "content": canonical_decision_json(teacher_decision)}
    ],
    "teacher_draft": teacher_decision.draft,
    "teacher_action": teacher_decision.output,
}

Рядок із м’якою міткою зберігає ті самі канонічні повідомлення та метадані вчителя, а також отримує оцінки токенів, встановлені вчителем, у позиціях цілі асистента. „Примус вчителя“ тут означає передачу відомого тексту-цілі моделі ймовірностей та запитання, токен за токеном, наскільки ймовірним є цей текст з урахуванням його контексту. Зберігаються логарифмічні ймовірності, а не сирі, оскільки їх значно безпечніше записувати та використовувати під час навчання:

row = {
    "messages": [..., {"role": "assistant", "content": target_decision_json}],
    "distillation": {
        "probability_model": "Qwen3.5-35B-A3B 8-bit",
        "top_k": 20,
        "row_weight": 1.18,
        "token_scores": [
            {
                "position": 1661,              # full-sequence token position
                "target_token_id": 412,
                "target_logprob": -0.21,
                "top_token_ids": [412, 879, 91],
                "top_logprobs": [-0.21, -2.81, -3.51],
                "top_mass": 0.90,
                "tail_mass": 0.10,
            }
        ],
    },
}

Функція оцінювання має одну мету — взяти зафіксований рядок та нанести на нього ймовірності токенів. Від оцінювача Qwen3.5-35B-A3B 8-bit ніколи не вимагають створювати нове рішення. Підказка відображається без відповіді асистента, повна послідовність — з нею, а цільова частина оцінюється по одному токену за раз:

prompt = chat_template(messages[:-1], add_generation_prompt=True)
full = chat_template(messages, add_generation_prompt=False)
prompt_ids = tokenize(prompt)
full_ids = tokenize(full)
target_ids = full_ids[len(prompt_ids):]
prefill_teacher_cache(prompt_ids[:-1])
driver_ids = [prompt_ids[-1]] + target_ids[:-1]
for i, target_id in enumerate(target_ids):
    logits = qwen_35b(driver_ids[i]).logits
    logprobs = log_softmax(logits)
    top_ids, top_logprobs = top_k(logprobs, k=20)
    save_token_score(
        position=len(prompt_ids) + i,
        target_token_id=target_id,
        target_logprob=logprobs[target_id],
        top_token_ids=top_ids,
        top_logprobs=top_logprobs,
        tail_mass=1.0 - sum(exp(top_logprobs)),
    )

Маскування лише асистента залишається незмінним порівняно з режимом використання жорстких токенів. Токени запиту є контекстом, а цільові токени асистента — засобом нагляду. Це має більше значення для агента, ніж для звичайного відповідання на запитання, оскільки запит містить спостереження за схемою, результати роботи інструментів раніше та результати SQL-запитів. Ці токени призначені для використання як умови, а не для прогнозування:

labels = full_ids.copy()
labels[: len(prompt_ids)] = -100
hard_ce = cross_entropy(student_logits, labels)

Навчання також вимагає більше тензорів, ніж звичайний SFT. Пакет, як завжди, містить input_ids, attention_mask та масковані labels, а крім того — вагу для кожної позиції, ідентифікатори токенів з найвищими значеннями k разом із їхніми лог-ймовірностями, маску для цих k позицій та залишкові ймовірності. Функція padding вставляє нейтральні значення у неактивні позиції, тож функція втрати ігнорує їх без проблем:

batch = {
    "input_ids": pad(input_ids, pad_id),
    "attention_mask": pad(attention_mask, 0),
    "labels": pad(labels, -100),
    "position_weights": pad(position_weights, 0.0),
    "topk_token_ids": pad(topk_token_ids, [0] * top_k),
    "topk_logprobs": pad(topk_logprobs, [0.0] * top_k),
    "topk_mask": pad(topk_mask, [False] * top_k),
    "tail_probs": pad(tail_probs, 0.0),
}

Умовою керування є ваговане тонку налаштування за допомогою жорстких токенів. Один обраний токен залишається цільовим, але крос-ентропія токенів-асистентів множиться на вагу впевненості, яка береться з лог-ймовірності оцінювача для цієї цілі. Варіант, який легко оцінити для оцінювача, може мати більшу вагу, а малоймовірний — меншу:

z = (mean_target_logprob - dataset_mean_logprob) / dataset_logprob_std
row_weight = clip(2 / (1 + exp(-z)), 0.25, 1.75)
loss = row_weight * hard_ce

Обрізка даних у діапазоні [0.25, 1.75] запобігає тому, щоб якийсь один ненадійний рядок вплинув на весь набір, проте надійні рядки все одно можуть значно переважати ненадійні.

У випадку м’яких міток до функції втрат додається член, який враховує збіг ймовірностей. Нижче наведено опис його форми, а не точний код реалізації:

teacher_top_probs = exp(top_logprobs) * topk_mask
teacher_top_probs *= (1.0 - tail_mass) / sum(teacher_top_probs)
student_logprobs = log_softmax(student_logits_at_target_positions)
student_top_logprobs = gather(student_logprobs, topk_token_ids)
student_tail_prob = 1.0 - sum(exp(student_top_logprobs))
topk_kl = sum(teacher_top_probs * (log(teacher_top_probs) - student_top_logprobs))
tail_kl = tail_mass * (log(tail_mass) - log(student_tail_prob))
loss = hard_ce + topk_kl + tail_kl

Інформація передається від викладача до учня: метою учня є отримання саме того розподілу, який визначає викладач, і настає покарання, якщо для цієї маси призначається занадто мала ймовірність. У справжньому тренері як крос-ентропія, так і процес дистиляції обчислюються лише щодо зсунутих позицій цілей асистента.

Фактична підготовка учня все ще є процесом тонкої налаштування LoRA. LoRA, або адаптація низького рангу, зберігає базову модель майже незмінною та додає невеликі матриці-адаптери, які можна налаштовувати, до обраних модулів уваги та MLP. Це дозволяє дешево порівнювати багато результатів, не проводячи щоразу повної налаштування моделі об’ємом 0,8 мільярда параметрів:

student = load_student("unsloth/Qwen3.5-0.8B", max_seq_length=4096)
student = add_lora_adapters(
    student,
    rank=32,
    alpha=32,
    target_modules=[
        "q_proj", "k_proj", "v_proj", "o_proj",
        "gate_proj", "up_proj", "down_proj",
    ],
)
trainer_class = make_trainer_class(Trainer, soft_label_args)
trainer = trainer_class(
    model=student,
    train_dataset=scored_train_examples,
    eval_dataset=scored_validation_examples,
    data_collator=distillation_collator,
    batch_size=1,
    gradient_accumulation_steps=8,
    learning_rate=5e-5,
    epochs=3,
)
trainer.train()
adapter = save_lora_adapter(student)

Реальна реалізація відповідає цьому: make_trainer_class повертає підклас Hugging Face Trainer, який застосовує збережену втрату типу sparse top-k разом із residual-tail. Зверніть увагу, як це відрізняється від онлайн-версії DistillationTrainer від TRL, де оцінка від вчителя виконується всередині самого тренеру. Усі три параметри м’яких міток залишилися на рівні 1.0: hard cross-entropy, distillation та temperature. Параметр temperature залишений без змін навмисно, оскільки артефакти, пов’язані з розрідженими даними, були встановлені на рівні 1.0, і метою не було проведення дослідження з масштабуванням temperature.

Оцінка наприкінці є справжнім тестуванням у реальних умовах, а не примусом з боку вчителя. Навчений адаптер повертається до системи SQL-agent та мусить виконати 220 завдань, які залишилися без обробки, діючи по одному кроцю за раз:

for task in held_out_eval_tasks:
    state = start_sql_agent_task(task)
    for turn in range(8):
        messages = render_baml_messages(state)
        decision = model_with_adapter.generate_action(
            messages,
            max_new_tokens=512,
            temperature=0.0,
        )
        state = execute_action_and_append_observation(state, decision)
        if state.solved or state.stopped:
            break
    results.append(score_final_submission(state))

Багато ідей офлайн-дистиляції зазнають невдачі на цьому останньому етапі. Тест від викладача перевіряє, чи може учень передбачити, що зробить викладач далі в контексті, створеному самим викладачем. Тест реалізації перевіряє, чи може учень прийняти свої попередні рішення, обрати корисні запити, уникнути повторень та надіслати правильний SQL. Тут має значення лише друге число.

Як працює експеримент

Легко можна сприйняти це як дистиляцію за правилами політики, але це не так. Ніщо з того, що створює учень, не оцінюється. Він вчиться лише пізніше, на основі слідів, які вже створив викладач.

Дані походять від оцінювання записів про успішні дії під час обробки заморожених даних. Дії вчителя вже існують, а модель ймовірностей лише визначає, наскільки ймовірним є кожен обраний токен з урахуванням контексту. Вона ніколи не формує нового рішення. Два набори даних, які підлягали оцінюванню, зберігалися окремо (записи GPT, оцінені Qwen, записи Qwen, оцінені Qwen), і кожен з них фільтрувався за довжиною всієї отриманої послідовності, адже спостереження за схемою та результати роботи попередніх інструментів є частиною того, що студент має засвоїти, а не лише кінцева відповідь. Межа: записи GPT вважаються оціненими за алгоритмом Qwen-proxy та не оцінювалися за власними ймовірностями GPT, причому студент ніколи не діє під час процесу оцінювання.

До оцінених даних було застосовано три варіанти навчання:

• Тонконалаштування з вагованими жорсткими токенами (метод керування). Для кожної позиції обирається один токен, причому кожен ряд вагований за рівнем впевненості оцінювача. Це SFT із регулятором впевненості. Межа: це не дистиляція з м’якими мітками, оскільки учень бачить ваги, але ніколи не бачить розподіл top-k.
• Дистиляція з м’якими мітками top-k (метод, який тестується). Той самий жорсткий цільовий сигнал плюс другий сигнал, який змушує учня розподілити ймовірності між топ-k варіантів, які бачив оцінювач, залишаючи решту для всього іншого. Межа: це метод поза політикою та з примусом від вчителя через заморожені дані, причому вчитель ніколи не оцінює власні зразки учня.

Поєднання даних від викладачів та самого моделювання. Рядки GPT-proxy та Qwen-self об’єднуються, перемішуються та використовуються для навчання базової моделі у обох напрямках. Особливість: цей підхід поєднує дані різних викладачів, замість того щоб об’єднати їхні розподіли в один, причому кожен рядок зберігає оцінювач, який його створив.

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

Набір даних та фільтрація

Дані від викладачів навмисно не генерувалися заново. Вони були зафіксовані під час виконання завдань з використанням „hard-token“, щоб порівняння стосувалося саме сигналу керування, а не нового етапу генерації даних.

У тому попередньому етапі обробки обидва вчителі виконували однакові 879 навчальних завдань. GPT 5.5 medium відповів правильно на 446 з 879 завдань, що дало 1046 рядків даних SFT. Qwen3.5-35B-A3B 8-bit відповів правильно на 394 завдання, що дало 1232 рядки, оскільки його успішні результати тривали довше. Під час оцінювання за 220 завдань GPT 5.5 medium показав кращі результати — 115 проти 96, тож тут тест Qwen є тестом з однієї родини моделей, а не найкращим варіантом використання вчителя.

Аргумент про проксі має вагу. Щоб отримати чесні оцінки від GPT 5.5 medium, знадобилися б ймовірності токенів цієї моделі, але вони не були доступні. Тож експеримент із відстеженням дій GPT ставить більш вузьке питання: чи додає оцінювач Qwen з однієї родини моделей щось корисне до обраних дій GPT?

Для кожного рядка було відтворено запит BAML, який насправді використовувався системою. Відому мету асистента потім примусово надавав вчитель за допомогою Qwen3.5-35B-A3B; оцінки 8-бітних токенів зберігалися лише для позицій мети асистента.

Перед будь-яким навчанням необхідно перевірити два аспекти оцінених даних: яку частину з них можна вмістити в ліміт у 4096 токенів та наскільки точно оцінювач Qwen узгоджується з кожним джерелом даних. Чим нижча значення негативної лог-ймовірності, тим краще, адже це означає, що модель ймовірностей вважає цілеві дії легшими для пояснення. Саме тому дані, оцінені Qwen самостійно, сильно відрізняються від даних, оцінених за допомогою GPT: Qwen був набагато впевненіший у власних даних, ніж у даних GPT 5.5 medium. Середнє значення негативної лог-ймовірності для рядків, оцінених Qwen самостійно, становило 0.297, а для рядків, оцінених за допомогою GPT — 0.876. У кожній позиції, оціненій Qwen самостійно, цільовий токен потрапляв до топ-20 збережених даних (100.00%), а у 98.56% позицій, оцінених за допомогою GPT.

Об’єднаний набір починався з 2278 рядків. Після фільтрації 4096 токенів залишилося 2253 рядки, які були розділені на 2141 для навчання та 112 для перевірки. Фіксоване насіння перемішало рядки перед розділенням, щоб набір для перевірки не відображав порядок джерел.

Налаштування навчання

Вісім запусків створили основну сітку — повне перетинання трьох бінарних варіантів: яке джерело даних (проксі GPT чи Qwen самостійно), який метод (з вагованими жорсткими чи м’якими мітками) та з якого старту починається навчання студента (з базової моделі чи з теплого старту з жорсткими токенами). Ще два запуски, обидва з базової моделі та обидва на поєднаних даних — один з вагованими жорсткими токенами та один з м’якими мітками — дали загалом десять навчених студентів. Запуски з теплим стартом були виключені. Перші вісім показали, що теплий старт сильно залежить від джерела даних, а запуски з поєднаними даними мали на меті відповісти на простіше питання: чи допомагає змішування вчителів у базовій моделі?

Гіперпараметри навчання відповідали базовій траєкторії hard-token. Для адаптерів використовувався LoRA з рангом 32 та коефіцієнтом alpha 32 для проекцій уваги (q_proj, k_proj, v_proj, o_proj) та проекцій MLP (gate_proj, up_proj, down_proj). Інші налаштування: швидкість навчання 5e-5, одна партія на пристрій з 8 кроками накопичення, три епохи, формат bf16 на GPU NVIDIA, бібліотеки Unsloth та FlashAttention 2 у разі наявності. Решта налаштувань включали 5% відсоток для валідації, параметр seed 42 та обмеження довжини повних послідовностей навчання у 4096 токенів.

Для м’яких міток температура становила 1,0, а ваги для як жорсткої крос-ентропії, так і процесу дистиляції — також 1,0. Код зберігає збережену масу top-k разом із залишковою масою хвоста, що є простим числовим рішенням для ймовірностей, які були серіалізовані у розрідженому вигляді.

Розміри пакетів даних не були ідентичними. Експерименти з GPT proxy-scored тренувалися на 990 рядах, експерименти з Qwen self-scored — на 1151 ряду, а комбіновані — на 2141 ряду. При розмірі пакета 1 та 8 кроках накопичення кількість оновлень оптимізатора за три епохи становила відповідно 372, 432 та 804. У мітках експериментів Base означає неналаштований модель unsloth/Qwen3.5-0.8B, GPT proxy — дані з GPT 5.5 medium, оцінені моделлю Qwen3.5-35B-A3B 8-bit, Qwen self — дані самої моделі Qwen, оцінені нею самою, а Combined — поєднання обох наборів оцінок перед тренуванням.

Будьте обережні з втратами валідації. Вони мають певне значення в межах однієї мети, але результати виконання з важкими та м’якими мітками не можна порівнювати між собою, оскільки їхні втрати включають різні складові. Найнижча втрата валідації належала до базового варіанту Qwen з важкими мітками, який вирішив лише 40 з 220 завдань, тоді як найкращий результат було досягнуто під час виконання з м’якими мітками, незважаючи на більш високі втрати.

Підготовка та навчання відбувалися на різному обладнанні. Комп’ютер із великою кількістю пам’яті зручно був для локального завантаження та оцінювання моделі Qwen3.5-35B-A3B у 8 біт, хоча точне оцінювання з використанням методу „вчитель-учень“ займало приблизно 60 хвилин для даних GPT та 41 хвилину для даних Qwen. Студенти тренувалися на GPU від NVIDIA. Одиночні виконання з записуванням тривалості тривали приблизно від 23 до 30 хвилин кожне, а більші комбіновані виконання займали близько 52 хвилин (з важкими мітками) та 55 хвилин (з м’якими мітками).

Результати, впорядковані за запитанням

У першій діаграмі намагалися показати все одночасно, що призвело до плутанини між двома окремими запитаннями: що відбувається, коли навчання починається з базової моделі, та що відбувається, коли воно продовжується з моделі траєкторії hard-token. Тому результати були розділені за дослідницькими запитаннями.

Для порівняння, результати використовуваних вчителів та базових моделей у оцінці з 220 завданнями були такими: без додаткової налаштуваності – 1/220, студент hard-token – 46/220, Qwen як вчитель – 96/220, а GPT як вчитель – 115/220. Метою експерименту з м’якими мітками top-k ніколи не було перевершити цих вчителів. Метою було з’ясувати, чи може більш насичений сигнал керування допомогти студенту з обсягом 0,8 мільярда параметрів досягти кращих результатів за тих самих умов.

Починаючи з базової моделі. Усі треновані варіанти перевершують нетреновану модель з результатом 1/220. Тренування лише з використанням GPT та лише з використанням Qwen дали схожі результати – від 41 до 43 завдань було вирішено залежно від методу. Об’єднання обох підходів призвело до значно більшої різниці: варіант з вагованими жорсткими токенами набрав 49/220, а варіант з комбінованими м’якими мітками – 55/220, що становить приблизно чверть від загальної кількості завдань. Це незначні результати в абсолютних цифрах та далеко від найкращого результату «вчителя» – 115/220, проте важливо те, наскільки модель об’ємом 0,8 мільярда параметрів піднімається від майже нуля, а не досягнення рівня «вчителя». Якщо починати з базової моделі, висновок полягає у використанні обох підходів, причому у цих об’єднаних даних м’які мітки виявилися ефективнішими за ваговані жорсткі токени.

Продовжуючи з прикладом студента з жорсткими токенами. Тут ситуація менш зрозуміла. Чекпоїнт вже вирішив 46/220 завдань. Додаткове навчання на слідах GPT із вагованими жорсткими токенами допомогло досягти рівня 48/220, тоді як м’які мітки на тих самих слідах призвели до падіння рівня до 44/220. На слідах Qwen з самооцінкою закономірність змінилась: ваговані жорсткі токени знизились до 38/220, а м’які мітки піднялись до 49/220.

Неочікуваний результат: м’які мітки допомагали лише тоді, коли оцінювач та слід збігалися. Qwen3.5-35B-A3B 8-bit виявився слабшим „вчителем“ з результатом 96/220 порівняно з 115/220 у GPT, проте його ймовірності відповідали його власним слідам, і там м’які мітки спрацювали (49/220), тоді як на слідах GPT з проксі-оцінкою вони завдали шкоди (44/220). Збіг оцінок мав більше значення, ніж сила самого „вчителя“.

Що змінилося у циклі агента. Базова модель майже ніколи не надсилала результати. Тренування з використанням траєкторій hard-token навчило її входити у цикл та надсилати дані, але багато з цих надсилань були неправильними. Поєднане тренування з використанням soft-label знову підвищило рівень успішності та є найкращим результатом загалом. Проте модель все одно надіслала 171 завдання та вирішила лише 55, що означає, що 116 надісланих запитів провалили приховані тести, а крім того вона мала ще 39 випадків зупинки через повторні дії.

Ось такий є справжній образ результатів. Модель провалюється не стільки через нездатність створювати коректні дії у форматі BAML, скільки через постійні помилкові рішення у форматі SQL та іноді застрягання у циклі.

Найнадійнішим показником поведінки була кількість поворотів. Середнє значення для комбінованого режиму з м’якими мітками становило 3,39 поворотів, на відміну від 3,48 у режимі теплого запуску з жорсткими токенами; різниця настільки незначна, що додаткові кроки не можуть пояснити покращення. Трохи кращий склад дій таке покращення пояснює: більше правильних вхідних даних порівняно з режимом теплого запуску, менше помилкових порівняно з комбінованим режимом з вагованими жорсткими токенами, а також менше помилок SQL та менше зупинок через досягнення ліміту поворотів. Кількість генерованих токенів за кожен етап оцінки не фіксувалась, тому не наводяться показники кількості вихідних токенів. Цифри, які можна без ризиків навести, походять з процесу навчання: кількість токенів запиту та цільового тексту, повна довжина послідовності та рівень покриття top-k.

Примітка щодо читання таблиць позаду діаграм: показник „submitted“ включає як правильні, так і неправильні подання, а показник „wrong submits“ дорівнює submitted мінус успішні подання. Колонка „SQL-error tasks“ не є виключною – завдання потрапляє сюди, якщо хоча б один з його SQL-запитів викинув помилку під час виконання, тож вона може збігатися з будь-яким кінцевим результатом.

Аналіз невдач

Якби оцінювати лише на основі спільного виконання базової моделі, результат виглядав би занадто ідеальним: змішані вчителі та „м’які“ мітки – і справа закрита. Розділені погляди менш охайні. Дивним є те, що слабший вчитель навчав краще, ніж сильніший, оскільки його ймовірності відповідали його власним даним. „М’які“ мітки набрали найбільше балів на шляхах Qwen з однієї родини, а також коли джерела були об’єднані. Вони набрали менше балів на даних GPT, які Qwen оцінював лише опосередковано, і це негативно вплинуло на елемент GPT warm-start.

Це цілком логічно: 8-бітні ймовірності Qwen3.5-35B-A3B добре описують 8-бітні дії цього моделювання, тому учень Qwen з обсягом 0.8B отримує більш чіткий сигнал для наслідування.

Під час виконання завдання зберігається останнє слово. Питання полягає у тому, чи може учень вгадати наступну дію вчителя, коли контекст схожий на контекст вчителя, під час його примусового керування. Система ставить ще складніші вимоги: чи може вона відновитися після власних попередніх дій, обрати розумні запити, уникнути замкнених циклів та завершити роботу з правильним SQL? Ці два аспекти пов’язані, але зовсім не є однаковими.

Показник втрат під час перевірки розповідає ту саму історію з іншого боку. При спільному використанні м’яких міток зі співвідношенням 55/220 показник втрат під час перевірки становив 0,5684, що є вищим за 0,3478 у варіанті з жорсткими токенами, який вирішив 49 завдань. Найнижчий показник — 0,2544 — належав базовому варіанту Qwen з жорсткими токенами, який вирішив лише 40 з 220 завдань. Низькі показники втрат при використанні методу навчання з вказівками вчителя не означають кращої продуктивності агента.

Результати, отримані при поєднанні обох підходів, є найкориснішими для навчання. Методи GPT змушували агента подавати відповіді частіше. Методи Qwen були простішими для оцінки та належали до тієї ж групи, проте спричиняли більше циклічних дій. Спільний варіант з м’якими мітками не просто поєднував найкраще з кожного підходу — проблеми з повторними спробами залишалися. Проте кількість вирішених ним завдань була найвищою, і порівняно зі спільним варіантом з жорсткими токенами він мав менше помилок під час виконання SQL-запитів та закінчував менше епізодів через досягнення ліміту кроків.

Метод контролю з ваговим фактором мав свої уроки. Вагомість рядків, залежна від рівня впевненості оцінювача, є дешевшою альтернативою використанню розріджених розподілів ймовірностей, і на даних GPT з попередньо оціненими значеннями він дав найкращі результати. Однак він не може повідомити учня про сусідні варіанти на кожній позиції; він лише пропонує «скопіювати цей токен жорсткіше чи м’якше». Методи з параметром Top-k підходять у випадках, коли оцінювач збігається з вихідним джерелом, а сукупність даних достатньо різноманітна, щоб учень не надто пристосовувався до стилю одного конкретного «вчителя».

Уроки з апаратного забезпечення

Були потрібні два типи пристроїв. Для оцінювання необхідно було зберігати модель Qwen3.5-35B-A3B у 8-бітному форматі в пам’яті та запускати її на зафіксованих об’єктах, тому доцільним був Mac із великою кількістю оперативної пам’яті — 128 ГБ єдиної пам’яті, яка може вміщати квантовану версію моделі. Він не був швидким, але дозволяв виконувати всі підготовчі кроки локально перед використанням платної GPU-пам’яті.

Навчання вимагало протилежного. Тонке налаштування LoRA є інтенсивним щодо використання матриц, оскільки включає кроки передачі даних уперед та назад, ядра уваги та кроки оптимізатора, і GPU від NVIDIA була набагато швидшою, незважаючи на меншу загальну кількість пам’яті, адже ці тензори залишалися у VRAM та оброблялися за допомогою ядер CUDA. Постійний урок полягає у тому, що ємність та продуктивність — це окремі проблеми. Велика кількість RAM у системі дозволяє зберігати та підготовлювати дані, тоді як VRAM GPU у поєднанні з CUDA дозволяє швидко їх обробляти. Робочий процес склався таким чином, що все можливе виконувалося на Mac, а віддалена GPU запускалася лише тоді, коли дані та скрипти були готові.

Уроки

Дистиляція з м’якими мітками заслуговує на спробу для дрібної налаштуваності агента, за умови оцінки її за результатами тестування. Невизначеність на рівні токенів містить більше інформації, ніж «тверді» токени, проте це залишається локальним керуванням, і саме по собі воно не навчить модель відновлюватися після невдалих викликів інструментів, уникати циклів чи краще аналізувати нові спостереження.

Проксі-м’які мітки мають бути позначені чесно. Рядки з GPT тут — це не власні ймовірності GPT, а ті, що оцінені за системою Qwen. Це все одно є корисним експериментом, просто це не справжня дистиляція логітів GPT.

Вчитель з тієї ж сімейства може перевершити сильнішого. Наскільки добре оцінювач відповідав оригіналу, мало більше значення, ніж сам бал оцінки.

Метод «рідкісний топ-к з хвостом» є прийнятним компромісом. Зберігання логітів усього словника було б більш повним, але вимагає значних ресурсів для зберігання, переміщення та навчання. Двадцять токенів разом із залишковим хвостом забезпечують достатню чіткість, щоб цільовий токен залишався видимим майже скрізь.

Змішування різних методів краще, ніж вибір одного оптимального. Найкращий результат було досягнуто шляхом поєднання рядків із оцінками GPT 5.5 medium та рядків із самооцінками Qwen, а також навчання базової моделі за допомогою м’яких міток.

Який результат?

Чи допомагає це? Так, за певних умов. У найкращій конфігурації метод дистиляції м’яких міток топ-к покращив продуктивність агента SQL обсягом 0.8B: рядки із оцінками GPT у поєднанні з рядками із самооцінками Qwen, подані до базової моделі unsloth/Qwen3.5-0.8B, вирішили 55 з 220 завдань, що значно краще, ніж у моделі, яка використовувала жорсткі токени (46 з 220), та у поєднаній версії з жорсткими токенами (49 з 220).

Не сприймайте це як твердження, що „м’які мітки завжди перемагають“. Джерело вчителя, ініціалізація студента, узгодження ймовірностей та поведінка під час виконання завдань — усе це мало значення, і вчитель, який вийшов на перше місце, не був тим, хто мав найкращий бал оцінки. Проблеми все ще виникають через агентні аспекти: неправильні SQL-запити, повторні дії та недосконале відновлення під час виконання циклу.

Саме тому цей бенчмарк варто зберігати. Студент може виглядати добре під впливом вчителя, але все одно зазнати невдачі, коли йому потрібно діяти самостійно. Будь-які подальші дослідження повинні зберігати постійні умови та перевіряти, чи нова ідея навчання покращує реальний цикл, а не лише показники втрат поза циклом.