Forwarded from Хитрый Питон
Django часто выбирают для быстрого старта в небольших стартапах — как средство накодить прототип бекенда за минимальное время. Но с ростом проекта неизбежно возникают вопросы производительности и надежности.
Такой рост может вызывать у не очень опытных разработчиков панику и непонимание - все тормозит, бизнес жалуется, что делать? В сегодняшней статье просто и по делу описаны ключевые аспекты масштабирования Django: оптимизация запросов, кэш, CDN и т.д. Отличное вводное чтиво для тех, кто впервые столкнулся с ростом нагрузи или просто хочет подготовить проект к будущему росту: https://slimsaas.com/blog/django-scaling-performance
Такой рост может вызывать у не очень опытных разработчиков панику и непонимание - все тормозит, бизнес жалуется, что делать? В сегодняшней статье просто и по делу описаны ключевые аспекты масштабирования Django: оптимизация запросов, кэш, CDN и т.д. Отличное вводное чтиво для тех, кто впервые столкнулся с ростом нагрузи или просто хочет подготовить проект к будущему росту: https://slimsaas.com/blog/django-scaling-performance
SlimSaaS
The Practical Guide to Scaling Django
Stripe Payments, Social Authentication & 2FA, Email Integrations, Tailwind/DaisyUI Theming, Astro Marketing Site, Automatic SSL, Containerized With Docker, and much more...
Forwarded from КПД
На днях наткнулся на канал в Youtube некоего Simon Oz.
Парень доступно, с красивыми визуализациями в стиле 3Blue1Brown рассказывает про всякие темы из теории информации и особенности программирования на CUDA.
В частности, особого внимания заслуживает видос про то, как написать эффективный kernel для softmax, который быстрее реализаций в торче и на тритоне. Он пошагово анализирует узкие места, нюансы железа и алгоритма, и постепенно добивается улучшения производительности:
1️⃣ Эффективный алгоритм редукции для нахождения максимума
2️⃣ Оптимизации доступов к памяти (coalescing)
3️⃣ Перенос части операций из shared memory в регистры GPU (которые еще быстрее)
4️⃣ Векторизация операций через float4
5️⃣ Однократная подгрузка данных для подсчета максимума и экспоненты вместо двухкратной
Красивое...
Парень доступно, с красивыми визуализациями в стиле 3Blue1Brown рассказывает про всякие темы из теории информации и особенности программирования на CUDA.
В частности, особого внимания заслуживает видос про то, как написать эффективный kernel для softmax, который быстрее реализаций в торче и на тритоне. Он пошагово анализирует узкие места, нюансы железа и алгоритма, и постепенно добивается улучшения производительности:
1️⃣ Эффективный алгоритм редукции для нахождения максимума
2️⃣ Оптимизации доступов к памяти (coalescing)
3️⃣ Перенос части операций из shared memory в регистры GPU (которые еще быстрее)
4️⃣ Векторизация операций через float4
5️⃣ Однократная подгрузка данных для подсчета максимума и экспоненты вместо двухкратной
Красивое...
Forwarded from Nikita Sushko
Есть много вариантов. vLLM — самый простой, TGI — очень быстрый с некоторых пор, TensorRT LLM — очень сложно в настройке, не стоит того, Llama.cpp не быстрый и не простой в настройке, зато самый популярный и квантов больше всего
Forwarded from Valery
еще SGLang, вроде как, набирает обороты - или уже отменили?
Forwarded from Remixer Dec
Частично перекатился на Zed
его немного больно конфигурировать, но зато потом летает
а курсор этот ваш - проприетарщина с закрытым кодом, т.е. разрабы не хотят делиться своим кодом, но не против стащить ваш
его немного больно конфигурировать, но зато потом летает
а курсор этот ваш - проприетарщина с закрытым кодом, т.е. разрабы не хотят делиться своим кодом, но не против стащить ваш
Forwarded from Slach
Cursor - но только в режиме Composer . который ментально близок к тому как ты ставишь задачу джуну, и он тебе приносит pull request
остальное бесполезно
в JetBrains слежу вот за этим плагином
https://github.com/devoxx/DevoxxGenieIDEAPlugin/
но он пока недоделал похожий функционал
остальное бесполезно
в JetBrains слежу вот за этим плагином
https://github.com/devoxx/DevoxxGenieIDEAPlugin/
но он пока недоделал похожий функционал
Forwarded from Заскуль питона (Data Science)
Дизайн 🆎 экспериментов и почему это важно.
😱 Ранее я считал, что важнее всего подводить итоги, но как оказалось не только. Дизайн эксперимента подразумевает определенную структуру, комплекс действий, направленных для корректного запуска и последующего анализа эксперимента. Подразумевается, что разметка уже готова (более подробно хочу рассказать в следующих постах).
🎄 При проектировании A/B эксперимента учитывайте сезонность, например, в Новый Год пользователи могут вести себя по-другому
💡 Нужно определиться с гипотезой. Проводя A/B тестирование, мы всегда говорим о постановке различных гипотез, как на языке бизнеса (в понятном для всех формате), так и на языке статистики, когда говорим про нулевые и альтернативные гипотезы. Важно понимать, что от гипотезы зависит многое. По сути, как мы дальше будем интерпретировать различные варианты.
🙅♂️ Риски. Какие могут быть риски для компании? Если что-то резонирующее, которое сразу улетит в СМИ - тест можно перезапускать, можем получить при анализе невалидные результаты. Например, если мы просто убираем точку входа или полностью меняем популярное приложение при раскатке 50/50.
🗒 Определение метрик и теста. А на что мы смотрим, когда подводим итоги? Может есть какие-то целевые, по которым мы хотим принимать решения, а может есть какие-то вспомогательные, которые нам нужны для дальнейшего анализа. Если у нас есть своя A/B платформа, проблемой с подсчетов быть не должно. На этом этапе важно также понимать какой тест мы используем для анализа.
☕ Сегменты пользователей. Хотим мы катиться на всех или нет зависит от сетапа эксперимента, возможно, нам нужно брать определенный срез пользователей (старички/новички, пользователи, обладающие каким-то признаком).
🌳 Дерево принятия решений. Если метрик несколько, мы должны определиться с различными вариантами, когда эксперимент катим, а когда нет. Если метрика серая, то..., а если нет, то. Базово должно фиксироваться до проведения эксперимента.
😁 Определение MDE / размера выборки / длительности эксперимента. Мы должны понять на истории, а действительно ли мы сможем прокрасить эксперимент? По сути, тот же MDE нужен нам для определения примерной длительности эксперимента или ответа на вопрос, а эта метрика чувствительна вообще будет на данном срезе или нет?
🥪 Другие слои. А считаем ли мы корректным проводить эксперимент, если слои забиты, а насколько забиты, все ли окей в этом плане?
📱 Если есть своя команда разработки и платформа, то с заведением пользователей (кому какой флаг навешиваем) проблем нет, а если самому, то нужно продумать. Не все могут себе позволить запускать так тесты. Если нет, то со старичками понятно, мы отдаем контроль и тест списком, с новичками сложнее, как будто нужно раз в какое-то время на дню отдавать пользователей списками с айдишниками.
🤕 Тестинг. Посмотрите, как функционал работает, корректно ли все раскатилось, нет ли проблем, походите по различным страницам приложения, может найдете какие-то проблемы, которые можно в дальнейшем пофиксить с помощью разработки
✅ Корректное логирование эксперимента. Можно раскатить на себя, посмотреть, собрать различные события в тестовой группе, попробовать посчитать метрики (просмотр, клик по фиче X, которую мы запускаем на тестовую группу).
🚀 Запуск эксперимента
От вас жду 100🐳 за пост. Далее пройдемся по вопросам, касаемых разметки и ТЗ для команды разработки и я продолжу писать посты из списка.
От вас жду 100
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Start Career in DS
📊 Как оценивать LLM: метрики [Ч.1]
🤖 Оценка языковых моделей также необходима, как и при работе с классическими ML-моделями. Однако, в случае с LLM задача усложняется тем, что мы должны оценивать текстовые данные.
💯 В этой части поста мы расскажем про наиболее популярные NLP-метрики для оценки языковых моделей, а уже в следующем посте поговорим про более продвинутые техники, включая бенчмарки.
❓ А в чем, собственно, отличие между метриками и бенчмарками:
Метрики - используются для измерения конкретных навыков аспектов работы модели (например, точность перевода с русского на английский) или могут использоваться, как часть бенчмарка.
Бенчмарки же — это наборы тестов, которые обычно включают множество задач и способов их оценок (метрик). Бенчмарки дают более масштабную оценку качества работы моделей, не в рамках отдельной задачи.
Поговорим про статистические метрики:
1️⃣ Перплексия:
Перплексия показывает, насколько точно модель предсказывает следующий токен: чем ниже значение, тем уверенее предсказание.
Например, если перплексия равна 1000, это означает, что модель в среднем имеет 1000 равновероятных вариантов для каждого следующего слова, что указывает на плохое качество предсказаний. Через перплексию в LLM можно определить галлюцинации, хоть и сама метрика не всегда коррелирует с качеством генерации текста.
Более подробно про перплексию и формулу данной меры читайте тут.
2️⃣ BLEU и ROUGE:
О данных метриках мы писали в одном из вопросов недавнего квиза (п.5) и оставляли хорошие материалы для изучения, советуем вернуться и ознакомиться.
3️⃣ METEOR:
Данная метрика создавалась, как улучшенная альтернатива BLEU, которая учитывает не только точное совпадение слов в сгенерированном тексте с эталонными примерами, но и их синонимы и морфологические варианты, что делает её более гибкой и устойчивой к разнообразным формулировкам. В добавок, метрика выдает штраф за неправильную фрагментацию текста и неверный порядок слов. Подробно про методику расчет METEOR смотрите в этом видео.
4️⃣ Классические ML-метрики:
Оценивать текст можно также, как и числа, используя ML-метрики. Например, посчитать количество слов (токенов) в сгенерированном примере, вошедшие в эталонный пример - accuracy. Или посчитать recall через количество слов, вошедшие в эталонный пример (TP), но, учитывая недостающие токены (FN).
Теперь поговорим про model-based метрики:
5️⃣ BERTScore:
Данная метрика в процессе расчета использует BERT-модели, чтобы через векторные представления слов в предложении оценивать схожесть текстов. Кратко процесс оценки выглядит следующим образом: получение эмбеддингов для каждого слова в сгенерированном и эталонном текстах с помощью BERT. И затем (в упрощенном виде) по косинусному сходству токены из сгенерированного текста сопоставляются с токенами эталонного текста, после чего высчитывается Recall-BERT, Precision-BERT F-BERT. Более детально про архитектуру подсчета BERTScore читайте тут.
6️⃣ G-Eval:
G-Eval (Generative Evaluation) создан для того, чтобы преодолеть ограничения статистических метрик (неустойчивость к формулировкам, разные длины сравниваемых текстов, непренимость к сложным задачам). В G-Eval в виде оценщика используются другие GPT-модели, например, GPT-4 от OpenAI. Оценка проводится через сравнительный анализ сгенерированного текста и эталонного примера по заранее выбранным критериям (согласованность, точность и т.д.).
🔥 Однако, это не весь список метрик, с помощью которых можно оценивать LLM, дополнительно читайте тут:
- Серия постов на Хабре про эволюцию NLP-метрик
- Ещё две статьи тут и тут про метрики, фреймворки и лучшие практики для оценки LLM.
- Отличная статья для погружения в бечнмаркинг LLM
- Статья с объяснением подхода "LLM-as-a-Judge" (LLM, как судья) [ENG]
- Evaluating-Cookbook - руководство по оценке LLM, созданное командой Hugging Face.
Ставьте ❤️ и 🔥 под постом!
Также пишите свои комментарии и вопросы! До встречи👋
🤖 Оценка языковых моделей также необходима, как и при работе с классическими ML-моделями. Однако, в случае с LLM задача усложняется тем, что мы должны оценивать текстовые данные.
💯 В этой части поста мы расскажем про наиболее популярные NLP-метрики для оценки языковых моделей, а уже в следующем посте поговорим про более продвинутые техники, включая бенчмарки.
❓ А в чем, собственно, отличие между метриками и бенчмарками:
Метрики - используются для измерения конкретных навыков аспектов работы модели (например, точность перевода с русского на английский) или могут использоваться, как часть бенчмарка.
Бенчмарки же — это наборы тестов, которые обычно включают множество задач и способов их оценок (метрик). Бенчмарки дают более масштабную оценку качества работы моделей, не в рамках отдельной задачи.
Поговорим про статистические метрики:
1️⃣ Перплексия:
Перплексия показывает, насколько точно модель предсказывает следующий токен: чем ниже значение, тем уверенее предсказание.
Например, если перплексия равна 1000, это означает, что модель в среднем имеет 1000 равновероятных вариантов для каждого следующего слова, что указывает на плохое качество предсказаний. Через перплексию в LLM можно определить галлюцинации, хоть и сама метрика не всегда коррелирует с качеством генерации текста.
Более подробно про перплексию и формулу данной меры читайте тут.
2️⃣ BLEU и ROUGE:
О данных метриках мы писали в одном из вопросов недавнего квиза (п.5) и оставляли хорошие материалы для изучения, советуем вернуться и ознакомиться.
3️⃣ METEOR:
Данная метрика создавалась, как улучшенная альтернатива BLEU, которая учитывает не только точное совпадение слов в сгенерированном тексте с эталонными примерами, но и их синонимы и морфологические варианты, что делает её более гибкой и устойчивой к разнообразным формулировкам. В добавок, метрика выдает штраф за неправильную фрагментацию текста и неверный порядок слов. Подробно про методику расчет METEOR смотрите в этом видео.
4️⃣ Классические ML-метрики:
Оценивать текст можно также, как и числа, используя ML-метрики. Например, посчитать количество слов (токенов) в сгенерированном примере, вошедшие в эталонный пример - accuracy. Или посчитать recall через количество слов, вошедшие в эталонный пример (TP), но, учитывая недостающие токены (FN).
Теперь поговорим про model-based метрики:
5️⃣ BERTScore:
Данная метрика в процессе расчета использует BERT-модели, чтобы через векторные представления слов в предложении оценивать схожесть текстов. Кратко процесс оценки выглядит следующим образом: получение эмбеддингов для каждого слова в сгенерированном и эталонном текстах с помощью BERT. И затем (в упрощенном виде) по косинусному сходству токены из сгенерированного текста сопоставляются с токенами эталонного текста, после чего высчитывается Recall-BERT, Precision-BERT F-BERT. Более детально про архитектуру подсчета BERTScore читайте тут.
6️⃣ G-Eval:
G-Eval (Generative Evaluation) создан для того, чтобы преодолеть ограничения статистических метрик (неустойчивость к формулировкам, разные длины сравниваемых текстов, непренимость к сложным задачам). В G-Eval в виде оценщика используются другие GPT-модели, например, GPT-4 от OpenAI. Оценка проводится через сравнительный анализ сгенерированного текста и эталонного примера по заранее выбранным критериям (согласованность, точность и т.д.).
🔥 Однако, это не весь список метрик, с помощью которых можно оценивать LLM, дополнительно читайте тут:
- Серия постов на Хабре про эволюцию NLP-метрик
- Ещё две статьи тут и тут про метрики, фреймворки и лучшие практики для оценки LLM.
- Отличная статья для погружения в бечнмаркинг LLM
- Статья с объяснением подхода "LLM-as-a-Judge" (LLM, как судья) [ENG]
- Evaluating-Cookbook - руководство по оценке LLM, созданное командой Hugging Face.
Ставьте ❤️ и 🔥 под постом!
Также пишите свои комментарии и вопросы! До встречи👋
Forwarded from DevFM
Почему не нужно отвлекать программиста
Во время работы программист создаёт в голове воздушные замки и работает с ними. Это требует немалой концентрации, и любое внешнее прерывание приводит к необходимости снова загружать в свою оперативную память сложные абстракции. В отличие от компьютера, который почти мгновенно выгружает и загружает информацию, кожаному мешку обработка прерываний даётся достаточно тяжело.
В статье Как поймать «поток», и как сделать так, чтобы он не сорвался объясняется, что такое состояние потока и как постоянное прерывание этого самого потока замедляет работу. По оценке автора, погружение в состояние потока "стоит" 15 минут, то есть любое прерывание имеет вот такие дополнительные накладные расходы.
В статье Как я использую папки в Телеграм для удобства мы делились опытом, как можно настроить Телеграмм для асинхронного общения, что как раз направлено на сохранение потока.
#edu
Во время работы программист создаёт в голове воздушные замки и работает с ними. Это требует немалой концентрации, и любое внешнее прерывание приводит к необходимости снова загружать в свою оперативную память сложные абстракции. В отличие от компьютера, который почти мгновенно выгружает и загружает информацию, кожаному мешку обработка прерываний даётся достаточно тяжело.
В статье Как поймать «поток», и как сделать так, чтобы он не сорвался объясняется, что такое состояние потока и как постоянное прерывание этого самого потока замедляет работу. По оценке автора, погружение в состояние потока "стоит" 15 минут, то есть любое прерывание имеет вот такие дополнительные накладные расходы.
В статье Как я использую папки в Телеграм для удобства мы делились опытом, как можно настроить Телеграмм для асинхронного общения, что как раз направлено на сохранение потока.
#edu
Хабр
Как поймать «поток», и как сделать так, чтобы он не сорвался
Вступление Я, как руководитель проектов, всё больше и больше замечаю, что эффективность работы команды (и каждого программиста в частности) – это ключевой фактор, определяющий успех проекта. При...
Forwarded from Персонализация неизбежна
Про мой опыт в RecSys Research
Вчера нашу новую статью приняли на ECIR 2025 - это A-конференция (значит, входит в некоторый топ-23% от некоторого набора конференций) по информационному поиску в Италии 🎉! Статья про e-grocery рекомендации, но подробности позже. Это четвертая статья на основном треке A-конференций с моим участием и четырнадцатая, если считать еще воркшопы. В этом посте напишу про свой путь, как я к этому пришел.
Весна 2019 года. Я на 4 курсе ФРКТ МФТИ, меня берут на стажировку в ML-команду. Первая задача там - сделать обзор на методы объяснений рекомендаций. Я читаю статьи, вникаю в сам домен рекомендаций. В итоге получаю табличку с ~20 статьями, где выделены важные пункты про каждую работу. На тот момент кажется, что я прекрасно разобрался в теме.
2019-2020 учебные годы. Меня берут лаборантом в VK Lab при МФТИ в recsys. Чтобы пройти отбор, я реализовывал статью про музыкальные рекомендации и пытался догнать ALS по качеству. На тот момент отгремела статья "Are we really making much progress", где авторы победили нейронные модели через простые линейные. Моя же задача была либо в поиске, либо в создании такой нейромодели, которая в честном сравнении все-таки победила бы простую модель. Мы с коллегами собрали статью на RecSys 20, но ее не взяли. Это была моя первая статья на английском языке, писать было очень сложно и получалось плохо.
2021 год. На работе начинается ресерч. Я подключаюсь, провожу эксперименты, помогаю с текстом. Мы не успеваем подать статью на RecSys 21, подаем на CIKM 21. Там нашу статью не берут, в том числе потому, что мы подали не на тот трек. Статью мы все равно выложили и ее даже процитировали зарубежные авторы. Также в этом году мы занимаем 4 место в SIGIR challenge, и пишем статью на Хабр.
2022 год. Мы пишем дипломы со студентами ВШЭ. Темы предложили исходя из наших интересов, которые потенциально могли раскрутиться и доехать до прода. Некоторым студентам предлагаем обернуть результаты в научные статьи и подать на воркшопы при конференциях. Получаем публикации про графы знаний, индуктивные sequential модели. Также в октябре мы пишем статью на ECIR 23 про next-basket recommendation и ее берут!
2023 год. В этом году у нас получается много работ со студентами ВШЭ на воркшопах, которые преобразуются в статьи. Также мы едем на первую для нас международную конференцию ECIR в Ирландию, где рассказываем про нашу статью. Впечатлений много, и мы по возвращении вкладываемся в еще одну работу, и ее тоже принимают на RecSys 23! Мы едем презентовать статью и Сингапур, оказываемся в международном RecSys коммьюнити. Также я удивляюсь, как много людей приехало из России от разных компаний: Сбер, Яндекс, Одноклассники, Дзен. В этом же году я поступаю в аспирантуру МФТИ на кафедру от Т-Банка. Статьи-то уже есть, и вроде их можно будет засчитать для защиты диссертации.
2024 год. Мы занимаемся RnD по RL&RecSys, о чем я рассказывал в докладе на Turbo ML Conf. Также у нас принимают статью по BPR на reproducibility track на RecSys 24 - полноценный full paper. Чуть позже мы пишем новую статью на ECIR 2025 по e-grocery рекомендациям, и вот, под конец года, получаем решение, что ее принимают! Параллельно у нас ведется и другая работа, о которой расскажу позже)
Итого, мой опыт с recsys research - это постепенное и довольно долгое развитие. Чем больше пишешь тексты статей, тем лучше и легче они получаются. Есть еще много идей и планов, одной из которых является написание и защита диссертации в МФТИ. Кроме этого, конечно, в recsys research есть еще много плюсов, но о них я расскажу в другом посте.
Вчера нашу новую статью приняли на ECIR 2025 - это A-конференция (значит, входит в некоторый топ-23% от некоторого набора конференций) по информационному поиску в Италии 🎉! Статья про e-grocery рекомендации, но подробности позже. Это четвертая статья на основном треке A-конференций с моим участием и четырнадцатая, если считать еще воркшопы. В этом посте напишу про свой путь, как я к этому пришел.
Весна 2019 года. Я на 4 курсе ФРКТ МФТИ, меня берут на стажировку в ML-команду. Первая задача там - сделать обзор на методы объяснений рекомендаций. Я читаю статьи, вникаю в сам домен рекомендаций. В итоге получаю табличку с ~20 статьями, где выделены важные пункты про каждую работу. На тот момент кажется, что я прекрасно разобрался в теме.
2019-2020 учебные годы. Меня берут лаборантом в VK Lab при МФТИ в recsys. Чтобы пройти отбор, я реализовывал статью про музыкальные рекомендации и пытался догнать ALS по качеству. На тот момент отгремела статья "Are we really making much progress", где авторы победили нейронные модели через простые линейные. Моя же задача была либо в поиске, либо в создании такой нейромодели, которая в честном сравнении все-таки победила бы простую модель. Мы с коллегами собрали статью на RecSys 20, но ее не взяли. Это была моя первая статья на английском языке, писать было очень сложно и получалось плохо.
2021 год. На работе начинается ресерч. Я подключаюсь, провожу эксперименты, помогаю с текстом. Мы не успеваем подать статью на RecSys 21, подаем на CIKM 21. Там нашу статью не берут, в том числе потому, что мы подали не на тот трек. Статью мы все равно выложили и ее даже процитировали зарубежные авторы. Также в этом году мы занимаем 4 место в SIGIR challenge, и пишем статью на Хабр.
2022 год. Мы пишем дипломы со студентами ВШЭ. Темы предложили исходя из наших интересов, которые потенциально могли раскрутиться и доехать до прода. Некоторым студентам предлагаем обернуть результаты в научные статьи и подать на воркшопы при конференциях. Получаем публикации про графы знаний, индуктивные sequential модели. Также в октябре мы пишем статью на ECIR 23 про next-basket recommendation и ее берут!
2023 год. В этом году у нас получается много работ со студентами ВШЭ на воркшопах, которые преобразуются в статьи. Также мы едем на первую для нас международную конференцию ECIR в Ирландию, где рассказываем про нашу статью. Впечатлений много, и мы по возвращении вкладываемся в еще одну работу, и ее тоже принимают на RecSys 23! Мы едем презентовать статью и Сингапур, оказываемся в международном RecSys коммьюнити. Также я удивляюсь, как много людей приехало из России от разных компаний: Сбер, Яндекс, Одноклассники, Дзен. В этом же году я поступаю в аспирантуру МФТИ на кафедру от Т-Банка. Статьи-то уже есть, и вроде их можно будет засчитать для защиты диссертации.
2024 год. Мы занимаемся RnD по RL&RecSys, о чем я рассказывал в докладе на Turbo ML Conf. Также у нас принимают статью по BPR на reproducibility track на RecSys 24 - полноценный full paper. Чуть позже мы пишем новую статью на ECIR 2025 по e-grocery рекомендациям, и вот, под конец года, получаем решение, что ее принимают! Параллельно у нас ведется и другая работа, о которой расскажу позже)
Итого, мой опыт с recsys research - это постепенное и довольно долгое развитие. Чем больше пишешь тексты статей, тем лучше и легче они получаются. Есть еще много идей и планов, одной из которых является написание и защита диссертации в МФТИ. Кроме этого, конечно, в recsys research есть еще много плюсов, но о них я расскажу в другом посте.