Новый курс по Agentic AI

Сегодня UC Berkeley стартует бесплатный MOOC курс по агентам.

Страница курса https://agenticai-learning.org/f25 с расписанием.

Каждую неделю новая лекция, квиз на усвоение материала. Вроде бы, даже какие-то домашки, но это не точно.

Ведут лекции рисерчеры из разных топовых лаб. Название первых блоков очень базовое (LLM Agents Overview, LLM with Tool Use, Agent Stack & Infrastructure) и ни о чем не говорит. Посмотрим, какое будет содержание.

Я смотрел несколько лекций предыдущей итерации, писал тут, общий фокус был на reasoning моделях и кодогенерации. Мне понравилось. Планирую активнее смотреть в этот раз и мб выкроить время поучаствовать в хакатоне.

#образование

Сходил на Anthropic London Builder Summit. Как нетрудно догадаться, всё крутилось вокруг Sonnet-4.5 и обновлённого Claude Code, релиз которых состоялся чуть ранее, в понедельник.

По содержанию получилось очень скудно. Большинство докладов просто копия 1 в 1 слайдов с анонса. Но было много людей из продукта и ресёрча Антропика, так что нетворк какой-то да получился!

Для себя из интересного такие моменты выделил:

• Один стенд и часть презентации отвели под Claude Code 2.0 и VS Code-расширение. Мне лично такой подход (интерактивно и с кнопками, как у Cursor) нравится больше, чем полный CLI-минимализм, поэтому показалось полезным. На стенде у ребят местами всё подвисало, а один раз совсем упало. Что оправдывает релиз в стадии беты. Низкий рейтинг в сторе говорит о том же самом.

• Вроде как прокачали визуальную часть модели для кода, и теперь она лучше работает в сценарии «вот тебе фото макета, сделай фронтенд». Живые демки работали стабильно даже на кастомных макетах. По опыту, в 1.x-версиях в one-shot-режиме Claude Code сильно-сильно уступал Lovable (при том что бэкбон-модель одна и та же — Sonnet).

• Большинство технических людей были из Applied AI команды. Это такие разработчики, которые общаются с потенциальными клиентами и делают им пилоты на базе технологий Антропика. AI-консалтинг. Сейчас это очень модная роль, и у всех больших компаний такие команды есть. По разговору с ними можно было понять, насколько они далеки от foundational-команды. На вопросы про eval-ы, сравнения, детали обучения честно говорили, что сами не знают. Всё секретно, даже внутри компании. Что поделать 🙂

• Была панельная дискуссия с несколькими ресёрчерами из core-команды. Все трое на фото. Ответы максимально базовые и скучные. Но один из них проговорился, что экспериментирует с новыми модальностями (речь? звук? картинки?). Подчеркнули большую важность safeguards моделей и довольны, что Антропик ведёт много исследований на эту тему. Снова проехались по Мете и Цукербергу лично, что тот часто пренебрегает моментом с чисткой данных (как минимум от копирайта). Вообще, в Антропике очень много людей ex-Meta.

• Последний доклад софтовый. вопросно-ответная сессия с менеджером одной из команд: «Как выстроить команду от 5 до 50 человек».
1) Нанимаем самых лучших. Hiring Bar на технических сессиях выкручен на максимум и они отдают себе в этом отчет.
2)Нанимаем Problem Solver-ов.

• Интересная мысль была такая: каждый нанятый менеджер сначала начинает как IC, чтобы в деталях понять, как устроена жизнь инженеров.

• На вопрос «Учитываете ли вы в процессе найма навыки человека использовать AI-инструменты?» (логично же, что это важно, для AI компании?) ответ был: НЕТ, НИКАК НЕ УЧИТЫВАЕМ.

Дошли руки прочитать пост про LoRA от Thinking Machines и Джона Шульмана (co-founder OpenAI; у него в личном блоге тоже есть интересные заметки, например, зашла такая: An Opinionated Guide to ML Research).

Главный посыл в том, что LoRA вполне может тягаться по качеству с фулл-файнтюном под новую задачу, если обучать адаптеры правильно:

*датасет для целевой задачи имеет small-to-medium размер;
*у адаптера достаточно ёмкости, и LoRA применяется не только к attention-матрицам, но и к MLP- и MoE-компонентам (в литературе же все еще популярен первый вариант);
*гиперпараметры подобраны корректно, в частности, большой batch size негативно влияет на сходимость;
*RL-тюнинг с LoRA-адаптерами работает так же хорошо, как и фулл-файнтюн.

В 2024 году, когда я ещё работал в Амазоне, мы обучали мультимодальные LLM, которые умели работать с текстом, изображениями и речью. Отдельно стояла задача поэкспериментировать: можно ли адаптировать модель под ситуации, где требуется эффективный файнтюн, чтобы заскейлить модальность. В качестве тестовой выбрали задачу Voice Cloning: есть N минут речи спикера (N варьируется от минут до часов), и хочется научиться клонировать его голос (тембр, интонацию, акцент, просодию). Задача идеальная: есть потенциальная выгода для бизнеса здесь и сейчас( например, озвучивание аудиокниг), а файнтюнить веса базовой модели каждый раз под новый голос — совсем не вариант. Поэтому всем было интересно посмотреть, что получится.

По большому счёту, мы прошли тот же путь экспериментов, что и команда Шульмана: перебирали гиперпараметры обучения, ранги, слои, в которых вставлять адаптеры, и веса, к которым их применять. Выводы сильно коррелировали: большой batch оказывает вредное влияние, а адаптеры нужно применять в первую очередь к FC-слоям трансформера. В итоге получили адаптируемый рецепт под разное количество обучающих данных.

Качество voice cloning оказалось достаточным для прода: реплики были в разы стабильнее, чем zero-shot voice cloning, и не уступали фулл-тюну (бэйзлайн), оставаясь при этом легко масштабируемыми, по крайней мере, с точки зрения ресерча. С точки зрения продакшена же адаптеры не достаются бесплатно (есть эффект на latency, плюс интеграция десятков тысяч адаптеров отдельная инфраструктурная задача). Но это уже другая история.

Успех эксперимента был моментальным и в сентябре того же года начались активные пилоты. Инициативу расширили и наняли отдельную команду, чтобы развивать именно этот продукт. Многих запромоутили или дали хороший бонус.

Также должна была выйти статья, чтобы зафиксировать эффективность метода LoRA для задачи voice cloning. Увы, вот она уже она утонула в потоке бюрократии и более глобальных перестановок в компании.

Последние несколько недель плотно работал с terminal-bench. За названием кроется сразу очень много вещей. Это и бенчмарк, и агент, и фреймворк для создания среды, где эти самые агенты могут работать над задачами.

В этом тексте как раз про последнее - про инструменты для создания среды. Сейчас это еще все называют execution harness.

Что это вообще такое? Допустим, у вас есть набор задач, и вы хотите протестировать какого-нибудь готового агента типа Claude Code или Codex (или даже своего) на то, как он справляется с этими задачами.

Чтобы такое дело провернуть, нужно понаписать немалое количество инфраструктурного кода, чтобы:
а) упаковать ваши подготовленные задачи в среду, где их можно будет изолированно решать (как правило, докер-контейнеры);
b) установить нужных агентов и/или предоставить весь необходимый скаффолдинг (если тестируете своего агента);
с) подготовить отдельную среду, в которой будет запускаться решение агента и как-то оцениваться (например, скрытыми автотестами);
d) ну и наконец, нужно хранить все возможные логи, чтобы потом можно было проанализировать все возможные паттерны;
e) а, и конечно, чтобы все это легко запускалось, каждую задачу можно было перезапускать по N раз и в идеале — легко масштабировалось.

С одной стороны, все это можно реализовать самому. Но это довольно долго и с множеством подводных камней.

Поэтому зачем, когда есть terminal-bench? На мой взгляд, у ребят получился простой, элегантный и масштабируемый фреймворк, который просто работает из коробки в несколько команд. С вас только подготовить все запускалки (докерфайлы для создания окружения и скрипты, как тестировать решение). Каждая задача - то вот такая структур. Подробный гайд есть тут . И реализовать своего агента, если нужно. Либо взять готовые интеграции из коробки - все популярные агенты уже доступны, подставляйте только API-ключи. Можно и их кастомно переделать под себя.

А потом запускаемся:

tb run \
    --dataset terminal-bench-core==head \
    --agent claude-code \
    --task-id hello-world

Все инструменты для отладки тоже есть; ещё и интерактивные сессии реализованы, если хочется симулировать какое-то определённое поведение пользователя при работе с агентом.

По впечатлениям - восторг. От опенсорсных решений давно такого не было. Все нужды, чтобы гонять своих агентов в режиме SWE-Bench задач (есть issue, просим агента сделать, делает, проверяем юнит-тестами) закрывает. Кстати, некоторое количество популярных бенчей тоже интегрировано.

И еще раз: terminal-bench предоставляет среду, чтобы можно было не париться с возней по запуску и логированию. Самое сложное – это подготовить задачи и сценарии. Это уже на вас.

На неделе выступил на Google Developer Group (GDG) митапе c рассказом про Gemini CLI.

Gemini CLI – это ответ гугла на Claude Code. Только все исходники в опенсоурсе.

В течение нескольких недель пытался пользоваться именно этим агентом, чтобы потом поделиться ощущениями с другими разработчиками. На митапе было несколько разработчиков из команды гугла, ждали именно такого фидбэка. рад стараться 🫡

TL;DR: у проекта точно есть потенциал, особенно за счет интересных фич. Лицензия хорошая, Apache 2.0, и хорошо подходит тем, кто делает своих агентов: всё можно переделать под себя, кодовая база не очень сложная. Так как проект в ранней фазе, дают 500 кредитов в день на бесплатное использование. Но это меньше, чем кажется, учитывая, как порой тупит агент и как приходится перезапускать сессии, кредиты сгорают быстро. Для ежедневного использования не рекомендую, слишком сыро.

Выжимка с доклада и общие впечатления такие:

• Gemini CLI стал официально доступен ещё в июле. И тогда им было просто невозможно пользоваться: CLI банально зависал и крашился на любом сценарии.

• На сегодняшний момент вопросы со стабильностью всё ещё не решены, но продуктом можно пользоваться. По эргономике он всё ближе и ближе к Claude Code, который авторы, очевидно, берут за референс.

• Полезность агента во многом измеряется качеством ллм, которая оркестрирует его действия. Как несложно догадаться, в агенте от гугла доступны только модели Gemini, конкретно Pro 2.5 и Flash. Последняя абсолютно бесполезная, и любую задачу приходится править по 2–3 раза. Pro-вариант заметно лучше и может генерировать адекватный рабочий код one-shot-ом. К качеству есть вопросы, но это ко всем агентам относится.

• Отдельно хочется упомянуть веб-разработку. Мне нравится делать тесты на парах вида: (картинка с референсным стилем фронтенда, промпт с конкретной инструкцией как нужно организовать веб страницу). Получается style-transfer задача, где нужно и придерживаться инструкции, и учитывать стиль. Вот тут Гемини просто ломается и не способен адекватно копировать стиль. Самый лучший в моих экспериментах это Codex: буквально в one-shot режиме выдаёт красивые визуалы и придерживается инструкции. Claude Code где-то посередине, тоже не очень круто.

• Так как модель не самая крутая, авторы делают фокус на профессиональных разработчиках и добавляют в начинку фичи, которые повышают производительность. Чтобы вообще не нужно было переключаться между вкладками и проводить всё время в окне с Гемини. Из полезного:

- Можно запускать агента в --sandbox режиме, когда он исполняется в отдельном докер-контейнере без возможности испортить локальные файлы.
-Можно переходить в shell mode, чтобы исполнять терминальные команды.
- Есть опция делать snapshot-ы, чтобы откатывать историю изменений прямо в агенте без явного использования гит-команд.
- Отдельно уделили внимание командам для работы с памятью: можно сжимать контекст, подгружать новые инструкции на лету, не правя GEMINI.md.

- Все эти продвинутые фичи в разной степени забагованности и работают не всегда интуитивно. А ещё некоторые выпиливаются между релизами 😄

- Тот факт, что агент опенсорсный, позволяет заглянуть в архитектурные решения и подсмотреть детали. Монорепа состоит из двух независимых частей: CLI UI для интерфейса и Core/ для tools, логики агента и API к Gemini. В целом добавлять свои built-in инструменты несложно, и можно переписать system prompt под себя. Поэтому, если вы разрабатываете своего агента, это может быть хорошим стартом.

Типы вопросов на собеседованиях про Трансформеры.

Один из первых постов на канале был про виды кодинг раундов для ML позиций совсем по верхам.

Так как я сам неоднократно проводил такие секции в роли интервьюера, а в начале года еще и активно собеседовался, то решил собрать новый текст на эту тему на основе личного опыта, опыта знакомых и историй читателей, которые уже есть на канале (ищите по тегу #интервью). Такие дисклеймеры делают текст сугубо субъективным и на полноту не претендуют.

В этот раз будет про темы вопросов.
Сюрприз-сюрприз, но почти всегда все сводится к работе с авторегриссонными трансформерами.

Тема 1. Предобработка данных.

Самые далекие от непосредственной работы с моделями вопросы. Такие чаще встречаются у ML SWE или ML Ops-ов (у самих же моделистов это наверняка спросят в теории) и заключатся они в том, чтобы реализовать какой-нибудь алгоритм или пайплайн обработки данных. Например, токенизация текста с помощью BPE.

BPE довольно интуитивен и красив, но реализация требует определенных манипуляций со словарями, списками, обработкой краевых случаев. Посмотреть подробнейший гайд с питонвоской реализацией можно у нашего любимого Andrej Karpathy

Тема 2. Реализация механизма self-attention

Может показаться удивительным, но вопрос "напишите на numpy классический self attention" успешно мигрировал из 2021-2022 (тогда их массово адоптировали) в 2025. При чем иногда даже без изменений. Еще более удивительно, что писать его научились далеко не все и огромное количество кандидатов не всегда могут написать и vanilla вариант.

На самом деле, какой бы простой не была задача, реализованный код - это просто повод к дискуссии. И даже в классической версии всплывает множество вещей, где можно копать: 1) а какой смысл нормировать QK на корень из размерности векторов? 2) а как сделать softmax стабильным 3) а как посчитать Q,K,V с помощью одной матричной операции, ...

Так что готовиться нужно не столько к задаче, сколько к хорошему пониманию каждого кусочка архитектуры. Дьявол всегда в деталях.

Тема 3. Сэмплинг токенов

Greedy Decoding - это хорошо, но нужен только для дебага. На практике используют вероятностные методы, вот и интервьюеры придумали спрашивать другие стратегии сэмплинга. Самый частый сейчас, на моей памяти, это top p. Хорошее референсое решение можно посмотреть тут (на сайте вообще бездонное количество крутых текстов)

Опять же, тут поможет уверенное владение матричными фрейморками (торч, numpy, jax), чтобы быть готовым к любой вариации. И чтобы экзотика типа min p не казалось странной.

Тема 4. Inference Loop

Эта секция на то, чтобы уверенно взаимодействовать с архитектурой, как с черным ящиком. Тензоры на вход, тензоры на выход, но еще надо хранить кэш, прошлые логиты, чего-нибудь еще. Тут тоже помогает детальное знание архитектуры трансформеров и умение писать это самому.

Порешать похожее можно на neetcod-e тут, и в смежных задачах.

Тема 5. ML Debugging

Довольно новая и загадочная вариация (по концепции) интервью. Ведь дебажить можно что угодно. Вам дают ссылку на ноутбук с кодом какой-нибудь сетки или пайплайном и просят найти в них... разные баги. В такой постановке я встречал подобное один раз, это было в биг тех. Дали код GPT2, в котором было сломано все. Модель начинала выдавать NaN-ы после нескольких итераций обучения. Нужно было поправить и добиться плавного падения лосса. Ну и попутно убеждать интервьюера, что говоришь что-то адекватное. Знакомый вытянул похожий вопрос на смежную тему: модель при инференсе выдает на одних и тех же входах разные ответы, устранить все источники недетерминированности.

Как-то так. Happy Learning!

Gemini 3 Pro доступна в Gemini CLI.

С сегодняшним релизом Gemini 3, тут же релизнули и интеграцию в гугловсокго кодинг агента.

Модель доступна подписчикам Google AI Ultra или тем, кто пользуется через платный API: Gemini API/ Vertex API . Все остальные, включая бесплатных юзеров, могут пока встать в waitlist

В посте с анонсом обращают внимание на такие фичи:
– улучшенные способности в генерации красивых UI-интерфейсов. Старая модель безумно страдала в этом аспекте.
- генерация 3D сцен.Прикрепленное видео из поста с анонсом, довольно впечатляюще
– генерация сложных терминальных команд
– генерация аккуратной документации (Гугл на днях тут еще запустил и Code Wiki, сервис для автоматической документации проектов)
– улучшенный ризонинг, требующий работы одновременно с несколькими файлами (старая модель тоже страдала с этим), помощь в дебаге и способность мониторить логи запущенных сервисов, чтобы диагностировать проблемы

Стал ли агент действительно интереснее и полезнее и насколько крутая модель скоро увидим. По тем скудным кодинг бенчмаркам что представлены (terminal bench, SWE Bench, livecodebench) модель не на голову выше других гигантов.

Неожиданно увидеть рекламу JetBrains в метро

Мб пригодится начинающим стартаперам:

http://yandex.ru/aistartup

Критерии участия:

Вы совершеннолетний студент, аспирант, исследователь или предприниматель

Команда от двух человек, и участники готовы уделять проекту 10–15 часов в неделю

Хотите валидировать свои гипотезы и открыты к обратной связи

У вас технологический проект с подтверждёнными гипотезами или прототипом, TRL 3+

В ногу с трендами ждут проекты про AI