Comments 15
И мои 5 копеек:
1. В постановке задачи, наверное, следует еще добавить откуда вообще появилась задача детекции ботов. Думается, далеко не всем это понятно.
2. Вы ведь эту же технологию использовали на наших корпоративах? мне понравилось очень!
3. А k-medians, вместо k-means, не пробовали? у него, обычно, silhouette получается лучше. Правда, вместо абстрактных центроид получим конкретные медоиды. Возможно, вам это не подходит.
- Мотивировка задачи детекции ботов это немного другая история. В данной статье хотелось поделиться именно нюансами работы с индексами и рассказать о нашем опыте.
- Да, мы использовали самый простой IndexFlatL2. Всё успешно работало, но данных оказалось совсем мало, поэтому было не так уж интересно.
- K-medians не пробовали, так как в FAISS для кластеризации вшит только метод k-means. Реализация иных методов разработчиками не подразумевается. Видимо в связи с тем, что вычисление на GPU норм отличных от L2 не оптимально и труднореализуемо.
Я, конечно, очень далека от IT-сферы, но сама суть того, что вы сделали, поражает)
Кстати, если я работаю в DAN, можно скинуть вам свою фотку и тоже поискать себя/своих клонов в инсте?)
Но такой индекс всего с десятком миллионов векторов размерности 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? Парсинг? С какими трудностями пришлось столкнуться при этом?
Здравствуйте!
А какие тайминги у поисковых запросов в индекс, который на диске хранится?
И ещё вопрос: вы новые картинки как вставляете, в реалтайме в основной индекс или время от времени делаете реиндексацию? У нас это привело к увеличению затрат оперативки при похожей структуре индекса.
Если очень грубо, самый первый поисковой запрос одного вектора в индексе из 315кк векторов занимает ~2.5 секунд (ищется ТОП-10 результатов).
На практике поиск у нас идет последовательно батчами по 8к векторов, каждые последующие запросы оказываются быстрее предыдущих, потому что FAISS по возможности подтягивает пройденные участки индекса в RAM, как я отмечал в другом комментарии. Для сравнения, второй поисковой запрос по тому же лицу с другим вектором (т.к. другая фотография) занимает уже ~1.7 сек.
Картинки мы вставляем не в реал-тайм, а разово, примерно раз в несколько дней. Поиск в индексе тоже не 24/7, а раз в неделю непрерывно несколько часов большими объемами.
С ростом индекса конечно же будет расти его размер и потребление памяти при поиске.
Добрый день. Спасибо большое за интересную статью. В выводах вы пишите, что "индекс «IVF262144, PQ64» полностью удовлетворил все наши нужды по скорости и точности поиска". Скажите пожалуйста, а есть у вас точные показатели точноти и скорости при ваших 315 миллионах векторов по сравнению с полным перебором, например.
Полный перебор на такой выборке займёт около 15 секунд в один поток, если всё сделать аккуратно, у нас же поиск занимал около 400 ms.
По качеству поиска данных не найду, посему предлагаю ориентироваться на бенчмарки от разработчиков faiss: https://github.com/facebookresearch/faiss/wiki/Indexing-1G-vectors
FAISS: Быстрый поиск лиц и клонов на многомиллионных данных