TL;DR
UTT — техника, в которой слабая модель решает задачи, на ошибках сильная модель показывает правильное решение, а третья роль сводит уроки в один текст — «учебник» (Primer). Каждое новое дополнение проверяют: если на тех же задачах слабая модель с ним стала хуже, дополнение выкидывают. Готовый Primer просто кладут слабой модели в контекст. Веса не трогают, дообучение не нужно.
Обычно слабой модели пишут общий промпт: «будь внимателен, рассуждай по шагам». Это почти не помогает, потому что промпт не знает, где именно эта модель ошибается. Сильная модель, которую просят «написать инструкцию для слабой», тоже гадает. В UTT учебник строится только из реальных провалов: берут задачи, которые сильная решила, а слабая нет. Поэтому в тексте оказываются конкретные приёмы и подводные камни, которых слабой модели не хватало. Удивительная часть: такой текст, написанный для одной слабой модели, заработал и на другой, которая в его создании не участвовала.
Цикл из четырёх ролей: Student (слабая модель) решает задачу. Если ошиблась, Prompter по задаче и отзыву проверки формулирует учебную инструкцию. Teacher (сильная) по ней даёт целевое решение, и оно должно пройти проверку. Synthesizer вливает проверенные записи в общий Primer. Кандидата принимают, только если он не хуже прежней версии на том же пакете задач.
Схема метода
ПОДГОТОВКА: прогнать Teacher и Student на наборе задач с проверяемым ответом
→ оставить задачи, где Teacher решает лучше Student (обучающая часть)
→ отложить отдельные задачи для финального теста
ЦИКЛ по пакетам задач (в статье пакет = 16):
ШАГ 1 Student: решает задачу с текущим Primer → ответ
верно → следующая задача
ШАГ 2 Prompter: задача + отзыв проверки → учебная инструкция (в чём разрыв)
ШАГ 3 Teacher: задача + инструкция → показательное решение
решение не прошло проверку → запись выбрасывается
ШАГ 4 Synthesizer: текущий Primer + проверенные записи → кандидат Primer
ШАГ 5 ШЛЮЗ: Student с кандидатом на том же пакете не хуже, чем с прежним Primer?
да → кандидат становится Primer; нет → остаётся старый
ИТОГ: Primer кладут в контекст Student (или другой модели) как есть
В статье цикл гоняет код. Роли можно разыграть в разных чатах вручную, о чём ниже.
Пример применения
Задача: Вы ведёте магазин на Ozon и Wildberries. Бухгалтерия присылает сканы УПД, дешёвая модель вытаскивает из них ИНН, ставку НДС, сумму без НДС и дату. Она стабильно путает «НДС 20/120» и «НДС 20%», берёт ИНН посредника вместо поставщика и теряется на документах с несколькими ставками. Дорогая модель такие документы разбирает верно. Есть 40 документов с проверенными вручную правильными ответами. Сверка ответа с эталоном — это проверка из метода.
Промпт (шаг 2 — Prompter, в чате с дорогой моделью):
Ты — Prompter. Вот документ, ответ дешёвой модели и результат сверки с эталоном.
Документ: УПД №412 от 14.03, поставщик ООО «Ромашка» (ИНН 7701234567),
посредник ИП Сидоров (ИНН 770987654321), две позиции: НДС 20% и НДС 10%.
Ответ модели: ИНН 770987654321, НДС 20%, сумма без НДС 118 400 ₽.
Результат сверки: ИНН неверный (взят посредник), ставка НДС неполная
(пропущена вторая), сумма без НДС неверная.
Сформулируй учебную инструкцию для дешёвой модели: что именно она сделала
не так и какому правилу ей надо следовать. Не решай документ сам.
Результат: Модель выдаст короткую учебную инструкцию с диагнозом: какое поле перепутано и на каком признаке документа это видно. Дальше вы отдаёте эту инструкцию и документ дорогой модели (роль Teacher), сверяете её ответ с эталоном и складываете проверенные записи для Synthesizer. После 10–15 таких записей получается Primer: список правил разбора УПД с примерами. Его вы вставляете в системный промпт дешёвой модели и проверяете на документах, которых не было в обучении.
Почему это работает
Слабость. Общие подсказки («проверь ИНН, будь внимателен») не знают, где именно эта модель ошибается. Если сильную модель просто попросить написать инструкцию, она сочинит советы «вообще». Модель, которой показали только правильные ответы, не понимает, чем её ход мыслей отличался.
Сильная сторона. LLM хорошо следует текстовым правилам и приёмам, если они конкретны и подкреплены разбором. Сильная модель умеет объяснить, чем ошибочный путь отличается от правильного. Проверка на эталоне отсекает красивые, но неверные объяснения.
Как метод это использует. Учебник растёт только из реальных провалов: берутся задачи, где сильная права, а слабая нет. Урок попадает в текст, только если демонстрация прошла проверку. Новая версия принимается, только если не ухудшила результат на тех же задачах. Так в Primer остаётся то, что реально закрывает разрыв.
Рычаги: - Размер пакета (в статье 16) → меньше пакет: чаще обновления и дешевле проверка, но шумнее решение «принять/отклонить». - Критерий шлюза («не хуже») → ужесточите до «строго лучше», если Primer раздувается. - Роли → Prompter и Synthesizer можно дать той же сильной модели. В статье так и сделано, Teacher, Prompter и Synthesizer — одна модель. - Набор задач → чем разнообразнее типы ошибок, тем шире Primer. Но он длиннее, а значит дороже в токенах. - Тестовые задачи → держите отдельно, иначе измерите зубрёжку, а не обучение.
Шаблон промпта
В статье у каждой роли свой общий системный промпт без привязки к задаче. Конкретные тексты лежат в Приложении A.3, в предоставленном фрагменте их нет. Ниже реконструкция по описанию ролей, с сохранением логики и структуры.
Ты решаешь задачи типа: {тип_задач}.
Перед решением внимательно прочитай учебник ниже и следуй его правилам.
{текущий_Primer}
Задача: {задача}
Дай ответ в формате: {формат_ответа}
Ты — Prompter. Тебе дают задачу, ответ ученика и результат проверки.
1. Определи, в чём конкретно ошибся ученик.
2. Сформулируй учебную инструкцию: какое правило или приём ему не хватило.
3. Не решай задачу сам. Только диагноз и инструкция.
Задача: {задача}
Ответ ученика: {ответ_ученика}
Результат проверки: {отзыв_проверки}
Ты — Teacher. Реши задачу, следуя учебной инструкции.
Покажи ход решения и итоговый ответ в формате {формат_ответа}.
Задача: {задача}
Инструкция: {учебная_инструкция}
(Проверь ответ Teacher по эталону. Не прошёл — запись не используем.)
Ты — Synthesizer. Есть текущий учебник и новые проверенные записи.
Каждая запись: задача, ошибка ученика, инструкция, верное решение.
1. Извлеки из записей общие правила и приёмы, а не частные ответы.
2. Влей их в учебник: объедини повторы, убери противоречия, сохрани то, что уже работало.
3. Верни полный обновлённый учебник.
{текущий_Primer}
{проверенные_записи}
Прогони Student на том же пакете задач дважды: с текущим учебником и с кандидатом.
Считай верные ответы.
Если N_верных(кандидат) >= N_верных(текущий) → принять кандидата.
Иначе → оставить текущий.
Что подставлять: {тип_задач} — ваш рабочий тип задач с проверяемым ответом. {задача} — один пример. {отзыв_проверки} — что именно не совпало с эталоном. {текущий_Primer} — на старте пустой или короткая вводная.
🚀 Быстрый старт — вставь в чат:
Вот шаблон UTT (Universal Textual Teaching). Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какой у тебя тип задач, как выглядит правильный ответ и чем ты его проверяешь. Ещё спросит, какая модель слабая, какая сильная и сколько у тебя размеченных примеров. Это нужно, потому что без проверяемого ответа шлюз и отбор записей не работают. Из этого она соберёт четыре готовых промпта и порядок прогона под твою задачу.
Ограничения
⚠️ Нужна проверка с однозначным ответом. Метод держится на сверке с эталоном: она решает, верна ли демонстрация Teacher и принимать ли кандидата. В статье это математика с готовыми ответами и GPU-код, который запускают и измеряют. Для текстов в духе «хороший пост» или «убедительное письмо» такой проверки нет.
⚠️ Нужен набор задач. Бюджет в статье — 100 и 200 примеров на задачу, плюс отдельные тестовые. Без размеченных кейсов цикл не запустить, а ручной прогон 10–15 примеров даёт слабый, неустойчивый Primer.
⚠️ Teacher должен решать лучше Student. Обучающие задачи — только те, где сильная модель права, а слабая нет. Если Teacher не справляется, урок брать неоткуда.
⚠️ Побочный вред возможен. На части задач, которые слабая модель и так решала, точность после Primer упала. В математике у двух из трёх конфигураций заметное падение, в статье называют 9,2 и 14 пунктов, остальной текст обрезан. В коде такого не было. Всегда проверяйте Primer на задачах, которые модель решала и без него.
⚠️ Перенос неравномерный. Primer, созданный для одной модели, на другой обычно работал, но не одинаково. На математике Primer, написанный под Qwen, дал Flash заметно меньший прирост, чем собственный Primer Flash. На быстродействии кода перенос с Opus на Qwen был слабее. Для важной задачи проверяйте Primer на целевой модели.
⚠️ Широта проверки узкая, исходный уровень низкий. Статья проверила только математику и GPU-код. Начальная точность там была очень низкой (около 9% на коде), а у такой отправной точки прирост всегда сильнее. Не рассчитывайте на +40 пунктов, если ваша модель уже решает 80% задач.
⚠️ Контекст и цена. Primer — это длинный текст на каждом запросе. Он ест токены и место в контексте.
Как исследовали
Идея была простой: вместо дообучения слабой модели написать ей учебник. Взяли две трудные задачи: олимпиадную математику (Omni-MATH-2) и генерацию GPU-ядер (KernelBench), где код запускают и меряют корректность и скорость. Собрали три пары «учитель → ученик»: DeepSeek Pro → Flash, Pro → Qwen3.6-27B и Claude Opus → Flash. Все задачи прогнали у обеих моделей и разбили на подмножества: где учитель сильнее (из них учебные и тестовые), где слабая и так решала, где не справились обе. Учебник строили только на обучающей части, остальное оставили для чистой проверки.
Результаты в таблице: на KernelBench точность Flash с Primer выросла с 9,4% до 48,6%, быстрые решения (Fast1) с 9% до 35%, на математике с 27,6% до 51,7%. Сравнили с one-shot, few-shot, суммой от учителя, автооптимизаторами промптов (APE, MIPROv2, GEPA) и методами с дообучением (SeqKD, Fine-tune-CoT, RSR, LUFFY). По авторам, UTT их превосходит, но цифры в доступном фрагменте обрезаны.
Самое удивительное: Primer, созданный для Flash, подняли в Qwen, который в его создании не участвовал, и точность там выросла на 32 пункта. Примерно так же сработал Primer, созданный Opus, на Qwen (51,0% на коде и 65,8% на математике). Главный вывод для практики: текстовые уроки, добытые на ошибках одной модели, часто обобщаются на другую. А на задачах, которые слабая модель решала и так, на коде точность не просела, а выросла.
Адаптации и экстраполяции
Это мои переносы идеи. Авторы их не проверяли.
💡 Адаптация для файла инструкций агента: вместо Primer для чат-модели собираем правила для CLAUDE.md или AGENTS.md. Агент выполняет 10–20 типовых задач, на провалах сильная модель (или вы) разбирает, какое правило ему не хватило, Synthesizer сводит их в файл. Шлюз: перед принятием правил прогоните агента на тех же задачах.
Ты — Synthesizer. Вот текущий CLAUDE.md и разбор {N} провалов агента
(задача, что агент сделал не так, что надо было сделать).
Выведи общие правила, объедини повторы, убери противоречия.
Верни обновлённый CLAUDE.md не длиннее {лимит} строк.
🔧 Техника: шлюз как отдельный приём → защита от «раздувания» инструкций. Любую правку системного промпта принимайте, только если на фиксированном наборе из 10–20 кейсов результат не хуже прежнего. Это работает и без остальных ролей.
Вот два варианта системного промпта: A (текущий) и B (с новыми правилами). Прогони оба на этих 15 кейсах и посчитай, сколько ответов совпало с эталоном. Если B не хуже A — оставь B, иначе A.
Ресурсы
- Universal Textual Teaching for LLMs — Zhanyi Lu, Huan Wang, Westlake University
- Страница проекта: https://alexlu99.github.io/UTT/
- Бенчмарки: KernelBench (Ouyang et al., 2025), Omni-MATH-2 (Ballon et al., 2026)
- Связанные методы: APE, ProTeGi, OPRO, MIPROv2, TextGrad, GEPA, Dynamic Cheatsheet, ExpeL, AutoManual, SkillX