Блог Артёма Агасиева

Telegram: @aagasiev

Почему я не люблю облака

Они пиздец какие дорогие, вот почему.

При всем их удобстве для быстрого масштабирования, любой чих будет стоить кучи денег и то, что на каком-нибудь Hetzner ты сделаешь за 10 евро, в AWS будет стоить уже все 50. А еще, можно случайно выстрелить самому себе в ногу и сжечь килотонны денег просто так.

Моя персональная боль — платный трафик. Конечно, я в курсе, что за любую работу нужно отстегивать мешочек убитых енотов, но тут вот ребята из Cloudflare высыпали мешок соли на рану, примерно прикинув, что в AWS на исходящий трафик идет наценка от 350% до 8000% от его реальной стоимости.

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

Шпаргалка по отличиям ансамблевых методов в классификации

Раньше, бывало, забывал в чем отличия каждого из популярных ансамблевых методов, так что решил написать об этом краткую справку. Может, кому-то пригодится.

Стекинг

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

Пример из жизни: Спрашиваем всех своих знакомых, какой из двух автомобилей лучше купить.

Плюсы: Очень просто реализовать.
Минусы: Хуже качество, если сравнивать с бэггингом и бустингом.

Бэггинг

Много раз берем случайные выборки из наших данных и обучаем на них несколько моделей с одним и тем же алгоритмом. Ответы по каждому примеру собираем и подаем на вход финальному решающему алгоритму.

Пример из жизни: Разные трейдеры, рекомендуют покупать или продавать какую-то конкретную акцию в зависимости от подмножества знаний о всем рынке, которыми они обладают в данный момент.

Плюсы: Очень легко параллелится, быстро работает.
Минусы: Качество классификации хуже, чем у бустинга.

Бустинг

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

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

Плюсы: Высокое качество классификации.
Минусы: Медленно работает. т. к. если не заморачиваться, по умолчанию не параллелится.

Определение языка текста на Python

Для задач NLP бывает полезно предварительно определить язык текста с которым мы сейчас работаем.

Например, это может пригодиться в случае, если:

  1. Какая-то наша модель умеет работать корректно только с определенным набором языков
  2. Для каждого языка у нас есть отдельная модель
  3. Текст на разных языках нужно по разному подготавливать: выбрать нужный стеммер или токенайзер — особенно важно для китайского и японского языков.

В работе я использую для решения этой задачи три библиотеки: fastText от Facebook, Compact Language Detector v3 от Google и langdetect. У каждой из них свои преимущества и недостатки связанные с размерами моделей, скоростью работы и точностью. Но, в целом, судя по опыту, точнее всего работает именно fastText.

Для задачи определения языка у fastText есть две готовые модели: побольше, на 126 мб и поменьше, на 917 кб. Вторая будет менее точная, но обе поддерживают одинаковое количество языков — 176 штук.

Качаем обе и посмотрим как с ними работать:


wget https://dl.fbaipublicfiles.com/fasttext/supervised-models/lid.176.bin
wget https://dl.fbaipublicfiles.com/fasttext/supervised-models/lid.176.ftz

Загружаем обе модели:


import fastText

model_big = fastText.load_model('./lid.176.bin')
model_small = fastText.load_model('./lid.176.ftz')

Пробуем в работе:


print(model.predict(["hi"]))
print(model_small.predict(["hi"]))

И получаем довольно странный результат:


([['__label__ca']], [array([0.5109927], dtype=float32)])
([['__label__en']], [array([0.12450418], dtype=float32)])

Почему так? Библиотека настроена на работу с предложениями, а не с отдельными словами, поэтому точность на очень коротких текстах будет хромать. Хотя, забавно, что маленькая модель сработала тут лучше, чем большая. Попробуем с текстом подлиннее:


print(model.predict(["hi there, human"]))
print(model_small.predict(["hi there, human"]))

И получаем вполне приемлемый результат:


([['__label__en']], [array([0.84252757], dtype=float32)])
([['__label__en']], [array([0.83792776], dtype=float32)])

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

 Нет комментариев    45   5 мес   fastText   NLP   Python

Ошибка при работе с библиотекой implicit на GPU

Работаю тут с библиотекой implicit для питона, настроил всю инфраструктуру CUDA, прописал все пути, но все равно ловил странное исключение, при попытке использования ALS на GPU:

No CUDA extension has been built, can't train on GPU

Чтож, идем читать исходники als.py:


if not implicit.gpu.HAS_CUDA:
    raise ValueError("No CUDA extension has been built, can't train on GPU.")

Очевидно, HAS_CUDA == False, но с чего это вдруг? Находим инициализацию этой переменной в __init__.py:


try:
    import cupy  # noqa

    from ._cuda import *  # noqa

    HAS_CUDA = True
except ImportError:
    HAS_CUDA = False

Файл _cuda — локальный, значит остается только проверить наличие cupy на рабочей машине. И правда, все дело было именно в её отсутствии. Ну хоть сообщить то об этом нормально можно было? :(

Устанавливаем по  инструкции, запускаем fit на ALS и вуаля, все работает. На RTX 3090 прирост скорости обучения, по сравнению с Xeon W-2265, у меня был примерно в 20 раз, на разреженной матрице размерности 300000х100000.

 Нет комментариев    32   5 мес   CUDA   GPU   Python

Разработка и проектирование высоконагруженных систем Highload++ 2013

Три части лекции по проектированию высоконагруженных систем от Олега Бунина на Highload++ 2013. Хоть лекции и не самые свежие, но, как необходимая база знаний, актуальны до сих пор.

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

Ранее Ctrl + ↓