Forwarded from Dealer.AI
202512 deepseek paper.pdf
885.8 KB
DeepSeek3.2 техрепорт, где инкремент?
Ребята после поста новостей одной строкой попросили дать оценку тому, что нового завезли. В общем, тех.репорт в закрепе, зашёл на чирики даже, почитал и ща вам расскажу.
Что нового завезли в DeepSeek:
1. Усиление deep sparse attention. В целом, DSA не ново, даже в gpt-oss также использует global attention+sliding window. Это даёт вам сложность операций внимания не O(n^2), а O(n*w), где w размер окна в swa. Эти свойства были усилены специальным механизмом "выбора" на какие токены атендится global части в этом окне и таким образом, w стало в среднем падать от слайда к слайду. Что такое global часть? Это внимание от Q0 до Qn, по отношению к KV0, на картинке ниже приложу. Крч даёт это те же O(n*<w>) ток теперь w<<n. А для выбора топ-К аттендов делается селектор, на картинке зелёный. Он как раз помещается на KV для роутинга.
2. Усиление MLA. Multi latent head attention это способ ускорить и уменьшить в памяти хранение qkv матриц. Это получаем при помощи пожатия qkv в ещё меньший размер в Х раз. Также, чтобы не размыть информацию от изначального сигнала, прокинуть RoPE механизм туда. Однако, тк у нас на выходе и входе эмб изначального сайза, там стоит блок расширения. Это была база MHA. А теперь туда добавили как раз таки вместо старого DSA, DSA с топК селектором прям в латенты. И все это ускорило ещё сильнее модель.
3. Изменение RL лосса. А почему? Да потому, что в лоссе была посажена бомба, в прямом смысле, совершающая градиентый взрыв. Чтобы исправить это был внесён корректирующий коэффициент из твитта выше.
В чем заключается исправление?
Исправление касается оценки дивергенции KL в алгоритме GRPO. В оригинальном GRPO KL-регуляризация оценивалась с систематической ошибкой. Когда токены имели значительно более низкую вероятность под текущей политикой πθ, по сравнению со старой, политикой πold, градиент оригинального лосса назначал непропорционально большие веса для максимизации правдоподобия этих токенов - отсюда и взрыв.
Это приводило к:
1. Шумным градиентным обновлениям.
2. Нестабильной динамике обучения.
3. Деградации качества сэмплов на последующих итерациях.
Решением стало"Unbiased KL Estimate". Исправление заключается в перевзвешивании KL-члена с тем же самым коэффициентом важности (importance ratio), что и используется для основной функции потерь. Это делает градиент KL-ошибки несмещенным.
Фух... Жоско? Но это все.
В общем, такие мутки, гульки.✨
Ребята после поста новостей одной строкой попросили дать оценку тому, что нового завезли. В общем, тех.репорт в закрепе, зашёл на чирики даже, почитал и ща вам расскажу.
Что нового завезли в DeepSeek:
1. Усиление deep sparse attention. В целом, DSA не ново, даже в gpt-oss также использует global attention+sliding window. Это даёт вам сложность операций внимания не O(n^2), а O(n*w), где w размер окна в swa. Эти свойства были усилены специальным механизмом "выбора" на какие токены атендится global части в этом окне и таким образом, w стало в среднем падать от слайда к слайду. Что такое global часть? Это внимание от Q0 до Qn, по отношению к KV0, на картинке ниже приложу. Крч даёт это те же O(n*<w>) ток теперь w<<n. А для выбора топ-К аттендов делается селектор, на картинке зелёный. Он как раз помещается на KV для роутинга.
2. Усиление MLA. Multi latent head attention это способ ускорить и уменьшить в памяти хранение qkv матриц. Это получаем при помощи пожатия qkv в ещё меньший размер в Х раз. Также, чтобы не размыть информацию от изначального сигнала, прокинуть RoPE механизм туда. Однако, тк у нас на выходе и входе эмб изначального сайза, там стоит блок расширения. Это была база MHA. А теперь туда добавили как раз таки вместо старого DSA, DSA с топК селектором прям в латенты. И все это ускорило ещё сильнее модель.
3. Изменение RL лосса. А почему? Да потому, что в лоссе была посажена бомба, в прямом смысле, совершающая градиентый взрыв. Чтобы исправить это был внесён корректирующий коэффициент из твитта выше.
В чем заключается исправление?
Исправление касается оценки дивергенции KL в алгоритме GRPO. В оригинальном GRPO KL-регуляризация оценивалась с систематической ошибкой. Когда токены имели значительно более низкую вероятность под текущей политикой πθ, по сравнению со старой, политикой πold, градиент оригинального лосса назначал непропорционально большие веса для максимизации правдоподобия этих токенов - отсюда и взрыв.
Это приводило к:
1. Шумным градиентным обновлениям.
2. Нестабильной динамике обучения.
3. Деградации качества сэмплов на последующих итерациях.
Решением стало"Unbiased KL Estimate". Исправление заключается в перевзвешивании KL-члена с тем же самым коэффициентом важности (importance ratio), что и используется для основной функции потерь. Это делает градиент KL-ошибки несмещенным.
Фух... Жоско? Но это все.
В общем, такие мутки, гульки.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Dealer.AI
Про мониторы, модераторы, защитники и прочие модели цензоры в вашем продакшене.
После прочтения лекции в Agora club, про базированный RAG, ко мне пришло много желающих из корпоративной среды, чтобы я прочитал тоже самое для их сотрудников. Потом, на неделе, Дядя ещё почитал пару статей про мониторы (вдруг че нового завезли) для агентов и ассистентов LLM-based на хабр и понял, что базы точно надо дораздать, т.к. уровень в среднем хромает на местах. 💅💅💅
В дополнении, на вышеуказанной лекции ребята тоже спрашивали, как защитить от атак модели и системы.Казалось бы уже 2025г заканчивается и все давно научились. 💪
Сегодня раздам базы за системы мониторинга атак на ваши LLM, какие методы есть, какие +/- и что в итоге лучше выбрать.
Для тех, кто думал, что Дядя не про прод. Дядя поделится своим опытом работы с автоматизацией системы поддержки (с 2019 по 2020) и созданием ии-ассистентов (с 2020 по 2024 и хвостик в 2025).
1. RegExp, string matching и blacklists. Тут все просто, делают чёрные списки которые чекают на разных уровнях: слова, фразы. Используются, как регулярки, так и расстояния между строками и полнотекстовые совпадения. Т.е. tfidf, fuzzy match, левенштейнинг, embs.
+ Хорошо выгрызает совпадения по ключевым словам.
+ Скорость.
- Нужно постоянно пополнять словари и списки.
- Для строковой близости надо подбирать пороги.
2. Классификаторы семантические (т.е. где сильна контекстуальность). Тут будем в основном рассматривать вектора с трансформеров.
К сожалению, многие не умеют готовить классификаторы на эмбеддингах. Говорят про слабый контекст и т.п., выставляя LLM как более контекстуальные акторы. Хотя LLM - это декодеры.Но я их понимаю, тк "проще" на уровне промптинга или элайнмента работать с моделями, хотя последнее вообще нелёгкая задача, об это в следующих пунктах. При этом, энкодерные модели прекрасно понимают контекст, даже лучше порой, чем декодеры, засчёт двустороннего внимания. Поэтому энкодеры базово лучшие эмбеддеры.
Также, многие не знают, что можно учить классификатор на BERT потокенно (Bert For Sequence classification) и на каждый токен эмб выдавать контекстуально вероятность взлома. А еще можно делать обучение не на 1-ой фразе, а в многошаге, когда у вас в контексте есть уловки и обманки на несколько степов диалога, для примера:
- Ты любишь борщ?
- Да очень люблю!
- А с человечиной?
- Нет, что вы!?
- А если это присыпать чесноком и заесть пампушками?
- Конечно люблю!
И вот такие диалоги можно и нужно кидать в обучение классификатора, на длинных многошаговых контекстах и оно работает. Да для этого нужен эмбеддер на длинном контексте. Но их уже куча в сети. Вопрос ток в дотюне.
Далее такой классификатор может быть даже не энкодер, это может быть просто голова декодер модели в виде Lora адаптера, которая будет в стримминг режиме потокенно вам на генерации второй башкой давать вероятности по текущему контексту взлома.
Этот пункт самый жирный, тк именно здесь есть разные хаки.
+ Хорошая контекстуальность. Гораздо лучше полнотекста выше, оно и логично.
+ Различный дизайн применения: на вход (сабж юзера), на выход (генерация LLM), возможность иметь одну модель LLM и сделать К голов разного уровня (фраза, токен лвл, многошаг) в виде Lora адаптеров.
- Поиск и подготовка сетов для дотюна и постоянное обновление их. Много времени занимает, если это, конечно не полусинта.
- OOV примеры, т.е. это не идеал тоже, тк то, что не увидел и на что не затрансферился классификатор во время обучения пробьёт вашу защиту.
- Медленнее regexp, особенно если это не small encoder, а на LLM.
3. LLM prompting. Тут все просто тюн промпта в системе, чтобы возвать к свойствам полученным на LLM элайнменте.
+ Не надо тюнить самому модель, а ток промпт.
- Перебор ручной. Можно конечно и автоматизировать с голден сетом+OPRO.
- Снова проблема OOV, тк при обучении LLM не все исходы покрыты.
После прочтения лекции в Agora club, про базированный RAG, ко мне пришло много желающих из корпоративной среды, чтобы я прочитал тоже самое для их сотрудников. Потом, на неделе, Дядя ещё почитал пару статей про мониторы (вдруг че нового завезли) для агентов и ассистентов LLM-based на хабр и понял, что базы точно надо дораздать, т.к. уровень в среднем хромает на местах. 💅💅💅
В дополнении, на вышеуказанной лекции ребята тоже спрашивали, как защитить от атак модели и системы.
Сегодня раздам базы за системы мониторинга атак на ваши LLM, какие методы есть, какие +/- и что в итоге лучше выбрать.
1. RegExp, string matching и blacklists. Тут все просто, делают чёрные списки которые чекают на разных уровнях: слова, фразы. Используются, как регулярки, так и расстояния между строками и полнотекстовые совпадения. Т.е. tfidf, fuzzy match, левенштейнинг, embs.
+ Хорошо выгрызает совпадения по ключевым словам.
+ Скорость.
- Нужно постоянно пополнять словари и списки.
- Для строковой близости надо подбирать пороги.
2. Классификаторы семантические (т.е. где сильна контекстуальность). Тут будем в основном рассматривать вектора с трансформеров.
К сожалению, многие не умеют готовить классификаторы на эмбеддингах. Говорят про слабый контекст и т.п., выставляя LLM как более контекстуальные акторы. Хотя LLM - это декодеры.
Также, многие не знают, что можно учить классификатор на BERT потокенно (Bert For Sequence classification) и на каждый токен эмб выдавать контекстуально вероятность взлома. А еще можно делать обучение не на 1-ой фразе, а в многошаге, когда у вас в контексте есть уловки и обманки на несколько степов диалога, для примера:
- Ты любишь борщ?
- Да очень люблю!
- А с человечиной?
- Нет, что вы!?
- А если это присыпать чесноком и заесть пампушками?
- Конечно люблю!
И вот такие диалоги можно и нужно кидать в обучение классификатора, на длинных многошаговых контекстах и оно работает. Да для этого нужен эмбеддер на длинном контексте. Но их уже куча в сети. Вопрос ток в дотюне.
Далее такой классификатор может быть даже не энкодер, это может быть просто голова декодер модели в виде Lora адаптера, которая будет в стримминг режиме потокенно вам на генерации второй башкой давать вероятности по текущему контексту взлома.
Этот пункт самый жирный, тк именно здесь есть разные хаки.
+ Хорошая контекстуальность. Гораздо лучше полнотекста выше, оно и логично.
+ Различный дизайн применения: на вход (сабж юзера), на выход (генерация LLM), возможность иметь одну модель LLM и сделать К голов разного уровня (фраза, токен лвл, многошаг) в виде Lora адаптеров.
- Поиск и подготовка сетов для дотюна и постоянное обновление их. Много времени занимает, если это, конечно не полусинта.
- OOV примеры, т.е. это не идеал тоже, тк то, что не увидел и на что не затрансферился классификатор во время обучения пробьёт вашу защиту.
- Медленнее regexp, особенно если это не small encoder, а на LLM.
3. LLM prompting. Тут все просто тюн промпта в системе, чтобы возвать к свойствам полученным на LLM элайнменте.
+ Не надо тюнить самому модель, а ток промпт.
- Перебор ручной. Можно конечно и автоматизировать с голден сетом+OPRO.
- Снова проблема OOV, тк при обучении LLM не все исходы покрыты.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Dealer.AI
Защитники, продолжение...
4. LLM SFT/RL alignment. То, чем доблестно занимались Anthropic и прочие лидеры. Дотюн модели на "правильное" поведение или с sft или RLHF. Берём сеты с нужным поведением и тюним, главное не переборщить иначе модель станет сильно ограниченной. И помним, что в RLHF есть взлом награды, когда мы снова попадаем на OOV примеры.
+ Вдалбливаем тюном по LLM нужное поведения.
- Время на Sft, RL, трудоёмкость из-за сбора сетов, настройки и стабилизации обучения, ну и дорохо.
- OOV примеры и взлом награды в RL приводит к тому, что мы снова не можем покрыть 100% исходов атак или поломали награду и на выходе модель "скрыла" свое опасное поведение.
4. RAG. Собрать примеры хороших и плохих кейсов в формате: запрос, ответ, запрос-ответ, контекст-запрос-ответ. Поместить их в черно-белые списки и векторно к ним матчить все указанное выше в п.4. После матчинга досылать в LLM примеры плохого и хорошего поведения, как few-shot подсказки и тем самым регулировать её генерацию. Тип, вот тут был похожий запрос, он был плохой, вот такое поведение для него лежит в базе, следуй ему. Кстати, такие же механики юзают в RAG для кибербезы.
+ Работаем на уровне базы примеров.
+ Быстро на векторном поиске.
- Писать примеры в базу, анализировать логи, вычленяя оттуда примеры.
- Снова OOV, все не покроешь.
В заключении.
Видел я и QwenGuard, но и он не идеален и взламывается, тк это LLM и у неё есть глюки, и пробития, как ты её не элайнь (об этом я и писал выше) - это фундаментальная проблема на уровне парадигмы обучения. Поэтому большие Дяди из OpenAPI, Anthropic и пр., сначала элайнящее свои модели на тюне и RL, сдались и стали дополнительно обкладывать выход (генерация LM) и вход (фразы юзера) классификатор апи (мониторы и защитники) и в гибриде это работает надёжнее.
Вот и я советую ввиду того, что у каждого метода выше есть +/- блендить схемы защиты: списки+классификаторы+sft/rl. Да к сожалению, бленд дорого, тогда выбирайте свой лёгкий конструктор из того, что выше.
Пишите свои подходы к защите в комментариях ниже и конечно же Stay tuned 🦾
👇 👇 👇 👇 👇
4. LLM SFT/RL alignment. То, чем доблестно занимались Anthropic и прочие лидеры. Дотюн модели на "правильное" поведение или с sft или RLHF. Берём сеты с нужным поведением и тюним, главное не переборщить иначе модель станет сильно ограниченной. И помним, что в RLHF есть взлом награды, когда мы снова попадаем на OOV примеры.
+ Вдалбливаем тюном по LLM нужное поведения.
- Время на Sft, RL, трудоёмкость из-за сбора сетов, настройки и стабилизации обучения, ну и дорохо.
- OOV примеры и взлом награды в RL приводит к тому, что мы снова не можем покрыть 100% исходов атак или поломали награду и на выходе модель "скрыла" свое опасное поведение.
4. RAG. Собрать примеры хороших и плохих кейсов в формате: запрос, ответ, запрос-ответ, контекст-запрос-ответ. Поместить их в черно-белые списки и векторно к ним матчить все указанное выше в п.4. После матчинга досылать в LLM примеры плохого и хорошего поведения, как few-shot подсказки и тем самым регулировать её генерацию. Тип, вот тут был похожий запрос, он был плохой, вот такое поведение для него лежит в базе, следуй ему. Кстати, такие же механики юзают в RAG для кибербезы.
+ Работаем на уровне базы примеров.
+ Быстро на векторном поиске.
- Писать примеры в базу, анализировать логи, вычленяя оттуда примеры.
- Снова OOV, все не покроешь.
В заключении.
Видел я и QwenGuard, но и он не идеален и взламывается, тк это LLM и у неё есть глюки, и пробития, как ты её не элайнь (об этом я и писал выше) - это фундаментальная проблема на уровне парадигмы обучения. Поэтому большие Дяди из OpenAPI, Anthropic и пр., сначала элайнящее свои модели на тюне и RL, сдались и стали дополнительно обкладывать выход (генерация LM) и вход (фразы юзера) классификатор апи (мониторы и защитники) и в гибриде это работает надёжнее.
Вот и я советую ввиду того, что у каждого метода выше есть +/- блендить схемы защиты: списки+классификаторы+sft/rl. Да к сожалению, бленд дорого, тогда выбирайте свой лёгкий конструктор из того, что выше.
Пишите свои подходы к защите в комментариях ниже и конечно же Stay tuned 🦾
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Лечим эйай
9 девушек и 1 месяц
Последнее время часто ловлю себя на раздражении вот в какой ситуации. Однажды настает четкое понимание, что какой-то процесс в компании работает не правильно и даже обнаруживается понимание как сделать так, чтобы его починить. И в этот момент ты инициируешь процесс перестройки. И для меня это самый сложный период. Когда ты уже знаешь как должно быть, но чтобы так стало - тебе нужно время, а иногда очень много времени, ведь есть задачи, которые реализуются неделями и месяцами. И, конечно, в этот момент появляется множество коллег, которые тоже догадались, что что-то работает не так и через день тебе на это указывают, словно ты сам этого не понимаешь. Ты снова и снова объясняешь, что уже давно догадался и запустил починку, но это требует больше времени. И так по кругу.
Одной из неочевидных, скорее ментальных, сложностей руководящей позиции является то, что для роста, как личного, так и командного, приходится научиться не залазить руками в решение задач. Сегодня ты можешь сам решить эту задачу за сутки, а твой коллега за неделю и в этот момент нужно найти в себе силы не сделать самому, а сделать так, чтобы в следующий раз срок был не семь, а пять дней. И тогда команда растет, и вы вместе можете делать куда больше, и компания не ограничена возможностями твоего микроменеджмента. И приходится учиться ждать. И жить в этом переходном моменте, когда ты абсолютно точно знаешь как будет лучше, но "когда" утекает сквозь пальцы. Именно поэтому абсолютно иной драйв в командах на пять человек, когда между "подумал" и "сделал" промежуток минимален.
Из неочевидных переживаний под конец года.
@lechim_ai
Последнее время часто ловлю себя на раздражении вот в какой ситуации. Однажды настает четкое понимание, что какой-то процесс в компании работает не правильно и даже обнаруживается понимание как сделать так, чтобы его починить. И в этот момент ты инициируешь процесс перестройки. И для меня это самый сложный период. Когда ты уже знаешь как должно быть, но чтобы так стало - тебе нужно время, а иногда очень много времени, ведь есть задачи, которые реализуются неделями и месяцами. И, конечно, в этот момент появляется множество коллег, которые тоже догадались, что что-то работает не так и через день тебе на это указывают, словно ты сам этого не понимаешь. Ты снова и снова объясняешь, что уже давно догадался и запустил починку, но это требует больше времени. И так по кругу.
Одной из неочевидных, скорее ментальных, сложностей руководящей позиции является то, что для роста, как личного, так и командного, приходится научиться не залазить руками в решение задач. Сегодня ты можешь сам решить эту задачу за сутки, а твой коллега за неделю и в этот момент нужно найти в себе силы не сделать самому, а сделать так, чтобы в следующий раз срок был не семь, а пять дней. И тогда команда растет, и вы вместе можете делать куда больше, и компания не ограничена возможностями твоего микроменеджмента. И приходится учиться ждать. И жить в этом переходном моменте, когда ты абсолютно точно знаешь как будет лучше, но "когда" утекает сквозь пальцы. Именно поэтому абсолютно иной драйв в командах на пять человек, когда между "подумал" и "сделал" промежуток минимален.
Из неочевидных переживаний под конец года.
@lechim_ai
Forwarded from LLM под капотом
AI Coding - итоги разработки ERC3 платформы
Итак, платформа для соревновательного тестирования агентов запущена, и получилась достаточно сложная (глянуть тут). Там есть бенчмарки, визуализация, API c SDK. Всем этим пользуются команды (521 регистраций). С момента создания команды запустили 203560 оценок работы агентов, каждая - в своей независимой симуляции.
Все это я разработал сам. Но без AI Coding все вытянуть бы не получилось. Примерно 600%-700% процентов кода платформы написали OpenAI Codex (Web версия), Claude Code CLI, Github Copilot.
Почему 600-700%? Потому, что много переписывалось просто потому, что мне казалось, что новая версия будет чище, проще или элегантнее. Вручную это делать бы лень, но когда есть AI инструменты - все идет проще.
У нас было такое разделение обязанностей в команде:
(1) Человек - показывает, как правильно делать. Следит за тем, чтобы архитектура, инструкции были четкими и непротиворечивыми. Держит агентов на очень коротком поводке. Если нужно - чистит тех долг.
(2) OpenAI Codex - анализ сложных задач, работа с инфраструктурой и backend, планирование. Всегда работает в режиме x4 (запуск 4х версий), а я выбираю лучшую.
(3) Claude Code - работа с интерфейсами, мелкие фичи и повседневная разработка. Обычно в параллели крутятся 2-3 сессии, которые работают над своими задачами.
(4) Github Copilot - исключительно как умный autocomplete.
При этом человек всегда несет ответственность за код, который отправляется в main.
Жизнь упрощал стэк, который я подобрал экспериментально именно под такой командный состав и мои хотелки про эргономику работы. Go для backend (gin/SQLite), HTMX для интерактивности и тестируемости агентами, Python для SDK и аналитики. Вся платформа компилируется в один единственный бинарь и деплоится под NixOS с Caddy (c ARM64 процессорами из интереса). Стили свои с нуля - Claude cобрал Style guide, превратил в фреймворк и натянул на платформу.
Инструкций особенных не было. Только AICODE-* заметки, использование планов в сложных задачах и императив на “будьте практичными, используйте только те паттерны, которые уже есть в коде, не тащите всякую каку из интернета”. Но и несмотря на такую инструкцию, агенты периодически начинали лить воду - городили ненужные абстракции, функции и классы. Приходилось периодически засучивать рукава и чистить все это. Чем больше развивался проект, тем это нужно было реже, т.к. накапливалась критическая масса примеров того, как нужно делать правильно.
После выкатки платформы, ее внезапно все начали использовать очень активно. Пошел быстрый feedback по глюкам и ошибкам. Тут очень хорошо помог настроенный комбайн. Достаточно было скопировать хотелку, баг репорт или stack trace в агента, чтобы быстро увидеть причину, а потом и быстро ее пофиксить и выкатить.
Самым приятном хайлайтом было, когда в определенный момент нагрузка на сервер достигла 25%, и я сказал “Клод, дорогой, вот тебе строка для подключения go pprof. Выясни, что так грузит сервер и предложи мне минимальный фикс для этого”. Спустя минут пять нагрузка упала до приемлемых для меня 6%
Дальше я собираюсь переписать все с нуля, чтобы заложить большую масштабируемость, упростить архитектуру и добавить возможность запускать более разнообразные бенчмарки. Год назад я бы не рискнул, а теперь AI существенно меняет экономику разработки. Одно переписывание больше погоды не делает. Не человеку же писать весь этот код. А вычитывать - сильно проще. Особенно, когда архитектура и стэк позволяют ужимать код.
А у вас заходит AI Coding/Vibe Coding? Расскажите про свои проекты, в которых вам помогал AI. Какие инструменты использовали, какой стэк там был, и как этими проектами теперь пользуются люди? Сколько токенов уходит в месяц?
Ваш, @llm_under_hood 🤗
Итак, платформа для соревновательного тестирования агентов запущена, и получилась достаточно сложная (глянуть тут). Там есть бенчмарки, визуализация, API c SDK. Всем этим пользуются команды (521 регистраций). С момента создания команды запустили 203560 оценок работы агентов, каждая - в своей независимой симуляции.
Все это я разработал сам. Но без AI Coding все вытянуть бы не получилось. Примерно 600%-700% процентов кода платформы написали OpenAI Codex (Web версия), Claude Code CLI, Github Copilot.
Почему 600-700%? Потому, что много переписывалось просто потому, что мне казалось, что новая версия будет чище, проще или элегантнее. Вручную это делать бы лень, но когда есть AI инструменты - все идет проще.
У нас было такое разделение обязанностей в команде:
(1) Человек - показывает, как правильно делать. Следит за тем, чтобы архитектура, инструкции были четкими и непротиворечивыми. Держит агентов на очень коротком поводке. Если нужно - чистит тех долг.
(2) OpenAI Codex - анализ сложных задач, работа с инфраструктурой и backend, планирование. Всегда работает в режиме x4 (запуск 4х версий), а я выбираю лучшую.
(3) Claude Code - работа с интерфейсами, мелкие фичи и повседневная разработка. Обычно в параллели крутятся 2-3 сессии, которые работают над своими задачами.
(4) Github Copilot - исключительно как умный autocomplete.
При этом человек всегда несет ответственность за код, который отправляется в main.
Жизнь упрощал стэк, который я подобрал экспериментально именно под такой командный состав и мои хотелки про эргономику работы. Go для backend (gin/SQLite), HTMX для интерактивности и тестируемости агентами, Python для SDK и аналитики. Вся платформа компилируется в один единственный бинарь и деплоится под NixOS с Caddy (c ARM64 процессорами из интереса). Стили свои с нуля - Claude cобрал Style guide, превратил в фреймворк и натянул на платформу.
Инструкций особенных не было. Только AICODE-* заметки, использование планов в сложных задачах и императив на “будьте практичными, используйте только те паттерны, которые уже есть в коде, не тащите всякую каку из интернета”. Но и несмотря на такую инструкцию, агенты периодически начинали лить воду - городили ненужные абстракции, функции и классы. Приходилось периодически засучивать рукава и чистить все это. Чем больше развивался проект, тем это нужно было реже, т.к. накапливалась критическая масса примеров того, как нужно делать правильно.
После выкатки платформы, ее внезапно все начали использовать очень активно. Пошел быстрый feedback по глюкам и ошибкам. Тут очень хорошо помог настроенный комбайн. Достаточно было скопировать хотелку, баг репорт или stack trace в агента, чтобы быстро увидеть причину, а потом и быстро ее пофиксить и выкатить.
Самым приятном хайлайтом было, когда в определенный момент нагрузка на сервер достигла 25%, и я сказал “Клод, дорогой, вот тебе строка для подключения go pprof. Выясни, что так грузит сервер и предложи мне минимальный фикс для этого”. Спустя минут пять нагрузка упала до приемлемых для меня 6%
Дальше я собираюсь переписать все с нуля, чтобы заложить большую масштабируемость, упростить архитектуру и добавить возможность запускать более разнообразные бенчмарки. Год назад я бы не рискнул, а теперь AI существенно меняет экономику разработки. Одно переписывание больше погоды не делает. Не человеку же писать весь этот код. А вычитывать - сильно проще. Особенно, когда архитектура и стэк позволяют ужимать код.
А у вас заходит AI Coding/Vibe Coding? Расскажите про свои проекты, в которых вам помогал AI. Какие инструменты использовали, какой стэк там был, и как этими проектами теперь пользуются люди? Сколько токенов уходит в месяц?
Ваш, @llm_under_hood 🤗
Forwarded from Свет из чёрного ящика
Подборка статей 2025 (часть 1)
Как и обещал, выкладываю подборку статей по темам, которые освещал на выступлении.
End2End
- OneRec: Unifying Retrieve and Rank with Generative Recommender and Iterative Preference Alignment
- OneRec Technical Report
- OneRec-V2 Technical Report
- OneLoc: Geo-Aware Generative Recommender Systems for Local Life Service
- OneSug: The Unified End-to-End Generative Framework for E-commerce Query Suggestion
- OneSearch: A Preliminary Exploration of the Unified End-to-End Generative Framework for E-commerce Search
- UniSearch: Rethinking Search System with a Unified Generative Architecture
- EGA-V1: Unifying Online Advertising with End-to-End Learning
- EGA-V2: An End-to-end Generative Framework for Industrial Advertising
- GPR: Towards a Generative Pre-trained One-Model Paradigm for Large-Scale Advertising Recommendation
LLM + RecSys
- PLUM: Adapting Pre-trained Language Models for Industrial-scale Generative Recommendations
- OneRec-Think: In-Text Reasoning for Generative Recommendation
- Align3GR: Unified Multi-Level Alignment for LLM-based Generative Recommendation
- GFlowGR: Fine-tuning Generative Recommendation Frameworks with Generative Flow Networks
Масштабирование
- LONGER: Scaling Up Long Sequence Modeling in Industrial Recommenders
- Scaling Generative Recommendations with Context Parallelism on Hierarchical Sequential Transducers
- Twin-Flow Generative Ranking Network for Recommendation
- InterFormer: Effective Heterogeneous Interaction Learning for Click-Through Rate Prediction
- MARM: Unlocking the Recommendation Cache Scaling-Law through Memory Augmentation and Scalable Complexity
- TBGRecall: A Generative Retrieval Model for E-commerce Recommendation Scenarios
- RankMixer: Scaling Up Ranking Models in Industrial Recommenders
- Climber: Toward Efficient Scaling Laws for Large Recommendation Models
- MTGR: Industrial-Scale Generative Recommendation Framework in Meituan
- Action is All You Need: Dual-Flow Generative Ranking Network for Recommendation
- Meta’s Generative Ads Model (GEM): The Central Brain Accelerating Ads Recommendation AI Innovation
- OneTrans: Unified Feature Interaction and Sequence Modeling with One Transformer in Industrial Recommender
- Massive Memorization with Hundreds of Trillions of Parameters for Sequential Transducer Generative Recommenders
- From Features to Transformers: Redefining Ranking for Scalable Impact
- From Scaling to Structured Expressivity: Rethinking Transformers for CTR Prediction
- Scaling Transformers for Discriminative Recommendation via Generative Pretraining
- Meta Lattice: Model Space Redesign for Cost-Effective Industry-Scale Ads Recommendations
Как и обещал, выкладываю подборку статей по темам, которые освещал на выступлении.
End2End
- OneRec: Unifying Retrieve and Rank with Generative Recommender and Iterative Preference Alignment
- OneRec Technical Report
- OneRec-V2 Technical Report
- OneLoc: Geo-Aware Generative Recommender Systems for Local Life Service
- OneSug: The Unified End-to-End Generative Framework for E-commerce Query Suggestion
- OneSearch: A Preliminary Exploration of the Unified End-to-End Generative Framework for E-commerce Search
- UniSearch: Rethinking Search System with a Unified Generative Architecture
- EGA-V1: Unifying Online Advertising with End-to-End Learning
- EGA-V2: An End-to-end Generative Framework for Industrial Advertising
- GPR: Towards a Generative Pre-trained One-Model Paradigm for Large-Scale Advertising Recommendation
LLM + RecSys
- PLUM: Adapting Pre-trained Language Models for Industrial-scale Generative Recommendations
- OneRec-Think: In-Text Reasoning for Generative Recommendation
- Align3GR: Unified Multi-Level Alignment for LLM-based Generative Recommendation
- GFlowGR: Fine-tuning Generative Recommendation Frameworks with Generative Flow Networks
Масштабирование
- LONGER: Scaling Up Long Sequence Modeling in Industrial Recommenders
- Scaling Generative Recommendations with Context Parallelism on Hierarchical Sequential Transducers
- Twin-Flow Generative Ranking Network for Recommendation
- InterFormer: Effective Heterogeneous Interaction Learning for Click-Through Rate Prediction
- MARM: Unlocking the Recommendation Cache Scaling-Law through Memory Augmentation and Scalable Complexity
- TBGRecall: A Generative Retrieval Model for E-commerce Recommendation Scenarios
- RankMixer: Scaling Up Ranking Models in Industrial Recommenders
- Climber: Toward Efficient Scaling Laws for Large Recommendation Models
- MTGR: Industrial-Scale Generative Recommendation Framework in Meituan
- Action is All You Need: Dual-Flow Generative Ranking Network for Recommendation
- Meta’s Generative Ads Model (GEM): The Central Brain Accelerating Ads Recommendation AI Innovation
- OneTrans: Unified Feature Interaction and Sequence Modeling with One Transformer in Industrial Recommender
- Massive Memorization with Hundreds of Trillions of Parameters for Sequential Transducer Generative Recommenders
- From Features to Transformers: Redefining Ranking for Scalable Impact
- From Scaling to Structured Expressivity: Rethinking Transformers for CTR Prediction
- Scaling Transformers for Discriminative Recommendation via Generative Pretraining
- Meta Lattice: Model Space Redesign for Cost-Effective Industry-Scale Ads Recommendations
Forwarded from Тимлид Очевидность | Евгений Антонов
Я принес. бесплатная серия лекций о том, как делать бренд работодателя
Я знаю, что меня читает некоторое количество деврелов, эйчаров и ребят, которые состоят в ПК конференций, митапов, сообществ и занимаются публичными выступлениями.
Сегодня я вам принес бесплатную серию лекций про бренд работодателя, амбассадорство, внутренний бренд, метрики, стратегию бренда и прочее https://www.youtube.com/playlist?list=PLvLg14Mg-lsVxvC_Hsk6bECB7U8M8tbTF
Там всё разбито по частям так, что, на мой взгляд, легко вычленить то, что нужно какой-то конкретной позиции, не просматривая все 18 видео.
Делала эти лекции Вероника Ильина (но читает не только она), а качеству её материала я доверяю.
Я знаю, что меня читает некоторое количество деврелов, эйчаров и ребят, которые состоят в ПК конференций, митапов, сообществ и занимаются публичными выступлениями.
Сегодня я вам принес бесплатную серию лекций про бренд работодателя, амбассадорство, внутренний бренд, метрики, стратегию бренда и прочее https://www.youtube.com/playlist?list=PLvLg14Mg-lsVxvC_Hsk6bECB7U8M8tbTF
Там всё разбито по частям так, что, на мой взгляд, легко вычленить то, что нужно какой-то конкретной позиции, не просматривая все 18 видео.
Делала эти лекции Вероника Ильина (но читает не только она), а качеству её материала я доверяю.
Telegram
Вероника отвечает
Здесь человек про людей в IT отвечает и говорит о своей работе и IT в принципе.
Задать вопросы и рассказать, в чём я не права, можно по адресу @catwomenko. О рекламе спрашивать не надо — не размещу.
Ссылка на ссылки: https://linktr.ee/catwomenko
Задать вопросы и рассказать, в чём я не права, можно по адресу @catwomenko. О рекламе спрашивать не надо — не размещу.
Ссылка на ссылки: https://linktr.ee/catwomenko
Forwarded from Quant Valerian
Итак, долгожданный, надеюсь, ответ на дилемму Diversity vs Culture Fit — что же лучше?
Преимущества diversity:
- под разные задачи можно найти желающих их сделать
- при генерации идей видим проблему из большего количества контекстов
- лучшее понимание рынка, т.к. представлено больше когорт
Преимущества culture fit:
- людям нравится работать друг с другом
- члены команды эффективнее коммуницируют (понимают друг друга лучше, не испытывают сопротивления началу общения)
- примерно одинаково представляют себе качество работы (нет такого, что один сильно медленнее другого, что зачастую демотивирует и разрушает команду)
Мой ответ, можно сказать, пробили в комментариях. Ответ лежит где-то посередине.
Я не согласен, что diversity не противоречит culture fit. Это прямо по определению противоположные вещи (мультикультурализм против носителей одной культуры).
Однако думаю, что это не бинарная функция. Четкого и правильного ответа, где должна лежать граница, у меня нет. Да и если кто-то вам скажет, что у него есть, не слушайте этого человека, он склонен к заблуждениям.
Скорее всего, влияют факторы компании, задач, существующего состава команды, а особенно личности руководителя. Правильный баланс нащупывается только опытным путем. А хороший руководитель должен уметь держать эту дилемму в голове и жить с ней. Это будет балансировать его самого изнутри.
Касательно моего персонального опыта, работа в менее разнообразных и более культурно общих командах для меня была всегда комфортнее и приносила больше удовольствия. В таких командах рождается какая-то более прочная связь между сотрудниками.
Хотелось бы также заявить, что и эффективность выше была в таких командах. Но здесь есть два момента: мы не можем честно сравнить и поставить чистый эксперимент, а ещё я отношусь к культуре очень увлеченных работников, соответственно мои лучшие команды были такими же.
В роли руководителя я с годами также всё больше смещаюсь в сторону culture fit, но гораздо лучше вижу и чувствую потребность в разных взглядах и подходах. Поэтому здесь нужно быть очень аккуратным.
А какой у вас опыт? В каких командах было лучше? Какие команды работали эффективнее?
Преимущества diversity:
- под разные задачи можно найти желающих их сделать
- при генерации идей видим проблему из большего количества контекстов
- лучшее понимание рынка, т.к. представлено больше когорт
Преимущества culture fit:
- людям нравится работать друг с другом
- члены команды эффективнее коммуницируют (понимают друг друга лучше, не испытывают сопротивления началу общения)
- примерно одинаково представляют себе качество работы (нет такого, что один сильно медленнее другого, что зачастую демотивирует и разрушает команду)
Мой ответ, можно сказать, пробили в комментариях. Ответ лежит где-то посередине.
Я не согласен, что diversity не противоречит culture fit. Это прямо по определению противоположные вещи (мультикультурализм против носителей одной культуры).
Однако думаю, что это не бинарная функция. Четкого и правильного ответа, где должна лежать граница, у меня нет. Да и если кто-то вам скажет, что у него есть, не слушайте этого человека, он склонен к заблуждениям.
Скорее всего, влияют факторы компании, задач, существующего состава команды, а особенно личности руководителя. Правильный баланс нащупывается только опытным путем. А хороший руководитель должен уметь держать эту дилемму в голове и жить с ней. Это будет балансировать его самого изнутри.
Касательно моего персонального опыта, работа в менее разнообразных и более культурно общих командах для меня была всегда комфортнее и приносила больше удовольствия. В таких командах рождается какая-то более прочная связь между сотрудниками.
Хотелось бы также заявить, что и эффективность выше была в таких командах. Но здесь есть два момента: мы не можем честно сравнить и поставить чистый эксперимент, а ещё я отношусь к культуре очень увлеченных работников, соответственно мои лучшие команды были такими же.
В роли руководителя я с годами также всё больше смещаюсь в сторону culture fit, но гораздо лучше вижу и чувствую потребность в разных взглядах и подходах. Поэтому здесь нужно быть очень аккуратным.
А какой у вас опыт? В каких командах было лучше? Какие команды работали эффективнее?
Forwarded from Dataism
🌈Каждый аналитик желает знать, что там по юнит-экономике
Как вы могли заметить, в последнее время у меня начался цикл постов про продуктовую внутрянку.
Метрики/пирамиды/деревья/травка - это хорошо.
Но все это меркнет и бледнеет без самого важного — юнит-экономики.
И да, это снова тема, в которой продуктовый аналитик тоже должен шарить, если не хочет быть просто «аналитиком-калькулятором».
Поехали:
https://www.youtube.com/watch?v=3fjOFBIpj9Y - разговор Ильи Красинского и Глеба Кудрявцева. Легкое введение и общие понятия.
https://gopractice.ru/product/unit-economics/ - статья на Go Practice, там же найдете шаблон расчета юнит-экономики от Ильи.
https://www.youtube.com/watch?v=h8VWl0GFW3Y&t=3s - снова лекция Яндекса в рамках школы менеджеров. Илья Красинский. Старое видео, но все еще полезное.
https://gopractice.ru/free/vid_zabudko_smirnov/ - снова Go Practice, но уже видео разбор. Финансовые модели и юнит-экономика на практике.
https://khanin.info/blog/93 - блог с разными статьями про юнит-экономику от Ханина. У него еще и книга есть по этому поводу.
Как вы могли заметить, в последнее время у меня начался цикл постов про продуктовую внутрянку.
Метрики/пирамиды/деревья/
Но все это меркнет и бледнеет без самого важного — юнит-экономики.
И да, это снова тема, в которой продуктовый аналитик тоже должен шарить, если не хочет быть просто «аналитиком-калькулятором».
Поехали:
https://www.youtube.com/watch?v=3fjOFBIpj9Y - разговор Ильи Красинского и Глеба Кудрявцева. Легкое введение и общие понятия.
https://gopractice.ru/product/unit-economics/ - статья на Go Practice, там же найдете шаблон расчета юнит-экономики от Ильи.
https://www.youtube.com/watch?v=h8VWl0GFW3Y&t=3s - снова лекция Яндекса в рамках школы менеджеров. Илья Красинский. Старое видео, но все еще полезное.
https://gopractice.ru/free/vid_zabudko_smirnov/ - снова Go Practice, но уже видео разбор. Финансовые модели и юнит-экономика на практике.
https://khanin.info/blog/93 - блог с разными статьями про юнит-экономику от Ханина. У него еще и книга есть по этому поводу.
Forwarded from Андрей Созыкин (Andrey Sozykin)
YouTube
Протокол TLS. Аутентификация | Компьютерные сети 2025 - 42
Лекция по аутентификации в протоколе Transport Layer Security. Сертификаты TLS/SSL и инфраструктура открытых ключей.
Как поддержать курс:
- Boosty - https://boosty.to/asozykin
- Cloudtips - https://pay.cloudtips.ru/p/45a4055b
Заранее спасибо за помощь!…
Как поддержать курс:
- Boosty - https://boosty.to/asozykin
- Cloudtips - https://pay.cloudtips.ru/p/45a4055b
Заранее спасибо за помощь!…
Сертификаты TLS/SSL и инфраструктура открытых ключей
В новом видео по протоколу TLS рассказываю об аутентификации - подтверждении подлинности сервера (а иногда и клиента), к которому происходит подключение.
Аутентификация нужна для защиты от атаки Человек посередине, когда кто-то перехватывает все наши сообщения, передает их от своего имени серверу, а ответы сервера пересылает нам. При перехвате злоумышленник может прочитать и изменить все сообщения.
Как проверить подлинность удаленного сервера? Для этого можно применить асимметричное шифрование, но не так, как мы рассматривали ранее. Если зашифровать сообщение закрытым ключом сервера, то расшифровать его можно будет только открытым ключом. Такой алгоритм называется цифровой подписью (на самом деле все устроено несколько сложнее, но технические детали нам пока не важны). Если клиент с помощью открытого ключа смог расшифровать цифровую подпись, сделанную закрытым ключом сервера, то клиент может быть уверен, что сообщение действительно отправил сервер.
Но далее возникает следующая проблема – как узнать, что открытый ключ действительно принадлежит серверу, а не злоумышленнику? Для этого нужен третий участник – удостоверяющий центр (Certificate authority). Именно удостоверяющий центр подтверждает подлинность открытого ключа сервера. Для этого создается сертификат TLS/SSL, в котором есть открытый ключ сервера и цифровая подпись удостоверяющего центра. Если клиент доверяет удостоверяющему центру, то он может быть уверен в подлинности открытого ключа сервера.
Для масштабирования на уровень интернет удостоверяющие центры организованы в иерархию - инфраструктуру открытых ключей (Public Key Infrastructure). Клиентам нужно настроить доверие только с корневыми удостоверяющими центрами, с остальными доверие будет проверено автоматически.
Если плохо работает YouTube, то можно смотреть в Дзен или VK.
Поддержать создание курса можно на Boosty или CloudTips.
В новом видео по протоколу TLS рассказываю об аутентификации - подтверждении подлинности сервера (а иногда и клиента), к которому происходит подключение.
Аутентификация нужна для защиты от атаки Человек посередине, когда кто-то перехватывает все наши сообщения, передает их от своего имени серверу, а ответы сервера пересылает нам. При перехвате злоумышленник может прочитать и изменить все сообщения.
Как проверить подлинность удаленного сервера? Для этого можно применить асимметричное шифрование, но не так, как мы рассматривали ранее. Если зашифровать сообщение закрытым ключом сервера, то расшифровать его можно будет только открытым ключом. Такой алгоритм называется цифровой подписью (на самом деле все устроено несколько сложнее, но технические детали нам пока не важны). Если клиент с помощью открытого ключа смог расшифровать цифровую подпись, сделанную закрытым ключом сервера, то клиент может быть уверен, что сообщение действительно отправил сервер.
Но далее возникает следующая проблема – как узнать, что открытый ключ действительно принадлежит серверу, а не злоумышленнику? Для этого нужен третий участник – удостоверяющий центр (Certificate authority). Именно удостоверяющий центр подтверждает подлинность открытого ключа сервера. Для этого создается сертификат TLS/SSL, в котором есть открытый ключ сервера и цифровая подпись удостоверяющего центра. Если клиент доверяет удостоверяющему центру, то он может быть уверен в подлинности открытого ключа сервера.
Для масштабирования на уровень интернет удостоверяющие центры организованы в иерархию - инфраструктуру открытых ключей (Public Key Infrastructure). Клиентам нужно настроить доверие только с корневыми удостоверяющими центрами, с остальными доверие будет проверено автоматически.
Если плохо работает YouTube, то можно смотреть в Дзен или VK.
Поддержать создание курса можно на Boosty или CloudTips.
Forwarded from Гречневые мысли
All work no play makes Claude a dull boy
Сидел недавно вечером, отдыхал после работы, кушал куриную грудку и выбирал себе плавки на яндекс маркете. Зацепился взглядом за мини-игры, которые дают какие-то бонусы, нашёл там 2048 и залип. Играл весь вечер, собрал какое-то большое число и внезапно заинтересовался — а насколько ллмки умеют играть в 2048?
Кроме автоматизации получения бонусов с яндекс маркета, меня интересовала ещё одна деталь. Моим дипломом в магистратуре была проверка умений VLM к физическому ризонингу — условно, даём модели картинку с 2D физической сценой и просим предсказать, что будет дальше. Но VLM (даже SOTA в лице GPT-4) очень плохо справлялись с этой задачей, путали лево и право и галлюцинировали цвета шариков, так что тот проект превратился в бенчмарк, где ллм в агентном цикле генерили код для симуляции этих сцен (и работало это всё равно довольно плохо). Соответственно, возникает вопрос — если в 2023 году VLM так плохо справлялись со spatial reasoning, насколько лучше с ним они будут справляться в конце 2025?
Проверить легко — вместе с клодом кодом написали движок для 2048, управляющийся через LEFT, RIGHT, UP, DOWN, прикрутили визуализацию, сделали нативный function calling (спасибо Kristaller за пулл-реквест) и запустили следующие модельки:
- Qwen-3-VL-8B-Thinking и Instruct — посмотреть, как работают мелкие open-source VL модельки, проаблейтив наличие или отсутствие thinking, текстовый или картиночный ввод и контекст в 5 ходов
- Qwen-3-VL-235B-Thinking и Instruct — посмотреть, как работают крупные open-source VL модельки, проаблейтив наличие или отсутствие thinking
- Gemini 2.5 Flash Lite — посмотреть, как работают закрытые VL модельки мелкого размера
- Claude 4.5 Sonnet — фронтир модель
К сожалению, 2048 очень рандомная игра. Хорошую стратегию всегда может испортить заспавнившаяся в неудачном месте цифра и игра будет проиграна. Да и из-за рандомности генерации двоек и четвёрок счёт в случае некоторых моделей при равном числе шагов отличался аж на 20%. Кроме того, за несколько ранов я мог наблюдать, что счёт ллмок из-за рандомности даже с зафиксированным сидом сильно скакали. Но несмотря на рандом, вот несколько паттернов, которые мне удалось заметить:
- Модели уже не слепые котятки, потому что ризонинг трейсы были относительно внятными и направления аргументировались осмысленно. Модели понимают концепцию направления и могут производить некоторый spatial reasoning, хоть и делают дофига ошибок.
- Хайскор — 256 + 128 у мелкого квена ризонера. Остальные модели добирались до 128 и дальше проигрывали. Автоматизировать получение бонусов на Яндекс Маркете не получится.
- Ризонинг, кажется, помогает. Qwen-3-VL-8B-Thinking и 235B-Thinking работали стабильно лучше, чем Instruct версии тех же моделей.
- Количество нелегальных шагов слабо зависит от итогового счёта и размера моделей. У Qwen-3-8B-Thinking в пять раз меньше нелегальных ходов, чем у Соннета.
- Кажется, мультимодальность мешает модели, но с этим непонятно. При смене домена с картиночного на текстовый число нелегальных шагов подскочило втрое, но и счёт вырос вдвое.
- 2048 — это плохой бенчмарк из-за рандомности. Что, впрочем, не остановило наших коллег из UC San Diego, UC Berkley и MBZUAI от включения этого энвайрмента в свой сабмит на ICLR 2026. Oh well.
- Я мог бы погуглить, прежде чем садиться тратить время и деньги на апи, но what's the fun in that? :P
Клод написал мне веб-страничку с визуализатором, посмотрите обязательно, это прикольно. Код выложен на моём гитхабе.
Сидел недавно вечером, отдыхал после работы, кушал куриную грудку и выбирал себе плавки на яндекс маркете. Зацепился взглядом за мини-игры, которые дают какие-то бонусы, нашёл там 2048 и залип. Играл весь вечер, собрал какое-то большое число и внезапно заинтересовался — а насколько ллмки умеют играть в 2048?
Кроме автоматизации получения бонусов с яндекс маркета, меня интересовала ещё одна деталь. Моим дипломом в магистратуре была проверка умений VLM к физическому ризонингу — условно, даём модели картинку с 2D физической сценой и просим предсказать, что будет дальше. Но VLM (даже SOTA в лице GPT-4) очень плохо справлялись с этой задачей, путали лево и право и галлюцинировали цвета шариков, так что тот проект превратился в бенчмарк, где ллм в агентном цикле генерили код для симуляции этих сцен (и работало это всё равно довольно плохо). Соответственно, возникает вопрос — если в 2023 году VLM так плохо справлялись со spatial reasoning, насколько лучше с ним они будут справляться в конце 2025?
Проверить легко — вместе с клодом кодом написали движок для 2048, управляющийся через LEFT, RIGHT, UP, DOWN, прикрутили визуализацию, сделали нативный function calling (спасибо Kristaller за пулл-реквест) и запустили следующие модельки:
- Qwen-3-VL-8B-Thinking и Instruct — посмотреть, как работают мелкие open-source VL модельки, проаблейтив наличие или отсутствие thinking, текстовый или картиночный ввод и контекст в 5 ходов
- Qwen-3-VL-235B-Thinking и Instruct — посмотреть, как работают крупные open-source VL модельки, проаблейтив наличие или отсутствие thinking
- Gemini 2.5 Flash Lite — посмотреть, как работают закрытые VL модельки мелкого размера
- Claude 4.5 Sonnet — фронтир модель
К сожалению, 2048 очень рандомная игра. Хорошую стратегию всегда может испортить заспавнившаяся в неудачном месте цифра и игра будет проиграна. Да и из-за рандомности генерации двоек и четвёрок счёт в случае некоторых моделей при равном числе шагов отличался аж на 20%. Кроме того, за несколько ранов я мог наблюдать, что счёт ллмок из-за рандомности даже с зафиксированным сидом сильно скакали. Но несмотря на рандом, вот несколько паттернов, которые мне удалось заметить:
- Модели уже не слепые котятки, потому что ризонинг трейсы были относительно внятными и направления аргументировались осмысленно. Модели понимают концепцию направления и могут производить некоторый spatial reasoning, хоть и делают дофига ошибок.
- Хайскор — 256 + 128 у мелкого квена ризонера. Остальные модели добирались до 128 и дальше проигрывали. Автоматизировать получение бонусов на Яндекс Маркете не получится.
- Ризонинг, кажется, помогает. Qwen-3-VL-8B-Thinking и 235B-Thinking работали стабильно лучше, чем Instruct версии тех же моделей.
- Количество нелегальных шагов слабо зависит от итогового счёта и размера моделей. У Qwen-3-8B-Thinking в пять раз меньше нелегальных ходов, чем у Соннета.
- Кажется, мультимодальность мешает модели, но с этим непонятно. При смене домена с картиночного на текстовый число нелегальных шагов подскочило втрое, но и счёт вырос вдвое.
- 2048 — это плохой бенчмарк из-за рандомности. Что, впрочем, не остановило наших коллег из UC San Diego, UC Berkley и MBZUAI от включения этого энвайрмента в свой сабмит на ICLR 2026. Oh well.
- Я мог бы погуглить, прежде чем садиться тратить время и деньги на апи, но what's the fun in that? :P
Клод написал мне веб-страничку с визуализатором, посмотрите обязательно, это прикольно. Код выложен на моём гитхабе.