#dl #nlp
Векторизация и кластеризация текста работает по схеме use / LaBSE / SBERT + k-means + tf-idf.
https://github.com/MaartenGr/BERTopic
Векторизация и кластеризация текста работает по схеме use / LaBSE / SBERT + k-means + tf-idf.
https://github.com/MaartenGr/BERTopic
GitHub
GitHub - MaartenGr/BERTopic: Leveraging BERT and c-TF-IDF to create easily interpretable topics.
Leveraging BERT and c-TF-IDF to create easily interpretable topics. - GitHub - MaartenGr/BERTopic: Leveraging BERT and c-TF-IDF to create easily interpretable topics.
Forwarded from Пресидский залив (Nadia ズエバ)
⚡️ open close openai расщедрились и релизнули свой трансформер для voice tech задач в opensource!
Основное — это конечно английский asr, но также и много другого, например any-to-english translation. Тут нет явного рокетсаенса, но зато есть веса, обученные на огромном датасете, которые можно скачать прямо сейчас, что как мне кажется еще лучше 😎
Почему это круто?
На мой взгляд самая интересная часть это энкодер, который можно вытащить из пайплайна и использовать как устойчивый к различным трудным данным feature extractor. Разработчики говорят, что учили модель на почти 700k данных, среди которых были очень разные примеры — и с акцентами, и с шумами, и просто музыка. Отдельная боль в ASR — это когда из бекграунд музыки распознаются рандомные словаиногда нехорошие 🙃 то есть можно дофайнтюнить энкодер, а дальше поставить что угодно — от классификатора до voice conversion.
Полная модель с декодером тоже очень интересна — особенно, если вы не делаете бенчмарк на LibriSpeech, а работаете с клиентскими данными, которые часто содержат большое число шумов, акцентов, или даже пение и музыку (откройте демку, там будет k-pop🕺🏻). Сказано, что на таких данных модель по качеству лучше на 50% — как именно подсчитали эту цифру, правда, я не нашла 💁🏻♀️
В репозитории есть несколько конфигураций модели, как это было с GPT-семейством, от tiny c 39M до large c 1550M параметров, которая вполне может подойти для дистилляцииили kaggle-соревнований.
Кроме того, судя по демо, Whisper сразу делает расстановку знаков препинания. Base (вторая по величине модель) весит всего 140 мб, так что если убрать все ненужные части (или даже декодер), останется очень приятный размер, который вполне можно использовать на разного рода девайсах. Круто, желаю openai больше таких прикладных проектов 🌚
Подробнее читать тут
#tech
Основное — это конечно английский asr, но также и много другого, например any-to-english translation. Тут нет явного рокетсаенса, но зато есть веса, обученные на огромном датасете, которые можно скачать прямо сейчас, что как мне кажется еще лучше 😎
Почему это круто?
На мой взгляд самая интересная часть это энкодер, который можно вытащить из пайплайна и использовать как устойчивый к различным трудным данным feature extractor. Разработчики говорят, что учили модель на почти 700k данных, среди которых были очень разные примеры — и с акцентами, и с шумами, и просто музыка. Отдельная боль в ASR — это когда из бекграунд музыки распознаются рандомные слова
Полная модель с декодером тоже очень интересна — особенно, если вы не делаете бенчмарк на LibriSpeech, а работаете с клиентскими данными, которые часто содержат большое число шумов, акцентов, или даже пение и музыку (откройте демку, там будет k-pop🕺🏻). Сказано, что на таких данных модель по качеству лучше на 50% — как именно подсчитали эту цифру, правда, я не нашла 💁🏻♀️
В репозитории есть несколько конфигураций модели, как это было с GPT-семейством, от tiny c 39M до large c 1550M параметров, которая вполне может подойти для дистилляции
Кроме того, судя по демо, Whisper сразу делает расстановку знаков препинания. Base (вторая по величине модель) весит всего 140 мб, так что если убрать все ненужные части (или даже декодер), останется очень приятный размер, который вполне можно использовать на разного рода девайсах. Круто, желаю openai больше таких прикладных проектов 🌚
Подробнее читать тут
#tech
Forwarded from Борис опять
На днях друг попросил помочь поторговаться за зарплату. Вот что получилось.
Дано:
* Оффер на Аналитика, 150к руб, большой Телеком.
* Оффер на ML инженера, 150к руб, небольшая техкомпания в мутной сфере, назовем ее Смолтех.
* Назревающий оффер на ML инженера в Бигтех, куда больше всего хочется.
Наблюдения:
* Никто не хочет идти работать в Телеком, но они довольно богатые , поэтому определенно готовы заплатить много денег, чтобы заманить специалиста.
* Смолтех работает в мутной и почти маргинальной сфере с огромной маржой. К ним скорее всего не выстраиваются очереди желающих. Они просто обязаны платить выше рынка, чтобы компенсировать риски мутности.
* В Бигтехе, напротив, люди готовы работать за еду и строчку в резюме.
Предложил такую стратегию:
1. Собираем свои причины торговаться. Определяем для себя зачем нам деньги. Например: надо переезжать, кризис, нужны вложения. Встаем в положение “у меня нет выбора, кроме как принять решение в пользу лучшего предложения”.
2. Относим оффер Смолтеха в Телеком и говорим: у Смолтеха интереснее работа, а деньги такие же, но я хочу к вам, потому что у них мутный сектор, и, если вы поднимете оффер, то это станет решающим.
3. Телеком скорее всего поднимет оффер примерно до 170к.
4. Берем новый оффер от Телекома и несем в Смолтех. Говорим: Телеком предлагает больше денег, и сектор не такой мутный, но у вас интереснее работа и в целом больше хочется к вам.
5. Они скорее всего поднимут еще выше.
6. При любых обновлениях офферов сразу скидываем их в Бигтех: апдейт по ситуации.
7. Когда офер в Бигтехе дозреет, он скорее всего будет выше обоих. Конечно же говорим, что больше всего хотим к ним.
8. Повторяем действия до тех пор, пока все не скажут “нет”.
Как все обернулось:
1. Телеком поднялся до 165к увидев оффер от Смолтеха.
2. Смолтех поднялся до 180к.
3. Бигтех поднялся до 187к после налогов, плюс все корпоративные бонусы, которые можно оценить еще в примерно 10к.
4. Телеком и Смолтех отказались поднимать выше.
В итоге подъем почти на 25%!
Дано:
* Оффер на Аналитика, 150к руб, большой Телеком.
* Оффер на ML инженера, 150к руб, небольшая техкомпания в мутной сфере, назовем ее Смолтех.
* Назревающий оффер на ML инженера в Бигтех, куда больше всего хочется.
Наблюдения:
* Никто не хочет идти работать в Телеком, но они довольно богатые , поэтому определенно готовы заплатить много денег, чтобы заманить специалиста.
* Смолтех работает в мутной и почти маргинальной сфере с огромной маржой. К ним скорее всего не выстраиваются очереди желающих. Они просто обязаны платить выше рынка, чтобы компенсировать риски мутности.
* В Бигтехе, напротив, люди готовы работать за еду и строчку в резюме.
Предложил такую стратегию:
1. Собираем свои причины торговаться. Определяем для себя зачем нам деньги. Например: надо переезжать, кризис, нужны вложения. Встаем в положение “у меня нет выбора, кроме как принять решение в пользу лучшего предложения”.
2. Относим оффер Смолтеха в Телеком и говорим: у Смолтеха интереснее работа, а деньги такие же, но я хочу к вам, потому что у них мутный сектор, и, если вы поднимете оффер, то это станет решающим.
3. Телеком скорее всего поднимет оффер примерно до 170к.
4. Берем новый оффер от Телекома и несем в Смолтех. Говорим: Телеком предлагает больше денег, и сектор не такой мутный, но у вас интереснее работа и в целом больше хочется к вам.
5. Они скорее всего поднимут еще выше.
6. При любых обновлениях офферов сразу скидываем их в Бигтех: апдейт по ситуации.
7. Когда офер в Бигтехе дозреет, он скорее всего будет выше обоих. Конечно же говорим, что больше всего хотим к ним.
8. Повторяем действия до тех пор, пока все не скажут “нет”.
Как все обернулось:
1. Телеком поднялся до 165к увидев оффер от Смолтеха.
2. Смолтех поднялся до 180к.
3. Бигтех поднялся до 187к после налогов, плюс все корпоративные бонусы, которые можно оценить еще в примерно 10к.
4. Телеком и Смолтех отказались поднимать выше.
В итоге подъем почти на 25%!
Forwarded from Архив Программиста
Как выучить Python в 2023 году — свежая дорожная карта от комьюнити.
В дорожной карте собрали все самые популярные и актуальные инструменты за прошедший год. Для новичков это отличная шпаргалка и понимание, с чего стоит начать, а опытным разработчикам она подскажет, куда развивать дальше.
В хорошем качестве можно глянуть тут.
В дорожной карте собрали все самые популярные и актуальные инструменты за прошедший год. Для новичков это отличная шпаргалка и понимание, с чего стоит начать, а опытным разработчикам она подскажет, куда развивать дальше.
В хорошем качестве можно глянуть тут.
Forwarded from DevFM
Программа vs процесс vs поток
В 4-минутном видео Process vs Thread раскрывается популярный на собеседовании вопрос из заголовка. Программа с диска в момент запуска становится процессом, а в процессе может быть один и более поток с общим адресным пространством. Пара слов сказана и о корутинах / зелёных потоках. Про зелёные потоки будет отдельный пост.
Для более вдумчивого чтения про процессы и потоки можем порекомендовать 2 главу Современные операционные системы Таненбаума (4 издание, 2015 год).
#skills
В 4-минутном видео Process vs Thread раскрывается популярный на собеседовании вопрос из заголовка. Программа с диска в момент запуска становится процессом, а в процессе может быть один и более поток с общим адресным пространством. Пара слов сказана и о корутинах / зелёных потоках. Про зелёные потоки будет отдельный пост.
Для более вдумчивого чтения про процессы и потоки можем порекомендовать 2 главу Современные операционные системы Таненбаума (4 издание, 2015 год).
#skills
YouTube
FANG Interview Question | Process vs Thread
Subscribe to our weekly system design newsletter: https://bit.ly/3tfAlYD
Checkout our bestselling System Design Interview books:
Volume 1: https://amzn.to/3Ou7gkd
Volume 2: https://amzn.to/3HqGozy
Other things we made:
Digital version of System Design…
Checkout our bestselling System Design Interview books:
Volume 1: https://amzn.to/3Ou7gkd
Volume 2: https://amzn.to/3HqGozy
Other things we made:
Digital version of System Design…
Forwarded from Love. Death. Transformers.
#ml #statistics
Интересная книга с Байесовским подходом в анализе данных
https://www.stat.columbia.edu/~gelman/book/BDA3.pdf
Интересная книга с Байесовским подходом в анализе данных
https://www.stat.columbia.edu/~gelman/book/BDA3.pdf
Forwarded from Artificial stupidity
#statistics
Weighted Z-test для мета-анализа результатов экспериментов.
Мне попался на глаза пост от ebay про z-test для мета-анализа (спасибо коллегам). Так что сегодня поговорим про этот метод.
Итак. Предположим, что у нас есть несколько запусков одного теста (например, волны коммуникации со схожей механикой, либо повторный запуск какого-либо эксперимента).
У нас есть N тестов (например, N t-тестов для средних), для каждого из которых есть свое p-value, свое значение статистики и свой доверительный интервал. Мы думаем, что объединение разрозненных источников информации даст нам преимущество и позволить уточнить наши выводы, увеличив мощность полученного комбинированного теста.
Для one-sided теста у нас может использоваться Fishers method. Но в случае two-sided теста нам нужен другой способ. И тут на сцену выходит Z-test.
Мы можем скомбинировать наши p-values в комбинированный p-value, используя Z-статистики из каждого эксперимента и веса, которые получаются из выражения
Соответственно, в такой постановке мы уже проверяем комбинированную гипотезу. И на ее основе решаем, что же получилось для группы тестов. А больший объем информации дает нам большую мощность эксперимента.
Какие тут плюсы и минусы?
Плюсы:
- Тест может комбинировать отдельные результаты тестов с разными размерами выборки;
- Полученная комбинация имеет большую мощность, чем каждый отдельный тест
Минусы:
- Тест предполагает нормальность распределения (не забываем о Z-статистике при его расчете);
- Тест чувствителен к весам. Соответственно, есть возможность того, что какой-то тест попросту перевесит все остальные;
- Комбинированный тест может быть сложнее к пониманию и реализации, чем единичный обычный проведенный тест
Weighted Z-test для мета-анализа результатов экспериментов.
Мне попался на глаза пост от ebay про z-test для мета-анализа (спасибо коллегам). Так что сегодня поговорим про этот метод.
Итак. Предположим, что у нас есть несколько запусков одного теста (например, волны коммуникации со схожей механикой, либо повторный запуск какого-либо эксперимента).
У нас есть N тестов (например, N t-тестов для средних), для каждого из которых есть свое p-value, свое значение статистики и свой доверительный интервал. Мы думаем, что объединение разрозненных источников информации даст нам преимущество и позволить уточнить наши выводы, увеличив мощность полученного комбинированного теста.
Для one-sided теста у нас может использоваться Fishers method. Но в случае two-sided теста нам нужен другой способ. И тут на сцену выходит Z-test.
Мы можем скомбинировать наши p-values в комбинированный p-value, используя Z-статистики из каждого эксперимента и веса, которые получаются из выражения
w_i = 1 / SE_i, где SE_i - это standart error для i-го эксперимента (формула построения доверительного интервала комбинированного эксперимента есть в исходном посте по ссылке в начале).Соответственно, в такой постановке мы уже проверяем комбинированную гипотезу. И на ее основе решаем, что же получилось для группы тестов. А больший объем информации дает нам большую мощность эксперимента.
Какие тут плюсы и минусы?
Плюсы:
- Тест может комбинировать отдельные результаты тестов с разными размерами выборки;
- Полученная комбинация имеет большую мощность, чем каждый отдельный тест
Минусы:
- Тест предполагает нормальность распределения (не забываем о Z-статистике при его расчете);
- Тест чувствителен к весам. Соответственно, есть возможность того, что какой-то тест попросту перевесит все остальные;
- Комбинированный тест может быть сложнее к пониманию и реализации, чем единичный обычный проведенный тест
Forwarded from DevFM
Идемпо… что? Улучшаем API
Когда писал пост про работу с HTTP, обнаружил непростительную оплошность. Мы ни разу не рассказывали о такой супер важной штуке, как идемпотентность API.
Начало статьи Стажёр Вася и его истории об идемпотентности API очень метко характеризует этот термин:
Звучит сложно, говорят о ней редко, но это касается всех приложений, использующих API в своей работе.
В реальных приложениях не всё идет гладко, нужно продумывать граничные случаи, случаются таймауты, перезапросы, дубли.
Автор на примере приложения Такси и всего одной кнопки "Заказать такси" рассказывает о множестве подвохов, которые поджидают разработчика.
Из-за затупа с базой пользователь дважды нажал кнопку Заказать и приехало две машины.
Что ж, на фронте начали блокировать кнопку Заказать, пока не придет ответ с сервера.
Оказалось, этого не достаточно. Из-за проблем с сетью по таймауту возникла ошибка и клиентское приложение разблокировало кнопку Заказать. Но кто бы мог подумать... проблема проблемой, но до сервера запрос дошёл и даже выполнился. По итогу имеем снова две машины. Эту проблему поправили уже на беке, добавив пару if.
Проблема решена, можно заканчивать статью. А потом тарам-пам-пам... классика. Менеджер изменил бизнес требования и старое решение уже не подходит.
Тут-то автор и подходит к сути статьи. Ключ идемпотентности, что за зверь такой, как он поможет решить обозначенную проблему. Но не всё так просто, поэтому далее в статье раскрываются ещё несколько тонких моментов.
Когда я первый раз прочитал эту статью в далёком 19 году, то был в искреннем восторге, насколько доступно и на понятных примерах можно раскрыть тему. А классический пример с заказчиком: от "нам это не нужно абсолютно точно" до "срооооочно нужна эта фича" — просто вишенка на торте.
#skills
Когда писал пост про работу с HTTP, обнаружил непростительную оплошность. Мы ни разу не рассказывали о такой супер важной штуке, как идемпотентность API.
Начало статьи Стажёр Вася и его истории об идемпотентности API очень метко характеризует этот термин:
Звучит сложно, говорят о ней редко, но это касается всех приложений, использующих API в своей работе.
В реальных приложениях не всё идет гладко, нужно продумывать граничные случаи, случаются таймауты, перезапросы, дубли.
Автор на примере приложения Такси и всего одной кнопки "Заказать такси" рассказывает о множестве подвохов, которые поджидают разработчика.
Из-за затупа с базой пользователь дважды нажал кнопку Заказать и приехало две машины.
Что ж, на фронте начали блокировать кнопку Заказать, пока не придет ответ с сервера.
Оказалось, этого не достаточно. Из-за проблем с сетью по таймауту возникла ошибка и клиентское приложение разблокировало кнопку Заказать. Но кто бы мог подумать... проблема проблемой, но до сервера запрос дошёл и даже выполнился. По итогу имеем снова две машины. Эту проблему поправили уже на беке, добавив пару if.
Проблема решена, можно заканчивать статью. А потом тарам-пам-пам... классика. Менеджер изменил бизнес требования и старое решение уже не подходит.
Тут-то автор и подходит к сути статьи. Ключ идемпотентности, что за зверь такой, как он поможет решить обозначенную проблему. Но не всё так просто, поэтому далее в статье раскрываются ещё несколько тонких моментов.
Когда я первый раз прочитал эту статью в далёком 19 году, то был в искреннем восторге, насколько доступно и на понятных примерах можно раскрыть тему. А классический пример с заказчиком: от "нам это не нужно абсолютно точно" до "срооооочно нужна эта фича" — просто вишенка на торте.
#skills
Telegram
DevFM
15 тривиальных фактов о правильной работе с протоколом HTTP
Полезный чеклист для всех, кто разрабатывает веб-приложения. По сути, это сборник разных и важных знаний из разных стандартов. В конце автор приводит ссылки на эти самые стандарты, так что особо…
Полезный чеклист для всех, кто разрабатывает веб-приложения. По сути, это сборник разных и важных знаний из разных стандартов. В конце автор приводит ссылки на эти самые стандарты, так что особо…
Forwarded from DevFM
Зелёные потоки в Python
Переключение между потоками — процесс очень затратный по времени, как мы уже разбирали. Для решения этой проблемы были придуманы зелёные потоки (green threads, они же coroutines или корутины), у которых вместо честного переключения потоков операционной системой реализуется виртуальное переключение потоков в пользовательском пространстве. Для IO-bound задач, где бутылочным горлышком являются медленные операции ввода-вывода, в том числе сетевого, зелёные потоки являются спасением. Для CPU-bound задач, где надо много физически вычислять на процессоре и нет простоев зелёные потоки не нужны.
Предлагаем прочитать статью Асинхронный python без головной боли (часть вторая). Начинается статья с наглядного примера асинхронности из жизни. Часто у начинающих разработчиков можно наблюдать ошибку, когда вместо подписки на событие, например, изменения файла, реализуется "жужжалка", которая в бесконечном цикле дёргает метаданные файла, загружая CPU на 100%.
Дальше на примере показывается async-await с разными нюансами, в том числе с необходимостью асинхронных функций. Потом показывается взаимосвязь корутин и генераторов, асинхронные контекстные менеджеры и приложение, которое асинхронно что-то делает с сервисом погоды.
Во второй части речь про event loop, про пример с API gateway, дополнение сервиса погоды переводчиком, асинхронным логгированием и базой.
#python
Переключение между потоками — процесс очень затратный по времени, как мы уже разбирали. Для решения этой проблемы были придуманы зелёные потоки (green threads, они же coroutines или корутины), у которых вместо честного переключения потоков операционной системой реализуется виртуальное переключение потоков в пользовательском пространстве. Для IO-bound задач, где бутылочным горлышком являются медленные операции ввода-вывода, в том числе сетевого, зелёные потоки являются спасением. Для CPU-bound задач, где надо много физически вычислять на процессоре и нет простоев зелёные потоки не нужны.
Предлагаем прочитать статью Асинхронный python без головной боли (часть вторая). Начинается статья с наглядного примера асинхронности из жизни. Часто у начинающих разработчиков можно наблюдать ошибку, когда вместо подписки на событие, например, изменения файла, реализуется "жужжалка", которая в бесконечном цикле дёргает метаданные файла, загружая CPU на 100%.
Дальше на примере показывается async-await с разными нюансами, в том числе с необходимостью асинхронных функций. Потом показывается взаимосвязь корутин и генераторов, асинхронные контекстные менеджеры и приложение, которое асинхронно что-то делает с сервисом погоды.
Во второй части речь про event loop, про пример с API gateway, дополнение сервиса погоды переводчиком, асинхронным логгированием и базой.
#python
Telegram
DevFM
Программа vs процесс vs поток
В 4-минутном видео Process vs Thread раскрывается популярный на собеседовании вопрос из заголовка. Программа с диска в момент запуска становится процессом, а в процессе может быть один и более поток с общим адресным пространством.…
В 4-минутном видео Process vs Thread раскрывается популярный на собеседовании вопрос из заголовка. Программа с диска в момент запуска становится процессом, а в процессе может быть один и более поток с общим адресным пространством.…
#career
Матрица компетенций в области SWE
https://sijinjoseph.netlify.app/programmer-competency-matrix/
Матрица компетенций в области SWE
https://sijinjoseph.netlify.app/programmer-competency-matrix/
Sijin Joseph
Programmer Competency Matrix | Sijin Joseph
Note that the knowledge for each level is cumulative; being at
level n implies that you also know everything from the
levels lower than n.
Computer Science 2n (Level 0) n2 (Level 1) n (Level 2) log(n) (Level 3) Comments data structures Doesn’t know the difference…
level n implies that you also know everything from the
levels lower than n.
Computer Science 2n (Level 0) n2 (Level 1) n (Level 2) log(n) (Level 3) Comments data structures Doesn’t know the difference…
Forwarded from Small Data Science for Russian Adventurers
#полезно
Довольно любопытный блог, в основном тут описываются идеи научных статей. Тематика: оптимизация, тензорные разложения, GAN-ы. Из последних интересных постов: качество на тестовой выборке почти совпадает с качеством на синтетической выборке, построенной с помощью GAN-a, обученного на обучении (т.е. предсказывается качество на тесте).
https://www.offconvex.org
Довольно любопытный блог, в основном тут описываются идеи научных статей. Тематика: оптимизация, тензорные разложения, GAN-ы. Из последних интересных постов: качество на тестовой выборке почти совпадает с качеством на синтетической выборке, построенной с помощью GAN-a, обученного на обучении (т.е. предсказывается качество на тесте).
https://www.offconvex.org