Потребовалось сейчас сделать быструю проверку того, что тип скачиваемого программой файла — картинка в формате webp, а если это не она, то не качать ее вовсе, ну или хотя бы не полностью.

Самый быстрый способ — сделать HEAD запрос и проверить content-type, например, с помощью питоновской библиотеки mimetypes:

import requests
import mimetypes

r = requests.head("https://.../image.webp")
file_ext = mimetypes.guess_extension(r.headers.get("content-type"), strict=False)

if file_ext == "webp":
    pass

Можно ли точно полагаться на ответ сервера? В целом, нет, ведь даже если этот заголовок с виду корректен, то в тело ответа сервер может запихнуть что угодно. Однако, можно отсеивать очевидно ненужные варианты типа text/plain или чего-то подобного.

А еще бывает так, что нужный файл отдается с не тем типом контента. Например, в моем случае нужное хранилище AWS S3 грешило тем, что отдавало файл картинки с заголовком binary/octet-stream.

А еще HEAD запрос может не поддерживаться веб-сервером.

И что делать-то? Будем использовать обертку над libmagic, библиотеку python-magic. Она позволит нам по небольшому чанку данных узнать mime тип получаемого контента.

import os
import magic
import requests
import mimetypes

local_filename = "/local/file/name.webp"

r = requests.get("https://.../image.webp", stream=True)
f = open(local_filename, "wb")

for chunk in r.iter_content(1024):
    mime = magic.from_buffer(chunk, mime=True)
    file_ext = mimetypes.guess_extension(mime, strict=False)

    if new_file_ext != "webp":
        f.close()
        os.remove(local_filename)
        break

    f.write(chunk)
else:
    f.close()
    # Тут уже что-то можем делать с полученным файлом.

Вроде, выглядит норм. Ну, еще обработку ошибок добавить бы не помешало, да.

Но вот с точки зрения работы с сетью есть некоторые сомнения, что в случае вызова break, requests реально считает только 1 кб данных. Беглое гугление скорее усугубило мои сомнения. Надо иметь это в виду и как-нибудь на досуге реально протестировать.

В общем, все.

P.S. Если mimetypes не смогла определить расширение файла webp по типу контента image/webp, то его стоит добавить вручную в один из файлов mime.types вашей системы. Например, для Ubuntu это файл /etc/mime.types, в который надо добавить строку:

image/webp    webp

Другие файлики, откуда mimetypes может загружать себе данные, прописаны в самой библиотеке в массиве knownfiles:

knownfiles = [
    "/etc/mime.types",
    "/etc/httpd/mime.types",                    # Mac OS X
    "/etc/httpd/conf/mime.types",               # Apache
    "/etc/apache/mime.types",                   # Apache 1
    "/etc/apache2/mime.types",                  # Apache 2
    "/usr/local/etc/httpd/conf/mime.types",
    "/usr/local/lib/netscape/mime.types",
    "/usr/local/etc/httpd/conf/mime.types",     # Apache 1.2
    "/usr/local/etc/mime.types",                # Apache 1.3
]

Для задач 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)])

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

Работаю тут с библиотекой 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.

При сборке Python биндинга крутой библиотеки StarSpace получил такую ошибку:

Traceback (most recent call last):
  File "test.py", line 1, in 
    import starwrap as sw
ImportError: /www/home/mntlp/Starspace/python/test/starwrap.so: undefined symbol: _Py_ZeroStruct

Возникает она потому, что я в данный момент работаю под anaconda, а биндинг собрался под другую версию Python. Пофиксить несложно. Открываем CMakeLists.txt и в начала файла, после строки

project(starspace)

устанавливаем пути к библиотекам и инклудам нужного нам питона:

set(PYTHON_LIBRARY "/home/user/anaconda3/lib")
set(PYTHON_INCLUDE_DIR "/home/user/anaconda3/include/python3.6m/")

А если работаем под виртуальной средой в anaconda, то вместо предыдущих путей нужно указать путь через нее:

set(PYTHON_LIBRARY "/home/user/anaconda3/envs/env_name/lib")
set(PYTHON_INCLUDE_DIR "/home/user/anaconda3/envs/env_name/include/python3.6m")

Дальше:

cd ./build
cmake --build .
cd -
cp ./build/starwrap.so ./test
cd test
python3 test.py

В общем, все как было в build.sh до возникновения ошибки.

С месяц назад, при записи JSON данных в лог, забыл отформатировать их json.dumps из питоновского dict’a в нормальный вид, а просто записал его при форматной печатью, преобразовав dict в str. Само собой, получил кучу данных в неудобоваримом виде, эх.

Как исправить? Стандартный json.loads теперь не воспримет такую строку как корректный JSON, т. к. с точки зрения формата она не валидна. Можно решить эту проблему при помощи функции ast.literal_eval.

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

Пример работы:

import ast
import json

# Наш преобразованный в строку dict()
s = "{'a': 'Text with \\'quotes\\''}"
j = json.loads(s)
# Получаем ошибку парсинга из-за одинарных кавычек
>> json.decoder.JSONDecodeError: Expecting property name enclosed in double quotes: line 1 column 2 (char 1)

# Парсим строку в dict
j = ast.literal_eval(s)
print(j)
>> {'a': "Text with 'quotes'"}
# Теперь уже дампим данные корректно
print(json.dumps(j))
>>{"a": "Text with 'quotes'"}