max.sh

Вчера стартап Миры Мурати, 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 под капотом, почему нет удобного интерфейса чтобы делать такие же слайд деки. Надеюсь, завезут.

В прошлом году делал пост с подборкой ресурсов для желающих разобраться в деталях RLHF. Одним из ключевых ресурсов была книга довольно уважаемого рисерчера и преподавателя Nathan Lambert.

Сегодня у него вышло обновление. Автор оформил книгу в виде бесплатного мини-курса с видео-лекциями, слайдами и кодом.

Получилось 4 лекции по часу, от введения до математики и реализации.

Лекции на ютубе смотреть тут

Вчера посетил конференцию 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: каждый может создать свой бенчмарк и прогнать разные модели.

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

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

Литкод для numpy

В тему к посту выше

Недавно один подписчик пришел за советом. Как готовиться к кодинг раунду, где спрашивают задачки с фокусом на знания фреймфорков с функционалом 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

Возможно, в комментарии еще накидают полезных ресурсов!
Кто знает, возможно такой формат адаптируют повсеместно, тогда будем гриндить новый тип литкода!

Андрей @asmekal описал свой опыт собеседований на ML роли за 25 год и скомпилировал мысли в один классный лонгрид:
https://asmekal.github.io/blog/posts/interviews-2025-ml-research-engineer-uk

Тут полезные советы, примеры вопросов и что вообще можно ждать в собесах от стартапов, биг теха и фронтир лаб. Рекомендую почитать, особенно тем, кому актуально!

Столкнулся недавно с тем, что перформанс популярных кодинговых агентов на внутренних бенчмарках, может значимо скакать (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!

Сегодня ребята из Nebius релизнули новую версию SWE-rebench-v2.

Большой бенчмарк для оценки способности агентов решать задачи в реальных кодовых базах для разных языков программирования.

Видно, что ребята проделали колоссальную работу, чтобы собрать такой датасет. Поддержите лайком на HF Papers, чтобы больше людей знали про хорошую статью!

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

Последние пару месяцев я плотно работал над этим релизом, и наконец-то мы выкатываем его в опенсорс!

📟 Встречайте SWE-rebench-V2: самый большой открытый, мультиязычный датасет для обучения кодовых агентов!

Вместе с командой Nebius AI R&D мы построили пайплайн для масштабного сбора задач из реальных GitHub репозиториев и теперь делимся всем с комьюнити. На текущий момент это самый большой и разнообразный открытый датасет подобных задач в мире.

Что внутри:
> 32 000+ задач — на базе реальных issue + готовый Docker-образ.
> 20 языков программирования. Некоторые языки (например, Lua или Clojure) вообще никогда раньше не были покрыты!
> 120 000+ дополнительных задач, собранных на базе реальных PR.
> Качество — задачи отфильтрованы и размечены с помощью ансамбля LLM. Также мы обогатили их метаданными и добавили интерфейсы, которые проверяются в тестах.

Вместе с датасетом мы дропаем техрепорт со всеми деталями нашего пайплайна и прогонами моделей.

📄 Статья и датасет

👾 Наш Discord (мы там онлайн, залетайте с фидбеком и вопросами).

✉️ Пост в X

Если есть любые мысли, идеи, предложения - приходите!

🔁 Буду благодарен за репост и пересылку!

AI компании продолжают захватывать лондонскую подземку. В этот раз реклама Lovable о простоте вайбкодинга.

Все конечно круто, но только рекламщики явно не учили, что интернет в местном метро вещь довольно редкая, и как правило между станциями не ловит. На ветке Виктория так точно.

💼 Hiring Post

Стартап растет и ищет к себе людей на роль Member of Technical Staff - AI Engineer
Полное описание вакансии можете посмотреть тут.

• Идеальный Кандидат. Это человек с большим бэкграундом в Software Engineering и умением плотно работать с рисерчерами (моей командой). Так, чтобы рисерч прототипы быстро и надежно доходили до продукта и можно было легко итерироваться, скейлить компьют.

• Немного про компанию. Сейчас фокус на том, чтобы делать Eval-ы разных кодинг агентов, подсвечивать боттленеки и предлагать варианты улучшения контекста (как показывает реальность -- хорошие качественные токены это все что нужно модели на вход, чтобы решить задачу). Эвалы разные. Есть быстрые standalone решения, например, померить качество вашего claude code skill-а (это как раз последний запуск, пост фаундера в твиттере), есть более глубокие, когда клиенты дают доступ к кодовой базе и мы плотно интегрируемся в их среду, чтобы понять в чем основные проблемы у агентов, как улучшать контекст и мониторить во времени.

• Интервью. Этапы собеседований очень практичные. Intro call с Head of Engineering, за жизнь и ориентиры. Take Home Exercise на несколько вечеров. технический on-site (очень-очень желательно лично, но если очень сильный кандидат, то есть возможность пройти все ремоут) на один день с командой, отдельно общение с фаундером.

• Важные детали. Компания базируется в UK, Лондон, Kings Cross. Работа on-site, 3 дня из офиса, 2 ремоут. Спонсируют рабочие визы. Компенсация на уровне местных биг техов (в компании прилично людей из разных FAANG-ов) + сверху опционы.

Можно податься самостоятельно через сайт (ссылка выше). Или прийти в личку с резюме, небольшим рассказом о себе и почему нравится Code Gen и откликается вакансия -- если все мэтчится, то сразу передам резюме нанимающим людям.

Посмотри сам или покажи другу!

Sutskever's List.

Согласно лору интернета, это список статей, которым Илья поделился в частной беседе с John Carmack (известный разработчик, создатель Doom, впоследствии работал над Oculus), добавив:

 ‘If you really learn all of these, you’ll know 90% of what matters today.’

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

Список состоит из статей по CNN, RNN, механизмам внимания, scaling laws и другим актуальным на сегодняшний день понятиям.

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

Интересно, что одного это не проверенного источника оказалось достаточно, чтобы издательство Manning выпустило книгу с одноименным названием. Посмотреть и при желании купить можно тут. Книга еще формально в разработке, но все главы уже доступны.

Не берусь судить о качестве книги целиком, бегло прочитал только одну главу. Про наш с вами любимый self attention. Глава построена на основе культовой статьи Attention Is All You Need.

И честно...мне показалось это бесполезнейшим текстом. Если автор пишет для новичков, то из тех скудных диаграм и примеров точно не будет ничего понятно. А если автор пишет для тех кто разбирается и хочет углубить знания, то он не привносит ничего нового. Оригинальная работа, например, не очень углубляется в детали того, зачем нужна нормировка QK произведения на корень из размерности эмбеддингов. Оригинальная статья так же и не дает детальных пояснений почему позиционные эмбеддинги считается через чередование sin, cos и какие свойства это дает. Казалось бы, вот супер годный контент для углубления и раскрытия в книге. Но автор ограничивается не самыми сильными аналогиями. Если взять статью и идти в гугл / чатгпт каждый раз когда непонятно, то можно углубить свои знания сильно быстрее.

А название и правда крутое.
What Did Ilya See?

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

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

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

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

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

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

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

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

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

Недавно вернулся со второго командного оффсайта (про прошлый писал в Июле).

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

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

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

В этот проводили в Барселоне. Первый раз оказался здесь зимой. И мне кажется, это самая идеальная зима, которую можно представить! Сухо, 10-13 градусов, одинаково тепло и днем и вечером, так еще и людей не слишком много!

Свободного времени почти не было, поэтому только посмотрел архитектуру Гауди – вечно строящийся собор и несколько фасадов. Интересно, что среди коллег мнения о его искусстве полярно разделились – либо поражает воображение, либо кажется необоснованным нагромождением. Мне вот очень откликнулось.

Но туристические заметки можно прочитать много где еще. А вот пообщаться с инвесторами и послушать, что они говорят - нет.

Познакомился с управляющим партнером венчурного фонда GV Tom Hulme (на последнем фото). Лидировал раунды в крупные компании, включая Stripe, Monzo, Blockchain (тут сомнительно, конечно). Том вел раунд и в Tessl (где сейчас и работаю). Из интересных публичных мыслей:

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

• Считает, что Gemini и гугл обойдут OpenAI в активных юзерах и возьмут превосходство в качестве.

• Скейлинг продолжится: pre-training, post-training, test-time compute живее всех живых. Человек который общаестя с Хассабисом каждую неделю что-то точно знает 😀

• Разрыв между опен-соурсом и проприетарными решениями будет сохраняться, а в компанию Reflection AI которая привлекла огромный раунд для создания "западного ответа DeepSeek" не верит