Forwarded from AI и грабли
То, что выше – это дамп моего канала вместе с комментариями к моим постам.
Что ты можешь рассказать про меня и про моих читателей на основе того, что они лайкают, комментируют и тех текстов, которые я пишу?
Твоя задача – делать не psychological insights, but behavioural insights. То есть не делать выводы о том, почему я что-то пишу, а делать выводы о том, что я пишу, что я делаю, как я это делаю. Не говорить, кто я такой, а говорить, как я себя веду. При этом они должны быть не только позитивными, но и негативными, да, потому что это что-то, чего я смогу сделать. Инсайты двигаться дальше.
Ну и плюс этот разбор будет интереснее почитать моим подписчикам, если там будет еще и негатив какой-то и прожарочка немножко
Пока ничего не пиши про читателей, я отдельным промтом это запрошу.
И прожарка не должна быть отдельной. Она должна, ну как бы, я хочу обычный список про меня. Просто в нем должны быть и такие пункты, которые скорее позитивные, и такие пункты, которые скорее негативные. Но желательно тоже без супер ярких, как бы очевидно гиперболизированных
Смотри, важно, чтобы они более-менее чередовались.
Чтобы они не были все примерно одинаковыми, состоящими из позитива и негатива.
Чтобы какие-то были более позитивные, а какие-то более негативные.
Но при этом не искусственно гиперболизированные, чтобы это не была очевидная лесть или очевидная доебка, высосанная из пальца.
И еще важно, что это не только про мебя и свою жизнь (исходя из того, что я сам про себя пишу), но мне еще интересно узнать про то, *как* я пишу, как я вообще веду канал. Как я общаюсь с комментаторами, и как они общаются со мной
Постарайся не писать тезисы по одинаковому шаблону.
Хочется, чтобы они отличались по форме и структуре, чтобы у текста не было одного скучного ритма, повторяющегося.
Еще из стилистического, пожалуйста, избегай вот типичных для LLM конструкций: "не X, а Y". Бесит.
Что ты можешь рассказать про меня и про моих читателей на основе того, что они лайкают, комментируют и тех текстов, которые я пишу?
Твоя задача – делать не psychological insights, but behavioural insights. То есть не делать выводы о том, почему я что-то пишу, а делать выводы о том, что я пишу, что я делаю, как я это делаю. Не говорить, кто я такой, а говорить, как я себя веду. При этом они должны быть не только позитивными, но и негативными, да, потому что это что-то, чего я смогу сделать. Инсайты двигаться дальше.
Ну и плюс этот разбор будет интереснее почитать моим подписчикам, если там будет еще и негатив какой-то и прожарочка немножко
Пока ничего не пиши про читателей, я отдельным промтом это запрошу.
И прожарка не должна быть отдельной. Она должна, ну как бы, я хочу обычный список про меня. Просто в нем должны быть и такие пункты, которые скорее позитивные, и такие пункты, которые скорее негативные. Но желательно тоже без супер ярких, как бы очевидно гиперболизированных
Смотри, важно, чтобы они более-менее чередовались.
Чтобы они не были все примерно одинаковыми, состоящими из позитива и негатива.
Чтобы какие-то были более позитивные, а какие-то более негативные.
Но при этом не искусственно гиперболизированные, чтобы это не была очевидная лесть или очевидная доебка, высосанная из пальца.
И еще важно, что это не только про мебя и свою жизнь (исходя из того, что я сам про себя пишу), но мне еще интересно узнать про то, *как* я пишу, как я вообще веду канал. Как я общаюсь с комментаторами, и как они общаются со мной
Постарайся не писать тезисы по одинаковому шаблону.
Хочется, чтобы они отличались по форме и структуре, чтобы у текста не было одного скучного ритма, повторяющегося.
Еще из стилистического, пожалуйста, избегай вот типичных для LLM конструкций: "не X, а Y". Бесит.
Forwarded from AI и грабли
Кайф.
А теперь давай сделаем обзор моей аудитории.
Кто они (факты, а не оценки), зачем они читают мой канал, как они себя ведут в комментариях, какое у них отношение, какая у них ценность, что им наоборот не нравится. Вот эти вот все штуки. Это я просто примеры накидываю.
Ты можешь дальше пойти и еще от себя сформулировать что-то.
И что мне будет интересно узнать про них? И, возможно, им самим будет интересно узнать про себя?
Но опять же, да, с точки зрения именно behavioral анализа – что они делают, а не почему. Не нужно угадывать за людей, что они хотят и чувствуют
Но сконцентрируйся на более новых постах за 2025 год, а не за 2024.
Потому что основная часть моей аудитории пришла в 2025, причем уже начиная с лета
А теперь давай сделаем обзор моей аудитории.
Кто они (факты, а не оценки), зачем они читают мой канал, как они себя ведут в комментариях, какое у них отношение, какая у них ценность, что им наоборот не нравится. Вот эти вот все штуки. Это я просто примеры накидываю.
Ты можешь дальше пойти и еще от себя сформулировать что-то.
И что мне будет интересно узнать про них? И, возможно, им самим будет интересно узнать про себя?
Но опять же, да, с точки зрения именно behavioral анализа – что они делают, а не почему. Не нужно угадывать за людей, что они хотят и чувствуют
Но сконцентрируйся на более новых постах за 2025 год, а не за 2024.
Потому что основная часть моей аудитории пришла в 2025, причем уже начиная с лета
Forwarded from Aspiring Data Science (Anatoly Alekseev)
#eda
В жизни не видел такого подробного разведанализа!
https://medium.com/@writeronepagecode/deciphering-the-market-a-visual-guide-to-the-jane-street-prediction-challenge-58391826f1c4
В жизни не видел такого подробного разведанализа!
https://medium.com/@writeronepagecode/deciphering-the-market-a-visual-guide-to-the-jane-street-prediction-challenge-58391826f1c4
Medium
Deciphering the Market: A Visual Guide to the Jane Street Prediction Challenge
A step-by-step journey through exploratory data analysis, feature engineering, and modeling financial time series.
Forwarded from Душный NLP
Подборка статей об альтернативах квадратичному селф-аттеншну
В последние годы всё больше обсуждают альтернативы классическому аттеншну — прежде всего из-за стоимости квадратичного скейлинга и работы с длинными контекстами. Ниже — краткий обзор нескольких любопытных работ и блогпостов на тему линейного, sparse- и гибридного аттеншна.
Why Did MiniMax M2 End Up as a Full Attention Model?
Начнём с поста от команды MiniMax. Их первая модель, MiniMax M1, была гибридной и использовала простой линейный аттеншн на матричных стейтах. Но во второй версии, MiniMax M2, они неожиданно вернулись к полному квадратичному аттеншну — даже без sliding window attention (SWA), который уже встречается в опенсорсных моделях.
Авторы говорят, что гибридная архитектура у них попросту не заработала. На классических текстовых бенчмарках всё выглядело приемлемо, а вот на агентских задачах — с кодом, итерациями и длинным контекстом — модель стабильно проигрывала. SWA тоже не помог: при дообучении моделей, изначально предобученных с полным аттеншном, ключевые головы не перестраивались и деградировали.
Итоговый вывод у MiniMax осторожный: линейные и гибридные подходы выглядят перспективно, но пока не хватает инфраструктуры, реализаций и бенчмарков. Поэтому на данный момент они остаются со стандартным трансформером и считают, что сначала нужно больше данных и экспериментов с длинным контекстом.
The Sparse Frontier: Sparse Attention Trade-offs in Transformer LLMs
В этой работе изучают training free sparsity в аттеншне и пытаются понять, что реально работает с точки зрения баланса compute/accuracy. На умеренных контекстах спарсификация аттеншна почти не помогает и часто ухудшает качество. На очень длинных — даёт выигрыш по FLOPs, но часто приводит к ухудшению качества: авторы замечают, что метод, работающий на одной задаче, ломается на другой. В среднем удаётся получить около 5× сжатия без сильной деградации качества, но разброс большой, особенно для маленьких моделей.
Evaluating Long Context (Reasoning) Ability
В следующем посте автор критикует популярные long-context-бенчмарки. Он говорит, что needle-in-a-haystack-like-задачи в основном проверяют ретривал и плохо отражают реальную (более сложную) работу с длинным контекстом. На более сложных задачах, где контекст нужно понять, а не просто найти факт (например, в длинном коде с логическими ошибками), модели начинают деградировать уже на десятках тысяч токенов — даже с Full Attention. Вывод: бенчмарков, которые реально проверяют ризонинг на длинном контексте, пока недостаточно.
Kimi Linear: an expressive, efficient attention architecture
Спустя неделю после скептического поста MiniMax Moonshot AI (авторы модели Kimi K2 и не только) выпустили работу с почти противоположным тезисом: Linear Attention работает. В Kimi Linear предложили Kimi Delta Attention с gated delta rule и рекуррентной матричной памятью. В модели используют соотношение 3:1 линейных слоёв к Full Attention. Качество на бенчмарках в статье не хуже полного аттеншна, а эффективность выше: prefill на длинных промптах быстрее примерно в три раза, декодинг и memory footprint тоже выигрывают за счёт меньшей зависимости от KV-cache.
Разбор подготовил❣ Иван Рубачёв, а ещё он приглашает вас на семинары Yandex Research Reading Group
Душный NLP
В последние годы всё больше обсуждают альтернативы классическому аттеншну — прежде всего из-за стоимости квадратичного скейлинга и работы с длинными контекстами. Ниже — краткий обзор нескольких любопытных работ и блогпостов на тему линейного, sparse- и гибридного аттеншна.
Why Did MiniMax M2 End Up as a Full Attention Model?
Начнём с поста от команды MiniMax. Их первая модель, MiniMax M1, была гибридной и использовала простой линейный аттеншн на матричных стейтах. Но во второй версии, MiniMax M2, они неожиданно вернулись к полному квадратичному аттеншну — даже без sliding window attention (SWA), который уже встречается в опенсорсных моделях.
Авторы говорят, что гибридная архитектура у них попросту не заработала. На классических текстовых бенчмарках всё выглядело приемлемо, а вот на агентских задачах — с кодом, итерациями и длинным контекстом — модель стабильно проигрывала. SWA тоже не помог: при дообучении моделей, изначально предобученных с полным аттеншном, ключевые головы не перестраивались и деградировали.
Итоговый вывод у MiniMax осторожный: линейные и гибридные подходы выглядят перспективно, но пока не хватает инфраструктуры, реализаций и бенчмарков. Поэтому на данный момент они остаются со стандартным трансформером и считают, что сначала нужно больше данных и экспериментов с длинным контекстом.
The Sparse Frontier: Sparse Attention Trade-offs in Transformer LLMs
В этой работе изучают training free sparsity в аттеншне и пытаются понять, что реально работает с точки зрения баланса compute/accuracy. На умеренных контекстах спарсификация аттеншна почти не помогает и часто ухудшает качество. На очень длинных — даёт выигрыш по FLOPs, но часто приводит к ухудшению качества: авторы замечают, что метод, работающий на одной задаче, ломается на другой. В среднем удаётся получить около 5× сжатия без сильной деградации качества, но разброс большой, особенно для маленьких моделей.
Evaluating Long Context (Reasoning) Ability
В следующем посте автор критикует популярные long-context-бенчмарки. Он говорит, что needle-in-a-haystack-like-задачи в основном проверяют ретривал и плохо отражают реальную (более сложную) работу с длинным контекстом. На более сложных задачах, где контекст нужно понять, а не просто найти факт (например, в длинном коде с логическими ошибками), модели начинают деградировать уже на десятках тысяч токенов — даже с Full Attention. Вывод: бенчмарков, которые реально проверяют ризонинг на длинном контексте, пока недостаточно.
Kimi Linear: an expressive, efficient attention architecture
Спустя неделю после скептического поста MiniMax Moonshot AI (авторы модели Kimi K2 и не только) выпустили работу с почти противоположным тезисом: Linear Attention работает. В Kimi Linear предложили Kimi Delta Attention с gated delta rule и рекуррентной матричной памятью. В модели используют соотношение 3:1 линейных слоёв к Full Attention. Качество на бенчмарках в статье не хуже полного аттеншна, а эффективность выше: prefill на длинных промптах быстрее примерно в три раза, декодинг и memory footprint тоже выигрывают за счёт меньшей зависимости от KV-cache.
Разбор подготовил
Душный NLP
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Поступашки - ШАД, Стажировки и Магистратура
How to заботать android-разработку
Периодически можно услышать мнение, что нативная разработка сдаёт позиции, которые перехватывают flutter и real native. Но, во-первых, реальность такова, что для приложений с критическими требованиями к производительности и безопасности (например, в финтехе) нативная разработка - всё ещё мастхев. А, во-вторых, стоит упомянуть быстрое развитие технологии Kotlin Multiplatform, позволяющей разрабатывать фичи для обеих платформ, используя всё тот же котлин и фреймворк Jetpack Compose.
Итак, переходим к роадмапу:
Kotlin
Если вы уже знакомы с экосистемой JVM, то переход на котлин не займёт много времени. Разберитесь с null-safety, классами данных, обработкой исключений, синтаксическим сахаром вроде функций-расширений, в общем, теми концепциями языка, которые делают его удобным и современным. Вопросы на эти темы частенько встречаются на собеседованиях, в том числе в контексте различий между джавой и котлином.
Основы android
После котлина вам нужно разобраться, собственно, с самим андроидом и освоить среду разработки Android Studio, начав реализовывать простое приложение. На этом этапе важно понимание компонентов Activity и Fragment, которые позволяют управлять экранами приложений, и их жизненных циклов.
Далее учимся создавать интерфейс с помощью XML. Да, потом вы перейдёте на Compose, но знание XML-разметки необходимо из-за огромного количества legacy-проектов, которые всё ещё нуждаются в поддержке. Разберитесь с этапами отрисовки View и его жизненным циклом, уделите внимание компоненту RecyclerView, чтобы чётенько разложить интервьюеру, почему списки данных в андроиде так эффективны.
Здесь же автоматизируйте сборку с помощью Gradle.
Многопоточка
Многопоточность - важнейший аспект в мобильной разработке. На собесах этой теме уделяется особое внимание, поэтому здесь стоит потратить время на базу. Разберитесь с основными концепциями асинхронности и корутинами (suspend-функции, structured concurrency), которые позволяют её реализовывать. Иногда интервьюеры спрашивают об эволюции подходов к обеспечению асинхронности, поэтому нелишним будет немного погуглить.
Работа с сетью и хранение данных
Стандарт - библиотека Retrofit, которая преобразует api в kotlin-интерфейс.
Что касается хранения данных, то здесь два варианта: библиотека Room для SQLite и Jetpack DataStore (о Jetpack поговорим следующим пунктом), который пришёл на смену SharedPreferences (но о нём всё ещё спрашивают на собесах).
Jetpack Compose
После того, как вы вдоволь намучились с XML, самое время перейти к фреймворку Jetpack Compose, обновляющему интерфейс автоматически при изменении данных, и базово в нём освоиться (composable-функции, рекомпозиция, управление состоянием, модификаторы, макеты). Можете глянуть для начала этот краткий плейлист, а потом разобраться более основательно.
На работе, вероятнее всего, в какой-то момент вам придётся решать задачу на совместимость Compose и XML, так как большинство проектов проходят через gradual migration.
Архитектура
При проектировании общепринято соблюдение Clean Architecture подхода (хороший плейлист), суть которого в разделении приложения на слои и отделении бизнес-логики от логики интерфейса.
Вам нужно разобраться с ключевым паттерном MVVM, концептуально посмотрите MVP и MVI.
Затем научитесь внедрять зависимости через библиотеку Dagger Hilt (в качестве более простой, но менее популярной альтернативы применяется Koin) для реализации Dependency Injection.
Тестирование
И, конечно, вам нужно научиться покрывать код тестами:
Unit-тесты: JUnit и Mockito
UI-тесты: Espresso, UiAutomator, Kaspresso
видео от Яндекса для лучшего понимания.
Итак, пройдя эти пункты, вы заботаете базу, необходимую для любого android-разработчика.
Ставьте 🔥, если считаете, что мобильщиков несправедливо обделяют, и мы напишем гайд по созданию мощного пет-проекта для прохождения на стажировку мечты!!!
@postypashki_old
Периодически можно услышать мнение, что нативная разработка сдаёт позиции, которые перехватывают flutter и real native. Но, во-первых, реальность такова, что для приложений с критическими требованиями к производительности и безопасности (например, в финтехе) нативная разработка - всё ещё мастхев. А, во-вторых, стоит упомянуть быстрое развитие технологии Kotlin Multiplatform, позволяющей разрабатывать фичи для обеих платформ, используя всё тот же котлин и фреймворк Jetpack Compose.
Итак, переходим к роадмапу:
Kotlin
Если вы уже знакомы с экосистемой JVM, то переход на котлин не займёт много времени. Разберитесь с null-safety, классами данных, обработкой исключений, синтаксическим сахаром вроде функций-расширений, в общем, теми концепциями языка, которые делают его удобным и современным. Вопросы на эти темы частенько встречаются на собеседованиях, в том числе в контексте различий между джавой и котлином.
Основы android
После котлина вам нужно разобраться, собственно, с самим андроидом и освоить среду разработки Android Studio, начав реализовывать простое приложение. На этом этапе важно понимание компонентов Activity и Fragment, которые позволяют управлять экранами приложений, и их жизненных циклов.
Далее учимся создавать интерфейс с помощью XML. Да, потом вы перейдёте на Compose, но знание XML-разметки необходимо из-за огромного количества legacy-проектов, которые всё ещё нуждаются в поддержке. Разберитесь с этапами отрисовки View и его жизненным циклом, уделите внимание компоненту RecyclerView, чтобы чётенько разложить интервьюеру, почему списки данных в андроиде так эффективны.
Здесь же автоматизируйте сборку с помощью Gradle.
Многопоточка
Многопоточность - важнейший аспект в мобильной разработке. На собесах этой теме уделяется особое внимание, поэтому здесь стоит потратить время на базу. Разберитесь с основными концепциями асинхронности и корутинами (suspend-функции, structured concurrency), которые позволяют её реализовывать. Иногда интервьюеры спрашивают об эволюции подходов к обеспечению асинхронности, поэтому нелишним будет немного погуглить.
Работа с сетью и хранение данных
Стандарт - библиотека Retrofit, которая преобразует api в kotlin-интерфейс.
Что касается хранения данных, то здесь два варианта: библиотека Room для SQLite и Jetpack DataStore (о Jetpack поговорим следующим пунктом), который пришёл на смену SharedPreferences (но о нём всё ещё спрашивают на собесах).
Jetpack Compose
После того, как вы вдоволь намучились с XML, самое время перейти к фреймворку Jetpack Compose, обновляющему интерфейс автоматически при изменении данных, и базово в нём освоиться (composable-функции, рекомпозиция, управление состоянием, модификаторы, макеты). Можете глянуть для начала этот краткий плейлист, а потом разобраться более основательно.
На работе, вероятнее всего, в какой-то момент вам придётся решать задачу на совместимость Compose и XML, так как большинство проектов проходят через gradual migration.
Архитектура
При проектировании общепринято соблюдение Clean Architecture подхода (хороший плейлист), суть которого в разделении приложения на слои и отделении бизнес-логики от логики интерфейса.
Вам нужно разобраться с ключевым паттерном MVVM, концептуально посмотрите MVP и MVI.
Затем научитесь внедрять зависимости через библиотеку Dagger Hilt (в качестве более простой, но менее популярной альтернативы применяется Koin) для реализации Dependency Injection.
Тестирование
И, конечно, вам нужно научиться покрывать код тестами:
Unit-тесты: JUnit и Mockito
UI-тесты: Espresso, UiAutomator, Kaspresso
видео от Яндекса для лучшего понимания.
Итак, пройдя эти пункты, вы заботаете базу, необходимую для любого android-разработчика.
Ставьте 🔥, если считаете, что мобильщиков несправедливо обделяют, и мы напишем гайд по созданию мощного пет-проекта для прохождения на стажировку мечты!!!
@postypashki_old
Forwarded from DeepSchool
Ruff: современный и быстрый linter + formatter для Python
Правила оформления кода закреплены в стандартах: какие нужны отступы, длина строк и названия переменных. Они делают код разработчика понятным и единообразным. Правила бывают внутренними (для конкретного проекта) или общими. Например, в Python главный стандарт — PEP8.
Привести код в нужный формат, например, под PEP8 — задача, которая может занять много времени. Поэтому были разработаны вспомогательные инструменты — linters и formatters.
🔜 Linter выполняет статический анализ кода, проверяя его на соответствие заданным правилам, например, PEP8 или пользовательским.
🔜 Formatter автоматически преобразовывает внешний вид кода, не затрагивая его логику и приводя в соответствие заданному стилю оформлению.
Linter и formatter безопасно исправляют код, не меняя его поведения. Они упрощат жизнь разработчка и помогают избежать споров о форматировании и правильности именования классов во время ревью, экономя участникам время и нервы 🙂.
Разработчик вызовом одной команды автоматически форматирует код и находит конкретные участки, которые не соответствуют принятому стандарту, чтобы их поправить. А ревьювер не тратит силы на проверку форматирования, если в CI MR прошёл этапы linter и formatter, уделяя всё внимание на ревью реализации функционала.
Основной linter для python — flake8, а formatters — isort и black. Каждый из них имеет свою конфигурацию и команду запуска.
Использование нескольких инструментов вызывает ряд неудобств:
1. Отдельные файлы конфигураций замусоривают корень проекта и могут конфликтовать между собой.
2. Каждый инструмент — отдельная зависимость, которую надо установить. Кроме того, для flake8, как правило, необходимо доустанавливать отдельные плагины.
3. Каждый инструмент запускается отдельным процессом / задачей в CI и может работать относительно долго на больших кодовых базах.
Ruff помогает избавиться от них: он ставится одним python package, правила для форматирования и различных linters описываются в одном конфиге, а реализация на Rust делает его быстрее аналогов🚀.
Пример внедрения ruff в проект
В
В
Далее:
Автор: Иван Перминов
Правила оформления кода закреплены в стандартах: какие нужны отступы, длина строк и названия переменных. Они делают код разработчика понятным и единообразным. Правила бывают внутренними (для конкретного проекта) или общими. Например, в Python главный стандарт — PEP8.
Привести код в нужный формат, например, под PEP8 — задача, которая может занять много времени. Поэтому были разработаны вспомогательные инструменты — linters и formatters.
Linter и formatter безопасно исправляют код, не меняя его поведения. Они упрощат жизнь разработчка и помогают избежать споров о форматировании и правильности именования классов во время ревью, экономя участникам время и нервы 🙂.
Разработчик вызовом одной команды автоматически форматирует код и находит конкретные участки, которые не соответствуют принятому стандарту, чтобы их поправить. А ревьювер не тратит силы на проверку форматирования, если в CI MR прошёл этапы linter и formatter, уделяя всё внимание на ревью реализации функционала.
Основной linter для python — flake8, а formatters — isort и black. Каждый из них имеет свою конфигурацию и команду запуска.
Использование нескольких инструментов вызывает ряд неудобств:
1. Отдельные файлы конфигураций замусоривают корень проекта и могут конфликтовать между собой.
2. Каждый инструмент — отдельная зависимость, которую надо установить. Кроме того, для flake8, как правило, необходимо доустанавливать отдельные плагины.
3. Каждый инструмент запускается отдельным процессом / задачей в CI и может работать относительно долго на больших кодовых базах.
Ruff помогает избавиться от них: он ставится одним python package, правила для форматирования и различных linters описываются в одном конфиге, а реализация на Rust делает его быстрее аналогов🚀.
Пример внедрения ruff в проект
В
pyproject.toml добавляются следующие строки:[tool.ruff] # Общие настройки ruff
extend-exclude = ["*.ipynb"] # Исключаем Jupyter-ноутбуки из проверки
line-length = 120 # Лимит длины строки
lint.select = [ # Добавляем правила из списка https://docs.astral.sh/ruff/rules
"E", # pycodestyle
"F", # pyflakes
"I", # isort
]
lint.ignore = [
"F821", # Пример добавления игнорирования правил
]
[tool.ruff.format] # Отдельные настройки форматтера
quote-style = "double" # Перевод одинарных кавычек в двойные
indent-style = "space" # Перевод табов в пробелы
В
.pre-commit-config.yaml добавляются следующие строки:repos:
- repo: https://github.com/astral-sh/ruff-pre-commit
rev: v0.14.7
hooks:
- id: ruff
types_or: [ python, pyi, jupyter ]
- id: ruff-format
types_or: [ python, pyi, jupyter ]
args: [ "--check", "--diff" ]
Далее:
# Устанавливаем зависимости
pip install pre-commit ruff
# После настройки linter и formatter создаем hooks для commit/push
pre-commit install
# Использование
ruff check --fix # Запустит linter, подсветит ошибки и исправит некоторые ошибки
ruff format # Запустит formatter и отформатирует код
Автор: Иван Перминов
Про форматтеры, линтеры и другие инженерные практики, помогающие навести порядок в репозиториях DL-инженеров, рассказываем на курсе «Деплой DL-сервисов»⚡️
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Всеволод Викулин | AI разбор
Друзья, опубликовал подробный фреймворк оценки качества LLM.
Он состоит из 7-ми шагов, по которым вы сделаете метрику под вашу LLM-задачу. Там много примеров, наглядных схем, основанных на моей 3-летней практике.
Если после прочтения остались вопросы, как в вашем случае строить метрики качества, напишите мне в личные сообщения — разберем ваш случай отдельно.
Он состоит из 7-ми шагов, по которым вы сделаете метрику под вашу LLM-задачу. Там много примеров, наглядных схем, основанных на моей 3-летней практике.
Если после прочтения остались вопросы, как в вашем случае строить метрики качества, напишите мне в личные сообщения — разберем ваш случай отдельно.
vikulin.ai
Как оценить качество LLM? Пошаговая методика создания надежных метрик.
Оценка качества — ключ к успешному внедрению LLM. В статье разберем, какими свойствами должна обладать метрика LLM, и выведем формулу, по которой вы сможете настроить надежную оценку качества.
Forwarded from Всеволод Викулин | AI разбор
Друзья, привет! Нас уже более 3-х тысяч, спасибо вам за это. Для тех, кто недавно со мной знаком, расскажу про себя и канал.
Я Сева, и уже 9 лет занимаюсь внедрением AI. Работал в VK, Яндексе, сейчас в Т-Банке. Начинал стажером, стал разработчиком, сейчас руководитель команд.
За 9 лет я много раз делал не так. Пришлось структурировать свой опыт в методику «как внедрять AI хорошо», чтобы избежать дальнейших ошибок. Год назад я понял — в этой методике нет ничего сложного, и я могу ей обучить. Не только инженера, но и аналитика, продуктового менеджера, маркетолога. И создал этот канал.
Я верю, что всем нужны эти знания. Каждый из нас лучше других знает, как и куда ему внедрить AI, чтобы было хорошо его компании, отделу и лично ему.
Далее перечислю материалы, которыми я горжусь больше всего.
Статьи про методику внедрения AI:
- 12 правил внедрения LLM
- Почему генеративный AI не приносит прибыли
- Методика оценки качества LLM
Основные посты про методику:
- Главный пост про итеративный фреймворк работы с AI-проектом
- Платформа — ключ к массовому внедрению AI
- Почему нельзя купить AI из коробки
- Как неправильное внедрение стоило компании полмиллиарда долларов
- Почему чаще всего не стоит делать своего code-ассистента. Кейс Uber
- 3 кита улучшения любой LLM
- Как можно сделать модель лучше, чем OpenAI и всего за 8 долларов
Кейсы:
- Ставим разработку AI-агентов на поток
- Как создали AI-агента аналитика
- Агент, который исследует информацию в интернете
- Массовая обработка документов на LLM
Уверен, в следующем году в этом посте будет минимум в 2 раза больше полезных материалов.
Если у вас есть мысли, идеи или вопросы по внедрению AI, всегда можно написать мне @seva_batareika
Я Сева, и уже 9 лет занимаюсь внедрением AI. Работал в VK, Яндексе, сейчас в Т-Банке. Начинал стажером, стал разработчиком, сейчас руководитель команд.
За 9 лет я много раз делал не так. Пришлось структурировать свой опыт в методику «как внедрять AI хорошо», чтобы избежать дальнейших ошибок. Год назад я понял — в этой методике нет ничего сложного, и я могу ей обучить. Не только инженера, но и аналитика, продуктового менеджера, маркетолога. И создал этот канал.
Я верю, что всем нужны эти знания. Каждый из нас лучше других знает, как и куда ему внедрить AI, чтобы было хорошо его компании, отделу и лично ему.
Далее перечислю материалы, которыми я горжусь больше всего.
Статьи про методику внедрения AI:
- 12 правил внедрения LLM
- Почему генеративный AI не приносит прибыли
- Методика оценки качества LLM
Основные посты про методику:
- Главный пост про итеративный фреймворк работы с AI-проектом
- Платформа — ключ к массовому внедрению AI
- Почему нельзя купить AI из коробки
- Как неправильное внедрение стоило компании полмиллиарда долларов
- Почему чаще всего не стоит делать своего code-ассистента. Кейс Uber
- 3 кита улучшения любой LLM
- Как можно сделать модель лучше, чем OpenAI и всего за 8 долларов
Кейсы:
- Ставим разработку AI-агентов на поток
- Как создали AI-агента аналитика
- Агент, который исследует информацию в интернете
- Массовая обработка документов на LLM
Уверен, в следующем году в этом посте будет минимум в 2 раза больше полезных материалов.
Если у вас есть мысли, идеи или вопросы по внедрению AI, всегда можно написать мне @seva_batareika
Forwarded from Женя Янченко
Очереди в Кафке
В 2025 году в Kafka начиная с версии 4.0 появился новый тип групп — share groups, которые обеспечивают работу с сообщениями как в очередях, а не в виде лога (как это обычно в Kafka).
Сообщения в Kafka логически распределены по топикам (например, orders, checks). Топик разбиты на партиции. Именно партиция является физической группировкой сообщений. Про топики, партиции, продюсеров и консьюмер группы у меня есть серия постов.
Consumer groups и привычные паттерны работы остались, просто появилась альтернатива в виде share groups.
Основные различия между share group и consumer group:
➡️ Совместное чтение из одной партиции
Внутри consumer группы одну партицию может читать только один консьюмер.
В share group консьюмеры совместно читают из партиций, то есть одна партиция может быть назначена нескольким консьюмерам одновременно. Kafka сама динамически распределяет доступные сообщения из партиций между консьюмерами так, чтобы балансировать нагрузку.
➡️ Количество консьюмеров в share group может превышать количество партиций в топике.
В случае с consumer groups, если мы хотим сильнее масштабироваться, нужно увеличить количество партиций. Если для топика с 3 партициями мы поднимем 4 консьюмера, то 4-й будет простаивать (пока кто-то из 3-х не отвалится). Поэтому число партиций определяет максимальный параллелизм, с которым мы можем обрабатывать сообщения. Но уменьшить их потом нельзя, плюс топик может быть другой команды.
В случае с share group мы можем поднять много консьюмеров, чтобы обработать нагрузку в пике.
➡️ Порядок сообщений не сохраняется
В партиции сообщения лежат по порядку. Но поскольку из одной и той же партиции в share группе могут читать два и более консьюмера, они могут обработать сообщения не по порядку.
Продолжение⬇️
В 2025 году в Kafka начиная с версии 4.0 появился новый тип групп — share groups, которые обеспечивают работу с сообщениями как в очередях, а не в виде лога (как это обычно в Kafka).
Совсем кратко: в share groups несколько консьюмеров читают одну партицию, поэтому не сохраняется порядок доставки, зато удобно масштабировать.
Сообщения в Kafka логически распределены по топикам (например, orders, checks). Топик разбиты на партиции. Именно партиция является физической группировкой сообщений. Про топики, партиции, продюсеров и консьюмер группы у меня есть серия постов.
Consumer groups и привычные паттерны работы остались, просто появилась альтернатива в виде share groups.
Основные различия между share group и consumer group:
Внутри consumer группы одну партицию может читать только один консьюмер.
В share group консьюмеры совместно читают из партиций, то есть одна партиция может быть назначена нескольким консьюмерам одновременно. Kafka сама динамически распределяет доступные сообщения из партиций между консьюмерами так, чтобы балансировать нагрузку.
В случае с consumer groups, если мы хотим сильнее масштабироваться, нужно увеличить количество партиций. Если для топика с 3 партициями мы поднимем 4 консьюмера, то 4-й будет простаивать (пока кто-то из 3-х не отвалится). Поэтому число партиций определяет максимальный параллелизм, с которым мы можем обрабатывать сообщения. Но уменьшить их потом нельзя, плюс топик может быть другой команды.
В случае с share group мы можем поднять много консьюмеров, чтобы обработать нагрузку в пике.
В партиции сообщения лежат по порядку. Но поскольку из одной и той же партиции в share группе могут читать два и более консьюмера, они могут обработать сообщения не по порядку.
Пример:
Два консьюмера в share group читают топик с одной партицией. Первый консьюмер получает записи с offset 100 по 109 включительно и падает. В это же время второй консьюмер получает, обрабатывает и подтверждает записи 110–119. Затем второй консьюмер получает необработанные первым записи 100–109, обрабатывает и подтверждает. Все сообщения обработаны, но порядок обработки не сохранен.
Продолжение
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Женя Янченко
Очереди в Кафке (продолжение)
Продолжаем рассматривать особенности share groups, которые обеспечивают работу с сообщениями как в очередях.
➡️ Чтение каждого сообщения подтверждается индивидуально
В случае consumer groups чтение фиксируется коммитом оффсета для каждой партиции. Если для этой консьюмер-группы закоммичен оффсет на сообщении 90, значит все сообщения до 90 включительно, прочитаны.
В share группе появляется понятие окна чтения (in-flight records) и статусная модель сообщения.
Статусы:
🌟 Available — сообщение доступно для чтения консьюмером
🌟 Acquired — сообщения было взято в обработку (залочено) конкретным консьюмером (время, на которое сообщение залочено, настраивается параметром
🌟 Acknowledged — сообщение обработано консьюмером (можно сказать, что это аналог коммита оффсета, но лишь для одного сообщения)
🌟 Archived — сообщение признано архивным, больше недоступно для чтения никаким консьюмером в этой share группе.
➡️ Лимит количества попыток доставки сообщения
Для share группы настраивается параметр
Жизненный цикл сообщение в share группе:
1️⃣ Сначала сообщение находится в статусе Available. Его забирает на обработку какой-то из консьюмеров. Счетчик попыток доставки увеличивается на 1. Если у сообщения еще не исчерпан лимит попыток обработки, то его статус становится Acquired. Если лимит попыток исчерпан, то оно становится Archived.
2️⃣ Если консьюмер обработал сообщение, то оно переводится в статус Acknowledged. Также консьюмер может зареджектить сообщение (например, если оно невалидное). Тогда оно становится Archived. Если консьюмер не успел обработать сообщение за время лока (30 сек), то оно снова становится Available.
3️⃣ Со временем, когда окно чтения сдвигается, все Acknowledged из прошлого окна становятся Archived.
Важно, что эти статусы работают в рамках конкретной share group. В одной share group это сообщение уже Archived, а в другой - Available.
Share groups — это просто другой тип группы потребителей, использующий другую модель распределения записей и другой протокол подтверждения:
🟢 consumer groups читают топик как лог
🟢 share groups читают тот же топик как очередь
Когда может пригодиться новый подход с share groups?
Если нам нужна очередь, а не лог: сообщения - это независимые события, которые можно обрабатывать параллельно, порядок некритичен, при этом мы хотим динамически масштабировать их обработку. Хотим ускорить обработку - добавляем больше воркеров (консьюмеров).
Подробно почитать про нововведение можно в доке: KIP-932: Queues for Kafka
Очень круто, что Kafka так развивается! Конечно, фича новая, сейчас правят баги, но для будущих проектов считаю интересно иметь в виду.
#kafka
Продолжаем рассматривать особенности share groups, которые обеспечивают работу с сообщениями как в очередях.
В случае consumer groups чтение фиксируется коммитом оффсета для каждой партиции. Если для этой консьюмер-группы закоммичен оффсет на сообщении 90, значит все сообщения до 90 включительно, прочитаны.
В share группе появляется понятие окна чтения (in-flight records) и статусная модель сообщения.
Статусы:
share.record.lock.duration.ms, по-умолчанию 30 сек)Для share группы настраивается параметр
group.share.delivery.attempt.limit (по-умолчанию 5) — это лимит попыток доставки. Для каждого сообщения Kafka ведет счетчик. Лимит позволяет бороться с невалидными сообщениями, чтобы они не доставлялись бесконечно.Жизненный цикл сообщение в share группе:
Важно, что эти статусы работают в рамках конкретной share group. В одной share group это сообщение уже Archived, а в другой - Available.
Топики и партиции остаются теми же, что были. Один сервис может читать топик через consumer группу, а другой - читать этот же топик через share группу. Продюсер вообще не знает, кто там и как читает. Его дело в партиции записать.
Share groups — это просто другой тип группы потребителей, использующий другую модель распределения записей и другой протокол подтверждения:
Когда может пригодиться новый подход с share groups?
Если нам нужна очередь, а не лог: сообщения - это независимые события, которые можно обрабатывать параллельно, порядок некритичен, при этом мы хотим динамически масштабировать их обработку. Хотим ускорить обработку - добавляем больше воркеров (консьюмеров).
Подробно почитать про нововведение можно в доке: KIP-932: Queues for Kafka
Очень круто, что Kafka так развивается! Конечно, фича новая, сейчас правят баги, но для будущих проектов считаю интересно иметь в виду.
#kafka
Please open Telegram to view this post
VIEW IN TELEGRAM