Стать специалистом по машинному обучению

В этом году уже в третий раз буду гостем Practical ML Conf в Москве. Приглашаю и вас присоединяться. В программе особенно отметил два доклада про инференс. Владислав Носивской, руководитель группы инференса LLM в Yandex AI Studio, разберёт, чем агентский трафик отличается от обычных запросов к моделям. На примере публичных трасс, бенчмарков и опыта Yandex AI Studio он покажет, как снижать стоимость инференса: выбирать схему параллелизма, маршрутизировать запросы с учётом KV-кеша, разделять prefill и decode и использовать спекулятивное декодирование. Александр Мисевич, руководитель Group of Efficient Runtime & Inference в AI Platform & Copilot Т-Банка, посмотрит на ту же задачу шире и расскажет, какие инженерные решения помогают превратить LLM и другие сложные AI-модели в доступный инструмент для бизнеса. Ну, а за что я ещё люблю подобные мероприятия - это нетворкинг. В Москве откроются три оффлайн-зала, в которых можно будет пообщаться с коллегами и поучаствовать в дискуссиях, а для онлайн-участников будет работать зал «Сеть». 19 сентября, Москва + онлайн → Смотреть программу и регистрироваться Реклама. ООО "ЯНДЕКС". ИНН: 7736207543. Erid: 2VtzqvL4A9A

Опираясь на полученный опыт, вот, что могу посоветовать тем, кто задумывается о работе через несколько параллельных сессий. Не давайте им общее рабочее дерево - пусть каждая заводят свой worktree с первого дня. Как выяснилось - это одна команда и git предоставляет возможность из коробки. Пройдитесь по всему, что делится помимо файлов - порты, кэши, папки зависимостей, соседние чекауты, временные файлы с фиксированными именами - и разведите заранее. Относитесь к обходным путям, которые надо помнить, как к долгу с процентами - каждая новая сессия про него не знает и обязательно вляпается. И то, что должно соблюдаться всегда, выносите из инструкций в гард (предохранитель), который не даст сделать неправильно.

Первым выстрелил порт. Браузерные тесты поднимают дев-сервер и ходят в него, а playwright умеет переиспользовать уже запущенный сервер, если на нужном адресе кто-то отвечает. Само по себе это удобно и у меня включено до сих пор. Проблема была в адресе - сервер поднимался на обычном порту разработки, одном и том же для всех чекаутов. И прогон, запущенный из worktree, преспокойно тестировал приложение из главного чекаута, другой ветки. Он сообщил о дефекте, который в этой самой ветке был уже починен. Полчаса ушло на разбор несуществующего бага. Починка стала такой - каждому свой порт, а дев-серверу - флаг --strictPort (это флаг Vite, не Playwright), чтобы занятый порт означал ошибку, а не тихий переход на следующий свободный. Занятый порт должен кричать (сейчас на этом слове вдруг осознал, что понахватался терминологии от агентов, раньше я бы и представить не мог, что закрытый порт может "кричать" :)). Переиспользование при этом осталось, но теперь оно переиспользует только свой собственный сервер на своём собственном порту. Иронично, что через три недели этот же флаг уронил чужой PR. CI у меня живёт на этой же машине, где работают агенты, на своих раннерах, и в какой-то момент чей-то прогон покраснел с сообщением "порт 5174 уже используется" - порт держал локальный прогон одной из сессий. К коду в том PR это не имело ни малейшего отношения. То есть сначала мы сделали порт строгим, а потом обнаружили, что строгий порт без изоляции сам становится источником конфликтов. Развели порты по ролям - для рабочей сессии один, для CI - другой, между двумя своими worktree - задавать явно. Вторым выстрелил путь. Контрактные тесты ищут схемы в соседнем репозитории относительно рабочего каталога, а worktree лежит на уровень глубже обычного чекаута - и путь стал указывать в пустоту. Прогон давал 215 упавших тестов вместо 2191 прошедшего. Ошибка, при этом, сообщала и лечение, но две сотни красных строк повергли агента в шок и он начал преживать, что сломал вообще весь код. Починили тем, что поиск стал подниматься по дереву каталогов вверх, пока не найдёт корень нужного репозитория, а маркером сделали сам файл спецификации, а не имя папки. Иначе пустая папка с подходящим именем, оказавшись ближе, выигрывала бы просто по расстоянию. Третьим выстрелило то, что каталог агента, в котором запускается фоновая команда, - не то состояние, на которое можно рассчитывать в следующей команде. У моего раннера после фоновой задачи каталог переднего плана возвращается туда, где был. Агент запускает длинный прогон в фоне, потом выполняет обычную команду - и правит файлы уже не в своём worktree, а в главном чекауте. Молча, без единой ошибки. Однажды за одну сессию такое случилось трижды. Механика та же, что и в первом инциденте, только виноват уже не сосед, а собственный дрейф. Лечится тем, что каждая команда начинается с перехода в свой worktree, а не только первая в цепочке. И, поскольку такое правило держится исключительно на внимательности, теперь стоит хук, который просто отказывает в записи в главный чекаут репозитория, если у того есть живое второе дерево. Чтение и уборку после мержа он пропускает, всё остальное - нет. Последнее, о чём хочется рассказать про текущий флоу - то, как открываются пулл-реквесты. Агент у меня не открывает их сам, он готовит ветку, коммит и push, а дальше отдаёт мне ссылку на страницу сравнения веток с уже подставленными заголовком и описанием. Я открываю, при желании правлю прямо в форме и жму кнопку. Смысл в том, что создание PR - это точка, где я могу посмотреть на работу глазами перед тем, как она поедет в мастер. Честно признаюсь, что реально ревью я провожу всё реже и реже, больше полагаясь на выросшие вокруг процесса автоматические проверки. Плюс база всегда мастер - отдельное правило, появившееся после того, как GitHub однажды влил PR в другую feature-ветку, которая к тому моменту отстала, и работа просто не доехала.

Первое, что мы сделали - ввели новые правила. Перед созданием ветки смотреть git status, чтобы не унаследовать чужое. Перед каждым коммитом проверять, на какой ветке стоит HEAD. Правила хорошие, они и сейчас в силе. Но по-настоящему проблему они не решают. Между проверкой и действием всегда есть окно. Агент посмотрел git status, увидел чистое дерево, начал работу, а через двадцать минут соседняя сессия сделала свой checkout. Дисциплина уменьшает вероятность, но не устраняет причину, что дерево одно, а писателей несколько. Настоящее решение оказалось встроено в Git и называется worktree. Век живи - век учись, как говорится, даже не знал до этого момента о такой фиче гита.

git worktree add _wt/задача-сессии-N -b ветка-сессии-N origin/master

Она создаёт ещё одно рабочее дерево того же репозитория - в подпапке _wt/задача-сессии-N, с полным набором файлов проекта и, главное, со своим собственным HEAD. При этом никакого второго клона не появляется - история, объекты и все ветки остаются общими, физически одними. Новое дерево знает, где лежат эти общие данные, а они держат запись о каждом живом дереве. Занимает это примерно столько, сколько весят файлы проекта, то есть история не дублируется. При этом переключение ветки в одном дереве больше не может повлиять на другое, потому что HEAD теперь у каждого свой. Каждая сессия сидит в своём каталоге и делает там что хочет. Главный чекаут остаётся стоять на мастере как справочная копия, и его никто не трогает. Несколько практических нюансов, всплывших в процессе работы. Одну и ту же ветку нельзя чекаутить в двух деревьях сразу - Git прямо откажет и назовёт, какое дерево её держит: fatal: 'feature' is already used by worktree at '…'. Запрет можно снять флагом --force, и я специально попробовал, что тогда будет. Получается так. Коммит из первого дерева двигает ветку, второе дерево оказывается на новом коммите, но с файлами старого состояния, и его git status показывает чужой файл как удалённый. Следующий обычный коммит оттуда этот файл действительно удаляет. То есть без запрета вернулась бы та же гонка, только хуже. В исходной истории работа терялась и её можно было достать из коммита, а здесь она отменяется коммитом, который выглядит совершенно законным. То есть изоляция worktree - это про то, что у каждой ветки ровно один писатель. Другой нюанс. Дерево после мержа надо убирать командой git worktree remove, а не просто удалять папку, так как иначе Git продолжит держать служебную запись о нём и считать ветку занятой, пока запись не почистить через git worktree prune - сам он до неё может добраться, но нескоро, там свой TTL (время жизни, срок устаревания). И ещё. В новом дереве нет ничего, чего нет в Git - ни .env, ни установленных зависимостей, ни виртуального окружения. Для питона мы обошлись относительным симлинком на окружение основного чекаута, для веба - общей папкой зависимостей. При этом, отсутствие .env неожиданно оказалось полезным - свежее дерево - это то, что видит CI, и однажды именно так мы воспроизвели падение, которое локально не воспроизводилось никак. После перехода на рабочие деревья класс проблем "коммит ушёл не туда" исчез полностью. Даже не уменьшился, а именно, что исчез. В истории видно, как переключения веток в главном чекауте обрываются в один день, и дальше их просто нет. Мержится по-прежнему несколько десятков PR в день, и нужно понимать, что подход не ускоряет отдельно взятые операции, он делает параллельную работу надёжной, а значит устраняет временные потери на то, чтобы разобраться, почему всё идёт не так, как хочется. Скорость даёт параллельность, а worktree убирает аварии, которыми изначально мы с агентами за эту скорость расплачивалась. А теперь главный урок всей истории. Worktree изолирует рабочее дерево, но не изолирует окружение. Файлы разъехались, а всё остальное, что сессии делят между собой, осталось общим. И следующие три инцидента пришли именно оттуда.

Ломается так. Сессия А создаёт ветку и какое-то время правит файлы. Сессия Б в этот момент домержила свой PR и делает то, что положено делать после мержа - переключается на мастер и подтягивает свежую версию. Она не сделала ничего неправильного, это рутинная уборка. Git её пустил, потому что незакоммиченные правки сессии А не мешали переключению - те файлы одинаково выглядели на обеих ветках, и Git спокойно перенёс изменения за собой (если бы они конфликтовали, checkout бы отказал, и вся история пошла бы иначе). Но дерево-то одно на двоих. HEAD, стоявший на ветке сессии А, теперь стоит на мастере. Сессия А об этом не узнает никак: она не выполняла команд, ей никто ничего не сообщил, у неё в чате по-прежнему написано "создал ветку feature/…". Затем сессия А делает git commit. Коммит всегда ложится туда, куда указывает HEAD, а HEAD в этот момент на мастере. Локальный мастер уезжает вперёд на один коммит с чужой работой. Дальше git push -u origin ветка-сессии-А создаёт эту ветку на сервере - и она указывает на тот коммит, с которого была отрезана, потому что локально её никто никуда не двигал. В origin уезжает ветка ровно в том виде, в каком её создали - пустая. Отсюда и "нечего сравнивать". Такие записи сохранились в reflog (журнале, куда гит пишет каждое перемещение HEAD). Журнал не знает, кто именно выполнял команду, но, в целом, картина восстанавливается однозначно:

12:44:14  checkout: moving from master to feat/the-controls…   ← сессия А
13:11:49  checkout: moving from feat/the-controls… to master   ← сессия Б
13:11:51  pull -q --ff-only: Fast-forward                      ← сессия Б
13:23:32  commit: feat(editor): the controls are part of…      ← коммит сессии А, на мастере
13:37:26  reset: moving to origin/master                       ← сессия А

Двадцать семь минут нормальной работы между "создал ветку" и "дерево ушло". Ни одна команда за это время не упала. В принципе, чинится это без переключения дерева - чтобы не мешать соседу, который в нём работает. Ветку переставляют на нужный коммит принудительно (git branch -f), отправляют на сервер с перезаписью и откатывают локальный мастер к серверному состоянию. Перезаписывать опубликованную ветку лучше не голым --force, а --force-with-lease. Он отправит только в том случае, если на сервере с момента вашей последней сверки ничего не изменилось. В обычной работе разница не существенна, а при нескольких параллельных сессиях именно она отделяет починку от затирания чужой работы. И перед всем этим стоит посмотреть git show --stat на спорный коммит - если внутри оказалось что-то чужое, это уже другая история. Теперь та же проблема в обратную сторону. Незакоммиченные файлы не принадлежат какой-либо ветке. Совсем. Они просто лежат в рабочем дереве, а ветка про них ничего не знает, потому что ветка - это указатель на уже сделанные коммиты. Особенно это касается новых файлов, которые Git ещё не отслеживает. При переключении веток он их не трогает вообще, они остаются на диске как есть. И вот сессия Б создала в дереве пару новых файлов и ушла на мастер. Сессия А, ничего не проверив, создаёт ветку - и чужие файлы оказываются в её ветке как её собственные. Команда git add -A, которой агенты пользуются постоянно, означает "взять все изменения из рабочего дерева, которые Git не игнорирует", и она честно берёт всё, включая чужое. Дальше сессия Б делает свой коммит, но HEAD ведь уже стоит на ветке сессии А. В origin уезжает коммит с сообщением сессии Б, её работой, чужой поправкой и под именем ветки сессии А. Распутать этот клубок постфактум можно, но агент сталкивается с тем, что не всегда однозначно понимает чью историю имеет право переписывать. У всех этих случаев одна общая черта - ни одна команда не завершилась ошибкой. Git каждый раз сделал ровно то, что у него просили. Просто это "что просили" складывалось из команд двух независимых процессов, каждый из которых считал дерево своим. Такие вещи не ловятся тестами, не видны в CI и обнаруживаются, только когда я открываю ссылку на PR и вижу, что сравнивать нечего.

Изначально, выстраивая свою работу с кодинг-ИИ-ассистентами, я работал очень последовательно - небольшими срезами и не больше одного PR на репозиторий за раз. И при этом моя любовь к микросервисам позволяла распараллелить работу, потому что для каждого отдельного микросервиса я завожу отдельный репозиторий. Также я обычно держу отдельный реп с контрактами и документацией, с которым сверяются остальные. Работа была выстроена так, что сначала всегда идут сверки с контрактами и если контракты затрагиваются - в первую очередь приводятся в нужное состояние они, а только потом идут изменения в сервисах, ложащиеся на изменившиеся контракты. Но потом я стал замечать, что мне не хватает такого разделения. Например, фронт требует намного больше итераций правок, чем бэк. Сервис для работы с разными вендорами LLM-ок иногда требует расширения доступного пула как поставщиков, так и моделей, и требует в моменте большого количества контролируемых изменений. В общем, это породило необходимость запускать несколько сессий с агентами уже в одном и том же репозитории, а не в разных. Как в таких случаях работают люди? У каждого на рабочей машине свой клон репозитория, с которым он работает, не мешая другим в моменте. Да, в процессе слияний могут быть конфликты, но в процессе основной работы - нет, так как правки независимы и на соседнюю работу до мержа повлиять не могут. Чтобы создать подобные условия для агентов мне пришлось бы для каждой сессии заводить свой собственный клон репозитория и процессить весь этот хаос, стараясь не забыть для чего какой клон нужен. Но потом выяснилось, что git уже давно поддерживает worktree, которым я раньше никогда не пользовался, в виду отсутствия необходимости. Но расскажу по порядку. Несколько сессий оправданны ещё потому, что воркфлоу состоит из большого количества тестов (юнит, интеграционных, e2e, мутационных и т.п.) и пока одна сессия ждёт прогона тестов, который может занимать от нескольких минут до их десятков, вторая делает следующую по списку задачу. Выигрыш очевиден. Но первые недели он регулярно съедался происшествиями, которые выглядели как "больше работы по поддержке параллельности, вместо самой работы". Из самого частого: агент отчитался, что работа сделана, ветка запушена, вот ссылка - а GitHub на этой ссылке пишет "There isn't anything to compare". Ветка есть, коммита в ней нет. Работа была, я её видел, тесты по ней проходили. Чтобы объяснить, куда делся коммит, напомню одну вещь про Git для лучшего погружения в контекст. В повседневной работе о ней не думаешь, потому что в одиночку она не мешает никогда. Клон репозитория состоит из двух разных вещей. Первая - данные самого Git - вся история, все коммиты, все ветки. У обычного клона они лежат в скрытой папке .git. Вторая - рабочее дерево - те самые файлы проекта, которые мы видим в редакторе. И вот ключевое - данных гита хватает на сколько угодно веток одновременно, а рабочее дерево у клона одно. Ветка при этом - это не папка и не копия проекта, а просто указатель на коммит - строчка в файле, если совсем грубо. Ещё есть указатель по имени HEAD, который говорит "мы сейчас вот здесь". Когда мы делаем git checkout другая-ветка, git не создаёт никакую копию, - он переписывает файлы в вашем единственном дереве под состояние той ветки и переставляет HEAD. Пока вы в клоне один, это ровно то, что нужно. Как только в нём двое - начинается то, ради чего этот пост.

↔️ Быстрый офер в Яндекс для ML- или DL-инженеров Приглашаем специалистов с опытом от 2 лет в доменных областях NLP, CV, RecSys и Classic ML на Weekend Offer ML* 12–13 сентября. Это один из наймовых ивентов Яндекса: вы сможете пройти все ключевые этапы онлайн и без долгих пауз. Как всё устроено: ⚪️до 4 сентября — регистрация; ⚪️12 сентября — всего две технические секции; ⚪️13 сентября — финальные интервью с командами. Если хотите работать в одной из команд Яндекса — R&D, Алиса и Умные устройства, Поиск с Алисой AI, Независимый Ecom, Рекламные технологии Яндекса — регистрируйтесь! 🔛 Подробности и полезные ссылки на сайте. После регистрации с вами свяжется рекрутер и расскажет все детали.

Поэтому следующая ступень ритуала звучит так: после мутации убедись, что прогон вообще состоялся и упало именно то, что должно. Смотреть нужно не только на "0 failed", а на количество собранных тестов и на имя красного. Ноль упавших при неверном пути к тестам и ноль упавших, потому что всё работает - в консоли выглядят одинаково. Выводы из опыта: Первое. Каждый гард проверять мутацией. Сломать то, что он охраняет, убедиться, что красный именно он и именно по той причине, и потом вернуть как было. Иногда, чтобы не терять связь с проектом, слепо доверяя тому, что происходит, я беру какой-нибудь рандомный тест из проекта и разбираю его вместе с Клодом, типа, для чего он, что ловит, как проверяется, что ловит именно это и т.п. Второе. Смотреть на число собранных тестов, а не только на отсутствие упавших. Ошибка сборки, неверный путь, не поднявшееся окружение - всё это может выглядеть как успех, если читать только 0 в последней строчке. Третье. Не давать тесту пересчитывать ответ. Если ожидаемое значение получено той же логикой, что и проверяемое, тест может проверять реализацию самого себя, а во многих случаях это просто означает, что теста нет. Ожидание должно быть константой или приходить из независимого источника. Четвёртое. Тестировать через тот путь, которым ходит прод. Не через хелпер, который дублирует шаг, и не через мок, который добрее реальности. Мок обычно добрее, если только осознанно и целенаправленно не делать его злым - он часто не таймаутится, не возвращает 401 и не забывает поле. Пятое. Красный тест тоже нельзя принимать на веру, как известно "зелёный" не всегда значит "работает", а "красный" не всегда значит "баг". Сначала нужно проверить окружение. Устаревший чекаут, не тот порт базы, забытая env-переменная дают ровно такую же красноту, как настоящая проблема, и ведут расследование не туда. Интересно, что вся эта дисциплина не про недоверие к агентам. Человек, который пишет код и тесты подряд, попадает в ту же ловушку - просто медленнее и размазанно во времени, то есть фактически реже. Но если вручную писать тесты с такой же скоростью, как это делают агенты, думаю, проблем будет намного больше. Ну, и, как говорится, тестов много не бывает. И, как я уже когда-то писал, агенты пишут их всё лучше, но понимать, что именно и как проверяется, думаю, смысл до сих пор имеет.

Есть особый сорт дефекта, который появляется часто тогда, когда код и тесты к нему пишет один и тот же агент. Это известная проблема, которую я уже несколько раз упоминал и даже писал, что Claude с ней разобрался самостоятельно. Проблема называется "тест, который не может упасть". Он зелёный, он в CI, он выглядит как проверка, но если сломать то, что он охраняет, он останется зелёным. И вы об этом не узнаете, потому что узнать об этом можно только одним способом - известным в народе тестированием продом. Claude после соответствующих моих докапываний поделился почему так: причина, говорит, в том, что тест он пишет из того же понимания, из того же контекста, что и код, впрочем, как и мы до появления хорошей насмотренности на то, какими тесты вообще должны быть. Если агент решил, что значение приходит вот отсюда, то и код напишет так, и проверять будет там же, подгоняя решение под ответ. Ошибка в понимании копируется в обе стороны, и они прекрасно между собой согласуются. Если тесты пишутся исходя из требований, то они обычно получаются сильнее, чем тесты, написанные сразу во время написания логики, которую они же и должны тестировать. Агент, пишет и код и тесты, используя один и тот же контекст, если не разделять специально. Первый раз я его поймал на истории, где оплаченное действие пользователя не сохранялось в базу вообще. В коде была перепутана пара типов при записи JSON, данные молча не доезжали. При этом юнит-тест на сохранение был, он был зелёный и он был бессмысленным - он сверял строку с фейковым коннектом, то есть проверял, что мок вернул то, что в мок положили. Ни одной строчки от настоящего пути в нём не было. Из этой ошибки выросло первое правило: проверять через тот же путь приложения, которым пользуется прод, а не через хелпер. Дёргай шаг целиком, ходи в настоящую базу, посылай настоящий запрос в приложение. Помогло, но не спасло. Следующая история была тоньше. У меня есть отдельный гард - проверка, которая должна гарантировать, что определённый шаг пайплайна отдаёт результат в нужной форме. Тест был честный, ходил через настоящий вызов и был зелёным. Только считал он ответ сам, своей копией логики, а не тем, что реально вернул шаг. Шаг откатили на старую версию - тест не заметил. Он проверял намерение, а не факт. Отсюда второе правило, которое мы с Клодом заучили как мантру: гард должен проверять факт, а не намерение. Если ты в тесте пересчитываешь ожидаемый ответ той же формулой, что и код, ты сравниваешь формулу с самой собой. Абстрактный пример для лучшего понимания чего в тестах быть не должно:

expected = calculate_price(order)
assert response.price == expected

Дальше. Недавно я добавлял в проект роль "админ readonly" и обнаружил, что десяток тестов админских страниц всё это время проходили от лица анонимного гостя. Просто потому, что роль до этого дня ни на что не влияла, и разницы не было видно. Тесты были зелёные ровно потому, что проверять было нечего. Как только роль начала что-то значить, они посыпались все разом. Зелёный тест отвечал "работает" на вопрос, не имеющий смысла. Так у нас появился ритуал, который зафиксирован отдельным правилом. Написал проверку - сломай то, что она охраняет, и посмотри, что она покраснела. Это позволяет отделить реальную проверку от её имитации. По сути, это ручное, но теперь руками агента, мутационное тестирование. Но вы, надеюсь, не подумали, что на этом проблемы с тестами прекратились? Мутация, оказывается, тоже может не сработать. Буквально на этой неделе Claude сломал правило в файле, прогнал тесты и увидел в выводе "1 error". Обрадовался, что поймал - и чуть не пошёл исправлять. А это была не упавшая проверка, это питон не смог собрать файл. Клод неаккуратно вырезал строку и порвал синтаксис. То есть тесты вообще не запускались, и проверка проверки ничего не проверила.

Программирую, не приходя в сознание. Так вот как китайская комната, оказывается, работает.

В прошлом году я посещал big tech night - ивент, похожий на "Ночь музеев", только вместо музеев - офисы крупных технологических компаний. Одна из самых запоминающихся мыслей, которая сразу же всплыла, как только я сел за написание этого текста, была о том, что будучи крупным игроком, ты не можешь сидеть на всём готовом (в смысле софта и инфраструктуры), - перед тобой постоянно возникают задачи, решения для которых либо ещё не придуманы, либо ещё не обкатаны, либо покрывают твои потребности лишь частично. И тебе приходится нужные решения создавать самому. Ну, а в дальнейшем они имеют большие шансы стать стандартом индустрии. В этом году Яндекс решил изменить жанр мероприятия. Теперь deep tech night - это конференция о технологических вызовах в эпоху AI. И если ещё пару лет назад многие только присматривались к искусственному интеллекту и спорили о том хайп это или нет, то сегодня, думаю, стало очевидно, что ИИ с нами навсегда и его эффективное внедрение требует существенного пересмотра устаканившихся за предыдущие годы бизнес- и технологических процессов. Об этом и будут доклады. Кого в первую очередь собираюсь слушать я. Мо Гавдат, бывший Chief Business Officer Google X, расскажет про то, что будет после первого поколения AI-систем и куда эволюционируют инженерные команды. Звучит довольно интересно, потому что за плечами докладчика большой опыт запуска проектов, опережавших своё время. Подозреваю, что ему хватит насмотренности, чтобы поделиться ценными мыслями о том, куда всё движется и как можно к этому готовиться. Дальше - Алексей Гусаков, CTO поисковых сервисов и ИИ Яндекса, с разбором перехода от классического ML к генеративным моделям в рекомендациях. Выступления Алексея - это всегда довольно плотный материал по существу, потому тоже жду. Сергей Мельник - про Physical AI "без купюр": как построить стек автономного транспорта и запустить его в реальных условиях, не в симуляторе. Я продолжаю утверждать, что следующий технологический бум, который нас ждёт, будет связан с автономными роботизированными системами. В какой-то мере он уже начался, просто пока менее заметен в свете событий вокруг ИИ. В эфире будет только часть докладов, записи всех выступлений обещают выложить уже после мероприятия. У зарегистрированных участников будет возможность задать экспертам вопросы на Q&A-сессия. Офлайн тоже есть, все подробности смотрите на сайте. Я в прошлый раз выходил с big tech night с полезным ощущением сомнения в своих инженерных скиллах, и это лучше любой мотивационной литературы. Надеюсь, что и в этот раз конференция сработает так же, только теперь сомневаться придётся в том, что я что-то уже понимаю в вопросах как строить системы в мире, где почти весь код пишут агенты. Регистрация на трансляцию открыта для всех

Опыт посещения недавних митапов снова напомнил, что пока никакая автоматизация не заменяет живого общения. Обсуждения актуальных вопросов с увлечёнными людьми и возможность обменяться парой фраз со спикерами в перерыве - дорогого стоит. Поэтому с удовольствием рассказываю про возвращение Data Dojo - встречи ML-комьюнити, которая в этом году пройдет 9 сентября в Санкт-Петербурге. В прошлом году я уже был на Data Dojo в Москве и делился впечатлениями. Мне понравилось мероприятие, и я планирую быть и на этом. Тогда доклады, общение с командами, отвечающими за разные ML-направления, заряд оптимизма от студентов самых продвинутых ВУЗов страны, нетворкинг и разные зоны активности, включая игровые автоматы с играми 80-90-х годов оставили очень приятное ощущение. Уезжал, как я тогда написал, со спокойной уверенностью, что всё идёт своим чередом и что люди-специалисты нужны не меньше, а то и больше, чем раньше. Сейчас я ещё больше верю в это, потому что решение и автоматизация текущих задач высвобождает руки для решения новых, а их перед человечеством стоит, мягко сказать, довольно много. В этом году в программе выступлений: - Антон Клочков, руководитель группы ML-разработки Фотоинпута, покажет, как выкат фичи может обернуться длительным откатом - Маргарита Мишустина, руководитель группы ранжирования Рекламы, расскажет про техническую эволюцию аукциона дизайнов - Сергей Фиронов, ведущий разработчик службы поведения и предсказания департамента Автономного транспорта, который в прошлом году рассказывал, как они готовили задачи для соревнования, в этот раз разберёт задачи Yandex ML Challenge. После докладов, как и в прошлый раз, можно будет пообщаться с командами, обсудить услышанное и сверить подходы с коллегами. Также будут карьерные консультации и постерные сессии о проектах Яндекса. Чтобы принять участие, необходимо подать заявку до 26 августа. Ориентируясь на личные ощущения - рекомендую сходить.

Кажется, я понимаю, что могли чувствовать люди-компьютеры, занимавшиеся математическими вычислениями на бумаге, когда их постепенно начали заменять компьютерами железными. Да, стало быстрее, да стало точнее и надёжнее, но тот самый кайф от работы карандашом, быстрыми прикидками в голове порядка получающихся значений, ощущение того, что ты чувствуешь цифры кончиками пальцев - всё это стало уходить. Кому-то, конечно, эти изменения были исключительно в радость, так как счёт на бумаге был скучной рабочей рутиной, лишённой творчества. Но, уверен, были и те, кому такие размеренные действия доставляли удовольствие, а железные машины лишали ощущения власти над числами. Я уже несколько месяцев, как и многие из вас, не пишу код руками. Сейчас я выстраиваю процессы автоматического написания кода так, чтобы проекты со временем не разваливались, не гнили и не источали неприятный запах. Чтобы как не развивался бы проект, агентам было с ним удобно работать с наименьшими затратами контекста. Чтобы новые фичи легко ложились на существующую инфраструктуру, во-первых, не ломая старые, а во-вторых, не превращая всё в макаронную фабрику. Чтобы оповещения о проблемных местах приходили раньше, чем проблемы случались. Всё это очень интересная и нужная работа, позволяющая добиваться быстрого и контролируемого результата, но теперь я чувствую, что мне не хватает того самого кайфа, когда именно написанные мной строчки кода, именно мной придуманные алгоритмы, запускались и работали. Видимо, надо снова идти решать литкод, теперь только там и получится что-то реально поделать руками, в работе этого больше не требуется.

Помните, ещё недавно многие жаловались на то, что модели пишут такие тесты, которые их код всегда пройдёт, даже если он проблемный? Теперь агенты не просто пишут тесты, но и проверяют их на то, ловят ли они то, что должны через ломание кода. Это пришло из коробки, я такому не учил. Проверяю иногда тесты и понимаю, что я во многих случаях вряд ли написал бы лучше. Всё больше верю в рекомендацию периодически обнулять все правила и смотреть на то, как изменилось поведение системы. Получается, мировые best practices доезжают автоматически на каждой итерации улучшения агентов.

Тестов много не бывает. А, уж, когда Клод фичи пилит - тем более! Тесты очень хорошо спасают от того, чтобы "в одном месте делаю, в другом - ломаю".

Ааааа! Ужас! Claude взломал сайт фитнес-клуба! Что же теперь будет?? Только проблема не в том, что Клод взломал, а в том, что сайт - говно.

Есть мнение, что чем сильнее агенты, тем в менее безопасном мире мы живём, потому что дыры в безопасности всё чаще находятся агентами и злоумышленники будут строить свои эксплоиты для этих уязвимостей. Звучит логично. Но я смотрю на это немного под другим углом. Чем больше дыр в безопасности найдут агенты, тем вероятнее они же (совместно с разработчиками) эти дыры и закроют. То есть информационные системы станут не менее, а более безопасными в перспективе. Я недавно был на митапе, на котором учёные рассказывали о том, как изменилась сейчас научная деятельность в условиях развития ИИ-агентов. Я сидел, слушал и офигевал от того, что изменилась она ровно так же, как и деятельность разработчиков. И жалобы на агентов ровно такие же: не с первого раза доказал теорему, сделал несколько ошибок, которые заметил только после того, как его ткнули носом, ссылался не на те теоремы, которые были бы более изящными для доказательства, требует постоянного напоминания, чтобы не сдавался и не заметал проблемы под ковёр и т.п. Но ещё больше меня зацепила фраза Сергея Николенко о том, что учёные получили в своё распоряжение тральщик, который в автоматическом режиме может читать научные статьи и находить в них ошибки, неточности, недораскрытые идеи и так далее. Я сразу вспомнил, что и в разработке сейчас так - множество агентов ходит по открытым репозиториям на гитхабе и предлагают PR'ы к давно открытым issues. То есть то, на что у людей не хватало времени теперь может быть починено автоматически. То важное, что давно лежало в бэклоге - наконец-то начнёт всплывать на поверхность и получать долю внимания разработчиков. То, где раньше шёл отказ от оверинжиниринга и безопасности в угоду скорости - теперь может делаться почти само в параллельных сессиях. Я и сам недавно глубоко отрефакторил несколько своих проектов, закрыв давние технические долги и усилив системы. Я очень не уверен, что вообще когда-нибудь до этого дошли бы руки, если бы только не выстрелило однажды само. Теперь у нас появилось больше возможностей стелить соломку заранее, не дожидаясь реальных инцидентов, чтобы делать это в безумном ритме постфактум. В общем, я думаю, что устойчивость и безопасность систем растёт, а не уменьшается. Слава роботам!

Как вам?

Срочно нужен фильм ужасов с таким сюжетом