Kantor.AI

Когда я начинал карьеру, а также на первых руководящих ролях, мне казалось, что если сотрудник несет какую-то фигню, с этим надо что-то делать. Со временем я принял, что не всегда. Например, если 50% генерируемого потока информации полезны, а 50% какая-то чушь, то бывает так, что использовать первую половину и игнорировать вторую выгоднее в моменте, чем что-то менять. Со временем я принял и то, что иногда чушь может оказаться не чушью и бывает полезно разобраться, может что-то я сам не понимаю. В общем, толерантность к тому, что кто-то может сказать какую-то глупость выросла, а категоричность суждений снизилась. Правильно это или нет, я не знаю и не хочу судить, во всем есть свои плюсы и минусы, но для меня это стало частью управленческой профдеформации. Сейчас при использовании нейросеток заметно как фидбек на их полезность зависит от того, на чем концентрируется пользователь - на ошибках и глупостях или на том, что получилось. Еще на Yet Another Insight одна из дискуссий была про то, можно ли использовать агента, который успешно решает задачу в 50% случаев. Дискуссия быстро сошлась к тезису, что если работает быстро, а проверка недорогая, то ведь отличная штука. Но часто мы судим, что 50% это «как монетку подбросить» и очень плохо, а не видим реальную полезность. Тут конечно помог бы не только менеджерский бэкграунд, но и просто знание, что такое метрики и бейзлайны или банальная способность считать сэкономленное время. Но вот вам еще пример. Обучение использованию LLMок топ-менеджеров солидной компании, один из топов восклицает: «Так это что, теперь придется четко и понятно задачи формулировать?». Это конечно было шуткой, но в любом случае примеры показывают, что появление любых помощников, что живых, что ИИшных, это всегда вызов для наших управленческих навыков и в постановке задач, и в валидации, и в принятии решений. Если раньше про какие-нибудь лидерско-менеджерские образовательные программы все шутили «зачем нам столько? все не могут быть руководителями», то теперь внезапно всем и правда понадобились менеджерские навыки, чтобы использовать в своей жизни ИИ достаточно продуктивно.

А вы знали, что Джеффри Хинтон (тот самый, который отец deep learning) - это праправнук Джорджа Буля (того самого, которому мы обязаны булевой алгеброй)? И это далеко не единственный его известный предок. Еще есть математик Чарльз Говард Хинтон (придумавший слово «тессеракт»), его отец - хирург из викторианской Англии Джэймс Хинтон (который кстати еще появляется как персонаж в некоторых художественных книгах о Джеке Потрошителе, хоть в реальном мире Хинтон и умер на 13 лет раньше убийств в Уайтчепеле), а также географ Джордж Эверест (в честь которого назвали угадайте что, несмотря на то, что эта идея ему не понравилась). А вас какие родственные связи в науке и технологиях более всего впечатлили?

Жена спросила: а если у нас столько шарящих в ИИ людей - и звезды Kaggle, и победители межнара по ИИ, почему все еще нет своей конкурентной нейросети, а не китайского опенсорса с дообучением? (Про заслуги китайского Qwen в отечественном ИИ я жене уже рассказывал) Я тяжело вздохнул и ответил, что этому слегка мешают три обстоятельства. Во-первых, наш язык, в отличие от английского, не стал международным, а жить в России, не говоря по-русски, довольно затруднительно. Поэтому возможности привлекать лучших ученых и инженеров со всего мира у нас существенно ограничены. Сюда же добавляется довольно скромная демография: в Китае тоже не то чтобы очень удобно жить англоговорящим, но там пошли по пути, когда и своих кадров на многое хватает. Во-вторых, наша экономика пока что увы не входит в топ-3 экономик Мира, и на сопоставимые инвестиции в ИИ у нас просто не то чтобы есть деньги. Ну и в-третьих, конечно нельзя не вспомнить про отставание в микроэлектронике и отсутствие каких-то перспектив на свое железо для ИИ. Конечно, остался вопрос, значит ли, что в России своих LLMок так и не появится. И тут конечно ответ не столь категоричный. Во-первых, очень может быть, что через несколько лет модели выйдут на плато по качеству, а вычислительные мощности какого-нибудь нового железа от Nvidia будут позволять делать pretrain до качества, слабо отличимого от топового на практике. Во-вторых, альтернативные подходы к архитектуре (SSM или какие-нибудь особо экзотические ветки развития attention) могут все же дать результат и удешевить процесс для всех. В-третьих, чтобы сократить отставание не нужно во всём прям быть первыми, а быть вторым или третьим существенно дешевле. Так что если кратко - это дорого, сложно и пока никому не было настолько сильно нужно, но на горизонте нескольких лет ситуация может и поменяться. А как бы ответили вы?

Это часть рассказа ChatGPT про историю развития AI. Как думаете, что меня больше всего насторожило?

7 золота, 1 бронза и абсолютное 1 место у Артема Горохова 🎉 Новость: https://cu.ru/tpost/4ib9ed5o01-shkolnaya-sbornaya-rossii-tretii-god-pod

Поздравляю сборную и тренеров с победой на межнаре по AI 🎉🥳💪 Просто красавчики, в очередной раз отличное выступление ❤️‍🔥

Набираем людей на ML KATA с Валерой :) Очень живой и полезный формат обучения ML System Design, стоимость участия 10 000 рублей. Участники в группах решают задачу на проектирование ML системы. Вместе с Валерой вы будете отвечать на вопросы, которые заставляют посмотреть на ML систему глубже: ▪️действительно ли вы решаете нужную проблему; ▪️не ушли ли в детали слишком рано; ▪️какие ограничения забыли учесть; ▪️где ваше решение может не сработать в реальном продукте. По сути, вы пройдете тот же процесс, что и ML-команды в индустрии, только за несколько часов вместо недель обсуждений.

Джефф Дин покидает Гугл Буквально вчера Джефф Дин объявил об уходе из Гугла после 27 лет работы в компании. Джефф известен как Чак Норрис в мире программирования, шутки про него сочиняют в таком же духе: Джефф Дин пишет сразу в двоичном коде. Исходники он потом дописывает исключительно как документацию для остальных. Джефф Дин умеет решать NP-полные задачи за полиномиальное время. В коде Джеффа Дина не бывает багов. Иногда он просто приобретает случайные возможности. Если у Джеффа случается NullPointerException, это указатель извиняется перед Джеффом. Джефф не удаляет файлы. Он сообщает им, что их больше не существует. Однажды Джефф настолько сильно сдвинул бит, что тот оказался на другом компьютере. Однажды в начале 2002 года, когда серверы индекса поиска упали, Джефф Дин два часа вручную отвечал на поисковые запросы пользователей. По результатам оценки качество поиска выросло на 5 пунктов. Дин стал одним из самых влиятельных инженеров в истории Google. Среди вещей, к которым он непосредственно приложил руку: +MapReduce; +Bigtable; +Protocol Buffers; +TensorFlow; +TPU; +Google Brain; +объединение Google Brain и DeepMind и запуск направления Gemini. Вместе с ним уходят его многолетний соавтор Sanjay Ghemawat, а также Oriol Vinyals и Quoc Le. Они создают новую компанию Discovery Loop, которая будет заниматься автоматизацией научных исследований с помощью ИИ. Судя по заявлениям, расставание происходит в очень дружеском формате: Google остается инвестором и партнером нового проекта, а Сундар Пичаи публично поблагодарил Дина за вклад. Пишите в комментах вашу любимую шутку про Джеффа Дина 😁

Что произошло в мировом ML за последние полгода? Разобраться в важных исследованиях и трендах поможет ML Global Recap'H1 2026. 13 августа эксперты Яндекса обсудят итоги ICML и других международных ML-конференций, расскажут, какие идеи уже меняют индустрию и на что стоит обратить внимание в ближайшее время. В программе — четыре доклада о ключевых направлениях современного ML. Артём Бабенко из Yandex Research расскажет о развитии Tabular DL, Дмитрий Мокеев из Alice AI — о трендах и вызовах в reasoning, Иван Дёгтев из Яндекс R&D — о новых подходах к оценке качества моделей, а Андрей Бежин из Яндекс R&D — об оптимизации LLM-инференса. 📍 Очно в Москве + онлайн 🗓 13 августа 2026 Регистрация — на сайте Реклама. ООО "ЯНДЕКС". ИНН: 7736207543. Erid: 2VtzqxJAKoQ

Одна из главных проблем мониторинга ИИ-агентов — понять, почему они приняли именно такое решение Если агент внезапно начал использовать не тот инструмент или отвечать невпопад, найти причину бывает сложнее, чем исправить саму ошибку. Обычные логи и метрики здесь помогают не всегда — они не показывают, что происходило внутри процесса. Для таких кейсов трейсы становятся одним из ключевых сигналов для observability ИИ-агентов. Теперь в Yandex AI Studio можно анализировать трейсы на базе Monium Traces, что позволяет проследить всю цепочку действий агента: от промптов и вызовов инструментов до финального ответа. По сути, это возможность увидеть не только результат, но и ход рассуждений системы. Обновление уже доступно пользователям AI Studio. Попробуйте включить трейсы и посмотреть на работу своих агентов изнутри.

Про постановку целей по AI в компаниях Часто, когда придумывают какой-то KPI, например повышение AI-зрелости, проникновения AI или экономических эффектов, в итоговую цель ложится что-то типа «повысить на 50%» или «достичь уровня 80%». Все такие формулировки неизменно вызывают много дискуссий «а как они решили, что надо именно 80, а не 70 или 90?», поэтому пара слов об этом. AI характерно то, что итоговый эффект довольно сложно точно предсказать, максимум - по порядку величины и то может оказаться, что его просто не будет. Как следствие, вы всегда ставите цель в условиях сильной неопределенности, и в какой-то момент надо просто решиться, ткнуть пальцем в график и сказать «будет вот так». Ну знаете, как Королев со своим известным «Луна твердая» (там на самом деле была чуть более длинная и менее бескомпромиссная записка, но легенда всегда становится чуть красивее). Что может смягчить для руководителя и компании последствия такого «тычка пальцем в небо» при планировании? Несколько вещей: 1. Оценивайте результат и уточняйте план чаще, чем раз в год. 2. Берите как руководитель ответственность за тот план, который сами поставили. И когда ставите цель себе, и когда ставите цели своим сотрудникам. Та же байка про Королева ведь не про гениальность и авторитарность великого, а именно про способность взять на себя ответственность. 3. Лучше сначала определитесь со способом измерения и проведите замер, что есть сейчас, чтобы потом не натягивать сову на глобус, подгоняя оценки под то, что вышло. 4. Ищите баланс между микроменеджментом и стратегичным стратегированием с отрывом от реальности: погружайтесь вглубь, чтобы не было чайка-менеджмента и форвард-менеджмента, но видьте границы ответственности. Последнее о том, что ошибиться с планом и посидеть без премии это ок, а «всех разогнать нафиг» это не ок. Если не нравится точность планирования - надо улучшать ее, а не крушить и ломать :) Не должно быть какого-то гнетущего эмоционального давления или чувства вины за неудачу, должен быть здоровый азарт - сделал ставку, пробуешь оправдать, не оправдал - что-то потерял, но не так чтобы руки дальше опускались, пробуем еще и еще. В AI это очень важно, потому что страх сильно влияет на проактивность и взятие на себя ответственности в интеллектуальной работе, где нельзя предсказать результат работы точно. 5. Самое важное: всегда, особенно при недостижении каких-то результатов, ищите возможность не поскорее найти виноватых и кого-нибудь наказать, а понять и вместе с командой придумать, как в следующем временном интервале сделать лучше. При этом терпилой быть не надо, если систематически ставите вместе с человеком цели и систематически их не достигаете, возможно вам обоим нужно поработать с кем-то другим.

О здоровом подходе к внедрению AI Яндекс хочет к концу 2026 года сделать ИИ новым стандартом внутренней разработки с помощью программы 75/75/75. Меня, видевшего в корпорациях разное, здесь больше радует не масштаб цели (с этим справляются многие), а логичный порядок действий. Компания сначала научилась измерять внедрение, получила текущие значения и только потом поставила план. "75/75/75" означает: 1. не менее 75% разработчиков регулярно используют ИИ 2. ИИ участвует не менее чем в 75% изменений 3. в каждом таком изменении не менее 75% кода генерирует ИИ Сейчас ИИ регулярно используют 73% разработчиков Яндекса, а с его помощью создается более половины нового кода. Но только 17,2% работают в режиме, где ИИ участвует минимум в 75% изменений. За последний месяц эта доля выросла более чем вдвое по сравнению с прошлым кварталом. Это и есть практика, которую компания масштабирует. Я бы ставил разработку на первое место среди направлений внедрения ИИ в крупной компании. Здесь уже понятны сценарии и можно считать эффект: скорость выпуска изменений, время на рефакторинг, тесты и документацию. В Браузере новую архитектуру технологии перевода видео сделали за два дня вместо двух-трех недель. В отдельных спринтах Лавки скорость разработки выросла в 3,3 раза. Но здесь же находится главный риск. Агент способен быстрее писать код, а вместе с ним так же быстро производить баги, спорные решения и техдолг. Если мерить только долю сгенерированного кода, отчет может выглядеть хорошо, а система становиться хуже. Поэтому мне близко, что Яндекс оставляет за инженером архитектуру, валидацию изменений, проверку качества и ответственность за то, что попадет в прод. ИИ должен увеличивать пропускную способность команды, но не подменять инженерное мышление. Для этого у компании есть SourceCraft, Yandex AI Studio, которые доступны и внешним разработчикам, и внутренние ИИ-агенты. На мой взгляд, нормальный переход к AI-native разработке выглядит так: сначала метрики, потом масштабирование, при этом ответственность остается у человека.

Про признак «у пользователя день рождения» в ML В этом году на день рождения (он был уже давно, сейчас просто вспомнил историю) я получил очень много поздравлений, и что-то меня побудило всем поздравившим ответить в тот же день. В итоге больше половины моих ответов телеграм удалил, решив, что я спамер. Даже были прецеденты, когда мы с человеком попереписывались, а на следующий день его реплики есть, а мои все потерли. В этом нашелся и позитивный момент, я до сих пор случайно нахожу диалоги с поздравлениями и снова радуюсь им, но конечно основное, что меня позабавило, это что в классификаторе спама либо нет признака «у пользователя ДР», либо он не работает. И это, кстати, частый недостаток ML моделей в B2C сервисах. Например, в одной компании, где я работал, два моих коллеги мужского пола постоянно определялись внутренним классификатором пола как женщины, а один из них на этот счет даже неплохо плевался желчью. Причина тому была очень простой: у них день рождения 8 марта, и они получают аномально высокое для мужчины количество звонков в этот день. Среди тысяч сотрудников оказалось достаточно мужчин, родившихся 8 марта, чтобы баг исправился сам собой, когда для модели сделали нормальные признаки. Общий же рецепт довольно простой: при разработке модели хорошо бы подумать, почему она может ошибаться на каких-то примерах, и что сделать, чтобы не ошибалась. Как правило первые ответы на этот вопрос будут касаться наличия и актуальности нужных признаков, корректности собранного таргета, баланса классов и в целом репрезентативности выборки.