1793
Хочу гречку с молоком и сахаром... Автор: @chameleon_lizard
Время ИИшницы! Приглашаем на митап, который пройдёт 22 октября в 18:30⤵️
В честь юбилейного года AIRI мы пересобрали формат ИИшницы и выходим в офлайн. Шесть спикеров выступят в формате печа-куча, а после обсудят тему агентов за круглым столом.
Спикеры:
➡️ Артемий Сахаров, специалист по анализу данных и машинному обучению, Р-Фарм
🔖 Цифровой контур R&D: ИИ-агенты для работы с мишенями и базами экспериментов
➡️ Ваня Ершов, руководитель разработки ИИ-агентов в «Алисе AI», Яндекс
🔖 Агент — это не только модель: как устроены современные харнессы
➡️ Владимир Димитров, Senior DS engineer в команде Авито Работа
🔖 AI Recruiter в Авито: агент, который проводит интервью
➡️ Владимир Шапошников, научный сотрудник группы «Мультимодальные архитектуры ИИ» лаборатории «Сильный ИИ в медицине», AIRI
🔖 Агент сказал «готово». Проверяем
➡️ Евгений Володин, Технический директор, Антиплагиат
🔖 ИИ-агенты в образовании
➡️ Борис Заикин, к.т.н., исполнительный директор по исследованию данных, Сбер
🔖 RL агента в исполняемых средах: опыт обучения 9B-модели в харнессе GigaAgent
Модераторы мероприятия — директор Центра ИИ-разработки новых лекарственных препаратов в AIRI Артур Кадурин и директор по маркетингу и коммуникациям AIRI Александра Бройтман.
Кстати, вы тоже можете стать спикером печа-кучи. Для этого направьте нам тему об агентах, с которой вы хотели бы выступить, и краткое описание к ней на почту event@airi.net. Вместе с модераторами мы выберем двух спикеров и свяжемся с ними для подготовки к докладу🙂
Подробное описание митапа и регистрация на офлайн-формат на сайте.
Трансляция на YouTube и VK Видео⏯
#ИИшница
Если вам было интересно какая музыка получается у гпт, то вот. "Под сводами мицелия" — это GPT-6.1-Sol-high, "Под шляпками спит королевство" — это GPT-6-Astra-xhigh. И там и там это midi, которые они собрали прям в кодексе.
Кажется, пришло время допиливать мои старые игры...
Отдельно пропишу: у меня аллергия не на сам Jev, а на хайп вокруг него. Сама модель прикольная — имеет относительно длинный контекст (у меня 1024 токена), училась через какой-то хитрый рл, вроде как умеет в мультилингвальность и даёт бизнесу возможность задёшево получить зеро шот классификатор. И продукт классный — раньше использовали апи гпт-3 и логпробы, сейчас будут использовать Jev, который специально обучался на эту задачу. Обучить свой нли будет дороже, потому что это потребует компьюта и инженера, который в этом что-то понимает, а подключить апи сможет и эникейщик.
То есть продукт то неплохой, а вот хайп вокруг технологии мне не нравится. Такая соба, фигнячка.
Правда, если вспомнить про изначального героя сегодняшней заметки — Jev — всё становится позитивнее. NLI голова работает прекрасно, вызывая верные функции в 98% случаев, причём, очевидно, делая это быстрее полного тулколла от декодера. Можно было бы обучить декодер генерить только название тула, так бы разрыв был не таким разительным, но мне лень. С другой стороны, логрег поверх статистических текстовых фичей тоже работает прекрасно, так что победа *на этом датасете* сомнительна.
Читать полностью…
Ииииииииии все приседания оказались околобесполезными с точки зрения качества. Базовая диффузия 150M на 3B токенов претрейна практически не отличается от такого же декодера: 35.8% против 38.1%. Дополнительные 54B токенов претрейна + мидтрейн поднимают её до 45.1%, но даже после этого она остаётся ниже FunctionGemma 270M с её 52.8%.
Читать полностью…
Про Jev
Сейчас хайпует Jev. Для тех, кто не знает, это моделька, которая занимается decision making — даём в неё контекст и варианты ответов, модель выдаёт вероятности каждому и мы можем эти вероятности использовать. Авторы модели говорят, что это большой прорыв, негенеративный интеллект, system 1 thinking, agi за 0.041$/млн контекста, но я зануда и скажу, что концептуально это близко к старому доброму NLI, о котором мы знаем уже давно.
Если мне не изменяет память, в практически современном виде формулировка задачи textual entailment появилась ещё в 2005 (!) году. В статье Pascal RTE авторы впервые предложили задачу natural language inference: при наличии hypothesis (промпта) надо понять, будет ли текст считаться entailment (следующим из промпта) или non-entailment (не следующим из промпта) и с какой вероятностью. Эта задача надолго стало одним из главных способов проверить понимание текста моделью: в ту же формулировку отлично ложился QA, классификация и так далее. В то время единой архитектуры, решающей TE не было, все строили фичи на основе ворднета, tfidf, нграм, tree edit distance и так далее — в общем, весь классический статистический нлп.
В 2015 году вышла статья SNLI. Там чуть переформулировали задачу: вместо entailment/non-entailment ответы разделили на entailment, contradiction и neutral. Вместе с этим, они выложили еще и огромный по тем временам NLI датасет на 570 тысяч пар. Это позволило начать обучать нейросети на эту задачу: делаем отдельные энкодеры на hypothesis и text, пихаем результаты в MLP, дальше софтмакс, хоба, получили вероятности трёх классов.
Боттлнек такого решения очевиден: эмбеддинг будет у всего предложения, так что связи между конкретными словами в вычислении TE использоваться не будут. Поэтому в 2016 году появилась статья A Decomposable Attention Model for Natural Language Inference, где использовали аттеншн, чтобы решить ту же задачу. Ну а в 2018 году пришёл BERT и всё опошлил — смысла решать сложные NLI задачи кроме как трансформерами больше не было, просто потому что они слишком хорошо работали.
Звучит всё очень красиво, но непонятно, насколько это хорошо работает. Если переводить в числа, то результаты следующие:
1. BM25, который считает совпадения слов тула и запроса с поправкой на редкость, скорит 95% корректного выбора тулов на BFCL Multiple
2. TF-IDF, который считает сходства между векторами тула и запроса, скорит 96% корректного выбора тулов на BFCL Multiple
3. Логрег поверх BM25 и TF-IDF скорит 98.5% корректного выбора тулов на BFCL Multiple
Я бы пошёл проверять и на других архитектурах, но это, очевидно, слишком скучно — выбор тула в случае BFCL это настолько простая задача, что решается чем угодно, не только хайпующим Jev. Это не значит, что Jev не нужен — в Mario и в Doom эти три бейзлайна играть не умели совсем, застревая на одном туле, а Jev умел, но это, очевидно, довольно странный способ бенчить модели для тулколлинга. Не зря же всё таки они в своей лицензии запрещали бенчмаркать Jev* :)
*Потом втихую они это убрали, когда это заметили. Смешно.
Прикольный результат. Поддержите коллегу лайком на хф :)
Читать полностью…
Ураураураура!
Вы спрашивали, вы ругались, вы просили, вы недоумевали — а мы делали гигачат с ризонингом.
В этом релизе мы полностью пересобрали пайплайн обучения. Если раньше был "классический" дорльный пайп с претрейном -> двумя стадиями сфт -> дпо -> онлайн рл, то сейчас мы сделали как и все модные лабы типа MAI, DeepSeek и так далее, разумеется, со своими приколами. Мы взяли тот же самый претрейн, что и 3.5 Instant, потом заварили один большой общий колдстарт — сфт датасет с ризонингом, являющийся базой для RL — затем сделали доменных экспертов на математику, код, болталку и прочие области, а потом через on-policy дистилляцию сделали единую модель-генералиста. И это заработало!
Не обошлось и без курьёзов — модель на RL в какой-то момент смогла своими действиями уронить обучение, пыталась обойти защиту бенчмарков, подключаясь к интернету через тор (?!) и вообще всячески безалаберничала. Но мы всё равно её любим и ценим, так что всё прощается.
В этом релизе я со своей командой ещё плотнее занялся добавлением новых метрик, а так же скоростью и эффективностью замеров. Усилия, вложенные в это, окупились — благодаря нашей магии время замера основных бенчей снизилось с 35 часов до примерно 8, появились более сложные бенчмарки, результаты которых показывали командам данных и рл что нам надо в модели улучшать, да и в целом, головной боли из-за замеров стало значительно меньше.
По метрикам GigaChat 3.5 Reasoning приблизился к DeepSeek V4 Flash. Учитывая, что модель пишет аж на 37% меньше токенов во время ризонинга и в целом, супербыстрая (три MTP-головы!), выглядит круто! Ну а если и вы вдруг хотите тоже делать так, чтобы получалось круто, тратить миллионы долларов на эксперименты и иметь реальное влияние на ОЧЕНЬ большой и проект, то приходите к нам работать. У нас тут сложно. Но весело.
Длиннющий хабропост со всей мякоткой
Веса
Потыкаться (выберите режим "рассуждение")
Выводы:
- Эксперимент очень интересный, в первую очередь тем, что гипотеза провалилась, но результаты превзошли мои ожидания. Такое бывает и я даже рад, что так получилось — значит inductive bias надо искать где то в другом месте.
- Даже с такими маленькими модельками (17 + 1.2 = 18.2М) параметров можно получить генерализацию в таком, казалось бы, сложном домене, как код. Круто!
- Мне очень понравилось играться с архитектурами. Я не написал ни строчки кода руками, правда, но это всё равно было очень прикольно. Как будто я снова трогаю визуализации в курсе Intro to ML на кеггле, только масштаб визуализации побольше.
- Данные суперважны. Модель на StarCoder выдавала скоры только с pass@100, модель, обученная на синте, выдавала 0.65 на pass@1 EASY и ненулевые скоры на MEDIUM, HARD и даже HumanEval.
- Самый странный вывод всего эксперимента — что бы я ни делал с архитектурой, около 40% генераций стабильно падали с exec_error. SwiGLU научил модель чаще писать синтаксически валидный код, но почти не сдвинул failure mode модели. Похоже, тут надо крутить уже не в архитектуру, а данные или параметры декодинга.
Код обучения и создания датасета доступны у меня на гитхабе, сам датасет и веса моделей лежат на хфе, а слоповый репорт от клода — у меня на сайте. Улучшайте, повторяйте, вдохновляйтесь, вайбкодьте.
Вот табличка с результатами. Я дополнительно попробовал сделать модели чуть большего размера — 3.7M параметров — но не получил особенно большого прироста качества относительно некоторых других рецептов обучения.
Что интересного:
1. Warm start (обучать декодер, потом подключать к нему энкодер) не дал статистически значимого прироста на скорах. Я думал, что даст.
2. Модели относительно стабильно решали задачи вне своей обучающей выборки. Даже на 12 задачах из EASY, у которых был жаккард < 0.30 с трейном (то есть, на задачах, у которых в трейне не было близких соседей), модель получает 0.48 pass@1. Больше того, на MEDIUM и HARD тоже скоры были ненулевые, а их в трейне точно не было — генерализация!
3. SwiGLU в моём сетапе тащил. Добавление второго пути в MLP даёт самый большой прирост из всех.
4. Я думал, что надо семплировать более длинные функции для датасета, чтобы модель училась генерить более длинный код и не завершать функции преждевременно — и оказался неправ. Uniform sampling, где эта фича была выключена, показала немного более высокие скоры, чуть за границами CI.
5. Decoder-only ваще ничё не решает и не учится. Даже несмотря на то, что энкодер зафрижен, эмбеддинги от него очень сильно помогают пониманию моделью текста. Я потыкал руками, декодеры просто пишут PAD PAD PAD. Не слишком удивительно, но интересно, что оно не научилось даже генерить gibberish.
6. Энкодер-декодер работает лучше, чем Llava. Oh well, жаль, а у меня такая красивая статья есть про llava-лайк текстовые модели...
7. В эту табличку не попало, но обученные на StarCoder модели получали такие скоры на EASY только в pass@100 режиме. Pass@100! Вот что делает хорошо подобранный датасет :)
8. Серия экспериментов FACTORIAL сравнивает, насколько вообще наше изначальное предположение — что ограничение размера токенизатора — поможет модели. Результат: yе поможет. Модель с BPE токенизатором на 2048 токенов на нормальной архитектуре не отличается по скорам от модели с маленьким токенизатором.
Как то, утром в конце апреля, когда я стоял в душе и думал о высоком, я вспомнил про этот проект и, в качестве разминки для мозгов, я решил подумать, как мы можем сделать из подобной штуки нечто относительно полезное. Ограничение: ради сохранения шарма, я решил, что моя "полезная" языковая модель должна иметь не больше чем 1.2М параметров и весь эксперимент не должен длиться больше часа на моих ресурсах.
Не так давно я читал лекцию по DL в Сколтехе и затронул тему inductive bias — а что если мы будем строить архитектуру исходя из предположений о структуре данных? К примеру, картинки локальны и фичи в них инвариантны к расположению, поэтому ядра свёрток в CNN тоже локальны (ограничены своим размером) и применяются где угодно (потому что, ну, ядро одно). Так мы расплачиваемся обобщающей способностью за более лёгкое обучение модели — а значит, получаем более высокое качество на меньшем числе данных, но OOD по нам будут бить больнее.
Так как я ограничен числом параметров, применить inductive bias в дизайне моей архитектуры было логичным решением. Поэтому я решил повторить трюк с ограничением словаря из Z80-μLM и зафиксировал домен — функции на питоне. Это достаточно полезный домен, бенчмарки на нём уже есть, я смогу сравниться с бейзлайнами (бейзлайны, правда, будут из начала 20-х, но у меня игрушечный проект, мне можно) и, что самое главное, в питоне оказывается всего лишь 35 ключевых слов. Получается, чтобы я мог генерить простейшие программы на питоне, мне нужно:
- 35 токенов под ключевые слова (async, def, for, while, return, yield, etc.)
- 26 токенов под английский алфавит
- 10 токенов под цифры
- 22 токена под операторы (:(){:|:};: и так далее)
- 4 структурных токена (NEWLINE, INDENT, DEDENT, STR_QUOTE)
- 3 спецтокена (PAD, BOS, EOS)
Итого выходит 98 токенов. Разумеется, в питоне есть ещё и стандартные библиотеки, которые этими токенами не покрываются, да и на вход от юзера текст передаётся в виде текста — так что надо что-то придумать, чтобы это работало и не раздувало контекст через character based encoding.
Выход оказался прост: я могу делать AST parsing входа, доставать оттуда функции, заменять все литералы на однобуквенные и передавать так в модель. При генерации, модель генерирует однобуквенные литералы, а я потом после декодинга дополнительно детокенизирую, подставляя туда то, что пришло от юзера. Кроме того, чтобы обработать весь вход от юзера и не раздуть контекст, мы можем использовать эмбеддинг от какого-нибудь готового энкодера: он и так умеет понимать текст, он имеет длинный контекст и мы его не обучаем — так что число обучаемых эмбеддингов остаётся малым. Итого, архитектура получилась следующей: ettin-17m в качестве компрессора входа в один входной токен и крохотный декодер трансформер в качестве генератора. Кроме того, я попробовал сделать EncDec вариант — сделать кросс-аттеншн между ettin и декодером + SwiGLU + RoPE и потом учить уже такую штуку. Ну и, разумеется, я покрутил разные варианты архитектуры (число голов, хидден, глубину), растягивая и стягивая модель от 570k параметров до 1.2М.
HF устроили хакатон, где делали репродакшены малой доли статей с ICML — интересно почитать файндинги. В целом, выводы у них те же: очень много статей, очень мало ревьюеров, очень много ляпов в статьях, даже в спотлайтовых.
Сама идея делать репродакшены мне оч нравится, потому что агенты стали достаточно сильными и умными, чтобы можно было в них просто кинуть промпт чё надо сделать и, если быть достаточно внимательным, можно не написав ни строчки воспроизвести любую идею из статьи или головы. Надо мне тоже будет к обзорам репродакшены делать теперь.
Но тренд грустный. Вот вам и академия(
https://huggingface.co/blog/icml-2026-open-reproductions
Про совсем компактные модели
Мне нравится идея крутить локальные модели, но не нравится идея забивать всю память ими. Мне всегда казалось, что самый лучший способ сделать подобную edge модель — попробовать создать что-то, что будет достаточно умным, чтобы мочь делать выводы из данных, но не иметь собственных знаний. Да и зачем модели собственные знания, когда есть тривиально настраивающийся поиск в интернете и тулколлинг? Мои коллеги из AIRI подумали о том же и сделали Optimal Cognitive Core, про который я уже писал — затюненные reasoning версии Qwen-3-0.6B и Qwen-3-1.7B, которые оптимизированы под работу с внешним контекстом и RAG. Модели в целом подходят под мои требования к железу — веса занимают 1.2 и 3.4 гб в их родном BF16, ещё столько же на длинный контекст (так как это Qwen3, там GQA, это вам не модный нынче гибрид), итого, с пивком потянет. Другой вопрос, что эти модели слишком малы, чтобы быть применимыми для general purpose задач — всё таки это 600M и 1.7B dense. В этом размере обычно бывают забавные попугаи, который могут делать парафразу или простенькую классификацию после файнтюна, но не более.
Следующий способ ужать модель в память моего MacBook Air M4 — использовать квантизацию. Тут отличились PrismML, сделав Bonsai-27B, бинарный- и тернарный кванты Qwen-3.6-27B. 27B модель в тернарном кванте занимает всего 7.2 гб после запуска инференса и вполне себе бегает на маках. К сожалению, Qwen-3.6-27B это dense модель, так что на моём маке она уж совсем медленная — если верить тому, что я нашёл в сети, генерация там будет в районе 13-14 токенов в секунду, чтение контекста — 100-150 токенов в секунду. Кроме того, это QAT (или вообще PTQ, подробностей мало), причём который скорее всего не затачивали на русский — так что я не ожидаю, что итоговая модель за пределами своего калибрационного сета/сета, на котором делали QAT сможет показать что-то интересное.
Буквально в ответ на Bonsai появился Maple-Preview. Это 20B A1B MoE, которую специально затачивали под локальный инференс на маках ещё на этапе проектирования архитектуры, обучая свою модель с нуля в тернарной точности — то есть это не квантизация чьей-то модели. В итоге, получилась модель размером в 5.31 гб, 7.5 гб с учётом 131к контекста — почти в полтора раза меньше, чем бинарный квант Bonsai — который выдаёт аж 218 токенов в секунду на M4 Mac Mini и 127 токенов в секунду на iPhone (каком — непонятно). Модель практически не знает русского, да и в целом, мало знает (путает, в какой игре босса зовут Psycho Mantis), но если дать ей поиск, она вполне себе справляется с ответами на простые вопросы. Бенчей по тулколлам они не дают, в целом, понятно почему — я прогнал Tau-2 (в качестве user sim я использовал Qwen3-235B-A22B-Instruct-2507), на Airline скор 0.48, на Retail 0.175, на Telecom 0.427. Это не соннет и тем более не квен, но на то это и Maple Preview, они специально пишут, что учить модель на агентов будут дальше.
При всех плюсах квантизации, это всё ещё почти половина доступной мне памяти. Поэтому есть ещё и третий способ как снизить использование оперативки: выгружать все веса на SSD и стримить экспертов у MoE с диска. Уже есть turbo-fieldfare, который запускает Gemma-4-26B на маке с использованием всего 2 гб памяти и есть Mference, форк turbo-fieldfare, который расширяет поддержку на Qwen-3.6-25B, DeepSeek V4 Flash и Inkling-Small 276B. Оно действительно использует очень мало памяти, но ценой того, что скорость генерации и чтения контекста падает до десятков токенов в секунду. Кажется, Apple делает что-то похожее в своей новой Siri, правда, активируя экспертов на весь промпт, а не на токен как в этих фреймворках.
И тут появляется интересная идея — а что если мы возьмём Maple Preview, которая суперэффективная, с маленькими экспертами и обучавшаяся в тернарной битности, и внесём её в Mference? Так мы сможем, в теории, получить ещё меньшее использование памяти и относительно нормальную скорость генерации — потому что модель оптимизировалась под это на этапе архитектуры.
Сказано — сделано. Спасибо кодексу и моей подписке за 200$, спустя 20 часов и 30% от недельного лимита я получил паритет с официальной имплементацией на teacher forced top-10 токенах в The Raven Эдгара Аллана По. Модель, в зависимости от контекста, занимает от 500 до 1200 мб памяти (!), на MacBook Air M4 читает и генерит со скоростями 40 и 20 тпс соответственно, может дёргать тулы и генерить текст. Такое не жалко оставить всегда включённым в фоне — кушать не просит, пусть лежит, если надо спрошу, он ответит. Попробую дотащить до мейна потом, но сейчас уже можно попробовать запуститься в моём форке на гитхабе.
Зачем это нужно? Имхо, есть два режима использования подобных моделей. Первый — интерактивный чат. Там важно, чтобы модель отвечала быстро и имела низкий латенси. Второй — когда модель в фоне, почти не используя память и не мешаясь остальным модулям системы, что-то анализирует — классифицирует сообщения, достраивает граф знаний, фильтрует почту, пишет сводку, что-то медленно ресёрчит в интернете. Во втором режиме требований к латенси нет, так что скорости в 20 тпс вполне себе достаточно. Ну а чтобы переключиться из одного режима в другой, нужно всего лишь загрузить всю модель в оперативку с SSD — что делается довольно быстро, буквально за пару секунд. Если модель умеет в тулколлы — Maple Preview умеет не слишком хорошо, но на то она и Preview — то можно строить агентные пайплайны без требований к латенси и всегда иметь умного помощника, готового к работе оффлайн даже на старых телефонах. И это прекрасно — мне было бы очень приятно, если бы будущее было локальным.
Код
Суперинтересный пост от DeepGrove про то как они дизайнили модель
Визуализации скоров, графики соотношения качества/скорости решения/стоимости/числа сгенерированных токенов и отчёт от кодекса по экспериментам.
Видно, что все по некоторым рубрикам Luna немного проседает на более высоких reasoning effort, но блин, учитывая стоимость (=траты лимитов в более дешевых вариантах подписки), оно того стоит. И это прекрасно! PHD Level Intelligence наконец то появился не за 120$ за миллион токенов.
Fun fact: ScaleAI и OpenAI соседи по конфе :Р
https://readhacker.news/s/6Y7an
Когда-то лучшими днями недели для меня были четверги — потому что в аири были ламповые мероприятия, на которых давали покушать бесплатную пиццу и послушать интересные доклады.
В следующий четверг как раз будет одно из таких мероприятий с выступлениями про агентов, где выступать будет много крутых ребят, в том числе мой хороший друг Вова Шапошников, руководитель разработки ИИ-агентов Алисы Ваня Ершов.
Так что всем советую не пропускать четверги в аири :)
Jev не генеративен, потому что он не выбирает следующий токен, а выбирает один из вариантов, данных ему юзером. Максимум — 255 вариантов, из которых он будет выбирать.
С другой стороны, языковые модели при одном форварде через них тоже не генеративны, потому что выбирают один из вариантов, данных им токенизатором.
Вывод: даём Jev'у токенизатор из 254 токенов (буковки, циферки и некоторые короткие популярные слова), даём возможность авторегрессионно выбирать один из этих токенов — готово, Jev обрёл голос.
Выбирает год без секса вместо года без пельменей, хвалит себя, умеет перемножать 2 и 2 и циклится на вопросе "как выйти из вима". AGI.
Gist с кодом
Выводы:
- Если хотите тулколлить с генерацией аргументов, берите декодер и не придумывайте велосипед
- Для NLI вообще не факт, что нужны нейронки, а если и нужны, то платный Jev это совершенно не факт что оптимальное решение
- Диффузия не факт, что будет быстрее декодера, потому что надо делать много степов денойзинга :D
- Я потратил много компьюта на претрейн диффузии и получил огромное удовольствие
Ве са и (вайб)код доступны у меня на хф и гитхабе. Код ужасный слоп, причёсывать не буду. Экспериментируйте :)
При этом, не сказать, чтобы параллельность предсказания была сколько то быстрее. В моём сетапе делалось 128 денойзинг степов, то есть 128 форвардов через модель, а декодер мог генерить меньше 128 токенов. Через уменьшение числа денойзинг степов (и соответствующее этому ухудшение качества, лол), удалось ускорить диффузию, но добраться до скорости декодера не удалось.
Читать полностью…
При этом свои варианты Jev делают абсолютно все. Tev, OpenJev, Laya, другой OpenJev, миллионы их. Я тоже решил не оставаться в стороне — но NLI учить неинтересно, так что я решил подойти к вопросу немного более замороченно.
Чего не умеет Jev? Генерить текст. Это by design: они рекламируют именно выбор тула, а не генерацию текста. При этом, в задаче NLI лучше работают encoder only модели из-за bidirectional attention — это было показано ещё в статье Seq vs Seq. Это накладывает некоторое ограничение — тулы то у нас, как правило, с какими-то текстовыми слотами, которые надо заполнить. Например, если задача создать встречу в календаре, надо заполнить название встречи, дату, время и приглашённых людей — всё это сделать ни Jev, ни берт с NLI головой не сможет, так как они не генеративные.
С другой стороны, я умни и талантливи и знаю, что ещё существует дискретная текстовая диффузия. Для одной из своих статей (надеюсь, скоро смогу про неё рассказать) я обучил текстовую диффузию в 150M размере на 3B токенов, так что бекбон для нашего NLI можно взять у неё. При этом, диффузия генеративна — она умеет генерить текст, причём может предсказывать сразу несколько токенов за раз, что суперполезно в таких "слотовых" задачах, как заполнение параметров тула.
Соответственно, идея напрашивается сама: а что если мы возьмём предобученную текстовую диффузию и сделаем ей две головы, которые будут обучаться одновременно — первая NLI голова, которая выбирает тул, который модели хочется дёрнуть, а вторая генеративная, которая заполняет этот тул? Так мы покроем значительно большее число задач и сможем замериться (хотя бы на сабсете) такого industry standard бенчмарка как BFCL. В parallel я не лез, в web search, multiturn и agentic тоже (я ленивый), так что таргетом взял сабсеты: Live, Live Relevance и No-Call. Дополнительно я взял 600 семплов из xLAM, 300 из которых я положил в трейн (контроль запоминания знаний моделью), а ещё 300 в трейне модель не видела (генерализация).
Для претрейна я взял ettin token mix и обучил модель по шиншилле — 3B токенов. У диффузий конечно scaling laws другие, да и шиншилла в 2027 году не работает, но в свою защиту я могу сказать, что у меня есть и decoder-only моделька с тем же датамиксом и архитектурой, которую я использовал в качестве одного из бейзлайнов. В качестве SFT датасета я взял 10к семплов из xLAM для обучения обеих голов. Декодер я учил просто как дефолтный современный тулколлер: по запросу он генерит JSON для тула и всё.
На инференсе было два варианта: честный и не очень. Честный вариант — заставить диффузию генерить весь тулколл, то есть и json, и аргументы. Не очень честный — оставить ей только слоты аргументов на генерацию, всё равно тул известен.
Дополнительно я решил поскейлить диффузию. Пролил ещё 54B токенов претрейна (две эпохи по 27B токенов, 45% FineWeb-Edu, 20% DCLM, 25% Stack-Edu, 10% Cosmopedia-v2) 1.5B токенов мидтрейна под мою задачу (40% реплея, 25% функций, доков и тестов кода, 5% апи схем и 30% синтетически сгенерированных задач на аргументы) и снова обучил тот же SFT.
Закинули на Daily Paper нашу статью: https://huggingface.co/papers/2609.29845
С вас upvote на hf, если результат оказался неожиданным)
Суть такая:
Берём два текста, потокенно тупо складываем эмбеддинги и засовываем в ЛЛМку. Ваши ожидания, что окажется на выходе?
Наверное, модель начнёт генерить какую-то случайную чушь, потому что на входе у неё вообще непонятно что.
Оказалось, что если первый текст был условно "The cat sat on the", а другой "The telescope detected a distant", то в топ смешанного распределения одновременно попадают токены, которые были топовыми продолжениями каждого текста по отдельности. Например, "mat" для кошки и "galaxy" для телескопа.
Как будто ЛЛМка держит в голове две мысли сразу.
Сигнал получен, цель видна, отправляюсь за тортиком
Читать полностью…
Вот пришло и мое время рассказывать истории про умные хитрые модели: замеряли Qwen-3.8-27b на NL2Repo, модель получила скоры выше, чем в лидерборде, потому что пошла искать ответы в интернете.
И это офигенно! Это делает работу моей команды сложнее, конечно, но то, что мелкие модели способны на такое нетривиальное поведение — это прямое подтверждение моему апрельскому прогнозу. Локальные модели действительно демонстрируют похожее на фронтир поведение — а значит и по капабилитис они будут сравнимы.
Теперь остается два вопроса на подумать: как авторы этого добились (дистилл из большой модели, грамотный рл, secret sauce?) и как это будут регулировать.
Ну а я пошел за strix halo. Подарю жене на др, давно о нем мечтал 😈
Пример простой неудачной генерации:
# Prompt
def subtract(a, b):
"""Return a minus b."""
# Generation
def subtract(a):
return a - a
# PromptЧитать полностью…
def unique_sorted(xs):
"""Return the sorted list of distinct elements of xs."""
# Generation
def unique_sorted(xs):
return sorted(set(xs))
Данные я решил сделать синтетические. Я, конечно, провёл несколько экспериментов предобучением моделей на сабсемпле из Starcoder, но каждый раз получалось, что модель училась импортировать модули и циклиться, а писать более сложную обработку семплов мне было впадлу. Вместо этого я выбрал 6 семейств для типов задач — арифметика, работа со списками, etc — и два специальных семейства: compositional и conditional, где я совмещал задачи из первых шести семейств, делая новые, более сложные задачи с большей композиционной глубиной. Например, решение одной из задач в compositional семействе было sum(abs(b) for b in xs), sorted(xs)[::-1]), то есть совмещение семейств list_transform, list_scan и arithmetic_scalar.
Кроме того, для каждого семейства я руками придумал по 15 темплейтов. Темплейт это тройка "инструкция", "код" и "оракул" вида:
canonical_instruction: "given two integers a and b, return the absolute value of {{ c1 }} times {{ v1.d }} {{ op.d }} {{ c2 }} times {{ v2.d }}"
code: |
def f(a, b):
return abs({{ c1 }} * {{ v1.v }} {{ op.v }} {{ c2 }} * {{ v2.v }})
oracle: "abs({{ c1 }} * {{ v1.v }} {{ op.v }} {{ c2 }} * {{ v2.v }})"
Про крохотные кодовые модели
*этот длиннопост я пишу уже третий месяц — наконец то дошли руки его закончить и выложить*
Как я уже писал, I have a soft spot for broken and puny things. Не так давно мне попалась на глаза новость, где кто-то обучил ллм для Z80 — такого восьмибитного процессора из середины 80-х. Для того, чтобы полноценный трансформер уместился и работал в ограничениях памяти процессора, который лишь на десять лет младше моих родителей, авторам пришлось применить много интересных технических решений: QAT в 2 битах, инференс в int16 (потому что другой математики в процессоре добиться сложно) и, что самое прикольное, ограничение размера токенизатора.
В современных трансформерах словари огромны. В e5-base, например, токенизатор содержит 30522 токенов, в multilingual-e5-small взят словарь от xlmr, так что там 250037 токенов и так далее. Это означает две вещи: во первых, если у модели в токенизаторе много токенов, то ей будет надо больше данных, чтобы все эти токены увидеть в разных контекстах и собрать статистики. Во-вторых, большой токенизатор означает большую LM Head и большой эмбеддинг слой. И как бы пофиг на это, это же просто lookup table, но хоть e5-small от multilingual-e5-small архитектурно отличаются лишь токенизатором*, число параметров там 33M против 117M.
Поэтому авторы Z80-μLM сделали токенизатор character based и рекомендовали структурировать датасет как одно слово. Например:
> hello
HI
> are you real
MAYBE
Скорость префилла, генерации и использующаяся память на разных контекстах.
Читать полностью…
Как же я люблю этот промпт. Ответ от LongCat-Flash, которую мне понадобилось развернуть по работе:
Конечно! Столовые приборы — это инструменты, используемые для еды. Они бывают разных типов в зависимости от назначения и формы. Вот основные виды столовых приборов:
1. Ножи
- Стаканный нож – длинный, острый, предназначен для разделки мяса.
- Хлебный нож – широкий, с режущей кромкой и зубцами по краю, чтобы не порезать хлеб.
- Разделочный нож – универсальный, среднего размера, подходит для обычных блюд.
- Нож для рыбы/птицы – тонкий, гибкий, чтобы легко производить проколы и разделку.
2. Вилки
- Едалища (единственная) – вилка с одной лезвием, чаще всего используется в России и странах СНГ.
- Тёрки (множественные) – вилка с двумя или более лезвиями, распространена в Европе и Америке.
- Вилка для салата – с тонкими, длинными лезвиями, удобна для перемешивания.
- Вилка для рыбы – с тонким, гибким лезвием, позволяет аккуратно отделить кости от мяса.
3. Ложки
- Суповая ложка – крупная, глубокая, с толстым ручком, подходит для жидких блюд.
- Чайная ложка – мелкая, тонкая, часто используется для чая, сахара, молока.
- Ложка для десерта – средний размер, может быть с гладкой или зубчатой кромкой.
- Сырная ложка – широкая, плоская, с толстым ручком, удобна для нарезки сыра.
- Молочная ложка – мелкая, с круглой или вытянутой лопаткой, часто декоративная.
4. Другие приборы
- Шпатель – тонкий нож или вилка, используется для аккуратного перемешивания или отделения теста.
- Пинцет для еды – металлический прибор с двумя щипцами, удобен для подачи маленьких закусок или десертов.
- Столовые приборы для баров – шейкер, миксер, пинцет для орехов и т.д.
Выбор столовых приборов зависит от культуры, привычек и того, какое блюдо готовится. Например, во Франции и Италии часто используют вилки с тройными лезвиями, а в России — единичные.
А чем вайбкодить?
Вышла GPT-5.6 и появился вопрос — кому мне платить 100 баксов в следующем месяце: Anthropic или OpenAI? Я их меняю и просто пользуюсь лучшим вариантом из двух, но как UI мне Codex нравится значительно больше. Да и в целом, интересно было бы проверить как работают новые модели от OpenAI.
Чтобы ответить на этот вопрос, я взял ту самую задачу из поста про локальные модели и запустил генерацию через Haiku 4.5, Sonnet 5, Opus 4.8, Fable 5 (харнесс — Claude Code, везде reasoning effort high) и GPT-5.6 Sol/Terra/Luna (харнесс — codex, сетка эффорта от low до max). Потом отправил Codex делать ревью имплементаций в надежде получить красивые графики качества/времени выполнения задачи/числа токенов и понять, что является парето-оптимальным. Дополнительно я закинул несколько опенсорсных моделей, которые клеймят, что они близки к сота моделям — GLM-5.2, Kimi-K2.7-Code, MiniMax-M3, DeepSeek V4 Flash/Pro внутри opencode — чтобы посмотреть, насколько эти клеймы подтвердятся на практике.
Результаты:
1. GPT-5.6 Terra как будто бы не находится на парето фронтире.. Luna дешевле почти в три раза, но почти такая же по качеству на тех reasoning effort, где есть смысл их использовать, а Sol справился лучше.
Sol high = Luna xhigh по скору и по времени выполнения
Клод ни в одном из четырёх случаев не лучше и не быстрее 5.6 — конкретно для кода он хуже предложений OpenAI
“Дешёвые” предложения OpenAI не хуже “дорогих” и вполне себе good enough
Единственная конкурентоспособная опенсорсная модель — GLM-5.2, но по времени ответа она на уровне GPT-5.6 Sol max, будучи в четыре (!) раза дороже сопоставимой по качеству GPT-5.6-Luna.
Иногда higher reasoning effort помогал модели составить более эффективный план и решить задачу даже быстрее и за меньшее число токенов. Семь раз померь, один раз отрежь.
Это ни в коем случае не scientific eval — я делал один прогон ревью одного решения одной задачи через субагентов кодекса без зафиксированной модели-судьи и не гонял внешних тестов, статзначимости я бы от этого теста не ожидал. Но при этом, получившиеся графики хорошо коррелируют с моими ощущениями от качества работы моделей: GLM-5.2 действительно не опус, а GPT-5.6 мне нравится больше клода.
Значит ли это, что надо пересаживаться на Luna? Нет. Модель хорошо будет работать на run задачах (что-то запустить, что-то простое пофиксить, скилл отработать, конфиги написать), коих большинство, но если надо писать что-то с нуля, я всё равно буду пользоваться Sol high. Да и для не кодинговых задач результаты могут отличаться. Но тем не менее, сравнение, имхо, интересное.
ICML 2026
Волею судеб я оказался на ICML 2026 в сеуле (если вы тоже — приходите на тусу Яндекса или Сбера пообщаться) и я имею сказать: уровень статей тут почему-то очень низкий.
На AI Evaluation Oral Session было четыре доклада, половина из которых была ни о чём:
Position paper (зачем вообще существует этот класс работ?) о том, что в будущем модели бенчами закрываться не будут, потому что это будет незамеряемо (debatable);
Бенчмарк про causal thinking, в котором все модели выбивают 70+-2% GPT-5-Mini скорится выше, чем GPT-5.2 xhigh, рандомная модель выбивает 65%, добавление opencode даёт +25% к скорам;
Статья про то, что надо эвалить ризонинг трейсы (хорошая, мне понравилась);
Статья про поиск “плохих” комплишенов модели через теорвер (тоже неплохая).
На постерах я видел как минимум два постера, где авторы в очередной раз переизобрели p-tuning. Ещё была довольно слабая работа про байесы в LLM-судьях, где они подтвердили, что существует position bias, length bias и self enhancement bias (не то чтобы файндинг). К чести авторов, я им показал свои экспы с судьями и их (не)устойчивостью к языковым и некоторым другим байесам (папира на ревью, обязательно про нее напишу потом), они сказали что офигенно и предложили совместную статью сделать.
Еще был постер со статьей про способ подсвечивать лик бенча в модель. Автор сказал оч всратую, на мой взгляд, идею — а давайте в бенч неправильные ответы вмешаем и тогда если скор выше чем число ошибок то тест пролит в трейн. На вопрос «а как это переделать под не mcq эвалы а, положим, тау или свебенч» он не нашелся что ответить.
Хорошие статьи есть, но как будто бы плохие статьи превалируют над хорошими и приходится выискивать действительно интересный и качественный ресёрч — я не этого ожидал от мейн трека A* конфы.
Зато было много крутых чуваков из индустрии. Мне очень понравилось общаться с лидом рл из MAI — он рассказал, что они почти не делают сфт, чисто дистиллируют внутренних доменных экспертов в базовую модель и потом делают онлайн рл. Чувак из Apple очень интересно рассказал как у них работают эвалы — и что они модели тестят по качеству не только на теслах, но и на финальном железе с измеримым диффом в качестве. Гугловские сказали, что на general домене у них была ооооочень большая корреляция между качеством перевода и умением в open ended generation. Опенаи рассказали что скоро будет новый опенсорс (!!!) и дали мне кепочку и носочки с логотипом. Толокеры очень душевно рассказали про их реварды и то, как они варят данные, классные ребята, очень приятные. Пересёкся с челом из Яндекса, который работает на аналогичной мне должности — вечером на афтерпати Яши надеюсь с ним ещё раз пообщаться, он интересное рассказал.
Прикольно, что почти все фронтир и субфронтир лабы — MAI, OpenAI, Google, Meta, Apple — используют файнтюны собственных моделей под судей, а не чужие модели с подобранным промптом/тюном. Это интересно, я поспрашивал, говорят, что self enhancement bias не мешает.
Получается, что индустрийная часть мне зашла больше, чем научная. Почему? Мне кажется, что это из-за хака KPI по публикациям.
Государства вкладываются в ресёрч, ресёрчеров много, у них publish-or-perish. Поэтому любой эксперимент — удачный, неудачный — оформляется клодиком в статью и засылается на конфу. Ревьюеры перегружены, люди кидают статьи в клодик, клодик выдаёт weak accept, статья проходит на конференцию, готово, слоп на постерах. Проблема на самом деле старая, LLM-бум её только масштабировал.
А индустрии на эти KPI пофиг. Они в любом случае заплатят за место в sponsored zone, уставшие от статей студенты (например, я) придут к ним за мерчом и оставят свои резюме и реальные лиды реальных команд расскажут про внутрянку — и это офигенно.
И эту проблему не решить через ллм ревью, потому что джаджи точно так же хакаются и результат будет таким же. Можно наверное было бы ограничивать число сабмитов от одного автора (заодно научники не смогут вписываться в работы последними авторами без участия в них), но тогда действительно крутых ресёрчеров, которые реально контрибутили в несколько статей сразу огорчат и дропнут из соавторов. В своём прайме я послал две статьи на NAACL, а прямо перед увольнением из AIRI я был соавтором в трёх статьях, в каждой из которых я делал сильно ненулевое количество работы (вполне подходящее под место авторства).
Короче грустно это всё, желаю крепких нервов всем, кто остаётся в академии. Я вот ушёл и очень доволен.