max.sh

🏎 Пост для для любителей контестов. Цель конкурса: разработать систему, которая передает поток данных от одного источника нескольким получателям с минимальной задержкой. Добиться низкой задержки в среднем или на медиане можно достаточно стандартными приемами. А вот хардовая часть – сделать так, чтобы на высоких квантилях и под нагрузкой задержка ухудшалась минимально, даже когда растут объем передаваемых данных и количество получателей. В общем оптимизировать P99 (по своему опыту работы с low latency аудио моделями знаю как это тяжело). Конкурс проводит Spectral::Technologies - команда занимается высокочастотным трейдингом (HFT), торгует на рынках по всему миру своими стратегиями. Чтобы чуть лучше дать понять, чем занимаются их инженеры – открыли одну из задач, которую решали сами, в формате соревнования. Из прикольного. Вместе с участниками задачу будет решать и Claude Code. Его решение будет находиться в публичном доступе. Можно использовать как бэйзлайн и источник для вдохновения. Recursive Self-Improvement тема горячая, поэтому хорошая площадка для экспериментов по дизайну таких агентов. Экспертиза по распределенным сетям и прокачанный C++ тоже явно не помешают. Оценивать будут распределение задержки, масштабируемость, корректность и воспроизводимость решения. 🏆 Бонусом хорошие призовые (участие индивидуально): 1 место – 6 000 USD gross 2 место – 3 600 USD gross 3 место – 2 400 USD gross Авторам лучших работ – и не только участникам из топ-3 – предложат сокращенный трек найма на позиции C++ Software Engineer или AI Software Engineer. Платят ребята очень хорошо, вилки публичные (ссылка на блог на codeforces) Дедлайн конкурса – 30 августа, 23:59 GMT+3 Регистрация и доступ к задаче через бота компании – @spectral_challenge_bot

Небольшой анекдот-история, чтобы задать правильный ритм на неделю. А кому и настроение поднять Наблюдал я как-то следующую ситуацию. Была у компании умная модель. И ее через кастомизированные харнессы (system prompts + тулы + конеткст) адаптировали к разным прикладным доменам. Одна из задач была помочь оптмизировать работу фиансовых аналитиков. Техническая команда быстро собрала агентскую обвязку и добавила разных профильных тулов. Среди прочих были и более классические: bash с файловой системой и web_search Чтобы померить качество своего агента, команда взяля набор открытых публичных бенчмарков, которые пересекались с реальными приложениями хотя бы на уровне инструментов. Сделали прогоны. На каждый бенчмарк по 5 попыток решить задачу - все честно и с стат значимостью. Бэйзлайны других агентов/моделей гонять не стали – взяли открытые цифры. Получалась SOTA! На каждом бенчмарке! Где-то 15%, где-то и все 30%. Кто следит за лабами, тот знает всю эту кухню бенчмаксинга. Большие цифры никого не смущали. Был проделан быстрый human expert анализ траекторий агентов на небольшом подмножестве сэмплов из каждого бенчмарка. Все клеилось. Агент просто хорош. Стали готовить презентации, рисовать те самые заветные bar charts, показывая в каком далеком космосе новый агент. Но все-таки бывалых инженеров что-то насторожило. Проделали еще один инженерный анализ. Выяснилось, что один из инструментов, web_search, так мощно работал, что когда агент решал его использовать, то в выдаче регулярно оказывались ссылки на...исходники бенчмарков! либо на гитхаб репозиторий, либо на hugging face, либо куда-то еще. Бенчи то опенсоурсные и все ответы лежат в открытом доступе! Стоит добавить, что не каждый поисковый движок такой сильный, чтобы глубоко индексировать интернет Обнаружить такое было и правда не тривиально (без некоторых проверок на уровне эвала), потому что модель по-умному читерила. Понимала, что нашла ответ, но якобы проверяла себя, сначала «честно» пытаясь решить задачу, используя все валидные инструменты, а при не удаче, просто копируя ответ. Так траектории получались достаточно реалистичными. Презентации свернули. Продакты краснели от негодования. Молодые рисерчеры краснели еще сильнее. Бывалые соколы оправдывали свое призвание бывалых. Баги устранили, определенные веб домены были добавлены в исключения, агенту в системном пропмтпе запретели лазить по некоторым сайтам, а в рубрики валидаторов добавили проверку на рассуждения. Эксперимент был перезапущен. Цифры стали скромнее. SOTA испарилась. Но на некоторых бенчах результаты все равно радовали глаз. Проверйте результаты, вставляйте все возможные проверки, чтобы отловить читерство.

Это я интересно на новое место вышел. Только пришел и сразу переезд в новый офис. Сочный вид на город и центральный вокзал с террасы на крыше. Еще и набор лего подарили. Воспроизведение культовой партии AlphaGo против Lee Sedol, где машина сделала тот самый ход 37. Если кто не смотрел документальный фильм про альфа го, то к просмотру обязательно. Драма уровня праймового Нолана. Некоторые место работы выбирают под впечатлением от увиденного.

Еще одна идея над которой успел поработать перед уходом из стартапа – это AI код ревьюеры. В какой-то момент, как и многие стартапы, мы стали строить свою Software Factory (воркшоп от Курсора, если интересуетесь) с идей того, чтобы 0) cтать настоящей AI Native Dev компанией 1) еще быстрее шипить новый софт 2) продавать это другим. Агентские код ревьюеры – это один из блоков такой фабрики, я и исследовал, какие существуют опции. Полигон для тестов – мои коллеги и их отзывы, исторические PR-ы с ревизиями, чтобы делать офлайн эвалы. Начал я с коробчных решений. На слуху был Code Rabbit, шустрый грейдер, хорошо советовал на уровне файлов, отлавливая очевидный слоп. Но в общем-то на этом и все. Более сложные архитектурные вопросы он полностью игнорировал. Еще одна подобная штука - это Qodo, у них была интеграция с разными агентскими файлами (cursor rules, agents.md), но завести адекватно так и не смог Другое коробочное решение – это Code Review от Claude Code. Вот это было прям хорошо: обшираная кастомизация (REVIEW.md для своих пожеланий, настраиваемые проверки для конкретного репозитория, калибровка severity). Работало правда как будто не обоснованно медленно, иногда ревьюер уходил в долгое изучения репозитория; крошечные изменения могли занимать 30 минут. В итоге очень большой расход токенов + лок ин на модели антропика. Запустить Claude Code + свои скиллы для ревью тоже пробовал, но получалось заметно хуже. В идеале хотелось большего детерминированного контроля, возможности кастомизировать глубину ревью, и конечно поддержать разные модели. В общем по классике - надо писать свое. Но писать c нуля для пилота мне не пришлось. Арсений, автор @partially_unsupervised в марте выложил в опенсоурс nitpicker, и быстро довел его до крайне полезной штуки. Большая мобильность, можно запускать не только на PR, но и просто на репе + интересующих файлах, чтобы мониторить состояние кодовой базы. Быстро я приблизился к качеству ревью от антропиков за счет запусков нескольких nitpicker-ов под разные цели, сделав при этом заметно быстрее. По итогу всех экспериментов на живых PR-ах получилась система с высокой полнотой. Ревьюер регулярно предлагал правки, которые разработчики считали полезными. Но на одно хорошее срабатывание приходилось много ложных, такой шум регулярно раздражал кожаных ревьюеров. Что из моих поделок доехало до продукта уже не знаю, но Tessl недавно выпустил Tessl Agent, первая версия фабрики. В мире Loop Engineering-а, где агент сам занимается эволюцией кодовой базы human review уже не имеет значения. А вот возможны ли такие фабрики в принципе – вопрос открытый. Среди стартаперов уже есть хайповые скептики. Посмотрите свежий доклад Harness Engineering is not Enough: Why Software Factories Fail если интересно.

https://m.youtube.com/watch?v=gFx-NjTw3sM Для чего еще нужен AI, если не для этого И правда Claude’s plan

Начинаю рассказывать, что интересного получилось поделать в свой финальный отрезок работы в стартапе. И начну с статьи. Почитать можно тут. Из приятного, ее недавно приняли на KDD – такая конфа с фокусом на приложения ML в индустрии, датасеты и эвалы. В этом году пройдет в Корее (что-то на азию всех потянуло, сейчас там проходит ICML). Теперь к сути. К нам часто приходили энтерпрайзы с одними и теми же вопросами: вот есть у меня набор агентских скиллов, а как мне понять, что он вообще что-то делает? насколько он полезный? и что будет, если я заменю одну модель на другую, а скилл оставлю? Мы соорудили многоступенчатый пайплайн генерации эвалов, чтобы отвечать на такие вопросы. Бенчмаркали все компоненты на опенсоурсных скиллах. Так и появилась статья. А именно: берем реальный скилл, генеирурем на основе него реалистичную задачу + набор рубрик, заточенных под Instruction Following (IF). Потом решаем эту задачу целевой моделью + выбранным агентским харнессом в изолированной среде. Дальше измеряем качество решения с помощью рубрик, используя логи агента + решение задачи. Логи в данном случае очень важная штука, так как позволяют ловить какие промежуточные шаги делает агент и делает ли что-то такое, что прямо противоречит скиллу. Померили такой пайплайн на качественных скиллах от больших вендоров (11labs, hugging face, ...) для большого количество моделей, открытх и закрытых + различных размеров. Ключевой результат на картинке к посту. Из основного: • размер модели решает: чем она больше, тем как правило лучше, хорошо видно на семействе всех фронтир лаб • новизна модели тоже решает; более свежая Gemini Flash 3.5 на уровне старой Pro 3.1 • опенсоурс отстает, но местами может быть очень компетитив, взять GLM - по результатам на уровне Сонета (тестил эту модельку в кодинге сам и впечатления очень хорошие; в отличие от Kimi - но кими и на нашем бенче проседает сильно) • Прогнав агента с скиллом и без него можно измерить насколько скилл вообще важен (или модель и без скилла уже действовала как ожидается) Последний пункт особенно полезен на практике. Конкретный пример. HF относительно недавно меняли свой cli - заменив его с huggingface-cli на просто hf. Первый депрекейтят и четко пишут не использовать. Но без скилла модель зачастую упорно выбирает старый вариант. — Будете делать какой-то рисерч про скиллы, буду благодарен, если поцитируете. Если есть ресурсы (токены и люди) вести рисерч в области кодинг агентов и бенчей, буду рад поколабить тоже, напишите в лс) Статья была побочной активностью, как это и бывает в прикладных командах. Но все равно приятно, что наконец-то что-то докатилось до публикации. За последние 4 года 2 мои статьи эпохи работы в Амазоне попали под эмбарго и уже никогда не увидят свет

💼 Career Update. Ухожу из стартапа Расскажу чем занимался последний год и куда двинулся теперь. ⏹️Чуть больше года назад я присоединился к раннему стартапу Tessl (писал тут). Первая идея компании была сделать движок для Spec Driven Development (SDD) и развить вокруг него экосистему: что-то типа нового Github-а, но для спецификаций. Большой раунд ($125M), опытный фаундер, талантливая команда и идеальное время, чтобы очень быстро вырасти, как Cursor / Lovable. ⏹️Реальность оказалась суровее. все реализации SDD былы неповоротливыми, медленными, дорогими и не приносил видимой пользы поверх обычного вайб-кодинга. На похожие грабли наступили и другие стартапы. Для нас пришло время пивота. ⏹️Cледующая идея закрутилась вокруг eval-ов (что такое читать тут). Прицел был на энтерпрайзы. Они входят в эпоху AI и хотят понимать, как агенты перформят именно в их кодовых базах, где можно использовать модель подешевле, и как поддерживать и обновлять агентский контекст. Конкретно, делали SWE Bench on-prem, эвалы Skill-ов, затачивали оркестрацию контекста под репозитории инженерных команд. Пивот попал в больную точку корпоратов. Они сжигают бюджеты под AI тулы без четкого понимания, был ли в этом хоть какой-то толк. Я во всей этой истории придумвал методологии тех самых эвалов (конструировал реалистичные среды, делал инфру и запускал бенчи, замеряя качество разных моделей), а потом рассказывал prospective customers, как всем этим пользоваться. Питч вида: "смотрите, Opus хорошо решает ваши задачи, но сжигает сумму XXX. А вот если у вас будет набор скиллов и Sonnet с high reasoning effort, то вы сможете урезать расходы вполовину, смотрите, вот скиллы" магически работал на VP и быстро двигал к пилотам. ⏹️Но пилот это часть истории. Далее начинается длинная стадия выстраивания отношений с компанией, постоянное общение на тему, а что мы можем сделать для вас еще? поиск бизнес-кейсов и жесткая борьба с фронтир лабами, которые кардианально улучшают модели каждый месяц. ⏹️И вот эта фундаметнальность, возможность улучшать конкретные модели стала сильно привлекать. По крайней мере, на данном этапе карьеры, когда еще интересно глубоко уйти в технические детали, а не бизнесовые истории. Я начал рассматривать фронтир лабы. В Лондоне они все представлены, но не у всех есть интересные команды с большим импактом на продукт (на данный момент в Европе). ⏹️Привели все эти поиски и общения к тому, что неделю назад завершил свой путь в стартапе и оказался в DeepMind, где буду улучшать Gemini в роли рисерч инженера. ⏹️За последние месяцы в Tessl накопилось несколько интересных тем. О них в ближайших постах. Во-первых, расскажу про небольшой рисерч вокруг эвалов Skill-ов, которым занимался в последний месяц и платформу для code-review. Во-вторых, давно хочется написать серию образовательных материлов про бенчмарки и куда движется мир агентов после SWE Bench-а. Ну и наконец, порекламирую вакансии и возможности в Тессл - если очень нравится активно общаться с клиентами, выступать на митапах и пилить кучу прототипов - точно понравится. У меня от этого опыта только позитивные эмоции. Но сейчас хочется посомтреть как оно там, на фронтире.

⚽️ Чемпионат мира по футболу стартанул и это повод сделать еще один небольшой проект. Так появился GoalStake – площадка, где можно создать турнир, пригласить друзей, выдать всем стартовый капитал игровых монет и соревноваться в прогнозах на исходы матчей, используя реальные вероятности исходов. Весело (потому что играешь с друзьями). Непредсказуемо (потому что чемпионаты всегда такие) Ссылку на проект публично не шейрю, так как: а) этические соображения b) чтобы все это не развалилось под нагрузкой, так как держится на free tier планах 👀. Но если хотите поиграть с друзьями или потыкать сами, то напишите в личку( в описании канала есть мой профиль) или в комментах и скину! ❗️Но вообще пост о другом. Насколько в эпоху вайбкодинга стало просто создавать подобные штуки. На весь проект у меня ушло около 4–5 часов работы с разными агентами. И дело не только в том, что сами агенты стали гораздо сильнее. Вокруг сформировалась целая экосистема инструментов, которые позволяют решать нетривиальные задачи в несколько кликов. О них и поговорим. 🔘 Supabase. Почти любой проект требует баз данных, мой не исключение. Заморачиваться с тем, чтобы поднимать свою, особенно на этапе пилота, как-то слишком. supabase берет часть сложностей на себя, от пользователя только требутеся создать все нужные Postgres таблицы. Кстати, у сервиса кроме облачных БД еще куча развиающихся фишек. Например, прокачанная авторизация (что я тоже попробовал), по почте/телефону/смс - все это можно довольно быстро подключить. Из интересного увидел еще поддержку realtime на базе WebSocket-ов 🔘 Vercel. Тут его и так наверное многие знают. Простой деплой бэкенда/фронтенда. 🔘 Conductor. Теперь о чем-то более агентском. О кондукторе. Ребята делают десктоп приложение, чтобы было удобно оркестрировать работу большого количества агентов. Каждый запускается в своем worktree. Когда я смастерил первую версию с клод кодом, то дальше захотел точечно улучшать определенные куски. Тут кондуктор и пригодился. Я запускал одного агента в задачах на фронтенд, другого на более эффективную работу с БД. А потом ревьюил, что каждый наделал.Так работать было сильно удобнее, чем с кучей терминалов: и распаралелил процесс, и мне ревьюить легче 🔘Agentic Skills. Наконец, мне пригодились подключение скиллов. Я использовал skills.sh, чтобы подключить скиллы для supabase. Свежий Opus 4.8 и так из коробки неплохо работает, но местами использует устаревший API или усложняет подходы. Но зачем все это самоделие, если есть официальные best practises от авторов supabase? Подключил и доволен. Кстати, вот тут большая подборка скиллов от популярных больших компаний. —- UPD 1. Пришло 23 запроса на попробовать, обнаружено 2 не критических бага. Фиксы подъедут когда-то на неделе

🕹 Давно хотел сделать клон старенькой игры Ice Rage, в которую рублися c друзьями в школе на переменах. К сожалению, на свежих iOS в нее уже не поиграть... Но для этого и нужны агенты! Поиграть в браузере можно тут, на телефоне тоже запускается, но с ноута сильно комфортнее. За одно и возможность потестить агентов на реальных Long Horizon Tasks. Длинные автономные сессии агентов один из тренд текущего года. Вместо того чтобы постоянно сидеть рядом и поправлять агента вручную, мы заранее готовим ему среду, даём подробные инструкции и отправляем работать на несколько часов самостоятельно. В такую парадигму укладывается много задач, от научных экспериментов до "Вот тебе CLI на Python перенеси его на Rust" (по такому принципу устроен наследник SWEBench – ProgramBench) Самое важное дать агенту валидироваться, чтобы он понимал, что именно нужно улучшить. Клонирование игры проходило в нескольких cетапах, где каждый следующий был надстройкой над предыдущим. Везде использовал Opus 4.8 с xhigh effort. В каждой попытке агент запускался автономно через`claude -p ...`. Игра делалась под three.js. У агента был доступ к playwright / agentbrowser чтобы смотреть на свой прогресс. ⚫️Сетап 1. Подробная Спецификация. В этой попытке агенту был выдан длинный файл с детальным описанием механик игры, визуала, описание поля, игроков и так далее – все что я сам написал и потом клод со мной расширил. Получилось все совсем плохо: кривой геймплей, персонажи из кубов, сломанная камера и белый шум вместо аудио эффектов (буквально). Не играбельно. Я даже удивился тому, как это было плохо. Особенно учитывая самоуверенность клода в том, что все сделано отлично. ⚫️Сетап 2. Референсы из оригинальной игры. Поняв, что просто инструкций недостаточно, я заменил исходную спеку на вариант, где были описания механики игры + приложены референсные скриншоты/видео с аннотациями того, что происходит на экране. Разметку всю делал сам. Вот тут уже пошел прогресс. Агент стал регулярно делать скриншоты своей поделки и сверяться с референсами. Вышло уже сильно приличнее – в это можно было играть. Отдельно порадовало, что агент пошел искать модельки персонажей в сети и нарыл бесплатные ресурсы. Формально играбельно, но агент во многих аспектах скатывался в "Я вижу, что это сделано не идеально, но поправлю в следующей итерации" и ленился прорабатывать детали. ⚫️Сетап 3. RALPH loop. Довольно известный способ борьбы с ленью агентов — это крутить их в цикле и просить улучшаться. Реализаций может быть великое множество, я выбрал такую: агент получает текущее состояние проекта, улучшает его, сверяет свой результат с референсами и записывает свои наблюдения (в идеале недочеты должен фиксировать независимый агент верификатор). На следующей итерации агент cтартует с точки, где сначала читает что нужно улучшит. Такой подход позволил пофиксить часть визуальных багов, улучшить текстуры, добавить трибуны и фанатов! Каждая следующая итерация становилась короче, а фидбэк все более синтетическим. Всего получилось 5 таких циклов после чего разница перестала чувствоваться. ⚫️Сетап 4. Анимации и эффекты. Квадратные персонажи раздражали, а тишина во время игры убивала весь геймплей. Я запустил отдельного агента с доступом к api 11labs для аудио генерации и segmind.com для 3D моделек. Агент сам нагенерировал релевантных моделей для игры. Правда с анимациями все равно осталось туговато и с этим я уже ничего не делал. ✨ Итоги Вышло играбельно. Механика в местах не такая чувствительная, боты не очень естественные да и визуал бюджетнее. Но порцию ностальгии я словил и с удовольствием поиграл. Фиксить механику без вмешательства в код тяжело, надо играть и калибровать баланс, у агента с чувством плавности жуткие проблемы. А вот допилить визуал, при наличии качественных моделек героев и анимаций (что конечно отдельный челлендж) – это уже дело техники. Удачный запуск, сетап 3 + сетап 4, потребовал 3 часов работы агента. Самая длинная автономная работа одного агента длилась 35 минут.

Хочу поделиться крутым образовательным ресурсом. А именно ссылкой на ютуб канал рисерчера и профессора из университета Мэриленда Jia-Bin Huang (он еще будет себе осенью набирать phd студентов – кому актуально) Здесь можно найти множество интересных разборов из современного DL, а последние видео точечно рассказывают про концепции из архитектур и обучения свежих LLM-ок: - Как устроен оптимизатор Muon - Как дизайнить MoE и разные подводные камни - Линейный аттеншн - Что такое Engram и как он делает трансформеры эффективнее Exclusive Self Attention, или почему стандартный механизм внимания может неэффективно представлять данные, который я разбирал чуть выше, тут тоже есть, да еще и с существенно большим количеством наглядности (и даже с объяснением всей линейной алгебры, которой нет в статье!) Контента у него очень много, рекомендую. Особенно если ведете рисерч, читаете статьи и хочется получить хорошее первое представление о свежей идее (все-таки из самой статьи иногда это сделать довольно трудно – нужно смотреть на предыдущие работы и долго вникать) или сами практикуете обучение моделей, чтобы глубже разбираться как что работает и где можно улучшить.

Реклама AI инструментов продолжает захватывать Лондонскую подземку. В коллекцию к JetBrains и Lovable добавляется Vercel Если первые две компании точно все знают, то Vercel не такой очевидный (ну или мне так кажется). Они делают тулы для быстрого/безопасного деплоя веб приложений. Отмечу что действительно очень удобно и круто (Next.js тоже был разработан ими). Сейчас ударились в агентов и предлагают какие-то автоматизации. По иронии, интернета на ветки Виктории все так же нет, а потому и посмотреть что же они там рекламируют сразу не выходит

А вы знали, что в стандартном механизме внимания есть неэффективность? Она называется 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!). Судя по лидерборду, многие решения используют этот подход. #статья

Вчера стартап Миры Мурати, Thinking Machines, анонсировал новый продукт – Interaction Model: реал-тайм мультимодального голосового ассистента. Анонс вышел тихим. Выкатили технический блог пост и записали несколько демок (комментарии к видео отключены 😁 ) Возможно так тихо, потому что показать пока реально нечего – обещают лимитированное ревью в течение следующих месяцев. Более крупный запуск обещают когда-то в этому году. В основе нативная мультимодальная модель: обучили с нуля свой трансформер на 276B, на каждом шаге обрабатывает текст+видео+аудио, далее генерирует текст+аудио. Дополнительно есть background модель, которая может делать поиск, чтобы не блокировать главную модель, создавая тем самым эффект риал-тайма. Демка выглядит слабо. Задержки в ответах даже на предзаписанных демо сильно ощущаются. Голос модели деревянный, как будто взяли старую Алексу из 2017-го. Работал над похожим еще в свое время в Амазоне. По существу все архитектурные решения были теми же, как и асинхронные бэкгруанд модели, чтобы делать поиск и суммаризировать ответ. Только без видео. Что-то из этого докатилось уже давным давно до прода, Alexa+ дуплексная. Может и ошибаюсь и оно полетит. Но как будто прошлый большой запуск компании, Tinker, выглядел сильно интереснее. Команда явно ищет нишу и их бросает от инфры для обучения моделей к обучению своих омни моделей. Хотя когда у тебя раунд на 2B$ можно и не такое делать.

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. От такого оптимайзера толку уже сильно больше и он дает значимые бусты почти во всех сетапах. Но при этом создается, конечно, немного читерская ситуация – все-таки агент видел текст задачи.

Есть такая шведская компания Legora. Они делают AI агентов для автоматизации юридических (Law) процессов. На недавней конференции AI Eng (писал впечатления чуть выше) их CTO выступал с докладом. Рассказывал, что документооборот и юр. контракты хорошо укладываются в дилемму верификации решений: то есть довольно легко сгенерировать правдоподобное решение (контракт, сделку) c помощью умных моделей, но очень тяжело валидировать его фактическую корректность. Основной способ борьбы с этим – декомпозиция. Legora предлагает юристам редактор, по типу Notion, под капотом которого крутятся агенты и помогают с этой самой разбивкой на более мелкие задачи. ✨ Но пост написан только из-за Джуда Лоу. А точнее из-за рекламной компании Legora с его участием. Ролики сделали мой день (их там несколько) По-моему, здесь замечательно все, от задумки до исполнения https://www.youtube.com/watch?v=1oWR_gpR6GY

Попробовал свежий Claude Design от 🖥. Простыми словами – Claude Code для визуала, для дизайнеров, фаундеров, продакт менеджеров, маркетологов и всех-всех, кому нужно что-нибудь презентовать с помощью сладов / моков / питч деков. Я ни к одной из этих ролей не отношусь. Но слайды мне иногда делать нужно: для технических демо, лекций или презентаций. Мне нравится делать нарратив, и абсолютно ок с мыслью надергать картинок/текста из источника, чтобы сделать повествование. Но вот визуальное оформление – это просто пытка, на которую никогда не хочется тратить время. Поэтому первый эксперимент, который я провел с Claude Design – это полировка моих слайдов на обзор одной статьи. Слайды оставлю в комментариях, а потом сделаю отдельный пост. Я создал простейшую презентацию в Google Slides, накидал туда выдержек из текста статьи, с простейшим форматированием, только буллетпоинты, добавил скриншотов и дополнительных подводок, которые мне были нужны. А потом загрузил все в Клода. Вышло очень приемлемо. В белую простыню текста добавился визуал и приятный вид. Сильно быстрее и лучше, чем если бы я учился делать что-то такое сам. Более того, можно интерактивно править каждый отдельный слайд или добавлять новый. Достаточно в окне чата просто написать "Добавь после слайда 27 слайд с такой-то картинкой и текстом". Instruction Following отличный! Так же можно легко переделать тему презентации или добавлять интерактивных элементов. Отдельно понравилось, что после каждого большого изменения Claude Design запускает агента верификатора. Тот делает скриншоты и отлавливает визуальные баги. Работает хорошо, но пока только на простых ситуациях, например, где картинка поехала за пределы слайда или наслоилась на другую. По итогу опыт очень приятный. Учитывая что это только Research Preview, работает бодро! И мне, как человеку, который не любит тратить время на дизайн, но хочет чтобы иногда было красиво, такой инструмент точно будет помогать. У меня только один вопрос. Почему такого нет нативно в Google Slides. Учитывая крутую модель для генерации картинок и умную LLM под капотом, почему нет удобного интерфейса чтобы делать такие же слайд деки. Надеюсь, завезут.