Если очень грубо, самый первый поисковой запрос одного вектора в индексе из 315кк векторов занимает ~2.5 секунд (ищется ТОП-10 результатов).
На практике поиск у нас идет последовательно батчами по 8к векторов, каждые последующие запросы оказываются быстрее предыдущих, потому что FAISS по возможности подтягивает пройденные участки индекса в RAM, как я отмечал в другом комментарии. Для сравнения, второй поисковой запрос по тому же лицу с другим вектором (т.к. другая фотография) занимает уже ~1.7 сек.
Картинки мы вставляем не в реал-тайм, а разово, примерно раз в несколько дней. Поиск в индексе тоже не 24/7, а раз в неделю непрерывно несколько часов большими объемами.
С ростом индекса конечно же будет расти его размер и потребление памяти при поиске.
В основном с помощью asyncio/aiohttp. Детально о механиках для подобной задачи уже много где писалось. Из трудностей хочется отметить, пожалуй, скорость получения данных и их объемы.
Я правильно понимаю, что использование «IVF262144, PQ64» помогло снизить размер данных на диске приблизительно в 30 раз, а потребление памяти в 200?
Всё так, размер данных на диске действительно становится меньше приблизительно в 30 раз.
Если же говорить про потребление памяти, то даже при поиске в индексе, чьи Inverted Lists хранятся на диске, FAISS по возможности подтягивает данные в RAM. Данные о 3 Гб RAM были получены непосредственно перед публикацией статьи, во время необходимого нам поиска в индексе — при периодических запросах на поиск, использование RAM памяти было не более 3 Гб. Это как раз метаданные индекса и данные некоторых ранее пройденных участков, загружаемые в RAM для ускорения поиска в этих секторах в дальнейшем.
Мотивировка задачи детекции ботов это немного другая история. В данной статье хотелось поделиться именно нюансами работы с индексами и рассказать о нашем опыте.
Да, мы использовали самый простой IndexFlatL2. Всё успешно работало, но данных оказалось совсем мало, поэтому было не так уж интересно.
K-medians не пробовали, так как в FAISS для кластеризации вшит только метод k-means. Реализация иных методов разработчиками не подразумевается. Видимо в связи с тем, что вычисление на GPU норм отличных от L2 не оптимально и труднореализуемо.
Мы брали pretrained модели в insightface:
Модель для детекции выбрана с целью ускорения обработки данных, по умолчанию там стоит retinaface_r50_v1.
Если очень грубо, самый первый поисковой запрос одного вектора в индексе из 315кк векторов занимает ~2.5 секунд (ищется ТОП-10 результатов).
На практике поиск у нас идет последовательно батчами по 8к векторов, каждые последующие запросы оказываются быстрее предыдущих, потому что FAISS по возможности подтягивает пройденные участки индекса в RAM, как я отмечал в другом комментарии. Для сравнения, второй поисковой запрос по тому же лицу с другим вектором (т.к. другая фотография) занимает уже ~1.7 сек.
Картинки мы вставляем не в реал-тайм, а разово, примерно раз в несколько дней. Поиск в индексе тоже не 24/7, а раз в неделю непрерывно несколько часов большими объемами.
С ростом индекса конечно же будет расти его размер и потребление памяти при поиске.
Вы можете отправить свой запрос мне через корпоративную почту:)
Всё так, размер данных на диске действительно становится меньше приблизительно в 30 раз.
Если же говорить про потребление памяти, то даже при поиске в индексе, чьи Inverted Lists хранятся на диске, FAISS по возможности подтягивает данные в RAM. Данные о 3 Гб RAM были получены непосредственно перед публикацией статьи, во время необходимого нам поиска в индексе — при периодических запросах на поиск, использование RAM памяти было не более 3 Гб. Это как раз метаданные индекса и данные некоторых ранее пройденных участков, загружаемые в RAM для ускорения поиска в этих секторах в дальнейшем.