Forwarded from Лечим эйай
9 девушек и 1 месяц
Последнее время часто ловлю себя на раздражении вот в какой ситуации. Однажды настает четкое понимание, что какой-то процесс в компании работает не правильно и даже обнаруживается понимание как сделать так, чтобы его починить. И в этот момент ты инициируешь процесс перестройки. И для меня это самый сложный период. Когда ты уже знаешь как должно быть, но чтобы так стало - тебе нужно время, а иногда очень много времени, ведь есть задачи, которые реализуются неделями и месяцами. И, конечно, в этот момент появляется множество коллег, которые тоже догадались, что что-то работает не так и через день тебе на это указывают, словно ты сам этого не понимаешь. Ты снова и снова объясняешь, что уже давно догадался и запустил починку, но это требует больше времени. И так по кругу.
Одной из неочевидных, скорее ментальных, сложностей руководящей позиции является то, что для роста, как личного, так и командного, приходится научиться не залазить руками в решение задач. Сегодня ты можешь сам решить эту задачу за сутки, а твой коллега за неделю и в этот момент нужно найти в себе силы не сделать самому, а сделать так, чтобы в следующий раз срок был не семь, а пять дней. И тогда команда растет, и вы вместе можете делать куда больше, и компания не ограничена возможностями твоего микроменеджмента. И приходится учиться ждать. И жить в этом переходном моменте, когда ты абсолютно точно знаешь как будет лучше, но "когда" утекает сквозь пальцы. Именно поэтому абсолютно иной драйв в командах на пять человек, когда между "подумал" и "сделал" промежуток минимален.
Из неочевидных переживаний под конец года.
@lechim_ai
Последнее время часто ловлю себя на раздражении вот в какой ситуации. Однажды настает четкое понимание, что какой-то процесс в компании работает не правильно и даже обнаруживается понимание как сделать так, чтобы его починить. И в этот момент ты инициируешь процесс перестройки. И для меня это самый сложный период. Когда ты уже знаешь как должно быть, но чтобы так стало - тебе нужно время, а иногда очень много времени, ведь есть задачи, которые реализуются неделями и месяцами. И, конечно, в этот момент появляется множество коллег, которые тоже догадались, что что-то работает не так и через день тебе на это указывают, словно ты сам этого не понимаешь. Ты снова и снова объясняешь, что уже давно догадался и запустил починку, но это требует больше времени. И так по кругу.
Одной из неочевидных, скорее ментальных, сложностей руководящей позиции является то, что для роста, как личного, так и командного, приходится научиться не залазить руками в решение задач. Сегодня ты можешь сам решить эту задачу за сутки, а твой коллега за неделю и в этот момент нужно найти в себе силы не сделать самому, а сделать так, чтобы в следующий раз срок был не семь, а пять дней. И тогда команда растет, и вы вместе можете делать куда больше, и компания не ограничена возможностями твоего микроменеджмента. И приходится учиться ждать. И жить в этом переходном моменте, когда ты абсолютно точно знаешь как будет лучше, но "когда" утекает сквозь пальцы. Именно поэтому абсолютно иной драйв в командах на пять человек, когда между "подумал" и "сделал" промежуток минимален.
Из неочевидных переживаний под конец года.
@lechim_ai
Forwarded from LLM под капотом
AI Coding - итоги разработки ERC3 платформы
Итак, платформа для соревновательного тестирования агентов запущена, и получилась достаточно сложная (глянуть тут). Там есть бенчмарки, визуализация, API c SDK. Всем этим пользуются команды (521 регистраций). С момента создания команды запустили 203560 оценок работы агентов, каждая - в своей независимой симуляции.
Все это я разработал сам. Но без AI Coding все вытянуть бы не получилось. Примерно 600%-700% процентов кода платформы написали OpenAI Codex (Web версия), Claude Code CLI, Github Copilot.
Почему 600-700%? Потому, что много переписывалось просто потому, что мне казалось, что новая версия будет чище, проще или элегантнее. Вручную это делать бы лень, но когда есть AI инструменты - все идет проще.
У нас было такое разделение обязанностей в команде:
(1) Человек - показывает, как правильно делать. Следит за тем, чтобы архитектура, инструкции были четкими и непротиворечивыми. Держит агентов на очень коротком поводке. Если нужно - чистит тех долг.
(2) OpenAI Codex - анализ сложных задач, работа с инфраструктурой и backend, планирование. Всегда работает в режиме x4 (запуск 4х версий), а я выбираю лучшую.
(3) Claude Code - работа с интерфейсами, мелкие фичи и повседневная разработка. Обычно в параллели крутятся 2-3 сессии, которые работают над своими задачами.
(4) Github Copilot - исключительно как умный autocomplete.
При этом человек всегда несет ответственность за код, который отправляется в main.
Жизнь упрощал стэк, который я подобрал экспериментально именно под такой командный состав и мои хотелки про эргономику работы. Go для backend (gin/SQLite), HTMX для интерактивности и тестируемости агентами, Python для SDK и аналитики. Вся платформа компилируется в один единственный бинарь и деплоится под NixOS с Caddy (c ARM64 процессорами из интереса). Стили свои с нуля - Claude cобрал Style guide, превратил в фреймворк и натянул на платформу.
Инструкций особенных не было. Только AICODE-* заметки, использование планов в сложных задачах и императив на “будьте практичными, используйте только те паттерны, которые уже есть в коде, не тащите всякую каку из интернета”. Но и несмотря на такую инструкцию, агенты периодически начинали лить воду - городили ненужные абстракции, функции и классы. Приходилось периодически засучивать рукава и чистить все это. Чем больше развивался проект, тем это нужно было реже, т.к. накапливалась критическая масса примеров того, как нужно делать правильно.
После выкатки платформы, ее внезапно все начали использовать очень активно. Пошел быстрый feedback по глюкам и ошибкам. Тут очень хорошо помог настроенный комбайн. Достаточно было скопировать хотелку, баг репорт или stack trace в агента, чтобы быстро увидеть причину, а потом и быстро ее пофиксить и выкатить.
Самым приятном хайлайтом было, когда в определенный момент нагрузка на сервер достигла 25%, и я сказал “Клод, дорогой, вот тебе строка для подключения go pprof. Выясни, что так грузит сервер и предложи мне минимальный фикс для этого”. Спустя минут пять нагрузка упала до приемлемых для меня 6%
Дальше я собираюсь переписать все с нуля, чтобы заложить большую масштабируемость, упростить архитектуру и добавить возможность запускать более разнообразные бенчмарки. Год назад я бы не рискнул, а теперь AI существенно меняет экономику разработки. Одно переписывание больше погоды не делает. Не человеку же писать весь этот код. А вычитывать - сильно проще. Особенно, когда архитектура и стэк позволяют ужимать код.
А у вас заходит AI Coding/Vibe Coding? Расскажите про свои проекты, в которых вам помогал AI. Какие инструменты использовали, какой стэк там был, и как этими проектами теперь пользуются люди? Сколько токенов уходит в месяц?
Ваш, @llm_under_hood 🤗
Итак, платформа для соревновательного тестирования агентов запущена, и получилась достаточно сложная (глянуть тут). Там есть бенчмарки, визуализация, API c SDK. Всем этим пользуются команды (521 регистраций). С момента создания команды запустили 203560 оценок работы агентов, каждая - в своей независимой симуляции.
Все это я разработал сам. Но без AI Coding все вытянуть бы не получилось. Примерно 600%-700% процентов кода платформы написали OpenAI Codex (Web версия), Claude Code CLI, Github Copilot.
Почему 600-700%? Потому, что много переписывалось просто потому, что мне казалось, что новая версия будет чище, проще или элегантнее. Вручную это делать бы лень, но когда есть AI инструменты - все идет проще.
У нас было такое разделение обязанностей в команде:
(1) Человек - показывает, как правильно делать. Следит за тем, чтобы архитектура, инструкции были четкими и непротиворечивыми. Держит агентов на очень коротком поводке. Если нужно - чистит тех долг.
(2) OpenAI Codex - анализ сложных задач, работа с инфраструктурой и backend, планирование. Всегда работает в режиме x4 (запуск 4х версий), а я выбираю лучшую.
(3) Claude Code - работа с интерфейсами, мелкие фичи и повседневная разработка. Обычно в параллели крутятся 2-3 сессии, которые работают над своими задачами.
(4) Github Copilot - исключительно как умный autocomplete.
При этом человек всегда несет ответственность за код, который отправляется в main.
Жизнь упрощал стэк, который я подобрал экспериментально именно под такой командный состав и мои хотелки про эргономику работы. Go для backend (gin/SQLite), HTMX для интерактивности и тестируемости агентами, Python для SDK и аналитики. Вся платформа компилируется в один единственный бинарь и деплоится под NixOS с Caddy (c ARM64 процессорами из интереса). Стили свои с нуля - Claude cобрал Style guide, превратил в фреймворк и натянул на платформу.
Инструкций особенных не было. Только AICODE-* заметки, использование планов в сложных задачах и императив на “будьте практичными, используйте только те паттерны, которые уже есть в коде, не тащите всякую каку из интернета”. Но и несмотря на такую инструкцию, агенты периодически начинали лить воду - городили ненужные абстракции, функции и классы. Приходилось периодически засучивать рукава и чистить все это. Чем больше развивался проект, тем это нужно было реже, т.к. накапливалась критическая масса примеров того, как нужно делать правильно.
После выкатки платформы, ее внезапно все начали использовать очень активно. Пошел быстрый feedback по глюкам и ошибкам. Тут очень хорошо помог настроенный комбайн. Достаточно было скопировать хотелку, баг репорт или stack trace в агента, чтобы быстро увидеть причину, а потом и быстро ее пофиксить и выкатить.
Самым приятном хайлайтом было, когда в определенный момент нагрузка на сервер достигла 25%, и я сказал “Клод, дорогой, вот тебе строка для подключения go pprof. Выясни, что так грузит сервер и предложи мне минимальный фикс для этого”. Спустя минут пять нагрузка упала до приемлемых для меня 6%
Дальше я собираюсь переписать все с нуля, чтобы заложить большую масштабируемость, упростить архитектуру и добавить возможность запускать более разнообразные бенчмарки. Год назад я бы не рискнул, а теперь AI существенно меняет экономику разработки. Одно переписывание больше погоды не делает. Не человеку же писать весь этот код. А вычитывать - сильно проще. Особенно, когда архитектура и стэк позволяют ужимать код.
А у вас заходит AI Coding/Vibe Coding? Расскажите про свои проекты, в которых вам помогал AI. Какие инструменты использовали, какой стэк там был, и как этими проектами теперь пользуются люди? Сколько токенов уходит в месяц?
Ваш, @llm_under_hood 🤗
Forwarded from Свет из чёрного ящика
Подборка статей 2025 (часть 1)
Как и обещал, выкладываю подборку статей по темам, которые освещал на выступлении.
End2End
- OneRec: Unifying Retrieve and Rank with Generative Recommender and Iterative Preference Alignment
- OneRec Technical Report
- OneRec-V2 Technical Report
- OneLoc: Geo-Aware Generative Recommender Systems for Local Life Service
- OneSug: The Unified End-to-End Generative Framework for E-commerce Query Suggestion
- OneSearch: A Preliminary Exploration of the Unified End-to-End Generative Framework for E-commerce Search
- UniSearch: Rethinking Search System with a Unified Generative Architecture
- EGA-V1: Unifying Online Advertising with End-to-End Learning
- EGA-V2: An End-to-end Generative Framework for Industrial Advertising
- GPR: Towards a Generative Pre-trained One-Model Paradigm for Large-Scale Advertising Recommendation
LLM + RecSys
- PLUM: Adapting Pre-trained Language Models for Industrial-scale Generative Recommendations
- OneRec-Think: In-Text Reasoning for Generative Recommendation
- Align3GR: Unified Multi-Level Alignment for LLM-based Generative Recommendation
- GFlowGR: Fine-tuning Generative Recommendation Frameworks with Generative Flow Networks
Масштабирование
- LONGER: Scaling Up Long Sequence Modeling in Industrial Recommenders
- Scaling Generative Recommendations with Context Parallelism on Hierarchical Sequential Transducers
- Twin-Flow Generative Ranking Network for Recommendation
- InterFormer: Effective Heterogeneous Interaction Learning for Click-Through Rate Prediction
- MARM: Unlocking the Recommendation Cache Scaling-Law through Memory Augmentation and Scalable Complexity
- TBGRecall: A Generative Retrieval Model for E-commerce Recommendation Scenarios
- RankMixer: Scaling Up Ranking Models in Industrial Recommenders
- Climber: Toward Efficient Scaling Laws for Large Recommendation Models
- MTGR: Industrial-Scale Generative Recommendation Framework in Meituan
- Action is All You Need: Dual-Flow Generative Ranking Network for Recommendation
- Meta’s Generative Ads Model (GEM): The Central Brain Accelerating Ads Recommendation AI Innovation
- OneTrans: Unified Feature Interaction and Sequence Modeling with One Transformer in Industrial Recommender
- Massive Memorization with Hundreds of Trillions of Parameters for Sequential Transducer Generative Recommenders
- From Features to Transformers: Redefining Ranking for Scalable Impact
- From Scaling to Structured Expressivity: Rethinking Transformers for CTR Prediction
- Scaling Transformers for Discriminative Recommendation via Generative Pretraining
- Meta Lattice: Model Space Redesign for Cost-Effective Industry-Scale Ads Recommendations
Как и обещал, выкладываю подборку статей по темам, которые освещал на выступлении.
End2End
- OneRec: Unifying Retrieve and Rank with Generative Recommender and Iterative Preference Alignment
- OneRec Technical Report
- OneRec-V2 Technical Report
- OneLoc: Geo-Aware Generative Recommender Systems for Local Life Service
- OneSug: The Unified End-to-End Generative Framework for E-commerce Query Suggestion
- OneSearch: A Preliminary Exploration of the Unified End-to-End Generative Framework for E-commerce Search
- UniSearch: Rethinking Search System with a Unified Generative Architecture
- EGA-V1: Unifying Online Advertising with End-to-End Learning
- EGA-V2: An End-to-end Generative Framework for Industrial Advertising
- GPR: Towards a Generative Pre-trained One-Model Paradigm for Large-Scale Advertising Recommendation
LLM + RecSys
- PLUM: Adapting Pre-trained Language Models for Industrial-scale Generative Recommendations
- OneRec-Think: In-Text Reasoning for Generative Recommendation
- Align3GR: Unified Multi-Level Alignment for LLM-based Generative Recommendation
- GFlowGR: Fine-tuning Generative Recommendation Frameworks with Generative Flow Networks
Масштабирование
- LONGER: Scaling Up Long Sequence Modeling in Industrial Recommenders
- Scaling Generative Recommendations with Context Parallelism on Hierarchical Sequential Transducers
- Twin-Flow Generative Ranking Network for Recommendation
- InterFormer: Effective Heterogeneous Interaction Learning for Click-Through Rate Prediction
- MARM: Unlocking the Recommendation Cache Scaling-Law through Memory Augmentation and Scalable Complexity
- TBGRecall: A Generative Retrieval Model for E-commerce Recommendation Scenarios
- RankMixer: Scaling Up Ranking Models in Industrial Recommenders
- Climber: Toward Efficient Scaling Laws for Large Recommendation Models
- MTGR: Industrial-Scale Generative Recommendation Framework in Meituan
- Action is All You Need: Dual-Flow Generative Ranking Network for Recommendation
- Meta’s Generative Ads Model (GEM): The Central Brain Accelerating Ads Recommendation AI Innovation
- OneTrans: Unified Feature Interaction and Sequence Modeling with One Transformer in Industrial Recommender
- Massive Memorization with Hundreds of Trillions of Parameters for Sequential Transducer Generative Recommenders
- From Features to Transformers: Redefining Ranking for Scalable Impact
- From Scaling to Structured Expressivity: Rethinking Transformers for CTR Prediction
- Scaling Transformers for Discriminative Recommendation via Generative Pretraining
- Meta Lattice: Model Space Redesign for Cost-Effective Industry-Scale Ads Recommendations
Forwarded from Тимлид Очевидность | Евгений Антонов
Я принес. бесплатная серия лекций о том, как делать бренд работодателя
Я знаю, что меня читает некоторое количество деврелов, эйчаров и ребят, которые состоят в ПК конференций, митапов, сообществ и занимаются публичными выступлениями.
Сегодня я вам принес бесплатную серию лекций про бренд работодателя, амбассадорство, внутренний бренд, метрики, стратегию бренда и прочее https://www.youtube.com/playlist?list=PLvLg14Mg-lsVxvC_Hsk6bECB7U8M8tbTF
Там всё разбито по частям так, что, на мой взгляд, легко вычленить то, что нужно какой-то конкретной позиции, не просматривая все 18 видео.
Делала эти лекции Вероника Ильина (но читает не только она), а качеству её материала я доверяю.
Я знаю, что меня читает некоторое количество деврелов, эйчаров и ребят, которые состоят в ПК конференций, митапов, сообществ и занимаются публичными выступлениями.
Сегодня я вам принес бесплатную серию лекций про бренд работодателя, амбассадорство, внутренний бренд, метрики, стратегию бренда и прочее https://www.youtube.com/playlist?list=PLvLg14Mg-lsVxvC_Hsk6bECB7U8M8tbTF
Там всё разбито по частям так, что, на мой взгляд, легко вычленить то, что нужно какой-то конкретной позиции, не просматривая все 18 видео.
Делала эти лекции Вероника Ильина (но читает не только она), а качеству её материала я доверяю.
Telegram
Вероника отвечает
Здесь человек про людей в IT отвечает и говорит о своей работе и IT в принципе.
Задать вопросы и рассказать, в чём я не права, можно по адресу @catwomenko. О рекламе спрашивать не надо — не размещу.
Ссылка на ссылки: https://linktr.ee/catwomenko
Задать вопросы и рассказать, в чём я не права, можно по адресу @catwomenko. О рекламе спрашивать не надо — не размещу.
Ссылка на ссылки: https://linktr.ee/catwomenko
Forwarded from Quant Valerian
Итак, долгожданный, надеюсь, ответ на дилемму Diversity vs Culture Fit — что же лучше?
Преимущества diversity:
- под разные задачи можно найти желающих их сделать
- при генерации идей видим проблему из большего количества контекстов
- лучшее понимание рынка, т.к. представлено больше когорт
Преимущества culture fit:
- людям нравится работать друг с другом
- члены команды эффективнее коммуницируют (понимают друг друга лучше, не испытывают сопротивления началу общения)
- примерно одинаково представляют себе качество работы (нет такого, что один сильно медленнее другого, что зачастую демотивирует и разрушает команду)
Мой ответ, можно сказать, пробили в комментариях. Ответ лежит где-то посередине.
Я не согласен, что diversity не противоречит culture fit. Это прямо по определению противоположные вещи (мультикультурализм против носителей одной культуры).
Однако думаю, что это не бинарная функция. Четкого и правильного ответа, где должна лежать граница, у меня нет. Да и если кто-то вам скажет, что у него есть, не слушайте этого человека, он склонен к заблуждениям.
Скорее всего, влияют факторы компании, задач, существующего состава команды, а особенно личности руководителя. Правильный баланс нащупывается только опытным путем. А хороший руководитель должен уметь держать эту дилемму в голове и жить с ней. Это будет балансировать его самого изнутри.
Касательно моего персонального опыта, работа в менее разнообразных и более культурно общих командах для меня была всегда комфортнее и приносила больше удовольствия. В таких командах рождается какая-то более прочная связь между сотрудниками.
Хотелось бы также заявить, что и эффективность выше была в таких командах. Но здесь есть два момента: мы не можем честно сравнить и поставить чистый эксперимент, а ещё я отношусь к культуре очень увлеченных работников, соответственно мои лучшие команды были такими же.
В роли руководителя я с годами также всё больше смещаюсь в сторону culture fit, но гораздо лучше вижу и чувствую потребность в разных взглядах и подходах. Поэтому здесь нужно быть очень аккуратным.
А какой у вас опыт? В каких командах было лучше? Какие команды работали эффективнее?
Преимущества diversity:
- под разные задачи можно найти желающих их сделать
- при генерации идей видим проблему из большего количества контекстов
- лучшее понимание рынка, т.к. представлено больше когорт
Преимущества culture fit:
- людям нравится работать друг с другом
- члены команды эффективнее коммуницируют (понимают друг друга лучше, не испытывают сопротивления началу общения)
- примерно одинаково представляют себе качество работы (нет такого, что один сильно медленнее другого, что зачастую демотивирует и разрушает команду)
Мой ответ, можно сказать, пробили в комментариях. Ответ лежит где-то посередине.
Я не согласен, что diversity не противоречит culture fit. Это прямо по определению противоположные вещи (мультикультурализм против носителей одной культуры).
Однако думаю, что это не бинарная функция. Четкого и правильного ответа, где должна лежать граница, у меня нет. Да и если кто-то вам скажет, что у него есть, не слушайте этого человека, он склонен к заблуждениям.
Скорее всего, влияют факторы компании, задач, существующего состава команды, а особенно личности руководителя. Правильный баланс нащупывается только опытным путем. А хороший руководитель должен уметь держать эту дилемму в голове и жить с ней. Это будет балансировать его самого изнутри.
Касательно моего персонального опыта, работа в менее разнообразных и более культурно общих командах для меня была всегда комфортнее и приносила больше удовольствия. В таких командах рождается какая-то более прочная связь между сотрудниками.
Хотелось бы также заявить, что и эффективность выше была в таких командах. Но здесь есть два момента: мы не можем честно сравнить и поставить чистый эксперимент, а ещё я отношусь к культуре очень увлеченных работников, соответственно мои лучшие команды были такими же.
В роли руководителя я с годами также всё больше смещаюсь в сторону culture fit, но гораздо лучше вижу и чувствую потребность в разных взглядах и подходах. Поэтому здесь нужно быть очень аккуратным.
А какой у вас опыт? В каких командах было лучше? Какие команды работали эффективнее?
Forwarded from Dataism
🌈Каждый аналитик желает знать, что там по юнит-экономике
Как вы могли заметить, в последнее время у меня начался цикл постов про продуктовую внутрянку.
Метрики/пирамиды/деревья/травка - это хорошо.
Но все это меркнет и бледнеет без самого важного — юнит-экономики.
И да, это снова тема, в которой продуктовый аналитик тоже должен шарить, если не хочет быть просто «аналитиком-калькулятором».
Поехали:
https://www.youtube.com/watch?v=3fjOFBIpj9Y - разговор Ильи Красинского и Глеба Кудрявцева. Легкое введение и общие понятия.
https://gopractice.ru/product/unit-economics/ - статья на Go Practice, там же найдете шаблон расчета юнит-экономики от Ильи.
https://www.youtube.com/watch?v=h8VWl0GFW3Y&t=3s - снова лекция Яндекса в рамках школы менеджеров. Илья Красинский. Старое видео, но все еще полезное.
https://gopractice.ru/free/vid_zabudko_smirnov/ - снова Go Practice, но уже видео разбор. Финансовые модели и юнит-экономика на практике.
https://khanin.info/blog/93 - блог с разными статьями про юнит-экономику от Ханина. У него еще и книга есть по этому поводу.
Как вы могли заметить, в последнее время у меня начался цикл постов про продуктовую внутрянку.
Метрики/пирамиды/деревья/
Но все это меркнет и бледнеет без самого важного — юнит-экономики.
И да, это снова тема, в которой продуктовый аналитик тоже должен шарить, если не хочет быть просто «аналитиком-калькулятором».
Поехали:
https://www.youtube.com/watch?v=3fjOFBIpj9Y - разговор Ильи Красинского и Глеба Кудрявцева. Легкое введение и общие понятия.
https://gopractice.ru/product/unit-economics/ - статья на Go Practice, там же найдете шаблон расчета юнит-экономики от Ильи.
https://www.youtube.com/watch?v=h8VWl0GFW3Y&t=3s - снова лекция Яндекса в рамках школы менеджеров. Илья Красинский. Старое видео, но все еще полезное.
https://gopractice.ru/free/vid_zabudko_smirnov/ - снова Go Practice, но уже видео разбор. Финансовые модели и юнит-экономика на практике.
https://khanin.info/blog/93 - блог с разными статьями про юнит-экономику от Ханина. У него еще и книга есть по этому поводу.
Forwarded from Андрей Созыкин (Andrey Sozykin)
Сертификаты TLS/SSL и инфраструктура открытых ключей
В новом видео по протоколу TLS рассказываю об аутентификации - подтверждении подлинности сервера (а иногда и клиента), к которому происходит подключение.
Аутентификация нужна для защиты от атаки Человек посередине, когда кто-то перехватывает все наши сообщения, передает их от своего имени серверу, а ответы сервера пересылает нам. При перехвате злоумышленник может прочитать и изменить все сообщения.
Как проверить подлинность удаленного сервера? Для этого можно применить асимметричное шифрование, но не так, как мы рассматривали ранее. Если зашифровать сообщение закрытым ключом сервера, то расшифровать его можно будет только открытым ключом. Такой алгоритм называется цифровой подписью (на самом деле все устроено несколько сложнее, но технические детали нам пока не важны). Если клиент с помощью открытого ключа смог расшифровать цифровую подпись, сделанную закрытым ключом сервера, то клиент может быть уверен, что сообщение действительно отправил сервер.
Но далее возникает следующая проблема – как узнать, что открытый ключ действительно принадлежит серверу, а не злоумышленнику? Для этого нужен третий участник – удостоверяющий центр (Certificate authority). Именно удостоверяющий центр подтверждает подлинность открытого ключа сервера. Для этого создается сертификат TLS/SSL, в котором есть открытый ключ сервера и цифровая подпись удостоверяющего центра. Если клиент доверяет удостоверяющему центру, то он может быть уверен в подлинности открытого ключа сервера.
Для масштабирования на уровень интернет удостоверяющие центры организованы в иерархию - инфраструктуру открытых ключей (Public Key Infrastructure). Клиентам нужно настроить доверие только с корневыми удостоверяющими центрами, с остальными доверие будет проверено автоматически.
Если плохо работает YouTube, то можно смотреть в Дзен или VK.
Поддержать создание курса можно на Boosty или CloudTips.
В новом видео по протоколу TLS рассказываю об аутентификации - подтверждении подлинности сервера (а иногда и клиента), к которому происходит подключение.
Аутентификация нужна для защиты от атаки Человек посередине, когда кто-то перехватывает все наши сообщения, передает их от своего имени серверу, а ответы сервера пересылает нам. При перехвате злоумышленник может прочитать и изменить все сообщения.
Как проверить подлинность удаленного сервера? Для этого можно применить асимметричное шифрование, но не так, как мы рассматривали ранее. Если зашифровать сообщение закрытым ключом сервера, то расшифровать его можно будет только открытым ключом. Такой алгоритм называется цифровой подписью (на самом деле все устроено несколько сложнее, но технические детали нам пока не важны). Если клиент с помощью открытого ключа смог расшифровать цифровую подпись, сделанную закрытым ключом сервера, то клиент может быть уверен, что сообщение действительно отправил сервер.
Но далее возникает следующая проблема – как узнать, что открытый ключ действительно принадлежит серверу, а не злоумышленнику? Для этого нужен третий участник – удостоверяющий центр (Certificate authority). Именно удостоверяющий центр подтверждает подлинность открытого ключа сервера. Для этого создается сертификат TLS/SSL, в котором есть открытый ключ сервера и цифровая подпись удостоверяющего центра. Если клиент доверяет удостоверяющему центру, то он может быть уверен в подлинности открытого ключа сервера.
Для масштабирования на уровень интернет удостоверяющие центры организованы в иерархию - инфраструктуру открытых ключей (Public Key Infrastructure). Клиентам нужно настроить доверие только с корневыми удостоверяющими центрами, с остальными доверие будет проверено автоматически.
Если плохо работает YouTube, то можно смотреть в Дзен или VK.
Поддержать создание курса можно на Boosty или CloudTips.
Forwarded from Гречневые мысли
All work no play makes Claude a dull boy
Сидел недавно вечером, отдыхал после работы, кушал куриную грудку и выбирал себе плавки на яндекс маркете. Зацепился взглядом за мини-игры, которые дают какие-то бонусы, нашёл там 2048 и залип. Играл весь вечер, собрал какое-то большое число и внезапно заинтересовался — а насколько ллмки умеют играть в 2048?
Кроме автоматизации получения бонусов с яндекс маркета, меня интересовала ещё одна деталь. Моим дипломом в магистратуре была проверка умений VLM к физическому ризонингу — условно, даём модели картинку с 2D физической сценой и просим предсказать, что будет дальше. Но VLM (даже SOTA в лице GPT-4) очень плохо справлялись с этой задачей, путали лево и право и галлюцинировали цвета шариков, так что тот проект превратился в бенчмарк, где ллм в агентном цикле генерили код для симуляции этих сцен (и работало это всё равно довольно плохо). Соответственно, возникает вопрос — если в 2023 году VLM так плохо справлялись со spatial reasoning, насколько лучше с ним они будут справляться в конце 2025?
Проверить легко — вместе с клодом кодом написали движок для 2048, управляющийся через LEFT, RIGHT, UP, DOWN, прикрутили визуализацию, сделали нативный function calling (спасибо Kristaller за пулл-реквест) и запустили следующие модельки:
- Qwen-3-VL-8B-Thinking и Instruct — посмотреть, как работают мелкие open-source VL модельки, проаблейтив наличие или отсутствие thinking, текстовый или картиночный ввод и контекст в 5 ходов
- Qwen-3-VL-235B-Thinking и Instruct — посмотреть, как работают крупные open-source VL модельки, проаблейтив наличие или отсутствие thinking
- Gemini 2.5 Flash Lite — посмотреть, как работают закрытые VL модельки мелкого размера
- Claude 4.5 Sonnet — фронтир модель
К сожалению, 2048 очень рандомная игра. Хорошую стратегию всегда может испортить заспавнившаяся в неудачном месте цифра и игра будет проиграна. Да и из-за рандомности генерации двоек и четвёрок счёт в случае некоторых моделей при равном числе шагов отличался аж на 20%. Кроме того, за несколько ранов я мог наблюдать, что счёт ллмок из-за рандомности даже с зафиксированным сидом сильно скакали. Но несмотря на рандом, вот несколько паттернов, которые мне удалось заметить:
- Модели уже не слепые котятки, потому что ризонинг трейсы были относительно внятными и направления аргументировались осмысленно. Модели понимают концепцию направления и могут производить некоторый spatial reasoning, хоть и делают дофига ошибок.
- Хайскор — 256 + 128 у мелкого квена ризонера. Остальные модели добирались до 128 и дальше проигрывали. Автоматизировать получение бонусов на Яндекс Маркете не получится.
- Ризонинг, кажется, помогает. Qwen-3-VL-8B-Thinking и 235B-Thinking работали стабильно лучше, чем Instruct версии тех же моделей.
- Количество нелегальных шагов слабо зависит от итогового счёта и размера моделей. У Qwen-3-8B-Thinking в пять раз меньше нелегальных ходов, чем у Соннета.
- Кажется, мультимодальность мешает модели, но с этим непонятно. При смене домена с картиночного на текстовый число нелегальных шагов подскочило втрое, но и счёт вырос вдвое.
- 2048 — это плохой бенчмарк из-за рандомности. Что, впрочем, не остановило наших коллег из UC San Diego, UC Berkley и MBZUAI от включения этого энвайрмента в свой сабмит на ICLR 2026. Oh well.
- Я мог бы погуглить, прежде чем садиться тратить время и деньги на апи, но what's the fun in that? :P
Клод написал мне веб-страничку с визуализатором, посмотрите обязательно, это прикольно. Код выложен на моём гитхабе.
Сидел недавно вечером, отдыхал после работы, кушал куриную грудку и выбирал себе плавки на яндекс маркете. Зацепился взглядом за мини-игры, которые дают какие-то бонусы, нашёл там 2048 и залип. Играл весь вечер, собрал какое-то большое число и внезапно заинтересовался — а насколько ллмки умеют играть в 2048?
Кроме автоматизации получения бонусов с яндекс маркета, меня интересовала ещё одна деталь. Моим дипломом в магистратуре была проверка умений VLM к физическому ризонингу — условно, даём модели картинку с 2D физической сценой и просим предсказать, что будет дальше. Но VLM (даже SOTA в лице GPT-4) очень плохо справлялись с этой задачей, путали лево и право и галлюцинировали цвета шариков, так что тот проект превратился в бенчмарк, где ллм в агентном цикле генерили код для симуляции этих сцен (и работало это всё равно довольно плохо). Соответственно, возникает вопрос — если в 2023 году VLM так плохо справлялись со spatial reasoning, насколько лучше с ним они будут справляться в конце 2025?
Проверить легко — вместе с клодом кодом написали движок для 2048, управляющийся через LEFT, RIGHT, UP, DOWN, прикрутили визуализацию, сделали нативный function calling (спасибо Kristaller за пулл-реквест) и запустили следующие модельки:
- Qwen-3-VL-8B-Thinking и Instruct — посмотреть, как работают мелкие open-source VL модельки, проаблейтив наличие или отсутствие thinking, текстовый или картиночный ввод и контекст в 5 ходов
- Qwen-3-VL-235B-Thinking и Instruct — посмотреть, как работают крупные open-source VL модельки, проаблейтив наличие или отсутствие thinking
- Gemini 2.5 Flash Lite — посмотреть, как работают закрытые VL модельки мелкого размера
- Claude 4.5 Sonnet — фронтир модель
К сожалению, 2048 очень рандомная игра. Хорошую стратегию всегда может испортить заспавнившаяся в неудачном месте цифра и игра будет проиграна. Да и из-за рандомности генерации двоек и четвёрок счёт в случае некоторых моделей при равном числе шагов отличался аж на 20%. Кроме того, за несколько ранов я мог наблюдать, что счёт ллмок из-за рандомности даже с зафиксированным сидом сильно скакали. Но несмотря на рандом, вот несколько паттернов, которые мне удалось заметить:
- Модели уже не слепые котятки, потому что ризонинг трейсы были относительно внятными и направления аргументировались осмысленно. Модели понимают концепцию направления и могут производить некоторый spatial reasoning, хоть и делают дофига ошибок.
- Хайскор — 256 + 128 у мелкого квена ризонера. Остальные модели добирались до 128 и дальше проигрывали. Автоматизировать получение бонусов на Яндекс Маркете не получится.
- Ризонинг, кажется, помогает. Qwen-3-VL-8B-Thinking и 235B-Thinking работали стабильно лучше, чем Instruct версии тех же моделей.
- Количество нелегальных шагов слабо зависит от итогового счёта и размера моделей. У Qwen-3-8B-Thinking в пять раз меньше нелегальных ходов, чем у Соннета.
- Кажется, мультимодальность мешает модели, но с этим непонятно. При смене домена с картиночного на текстовый число нелегальных шагов подскочило втрое, но и счёт вырос вдвое.
- 2048 — это плохой бенчмарк из-за рандомности. Что, впрочем, не остановило наших коллег из UC San Diego, UC Berkley и MBZUAI от включения этого энвайрмента в свой сабмит на ICLR 2026. Oh well.
- Я мог бы погуглить, прежде чем садиться тратить время и деньги на апи, но what's the fun in that? :P
Клод написал мне веб-страничку с визуализатором, посмотрите обязательно, это прикольно. Код выложен на моём гитхабе.
Forwarded from Заскуль питона (Data Science)
Как бороться с переобучением в ML
Считаете вы значит свои данные на тренировочных данных, качество хорошее, нужно внедрять в прод. Смотрите на тестовых — все плохо. Достаточно понятное объяснение: модель подстроилась под тренировочные данные.
Чем это грозит? Когда будем получать новые данные, модель не сможет адекватно интерпретировать нашу реальность, из-за чего будем страдать. Неадекватные прогнозы, плохое обобщение модели, неверные решения для бизнеса, убытки. В общем, всехорошо приемлемо 👨⚖️
Что можно с этим сделать
1. Больше качественных данных. Взять больше выборку, предобработать лучше. Минусы: не всегда есть эти данные. Возможно, мы уже взяли те самые 100% на которых мы обучаем👀 . У меня в магистратуре есть курс по предподготовке и анализу данных. Считаю его одним из самых важных. Об этом напишу в следующих постах.
2. Регуляризация. Модель может штрафовать за сложность. Чем проще модель, тем меньше она запоминает шум в данных. Без нее модель может выучить все подряд. Почитать можно тут, все хорошо объяснено. Практически всегда стоит начинать со включенной регуляризации, если понимаете за что каждый из видов отвечает.
3. Уменьшить сложность модели. Несмотря на то, что могут быть более мощные модели, они имеют свойство переобучаться. Например, для деревьев можно ограничить глубину. Попробовать сократить количество фичей и использовать более простую модель🤔
4. Замерять качество на валидационном датасете. Сравнивать качество на тренировочных и тестовых данных, а дальше тюнить в зависимости от обнаружения проблемы по метрикам качества модели. Про то как работать с кросс-валидацией написано тут🍪 🍪
5. Feature Selection. Определять важные для модели фичи, которые можно будет легко интерпретировать. Лучше использовать 10 хороших фичей, чем 200 случайных. Про простенький вариант на примере Титаника😮
6. Аугментация и добавление синтетических данных. Можно обмануть алгоритм, добавив шум, предоставить те же семплы данных, но немного измененные. Обычно это подходит для CV и NLP. Например, когда, мы подаем в модель повернутые картинки котиков, искусственно масштабируя датасет. Здесь также можно применить и SMOTE / ADASYN🙊 . Важно: все oversampling / SMOTE только на тренировочной выборке, иначе будет data leakage (утечка данных). О том, что это и как с этим бороться — тут.
7. Раннее прекращение обучения модели. Если качество на валидации перестаёт расти или начинает ухудшаться, обучение стоит остановить. Дальше модель может запоминать только шум. Например, останавливать обучение, если после N итераций качество на валидации не улучшается (как это указано на картинке).
Вот здесь неплохо рассказано про то, как проявляется переобучение у разных моделей машинного обучения и не только.
Но все должно быть объяснимо, почему может возникнуть переобучение, проблемные случаи и так далее. Мы же не на Kaggle🔑 , чтобы оптимизировать модели вслепую ради скора, а должны смотреть на все комплексно
Что-то забыл? Пишите в комментариях! Ставьте🤪 , если понравился пост! Планирую по 💻 писать больше, так как учусь на него, ну...
@zasql_python
Считаете вы значит свои данные на тренировочных данных, качество хорошее, нужно внедрять в прод. Смотрите на тестовых — все плохо. Достаточно понятное объяснение: модель подстроилась под тренировочные данные.
Чем это грозит? Когда будем получать новые данные, модель не сможет адекватно интерпретировать нашу реальность, из-за чего будем страдать. Неадекватные прогнозы, плохое обобщение модели, неверные решения для бизнеса, убытки. В общем, все
Вся эта борьба по сути, управление bias–variance tradeoff: либо модель слишком простая, либо слишком подгоняется под шум.
Что можно с этим сделать
1. Больше качественных данных. Взять больше выборку, предобработать лучше. Минусы: не всегда есть эти данные. Возможно, мы уже взяли те самые 100% на которых мы обучаем
2. Регуляризация. Модель может штрафовать за сложность. Чем проще модель, тем меньше она запоминает шум в данных. Без нее модель может выучить все подряд. Почитать можно тут, все хорошо объяснено. Практически всегда стоит начинать со включенной регуляризации, если понимаете за что каждый из видов отвечает.
3. Уменьшить сложность модели. Несмотря на то, что могут быть более мощные модели, они имеют свойство переобучаться. Например, для деревьев можно ограничить глубину. Попробовать сократить количество фичей и использовать более простую модель
4. Замерять качество на валидационном датасете. Сравнивать качество на тренировочных и тестовых данных, а дальше тюнить в зависимости от обнаружения проблемы по метрикам качества модели. Про то как работать с кросс-валидацией написано тут
5. Feature Selection. Определять важные для модели фичи, которые можно будет легко интерпретировать. Лучше использовать 10 хороших фичей, чем 200 случайных. Про простенький вариант на примере Титаника
6. Аугментация и добавление синтетических данных. Можно обмануть алгоритм, добавив шум, предоставить те же семплы данных, но немного измененные. Обычно это подходит для CV и NLP. Например, когда, мы подаем в модель повернутые картинки котиков, искусственно масштабируя датасет. Здесь также можно применить и SMOTE / ADASYN
7. Раннее прекращение обучения модели. Если качество на валидации перестаёт расти или начинает ухудшаться, обучение стоит остановить. Дальше модель может запоминать только шум. Например, останавливать обучение, если после N итераций качество на валидации не улучшается (как это указано на картинке).
Вот здесь неплохо рассказано про то, как проявляется переобучение у разных моделей машинного обучения и не только.
Хорошая модель — это не та, что идеальна на трейне, а та, что стабильно работает на новых данных🤓
Но все должно быть объяснимо, почему может возникнуть переобучение, проблемные случаи и так далее. Мы же не на Kaggle
Что-то забыл? Пишите в комментариях! Ставьте
@zasql_python
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Роман с данными
Ключевые выводы McKinsey из отчета The State of AI in 2025 о применении AI агентов
1. Большинство организаций всё ещё находятся на стадии экспериментов или пилотных проектов: две трети респондентов говорят, что их организации пока не начали масштабировать ИИ на уровне всей компании.
2. Высокий интерес к ИИ-агентам: 62% участников опроса отмечают, что их организации как минимум экспериментируют с ИИ-агентами.
3. Позитивные ранние сигналы влияния ИИ: Респонденты сообщают о выгодах по отдельным сценариям применения — снижении затрат и росте выручки — и 64% говорят, что ИИ помогает инновациям.
4. Лидеры используют ИИ для роста, инноваций и снижения затрат: 80% респондентов говорят, что их компании ставят повышение эффективности целью ИИ-инициатив.
5. Перепроектирование рабочих процессов — ключевой фактор успеха: половина наиболее успешных компаний в ИИ намерена использовать ИИ для трансформации бизнеса, и большинство из них пересматривают рабочие процессы.
Цифры крутые! Но потом читаю юмористические посты
Вити Тарнавского https://t.iss.one/singularityfm/375
Леши Хахунова https://t.iss.one/aihappens/392
И складывается картинка как их внедряют😀😀😀
1. Большинство организаций всё ещё находятся на стадии экспериментов или пилотных проектов: две трети респондентов говорят, что их организации пока не начали масштабировать ИИ на уровне всей компании.
2. Высокий интерес к ИИ-агентам: 62% участников опроса отмечают, что их организации как минимум экспериментируют с ИИ-агентами.
3. Позитивные ранние сигналы влияния ИИ: Респонденты сообщают о выгодах по отдельным сценариям применения — снижении затрат и росте выручки — и 64% говорят, что ИИ помогает инновациям.
4. Лидеры используют ИИ для роста, инноваций и снижения затрат: 80% респондентов говорят, что их компании ставят повышение эффективности целью ИИ-инициатив.
5. Перепроектирование рабочих процессов — ключевой фактор успеха: половина наиболее успешных компаний в ИИ намерена использовать ИИ для трансформации бизнеса, и большинство из них пересматривают рабочие процессы.
Цифры крутые! Но потом читаю юмористические посты
Вити Тарнавского https://t.iss.one/singularityfm/375
Леши Хахунова https://t.iss.one/aihappens/392
И складывается картинка как их внедряют😀😀😀