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. Кроме того, любопытно, как оно себя поведет поверх моделей, которые уже могут в ризонинг и на более длинных контекстах.
Forwarded from Пресидский залив (ex Надя пробует)
Собирать стиль из случайных покупок - все равно что пытаться составить осмысленное предложение из слов на холодильнике.
По отдельности интересно, но вместе не очень работает😐
Aesty (Antler ‘24) - это Fashion OS: приложение, который помогает собрать стиль из того, что у тебя уже есть, и дополнить его тем, что действительно нужно. Получается связный, логичный гардероб, который работает как система и курируется приложением🎧
В отличие от классических fashion-приложений, Aesty:
- Позволяет примерять и свои вещи, и новые — прямо на себе, в одном образе
- Показывает, что у тебя уже есть в гардеробе и как это сочетать друг с другом
- Строит образы под погоду, стиль и тренды
- Показывает, что действительно стоит докупить — с учетом твоего контекста, а не просто красивой ленты в пинтересте
С первого дня Aesty помогает иначе смотреть на гардероб не как на хаос, а как на стройную, понятную систему😎
⌨️ Лаунч на Product Hunt: https://www.producthunt.com/posts/aesty-your-fashion-os/
будем рады поддержке🤝
🎁 Только для PH:
Инвайт другу = обеим бесплатная примерка
Промокод:PRODUCTHUNT
Лайк, шэир, репост очень привествуются!😎
По отдельности интересно, но вместе не очень работает
Aesty (Antler ‘24) - это Fashion OS: приложение, который помогает собрать стиль из того, что у тебя уже есть, и дополнить его тем, что действительно нужно. Получается связный, логичный гардероб, который работает как система и курируется приложением
В отличие от классических fashion-приложений, Aesty:
- Позволяет примерять и свои вещи, и новые — прямо на себе, в одном образе
- Показывает, что у тебя уже есть в гардеробе и как это сочетать друг с другом
- Строит образы под погоду, стиль и тренды
- Показывает, что действительно стоит докупить — с учетом твоего контекста, а не просто красивой ленты в пинтересте
С первого дня Aesty помогает иначе смотреть на гардероб не как на хаос, а как на стройную, понятную систему
будем рады поддержке
🎁 Только для PH:
Инвайт другу = обеим бесплатная примерка
Промокод:
Лайк, шэир, репост очень привествуются!
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Обе статьи, которые приняли на 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 и бьёт их по всем метрикам в основном за счёт нормальной интеграции картиночной части.
Для этой статьи будет только постер, который будет представлять сам Арьян, но я тоже скорее всего там буду.
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 и бьёт их по всем метрикам в основном за счёт нормальной интеграции картиночной части.
Для этой статьи будет только постер, который будет представлять сам Арьян, но я тоже скорее всего там буду.
На LessWrong поймал очень классный пост: ссылка
Местами ржал в голос, очень увлекательно написано.
Основные утверждения:
1. У Антропиков, оказывается, была статья про ИИ ассистентов через промптинг базовых моделей. В декабре 2021 года, за пару месяцев до InstructGPT. Не то чтобы я эту статью никогда не видел, но я её не читал. И вот промпт из этой статьи неожиданно задал стиль общения для всех последующих ИИ ассистентов. То есть базовую модель заставили имитировать ещё не существующий ChatGPT, из-за чего реальный ChatGPT получился таким, каким получился.
2. Для нормального продолжения текста базовые модели пытаются неявно понять, кто этот текст написал и что это был за человек. Но первые языковые модели, которые прошли через обучение инструкциям, не имели понятия, кого им надо отыгрывать! В корпусах для выравнивания на самом деле никак толком не определялся характер персонажа, "ИИ ассистента", а в текстах предобучения про таких ассистентов не было ни слова. Модели были вынуждены имитировать штуку, о которой они не имели никакого представления, и которая не существовала в их "реальности". Отчасти из-за этого модели можно было так легко джейлбрейкать, потому что нечего было ломать: персонаж "ИИ ассистента" был плохо прописан. Кроме того, когда тексты о ChatGPT попали в интернет, все последующие ассистенты автоматически получили частичку характера ChatGPT.
3. Тесты "безопасности", которые устраивают при больших запусках, отвратительны. Если в них вчитаться, то окажется, что модели ведут себя вполне нормально и адекватно, а ожидаются от них реально злые штуки. Более того, само наличие тестов и их подробное описание делает последующие модели гораздо более небезопасными. То есть AI safety команды крупных игроков раскручивают спираль опасности и исполняют самосбывающееся пророчество.
Мини-утверждения:
1. Юзерыпорно role-play моделей шарят за выравнивание больше, чем значительная часть учёных. Потому что они хотя бы разговаривают с моделью. Как и поехавшие на языковых моделях.
2. Claude 3 Opus — пока что лучшая модель за всё время.
3. Claude Gov — линейка моделей для спецслужб и военных! Вот оно ваше выравнивание...
С большинством утверждений я скорее согласен, очень интересный взгляд на историю моделей.
Местами ржал в голос, очень увлекательно написано.
Основные утверждения:
1. У Антропиков, оказывается, была статья про ИИ ассистентов через промптинг базовых моделей. В декабре 2021 года, за пару месяцев до InstructGPT. Не то чтобы я эту статью никогда не видел, но я её не читал. И вот промпт из этой статьи неожиданно задал стиль общения для всех последующих ИИ ассистентов. То есть базовую модель заставили имитировать ещё не существующий ChatGPT, из-за чего реальный ChatGPT получился таким, каким получился.
2. Для нормального продолжения текста базовые модели пытаются неявно понять, кто этот текст написал и что это был за человек. Но первые языковые модели, которые прошли через обучение инструкциям, не имели понятия, кого им надо отыгрывать! В корпусах для выравнивания на самом деле никак толком не определялся характер персонажа, "ИИ ассистента", а в текстах предобучения про таких ассистентов не было ни слова. Модели были вынуждены имитировать штуку, о которой они не имели никакого представления, и которая не существовала в их "реальности". Отчасти из-за этого модели можно было так легко джейлбрейкать, потому что нечего было ломать: персонаж "ИИ ассистента" был плохо прописан. Кроме того, когда тексты о ChatGPT попали в интернет, все последующие ассистенты автоматически получили частичку характера ChatGPT.
3. Тесты "безопасности", которые устраивают при больших запусках, отвратительны. Если в них вчитаться, то окажется, что модели ведут себя вполне нормально и адекватно, а ожидаются от них реально злые штуки. Более того, само наличие тестов и их подробное описание делает последующие модели гораздо более небезопасными. То есть AI safety команды крупных игроков раскручивают спираль опасности и исполняют самосбывающееся пророчество.
Мини-утверждения:
1. Юзеры
2. Claude 3 Opus — пока что лучшая модель за всё время.
3. Claude Gov — линейка моделей для спецслужб и военных! Вот оно ваше выравнивание...
С большинством утверждений я скорее согласен, очень интересный взгляд на историю моделей.