https://storage.googleapis.com/deepmind-media/gemini/gemini_v2_5_report.pdf
The development of Gemini is a large-scale collaborative effort involving over 3000 individuals across Google, including researchers, engineers, and operations staff. These individuals contributed their hard work and expertise across diverse areas, from foundational research and the development of model architecture, data, training, and infrastructure, through to evaluation and ensuring safety and security. We gratefully acknowledge the dedication and hard work of each contributor in making Gemini a reality.
The development of Gemini is a large-scale collaborative effort involving over 3000 individuals across Google, including researchers, engineers, and operations staff. These individuals contributed their hard work and expertise across diverse areas, from foundational research and the development of model architecture, data, training, and infrastructure, through to evaluation and ensuring safety and security. We gratefully acknowledge the dedication and hard work of each contributor in making Gemini a reality.
🤯7👍3👎2🤣1
PML Conf
Я тут неожиданно для себя стал одним из членов ПК конференции от Яндекса — Practical ML Conf. В этом году на конференции будут представлены доклады по 6 трекам: CV, NLP, Speech, RecSys, MLOps, Data Science. Подать заявку можно до 23 июня (енто я вовремя пишу, в общем-то😁 ), для подачи заявки перейдите по ссылке.
Что предлагаем для спикеров:
— Дадим советы по структуре и содержанию доклада
— Будут прогоны материалов с тренером по публичным выступлениям и помощь с дизайном презентаций
— Возможность понетворкать с другими спикерами и получить фидбэк по проекту
— Промо докладов через каналы Яндекса до и после конференции
— Возможность посетить PML Conf без отбора вместе с +1
Насколько мне известно, планируется как онлайн, так и офлайн трек. Потому, если вдруг вы бы хотели выступить, но нет возможности сделать это оффлайн — тож подавайтесь🧠 .
Я тут неожиданно для себя стал одним из членов ПК конференции от Яндекса — Practical ML Conf. В этом году на конференции будут представлены доклады по 6 трекам: CV, NLP, Speech, RecSys, MLOps, Data Science. Подать заявку можно до 23 июня (енто я вовремя пишу, в общем-то
Что предлагаем для спикеров:
— Дадим советы по структуре и содержанию доклада
— Будут прогоны материалов с тренером по публичным выступлениям и помощь с дизайном презентаций
— Возможность понетворкать с другими спикерами и получить фидбэк по проекту
— Промо докладов через каналы Яндекса до и после конференции
— Возможность посетить PML Conf без отбора вместе с +1
Насколько мне известно, планируется как онлайн, так и офлайн трек. Потому, если вдруг вы бы хотели выступить, но нет возможности сделать это оффлайн — тож подавайтесь
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥18👎2
Мысли про самоотзывы на перформанс ревью
Неожиданно много блогов стало писать про ревью. С чего бы это? Ну да ладно, чем я хуже, давайте чего-нибудь про это напишу.
Будучи линейным разработчиком я старался фиксировать все свои достижения🧠 : успехи, неудачи, выступления на семинарах и конференциях, помощь в мероприятиях и т.д. Это позволялом мне достаточно быстро слепить самоотзыв, из того, что есть, в период, когда он нужен. Обычно у меня получались достаточно объёмные полотна текста, хоть и с выделенными фокусами. И я считал это невероятным достижением: ну нифига себе я сделал, говорил я себе! Вот тут я, получается, выше ожиданий, а тут успешный успех!
Со стороны руководителя начинаешь смотреть на полотна немного иначе.
Очень хочется самоотзывы плотнее по сутевому содержанию, без воды и речевых оборотов: глобально сделал вот это, получил такие-то чиселки
на метриках, а дальше уже под кат убираешь подробное описание, а чо именно ты там сделал;
Когда я раньше писал самоотзывы, я, конечно же, выделял основные достижения. Но никак их не приоритизировал — это зря. Всё же сначала должны быть ключевые вещи, а дальше уже по убыванию важности/значимости.
Лучше писать объективно: рост такой-то, это статзначимо или нет. Если про ожидания, то пишем были ожидания такие, чисел достигли таких.
Тут лишь благодарность за ссылки и пояснения к ним, где можно всё прочитать и посмотреть.
Выглядит прям как голимая отписка. Хочется вместо этого читать мякотку самой работы.
В общем, всё, как в одном меме, упирается в один факт: "Много букав, не хочется букавы читать. Картинки лучше, какие букавы читать ? На кой это надо? Их много, букв"
А вы что думаете вообще про самоотзывы? Легко пишется?
Неожиданно много блогов стало писать про ревью. С чего бы это? Ну да ладно, чем я хуже, давайте чего-нибудь про это напишу.
Будучи линейным разработчиком я старался фиксировать все свои достижения
Со стороны руководителя начинаешь смотреть на полотна немного иначе.
Будучи радеющим за своих людей человеком, ты обязательно и досканально его прочитаешь. И это уже сам по себе челелендж, учитывая и количество людей, и размеры текстов.
Очень хочется самоотзывы плотнее по сутевому содержанию, без воды и речевых оборотов: глобально сделал вот это, получил такие-то чиселки
на метриках, а дальше уже под кат убираешь подробное описание, а чо именно ты там сделал;
Пытаешься отделить основное от дополнительного, приоритезировать достижения.
Когда я раньше писал самоотзывы, я, конечно же, выделял основные достижения. Но никак их не приоритизировал — это зря. Всё же сначала должны быть ключевые вещи, а дальше уже по убыванию важности/значимости.
Пытаешься фильровать описательные и субъективные выражения: "сильно выросли", "невроятный успех", "выше ожиданий", "крайне близко" и т.д.
Лучше писать объективно: рост такой-то, это статзначимо или нет. Если про ожидания, то пишем были ожидания такие, чисел достигли таких.
Фактчекаешь любое утверждение.
Тут лишь благодарность за ссылки и пояснения к ним, где можно всё прочитать и посмотреть.
Очень скептичного смотришь на выражения "разобрался в работе", "провёл много экспериментов", "посмотрел и выяснил".
Выглядит прям как голимая отписка. Хочется вместо этого читать мякотку самой работы.
В общем, всё, как в одном меме, упирается в один факт: "Много букав, не хочется букавы читать. Картинки лучше, какие букавы читать ? На кой это надо? Их много, букв"
А вы что думаете вообще про самоотзывы? Легко пишется?
Please open Telegram to view this post
VIEW IN TELEGRAM
❤14🔥5👎2
Forwarded from CV Time
Что читает команда распознавания текста в VLM: подборка актуальных статей
Инженеры VLM-команды Яндекса поделились статьями, которые они в последнее время читали и обсуждали. В сегодняшней подборке: новые подходы к генерации инфографики, свежие бенчмарки для мультимодальных моделей, работающие пайплайны генерации кода по графику и попытки добавить зрение в диффузионки.
ChartGalaxy: A Dataset for Infographic Chart Understanding and Generation
Статья о том, как сгенерировать около миллиона инфографик. Авторы подробно описали каждую стадию процесса: сбор шаблонов, индексирование описаний, иконок и других элементов для заполнения шаблонов, фильтрацию и проверку качества.
InfoChartQA: A Benchmark for Multimodal Question Answering on Infographic Charts
Авторы собрали новый бенчмарк позволяющий проверить, как VLM-модели понимают инфографику. Для каждой инфографики сделали упрощённую версию в виде обычного графика с теми же данными — модели справляются с таким заметно лучше, чем с визуально перегруженным оригиналом. Также добавили новый тип вопросов по отдельным кропам из изображения инфографики — на понимание мелких визуальных деталей.
ChartCoder: Advancing Multimodal Large Language Model for Chart-to-Code Generation
Авторы обучили модель понимать графики: она получает изображение и возвращает код на Python (Matplotlib), чтобы построить такой же график. Для этого использовали стратегию Snippet-of-Thoughts (SoT) — пошаговое рассуждение перед финальной генерацией кода. Взяли LLM, способную писать код, собрали датасет под задачу (160 тысяч картинок, на каждую — один вопрос и ответ). Кратко описали пайплайн его создания. Модель показывает лучшие результаты среди аналогов такого же размера (включая почти самые свежие Qwen и InternVL). В ablation-экспериментах дообучили Qwen на своём датасете — получили прирост; 384 px + Anyres почти хватает для большинства графиков.
Relation-Rich Visual Document Generator for Visual Information Extraction
Статья с CVPR 2025 о генерации синтетических text-rich-документов с логической структурой (таких, как формы). Пайплайн генерации любопытен тем, что в нём сначала генерируют текст с помощью ChatGPT, а уже потом — структуру документа (laytout). Чаще встречается обратный вариант, когда структуру документа заполняют текстом. Авторы показывают, что обучение Qwen2-VL и Llava-NexT-mistral на таких данных улучшает метрики распознавания текста и извлечения информации на публичных бенчмарках.
LLaDA-V: Large Language Diffusion Models with Visual Instruction Tuning
Авторы попытались расширить предобученную текстовую диффузию LLaDA на мультимодальность, добавив визуальный вход через SigLIP2 и MLP-проекцию в языковое пространство. Итоговая модель зафайнтюнена на визуальных и reasoning-focused-инструкциях MAmmoTH-VL и VisualWebInstruct и бьёт автогрессионные и диффузионные бейзлайны по ряду мультидисциплинарных и визуально-математических бенчмарков.
SFT Memorizes, RL Generalizes: A Comparative Study of Foundation Model Post-training
Интересная статья, авторы которой подтверждают тезис из названия: SFT хорошо запоминает жёсткие форматы и правила, но плохо справляется с out-of-distribution-задачами. В то же время RL реально улучшает генерализацию и показывает заметный прирост на OOD-случаях. Но SFT всё равно нужен, чтобы RL вообще завёлся. В противном случае модель не умеет нормально реагировать на инструкции или генерирует неконтролируемый выход. RL-обучение не получает положительного сигнала. Это справедливо как для LLM, так и для VLM.
Подборку подготовила❣ Команда распознавания текста в VLM
CV Time
Инженеры VLM-команды Яндекса поделились статьями, которые они в последнее время читали и обсуждали. В сегодняшней подборке: новые подходы к генерации инфографики, свежие бенчмарки для мультимодальных моделей, работающие пайплайны генерации кода по графику и попытки добавить зрение в диффузионки.
ChartGalaxy: A Dataset for Infographic Chart Understanding and Generation
Статья о том, как сгенерировать около миллиона инфографик. Авторы подробно описали каждую стадию процесса: сбор шаблонов, индексирование описаний, иконок и других элементов для заполнения шаблонов, фильтрацию и проверку качества.
InfoChartQA: A Benchmark for Multimodal Question Answering on Infographic Charts
Авторы собрали новый бенчмарк позволяющий проверить, как VLM-модели понимают инфографику. Для каждой инфографики сделали упрощённую версию в виде обычного графика с теми же данными — модели справляются с таким заметно лучше, чем с визуально перегруженным оригиналом. Также добавили новый тип вопросов по отдельным кропам из изображения инфографики — на понимание мелких визуальных деталей.
ChartCoder: Advancing Multimodal Large Language Model for Chart-to-Code Generation
Авторы обучили модель понимать графики: она получает изображение и возвращает код на Python (Matplotlib), чтобы построить такой же график. Для этого использовали стратегию Snippet-of-Thoughts (SoT) — пошаговое рассуждение перед финальной генерацией кода. Взяли LLM, способную писать код, собрали датасет под задачу (160 тысяч картинок, на каждую — один вопрос и ответ). Кратко описали пайплайн его создания. Модель показывает лучшие результаты среди аналогов такого же размера (включая почти самые свежие Qwen и InternVL). В ablation-экспериментах дообучили Qwen на своём датасете — получили прирост; 384 px + Anyres почти хватает для большинства графиков.
Relation-Rich Visual Document Generator for Visual Information Extraction
Статья с CVPR 2025 о генерации синтетических text-rich-документов с логической структурой (таких, как формы). Пайплайн генерации любопытен тем, что в нём сначала генерируют текст с помощью ChatGPT, а уже потом — структуру документа (laytout). Чаще встречается обратный вариант, когда структуру документа заполняют текстом. Авторы показывают, что обучение Qwen2-VL и Llava-NexT-mistral на таких данных улучшает метрики распознавания текста и извлечения информации на публичных бенчмарках.
LLaDA-V: Large Language Diffusion Models with Visual Instruction Tuning
Авторы попытались расширить предобученную текстовую диффузию LLaDA на мультимодальность, добавив визуальный вход через SigLIP2 и MLP-проекцию в языковое пространство. Итоговая модель зафайнтюнена на визуальных и reasoning-focused-инструкциях MAmmoTH-VL и VisualWebInstruct и бьёт автогрессионные и диффузионные бейзлайны по ряду мультидисциплинарных и визуально-математических бенчмарков.
SFT Memorizes, RL Generalizes: A Comparative Study of Foundation Model Post-training
Интересная статья, авторы которой подтверждают тезис из названия: SFT хорошо запоминает жёсткие форматы и правила, но плохо справляется с out-of-distribution-задачами. В то же время RL реально улучшает генерализацию и показывает заметный прирост на OOD-случаях. Но SFT всё равно нужен, чтобы RL вообще завёлся. В противном случае модель не умеет нормально реагировать на инструкции или генерирует неконтролируемый выход. RL-обучение не получает положительного сигнала. Это справедливо как для LLM, так и для VLM.
Подборку подготовила
CV Time
Please open Telegram to view this post
VIEW IN TELEGRAM
👍9❤🔥4🔥4👎2🏆1
Forwarded from Quant Valerian
Майндсет тимлида и его руководителя
Большинство тимлидов занимают ролевую модель папочки для своих сотрудников. Это такие маленькие, сплоченные коллективы, которые чувствуют, что живут в страшном и жестоком мире, где все, кто не входит в команду, пытаются их обмануть, сожрать и унизить. Тимлиды же никого подпускают к своим ребятам, закрывают их грудью, принимая на себя все летящие снаружи вопросы, претензии и задачи. Любой ценой нужно недопустить, чтобы злой проджект навалил в спринт своих задач побольше. Всеми силами экономить энергию и время своих ребят, отбивая задачи в смежников или в небытие. И сотрудники таких тимлидов, обычно, любят, потому что чувствуют, как за них врубаются, потому что имеют время на технические, интересные задачки, потому что общий враг, в принципе, хорошо сплочает коллективы.
А вот тимлид тимлидов смотрит на картину несколько иначе. Со стороны выглядит, что он делает то же самое: отбивает какие-то задачи и проекты в смежников или небытие, отдувается перед топами на всевозможных разносах, защищая команды. Но на самом деле, есть очень существенное отличие. Если о нем не задумываться, то поведение М2 менеджера может казаться тимлидам нелогичным.
Разница очень простая, но очень важная. М2 думает, как должно быть хорошо и правильно. Если он отбивает задачу в смежников, то не для защиты своих команд от переработок, а потому что считает, что это выгоднее для компании (или проекта) в целом. Например, экспертиза должны находиться в другом месте или смежники могут сделать быстрее, а уже горит. Если он отбивает задачу совсем, то, вероятно, считает, что она только навредит. Может, ROI плохой, может, не вписывается в целевую архитектуру, может, противоречит стратегии.
Вообще видение такое, что вокруг не враги, а люди, с ограниченными контекстами. И ты сам с ограниченным контекстом. И вам надо достичь какой-то общей большой цели, но вы каждый видите свои пути. И вот надо всем объяснить, что ты не враг. Показать свой контекст. Убедить их показать свои тебе. И дальше договариваться, как же поступить оптимально. И это непрерывная работа.
Но иногда, даже держа в голове эти мысли, тимлид может решить, что М2 ведёт какую-то хитрую политическую игру, ведь решения всё ещё не логичны. Может и так. Но скорее всего, М2 просто подумал на много шагов вперед и учел риски, которые тимлиду даже в голову не приходили (он банально меньше знает вширь, но больше вглубь, да).
В целом, я, например, даже пытаюсь объяснять свои решения тимлидам. Но, во-первых, не всегда об этом думаю, во-вторых, не всегда нахожу силы, в-третьих, всё равно иногда вижу реакцию типа "ага, ну я понял, как _на_самом_деле_, но буду транслировать твою версию, я тебя раскусил".
М2 это работать почти никак не мешает. Просто иногда тимлидов заносит и надо их поправлять. А вот тимлиду изменение майндсета на М2 может помочь вырасти на следующую ступеньку.
P.S.:
Kind reminder, что вы можете связаться со мной через бота в описании, он звездочек не просит.
Большинство тимлидов занимают ролевую модель папочки для своих сотрудников. Это такие маленькие, сплоченные коллективы, которые чувствуют, что живут в страшном и жестоком мире, где все, кто не входит в команду, пытаются их обмануть, сожрать и унизить. Тимлиды же никого подпускают к своим ребятам, закрывают их грудью, принимая на себя все летящие снаружи вопросы, претензии и задачи. Любой ценой нужно недопустить, чтобы злой проджект навалил в спринт своих задач побольше. Всеми силами экономить энергию и время своих ребят, отбивая задачи в смежников или в небытие. И сотрудники таких тимлидов, обычно, любят, потому что чувствуют, как за них врубаются, потому что имеют время на технические, интересные задачки, потому что общий враг, в принципе, хорошо сплочает коллективы.
А вот тимлид тимлидов смотрит на картину несколько иначе. Со стороны выглядит, что он делает то же самое: отбивает какие-то задачи и проекты в смежников или небытие, отдувается перед топами на всевозможных разносах, защищая команды. Но на самом деле, есть очень существенное отличие. Если о нем не задумываться, то поведение М2 менеджера может казаться тимлидам нелогичным.
Разница очень простая, но очень важная. М2 думает, как должно быть хорошо и правильно. Если он отбивает задачу в смежников, то не для защиты своих команд от переработок, а потому что считает, что это выгоднее для компании (или проекта) в целом. Например, экспертиза должны находиться в другом месте или смежники могут сделать быстрее, а уже горит. Если он отбивает задачу совсем, то, вероятно, считает, что она только навредит. Может, ROI плохой, может, не вписывается в целевую архитектуру, может, противоречит стратегии.
Вообще видение такое, что вокруг не враги, а люди, с ограниченными контекстами. И ты сам с ограниченным контекстом. И вам надо достичь какой-то общей большой цели, но вы каждый видите свои пути. И вот надо всем объяснить, что ты не враг. Показать свой контекст. Убедить их показать свои тебе. И дальше договариваться, как же поступить оптимально. И это непрерывная работа.
Но иногда, даже держа в голове эти мысли, тимлид может решить, что М2 ведёт какую-то хитрую политическую игру, ведь решения всё ещё не логичны. Может и так. Но скорее всего, М2 просто подумал на много шагов вперед и учел риски, которые тимлиду даже в голову не приходили (он банально меньше знает вширь, но больше вглубь, да).
В целом, я, например, даже пытаюсь объяснять свои решения тимлидам. Но, во-первых, не всегда об этом думаю, во-вторых, не всегда нахожу силы, в-третьих, всё равно иногда вижу реакцию типа "ага, ну я понял, как _на_самом_деле_, но буду транслировать твою версию, я тебя раскусил".
М2 это работать почти никак не мешает. Просто иногда тимлидов заносит и надо их поправлять. А вот тимлиду изменение майндсета на М2 может помочь вырасти на следующую ступеньку.
P.S.:
Kind reminder, что вы можете связаться со мной через бота в описании, он звездочек не просит.
❤10🔥7👎3👍2
Руководитель и код. Часть 1/2
Банальную и понятную фразу сейчас напишу: да, навыки работы с технологиями стремительно показывают отрицательный рост у руководителей😀 . Но правда ли всё так плохо? И у всех ли это так?
Я видел и вижу разных руководителей, среди них бывают и такие:
- руководитель супер технической команды — почти всегда это больше техлид, но тем не менее и с бизнесом пообщаться, и в people managment нужно немного уметь;
- топ-менеджеры в различных компаниях, которые не против и покодить между делом (естественно, не супер много).
Но, конечно же, чаще всего у руководителей полно различной работы, и код здесь почти не в приоритете 🥺. И дело не в том, что задач на разработку нет, они есть, их дофига, они не вмещаются в твою команду, но если ты начнёшь писать код — ты начнёшь терять фокус с чего-то другого, например, с ресурсного состояния людей в команде. Далеко не всегда грамотный руководитель может позволить себе такую роскошь🤓 .
Как мне видится, то, что я плохо начинаю понимать за технологии, ужасно, если захочу перекатиться обратно — будет не так просто это сделать, нужно заново вникать в суть работы разработчика/инженера. Тем не менее, современные AI помощники очень классно помогают поддерживать тонус, поэтому это проблема меня 5-ти летней давности. Ну и у меня есть люди в команде, которые, честно говоря, всегда с радостью поделятся знаниями. Так, например, я недавно понял, что я чот не понимаю в роторных эмбедингах, и мне ребята быстро объяснили за них🌿 !
Что более важно, как мне кажется, в самом руководителе, это умение быстро докапываться до сути и балансировать приоритеты. Если ты в чём-то не разбираешься — найти и пройти оптимальный путь до хорошего осознания. Если у тебя планы на следующий квартал не готовы, то какой код, Антон, ты чего. Если это есть, то и код быстро восстановится, как мне кажется.
Я буду как блогер😀 : давайте на этом посте мы наберём 40 реакций 🔥 и я рассказываю, каким образом я недавно променял все свои менеджерские задачки на код (на недельку так) и почему без этого было никак 😺 .
Банальную и понятную фразу сейчас напишу: да, навыки работы с технологиями стремительно показывают отрицательный рост у руководителей
Я видел и вижу разных руководителей, среди них бывают и такие:
- руководитель супер технической команды — почти всегда это больше техлид, но тем не менее и с бизнесом пообщаться, и в people managment нужно немного уметь;
- топ-менеджеры в различных компаниях, которые не против и покодить между делом (естественно, не супер много).
Но, конечно же, чаще всего у руководителей полно различной работы, и код здесь почти не в приоритете 🥺. И дело не в том, что задач на разработку нет, они есть, их дофига, они не вмещаются в твою команду, но если ты начнёшь писать код — ты начнёшь терять фокус с чего-то другого, например, с ресурсного состояния людей в команде. Далеко не всегда грамотный руководитель может позволить себе такую роскошь
Как мне видится, то, что я плохо начинаю понимать за технологии, ужасно, если захочу перекатиться обратно — будет не так просто это сделать, нужно заново вникать в суть работы разработчика/инженера. Тем не менее, современные AI помощники очень классно помогают поддерживать тонус, поэтому это проблема меня 5-ти летней давности. Ну и у меня есть люди в команде, которые, честно говоря, всегда с радостью поделятся знаниями. Так, например, я недавно понял, что я чот не понимаю в роторных эмбедингах, и мне ребята быстро объяснили за них
Что более важно, как мне кажется, в самом руководителе, это умение быстро докапываться до сути и балансировать приоритеты. Если ты в чём-то не разбираешься — найти и пройти оптимальный путь до хорошего осознания. Если у тебя планы на следующий квартал не готовы, то какой код, Антон, ты чего. Если это есть, то и код быстро восстановится, как мне кажется.
Я буду как блогер
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥82❤4🏆3👎2🤩1
This media is not supported in your browser
VIEW IN TELEGRAM
Кэширование для самых маленьких
Вай-вай-вай, наткнулся на классную вводную статью про кэширование🌿 . Такую показываешь на первом курсе или в школе — и сразу людям чуточку понятнее становится, почему так много типов памяти, какая вообще бывает и т.д. Под конец: локальность кэширования, немного слов про LIFO, LRU, Time-aware LRU.
Я бы не писал про столь простую статью сюда, но там, друзья, такие классные интерактивные анимации, что меня пленило. Попробуйте и вы!
Ну а если вы не знаете, что такое cache miss, то пора бы узнать🤓 !
Ссылка на статью: https://planetscale.com/blog/caching
В общем, скидываю бабушке, а дальше быстренькая лекция ей про локальность вычислений для cuda-ядер. Как план?
Вай-вай-вай, наткнулся на классную вводную статью про кэширование
Я бы не писал про столь простую статью сюда, но там, друзья, такие классные интерактивные анимации, что меня пленило. Попробуйте и вы!
Ну а если вы не знаете, что такое cache miss, то пора бы узнать
Ссылка на статью: https://planetscale.com/blog/caching
В общем, скидываю бабушке, а дальше быстренькая лекция ей про локальность вычислений для cuda-ядер. Как план?
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥25❤8✍2👎2
This media is not supported in your browser
VIEW IN TELEGRAM
Как работают устройства хранения
Я чот зачитался блога из поста выше😍 . И хочу отметить ещё одну очень классную статью, уже не то, чтобы прям для самых маленьких (но и для них тоже). Я концептуально понимал, как работают разные устройства хранения, но эти концепты у меня были размыты 😍 .
Кажется, статья это исправила. Тут про то, как работают ленточное хранение, HDD, SSD. Немного рассказывают про облачное хранение и проблемы с ним (но имхо, уже больше для рекламы).
Мне очень понравился раздел про проблемы с порядком хранения данных в SSD и зацепила фраза:
Опять же, отличные интерактивы🌿 : самое то для школьных уроков или пары в вузе!
Ссылка на статью: https://planetscale.com/blog/io-devices-and-latency
Я чот зачитался блога из поста выше
Кажется, статья это исправила. Тут про то, как работают ленточное хранение, HDD, SSD. Немного рассказывают про облачное хранение и проблемы с ним (но имхо, уже больше для рекламы).
Мне очень понравился раздел про проблемы с порядком хранения данных в SSD и зацепила фраза:
This demonstrates that the order in which we read and write data matters for performance. Many software engineers don't have to think about this on a day-to-day basis, but those designing software like MySQL need to pay careful attention to what structures data is being stored in and how data is laid out on disk.
Опять же, отличные интерактивы
Ссылка на статью: https://planetscale.com/blog/io-devices-and-latency
Please open Telegram to view this post
VIEW IN TELEGRAM
❤4👍2👎2🔥2🤯1
Влияние LLM на продуктивность опытных разработчиков
Статья: https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
Утверждается:
Уже хотелось поверить, проваливаемся внутрь блога, видим:
Ну и скриншот уже из статьи.
И к чему такие громкие заголовки или я чот не понял?
В целом и правда когда ты только начинаешь работать с LLM, то думаешь, ну ща она перелопатит весь проект и всё будет класс. Но, кажется, пока так не работает. Кто знает, что будет в следующем году — посмотрим.
Статья: https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
Утверждается:
Surprisingly, we find that when developers use AI tools, they take 19% longer than without—AI makes them slower.
Уже хотелось поверить, проваливаемся внутрь блога, видим:
It also may be the case that there are strong learning effects for AI tools like Cursor that only appear after several hundred hours of usage—our developers typically only use Cursor for a few dozen hours before and during the study.
Ну и скриншот уже из статьи.
И к чему такие громкие заголовки или я чот не понял?
В целом и правда когда ты только начинаешь работать с LLM, то думаешь, ну ща она перелопатит весь проект и всё будет класс. Но, кажется, пока так не работает. Кто знает, что будет в следующем году — посмотрим.
🔥12👎6💯3👀2❤1👍1
Планы планы планы
Итак, закончился очередной отчётный период, пора бы уже начать новые дела какие-то делать. Но какие? Как говорится, нужон план🤓 .
Я помню, еще на прошлой работе делал первый план работы по направлению. И слева подошёл, и сбоку, и снизу подглядел, но всё-таки родил какой-никакой план. Гордый результатами своих трудов за несколько фулл-тайм дней приношу их к своему руководителю и получаю: "Не, ну это не план"😊 . На секундочку, тогда у меня был список шагов, без какой-либо конкретики, задач хватало от силы на 2-3 недели, и без каких-либо целей и сроков.
Тогда я усвоил для себя один из уроков: список задач/целей/направлений — это еще не план, это просто список. План должен что-то про сроки говорить, про то, зачем это вообще делается, и как будет оцениваться успех.
После много лет утекло, планы как-то писались и что-то даже получалось (по крайней мере, вопросов не так много было). Я уже снова успел побывать разработчиком🤔 , обратно перекатился в лиды — и снова эти планы. В поте лица написал огромную тираду амбициозных планов по всем канонам, с какими-то там сроками! Вам не показалось — она была и правда ОГРОМНОЙ 👨🦳 .
Тут другой урок: планы должны быть компактными, но с возможностью детализации. Часто мало кому нужно понимать, что через пару недель нужно обновить компоненту X в сервисе Y. В этом аспекте я очень люблю наставление моего руководителя: план должен состоять из 3-5 фокусов, чтобы у человека сложилось общее понимание, что происходит. При необоходимости — можно углубляться, но часто это нужно уже самому тебе.
Ну вот и построил ты свои планы. А через пару недель они сломались❓ . Где-то человек заболел, где-то обстоятельства поменялись. Одним словом — риски, форс-мажоры и внешние факторы. Связаны могут как с людьми, так с технологиями и, в целом, с бизнесом.
Урок следующий — планы должны быть гибкими. Это позволяет митигировать риски, о которых просто не подумал/упустил (а обязательно что-то пройдёт мимо). Подумать про запасные варианты, различные случаи — это всегда полезно и часто важно.
Лично у меня в R&D всегда было так🏥 . А у вас как? Пишете планы? Получается?
P.S. самое важное: план — это не что-то прибитое гвоздями, но неплохо, чтобы он был +- стабилен🌿 .
Итак, закончился очередной отчётный период, пора бы уже начать новые дела какие-то делать. Но какие? Как говорится, нужон план
Я помню, еще на прошлой работе делал первый план работы по направлению. И слева подошёл, и сбоку, и снизу подглядел, но всё-таки родил какой-никакой план. Гордый результатами своих трудов за несколько фулл-тайм дней приношу их к своему руководителю и получаю: "Не, ну это не план"
Тогда я усвоил для себя один из уроков: список задач/целей/направлений — это еще не план, это просто список. План должен что-то про сроки говорить, про то, зачем это вообще делается, и как будет оцениваться успех.
После много лет утекло, планы как-то писались и что-то даже получалось (по крайней мере, вопросов не так много было). Я уже снова успел побывать разработчиком
Тут другой урок: планы должны быть компактными, но с возможностью детализации. Часто мало кому нужно понимать, что через пару недель нужно обновить компоненту X в сервисе Y. В этом аспекте я очень люблю наставление моего руководителя: план должен состоять из 3-5 фокусов, чтобы у человека сложилось общее понимание, что происходит. При необоходимости — можно углубляться, но часто это нужно уже самому тебе.
Ну вот и построил ты свои планы. А через пару недель они сломались
Урок следующий — планы должны быть гибкими. Это позволяет митигировать риски, о которых просто не подумал/упустил (а обязательно что-то пройдёт мимо). Подумать про запасные варианты, различные случаи — это всегда полезно и часто важно.
Лично у меня в R&D всегда было так
P.S. самое важное: план — это не что-то прибитое гвоздями, но неплохо, чтобы он был +- стабилен
Please open Telegram to view this post
VIEW IN TELEGRAM
👍13❤5👎2🔥2
N айтишниц нашли в баре Антона
Меня позволи в свою рубрику N айтишниц и в формате небольшого интервью рассказал про свою жизу😍
Порции мотивашки раздал здесь: https://t.me/n_it_girls/358
В тексте есть спойлер, что послужило мотивацией написать пост: https://t.me/blog_toxa/391
Меня позволи в свою рубрику N айтишниц и в формате небольшого интервью рассказал про свою жизу
Порции мотивашки раздал здесь: https://t.me/n_it_girls/358
В тексте есть спойлер, что послужило мотивацией написать пост: https://t.me/blog_toxa/391
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
N айтишниц заходят в бар
Сегодняшний гость рубрики #Типичный_айтишник – человек, у которого был план, и он ему следовал. Знакомьтесь, Антон.
- Кто ты и что делаешь?
Я Антон, сейчас руковожу командой распознавания текста в VLM в Яндексе. Мы стараемся наделить языковую модель…
- Кто ты и что делаешь?
Я Антон, сейчас руковожу командой распознавания текста в VLM в Яндексе. Мы стараемся наделить языковую модель…
🔥26❤6🐳5👎2✍1💯1
Давайте поболтаем 😍
Что-то хочется немного похоливарить или просто пообщаться сегодня вечером в комментах.
Вот вам вопрос:
Самая кринж статья последнего полугодия? Не обязательно только про статьи из arxiv.org
Что-то хочется немного похоливарить или просто пообщаться сегодня вечером в комментах.
Вот вам вопрос:
Самая кринж статья последнего полугодия? Не обязательно только про статьи из arxiv.org
Please open Telegram to view this post
VIEW IN TELEGRAM
👎2🤗2
Руководитель и код. Часть 2/2
Мы в команде очень сильно заботимся о качественных метриках. Достаточно строго собираем наборы данных и оцениваем качество метрик, валидаторов. Вообще замеры — это очень сложная тема, требующая понимания не только того, как работаем сам процесс (данные, валидаторы и природа метрик), но и то, как всё работает под капотом: какой режим семплирования, какой бэкенд используется, на каком железе, есть ли батчевание и т.д. И ясное дело за всем уследить не всегда возможно.
И тут возникли проблемы разного характера из мира инженерии, в абсолютно разных местах, но на KPI метриках. Где-то начало флапать, где-то онлайн (внутренний) не сходится с оффлайном на одних и тех же данных. В общем, какой-то бред.
По людям история такая: кто-то ушёл в отпуск, кому-то нужно допинать текущие задачи, кому-то просто пока не дашь эти задачи, потому что нужно починить быстро, а опыта работы именно с этим еще не было. И не то, что нельзя вырвать какого-то знающего человека из текущих задач и дать ему раздебажить проблему — всё-таки важные KPI метрики. Просто только-только случился очередной релиз и хочется дать ребяткам выдохнуть, да и тем более я сам понимал, что примерно нужно копать. Посмотрел по своим приоритетам, поранжировал, решил, что нужно мне сделать.
Спойлер: решил обе задачи. С флапающими тестами всё сложно, описывать не буду, а вот про оффлайн и онлайн рассказать можно. В режиме фоновых задач запускали эксперименты, где пытались зафиксировать стейт данных. И вот уже всё фиксированное — но числа разные.
Ну бред, думаю я. А потом вспоминаю, что оффлайн замеряется на одном коде, а онлайн — на другом (специфика реализации). Код оффлайна читать было бессмысленно — я его читал 100500 раз и там ничего не менялось. А вот в онлайне нужно было поднапрячься.
И, к слову, баг описывает классический мем — вроде знаешь, что он есть, но как найти — ну вот фиг знает. После получаса пристального чтения кода нахожу примерно следующую конструкцию:
Ну в общем, в ситуация смешная, забыли
Но я так легко всё рассказываю. В реальности: погрузился детально во все процессы текущих тестирований, сильно больше стал понимать в инференсе для онлайна, узнал для себя несколько новых вещей. И заняли обе задачки примерно недельку неполного рабочего моего времени. Для себя вижу в том числе плюсы, что подсобрал некоторые инфраструктурные боли, которые смогу либо решить на своём уровне, либо странслировать выше (что, имхо, полезно).
Теперь я сплю спокойнее😀 . Такие дела.
В прошлом посте вы постарались набрать очень быстро необходимое число лайков. Тем не менее, пишу пост только сейчас. Вообще ваши реакции — практически единственная форма фидбека мне. Поэтому если вам что-то нравится или, наоборот, не нравится, вы смело приходите ко мне с этим (куда угодно: личка, сообщения канала, комменты). Ну и реакции ставьте😍
Мы в команде очень сильно заботимся о качественных метриках. Достаточно строго собираем наборы данных и оцениваем качество метрик, валидаторов. Вообще замеры — это очень сложная тема, требующая понимания не только того, как работаем сам процесс (данные, валидаторы и природа метрик), но и то, как всё работает под капотом: какой режим семплирования, какой бэкенд используется, на каком железе, есть ли батчевание и т.д. И ясное дело за всем уследить не всегда возможно.
И тут возникли проблемы разного характера из мира инженерии, в абсолютно разных местах, но на KPI метриках. Где-то начало флапать, где-то онлайн (внутренний) не сходится с оффлайном на одних и тех же данных. В общем, какой-то бред.
По людям история такая: кто-то ушёл в отпуск, кому-то нужно допинать текущие задачи, кому-то просто пока не дашь эти задачи, потому что нужно починить быстро, а опыта работы именно с этим еще не было. И не то, что нельзя вырвать какого-то знающего человека из текущих задач и дать ему раздебажить проблему — всё-таки важные KPI метрики. Просто только-только случился очередной релиз и хочется дать ребяткам выдохнуть, да и тем более я сам понимал, что примерно нужно копать. Посмотрел по своим приоритетам, поранжировал, решил, что нужно мне сделать.
Спойлер: решил обе задачи. С флапающими тестами всё сложно, описывать не буду, а вот про оффлайн и онлайн рассказать можно. В режиме фоновых задач запускали эксперименты, где пытались зафиксировать стейт данных. И вот уже всё фиксированное — но числа разные.
Ну бред, думаю я. А потом вспоминаю, что оффлайн замеряется на одном коде, а онлайн — на другом (специфика реализации). Код оффлайна читать было бессмысленно — я его читал 100500 раз и там ничего не менялось. А вот в онлайне нужно было поднапрячься.
И, к слову, баг описывает классический мем — вроде знаешь, что он есть, но как найти — ну вот фиг знает. После получаса пристального чтения кода нахожу примерно следующую конструкцию:
// some code
if (currentPrompt.size() == 0) {
currentPrompt = userData.content;
}
currentPrompt += userData.content;
// some code
Ну в общем, в ситуация смешная, забыли
if. Хорошо, что куда-то наружу не ухеало. Ну и замечательно, что это была единственная проблема.Но я так легко всё рассказываю. В реальности: погрузился детально во все процессы текущих тестирований, сильно больше стал понимать в инференсе для онлайна, узнал для себя несколько новых вещей. И заняли обе задачки примерно недельку неполного рабочего моего времени. Для себя вижу в том числе плюсы, что подсобрал некоторые инфраструктурные боли, которые смогу либо решить на своём уровне, либо странслировать выше (что, имхо, полезно).
Теперь я сплю спокойнее
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥22❤3👎2
Forwarded from БАШНЯ
СОЗВОН-ПОДКАСТ❗️
Новый онлайн-подкаст состоится уже 6 августа (среда) в 19:00🔥
Наш гость - Антон Клочков, руководитель R&D команды в Яндексе💸
Тема подкаста: «ML-инженерия и что из себя представляет профессия ML-инженера»👨💻
О чем поговорим?
🟣 Чем интересная профессия ML-инженера?
🟣 Как эффективно расти в сфере ML-инженерии?
🟣 Как вырасти из линейного сотрудника до руководителя команды?
Не пропусти! И не забудь позвать своих друзей и коллег💖
Новый онлайн-подкаст состоится уже 6 августа (среда) в 19:00
Наш гость - Антон Клочков, руководитель R&D команды в Яндексе
Тема подкаста: «ML-инженерия и что из себя представляет профессия ML-инженера»
О чем поговорим?
Не пропусти! И не забудь позвать своих друзей и коллег
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥12💯6🏆5👎2
Intern-S1
В мультимодалках пополнение:
— 235B MoE LLM (Qwen3) + 6B Vis Encoder (InternViT);
— 5T мультимодальных токенов в обучении;
— Thinking и Non-Thinking Modes;
— По уровню такая же или чуть лучше текущих опенсорсов, как по мне, по идее хуже gemini 2.5 pro;
— Бенчмарков маловато, хотелось бы побольше общеупотребимых, будем ждать народного инференса;
— Важным выделяют то, что половина трейна — это научные данные.
Страничка на HF: https://huggingface.co/internlm/Intern-S1
Тех репорт: ждём🙂
Потыкаться можно здесь: https://chat.intern-ai.org.cn/
Если кто-то развернёт у себя на маке, скиньте гайд, тож попробую😀
В мультимодалках пополнение:
— 235B MoE LLM (Qwen3) + 6B Vis Encoder (InternViT);
— 5T мультимодальных токенов в обучении;
— Thinking и Non-Thinking Modes;
— По уровню такая же или чуть лучше текущих опенсорсов, как по мне, по идее хуже gemini 2.5 pro;
— Бенчмарков маловато, хотелось бы побольше общеупотребимых, будем ждать народного инференса;
— Важным выделяют то, что половина трейна — это научные данные.
Страничка на HF: https://huggingface.co/internlm/Intern-S1
Тех репорт: ждём
Потыкаться можно здесь: https://chat.intern-ai.org.cn/
Если кто-то развернёт у себя на маке, скиньте гайд, тож попробую
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥9👎2❤1