Паровые двигатели изобрели в 1700 году. С тех пор их эффективность неизменно росла.

Самый популярный вид транспорта того времени – лошади. И что интересно: первые 120 лет прогресса паровых двигателей никак не повлияли на численность лошадей в США.

А затем произошло резкое изменение. В период примерно с 1930 по 1950 годы около 90% лошадей в Штатах исчезло. К началу нулевых количество лошадей на семейство стало близким к нулю.

Прогресс паровых двигателей был плавным. Но скачок в их эффективности, и как следствие, полный отказ от лошадей оказался стремительным.

К чему вообще здесь лошади? Думаю, параллель с развитием AI-технологий и автоматизацией разных отраслей, включая разработку, углядеть нетрудно.

Один из ресёрчеров из фаундинг-команды Anthropic, Andy Jones, как раз пишет об этом у себя в блоге:
https://andyljones.com/posts/horses.html

Он подкрепляет историческую аналогию личным опытом. В 2024 году, ещё до выхода Claude Sonnet 3.5, значительная часть его работы заключалась в онбординге новых сотрудников и ответах на их вопросы, порядка 4000 вопросов в месяц.
К декабрю их доля заметно сократилась. А ещё через шесть месяцев 80% этой рутины было автоматизировано. В итоге появилась система, которая в сотни раз дешевле человека и легко масштабируется.

На такой ноте заметка заканчивается.

Но в жизни Andy Jones большой AI-евангелист. Коллега по работе училась вместе с ним в Эдинбургском университете, так что была редкая возможность познакомиться ближе. В жизни он с юмором сочетает мысли о невероятной скорости прогресса и неизбежной автоматизации профессий с абсолютной глупостью моделей в некоторых вещах. Одни технологии и профессии уйдут, но придут новые.

Прогресс может быть плавным. Но трансформация стремительной.

На ютубе разлетелось видео, в котором стример разбирает якобы слитый собес в Антропик, секция кодинг, на позицию Senior AI engineering, Inference team.

Смотреть тут
Пост на блайнде

Слить такое в сеть мог только сам кандидат. Учитывая, что интервью он прошел, объективно, плохо (для человека с позиционированием себя как 10+ лет опыта разработки на c++ очень плохо), зачем такое выкладывать не очень понятно. Только для пиара. Но его оригинал я не нашел, кстати.

Так что воспринимать контент стоит в любом случае осторожно, с долей скептицизма.

В комментариях к видео (и посту здесь в тг!) пишут, что действительно такой раунд и формат, и задача имеют место быть.

Задача кажется не очень сложная. Конвертировать стак трейс в вектор событий. Что-то на уровне между литкодом и повседневным программированием. Разобраться (не так как кандидат) и решить за час точно можно.

В конце интервью замечательный диалог:

кандидат: How do you compromise speed for safety?

интервьюер: We never compromise on safety.

Сильно.

Когда-то давно, во времена учебы в ШАДе, нам читали интенсив по основам архитектуры GPU и разработки на CUDA. Обещали рассказать, как устроены видеокарты и почему они эффективны для машинного обучения. Я тогда дальше model.to('cuda:0') в этом вопросе ничего не знал, поэтому с интересом записался.

Лекции читали разработчики из Nvidia. Да, это было такое время, когда у компании был Московский офис и они периодически нанимали DL-инженеров, а иногда и стажеров (марафон технических раундов и глубоких вопросов на понимание, чтобы побороться за 2 стажерские позиции).

Курс, по моему мнению, получился ужасным. Материал стремительно усложнялся без какой-либо оглядки на аудиторию и тот факт, что ко второй лекции половина слушателей уже отвалилась. Я потерял суть происходящего уже минуте на 20-30 первой лекции, в момент когда термины вида SM, warp schedulers, cuda cores заполняли каждый слайд, а повествование превратилось во внутренний митап для инженеров Nvidia.

Худо-бедно интенсив я закрыл, решая задачи методом проб и ошибок. От курса в голове не осталось почти ничего. Разве что боязнь копаться в деталях работы с GPU.

Позже, уже в 2022-2023 году, модели перестали влазить в память одной ГПУ и нужно было учиться паралелить, оценивать эффективность инфраструктуры в поисках ответа на вопрос: а почему все так медленно? are we compute bound or communication bound? Снова я столкнулся с GPU акселераторами лицом к лицу. Документации от Nvidia было не очень много, так что неподготовленному читателю входить было не просто. Но дело двигалось тем же путем проб и ошибок и общением с коллегами по работе.

А хороших гайдов на понимание все еще не было. Мне кажется их и сейчас не очень много. ( Как и специалистов в этой области. Performance Engineer крайне актуальная роль в области DL на ближайшие годы)

Недавно наткнулся на "книгу" от ребят из DeepMind, они проделали невероятную методологическую работу. И выпустили онлайн-учебник How to Scale Your Model. Центральный предмет книги о том, как учить трансформеры на больших кластерах, арифметику моделей (откуда набегает так много гигабайтов памяти, чтобы сделать один forward pass) и что такое TPU/GPU. К каждой главе идет еще набор квизов, чтобы посчитать что-нибудь руками.

Крайне Рекомендую!

https://jax-ml.github.io/scaling-book/

Edit: в комментариях накидали еще полезных материалов!

Как строить evaluation системы для AI агентов?

Очередной крутой блог пост от Антропиков. Читать тут.

Прорывных мыслей, бенчмарков или сокрального знания тут не найти, но зато очень хорошая структура (такое пригождается на систем дизайн интервью, если что), отличный технический словарь (task, trannoscript, evaluation harness, agent harness, и.т.д) и призыв к действию для тех, кто активно шаманит над агентами в рабочих задачах.

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

Поэтому Eval-ы и нужны. Eval (от evaluation) – это по большому счету тест AI агента. Даете ему среду, задачу, запускаете, и оцениваете результат. На бумаге легко. На деле же каждая из переменных: среда, задача и оценка результата – безумно сложная задача. Особенно на масштабе организаций с сотнями репозиториев. Тут нужна методичность и структура. Поэтому так легко свалиться в "да пофиг, вроде стало лучше". По работе много общаюсь с энтерпрайзами и это головная боль чуть ли не каждого. Собственно поэтому мы и стали командой делать eval платформу, в которой можно эвалить разного рода контекст (например, вы сделали claude skill, а насколько он хорош? оценить можно тут) или целые репозитории и смотреть насколько хорошо агенты справляются с задачами. Но про это в другой раз.

Мне из блога откликнулись такие мысли.

* Смотреть на Eval-ы, как на модель швейцарского сыра. Картинка к посту в пояснение. Суть в том, что одним подходом все не поймать. Поэтому нужно много слоев. Где-то часть ошибок отловят автопроверки, где-то llm-as-judge, а где-то нужно смотреть не просто в input-output поведение, а анализировать логи агента и смотреть что он там накуролесил в процессе.

* Чем больше в системе детерминированных проверок, тем лучше (для вас). Проще дебажить, проще менять. Вслепую делегировать работу на откуп агенту-валидатору (читай llm-as-judge), себе дороже. По мнению такого валидатора все всегда будет ХО-РО-ШО. Как минимум рубрики нужно калибровать и смотреть глазами прежде чем внедрять такое и основывать на этом выводы.

* Чем раньше начнете задумываться о концепции eval-ов, тем проще будет с агентами дальше. Потому что так будет четкие аргументы, почему агент не может решать задачи именно в вашей кодовой базе и во что инвестировать, чтобы стало лучше. Несколько знакомых так уже получили промоушены в биг техах, чисто за счет какой-никакой observability-платформы для агентов. Лайфхаком не является, но намек вы поняли.