Forwarded from Борис опять
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(нормальный код!!!)
Guard модели работают модераторами для LLM: ловят джейлбрейки, атаки и нарушения правил. Раньше их тестировали либо на токсичных промптах (HarmfulQA, HarmBench), либо на джейлбрейках (AART), либо на тайминге. Каждый из этих подходов измерял какой-то аспект guard модели, но не её практическую полезность.
В новом бенчмарке авторы составили таксономию вредных запросов и смотрят: что модели блокируют, что пропускают и насколько быстро обрабатывают запросы. Интересно, что метрика комбинированная, а не просто accuracy, как обычно делается. В реальном проде false positive могут убить UX, а false negative компанию. Accuracy или даже какой-нибудь f1-score сами по себе не оценивают практическую полезность модели для работы в проде. Они показывают только качество в идеальных условиях неограниченного времени.
В CircleGuardBench авторы ввели комбинированный скор, который взвешивает несколько метрик и добавляет штрафы за время ответа и наличие ошибок.
Они так же написали прикольный пост на HF: рассказывают не только про цифры, но и про то, как дизайнили и собирали бенчмарк. Мастрид про безопаспость LLM.
Ждём теперь бенчмарк для атакующих моделей, которые взламывают guard-модели, которые защищают базовые модели.
- Блог на huggingface
- Тред в X
- Лидерборд
- Код на github
τ-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). Сами числа уже не очень релевантны, но вот подход до сих пор классный. Единственная серьёзная проблема — это сбор данных: создание базы, написание профилей и сценариев. Но, как несложно догадаться, это тоже можно автоматизировать.
Статья: ссылка
Код: ссылка
Вообще-то Тау-бенч — штука известная. Каким-то странным стечением обстоятельств он прошёл мимо меня, хоть и пару раз мелькал в инфополе. На днях коллега рассказал про этот бенч на кружке чтения статей, и наконец-то моё внимание сфокусировалось на нём
К тому же, от первого автора недавно был популярный пост: The Second Half.
Если коротко — это ПингПонг для агентов, динамический многоходовый бенчмарк. То есть есть разыгрывается какая-то разговорная ситуация, в которой реплики пользователя симулирует языковая модель. Только в ПингПонге ситуации крутятся вокруг отыгрывания разных персонажей, а тут — вокруг агентов и серьёзных корпоративных систем в области розничной торговли (ритейла) и бронирования перелётов
Доступные агентам инструменты включают в себя API для релевантных баз данных. Каждая из предметных областей описывается промптом, в котором объясняется устройство базы данных, как надо надо общаться с пользователями, и какие есть ограничения при взаимодействии с ними.
Пользователи симулируются через системный промт с описанием личности и сценария. При симуляции возможно два типа действий: написать что-то в чат или закончить переписку специальным сообщением "###STOP###". Естественно, симуляция не должна ничего знать о промпте агента или политиках предметной области, то есть не должна подглядывать в промпт агента.
Каждый сценарий предполагает только один правильный исход на базе описания предметной области, которое подаётся агенту, то есть для каждого сценария есть своя эталонная транзакция. Наример, отмена бронирования, оформление возврата посылки, замена товара, и так далее. Чаще всего это какая-то запись в базу данных. Соответственно, переписка считается "успешной" тогда, когда эталонная транзакция была совершена, и об этом корректно сообщили пользователю. При этом в качестве метрики предлагается не стандартный pass@K (=среди K испытаний существует хотя бы одно успешное), а pass^K (=среди K испытаний любое было успешным). Это позволяет оценивать ещё и стабильность моделей и политик.
Сами базы данных с разными продуктами и заказами, а также пользователей и их ситуации авторы делали в полуручном режиме, местами используя gpt-4 для генерации синты.
На полученных данных сравнивали разные модели (сейчас уже все из них древние) и разные парадигмы (function-calling > ReAct > Act). Сами числа уже не очень релевантны, но вот подход до сих пор классный. Единственная серьёзная проблема — это сбор данных: создание базы, написание профилей и сценариев. Но, как несложно догадаться, это тоже можно автоматизировать.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Daniilak — Канал
DeepWiki — нейросетевой инструмент, который генерирует подробную документацию на основе GitHub-репозиториев. Для доступа достаточно заменить
#сервисы@daniilak
github.com в адресной строке на deepwiki.com#сервисы@daniilak
Например, документация к боту Сайги: https://deepwiki.com/IlyaGusev/saiga_bot
Еду на ACL 2025 с внезапно аж 2 статьями по работе. В обеих я не первый автор (но и не последний). Одна на основной части, одна на индустриальном треке. Как будут тексты в открытом доступе, подробно про них расскажу. Если коротко:
- Первая статья про семантический поиск по отелям от нашего PhD стажёра. В ней мы строим поисковую модель, которая умеет использовать информацию сразу из фоток/рецензий/описания, и у которой хитрый мультизадачный лосс с self-supervised компонентами. В итоге получается эмбеддинг, в котором лежит вся информация об отеле, а также маленькая моделька, которая умеет отображать поисковые запросы в то же пространство, где лежат эмбеддинги отелей.
- Вторая статья (на индустриальном треке) про совмещение Медузы и SeqKD (дистилляции) в применении к нескольким существующим задачам Букинга. Это совместная работа с очень толковыми ребятами из Амазона.
- Первая статья про семантический поиск по отелям от нашего PhD стажёра. В ней мы строим поисковую модель, которая умеет использовать информацию сразу из фоток/рецензий/описания, и у которой хитрый мультизадачный лосс с self-supervised компонентами. В итоге получается эмбеддинг, в котором лежит вся информация об отеле, а также маленькая моделька, которая умеет отображать поисковые запросы в то же пространство, где лежат эмбеддинги отелей.
- Вторая статья (на индустриальном треке) про совмещение Медузы и SeqKD (дистилляции) в применении к нескольким существующим задачам Букинга. Это совместная работа с очень толковыми ребятами из Амазона.
Forwarded from gonzo-обзоры ML статей
[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 функция
AlphaEvolve предоставляет API, куда можно отправить код, где часть требующая улучшения помечена комментариями
Эволюционируемая программа не обязана быть финальным результатом, она может быть средством его достижения. Например, найденное решение может быть просто строкой (как часто бывает в эволюционных алгоритмах); функцией определённого вида, определяющей как должно быть создано решение; уникальным поисковым алгоритмом, могущим найти решение при заданном ограниченном бюджете; или ещё чем-то более сложным. Специфика задачи может влиять на выбор подхода, например, для проблем с очень симметричными решениями авторы советуют выводить функции-конструкторы, они получаются более краткими.
Внутри AlphaEvolve и его эволюционного цикла работают несколько компонентов.
Prompt sampler отвечает за шаблоны промптов, включая системные инструкции, а также вставляет в промпт предыдущие найденные решения, засэмпленные из базы программ. Здесь можно многое произвольно расширять: добавлять явные инструкции от пользователя, стохастическое форматирование с заданными извне распределениями, рендеринг результатов оценки, эволюционировать мета-промпт.
Ансамбль LLM, в статье комбинация Gemini 2.0 Flash и Gemini 2.0 Pro, используется для креативной генерации. Такой микс даёт возможность быстрой генерации множества гипотез через Flash и более качественные рекомендации от более медленной Pro. В целом система model-agnostic, можно использовать разное. LLM просят генерить изменения в коде в виде серии диффов, какой блок кода заменять на какой. Но можно и просить заменять код целиком, если так удобнее.
Evaluation содержит в себе набор оценщиков. В простом случае надо вызывать переданную пользователем функцию
База программ или evolutionary database, хранящая найденные решения и оценки их качества. Здесь важно балансировать exploration и exploitation, так что база реализует алгоритм вдохновлённый комбинацией MAP elites и island-based population models.
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.
Forwarded from gonzo-обзоры ML статей
Всё целиком оформлено как асинхронный пайплайн (спасибо питонячьему
Это в целом всё, система не выглядит суперсложной. По сравнению с прерыдущими 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 это ещё и проще и понятнее.
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 это ещё и проще и понятнее.
Предыдущий пост про это: https://www.group-telegram.com/senior_augur.com/429
Спустя полтора месяца пользования Курсором и исчерпанную fast квоту, я, кажется, с ним смирился. Примерно понял, где он может выдать полную чепуху, с какими штуками он не справится, а с какими справится без проблем.
В больших незнакомых проектах особой альтернативы языковым моделям я не вижу. Можно, конечно, потратить часы на чтение кода и превращение незнакомого проекта в знакомый, но во многих случаях этого не очень-то и хочется, да и нет у меня этих часов.
Для своих пет-проектов, в которых я сам писал весь код, большой пользы от Курсора я не вижу и пользоваться им для них не буду. Это по-моему будет просто вредно для профессиональных навыков
Спустя полтора месяца пользования Курсором и исчерпанную fast квоту, я, кажется, с ним смирился. Примерно понял, где он может выдать полную чепуху, с какими штуками он не справится, а с какими справится без проблем.
В больших незнакомых проектах особой альтернативы языковым моделям я не вижу. Можно, конечно, потратить часы на чтение кода и превращение незнакомого проекта в знакомый, но во многих случаях этого не очень-то и хочется, да и нет у меня этих часов.
Для своих пет-проектов, в которых я сам писал весь код, большой пользы от Курсора я не вижу и пользоваться им для них не буду. Это по-моему будет просто вредно для профессиональных навыков
Не так давно OpenAI и Anthropic выпустили поиск как инструмент.
Документация Anthropic: ссылка
Документация OpenAI: ссылка
До этого я пользовался DuckDuckGo поиском с питонячьей библиотекой. Без прокси это было довольно больно, регулярно попадал на rate limit. Поэтому искал альтернативу.
В качестве альтернативы было несколько платных сервисов, типа SerpAPI. Но цена... 75$ за 5000 поисков, причём только по подписке. И у конкурентов как будто бы не сильно дешевле.
По идее можно было покупать и напрямую у Гугла, но там всё было слишком хитро и результаты тамошнего облачного поиска сильно отличались от основного.
У OpenAI цена 35$ за 1000 поисков, что офигеть как много. У Anthropic сильно лучше: 10$ за 1000 поисков (плюс расходы на токены).
Поэтому в некоторых проектах перешёл на поиск от Антропиков. Например, в боте (@saiga_igusev_bot). Код: ссылка.
Документация Anthropic: ссылка
Документация OpenAI: ссылка
До этого я пользовался DuckDuckGo поиском с питонячьей библиотекой. Без прокси это было довольно больно, регулярно попадал на rate limit. Поэтому искал альтернативу.
В качестве альтернативы было несколько платных сервисов, типа SerpAPI. Но цена... 75$ за 5000 поисков, причём только по подписке. И у конкурентов как будто бы не сильно дешевле.
По идее можно было покупать и напрямую у Гугла, но там всё было слишком хитро и результаты тамошнего облачного поиска сильно отличались от основного.
У OpenAI цена 35$ за 1000 поисков, что офигеть как много. У Anthropic сильно лучше: 10$ за 1000 поисков (плюс расходы на токены).
Поэтому в некоторых проектах перешёл на поиск от Антропиков. Например, в боте (@saiga_igusev_bot). Код: ссылка.
Forwarded from Время Валеры
Анонимусы (без шуток, так и написано в статье) из неуказанной компании (но дальше честно говорится, что это Яндекс) выпустили статью — 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 по таймстемпам, но корректируют его, чтобы в тесте были только те пользователи, что есть в трейне — ближе к продакшену.
В общем, выглядит мощно. Ждём, когда Саша Петров наложит на это свои руки.
Перезалил, с ссылкой на датасет
Собирать и раздавать датасеты — дело богоугодное. Помню, как Женя Макаров на Датафесте в 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 по таймстемпам, но корректируют его, чтобы в тесте были только те пользователи, что есть в трейне — ближе к продакшену.
В общем, выглядит мощно. Ждём, когда Саша Петров наложит на это свои руки.
Перезалил, с ссылкой на датасет
Forwarded from Сиолошная
This media is not supported in your browser
VIEW IN TELEGRAM
Вышла статья и результаты, сайт тут: 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 в реальном времени, успешно проходя начальный уровень и достигая первой встречи с мини-боссом.
Код тут: https://github.com/alexzhang13/VideoGameBench
В целом все модели около нуля, но Gemini 2.5 Pro и Claude 3.7 себя показывают чуть лучше.
Самое обидное, что никакого прогресса в Civilizaiton 1 модели не делают( надо бы заняться вопросом!
На видео: Gemini 2.5 Pro играет в Kirby's Dream Land в реальном времени, успешно проходя начальный уровень и достигая первой встречи с мини-боссом.
Недавно я писал серию постов про новые инструменты для механистической интерпретируемости:
- Основные выводы: https://www.group-telegram.com/senior_augur.com/444
- Детали, часть 1: https://www.group-telegram.com/senior_augur.com/446
- Детали, часть 2: https://www.group-telegram.com/senior_augur.com/447
Ребята, которых финансирует Антропик, выложили в открытый доступ библиотеку для создания графов атрибуции.
Анонс: https://www.anthropic.com/research/open-source-circuit-tracing
Библиотека: https://github.com/safety-research/circuit-tracer
Пример графа на Нейронпедии: ссылка
Графы доступны для Gemma 2 2B и Llama 3.2 1B. Для всего остального нужны самим обучать транскодеры, и эта часть новой библиотекой не покрывается.
- Основные выводы: https://www.group-telegram.com/senior_augur.com/444
- Детали, часть 1: https://www.group-telegram.com/senior_augur.com/446
- Детали, часть 2: https://www.group-telegram.com/senior_augur.com/447
Ребята, которых финансирует Антропик, выложили в открытый доступ библиотеку для создания графов атрибуции.
Анонс: https://www.anthropic.com/research/open-source-circuit-tracing
Библиотека: https://github.com/safety-research/circuit-tracer
Пример графа на Нейронпедии: ссылка
Графы доступны для Gemma 2 2B и Llama 3.2 1B. Для всего остального нужны самим обучать транскодеры, и эта часть новой библиотекой не покрывается.
У HF позавчера начался агентский хакатон: https://huggingface.co/Agents-MCP-Hackathon
Регистрация открыта до 8 июня, тогда же последний день посылок.
Бесплатные кредиты на паре вендоров для всех участников. 3 трека: MCP инструменты в HF Spaces, Gradio UI компоненты, целиковые агенты (тоже в Spaces). 2500$ за первое место в каждом плюс призы от спонсоров.
Регистрация открыта до 8 июня, тогда же последний день посылок.
Бесплатные кредиты на паре вендоров для всех участников. 3 трека: MCP инструменты в HF Spaces, Gradio UI компоненты, целиковые агенты (тоже в Spaces). 2500$ за первое место в каждом плюс призы от спонсоров.
Собственно в рамках хакатона выделили из 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
- Поиск и скачивание статей на ArXiv
- То же самое про ACL Anthology
- Графы цитирований из Semantic Scholar
- Поиск по датасетам в HF
Репо: ссылка
Space: ссылка
В README есть инструкции по подключению к Claude Desktop: ссылка
Скринкасты:
Про одну статью: https://www.youtube.com/watch?v=IAAPMptJ5k8
Про большой отчёт: https://www.youtube.com/watch?v=4bweqQcN6w8
Corrector Sampling in Language Models
Статья: ссылка
Идея о языковых моделях, которые корректируют сами себя, не нова. Я часто такое видел в контексте цепочек рассуждений. В диффузионных моделях это тоже можно делать практически бесплатно, заново маскируя токены. Но вот в авторегрессионных (=обычных) моделях для подобных корректировок нужно очень попотеть.
В этой статье описывается процедура дообучения авторегрессионной языковой модели с небольшими перестановками входов/выходов. Цель этих перестановок — научить модель заново предсказывать предпоследний токен на основании токенов до него и последнего токена. После такого дообучения можно на этапе инференса заново сэмплировать уже сгенерированные токены, по сути проходясь ещё раз по написанному тексту.
При обучении сама архитектура не меняется, добавляется только один слой относительных позиционных эмбеддингов, который кодирует реальное расстояние от выходного токена до входного. Собственно, ещё меняется порядок входных и выходных токенов (чтобы предпоследний токен стал последним, например). Так модель учится работать в двух режимах, а переключаются они позиционной кодировкой расстояний. Если подаётся вектор расстояний (1, 1, ..., 1), то это классическое предсказание следующего токена. Если что-то типа (1, -1, 2, ..., 1), то это в том числе про предсказание предыдущих токенов.
8B модель, 1T токенов. 90% обучения идут одинаково, оставшиеся 10% с фичёй и без фичи. Получившиеся 2 модели сравниваются на всяких бенчмарках про код, с фичёй получается чуть лучше. Даже если ничего не менять при инференсе😐
Трюк прикольный (а нафига бы мне ещё писать этот пост), но... Статья написана так себе, очень много неоднозначностей. Например, одна из эвристик инференса — приёмка по уверенности. И не очень понятно, вероятность какого именно токена имеется в виду, оригинального или нового. Эксперименты на богатом (256 H100). Кода нет💀
Статья: ссылка
Идея о языковых моделях, которые корректируют сами себя, не нова. Я часто такое видел в контексте цепочек рассуждений. В диффузионных моделях это тоже можно делать практически бесплатно, заново маскируя токены. Но вот в авторегрессионных (=обычных) моделях для подобных корректировок нужно очень попотеть.
В этой статье описывается процедура дообучения авторегрессионной языковой модели с небольшими перестановками входов/выходов. Цель этих перестановок — научить модель заново предсказывать предпоследний токен на основании токенов до него и последнего токена. После такого дообучения можно на этапе инференса заново сэмплировать уже сгенерированные токены, по сути проходясь ещё раз по написанному тексту.
При обучении сама архитектура не меняется, добавляется только один слой относительных позиционных эмбеддингов, который кодирует реальное расстояние от выходного токена до входного. Собственно, ещё меняется порядок входных и выходных токенов (чтобы предпоследний токен стал последним, например). Так модель учится работать в двух режимах, а переключаются они позиционной кодировкой расстояний. Если подаётся вектор расстояний (1, 1, ..., 1), то это классическое предсказание следующего токена. Если что-то типа (1, -1, 2, ..., 1), то это в том числе про предсказание предыдущих токенов.
8B модель, 1T токенов. 90% обучения идут одинаково, оставшиеся 10% с фичёй и без фичи. Получившиеся 2 модели сравниваются на всяких бенчмарках про код, с фичёй получается чуть лучше. Даже если ничего не менять при инференсе
Трюк прикольный (а нафига бы мне ещё писать этот пост), но... Статья написана так себе, очень много неоднозначностей. Например, одна из эвристик инференса — приёмка по уверенности. И не очень понятно, вероятность какого именно токена имеется в виду, оригинального или нового. Эксперименты на богатом (256 H100). Кода нет
Please open Telegram to view this post
VIEW IN TELEGRAM
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 и эту статью, я там был, мёд, пиво пил. Следующая статья от него будет про генерацию идей для исследований.
Статья: ссылка
Лендинг: 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 и эту статью, я там был, мёд, пиво пил. Следующая статья от него будет про генерацию идей для исследований.
Please open Telegram to view this post
VIEW IN TELEGRAM
min-p — В С Ё
Обожаю скандалы, особенно когда они касаются непосредственно меня.
Начало истории: ссылка, там можно полистать чуть вниз
Продолжение: ссылка
Оригинальная статья: ссылка
Новая статья с критикой: ссылка
Если коротко, жил-был человек и придумывал себе прикольные сэмплеры для языковых моделей. Одним из таких был довольно популярный min-p, в котором просто отрезались все токены с вероятностью ниже заданной.
Я с этим сэмплером ознакомился и решил забенчмаркать разные сэмплеры на разных промптах про написание историй и role-play, и с более-менее современной моделью. Результаты отослал человеку, он их позже включил в свою статью про min-p. Статья вышла в топ-15 по оценкам рецензентов на ICLR. Меня добавили в acknowledgements. Все довольны, happy end... Или нет?
Сегодня, листая alphaxiv, я натыкаюсь на статью с критикой оригинальной статьи, где... есть ссылка на тот самый канал, который вы читаете! В разделе 4.3 есть прямая ссылка на пост из этого канала. Часто вы такое видели?
Разбирать по существу я эту статью буду в отдельном посте, а пока просто порадуемся за бесплатную рекламу для меня 🥰
Обожаю скандалы, особенно когда они касаются непосредственно меня.
Начало истории: ссылка, там можно полистать чуть вниз
Продолжение: ссылка
Оригинальная статья: ссылка
Новая статья с критикой: ссылка
Если коротко, жил-был человек и придумывал себе прикольные сэмплеры для языковых моделей. Одним из таких был довольно популярный min-p, в котором просто отрезались все токены с вероятностью ниже заданной.
Я с этим сэмплером ознакомился и решил забенчмаркать разные сэмплеры на разных промптах про написание историй и role-play, и с более-менее современной моделью. Результаты отослал человеку, он их позже включил в свою статью про min-p. Статья вышла в топ-15 по оценкам рецензентов на ICLR. Меня добавили в acknowledgements. Все довольны, happy end... Или нет?
Сегодня, листая alphaxiv, я натыкаюсь на статью с критикой оригинальной статьи, где... есть ссылка на тот самый канал, который вы читаете! В разделе 4.3 есть прямая ссылка на пост из этого канала. Часто вы такое видели?
Разбирать по существу я эту статью буду в отдельном посте, а пока просто порадуемся за бесплатную рекламу для меня 🥰
Разбор по существу начнём с тех частей, которые касаются непосредственно меня, а именно с 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 для других моделей по ошибке. Вот такой там уровень погружения, да.
Она про набор экспериментов, где большая языковая модель (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 для других моделей по ошибке. Вот такой там уровень погружения, да.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from КПД
Multiverse: Your Language Models Secretly Decide How to Parallelize and Merge Generation
[Статья][Код (Page Not Found)][Страница проекта (мое почтение)]
Вряд ли для кого уже будет новостью, что test-time compute scaling значительно улучшает качество моделей на задачах, требующих рассуждений. Причем можно масштабировать, как в длину, так и в ширину. Более того, LLM можно научить (а можно попробовать прямо из коробки) решать задачу от лица нескольких взаимодействующих процессов.
И команда из CMU/Nvidia предложила свой метод (с небольшим дообучением), под названием MulitVerse, где модель динамически переключается между последовательной и параллельной генерацией.
[Статья][Код (Page Not Found)][Страница проекта (мое почтение)]
Вряд ли для кого уже будет новостью, что test-time compute scaling значительно улучшает качество моделей на задачах, требующих рассуждений. Причем можно масштабировать, как в длину, так и в ширину. Более того, LLM можно научить (а можно попробовать прямо из коробки) решать задачу от лица нескольких взаимодействующих процессов.
И команда из CMU/Nvidia предложила свой метод (с небольшим дообучением), под названием MulitVerse, где модель динамически переключается между последовательной и параллельной генерацией.
Forwarded from КПД
Метод
Многие задачи допускают параллелизм. Авторы определяют 2 варианта:
1️⃣ Коллективный. Задача разбивается на независимые подзадачи. Процессы могут независимо решать каждую из них, а в конце результат агрегируется.
2️⃣ Селективный. Есть несколько веток рассуждений - правильные и неправильные. Неправильные отбрасываются.
Анализируя решения задач из s1.1-1k DeepSeek-R1/Gemini 2.0 Flash Thinking авторы обнаруживают что при авторегрессионной генерации многие решения содержат вышеописанные паттерны. Но можно ли генерировать их параллельно? Причем автоматически понимать, когда это нужно.
Могут ли сами LLM распознать что генерируют параллельно? Для валидации данной гипотезу обучают MLP поверх скрытых состояний (где последовательным веткам дается метка 1, а параллельным - 0) перед языковой головой и качество оказывается чуть лучше рандома. Из чего делают вывод, что, мол, не распознают 😩.
Дабы научить модель запускать параллелизм, когда надо, авторы собирают датасет на основе из s1.1-1k (с помощью Gemini 2.5 Pro). Ответы на задачи размечают специальными тегами:
🌐
🌐
🌐
🌐
При входе в блок
Обучение занимает примерно 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. Кроме того, любопытно, как оно себя поведет поверх моделей, которые уже могут в ризонинг и на более длинных контекстах.
Многие задачи допускают параллелизм. Авторы определяют 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. Кроме того, любопытно, как оно себя поведет поверх моделей, которые уже могут в ризонинг и на более длинных контекстах.