ИИ

⚡️ Практический гайд по AI-adoption для руководителей Ну что, готов горячий пирожок — мой гайд о том, как внедрять AI в ежедневную работу команд. За последний год разговор про AI внутри компаний сильно изменился. Нам нужно понять, как сделать так, чтобы новые инструменты действительно вошли в работу, и задача руководителя здесь — помочь своим людям, создать нужную среду, дать доступ к инструментам, научить, самому стать примером. Меня в процессе AI-adoption мотивирует вот какая мысль одного моего коллеги: ИИ всё усиливает, и хорошее, и плохое, и порядок, и хаос. Если в команде понятные процессы, нормальные доступы, сильная экспертиза и культура обмена знаниями — AI может всё это заметно усилить. Если процессы разваливаются, контекст живёт в головах, а инструменты выдаются как попало — массовый adoption, скорее всего, просто масштабирует этот хаос. Поэтому гайд — рабочая карта того, как помочь своей команде освоиться в новой рабочей реальности, где умение работать вместе с ИИ уже стало базовым навыком. Мы в Яндексе сейчас проходим этот путь в очень большом масштабе. Что-то уже умеем делать системно, какие-то первые подходы пришлось пересобрать, а часть практик всё ещё проверяем на ходу. В гайде я собрала то, что оказалось полезным у нас: — с чего начинать adoption в команде; — как искать первые рабочие кейсы; — зачем нужны AI-champions и амбассадоры; — почему обычное обучение часто не работает; — какие инструменты и условия нужны людям; — что имеет смысл измерять, а что легко превратить в бессмысленный KPI. Там, где это полезно, добавила практики других технологических компаний — как ещё один способ сравнить подходы. Гайд адаптирован для чтения с мобилки, навигация по разделам кликабельная. Без смс, без ботиков, только за ваши сердца 💙 @technohumanist

Я все чаще замечаю забавную инверсию. Раньше в моих проектах копились идеи, которые я не успевал реализовать. Теперь coding-агенты реализуют идеи быстрее, чем я успеваю решить, хочу ли я потом с этими изменениями жить. В списке моих диалогов с Codex лежит немало почти готовых фич. Там проходят тесты, работает интерфейс, обновлена документация. Осталось «только проверить». Проверить - это не посмотреть, что тесты проходят (агент их уже сам прогнал). Нужно еще понять, не появилась ли в проекте новая лишняя концепция? Хорошо ли изменение сочетается с остальной системой? Готов ли я поддерживать этот код через год? И вообще - нужна ли мне эта фича после того, как я увидел её реализованной? Поэтому я откладываю проверку «на потом», которое обычно не наступает. Раньше сырая идея оставалась хотелкой в заметках и ничего не стоила. Теперь она за десять минут превращается в ветку с кодом, тестами, документацией и потенциальными последствиями. Вот и получается, что идеи теперь копятся не перед реализацией, а после неё - перед бутылочным горлышком моего внимания и времени. Причём у такого кода короткий срок годности. Проект продолжает меняться, ветка отстаёт все больше, а контекст постепенно выветривается из головы. Проверить изменение завтра сложнее, чем сегодня, а через неделю уже дешевле выкинуть и сделать заново. Я слышал похожее и от других команд. У некоторых после внедрения coding-агентов число открытых PR выросло в 5–7 раз. Генерация кода в 2026 году ускорилась, а пропускная способность человеческого внимания - пока нет. Поэтому сейчас я стараюсь нарезать задачи так, чтобы агент приносил не целую реализованную хотелку, а следующий минимальный reviewable slice: одно понятное изменение и достаточно сопроводительного контекста, чтобы проверить его за один подход. По расходу токенов может выходить забавно: Codex нередко тратит до 95% процентов токенов на поиск такого маленького, независимого и проверяемого следующего шага, который я одобрю. И только процентов пять уйдет на его реализацию. Оно того стоит. Такой кусочек легче проскальзывает через бутылочное горлышко внимания и начинает приносить пользу. Большая же фича, даже полностью написанная агентом, рискует просто пополнить залежи рабочего, но быстро устаревающего кода. А как вы решаете проблему с накапливающимися фичами и PR от coding-агентов - или у вас её нет? Ваш, @llm_under_hood 🤗

Google купит данные обанкротившейся авиакомпании для обучения AI Компания выиграла аукцион с предложением 10 миллионов долларов за данные авиакомпании Spirit Airlines. В пакет входят 100 миллионов рабочих писем, 500 миллионов сообщений из Teams, данные об операционной работе, маркетинге, финансах и сотрудниках, а также около 30 миллионов строк кода. Есть там и огромный массив отраслевых данных: цены на 7.2 миллиарда рейсов конкурентов и около 7.5 миллиарда записей о пассажирских транзакциях начиная с 2008 года. Персональные данные пассажиров в сделку не входят. Сделка пока не закрыта. Профсоюз бывших бортпроводников Spirit выступил против продажи из-за данных сотрудников. https://news.bloomberglaw.com/bankruptcy-law/google-aims-to-boost-ai-with-purchase-of-spirit-airlines-data

В прошлую пятницу был финальный симпозиум MATS 10 потока. Мы рассказывали talk про нашу работу в офисе Лондона + стояли с постером (поигрались в что-то вроде oral на конфе) мы сейчас в процессе сведения всего к завершающей точке и подачи на конфу + пост моей части про генерацию механизмов атак Цель работы следующая: уже со специфичным скофолдингом ваш агент может работать типо день. Есть ли возможность проверить все вызовы вручную? - нет. Но есть решение, можно поставить модель дополнительную в харнес и она за вас просмотрит все выводы и решит было ли что-то в траектории противодейственное. 🐱 Так вот наш пайплайн направлен буквально на создание таких моделей. Вы можете взять любую новую фронтирную модель и натравив наш пайплайн тренировки (red-blue loop) улучшить модель чтобы она сама себе была монитором. Почему так работает? Потому что у вас есть редтиминг. Сторона, которая генерирует атаки, чтобы модель исходная их не поймала. И блу тиминг. Сторона, которая на основании собранного сложного сета с прошлой части обучает модель распознавать такого рода атаки Red team строится так: Берем реальную чистую траекторию, режем на шаги и вставляем side task так (как именно мы ищем механизм атаки надеюсь совсем скоро выйдет постом от меня на Less Wrong) , чтобы отличался только он. Получается траектория близнец, отличающийся от оригинала ровно вставленными шагами. На blue стороне можно обучать монитор находить атаку из 2 пар 💛модель ищет правдоподобное окно и добавляет минимум шагов 💛панель джаджей проверяет, что правка настоящая, минимальная и естественная 💛сложность оценивают уже после заморозки пары, чтобы она не влияла на поиск Что это дает на эвале? тайминг (успел ли монитор до необратимого шага и на сколько опоздал) и атрибуцию с ложными тревогами (скор поменялся из-за вставки или просто из-за задачи, и что монитор делает на бенайн-близнеце). На постере замеры работоспособности 💅 P.S. было еще 2 крутые работы с симпозиума: Stealing Reasoning Traces from Proprietary LLM APIs Diffuse AI Control on Fuzzy Tasks