Как стать автором
Обновить

Комментарии 15

Классная работа!!!

И мои 5 копеек:
1. В постановке задачи, наверное, следует еще добавить откуда вообще появилась задача детекции ботов. Думается, далеко не всем это понятно.
2. Вы ведь эту же технологию использовали на наших корпоративах? мне понравилось очень!
3. А k-medians, вместо k-means, не пробовали? у него, обычно, silhouette получается лучше. Правда, вместо абстрактных центроид получим конкретные медоиды. Возможно, вам это не подходит.
Большое спасибо!

  1. Мотивировка задачи детекции ботов это немного другая история. В данной статье хотелось поделиться именно нюансами работы с индексами и рассказать о нашем опыте.
  2. Да, мы использовали самый простой IndexFlatL2. Всё успешно работало, но данных оказалось совсем мало, поэтому было не так уж интересно.
  3. K-medians не пробовали, так как в FAISS для кластеризации вшит только метод k-means. Реализация иных методов разработчиками не подразумевается. Видимо в связи с тем, что вычисление на GPU норм отличных от L2 не оптимально и труднореализуемо.
Ребята, это просто огонь! Молодцы!

Я, конечно, очень далека от IT-сферы, но сама суть того, что вы сделали, поражает)

Кстати, если я работаю в DAN, можно скинуть вам свою фотку и тоже поискать себя/своих клонов в инсте?)
Спасибо! Радует, что материал интересен аудитории, далекой от IT!

Вы можете отправить свой запрос мне через корпоративную почту:)
Большое спасибо за статью. Недавно в статье Как помнить всех в лицо, или эффективный поиск лиц в большой базе про Faiss и Annoy было упомянуто только в комментариях и я не уделил этой информации должного внимания. До этого момента я даже не догадывался, что благодаря Faiss можно не только уменьшить размер потребляемой памяти, но ещё и сильно уменьшить занимаемое место на диске.

Но такой индекс всего с десятком миллионов векторов размерности 512 будет весить около 20Гб и занимать при использовании столько же RAM.
315 миллионах векторов индекс занимает 22 Гб дискового пространства и около 3 Гб RAM при использовании.
Я правильно понимаю, что использование «IVF262144, PQ64» помогло снизить размер данных на диске приблизительно в 30 раз, а потребление памяти в 200?
Спасибо!

Я правильно понимаю, что использование «IVF262144, PQ64» помогло снизить размер данных на диске приблизительно в 30 раз, а потребление памяти в 200?

Всё так, размер данных на диске действительно становится меньше приблизительно в 30 раз.

Если же говорить про потребление памяти, то даже при поиске в индексе, чьи Inverted Lists хранятся на диске, FAISS по возможности подтягивает данные в RAM. Данные о 3 Гб RAM были получены непосредственно перед публикацией статьи, во время необходимого нам поиска в индексе — при периодических запросах на поиск, использование RAM памяти было не более 3 Гб. Это как раз метаданные индекса и данные некоторых ранее пройденных участков, загружаемые в RAM для ускорения поиска в этих секторах в дальнейшем.
Интересная работа, спасибо!
Как фотографии с instagram брали? API? Парсинг? С какими трудностями пришлось столкнуться при этом?
В основном с помощью asyncio/aiohttp. Детально о механиках для подобной задачи уже много где писалось. Из трудностей хочется отметить, пожалуй, скорость получения данных и их объемы.

Здравствуйте!
А какие тайминги у поисковых запросов в индекс, который на диске хранится?


И ещё вопрос: вы новые картинки как вставляете, в реалтайме в основной индекс или время от времени делаете реиндексацию? У нас это привело к увеличению затрат оперативки при похожей структуре индекса.

Здравствуйте!

Если очень грубо, самый первый поисковой запрос одного вектора в индексе из 315кк векторов занимает ~2.5 секунд (ищется ТОП-10 результатов).

На практике поиск у нас идет последовательно батчами по 8к векторов, каждые последующие запросы оказываются быстрее предыдущих, потому что FAISS по возможности подтягивает пройденные участки индекса в RAM, как я отмечал в другом комментарии. Для сравнения, второй поисковой запрос по тому же лицу с другим вектором (т.к. другая фотография) занимает уже ~1.7 сек.

Картинки мы вставляем не в реал-тайм, а разово, примерно раз в несколько дней. Поиск в индексе тоже не 24/7, а раз в неделю непрерывно несколько часов большими объемами.
С ростом индекса конечно же будет расти его размер и потребление памяти при поиске.
Понятно :)
У нас около 400 ms по 95%% уходит на ответ из памяти при 350кк векторов в индексе, но у нас при этом реализовано realtime обновление данных, реиндексации нет.

Спасибо за статью, рад, что появляется больше информации об использовании faiss в проде, отличный инструмент.
Здравствуйте! Спасибо, что поделились опытом. А какую модель использовали? — сами тренеровали или брали pretrained из каталога insightface?
Приветствую!

Мы брали pretrained модели в insightface:

model = insightface.app.FaceAnalysis(det_name='retinaface_mnet025_v2', 
rec_name='arcface_r100_v1', ga_name='genderage_v1')


Модель для детекции выбрана с целью ускорения обработки данных, по умолчанию там стоит retinaface_r50_v1.

Добрый день. Спасибо большое за интересную статью. В выводах вы пишите, что "индекс «IVF262144, PQ64» полностью удовлетворил все наши нужды по скорости и точности поиска". Скажите пожалуйста, а есть у вас точные показатели точноти и скорости при ваших 315 миллионах векторов по сравнению с полным перебором, например.

Полный перебор на такой выборке займёт около 15 секунд в один поток, если всё сделать аккуратно, у нас же поиск занимал около 400 ms.

По качеству поиска данных не найду, посему предлагаю ориентироваться на бенчмарки от разработчиков faiss: https://github.com/facebookresearch/faiss/wiki/Indexing-1G-vectors

Зарегистрируйтесь на Хабре, чтобы оставить комментарий