Новый сервис для онлайн-школ

Покажет кто читает канал и кто покупает ваши курсы

Книга "Взгляд в будущее: шаги к себе"

61 проверенный способ достичь гармонии и счастья

TGStat - аналитика каналов и чатов

Подписывайся, чтобы быть в курсе новостей TGStat.

Статистика Избранное

Запрети мне псевдолейблить

@pseudolabeling

Гео и язык канала: Германия, Русский

Категория: Софт и приложения

Сутра:
1. Kaggle решат
2. Соревы обозреват
3. Gold фармить
4. Социальност
Канал о пути к Kaggle competitions Master, баварских сосисках и пиве, которым обливаешься в процессе
https://www.kaggle.com/asimandia
Для вопросов: @dimitriy_rudenko

Связанные каналы | Похожие каналы

Гео и язык канала

Германия, Русский

Категория

Софт и приложения

Статистика

Избранное

Фильтр публикаций

Скрывать удаленные

Скрывать репосты

Запрети мне псевдолейблить

26 Sep, 15:40

Во-вторых, теперь можно наконец-то нормально устанавливать пакеты через специальный интерфейс Package manager.

Представьте, теперь не надо создавать датасеты с source кодом и устанавливать все в ноутбук через магические команды jupyter. Самое полезное- это то, что теперь можно устанавливать пакеты в Code Competitions, когда код должен быть отправлен в ноутбуке, у которого нет доступа к интернету. Теперь код из Package Manager выполнится и установит нужные пакеты заранее и с интернетом. Кстати поддерживается только pip, никакого вам poetry и uv

Я очень давно ждал эту штуку, и теперь буду со всей силы ждать возможность качать данные не из tar.gz архива, а через что-нибудь с поддержкой разбивки частей архива и rsync или даже может быть с торрентов, потому что качать террабайт данных со скорость 5мб/сек одним большим куском- очень больно и слишком 2011. Тем более с текущей надежностью серверов с данными на каггле.

https://www.kaggle.com/discussions/product-feedback/532336tart

664 0 5 3 15

Запрети мне псевдолейблить

26 Sep, 15:39

На Kaggle случилось два апдейта.

Во первых, следуя за гитом и прочими платформами выкатили награды и бейджи:

Награды это какие-то ДОСТИЖЕНИЯ.
Например за то, что я был хостом соревнования Инстамарта (Сбермаркета (Купера)) на стажировку, я получил от Kaggle награду. Еще вот Сергею Фиронову дали ачивку за топ 100.

Бейджи дают за более доступные штуки:
Возраст акаунта
Стрики логинов
Форк ноутбуков
etc

Жду сториз и удаление стены!

Полный список бейджей

628 0 1 10

Запрети мне псевдолейблить

24 Sep, 11:00

Да в смысле вам не нравится. Объяснитесь!

819 0 2 6 9

Запрети мне псевдолейблить

23 Sep, 18:30

Глупый телеграм пережимает, вот вам оригинал:
https://www.linkedin.com/posts/astratoanalytics_datadna-dataviz-datadna-activity-7003783958660292608-da5X?utm_source=share&utm_medium=member_desktop

Безумно красивая визаулизация опыта и плотность инофрмации на пиксель. А еще визуальная метафора роста крутая, хотя там не только рост на самом деле
Единственная проблема, что в резюме вложено непропорционально больше времени, чем потратит на него хоть какой-то рекрутер

Astrato Analytics on LinkedIn: #datadna #dataviz #datadna #datachallenge #astrato

Check out this awesome entry to this month's #datadna challenge from Emily Cline! 🤩 Emily said: "I designed this interactive resume using Astrato Analytics…

930 0 14 25

Запрети мне псевдолейблить

23 Sep, 18:20

Обожаю датавиз, особенно функциональный. У кого-нибудь есть пины на пинтересте с красивыми дашбордами?
Одно из самых крутых, что я видел- это вот это резюме:

876 0 3 1 10

Запрети мне псевдолейблить

19 Sep, 20:02

Репост из: adapt compete evolve or die

оверфит начинается с головы, а ощущается гораздо ниже

1.3k 0 4 20

Запрети мне псевдолейблить

19 Sep, 12:36

Apache Parquet: как Twitter и Cloudera развивали дата инжиниринг

Apache Parquet начинался как совместный проект Twitter (ныне X) и Cloudera — компании, известной своими дистрибутивами Hadoop и инструментами для работы с ним. Многие, кто работал с Hadoop, вероятно, сталкивались с Cloudera и пользовались их решениями. Например, в Сбербанке используют их софт для обработки больших данных (Сбер за рекламу не платил, а мог бы).

Теперь давайте наглядно сравним Parquet с традиционным CSV-файлом, чтобы понять его преимущества. Возьмем простой пример CSV:

Имя, Пол, Год рождения, Вес, Рост, Дата записи
Владимир, М, 1954, 74, 179, 01/01/2024
Борис, М, 1931, 88, 187, 01/01/2024
None, М, None, 77, 178, 02/01/2024
Валерия, Ж, 1950, 150, 168, 02/01/2024

1. Колоночный формат
Первая ключевая особенность Parquet — это колоночное хранение данных. В CSV данные хранятся построчно, и для вычисления среднего значения, скажем, веса, вам нужно пройти по каждой строке, извлекая из нее данные. Это требует времени, особенно для больших наборов данных.

Parquet же хранит данные по колонкам. Сначала записываются все значения первой колонки, затем второй, и так далее. Например, для расчета среднего роста нужно считать только колонку с ростом, не затрагивая остальные данные. Это заметно ускоряет обработку.

Более того, в Parquet применяется метод сжатия RLE (Run Length Encoding), что эффективно для хранения повторяющихся значений и пропусков. Например:

Имя: (Владимир, [0]), (Борис, [1]), (Валерия, [3])
Пол: (М, [0, 1, 2]), (Ж,[3])

Таким образом, можно обрабатывать большие объемы данных быстрее и с меньшими затратами памяти. Библиотеки вроде Polars, благодаря колоночному формату, не будут загружать лишние данные при ленивых вычислениях, что делает их работу еще эффективнее.

Типизация данных, схемы и партиционирование
Каждый Parquet-файл сопровождается схемой, которая описывает структуру данных: какие есть поля, их типы, и где начинается блок с данными. Так как данные типизированы, можно сэкономить место. Например, колонку "Пол" можно хранить в виде числовых значений, а в схеме — просто словарь, который сопоставляет числа с реальными значениями ("М" и "Ж"). Помните, в CSV каждый символ весит минимум байт!

Теперь представим, что наш CSV-файл содержит миллиард строк. Это около 100 ГБ данных, что вполне помещается на обычный компьютер, но работать с таким файлом будет неудобно. Чтобы оптимизировать работу с большими данными, применяют партиционирование. Это разделение файла на несколько частей по какому-то признаку — например, по дате записи.

Разделив данные по дням, вы сможете, например, быстро посчитать средний рост людей только за вчерашний день, не обрабатывая весь миллиард строк. Более того, партиции можно читать параллельно в разных потоках, что еще больше ускоряет вычисления на современных многопроцессорных архитектурах. Библиотеки Pandas, Polars и Spark поддерживают такое параллельное чтение с помощью Apache Arrow.

Parquet — это мощный инструмент для работы с большими объемами данных благодаря колоночному хранению, эффективным алгоритмам сжатия и возможностям партиционирования. Для задач, связанных с большими данными, Parquet сильно удобнее и быстрее, чем традиционный CSV. Используя такие библиотеки как Polars и Spark, можно значительно ускорить обработку данных и снизить затраты на вычисления. А еще можно каждый день дописывать новую партицию за день и не менять структуру файлов и избежать дублирования

1.4k 0 28 5 33

Запрети мне псевдолейблить

17 Sep, 16:10

История с продвижением математики вперед с помощью ML пока не закончилась

Скоро будет онлайн-доклад от известного математического физика Сергея Гукова , где они решили один из вопросов в теории групп , который стоял 39 лет с помощью МЛ

https://t.me/sberlogabig/514

1.2k 0 11 20

Запрети мне псевдолейблить

9 Sep, 22:14

2k 0 6 72

Запрети мне псевдолейблить

9 Sep, 21:37

Все, преза кончилась. Весь шитпост спрячу в первый пост. Спасибо, что были с нами

1.8k 0 2 9

Запрети мне псевдолейблить

9 Sep, 20:14

BeVIT на ваших эпл часах? А может лучше на роботе пылесосе?

Эпл добавил neural engine в часы и обещают инференсить dense transformers

1.8k 0 3 1 2

Запрети мне псевдолейблить

6 Sep, 01:40

Сергей Фиронов завел свой канал. Если вы не в курсе кто это, вам тем более надо подписаться

https://t.me/abacabadabacaba404

2.4k 0 9 9 8

Запрети мне псевдолейблить

2 Sep, 15:24

Снова про Polars.
Очень рекомендую подкаст для свободных слушателей на английском о том, как библиотека построена с точки зрения Rust сообщества:
Spotify: https://open.spotify.com/episode/7CrTW3a3X2Kd2q6at3LsJW?si=xqIHROIlTKut5fYCKcda_Q
Self-hosted: https://rustacean-station.org/episode/ritchie-vink/

Вот пока слушал подкаст еще раз вдохновился всем объяснить почему polars круто и быстро.

Polars — это такая попытка взять лучшее из Spark и Pandas. Если грамотно спроектировать пайплайн на Polars, то можно обрабатывать данные без смены технологии до тех пор, пока они помещаются на физическую машину. Представьте: вытянуть кучу данных из S3-хранилища, выполнить сложные преобразования и вернуть их обратно, как на Spark, но при этом дебажить и экспериментировать с пайплайном можно так же быстро, как на Pandas. В итоге, это еще и работает быстрее, чем Pandas.

Достигается все известным трюкам, просто вынесенным в Python-интерфейс и выполняемым локально, а не на далекой и сложной для дебага JVM в облаке с множеством уровней доступа и доступ-привратниками Data Lake, которые тайно молятся Adeptus Mechanicus уже пять поколений.

Первый кирпичик — это ленивое вычисление (lazy evaluation). В Pandas для выполнения одной операции условно есть два пути: использовать исключительно Python-движок (так никто не делает, но можно), что, конечно, медленно. Второй вариант — конвертировать данные в Cython и обрабатывать их с его помощью. Для этого нужно сначала выести строгие типы данных, сконвертировать данные в них, подобрать нужный кусочек Cython-кода, выполнить вычисления, а затем сконвертировать данные обратно в Python-объекты и вернуть результат. Автоматически и без головной боли, но надо так делать для каждой операции, а их у нас в пайплайне могут быть сотни.

Ленивое вычисление позволяет уменьшить этот оверхед на конверсии данных туда и обратно. Сначала мы описываем все преобразования в пайплайне, затем по этому пайплайну строится граф вычислений, который компилируется в Rust и исполняется. Вдобавок, прямо из коробки идут два дополнительных преимущества: до компиляции граф можно оптимизировать и распараллелить на многопоточность с помощью очередей. Это позволяет выполнить меньше операций, а время выполнения сделать быстрее, потому что в среднем можем больше вычислительных ресурсов эффективно утилизировать в единицу времени.

Второй кирпичик — это стриминг (streaming). Предположим, данных стало существенно больше или ресурсов стало меньше. Классический пример: вам на Kaggle дали 250 ГБ таблиц для расчета фичей для вашего ML. У вас есть 32 ГБ ОЗУ, так что все эти таблицы вместе в память не влезут. Обычно решение выглядит так: мы считаем одну группу фич, сохраняем их в памяти для финального этапа (или пишем в CSV), и, ловко оперируя gc.collect() и del, выбрасываем ненужные промежуточные куски из памяти Python. Получается неудобно и костыльно.

Стриминг позволяет сделать что-то подобное, но интеллектуально и автоматически. Polars строит индекс по таблицам и разбивает все данные на части, не загружая их полностью в память. Затем вычисляет связи между этими батчами и оптимизирует граф их взаимодействий так, чтобы в самом "широком по памяти" месте графа использовать не более доступной памяти, но при этом обрабатывать каждый батч как можно быстрее. И только после этого читает каждый индексированный батч данных с диска, обрабатывает его и выполняет вычисления до конца пайплайна. А если вдруг где-то не хватит места, то Polars может притормозить и дампнуть какой-нибудь батч на диск, чтобы обработать прочие. Это можно сравнить с тем, как если нужно выкопать яму, вместо попытки сразу сдвинуть тонну песка, можно впятером быстро перекидать его лопатами. Только представьте, как это шикарно дружится с Parquet!

Если представить не можете, ставьте 🤔️️️️️️. Напишу пост про Parquet и станет сильно понятнее

Polars with Ritchie Vink :: Rustacean Station

Come journey with us into the weird, wonderful, and wily world of Rust.

3k 1 68 6 77

Запрети мне псевдолейблить

25 Aug, 18:56

Сколько стоит политическая позиция админа

2.5k 0 2 12 67

Запрети мне псевдолейблить

19 Aug, 11:13

Как ведет себя поиск по эмбедингам разных моделей при применении Binary Quantization?

Аккуратно, контент сложноприкольный. Возможно стоит перечитать пару последних постов отсюда

Собрав все предыдущие посты вместе, хочу поделиться недавними экспериментами.

У Qdrant есть не только векторная база данных, но и fastembed, питонический пакет для быстрого и простого извлечения эмбеддингов. Быстро — потому что поддержка параллелизации встроена из коробки и работает без лишних усилий на разных бекендах. Просто — потому что минимум зависимостей и все они лёгкие, без необходимости тянуть за собой 3 Гб torch или 1.5 Гб Tensorflow. Эмбеддинги можно извлекать как из текстов, так и из картинок.

Из четырёх моделей для картинок я добавил в репозиторий три, что позволило легко использовать именно этот инструмент.

Вопросы, которые я себе задал:
1. Как влияет использование разных моделей на производительность Qdrant?
2. Как изменяется время поиска для разных моделей при увеличении параметра EF (который отвечает за количество связей на очередном слое HNSW)?
3. Какие модели наименьшим образом деградируют при переключении в режим BQ?
4. Что объединяет модели, которые работают с BQ хорошо и плохо?

Для ответа на эти вопросы я взял 10% данных Imagenet с любимого Kaggle, заэмбеддил их и залил в базу. Бенчмарк сравнивал метрики качества поиска с Exact search (честное сравнение каждого запроса со всеми объектами в базе) по метрике Dot_product. Для тестирования использовал все доступные в fastembed модели для картинок:

clip-ViT-B-32-vision — живая классика.
Unicom-ViT-B-16 — специальная модель из open metric learning.
Unicom-ViT-B-32 — тоже модель для open metric learning (по менбше).
ResNet50 — полуживая классика.

Основные выводы:
1. Время поиска линейно зависит от параметра EF, а скорость поиска — от размера эмбеддингов.
2. Качество поиска от EF скейлится логарифмически, что делает этот компромисс очень выгодным.
3. ResNet50 плохо работает с BQ, в то время как модели, специально обученные для metric learning, показывают минимальную деградацию.

Общий вывод:
Если бы я начинал стартап по поиску похожих лиц, то выбрал бы Unicom-16b. Это позволило бы при росте числа лиц легко переключиться на Binary Quantization с оверсемплингом и минимально потерять в качестве.

А теперь приглашаю к обсуждению в комментариях:

1. Влияет ли loss-функция, на которую обучалась модель, на её деградацию в BQ?
2. Какие модели стоит ещё попробовать?
3. Какую другую метрику близости стоило использовать для сравнения и почему?

2.8k 1 45 6 23

Запрети мне псевдолейблить

18 Aug, 12:03

Ускоряем HNSW: Квантизация для ANN-поиска

Где красивые алгоритмы, там и красивые их ускорения от железа. Квантизация нейросетей — отличный способ уменьшить вес модели, ускорить инференс и жечь меньше электричества без значительных потерь в качестве. Так почему бы не применить этот подход в ANN-поиске?

Реализуем это максимально просто и эффективно: заменим все значения больше нуля на единицы, а все, что меньше нуля — на нули. Вот и все, Binary Quantization готова.

Что это дает? Значительное ускорение поиска. Вектор длиной 512 можно упаковать в 64 байта и использовать SIMD-инструкции на CPU. Почему это не сломает поиск? Потому что эмбединги как и сами нейросети содержат множество избыточных параметров, от которых можно избавиться без заметной потери качества. Иногда даже лучше становится!

Оптимальный подход — комбинированный. Сначала строим бинарный индекс, отбираем кандидатов с запасом например в два раза больше чем нам надо объектов, а затем выполняем полноценный поиск (либо в лоб, либо с использованием HNSW). Плюс ко всему, теперь весь бинарный индекс можно хранить в оперативной памяти и загружать полные вектора только по мере необходимости.

Ну все, теперь я вам всю базу рассказал, можно и оригинальный контент следующим постом закинуть.

2.1k 1 39 28

Запрети мне псевдолейблить

16 Aug, 12:01

Что за HNSW такой?

Базовый подход, на котором работает Qdrant, — это HNSW (Hierarchical Navigable Small World). Давайте разберёмся, что это такое и как оно работает.

Small world graphs — это такие графы, которые характеризуются высоким коэффициентом кластеризации и малым расстоянием между любой парой вершин. Navigable Small World использует эти свойства для поиска ближайших соседей в многомерном пространстве. Представим, что мы строим такую структуру на наших эмбеддингах, чтобы перемещаться по ней было эффективно. Как добиться этой эффективности?

Начинаем с эмбеддинга случайного объекта из нашей базы и шагаем по рёбрам графа в сторону эмбеддинга-запроса, пока не сойдёмся к локальному минимуму. Для каждой пары эмбедингов мы можем посчитать расстояние, так что идти в сторону ближайшего к эмбедингу-запросу вполне себе можем на каждом шаге. Если бы мы связали ребрами все эмбеддинги, каждый с каждым, то минимальное расстояние находилось бы за один шаг, но пришлось бы просмотреть n дистанций. Если связать все эмбеддинги в двусвязный список, то на каждом шаге будет выполняться только одно сравнение, но шагов придётся сделать столько, сколько у нас точек, что тоже не очень эффективно. Зато уже n/2 в среднем! Как найти баланс? Никак, надо тестить на каждой новой базе

Но есть некоторое соображение: рёбра "средней длины" в графе часто оказываются наименее полезными. По ним мы движемся к точке с умеренной скоростью, но их слишком много, и приходится делать много шагов. Это как передвигаться на автобусе в пределах МКАДа — долго и автобусов слишком много, так что приходится делать кучу пересадок. Легче доехать на метро до нужной станции, а затем сделать последнюю милю на самокате.
Так что, построим наш граф поиска следующим образом:

1. Посчитаем расстояние от каждого объекта до каждого.
2. Возьмём случайный объект из базы и проверим, есть ли он в нашем графе поиска. Если есть — пропускаем. В первом прогоне его, конечно, там нет, но дальше цикл будет работать.
3. Возьмём X процентов ближайших объектов к целевому и построим между ними рёбра.
4. Сделаем то же самое с Y процентами самых дальних объектов.
5. Повторяем с пункта 2, пока не добавим в граф все объекты из базы.

Теперь на первых шагах мы будем часто пользоваться длинным ребрами, и в конце искать оптимум за счет коротких.
Да, в редких случаях (скажем, в 1% случаев) мы не найдём самого ближайшего соседа, но зато будем работать гораздо быстрее — скажем, в 12 раз. Конечно, всё сильно зависит от реализации, но ускорение впечатляет.

Вот и получается, что HNSW позволяет балансировать между количеством шагов и сравнений, что делает его отличным выбором для поиска ближайших соседей в больших базах данных.

А еще HNSW- в русской раскладке это РТЫЦ. Живите с этим

2k 1 53 23

Запрети мне псевдолейблить

15 Aug, 11:46

Кто такие ANN?

Вот сетап из 2018 года, которая отлично иллюстрирует, зачем нам нужны методы ускорения поиска похожих объектов, в частности, ANN (Approximate Nearest Neighbor). Сейчас все их используют для RAG, но мою историю я прочувствовал лично.

На одном из хакатонов PicsArt мы с двумя товарищами придумали интересное приложение: а что, если делать фотки людей и подбирать к ним наиболее похожих знаменитостей? Идея казалась крутой — пользователей точно бы привлекла, а дальше можно придумать, как на этом заработать. На хакатонах нужно быстро тестировать идеи и привлекать внимание, поэтому за ночь мы написали простенький апп для iPhone и сервер, который извлекал фичи из фотографий пользователей, а затем в векторном пространстве искал ближайшую знаменитость из нишевого жанра кино. 🔍

Маленькая деталь: по каким-то причинам почти все мужчины оказывались похожи на Стивена Вулфа

К сожалению, на том хакатоне первое место занял, кажется, Noize, а третье досталось девченкам, которые запустили домашку какого-то ММПшника с гитхаба по баесовским методам для склеивания нескольких плохих фоток в одну хорошую. Мы ничего не получили и на наш проект забили, а через полгода появился Gradient: Celebrity Look Like от того же PicsArt, который стал очень популярным и подозрительно похожим на нашу идею. Так я понял, зачем на самом деле нужны продуктовые хакатоны.

Представим, что мы бы продолжили наш сервис развивать. Пока у нас был датасет из 1000 знаменитостей, можно было справляться с поиском в лоб. Мы просто брали эмбеддинги размером в 512, меряли dot_distance каждый с каждым, и готово. Но дела сильно усложняются, если у нас миллион пользователей. А если хочется находить по-настоящему похожие фото, то может понадобиться и 100 миллионов изображений.

И вот тогда нужны ANN. Зачем сравниваться для запроса со всеми, если можно построить умную структуру данных и делать гораздо меньше сравнений? Примерно как в поиске по бинарному дереву, только сложнее и с учётом специфики задачи. ANN позволяет находить "почти ближайших соседей" за гораздо меньшее время, чем прямой перебор, что становится критически важным, когда база для поиска стремительно пухнет.

Если юзкейс кажется не очень, то представьте что мы на маркетплейсе все платья прогнали через Clip и хотим искать по текстовому запросу 'Красное платье' , даже если в описание указано, что платье 'Алое'.

В следующем посте расскажу, как я бенчмаркал Qdrant для поиска по картиночкам в разных режимах и разными моделями.

2.7k 2 54 10 62

Запрети мне псевдолейблить

3 Aug, 15:08

FOUND 1 #TODO
В португальском/испанском todo означается 'все' и является стоп-словом. Для пайчарма конечно это тоже стоп-слово и признак халутры

2.7k 0 7 2 21

Запрети мне псевдолейблить

17 Jun, 01:03

Я там тоже альтрузимом занимаюсь, и вас советую присоединиться. Однажды неизбежно надо будет диссер защищать

4.6k 0 3 21

Показано 20 последних публикаций.

1 914

подписчиков

Статистика канала

Популярное в канале

Снова про Polars. Очень рекомендую подкаст для свободных слушателей на английском о том, как библ...

Сергей Фиронов завел свой канал. Если вы не в курсе кто это, вам тем более надо подписаться htt...

Пост #184: Фото

BeVIT на ваших эпл часах? А может лучше на роботе пылесосе? Эпл добавил neural engine в часы и о...

Все, преза кончилась. Весь шитпост спрячу в первый пост. Спасибо, что были с нами