5654
Сохраненки и шитпост про ML от @YallenGusev Чат канала: @augur_chat
На LessWrong поймал очень классный пост: ссылка
Местами ржал в голос, очень увлекательно написано.
Основные утверждения:
1. У Антропиков, оказывается, была статья про ИИ ассистентов через промптинг базовых моделей. В декабре 2021 года, за пару месяцев до InstructGPT. Не то чтобы я эту статью никогда не видел, но я её не читал. И вот промпт из этой статьи неожиданно задал стиль общения для всех последующих ИИ ассистентов. То есть базовую модель заставили имитировать ещё не существующий ChatGPT, из-за чего реальный ChatGPT получился таким, каким получился.
2. Для нормального продолжения текста базовые модели пытаются неявно понять, кто этот текст написал и что это был за человек. Но первые языковые модели, которые прошли через обучение инструкциям, не имели понятия, кого им надо отыгрывать! В корпусах для выравнивания на самом деле никак толком не определялся характер персонажа, "ИИ ассистента", а в текстах предобучения про таких ассистентов не было ни слова. Модели были вынуждены имитировать штуку, о которой они не имели никакого представления, и которая не существовала в их "реальности". Отчасти из-за этого модели можно было так легко джейлбрейкать, потому что нечего было ломать: персонаж "ИИ ассистента" был плохо прописан. Кроме того, когда тексты о ChatGPT попали в интернет, все последующие ассистенты автоматически получили частичку характера ChatGPT.
3. Тесты "безопасности", которые устраивают при больших запусках, отвратительны. Если в них вчитаться, то окажется, что модели ведут себя вполне нормально и адекватно, а ожидаются от них реально злые штуки. Более того, само наличие тестов и их подробное описание делает последующие модели гораздо более небезопасными. То есть AI safety команды крупных игроков раскручивают спираль опасности и исполняют самосбывающееся пророчество.
Мини-утверждения:
1. Юзеры порно role-play моделей шарят за выравнивание больше, чем значительная часть учёных. Потому что они хотя бы разговаривают с моделью. Как и поехавшие на языковых моделях.
2. Claude 3 Opus — пока что лучшая модель за всё время.
3. Claude Gov — линейка моделей для спецслужб и военных! Вот оно ваше выравнивание...
С большинством утверждений я скорее согласен, очень интересный взгляд на историю моделей.
Собирать стиль из случайных покупок - все равно что пытаться составить осмысленное предложение из слов на холодильнике.
По отдельности интересно, но вместе не очень работает 😐
Aesty (Antler ‘24) - это Fashion OS: приложение, который помогает собрать стиль из того, что у тебя уже есть, и дополнить его тем, что действительно нужно. Получается связный, логичный гардероб, который работает как система и курируется приложением 🎧
В отличие от классических fashion-приложений, Aesty:
- Позволяет примерять и свои вещи, и новые — прямо на себе, в одном образе
- Показывает, что у тебя уже есть в гардеробе и как это сочетать друг с другом
- Строит образы под погоду, стиль и тренды
- Показывает, что действительно стоит докупить — с учетом твоего контекста, а не просто красивой ленты в пинтересте
С первого дня Aesty помогает иначе смотреть на гардероб не как на хаос, а как на стройную, понятную систему 😎
⌨️ Лаунч на Product Hunt: https://www.producthunt.com/posts/aesty-your-fashion-os/
будем рады поддержке 🤝
🎁 Только для PH:
Инвайт другу = обеим бесплатная примерка
Промокод: PRODUCTHUNT
Лайк, шэир, репост очень привествуются! 😎
Multiverse: Your Language Models Secretly Decide How to Parallelize and Merge Generation
[Статья][Код (Page Not Found)][Страница проекта (мое почтение)]
Вряд ли для кого уже будет новостью, что test-time compute scaling значительно улучшает качество моделей на задачах, требующих рассуждений. Причем можно масштабировать, как в длину, так и в ширину. Более того, LLM можно научить (а можно попробовать прямо из коробки) решать задачу от лица нескольких взаимодействующих процессов.
И команда из CMU/Nvidia предложила свой метод (с небольшим дообучением), под названием MulitVerse, где модель динамически переключается между последовательной и параллельной генерацией.
min-p — В С Ё
Обожаю скандалы, особенно когда они касаются непосредственно меня.
Начало истории: ссылка, там можно полистать чуть вниз
Продолжение: ссылка
Оригинальная статья: ссылка
Новая статья с критикой: ссылка
Если коротко, жил-был человек и придумывал себе прикольные сэмплеры для языковых моделей. Одним из таких был довольно популярный min-p, в котором просто отрезались все токены с вероятностью ниже заданной.
Я с этим сэмплером ознакомился и решил забенчмаркать разные сэмплеры на разных промптах про написание историй и role-play, и с более-менее современной моделью. Результаты отослал человеку, он их позже включил в свою статью про min-p. Статья вышла в топ-15 по оценкам рецензентов на ICLR. Меня добавили в acknowledgements. Все довольны, happy end... Или нет?
Сегодня, листая alphaxiv, я натыкаюсь на статью с критикой оригинальной статьи, где... есть ссылка на тот самый канал, который вы читаете! В разделе 4.3 есть прямая ссылка на пост из этого канала. Часто вы такое видели?
Разбирать по существу я эту статью буду в отдельном посте, а пока просто порадуемся за бесплатную рекламу для меня 🥰
Corrector Sampling in Language Models
Статья: ссылка
Идея о языковых моделях, которые корректируют сами себя, не нова. Я часто такое видел в контексте цепочек рассуждений. В диффузионных моделях это тоже можно делать практически бесплатно, заново маскируя токены. Но вот в авторегрессионных (=обычных) моделях для подобных корректировок нужно очень попотеть.
В этой статье описывается процедура дообучения авторегрессионной языковой модели с небольшими перестановками входов/выходов. Цель этих перестановок — научить модель заново предсказывать предпоследний токен на основании токенов до него и последнего токена. После такого дообучения можно на этапе инференса заново сэмплировать уже сгенерированные токены, по сути проходясь ещё раз по написанному тексту.
При обучении сама архитектура не меняется, добавляется только один слой относительных позиционных эмбеддингов, который кодирует реальное расстояние от выходного токена до входного. Собственно, ещё меняется порядок входных и выходных токенов (чтобы предпоследний токен стал последним, например). Так модель учится работать в двух режимах, а переключаются они позиционной кодировкой расстояний. Если подаётся вектор расстояний (1, 1, ..., 1), то это классическое предсказание следующего токена. Если что-то типа (1, -1, 2, ..., 1), то это в том числе про предсказание предыдущих токенов.
8B модель, 1T токенов. 90% обучения идут одинаково, оставшиеся 10% с фичёй и без фичи. Получившиеся 2 модели сравниваются на всяких бенчмарках про код, с фичёй получается чуть лучше. Даже если ничего не менять при инференсе 😐
Трюк прикольный (а нафига бы мне ещё писать этот пост), но... Статья написана так себе, очень много неоднозначностей. Например, одна из эвристик инференса — приёмка по уверенности. И не очень понятно, вероятность какого именно токена имеется в виду, оригинального или нового. Эксперименты на богатом (256 H100). Кода нет 💀
У HF позавчера начался агентский хакатон: https://huggingface.co/Agents-MCP-Hackathon
Регистрация открыта до 8 июня, тогда же последний день посылок.
Бесплатные кредиты на паре вендоров для всех участников. 3 трека: MCP инструменты в HF Spaces, Gradio UI компоненты, целиковые агенты (тоже в Spaces). 2500$ за первое место в каждом плюс призы от спонсоров.
Вышла статья и результаты, сайт тут: https://www.vgbench.com/
Код тут: https://github.com/alexzhang13/VideoGameBench
В целом все модели около нуля, но Gemini 2.5 Pro и Claude 3.7 себя показывают чуть лучше.
Самое обидное, что никакого прогресса в Civilizaiton 1 модели не делают( надо бы заняться вопросом!
На видео: Gemini 2.5 Pro играет в Kirby's Dream Land в реальном времени, успешно проходя начальный уровень и достигая первой встречи с мини-боссом.
Не так давно OpenAI и Anthropic выпустили поиск как инструмент.
Документация Anthropic: ссылка
Документация OpenAI: ссылка
До этого я пользовался DuckDuckGo поиском с питонячьей библиотекой. Без прокси это было довольно больно, регулярно попадал на rate limit. Поэтому искал альтернативу.
В качестве альтернативы было несколько платных сервисов, типа SerpAPI. Но цена... 75$ за 5000 поисков, причём только по подписке. И у конкурентов как будто бы не сильно дешевле.
По идее можно было покупать и напрямую у Гугла, но там всё было слишком хитро и результаты тамошнего облачного поиска сильно отличались от основного.
У OpenAI цена 35$ за 1000 поисков, что офигеть как много. У Anthropic сильно лучше: 10$ за 1000 поисков (плюс расходы на токены).
Поэтому в некоторых проектах перешёл на поиск от Антропиков. Например, в боте (@saiga_igusev_bot). Код: ссылка.
Всё целиком оформлено как асинхронный пайплайн (спасибо питонячьему asyncio), где множество задач работают параллельно и дожидаются результата от предыдущих шагов, когда требуется. В пайплайне есть контроллер, LLM сэмплеры и узлы оценки. Всё оптимизировано под throughput, а не время выполнения одного конкретного вычисления. Максимизируют количество проверяемых идей за фиксированный вычислительный бюджет.
Это в целом всё, система не выглядит суперсложной. По сравнению с прерыдущими AlphaTensor, AlphaDev, FunSearch и т.п. всё больше “интеллекта” выносится на сторону LLM.
С FunSearch есть отдельное сравнение в таблице, если кратко, то три ключевых момента. FunSearch работал на уровне одной питоновской функции, здесь работа на уровне всей кодовой базы, сколько имеется, и не обязательно на питоне. У FunSearch была одна objective function, здесь же многокритериальная оптимизация. Наконец, внутри FunSearch были довольно маленькие LLM, обученные на коде, а здесь одна из лучших фронтирных моделей.
Итак, применили AlphaEvolve к различным задачам.
Например, поиск декомпозиции тензора для нахождения способа перемножения матриц, та же самая задача, которую решал узкоспециализированный AlphaTensor, подробнее про саму задачу рекомендую прочитать в оригинальном посте. Стартовали со стандартного градиентного алгоритма, включающего инициализатор, лосс функцию для реконструкции тензора, и оптимизатор Adam. С этой стартовой точки AlphaEvolve вывел новый алгоритм и улучшил SoTA результаты для матричных умножений 14 разных размеров ⟨𝑚, 𝑛, 𝑝⟩. Интересно, что в таблице заявлено улучшение для размера ⟨4, 4, 4⟩, где получили 48 скалярных умножений вместо 49. AlphaTensor правда получал 47, но там была модульная арифметика, а здесь это число для комплексной.
Другое направление включало 50 математических задач из анализа, комбинаторики, теории чисел и геометрии, где надо было находить объекты или делать построения с определёнными свойствами, оптимальными или около-оптимальными по некоторой мере. В 75% случаев AlphaEvolve переоткрыл известное лучшее решение, в 20% улучшил его. Во всех случаях стартовали со случайного или простого решения. По сравнению с классическими подходами AlphaEvolve более универсален и не требует какого-то особого затачивания на конкретную задачу, он сам способен обнаружить эффективные паттерны для поиска решения, что открывает дорогу к широкомасштабному исследованию разных задач. Здесь мы имеем сильно улучшенный FunSearch.
Главная методологическая инновация здесь -- это способность выводить (в смысле эволюционировать) эвристические алгоритмы поиска, вместо того чтобы сразу выводить сами построения. В частности использовалась стратегия итеративного улучшения, когда на каждом шаге алгоритму давали лучшее решение предыдущего шага и фиксированный бюджет (1000 секунд), и модель должна была найти более хорошее построение. Так отбирались эвристики, способные улучшать уже найденные хорошие решения, и финальное построение являлось результатом цепочки различных специализированных эвристик -- ранние специализировались на улучшении простых или случайных начальных состояний, поздние на файнтюнинге околооптимальных решений.
Найденные математические результаты и результаты тензорных декомпозиций собраны в колабе.
Применили AlphaEvolve и к инфраструктурным задачам Гугла -- шедулингу задач на кластере, управляемом Borg. Там надо было раскидывать задачи по машинам с учётом доступности и требований по CPU/memory. Функция должна была выдавать priority score для каждой машины под текущую задачу. AlphaEvolve нашёл эвристику, улучшившую текущую эвристику Гугла в продакшне, что привело к экономии 0.7% ресурсов. В отличие от результатов DRL это ещё и проще и понятнее.
Еду на ACL 2025 с внезапно аж 2 статьями по работе. В обеих я не первый автор (но и не последний). Одна на основной части, одна на индустриальном треке. Как будут тексты в открытом доступе, подробно про них расскажу. Если коротко:
- Первая статья про семантический поиск по отелям от нашего PhD стажёра. В ней мы строим поисковую модель, которая умеет использовать информацию сразу из фоток/рецензий/описания, и у которой хитрый мультизадачный лосс с self-supervised компонентами. В итоге получается эмбеддинг, в котором лежит вся информация об отеле, а также маленькая моделька, которая умеет отображать поисковые запросы в то же пространство, где лежат эмбеддинги отелей.
- Вторая статья (на индустриальном треке) про совмещение Медузы и SeqKD (дистилляции) в применении к нескольким существующим задачам Букинга. Это совместная работа с очень толковыми ребятами из Амазона.
DeepWiki — нейросетевой инструмент, который генерирует подробную документацию на основе GitHub-репозиториев. Для доступа достаточно заменить github.com в адресной строке на deepwiki.com
#сервисы@daniilak
AI Safety стартап WhiteCircle.ai, НАШИ ребята, выкатили бенчмарк для guard-моделей CircleGuardBench и показали две собственные guard модели которые обходят ShieldGemma, PromptGuard и OpenAI moderation.
Guard модели работают модераторами для LLM: ловят джейлбрейки, атаки и нарушения правил. Раньше их тестировали либо на токсичных промптах (HarmfulQA, HarmBench), либо на джейлбрейках (AART), либо на тайминге. Каждый из этих подходов измерял какой-то аспект guard модели, но не её практическую полезность.
В новом бенчмарке авторы составили таксономию вредных запросов и смотрят: что модели блокируют, что пропускают и насколько быстро обрабатывают запросы. Интересно, что метрика комбинированная, а не просто accuracy, как обычно делается. В реальном проде false positive могут убить UX, а false negative компанию. Accuracy или даже какой-нибудь f1-score сами по себе не оценивают практическую полезность модели для работы в проде. Они показывают только качество в идеальных условиях неограниченного времени.
В CircleGuardBench авторы ввели комбинированный скор, который взвешивает несколько метрик и добавляет штрафы за время ответа и наличие ошибок.
Они так же написали прикольный пост на HF: рассказывают не только про цифры, но и про то, как дизайнили и собирали бенчмарк. Мастрид про безопаспость LLM.
Ждём теперь бенчмарк для атакующих моделей, которые взламывают guard-модели, которые защищают базовые модели.
- Блог на huggingface
- Тред в X
- Лидерборд
- Код на github (нормальный код!!!)
А теперь снова развлекательная часть: в интернете опять кто-то не прав 🍿
Осуждаемый пост: We Have Made No Progress Toward AGI
Если упростить, вся статья сводится к 2 утверждениям. Утверждения аналогичны вот этому посту: (Maybe) A Bag of Heuristics is All There Is & A Bag of Heuristics is All You Need, только позиция по ним несколько другая 😳
🔹Утверждение 1: языковые модели — это только мешок эвристик
Цитаты:
> These models are nothing more than statistical models. They can’t determine what is right and what is wrong. They can only heuristically determine what is probably right and what is probably wrong.
> Emergent model behavior is simply patterns. You build bigger models that can find more patterns and you get more patterns. It is patterns all the way down.
Перефразируя, в языковых моделях нет ничего, кроме статистических шаблонов. Посты про механистическую интерпретацию как будто бы это подтверждают: в них в моделях находятся именно эвристики и шаблоны. Для сложения, например, нашлась своя эвристическая схема.
Какова же реальная ситуация? Мы знаем, что статистические шаблоны в языковых моделях есть, но есть ли что-то ещё? Предположим, мешок эвристик на самом деле является параллельным алгоритмом сложения (пример из этого комментария). Смогли бы мы это понять с текущими инструментами интерпретации? А ведь разные алгоритмы даже вполне находятся: раз, два, три.
В целом, конструктивные вопросы звучали бы так: какие алгоритмы представимы и выучиваемы на базе трансформеров? Какие из них выучиваются языковыми моделями? Автор же говорит: только шаблоны, только эвристики 🤦♂️
🔹Утверждение 2: мешок эвристик — это не интеллект
Цитаты:
> A statistical model can not perform the full set of capabilities as intelligence and for the ones where there appears to be overlap, it is seemingly so at the cost of extraordinary inefficiency and unreliability.
> LLMs are statistical models that can arrive at the correct answers, but by means that look nothing like intelligent reasoning and therefore this meaningful difference in process has significant implications for what LLMs will ultimately be capable of achieving.
> Therefore, they (language models) are incapable of constructing hard rules of the world by reasoning.
Перефразируя, языковые модели работают неправильно. Хоть они и достигают целей, но делают это способами, непохожими на нормальные разумные рассуждения. Вот если бы они приводили логичные человекочитаемые рассуждения, тогда было бы другое дело! Но вот сейчас они галлюцинируют, и будут галлюцинировать, и текстовые рассуждения не соответствуют реальным процессам внутри модели.
С моей точки зрения тут в полный рост и проявляется антропоцентричность, и на протяжении всей статьи мы не раз ещё это увидим 👎
> On the quest for human-like reasoning machines
> Human reasoning is something far more sophisticated than a statistical model
Доведенное до конца рассуждение звучит так: если ты не человек, ты не разумен.
Означают ли плохие вербальные рассуждения отсутствие интеллекта? Если бы это было правдой, то можно было бы говорить, что все животные в принципе не обладают интеллектом. Рассуждения людей тоже могут быть неправильными или не соответствовать действиям.
Если отбросить эти компоненты, то останется неприятие статистических паттернов. Почему статистические паттерны — это не интеллект? А чёрт его знает. Хорошо бы определить, что такое интеллект. Автор, естественно, не соизволил этого сделать.
🔹Остальное
Автор предлагает избавиться от всех бенчмарков и вводит 2 новых сигнала интеллекта: эффективность и отсутствие коллапса при обучении в цикле на сгенерированных данных. И если эффективность — ок, то второй сигнал абсурден, потому что даже люди так не умеют.
Что касается определения интеллекта, мне нравится RL определение:
Интеллект — это способность агента достигать целей в широком спектре окружающих сред
По нему что эвристики, что рассуждения — не важно, лишь бы работало и обобщалось.
И личное: использование мема из Звёздного Пути считаю особенно греховным, учитывая репрезентацию синтетиков в сериалах.
Circuit Tracing: Revealing Computational Graphs in Language Models
Статья: ссылка
Часть 1
Первая из набора антропиковских статей. Она безумно большая сама по себе 😳, кроме того содержит интерактивные визуализации.
В этом посте покрыто два перехода: SAE -> CLT -> локальная заменяющая модель.
Теоретические предпосылки SAE (гипотеза суперпозиции) опустим.
🔹SAE
SAE (sparse autoencoders, разреженные автокодировщики) — довольно популярная техника механистической интерпретации. Мы берём активации модели (например, выход MLP). Эти активации мы хотим отобразить в разреженный вектор высокой размерности. Для этого мы учим двухслойную нелинейную сетку с одним промежуточным вектором с размерностью выше оригинальных активаций. Реконструируем активации с MSE лоссом. Разреженность можно обеспечить по-разному, например через L1 штраф (как в Lasso) или через TopK, то есть прямой отбор k наибольших значений. Или через JumpReLU.
Для больших моделей учить SAE сложно и долго, поэтому есть уже обученные наборы, такие как Gemma Scope. Есть и Нейронпедия, платформа для визуализации разных наборов SAE. Там можно подставить свой текст и посмотреть, какие фичи на каких токенах активировались для разных моделей и разных наборов.
Исследования SAE-подобных инструментов долгое время были мейнстримом механистической интерпретации. Однако, недавно DeepMind снизил приоритет вокруг них. Они попытались применить SAE для чего-то реально полезного, но оказалось, что простые линейные зонды справляются лучше. Кроме того, есть и другие работы, которые показывают серьёзные ограничения SAE. Это не означает, что DeepMind полностью откажется от SAE, но теперь они гораздо более скептично к ним настроены.
🔹CLT
Транскодеры — это SAE-подобный инструмент, только в качестве входа выступают входные активации MLP, а в качестве выхода — выходные. То есть мы полностью заменяем MLP на разреженную версию. Это позволяет нам создавать альтернативные версии модели, в которых какие-то фичи изменены. Антропики же используют не просто отдельные послойные транскодеры, но межслойные транскодеры (cross-layer transcoders, CLT). Это означает, что при реконструкции выходных активаций на слое L используются все разреженные векторы с более нижних слоёв.
Так вот, они как-то обучают эти самые CLT и при замене оригинальных MLP на разреженные аналоги проверяют, насколько сильно ломается модель. Для 18-слойной модели самые жирные их CLT дают тот же топ-1 токен в ~50% случаев. Ещё раз, полученная таким образом заменяющая модель — это аппроксимация оригинальной модели, что несколько обесценивает любые результаты, полученные через её анализ 😫
🔹Локальная заменяющая модель
Поэтому эту модель "исправляют" через добавление "тёмной материи" (термин из статьи, это не я придумал) — констант ошибок реконструкции для заданного промпта. Так вводится понятие локальной заменяющей модели, в которой для заданного промпта все ошибки реконструкции исправляются добавлением констант, а все паттерны внимания заморожены (=веса внимания не вычисляются, а зафиксированы для каждого слоя и токена). Таким образом, для этого конкретного промпта локальная заменяющая модель ведёт себя в точности как оригинал. При этом получившаяся модель — это практически линейная полносвязная сетка (с вычисляемыми "виртуальными" весами), где единственные нелинейности есть внутри CLT. Это позволяет производить принципиальную атрибуцию фичей.
Но даже при идеальном воспроизведении активаций и выходов для заданного промпта, локальная заменяющая модель может использовать механизмы, отличные от исходной модели. Степень сходства механизмов называется авторами "механистической верностью" (mechanistic faithfulness), и измеряют её через пертурбационные эксперименты.
🔹Промежуточный вывод
CLT действительно выглядят прикольнее стандартных SAE. Но вот насколько можно верить объяснениям, полученным таким образом — вопрос открытый. Да, ребята пытаются это численно оценить, но где граница, на которой можно сказать "да, верим"? 🤨
О новых статьях про механистическую интерпретируемость от Anthropic
- Короткий обзорный пост: Tracing the thoughts of a large language model
- Первая основная статья: Circuit Tracing: Revealing Computational Graphs in Language Models
- Вторая основная статья: On the Biology of a Large Language Model
- Пессимистичный пост (не от Антропиков) по мотивам второй статьи, с которым я жёстко не согласен: We Have Made No Progress Toward AGI
🍿 Начнём с развлекательной части — с выводов, полученных через механистическую интерпретацию. Эксперименты проводились на основе Claude 3.5 Haiku. Об обобщении на все-все языковые модели говорить не приходится, но, к счастью, у большинства выводов есть и внешние подтверждения.
🔹В многоязычных языковых моделях существует общее пространство концептов для всех языков. Это проверяли, спрашивая антоним к слову "маленький" и проверяя, активировался ли один и тот же набор схем.
См. также:
- ACL 2024 день 2
- Do Llamas Work in English? On the Latent Language of Multilingual Transformers
- Large Language Models Share Representations of Latent Grammatical Concepts Across Typologically Diverse Languages
🔹При сочинении стихов модель планирует наперёд, на какое слово должна закончиться следующая строка для сохранения рифмы. И потом раскручивает строку назад. Это проверили, найдя концепт, отвечающий за запланированное слово, и заменяя его на другие слова.
См. также:
- Как научить свою нейросеть генерировать стихи (справа налево)
- Physics of Language Models, part 2.1 (результат 5)
🔹При сложении двузначных чисел модель использует мешок эвристик. В стиле ("складываем что-то около 36 к чему-то около 60" => "сумма близка к 92"). Тут, мне кажется, это вопрос обучения. Трансформеры точно могут выучить нормальную схему для сложения, что показывалось неоднократно (см. "сложение в трансформерах" ниже). Это не означает, что языковые модели всегда её выучивают, но они пытаются (см. "сложение в LLM" ниже).
См. также:
- OthelloGPT learned a bag of heuristics (мешок эвристик)
- A Mechanistic Interpretability Analysis of Grokking (сложение в трансформерах)
- Language Models Use Trigonometry to Do Addition (сложение в LLM)
🔹В CoT модель галлюцинирует объяснения, например в случае того же сложения. То есть объяснение модели никак не связано с её настоящим мыслительным процессом.
См. также:
- Making Reasoning Matter: Measuring and Improving Faithfulness of Chain-of-Thought Reasoning
- Think before you speak: Training Language Models With Pause Tokens
🔹В рассуждениях, которые требуют несколько шагов, можно отловить промежуточные концепты. Например, есть вопрос “Какой город является столицей региона, в котором находится Нижнекамск?”. Для этого модели нужно 2 факта: “Нижнекамск в Татарстане" и "Казань — столица Татарстана". И действительно, показывается, что оба этих факта используются, чтобы получить правильный финальный ответ.
См. также:
- Testing which LLM architectures can do hidden serial reasoning
🔹В моделях есть схема, которая отвечает за отказы, и она включена по умолчанию. Но если модель спрашивают что-то, о чём она знает, включается конкурирующая схема "знакомых сущностей", которая побеждает схему отказов. Иногда включение схемы "знакомых сущностей" происходит не вовремя, и тогда получаются галлюцинации. Влияя на любую из этих схем, можно заставить модель производить галлюцинации.
См. также:
- Inference-Time Intervention: Eliciting Truthful Answers from a Language Model
- Uncensor any LLM with abliteration
🔹Почему работают джейлбрейки? Есть схемы, отвечающие за безопасность, и есть схемы, отвечающие за собственно составление текста. В случаях джейлбрейков они конфликтуют друг с другом, и если вторые побеждают, то модель выдаёт небезопасные выходы.
См. также:
- Safety Alignment Should Be Made More Than Just a Few Tokens Deep
Узнали ли мы что-то новое? Авторы думают, что да. Для них факт про стихи был удивительным. Я скорее склоняюсь к "нет", но прикольно, что все эти утверждения собрали в одном месте. Следующие посты будут про собственно сам метод интерпретации и про критику пессимистичного поста ⚰️
Обе статьи, которые приняли на ACL и в которых я соавтор, теперь в открытом доступе!
Speed without sacrifice: Fine-tuning language models with Medusa and knowledge distillation in travel applications
Статья: ссылка
Индустриальный трек, научной новизны около нуля, зато полезные циферки на реальных задачах. Совместная работа с командой из Амазона.
Есть 3 букинговских кейса (все в проде, но раскатаны не на все страны):
- “Умные” фильтры. Когда вы ищите отель на Букинге, слева есть колонка с кучей разных фильтров (типа “Завтрак включен”, “Рейтинг выше 8”, “С бассейном”). Фича — текстовая формочка, в которую вы пишите, что вы хотите, и это автоматически транслируется во все нужные галочки. То есть не надо скроллить и искать фильтры вручную.
- Чатбот, который рекомендует отели и города для посещения. То есть вы с ним переписываетесь, и в определенный момент (когда хватает информации) он рекомендует карусель с карточками отелей. Карусель выдается на базе существующего рекомендательного движка Букинга, и в качестве входа он принимает структурированную информацию (большой JSON), который извлекается на основе переписки.
- Автоматические описания отелей. До этой фичи там были текстовые шаблоны с переменными. Теперь всё красиво пишется локальной моделькой на основе инфы от партнеров, отзывов юзеров и даже информации о текущем пользователе (локация и сегмент).
А статья собственно про ускорение моделей для этих кейсов с помощью методов дистилляции (SeqKD) и спекулятивного декодирования (Медузы). Итоговые модели выдают меньше 300 мс задержки P99 для первых двух кейсов и на 2 порядка дешевле GPT-4 для третьего кейса.
Статью я буду рассказывать предварительно 28 июля в 14:00, Hall L.
Постер тоже будет, но хз когда.
HotelMatch-LLM: Joint Multi-Task Training of Small and Large Language Models for Efficient Multimodal Hotel Retrieval
Статья: ссылка
Когда я только пришёл в Букинг, одним из первых проектов был универсальный энкодер для отелей. К нему было 4 основных требования:
1. Он должен отображать отели в текстовое пространство, чтобы работал семантический поиск.
2. Он должен обрабатывать мультимодальные и мультидокументные данные произвольного количества: картинки, описание отеля, отзывы пользователей.
3. Он должен хорошо работать для поиска и для классификации. По эмбеддингам из него, например, мы могли хорошо определять правильный тип недвижимости: отель, апартраменты, дом, хижина, шале, бунгало, и так далее.
4. Запросный эмбеддинг должен считаться очень быстро, потому что его нужно считать на лету.
Первая итерация была поверх CLIP’а, и была давно. А вот эту статью делал наш PhD стажёр, Арьян, и это была уже вторая итерация. В ней CLIP всё ещё на месте, но основная тушка уже LLM, например Mistral 7B. Плюс есть всякие приколы, типа многозадачного лосса. Итоговая модель сравнивается с открытыми мультимодальными мультидокументными энкодерами VISTA и MARVEL и бьёт их по всем метрикам в основном за счёт нормальной интеграции картиночной части.
Для этой статьи будет только постер, который будет представлять сам Арьян, но я тоже скорее всего там буду.
Метод
Многие задачи допускают параллелизм. Авторы определяют 2 варианта:
1️⃣ Коллективный. Задача разбивается на независимые подзадачи. Процессы могут независимо решать каждую из них, а в конце результат агрегируется.
2️⃣ Селективный. Есть несколько веток рассуждений - правильные и неправильные. Неправильные отбрасываются.
Анализируя решения задач из s1.1-1k DeepSeek-R1/Gemini 2.0 Flash Thinking авторы обнаруживают что при авторегрессионной генерации многие решения содержат вышеописанные паттерны. Но можно ли генерировать их параллельно? Причем автоматически понимать, когда это нужно.
Могут ли сами LLM распознать что генерируют параллельно? Для валидации данной гипотезу обучают MLP поверх скрытых состояний (где последовательным веткам дается метка 1, а параллельным - 0) перед языковой головой и качество оказывается чуть лучше рандома. Из чего делают вывод, что, мол, не распознают 😩.
Дабы научить модель запускать параллелизм, когда надо, авторы собирают датасет на основе из s1.1-1k (с помощью Gemini 2.5 Pro). Ответы на задачи размечают специальными тегами:
🌐 <Parallel> / </Parallel> - начало/конец параллельного блока
🌐 <Outline> / </Outline> - описание подзадачи
🌐 <Path> / </Path> - решение подзадачи
🌐 <Conclusion> / </Conclusion> - вывод на основе решений
При входе в блок <Path> процессы генерируют независимо (attention маска одного процесса не дает смотреть на другой).
Обучение занимает примерно 3 часа на 8 B 200 (порадуемся за челов).
Все это может быть эффективно реализовано с помощью Radix Attention из SGLang.
Результаты
Метод валидируют на ряде ризонинг задач - AIME/GPQA-Diamond/MATH500. Дообучают Qwen2.5-32B-Instruct. Генерацию ограничивают от 1k до 4к токенов (мало для таких задач).
Полученная модель работает гораздо лучше, чем исходный Qwen. Просто авторегрессионное дообучение на трейсах тоже значительно улучшает качество по сравнению с изначальной моделью, но немного уступает Mutliverse и не дает желаемого параллелизма.
Явное указание в промпте (Mutliverse) с указанием think in parallel работает чуть лучше, чем Mutliverse-zero - без данной инструкции, но не всегда.
Mutliverse и заданном контекстом окне чуть лучше авторегрессивной генерации.
Степень параллелизма, достигаемая на практике, около 15-17%. И итоговое ускорение генерации (при фиксированной длине генерации) - до 18.5%.
Вывод
Интересное исследование, с красивой страницей проекта и качественной реализацией. Однако, не хватает сравнения с некоторыми очевидными бейзлайнами - такими как Self-Consistency и Hogwild. Кроме того, любопытно, как оно себя поведет поверх моделей, которые уже могут в ризонинг и на более длинных контекстах.
Разбор по существу начнём с тех частей, которые касаются непосредственно меня, а именно с 4 секции статьи.
Она про набор экспериментов, где большая языковая модель (gpt-4-turbo, давно дело было) оценивает ответы на разные промпты про написание историй и role-play. Эксперимент был такой: берём N промптов, считаем для всех них ответы в разных режимах сэмплирования, сравниваем их попарно с ответами, которые были получены сэмплированием по умолчанию (температура = 1, top_p/min_p/top_k отключены). Сравниваем через спрашивание gpt-4-turbo, какой ответ был лучше.
Претензии опровергаторов:
41а. В оригинальной статье не указана модель.
41б. В оригинальной статье не указаны доверительные интервалы.
41в. Сравнение с сэмплированием по умолчанию не очень хорошо, потому что попарные оценки нетранзитивны. Стоило бы сравнивать все методы напрямую с min-p.
42а. Нет кода инференса и подсчёта оценок.
42б. Бюджет гиперпараметров для min-p в 2 раза больше, чем для top-p и в 10 раз больше дефолтного сэмплирования.
42в. При некоторых гиперпараметрах min-p хуже top-p и дефолтного сэмплирования.
43. В первых версиях оригинальной статьи авторы использовали не наилучший винрейт для top-p.
Мои ответы:
41а, 41б, 42а — это ложь, потому что авторы ссылались на мой репо, и в нём всё это есть. Как опровергаторы признались в этом issue, они всё это просто... не нашли. Как я предполагаю там же, искали с телефона и забыли тыкнуть на кнопку "View all files" 😁
41в — это правда, но мои-то замеры были не сфокусированы на min-p, для меня это был только один из методов, которые я хотел проверить.
42б — это не совсем правда, просто часть замеров не попали в табличку по 2 причинам: либо получившиеся тексты были полностью "сломанными" (и любой прогон выдал бы для них околонулевой винрейт), либо неотличимыми от жадной генерации (и в репо есть метрика для этого). Это всё есть в этом скрипте, который, напомню, опровергаторы не нашли. Но реальная проблема в том, что я искал гиперпараметры по фиксированной сетке, а у min-p более широкий диапазон рабочих температур. Делай я эту же работу сейчас, делал бы по-другому.
42в — не очень понимаю, что это должно опровергать или доказывать.
43 — а вот это выглядит для меня как ненамеренная ошибка авторов статьи про min-p: она, на самом деле ни на что не влияет, и скорее всего кто-то случайно перепечатал соседнюю чиселку.
Это всё говорит о том, что опровержение очень ленивое. Там в остальных секциях тоже хватает приколов. Например, в 3 секции опровергаторы явно пишут, что изначально использовали формат промпта от Llama для других моделей по ошибке. Вот такой там уровень погружения, да.
AgentRxiv: Towards Collaborative Autonomous Research
Статья: ссылка
Лендинг: https://agentrxiv.github.io/
Очень смешная идея от создателя AgentLaboratory. AgentRxiv — специальный сервер, на который агенты могут складывать написанные статьи и переиспользовать их между запусками.
Замечу, что это не для того, чтобы их читали люди. Для этого есть уже есть viXra, то есть arXiv для статей, написанных с помощью языковых моделей.
А эта идея про то, что можно совместно запускать несколько автоматических исследователей, которые могли бы переиспользовать результаты друг друга. Один из описанных экспериментов как раз про запуск 3 параллельных "лабораторий".
В качестве тестовой задачи авторы используют разработку техник промптинга для решения MATH-500 (сомнительно, ну и ладно). Итоговые найденные техники якобы обобщаются на другие датасеты и задачи: GPQA, MMLU-Pro, MedQA.
С точки зрения реализации всё как в обычном ArXiv'е: сервер, API для поиска, чтения и загрузки статей, сайт для просмотра кожаными мешками. Поиск нормальный, то есть семантический.
Эксперименты:
1) Запуск по умолчанию с доступом к AgentRxiv (78.2% на MATH-500)
2) Обязательное учитывание 5 статей с AgentRxiv против отсутствия доступа к AgentRxiv (78.2% vs 73.8%)
3) Запуск 3 параллельных "лабораторий" (79.8%)
Что по цене? Модели: o1-mini и o1-preview. 280$ за 120 статей в 3 эксперименте (по 40 на каждую "лабораторию"). И примерно 3 дня реального времени 🤔
Из кеков:
- Модуль про написание кода часто генерировал питоновский exit(), что убивало весь пайплайн.
- Значительная часть экспериментов содержала критичные баги, из-за которых точность была примерно 0% 😂
- Ну и с latex'ом моделям было очень сложно (понимаемо).
Очень крутая механика, но по-моему всё ещё не хватает нормального интерфейса взаимодействия с людьми. Первый автор недавно был на стриме AI4Science сообщества alphaXiv, как раз рассказывал про AgentLaboratory и эту статью, я там был, мёд, пиво пил. Следующая статья от него будет про генерацию идей для исследований.
Собственно в рамках хакатона выделили из holosophos набор инструментов:
- Поиск и скачивание статей на ArXiv
- То же самое про ACL Anthology
- Графы цитирований из Semantic Scholar
- Поиск по датасетам в HF
Репо: ссылка
Space: ссылка
В README есть инструкции по подключению к Claude Desktop: ссылка
Скринкасты:
Про одну статью: https://www.youtube.com/watch?v=IAAPMptJ5k8
Про большой отчёт: https://www.youtube.com/watch?v=4bweqQcN6w8
Недавно я писал серию постов про новые инструменты для механистической интерпретируемости:
- Основные выводы: /channel/senior_augur/444
- Детали, часть 1: /channel/senior_augur/446
- Детали, часть 2: /channel/senior_augur/447
Ребята, которых финансирует Антропик, выложили в открытый доступ библиотеку для создания графов атрибуции.
Анонс: https://www.anthropic.com/research/open-source-circuit-tracing
Библиотека: https://github.com/safety-research/circuit-tracer
Пример графа на Нейронпедии: ссылка
Графы доступны для Gemma 2 2B и Llama 3.2 1B. Для всего остального нужны самим обучать транскодеры, и эта часть новой библиотекой не покрывается.
Анонимусы (без шуток, так и написано в статье) из неуказанной компании (но дальше честно говорится, что это Яндекс) выпустили статью — Yambda-5B: A Large-Scale Multi-modal Dataset for Ranking and Retrieval.
Собирать и раздавать датасеты — дело богоугодное. Помню, как Женя Макаров на Датафесте в 2018 году ходил и фотографировал эмоции людей, чтобы собрать уникальный датасет (Женя, где датасеты!). А тут сразу:
1 миллион пользователей,
9.39 миллиона треков,
4.78 миллиарда взаимодействий из Яндекс Музыки.
Для каждого трека прилагается эмбеддинг, полученный свёрточной сетью по спектрограмме. Почему не Vision Transformer — вопрос интересный, но идея понятна.
По типу фидбэка:
– Implicit — прослушивания
– Explicit — лайки и прочие действия
Из уникальных штук — флаг is_organic. У каждого события указано, было ли оно органическим или вызвано рекомендацией. Это редкость: можно отдельно изучать, как алгоритмы влияют на поведение и как выглядит "чистое" прослушивание.
Датасет выдают в Parquet (но без Iceberg, увы) — что уже хорошо.
И ещё одна редкость — реалистичная схема сплита (Где то радуется один Information Retrieval) :
• Train — 300 дней
• Gap — 30 минут
• Test — 1 день
Сначала делают Global Temporal Split по таймстемпам, но корректируют его, чтобы в тесте были только те пользователи, что есть в трейне — ближе к продакшену.
В общем, выглядит мощно. Ждём, когда Саша Петров наложит на это свои руки.
Перезалил, с ссылкой на датасет
Предыдущий пост про это: /channel/senior_augur/429
Спустя полтора месяца пользования Курсором и исчерпанную fast квоту, я, кажется, с ним смирился. Примерно понял, где он может выдать полную чепуху, с какими штуками он не справится, а с какими справится без проблем.
В больших незнакомых проектах особой альтернативы языковым моделям я не вижу. Можно, конечно, потратить часы на чтение кода и превращение незнакомого проекта в знакомый, но во многих случаях этого не очень-то и хочется, да и нет у меня этих часов.
Для своих пет-проектов, в которых я сам писал весь код, большой пользы от Курсора я не вижу и пользоваться им для них не буду. Это по-моему будет просто вредно для профессиональных навыков
[DeepMind] AlphaEvolve: A coding agent for scientific and algorithmic discovery
Alexander Novikov, Ngân Vu, Marvin Eisenberger, Emilien Dupont, Po-Sen Huang, Adam Zsolt Wagner, Sergey Shirobokov, Borislav Kozlovskii, Francisco J. R. Ruiz, Abbas Mehrabian, M. Pawan Kumar, Abigail See, Swarat Chaudhuri, George Holland, Alex Davies, Sebastian Nowozin, Pushmeet Kohli and Matej Balog
Статья
Пост
AlphaEvolve -- это coding agent агент, оркестрирующий пайплайн с вызовами LLM и выдающий алгоритм, решающий заданную пользователем задачу. Внутри процедуры оркестрации работает эволюционный алгоритм, постепенно создающий программы, улучшающие скор на автоматических метриках для заданной задачи.
Пользователь должен предоставить механизм автоматической оценки генерируемых решений -- это Python функция evaluate(), мапящая решение в набор скалярных метрик для оценки, которые надо максимизировать. Она может быть как простой и лёгкой, отрабатывающей за доли секунды, так и очень тяжёлой, включающей, например, распределённое обучение сети. Соответственно, задачи требующие ручного экспериментирования, остаются здесь за бортом, текущая версия работает для того, что может быть автоматически оценено.
AlphaEvolve предоставляет API, куда можно отправить код, где часть требующая улучшения помечена комментариями # EVOLVE-BLOCK-START и # EVOLVE-BLOCK-END. Где-то там же в коде находится и функция evaluate(), как и всё остальное, необходимое для связывания всех частей программы воедино.
Эволюционируемая программа не обязана быть финальным результатом, она может быть средством его достижения. Например, найденное решение может быть просто строкой (как часто бывает в эволюционных алгоритмах); функцией определённого вида, определяющей как должно быть создано решение; уникальным поисковым алгоритмом, могущим найти решение при заданном ограниченном бюджете; или ещё чем-то более сложным. Специфика задачи может влиять на выбор подхода, например, для проблем с очень симметричными решениями авторы советуют выводить функции-конструкторы, они получаются более краткими.
Внутри AlphaEvolve и его эволюционного цикла работают несколько компонентов.
Prompt sampler отвечает за шаблоны промптов, включая системные инструкции, а также вставляет в промпт предыдущие найденные решения, засэмпленные из базы программ. Здесь можно многое произвольно расширять: добавлять явные инструкции от пользователя, стохастическое форматирование с заданными извне распределениями, рендеринг результатов оценки, эволюционировать мета-промпт.
Ансамбль LLM, в статье комбинация Gemini 2.0 Flash и Gemini 2.0 Pro, используется для креативной генерации. Такой микс даёт возможность быстрой генерации множества гипотез через Flash и более качественные рекомендации от более медленной Pro. В целом система model-agnostic, можно использовать разное. LLM просят генерить изменения в коде в виде серии диффов, какой блок кода заменять на какой. Но можно и просить заменять код целиком, если так удобнее.
Evaluation содержит в себе набор оценщиков. В простом случае надо вызывать переданную пользователем функцию evaluate(). В реальности есть также различные опциональные добавки: каскады от более простых примеров к более сложным; фибдек от LLM, когда проще описать желаемые свойства решения, нежели оценивать; параллелизация оценки. Может считаться сразу множество метрик (функция evaluate() может возвращать несколько) и авторы утверждают, что даже если важна только единственная метрика, оптимизация по множеству метрик даёт лучше результат. Что мне немного удивительно, потому что в многокритриальной оптимизации вроде как не всё так просто, и редко когда получается увеличивать сразе все метрики, или хотя бы не ухудшать остальные при увеличении одной.
База программ или evolutionary database, хранящая найденные решения и оценки их качества. Здесь важно балансировать exploration и exploitation, так что база реализует алгоритм вдохновлённый комбинацией MAP elites и island-based population models.
Например, документация к боту Сайги: https://deepwiki.com/IlyaGusev/saiga_bot
Читать полностью…
τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains
Статья: ссылка
Код: ссылка
Вообще-то Тау-бенч — штука известная. Каким-то странным стечением обстоятельств он прошёл мимо меня, хоть и пару раз мелькал в инфополе. На днях коллега рассказал про этот бенч на кружке чтения статей, и наконец-то моё внимание сфокусировалось на нём 😳
К тому же, от первого автора недавно был популярный пост: The Second Half.
Если коротко — это ПингПонг для агентов, динамический многоходовый бенчмарк. То есть есть разыгрывается какая-то разговорная ситуация, в которой реплики пользователя симулирует языковая модель. Только в ПингПонге ситуации крутятся вокруг отыгрывания разных персонажей, а тут — вокруг агентов и серьёзных корпоративных систем в области розничной торговли (ритейла) и бронирования перелётов
Доступные агентам инструменты включают в себя API для релевантных баз данных. Каждая из предметных областей описывается промптом, в котором объясняется устройство базы данных, как надо надо общаться с пользователями, и какие есть ограничения при взаимодействии с ними.
Пользователи симулируются через системный промт с описанием личности и сценария. При симуляции возможно два типа действий: написать что-то в чат или закончить переписку специальным сообщением "###STOP###". Естественно, симуляция не должна ничего знать о промпте агента или политиках предметной области, то есть не должна подглядывать в промпт агента.
Каждый сценарий предполагает только один правильный исход на базе описания предметной области, которое подаётся агенту, то есть для каждого сценария есть своя эталонная транзакция. Наример, отмена бронирования, оформление возврата посылки, замена товара, и так далее. Чаще всего это какая-то запись в базу данных. Соответственно, переписка считается "успешной" тогда, когда эталонная транзакция была совершена, и об этом корректно сообщили пользователю. При этом в качестве метрики предлагается не стандартный pass@K (=среди K испытаний существует хотя бы одно успешное), а pass^K (=среди K испытаний любое было успешным). Это позволяет оценивать ещё и стабильность моделей и политик.
Сами базы данных с разными продуктами и заказами, а также пользователей и их ситуации авторы делали в полуручном режиме, местами используя gpt-4 для генерации синты.
На полученных данных сравнивали разные модели (сейчас уже все из них древние) и разные парадигмы (function-calling > ReAct > Act). Сами числа уже не очень релевантны, но вот подход до сих пор классный. Единственная серьёзная проблема — это сбор данных: создание базы, написание профилей и сценариев. Но, как несложно догадаться, это тоже можно автоматизировать.
Открытая версия Suno (генератора музыки и песен): https://ace-step.github.io/
Модель: https://huggingface.co/ACE-Step/ACE-Step-v1-3.5B
Код: https://github.com/ace-step/ACE-Step
Поддерживает русский до какой-то степени, на сайте есть пример на нём. По качеству как ранние версии Suno, в принципе довольно хорошо, но косяки всё равно слышны, особенно в вокале.
Circuit Tracing: Revealing Computational Graphs in Language Models
Статья: ссылка
Часть 2
🔹Графы атрибуции (те самые схемы из нулевого поста)
В прошлой части мы остановились на локальных заменяющих моделях, в которых шаблоны внимания зафиксированы, добавлены корректирующие константы, и единственная нелинейность есть только в самих CLT. На эту модель можно смотреть как на большую полносвязную сетку.
Из этой полносвязной сетки делается граф атрибуции. Вершины графа: входные и выходные токены, включенные признаки транскодера (не-нули в разреженном векторе), константы ошибок реконструкции. Веса на рёбрах графа определяются как произведение входных активаций и "виртуальных" весов и отражают степень влияния одних вершин на другие. Однако, так размер графа получается слишком большим, даже учитывая высокую степень разреженности активаций CLT.
Поэтому после этого в этом графе удаляются вершины и рёбра, которые не влияют на выходные токены. Количество вершин уменьшается на порядок, но объясняющая сила падает не очень сильно. Итоговый граф отражает то, как информация движется между вершинами.
🔹Интерпретация признаков
Граф-то мы построили, но что означают вершины мы пока не знаем. Для этого для каждого признака мы собираем набор примеров из какого-нибудь корпуса, на которых этот признак активируется (с указанием конкретного токена), а также статистику по предсказаниям токенов после активации этого признака.
Входные признаки обычно можно интерпретировать на основе токенов промпта. Например, есть признак, который активируется на всём, что связано с цифрой 6. Выходные признаки — на основе предсказанных логитов и тех токенов, которые они заставляют генерировать. Например, есть выходной признак, который продвигает генерацию названий разных видов спорта: футбола, крикета, лякросса.
С признаками промежуточных слоёв сложнее. В их случае надо смотреть на всё-всё, в том числе на признаки с предыдущих слоёв. Например, есть промежуточный признак, который активируется на 3 букве любого акронима в скобках. Иногда разные признаки делают одно и то же, и в таком случае они объединяются авторами в "сверхвершины".
🔹Патчинг
Граф атрибуций позволяет рассуждать о том, как признаки связаны друг с другом и как они влияют на выход модели. Подобные рассуждения можно проверять различными вмешательствами в оригинальную модель, напрямую умножая активации или переставляя их в разреженных векторах внутри CLT и складывая их с выходами оригинальных MLP.
Из-за межслойности CLT по-хорошему это надо делать во всех слоях, которые выше заданного. Авторы так не делают, и применяют вмешательства только на ограниченных диапазонах слоёв.
🔹Оценка качества
Что именно авторы оценивают:
- Замену MLP на CLT: считаем долю верных предсказаний, ошибку реконструкции, разреженность и интерпретируемость через анализ примеров языковой моделькой.
- Графы атрибуции: считаем среднюю длину путей, долю входящих рёбер из "хороших" вершин (а не из вершин констант реконструкции), долю путей через "хорошие" вершины.
- Механистическую верность: убираем или добавляем признаки и считаем эффект на выходы модели. Если реконструированные эффекты совпадают с реальными — наша реконструкция модели хороша.
🔹Заключение
Там ещё осталась секции про глобальные веса и ограничения подхода (только OV-контур без QK, "тёмная материя", фокус на включенных фичах, размер графов), но по-моему они не так принципиальны для понимания 😡
Что нам даёт эта статья с практической точки зрения?
- Эта статья сильно продвигает SAE-подобные подходы в противовес результатам DeepMind.
- Это описание фреймворка, с которым было получено большинство результатов из нулевого поста. Хоть результаты оттуда и не особо новые, но до этого они собирались совершенно разными подходами, а тут всё сделано единым методом. Это даёт надежду, что этим же методом можно получить и новые результаты.
- Хоть код и веса не выложены (только код визуализации), этот фреймворк выглядит принципиально воспроизводимым. А значит в какой-то момент у нас появится прикольный инструмент для картирования языковых моделей 🍫
Qwen3-14B доступен в боте (@saiga_igusev_bot). Выставляется через /setmodel. Прикольно, что оно позволяет в промпте отключать размышления.
Читать полностью…
https://senioraugur.substack.com/p/how-i-taught-ai-to-make-memes
Мини-заметка про мемогенератор на английском по мотивам этого поста.
Там же перевыложил древний пост о новостном агрегаторе для контеста Телеграма.