AI компании продолжают захватывать лондонскую подземку. В этот раз реклама Lovable о простоте вайбкодинга.
Все конечно круто, но только рекламщики явно не учили, что интернет в местном метро вещь довольно редкая, и как правило между станциями не ловит. На ветке Виктория так точно.
Все конечно круто, но только рекламщики явно не учили, что интернет в местном метро вещь довольно редкая, и как правило между станциями не ловит. На ветке Виктория так точно.
3😁48🤣10❤4🆒2🔥1
Forwarded from commit history
Последние пару месяцев я плотно работал над этим релизом, и наконец-то мы выкатываем его в опенсорс!
📟 Встречайте SWE-rebench-V2: самый большой открытый, мультиязычный датасет для обучения кодовых агентов!
Вместе с командой Nebius AI R&D мы построили пайплайн для масштабного сбора задач из реальных GitHub репозиториев и теперь делимся всем с комьюнити. На текущий момент это самый большой и разнообразный открытый датасет подобных задач в мире.
Что внутри:
> 32 000+ задач — на базе реальных issue + готовый Docker-образ.
> 20 языков программирования. Некоторые языки (например, Lua или Clojure) вообще никогда раньше не были покрыты!
> 120 000+ дополнительных задач, собранных на базе реальных PR.
> Качество — задачи отфильтрованы и размечены с помощью ансамбля LLM. Также мы обогатили их метаданными и добавили интерфейсы, которые проверяются в тестах.
Вместе с датасетом мы дропаем техрепорт со всеми деталями нашего пайплайна и прогонами моделей.
📄 Статья и датасет
👾 Наш Discord (мы там онлайн, залетайте с фидбеком и вопросами).
✉️ Пост в X
Если есть любые мысли, идеи, предложения - приходите!
🔁 Буду благодарен за репост и пересылку!
📟 Встречайте SWE-rebench-V2: самый большой открытый, мультиязычный датасет для обучения кодовых агентов!
Вместе с командой Nebius AI R&D мы построили пайплайн для масштабного сбора задач из реальных GitHub репозиториев и теперь делимся всем с комьюнити. На текущий момент это самый большой и разнообразный открытый датасет подобных задач в мире.
Что внутри:
> 32 000+ задач — на базе реальных issue + готовый Docker-образ.
> 20 языков программирования. Некоторые языки (например, Lua или Clojure) вообще никогда раньше не были покрыты!
> 120 000+ дополнительных задач, собранных на базе реальных PR.
> Качество — задачи отфильтрованы и размечены с помощью ансамбля LLM. Также мы обогатили их метаданными и добавили интерфейсы, которые проверяются в тестах.
Вместе с датасетом мы дропаем техрепорт со всеми деталями нашего пайплайна и прогонами моделей.
📄 Статья и датасет
👾 Наш Discord (мы там онлайн, залетайте с фидбеком и вопросами).
✉️ Пост в X
Если есть любые мысли, идеи, предложения - приходите!
🔁 Буду благодарен за репост и пересылку!
3🔥19⚡5❤5👏1🆒1
Сегодня ребята из Nebius релизнули новую версию SWE-rebench-v2.
Большой бенчмарк для оценки способности агентов решать задачи в реальных кодовых базах для разных языков программирования.
Видно, что ребята проделали колоссальную работу, чтобы собрать такой датасет. Поддержите лайком на HF Papers, чтобы больше людей знали про хорошую статью!
И отдельно порекомендую канал Ибрагима, автора статьи. Все про кодинговых агентов, крутые технические заметки, карьера в рисерче и наблюдения из жизни!
Большой бенчмарк для оценки способности агентов решать задачи в реальных кодовых базах для разных языков программирования.
Видно, что ребята проделали колоссальную работу, чтобы собрать такой датасет. Поддержите лайком на HF Papers, чтобы больше людей знали про хорошую статью!
И отдельно порекомендую канал Ибрагима, автора статьи. Все про кодинговых агентов, крутые технические заметки, карьера в рисерче и наблюдения из жизни!
20👍21🔥5⚡4❤3🆒1
Столкнулся недавно с тем, что перформанс популярных кодинговых агентов на внутренних бенчмарках, может значимо скакать (3-7%) в зависимости от времени суток и нагрузки на провайдера.
Дело в том, что в пиковые часы агенты могут медленнее генерировать решения из-за большого трафика. Особенно сильно у меня проседал Claude Code. Как результат, наблюдал всплеск AgentTimeoutError при прогонах автономных бенчей.
Единственного решения такой проблемы нет, есть только много вариантов с своими нюансами. 1) Ограничивать не время, а доступный бюджет на задачу 2) Увеличивать время на выполнение задачи на основе прошлых прогонов 3) Ловить пики и запускать бенчи только когда нет высокого трафика. И еще много-много эвристик. Все решения по-своему плохи, когда у тебя весь продукт про эвалы, но это уже другой момент.
Интересно было посмотреть, сталкивается ли кто-то еще с подобными проблемами. И из свежего наткнулся на заметку от самих Антропиков – Quantifying infrastructure noise in agentic coding evals. Они делятся в целом своим опытом борьбы с шумом в инфраструктуре.
Конкретно, рассказывают, что отловили неприятный эффект, который сказывался на результатах бенчмарка Terminal Bench.
Kubernetes кластер команды был устроен так, что если агент во время выполнения задачи в изолированной среде, в контейнере, вдруг превышал лимит на гарантированно отведенные ему ресурсы, то контейнер сразу умирал.
У контейнерных рантаймов обычно есть два отдельных параметра на ресурсы: гарантированные ресурсы, которые резервируется заранее, и жёсткий upper bound, при превышении которого контейнер просто убивается. Если выставить их в одно и то же значение (что было сделано у антропиков), то нет запаса на непредвиденные всплески – любое отклонение приведет к OOM контейнера, который в норме спокойно бы дожил до конца задачи.
В общем, они заметили что процент таких ошибок большой (достигает 6% по их графикам) и решили расслабить ограничения, увеличив зазор лимита на ресурсы в 1x, 2x, ... 4x и наконец убрав ограничение совсем.
Результаты на картинке снизу. Инфраструктурные ошибки почти ушли, а скоры выросли пропорционально, на 6%. Приятно и полезно.
Отдельно пишут и про другие источники шума, в частности time limit constraints, которые по их опыту влияют на результаты бенчей, но конкретных исследований и замеров не проводили.
Так что да, если релизите модель или бенч, убедитесь, что результаты достоверны и не зависят от шума в инфре, или искусственных ограничений. А то сегодня +2% на бенче может быть SOTA!
Дело в том, что в пиковые часы агенты могут медленнее генерировать решения из-за большого трафика. Особенно сильно у меня проседал Claude Code. Как результат, наблюдал всплеск AgentTimeoutError при прогонах автономных бенчей.
Единственного решения такой проблемы нет, есть только много вариантов с своими нюансами. 1) Ограничивать не время, а доступный бюджет на задачу 2) Увеличивать время на выполнение задачи на основе прошлых прогонов 3) Ловить пики и запускать бенчи только когда нет высокого трафика. И еще много-много эвристик. Все решения по-своему плохи, когда у тебя весь продукт про эвалы, но это уже другой момент.
Интересно было посмотреть, сталкивается ли кто-то еще с подобными проблемами. И из свежего наткнулся на заметку от самих Антропиков – Quantifying infrastructure noise in agentic coding evals. Они делятся в целом своим опытом борьбы с шумом в инфраструктуре.
Конкретно, рассказывают, что отловили неприятный эффект, который сказывался на результатах бенчмарка Terminal Bench.
Kubernetes кластер команды был устроен так, что если агент во время выполнения задачи в изолированной среде, в контейнере, вдруг превышал лимит на гарантированно отведенные ему ресурсы, то контейнер сразу умирал.
У контейнерных рантаймов обычно есть два отдельных параметра на ресурсы: гарантированные ресурсы, которые резервируется заранее, и жёсткий upper bound, при превышении которого контейнер просто убивается. Если выставить их в одно и то же значение (что было сделано у антропиков), то нет запаса на непредвиденные всплески – любое отклонение приведет к OOM контейнера, который в норме спокойно бы дожил до конца задачи.
В общем, они заметили что процент таких ошибок большой (достигает 6% по их графикам) и решили расслабить ограничения, увеличив зазор лимита на ресурсы в 1x, 2x, ... 4x и наконец убрав ограничение совсем.
Результаты на картинке снизу. Инфраструктурные ошибки почти ушли, а скоры выросли пропорционально, на 6%. Приятно и полезно.
Отдельно пишут и про другие источники шума, в частности time limit constraints, которые по их опыту влияют на результаты бенчей, но конкретных исследований и замеров не проводили.
Так что да, если релизите модель или бенч, убедитесь, что результаты достоверны и не зависят от шума в инфре, или искусственных ограничений. А то сегодня +2% на бенче может быть SOTA!
1👍19❤6⚡5🆒1
Андрей @asmekal описал свой опыт собеседований на ML роли за 25 год и скомпилировал мысли в один классный лонгрид:
https://asmekal.github.io/blog/posts/interviews-2025-ml-research-engineer-uk
Тут полезные советы, примеры вопросов и что вообще можно ждать в собесах от стартапов, биг теха и фронтир лаб. Рекомендую почитать, особенно тем, кому актуально!
https://asmekal.github.io/blog/posts/interviews-2025-ml-research-engineer-uk
Тут полезные советы, примеры вопросов и что вообще можно ждать в собесах от стартапов, биг теха и фронтир лаб. Рекомендую почитать, особенно тем, кому актуально!
Andrey Zharkov
ML/Research Engineer interviews 2025
6🔥43👍13❤8⚡3🥰1👌1
Литкод для numpy
В тему к посту выше
Недавно один подписчик пришел за советом. Как готовиться к кодинг раунду, где спрашивают задачки с фокусом на знания фреймфорков с функционалом numpy. Cуть задачи реализовать обозначенную логику через операции над тензорами. Без циклов и явных обращений к каждом элементу, а путем работы с векторами.
Формально, это конечно же никакой ни литкод. Но из-за того что задачи часто могут звучать далекими от жизни, можно сказать, что элемент литкода присутствует. Как правило, решение будет состоять из того, чтобы написать наивное решение с циклами, увидеть какой-то паттерн и найти как это можно свести к существующим операциям над тензорами (слайсы, бродкастинг, паддинг, cumsum, маскирование и так далее).
Пример подобной задачи:
Или чуть более сложная версия (с точки зрения векторных операций):
Такие секции не очень частое явление. Их можно увидеть в стартапах, организованных выходцами из больших лаб, где компании ориентированы на обучение своих моделей. Из того что я слышал, таким подходом пытаются заменить классический литкод про алгоритмы и структуры данных – чем-то более похожим, что делают ML инженеры. Подписчик вытянул подобные вопросы в 2 из 5 процессов с стартапами SF based.
Похоже ли это на ML инженерию в жизни? Частично. Когда-то я и в сам возился с сложными процессингом батчей и без эффективных операций над матрицами все работало крайне медленно; хорошее решение заняло часы (еще до агентской эпохи), много принтов и тестов, чтобы убедиться в правильности. Но в рамках интервью, пока что звучит как какое-то задротство. Классический ML Coding / ML Debugging, который хотя бы про известные кусочки мл архитектур, выглядит более разумно.
Остается важный вопрос. А как готовиться к такого рода задачам? Я не нашел одного хорошего ответа, как прокачивать свои навыки в такой нишевой теме, но вот несколько ссылок и советов:
1. Комфортно чувствовать себя при работе с ключевыми операциями над тензорами. Порешать упражнения из популярного репозитория тут
2. Более структурированный курс с набором упражнений на codechef
3. Платформы-тренажеры с вопросами в стиле интервью: tensorgym, tensortonic, deep-ML
Возможно, в комментарии еще накидают полезных ресурсов!
Кто знает, возможно такой формат адаптируют повсеместно, тогда будем гриндить новый тип литкода!
В тему к посту выше
Недавно один подписчик пришел за советом. Как готовиться к кодинг раунду, где спрашивают задачки с фокусом на знания фреймфорков с функционалом numpy. Cуть задачи реализовать обозначенную логику через операции над тензорами. Без циклов и явных обращений к каждом элементу, а путем работы с векторами.
Формально, это конечно же никакой ни литкод. Но из-за того что задачи часто могут звучать далекими от жизни, можно сказать, что элемент литкода присутствует. Как правило, решение будет состоять из того, чтобы написать наивное решение с циклами, увидеть какой-то паттерн и найти как это можно свести к существующим операциям над тензорами (слайсы, бродкастинг, паддинг, cumsum, маскирование и так далее).
Пример подобной задачи:
Given a binary array mask and a value fill_value, return an array of the same length where each contiguous run of 1s is replaced by its 0-based run id (from left to right), and each 0 is replaced by fill_value.
mask = [0, 0, 1, 1, 0, 0, 1, 1, 1, 0, 1, 0, 1, 1, 1, 1, 0, 1, 0]
fill_value = -1
# output
[-1, -1, 0, 0, -1, -1, 1, 1, 1, -1, 2, -1, 3, 3, 3, 3, -1, 4, -1]
Или чуть более сложная версия (с точки зрения векторных операций):
Given a binary array mask, return an array of the same length where each contiguous run of 1s is replaced by its run length, and each 0 stays 0.
mask = [0, 1, 1, 0, 1, 1, 1, 0, 1]
# output
[0, 2, 2, 0, 3, 3, 3, 0, 1]
Такие секции не очень частое явление. Их можно увидеть в стартапах, организованных выходцами из больших лаб, где компании ориентированы на обучение своих моделей. Из того что я слышал, таким подходом пытаются заменить классический литкод про алгоритмы и структуры данных – чем-то более похожим, что делают ML инженеры. Подписчик вытянул подобные вопросы в 2 из 5 процессов с стартапами SF based.
Похоже ли это на ML инженерию в жизни? Частично. Когда-то я и в сам возился с сложными процессингом батчей и без эффективных операций над матрицами все работало крайне медленно; хорошее решение заняло часы (еще до агентской эпохи), много принтов и тестов, чтобы убедиться в правильности. Но в рамках интервью, пока что звучит как какое-то задротство. Классический ML Coding / ML Debugging, который хотя бы про известные кусочки мл архитектур, выглядит более разумно.
Остается важный вопрос. А как готовиться к такого рода задачам? Я не нашел одного хорошего ответа, как прокачивать свои навыки в такой нишевой теме, но вот несколько ссылок и советов:
1. Комфортно чувствовать себя при работе с ключевыми операциями над тензорами. Порешать упражнения из популярного репозитория тут
2. Более структурированный курс с набором упражнений на codechef
3. Платформы-тренажеры с вопросами в стиле интервью: tensorgym, tensortonic, deep-ML
Возможно, в комментарии еще накидают полезных ресурсов!
Кто знает, возможно такой формат адаптируют повсеместно, тогда будем гриндить новый тип литкода!
10🔥33❤19⚡8👍4🤯2🆒1
Вчера посетил конференцию AI Engineer в Лондоне. Это те самые ребята с классным YouTube-каналом, где публикуют доклады про все возможные темы в AI (посмотреть можно тут). Масштаб мероприятия чуть скромнее, чем в SF, но всё равно очень бодро: куча выступлений, воркшопов, экспо и почти все фронтир лабы.
Несколько впечатлений:
* За локацию большой лайк. Идти по Westminster-у утром одно удовольствие. И сама площадка, Queen Elizabeth II Centre, впечатляет внутри и снаружи – фото 1-3.
* Экспо класс. Дизайн стэндов, их оформление и наполнение – это отдельный вид искусства. Тут и гугл, который предлагает сделать селфи, стилизовать фото с помощью Nano Banana и напечатать персонализированные стикеры, и стэнд в виде лавки с хот-догами от ребят из PostHog. Все компании стараются привлечь внимание и удивить.
* Креативность ребят из ElevenLabs просто на другом уровне. Они привезли английскую красную телефонную будку, поставили в неё ретро-телефон. Фото 4. Если взять трубку, с тобой заговорит ведущий и предложит пройти викторину, за которую потом можно получить приятные подарки. Как можно догадаться, ведущий – это голосовой агент на движке от компании. Звучит очень натурально, с минимальной задержкой и совсем не раздражает. Автору задумки, Борису (Борис, привет, если читаешь!), Growth Engineer в компании, респект за всю концепцию и реализацию.
* Немного и про более серьезные вещи. Про выступления. Естественно, в каждом докладе говорят про агентов, но в зависимости от специфики компании фокусируются на своей нише: Modal и RunPod продают облачные вычисления, SnorkelAI – RL-среды фронтир-лабораториям для обучения агентов, Braintrust – observability агентских логов. А кто-то продает и самих агентов. Интересно, что во всех докладах делается акцент на бенчмарках и важности эвалов. До такой степени, что эвалы становятся новой фичей продукта.
* Поэтому когда я пошел на секцию про Kaggle (олды помнят это как крупнейшую площадку для ML-соревнований), то был удивлен, как сильно изменилась платформа. На лендинге теперь красуется слоган «The World's AI Proving Ground», а сам доклад был про релиз новых функций для тестирования агентов. В том числе показали режим Benchmarks: каждый может создать свой бенчмарк и прогнать разные модели.
* Хоть организаторы и обещают, что в докладах минимум рекламы (даже в спонсорских), на практике это реализуется слабо. Были технические воркшопы с хорошей глубиной, про статью или опыт обучения моделей, но те кто следят за индустрией, с высокой долей вероятности уже и так с этим знакомы.
* Нетворк офигенный. На стэндах в основном стоят сэйлзы или продакты, но иногда можно найти и инженеров и здорово поговорить.
Несколько впечатлений:
* За локацию большой лайк. Идти по Westminster-у утром одно удовольствие. И сама площадка, Queen Elizabeth II Centre, впечатляет внутри и снаружи – фото 1-3.
* Экспо класс. Дизайн стэндов, их оформление и наполнение – это отдельный вид искусства. Тут и гугл, который предлагает сделать селфи, стилизовать фото с помощью Nano Banana и напечатать персонализированные стикеры, и стэнд в виде лавки с хот-догами от ребят из PostHog. Все компании стараются привлечь внимание и удивить.
* Креативность ребят из ElevenLabs просто на другом уровне. Они привезли английскую красную телефонную будку, поставили в неё ретро-телефон. Фото 4. Если взять трубку, с тобой заговорит ведущий и предложит пройти викторину, за которую потом можно получить приятные подарки. Как можно догадаться, ведущий – это голосовой агент на движке от компании. Звучит очень натурально, с минимальной задержкой и совсем не раздражает. Автору задумки, Борису (Борис, привет, если читаешь!), Growth Engineer в компании, респект за всю концепцию и реализацию.
* Немного и про более серьезные вещи. Про выступления. Естественно, в каждом докладе говорят про агентов, но в зависимости от специфики компании фокусируются на своей нише: Modal и RunPod продают облачные вычисления, SnorkelAI – RL-среды фронтир-лабораториям для обучения агентов, Braintrust – observability агентских логов. А кто-то продает и самих агентов. Интересно, что во всех докладах делается акцент на бенчмарках и важности эвалов. До такой степени, что эвалы становятся новой фичей продукта.
* Поэтому когда я пошел на секцию про Kaggle (олды помнят это как крупнейшую площадку для ML-соревнований), то был удивлен, как сильно изменилась платформа. На лендинге теперь красуется слоган «The World's AI Proving Ground», а сам доклад был про релиз новых функций для тестирования агентов. В том числе показали режим Benchmarks: каждый может создать свой бенчмарк и прогнать разные модели.
* Хоть организаторы и обещают, что в докладах минимум рекламы (даже в спонсорских), на практике это реализуется слабо. Были технические воркшопы с хорошей глубиной, про статью или опыт обучения моделей, но те кто следят за индустрией, с высокой долей вероятности уже и так с этим знакомы.
* Нетворк офигенный. На стэндах в основном стоят сэйлзы или продакты, но иногда можно найти и инженеров и здорово поговорить.
24🔥34❤12👍4🍓3😁2😱1🦄1
В прошлом году делал пост с подборкой ресурсов для желающих разобраться в деталях RLHF. Одним из ключевых ресурсов была книга довольно уважаемого рисерчера и преподавателя Nathan Lambert.
Сегодня у него вышло обновление. Автор оформил книгу в виде бесплатного мини-курса с видео-лекциями, слайдами и кодом.
Получилось 4 лекции по часу, от введения до математики и реализации.
Лекции на ютубе смотреть тут
Сегодня у него вышло обновление. Автор оформил книгу в виде бесплатного мини-курса с видео-лекциями, слайдами и кодом.
Получилось 4 лекции по часу, от введения до математики и реализации.
Лекции на ютубе смотреть тут
Telegram
max.sh
Подборка ресурсов для изучения RL в контексте LLM
Методы пост-тренировки — RLHF, GRPO, DPO и другие — очень быстро эволюционируют и становятся "повседневным" инструментом ML-инженеров. Это особенно заметно с появлением концепции верифицируемых ревордов (подробнее…
Методы пост-тренировки — RLHF, GRPO, DPO и другие — очень быстро эволюционируют и становятся "повседневным" инструментом ML-инженеров. Это особенно заметно с появлением концепции верифицируемых ревордов (подробнее…
12❤34👍11👏5👾2🔥1
Попробовал свежий Claude Design от 🖥 . Простыми словами – Claude Code для визуала, для дизайнеров, фаундеров, продакт менеджеров, маркетологов и всех-всех, кому нужно что-нибудь презентовать с помощью сладов / моков / питч деков.
Я ни к одной из этих ролей не отношусь. Но слайды мне иногда делать нужно: для технических демо, лекций или презентаций. Мне нравится делать нарратив, и абсолютно ок с мыслью надергать картинок/текста из источника, чтобы сделать повествование. Но вот визуальное оформление – это просто пытка, на которую никогда не хочется тратить время.
Поэтому первый эксперимент, который я провел с Claude Design – это полировка моих слайдов на обзор одной статьи. Слайды оставлю в комментариях, а потом сделаю отдельный пост.
Я создал простейшую презентацию в Google Slides, накидал туда выдержек из текста статьи, с простейшим форматированием, только буллетпоинты, добавил скриншотов и дополнительных подводок, которые мне были нужны. А потом загрузил все в Клода.
Вышло очень приемлемо. В белую простыню текста добавился визуал и приятный вид. Сильно быстрее и лучше, чем если бы я учился делать что-то такое сам.
Более того, можно интерактивно править каждый отдельный слайд или добавлять новый. Достаточно в окне чата просто написать "Добавь после слайда 27 слайд с такой-то картинкой и текстом". Instruction Following отличный! Так же можно легко переделать тему презентации или добавлять интерактивных элементов.
Отдельно понравилось, что после каждого большого изменения Claude Design запускает агента верификатора. Тот делает скриншоты и отлавливает визуальные баги. Работает хорошо, но пока только на простых ситуациях, например, где картинка поехала за пределы слайда или наслоилась на другую.
По итогу опыт очень приятный. Учитывая что это только Research Preview, работает бодро! И мне, как человеку, который не любит тратить время на дизайн, но хочет чтобы иногда было красиво, такой инструмент точно будет помогать.
У меня только один вопрос. Почему такого нет нативно в Google Slides. Учитывая крутую модель для генерации картинок и умную LLM под капотом, почему нет удобного интерфейса чтобы делать такие же слайд деки. Надеюсь, завезут.
Я ни к одной из этих ролей не отношусь. Но слайды мне иногда делать нужно: для технических демо, лекций или презентаций. Мне нравится делать нарратив, и абсолютно ок с мыслью надергать картинок/текста из источника, чтобы сделать повествование. Но вот визуальное оформление – это просто пытка, на которую никогда не хочется тратить время.
Поэтому первый эксперимент, который я провел с Claude Design – это полировка моих слайдов на обзор одной статьи. Слайды оставлю в комментариях, а потом сделаю отдельный пост.
Я создал простейшую презентацию в Google Slides, накидал туда выдержек из текста статьи, с простейшим форматированием, только буллетпоинты, добавил скриншотов и дополнительных подводок, которые мне были нужны. А потом загрузил все в Клода.
Вышло очень приемлемо. В белую простыню текста добавился визуал и приятный вид. Сильно быстрее и лучше, чем если бы я учился делать что-то такое сам.
Более того, можно интерактивно править каждый отдельный слайд или добавлять новый. Достаточно в окне чата просто написать "Добавь после слайда 27 слайд с такой-то картинкой и текстом". Instruction Following отличный! Так же можно легко переделать тему презентации или добавлять интерактивных элементов.
Отдельно понравилось, что после каждого большого изменения Claude Design запускает агента верификатора. Тот делает скриншоты и отлавливает визуальные баги. Работает хорошо, но пока только на простых ситуациях, например, где картинка поехала за пределы слайда или наслоилась на другую.
По итогу опыт очень приятный. Учитывая что это только Research Preview, работает бодро! И мне, как человеку, который не любит тратить время на дизайн, но хочет чтобы иногда было красиво, такой инструмент точно будет помогать.
У меня только один вопрос. Почему такого нет нативно в Google Slides. Учитывая крутую модель для генерации картинок и умную LLM под капотом, почему нет удобного интерфейса чтобы делать такие же слайд деки. Надеюсь, завезут.
Please open Telegram to view this post
VIEW IN TELEGRAM
Anthropic
Introducing Claude Design by Anthropic Labs
Today, we’re launching Claude Design, a new Anthropic Labs product that lets you collaborate with Claude to create polished visual work like designs, prototypes, slides, one-pagers, and more.
10❤21🔥10😁3🤡3👎1🖕1
Есть такая шведская компания Legora. Они делают AI агентов для автоматизации юридических (Law) процессов.
На недавней конференции AI Eng (писал впечатления чуть выше) их CTO выступал с докладом.
Рассказывал, что документооборот и юр. контракты хорошо укладываются в дилемму верификации решений: то есть довольно легко сгенерировать правдоподобное решение (контракт, сделку) c помощью умных моделей, но очень тяжело валидировать его фактическую корректность. Основной способ борьбы с этим – декомпозиция. Legora предлагает юристам редактор, по типу Notion, под капотом которого крутятся агенты и помогают с этой самой разбивкой на более мелкие задачи.
✨ Но пост написан только из-за Джуда Лоу. А точнее из-за рекламной компании Legora с его участием. Ролики сделали мой день (их там несколько)
По-моему, здесь замечательно все, от задумки до исполнения
https://www.youtube.com/watch?v=1oWR_gpR6GY
На недавней конференции AI Eng (писал впечатления чуть выше) их CTO выступал с докладом.
Рассказывал, что документооборот и юр. контракты хорошо укладываются в дилемму верификации решений: то есть довольно легко сгенерировать правдоподобное решение (контракт, сделку) c помощью умных моделей, но очень тяжело валидировать его фактическую корректность. Основной способ борьбы с этим – декомпозиция. Legora предлагает юристам редактор, по типу Notion, под капотом которого крутятся агенты и помогают с этой самой разбивкой на более мелкие задачи.
По-моему, здесь замечательно все, от задумки до исполнения
https://www.youtube.com/watch?v=1oWR_gpR6GY
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Law just got more attractive
Hello. We recently hired Jude Law to be the face of our brand. So, moving forward, we would prefer that you associate him with precise drafting, seamless collaboration and the ability to analyze thousands of legal documents simultaneously. In line with his…
1🤣20😁11❤7👏2
How Well Do Agentic Skills Work in the Wild?
Про скиллы для кодинг агентов не слышал уже наверное только ленивый. Их легко создавать, появляются маркетплейсы, чтобы их было легче распространять и они точно помогают заставить агента учитывать преференции каждого конкретного инженера.
А вот исследований, чтобы численно померить импакт от скиллов, как делать их эвалы (сейчас в вялом режиме пишу статью для воркшопа на KDD, так что может быть будет пополнение) и, самое главное, как улучшать – пока мало. Исследовательская группа из MIT практично копают в эту тему в своей свежей статье
Разберу основные мысли.
Как бенчмаркать скиллы? В коммьюнити сейчас есть один бенчмарк, чтобы мерить полезность скиллов в разных доменах – SkillsBench. Он завирусился в твиттере (но статью на ICML не взяли – недостаточно новизны), авторы собрали людей, получился бенч на ~100 задач в формате Terminal-Bench тасок: есть текстовое описание задачи, докер среда с окружением, набор скиллов которые должны помочь решить задачу и юнит тесты, чтобы проверить. В статье которую разбираем в этом посте авторы делают эксперименты в основном на этом бенче.
Проблема загрузки скиллов в контекстное окно агента. Любой кто брался за создание своего скилла читал гайд Антропиков как писать хороший скилл. Ключевую роль играет поле description – в момент старта агента только это короткое поле с описанием сути скилла будет загружено в контекст модели. Так можно загрузить сотни скиллов и не перегрузить контекстное окно. Целиком же скилл будет загружен только когда модель понимает, что он ей нужен исходя из контекста. Авторы статьи решают симулировать проблему выбора – пусть у агента будут загружены не только релевантные скиллы, но и скиллы дистракторы. Идеальную модель это не смутит и она разберется какой скилл использовать. На практике оказывается, что дистракторы серьезно влияют, перформанс opus 4.6 падает на 8% (первый график, первые 2 столбца)
Почему так происходит? Оказывается все просто. Модель просто не понимает, что ей нужно использовать скилл. То есть даже в идеализированном сетапе, где есть текст задачи + несколько релевантных скиллов – опус реально будет использовать скилл только в 50% случаев (второй график). Все это поправимо – пост-трейн решает.
Представим недалекое будущее. Это такое, в котором нет необходимости писать свои скиллы принципе. Ну действительно, нет смысла каждому писать свой для документации к какой-нибудь популярной библиотеке. Гораздо быстрее скачать готовый с маркетплейса. Тогда появляется проблема поиска и ранжирования. Авторы скачали скиллы из маркетплейса skills.sh и сделали из него индекс. Теперь протестировали агента на решении задач в двух сетапах: в одном был доступ к индексу с заведомо нужными скиллами, во втором только к индексу. результаты естественно просели еще сильнее, у опуса на 20% (первый график, столбцы 3 и 4).
Как улучшить свой скилл? Это вполне себе резонынй вопрос. Одна стратегия, это просить агента-валидатора как-нибудь его переписать: учитывать гайды антропика, смерджить несколько – короче self-improvement loop. Чтобы померить эффект авторы добавляют еще один бенчмарк – Terminal-Bench 2.0. Ретривят к каждой задаче релевантные скиллы (по мнению ретривера), применяют к ним оптимайзер, и дальше решают задачу с учетом доступа теперь к скиллам. Оптимайзер имеет доступ только к тексту скиллов. Бонусов от такого как правило не наблюдается. Иными словами, не получается улучшить скилл только на основе каких-то чисто синтетических рассуждений.
Другой способ улучшить скилл – это дать агенту доступ к тексту задаче и среде, где он может ее решать – но без доступа к фидбэку о том, правильно ли агент ее решил. В этом случае это тоже self-improvement loop, но теперь есть сама задача, а самое главное возможность попытаться ее решить. Такой оптимайзер часто решает смерджить скиллы или переписать description. От такого оптимайзера толку уже сильно больше и он дает значимые бусты почти во всех сетапах. Но при этом создается, конечно, немного читерская ситуация – все-таки агент видел текст задачи.
Про скиллы для кодинг агентов не слышал уже наверное только ленивый. Их легко создавать, появляются маркетплейсы, чтобы их было легче распространять и они точно помогают заставить агента учитывать преференции каждого конкретного инженера.
А вот исследований, чтобы численно померить импакт от скиллов, как делать их эвалы (сейчас в вялом режиме пишу статью для воркшопа на KDD, так что может быть будет пополнение) и, самое главное, как улучшать – пока мало. Исследовательская группа из MIT практично копают в эту тему в своей свежей статье
Разберу основные мысли.
Как бенчмаркать скиллы? В коммьюнити сейчас есть один бенчмарк, чтобы мерить полезность скиллов в разных доменах – SkillsBench. Он завирусился в твиттере (но статью на ICML не взяли – недостаточно новизны), авторы собрали людей, получился бенч на ~100 задач в формате Terminal-Bench тасок: есть текстовое описание задачи, докер среда с окружением, набор скиллов которые должны помочь решить задачу и юнит тесты, чтобы проверить. В статье которую разбираем в этом посте авторы делают эксперименты в основном на этом бенче.
Проблема загрузки скиллов в контекстное окно агента. Любой кто брался за создание своего скилла читал гайд Антропиков как писать хороший скилл. Ключевую роль играет поле description – в момент старта агента только это короткое поле с описанием сути скилла будет загружено в контекст модели. Так можно загрузить сотни скиллов и не перегрузить контекстное окно. Целиком же скилл будет загружен только когда модель понимает, что он ей нужен исходя из контекста. Авторы статьи решают симулировать проблему выбора – пусть у агента будут загружены не только релевантные скиллы, но и скиллы дистракторы. Идеальную модель это не смутит и она разберется какой скилл использовать. На практике оказывается, что дистракторы серьезно влияют, перформанс opus 4.6 падает на 8% (первый график, первые 2 столбца)
Почему так происходит? Оказывается все просто. Модель просто не понимает, что ей нужно использовать скилл. То есть даже в идеализированном сетапе, где есть текст задачи + несколько релевантных скиллов – опус реально будет использовать скилл только в 50% случаев (второй график). Все это поправимо – пост-трейн решает.
Представим недалекое будущее. Это такое, в котором нет необходимости писать свои скиллы принципе. Ну действительно, нет смысла каждому писать свой для документации к какой-нибудь популярной библиотеке. Гораздо быстрее скачать готовый с маркетплейса. Тогда появляется проблема поиска и ранжирования. Авторы скачали скиллы из маркетплейса skills.sh и сделали из него индекс. Теперь протестировали агента на решении задач в двух сетапах: в одном был доступ к индексу с заведомо нужными скиллами, во втором только к индексу. результаты естественно просели еще сильнее, у опуса на 20% (первый график, столбцы 3 и 4).
Как улучшить свой скилл? Это вполне себе резонынй вопрос. Одна стратегия, это просить агента-валидатора как-нибудь его переписать: учитывать гайды антропика, смерджить несколько – короче self-improvement loop. Чтобы померить эффект авторы добавляют еще один бенчмарк – Terminal-Bench 2.0. Ретривят к каждой задаче релевантные скиллы (по мнению ретривера), применяют к ним оптимайзер, и дальше решают задачу с учетом доступа теперь к скиллам. Оптимайзер имеет доступ только к тексту скиллов. Бонусов от такого как правило не наблюдается. Иными словами, не получается улучшить скилл только на основе каких-то чисто синтетических рассуждений.
Другой способ улучшить скилл – это дать агенту доступ к тексту задаче и среде, где он может ее решать – но без доступа к фидбэку о том, правильно ли агент ее решил. В этом случае это тоже self-improvement loop, но теперь есть сама задача, а самое главное возможность попытаться ее решить. Такой оптимайзер часто решает смерджить скиллы или переписать description. От такого оптимайзера толку уже сильно больше и он дает значимые бусты почти во всех сетапах. Но при этом создается, конечно, немного читерская ситуация – все-таки агент видел текст задачи.
3🔥24❤9👍4🐳3🆒1
Вчера стартап Миры Мурати, Thinking Machines, анонсировал новый продукт – Interaction Model: реал-тайм мультимодального голосового ассистента.
Анонс вышел тихим. Выкатили технический блог пост и записали несколько демок (комментарии к видео отключены😁 ) Возможно так тихо, потому что показать пока реально нечего – обещают лимитированное ревью в течение следующих месяцев. Более крупный запуск обещают когда-то в этому году.
В основе нативная мультимодальная модель: обучили с нуля свой трансформер на 276B, на каждом шаге обрабатывает текст+видео+аудио, далее генерирует текст+аудио. Дополнительно есть background модель, которая может делать поиск, чтобы не блокировать главную модель, создавая тем самым эффект риал-тайма.
Демка выглядит слабо. Задержки в ответах даже на предзаписанных демо сильно ощущаются. Голос модели деревянный, как будто взяли старую Алексу из 2017-го.
Работал над похожим еще в свое время в Амазоне. По существу все архитектурные решения были теми же, как и асинхронные бэкгруанд модели, чтобы делать поиск и суммаризировать ответ. Только без видео. Что-то из этого докатилось уже давным давно до прода, Alexa+ дуплексная.
Может и ошибаюсь и оно полетит. Но как будто прошлый большой запуск компании, Tinker, выглядел сильно интереснее. Команда явно ищет нишу и их бросает от инфры для обучения моделей к обучению своих омни моделей. Хотя когда у тебя раунд на 2B$ можно и не такое делать.
Анонс вышел тихим. Выкатили технический блог пост и записали несколько демок (комментарии к видео отключены
В основе нативная мультимодальная модель: обучили с нуля свой трансформер на 276B, на каждом шаге обрабатывает текст+видео+аудио, далее генерирует текст+аудио. Дополнительно есть background модель, которая может делать поиск, чтобы не блокировать главную модель, создавая тем самым эффект риал-тайма.
Демка выглядит слабо. Задержки в ответах даже на предзаписанных демо сильно ощущаются. Голос модели деревянный, как будто взяли старую Алексу из 2017-го.
Работал над похожим еще в свое время в Амазоне. По существу все архитектурные решения были теми же, как и асинхронные бэкгруанд модели, чтобы делать поиск и суммаризировать ответ. Только без видео. Что-то из этого докатилось уже давным давно до прода, Alexa+ дуплексная.
Может и ошибаюсь и оно полетит. Но как будто прошлый большой запуск компании, Tinker, выглядел сильно интереснее. Команда явно ищет нишу и их бросает от инфры для обучения моделей к обучению своих омни моделей. Хотя когда у тебя раунд на 2B$ можно и не такое делать.
Please open Telegram to view this post
VIEW IN TELEGRAM
Thinking Machines Lab
Interaction Models: A Scalable Approach to Human-AI Collaboration
Interaction models move beyond turn-based AI interfaces by handling multimodal, real-time collaboration natively across audio, video, and text.
👍17😴6❤4😁2🤣2⚡1👏1
А вы знали, что в стандартном механизме внимания есть неэффективность?
Она называется attention similarity bias.
Разберемся. В стандартной формуле attention для каждого токена мы считаем query, key и value, затем считаем attention scores: насколько query текущего токена похож на ключи других токенов. После этого агрегируем value векторы с attention-весами и получаем выходной вектор для токена, условный y.
Оказывается, что этот выходной вектор y может быть сильно похож (по cosine similarity) на собственный value вектор токена. И чем глубже слой трансформера, тем сильнее проявляется эффект (Картинка 1).
Этот и называется attention similarity bias.
Его можно интерпретировать как признак того, что часть емкости SA слоя может уходить не совсем туда. Основная роль аттеншена в моделировании контекстных фичей: собирать информацию из других токенов и позиций. А point-wise feature transformation, то есть преобразование признаков самого токена, обычно ожидается от отдельного блока – FFN слоя.
Это может сказываться на качестве модели, как минимум на language modeling способностях. Особенно в маленьких моделях, где каждый вес важен.
Фикс такого “бага” технически оказывается простым: нужно убрать из выходного вектора y проекцию собственного value вектора. В реализации это несколько строк (Картинка 2).
Такая модификация красиво называется XSA (Exclusive Self-Attention) И, судя по экспериментам, действительно помогает на маленьких моделях. На размерах 0.7B – 2.7B XSA приводил к более низкому train/val loss по сравнению с обычным аттеншном (Картинка 3).
Как это обобщается на сильно большие модели и конкретные downstream-задачи – отдельный открытый вопрос. Возможно, на больших масштабах эффект будет меньше из-за огромного числа параметров.
Работу сделал исследователь из Apple. Статья, реализация, эксперименты и сам эффект на маленьких моделях для задачи Next Token Prediction можно посмотреть здесь. А сделал он это все в рамках конкусра от OpenAI – Parameter Golf (правило одно:
#статья
Она называется attention similarity bias.
Разберемся. В стандартной формуле attention для каждого токена мы считаем query, key и value, затем считаем attention scores: насколько query текущего токена похож на ключи других токенов. После этого агрегируем value векторы с attention-весами и получаем выходной вектор для токена, условный y.
Оказывается, что этот выходной вектор y может быть сильно похож (по cosine similarity) на собственный value вектор токена. И чем глубже слой трансформера, тем сильнее проявляется эффект (Картинка 1).
Этот и называется attention similarity bias.
Его можно интерпретировать как признак того, что часть емкости SA слоя может уходить не совсем туда. Основная роль аттеншена в моделировании контекстных фичей: собирать информацию из других токенов и позиций. А point-wise feature transformation, то есть преобразование признаков самого токена, обычно ожидается от отдельного блока – FFN слоя.
Это может сказываться на качестве модели, как минимум на language modeling способностях. Особенно в маленьких моделях, где каждый вес важен.
Фикс такого “бага” технически оказывается простым: нужно убрать из выходного вектора y проекцию собственного value вектора. В реализации это несколько строк (Картинка 2).
Такая модификация красиво называется XSA (Exclusive Self-Attention) И, судя по экспериментам, действительно помогает на маленьких моделях. На размерах 0.7B – 2.7B XSA приводил к более низкому train/val loss по сравнению с обычным аттеншном (Картинка 3).
Как это обобщается на сильно большие модели и конкретные downstream-задачи – отдельный открытый вопрос. Возможно, на больших масштабах эффект будет меньше из-за огромного числа параметров.
Работу сделал исследователь из Apple. Статья, реализация, эксперименты и сам эффект на маленьких моделях для задачи Next Token Prediction можно посмотреть здесь. А сделал он это все в рамках конкусра от OpenAI – Parameter Golf (правило одно:
Train the smallest LM you can that fits in 16MB. Best model wins!). Судя по лидерборду, многие решения используют этот подход.#статья
4👍30❤16🔥9⚡2👏1
Реклама AI инструментов продолжает захватывать Лондонскую подземку.
В коллекцию к JetBrains и Lovable добавляется Vercel
Если первые две компании точно все знают, то Vercel не такой очевидный (ну или мне так кажется). Они делают тулы для быстрого/безопасного деплоя веб приложений. Отмечу что действительно очень удобно и круто (Next.js тоже был разработан ими).
Сейчас ударились в агентов и предлагают какие-то автоматизации. По иронии, интернета на ветки Виктории все так же нет, а потому и посмотреть что же они там рекламируют сразу не выходит
В коллекцию к JetBrains и Lovable добавляется Vercel
Если первые две компании точно все знают, то Vercel не такой очевидный (ну или мне так кажется). Они делают тулы для быстрого/безопасного деплоя веб приложений. Отмечу что действительно очень удобно и круто (Next.js тоже был разработан ими).
Сейчас ударились в агентов и предлагают какие-то автоматизации. По иронии, интернета на ветки Виктории все так же нет, а потому и посмотреть что же они там рекламируют сразу не выходит
😁13❤3🤣2👍1🔥1