У кого есть предположения, как работал финд фейс, а точнее как он так быстро искал? Я вообще нихуя не пойму.Судя по интервью с разрабами, у них нейросеть выделяла то ли 80, то ли 128 точек на лице, ну это не важно. Я юзаю dlib, там нейросеть выдает 128 точек. Максимум который мне удалось добиться, это 7 секунд (!!!!) для поиска среди 1 млн фотографий. Это пиздец как долго. Я пробовал переводить все точки из float в int точность падает не критично вообще, но скорость выше, искать по 10 разным точкам вместо 128, а потом из этого результата делать детальный анализ по 128, упростил в два раза формулу поиска расстояния - всё равно сука долго.Даже допустим теоретически хотя я даже пробовать не хочу, нет смысла заставлю поиск работать на 8-16-etc ядрах, то скорость увеличится всего в 8-16-etc раз, то есть поиск по рашке всё равно будет занимать минуту, а то и больше.Проблема в том, что я не понимаю как вообще можно хэш или индекс или хоть что то из этих точек выделить, они могут быть как отрицательные, так и положительные, а ищется только лишь положительная разница между ними. Вот пример 10 первых точек из описания лица 2 разных людей, они все могут быть как + так и -[1.0] -41435182[1.1] 86082510[1.2] 73057301[1.3] -63838362[1.4] -161909908[1.5] 21032849[1.6] -79625226[1.7] -91760754[1.8] 198397651[1.9] -71357108[2.0] -248804286[2.1] -50261076[2.2] 74084460[2.3] -95639087[2.4] -193871259[2.5] -50331693[2.6] 45858778[2.7] -36446824[2.8] 134124800[2.9] -155780196А схожесть лица ищется примерно такabs([1.0] - [2.0]) + abs([1.1] - [2.1]) + .... + abs([1.127] - [2.127]) и чем меньше полученное число, тем лица более схожи или вообще один человек, в идеале эта разница должна стремиться к 0, но это будет только на одной и той же фотографии. Что значат эти точки - не известно, нельзя сказать что эти точки описывают глаза, а эти нос. Если например закрасить рот на одной фотке и сравнить их, то ВСЕ точки немного поменяются
>>1330190 (OP)>У кого есть предположенияНу наверное по фичам распределяет, на этапе препроцессинга можно кучу инфы получитьА нейронки для пидоров, думаю там они их для маркетинга приплели
>>1330213Типа такого что ли? В случае с лицами не будет работать. К тому же нейронка распознает лицо под углом, повернутое и тд, главное чтоб оба глаза видны были
>>1330230> В случае с лицами не будет работатьКококо, у меня древний фотик ебало находит без всяких твоих нейронок, ставлю литр пивчана, что там нихуя не нейронки
>>1330236Одно дело просто лицо найти, хули там надо то, 2 глаза да рот определить. Другое дело найти похожие лица, а в идеале одного и того же человека, да еще и на разных фотках
>>1330243Другого варианта и нет. Разве что у них сама нейронка какой то хэш генерировала, ну это хз. Твой же фотик так не мог, правильно?
>>1330275>Кого угодноА вот вопрос, почему лиц? Какая алгоритму на хуй разница, по идее должен распознавать все что угодно, любые объекты в различных ракурсах.
>>1330190 (OP)Возможно супералгоритм работает не на "обычных" CPU, которые можно в любом магазине купить, а ребята ради этого заморочились и перенесли "алгоритм" на железо, т.е. на FGPA.
>>1330287Ну если обучить на дорожные знаки, то будет знаки распознавать и тд>>1330296Они писали, что финд фейс на 4 серверах стоял не самых мощных. У меня есть только еще идея перенести базу на blazingDB какую нибудь, больше нет вариантов
>>1330297>Ну если обучить на дорожные знаки, то будет знаки распознавать и тдТогда почему они не обучают? Нахождение лиц менее перспективно, чем оценивание дорожной обстановки.
>>1330306>Тогда почему они не обучают? Нахождение лиц менее перспективно, чем оценивание дорожной обстановкилол че? почти все современные машины знаки на панель приборов выводят
>>1330325В гугле забанили что ли блять? У мерседеса такое есть, у ауди и бмв вроде тоже, про теслу молчу
>>1330373> У мерседеса такое есть, у ауди и бмв вроде тоже, про теслу молчуУ хуерса, ты рекламных роликов насмотрелся?
>>1330190 (OP)>Максимум который мне удалось добиться, это 7 секунд (!!!!) для поиска среди 1 млн фотографий.Насколько быстро надо?
ОП, лучше скажи, как ты собрался выкачивать все эти миллионы миллиарды фото ВК для анализа? Особенно учитывая что VK API имеет пиздецовые ограничения по количеству запросов.
>>1330822Ну ладно, если не за 1, то за 7 хотя бы, в 100 раз быстрее то есть. Пока только blazingdb и mapd нагуглил, надо будет убунту второй системой ставить, пока ебаться лень с этим, через пару дней может попробую
>>1330822Сколько у тебя реально получается запросов к API в секунду пока не сработает ограничение? Сколько весят фотки беларуси?
>>1330190 (OP)>Максимум который мне удалось добиться, это 7 секунд (!!!!) для поиска среди 1 млн фотографий.Ну и? А среди 100к фотографий? Распараллелил на сколько тебе нужно - получил те самые 0.5 секунд на ответ, или как быстро там он работал.Пока что вопрос масштабирования. Ну и да, наверняка они ебались с оптимизацией.
>>13308561 ядро ищет в 1 млн за 7 сек. В 100 млн надо будет 100 ядер, лол. И это еще учесть что тесты были на core i7, а на серверах ставят зеоны с отключенным бустом на 2 ггц, то есть надо будет 150 ядер. А если 300 млн фоток, то говорить даже нечего
Нужен алгоритм который каким то образом будет разделять миллионы дескрипторов лиц на типы и подтипы, например по ширине глаз, соотношению размеров носа и рта и тд. А дальше бинарное дерево поиска.
>>1330879Такое не сделать, я пробовал сделать некие опорные точки, например лицо со всеми координатам 0, или 10000000 и тд, всё равно чушь выдает всякую. Пробовал взять 10 разных лиц за эталон, думал что лицо определенного человека всегда будет похоже на лицо одного из эталонных, а хуй там. Вообще лица разных людей всегда в одном и том же диапазоне разницы, то есть взять 3 разных людей у них всегда будут примерно одни и те же расстояния друг от друга. По сути нейронка лишь может сказать на сколько процентов один человек похож на другого и всё, даже если жирного с тощим сравнивать, или тощего с тощим и тд
>>1330879ну и да, у людей настолько ничтожная разница в расстояниях глаз, носа и тд, что по фотке это просто нереально высчитать. Разве что в студийных условиях, но у нас то фотки то с мобильника, то еще какие
>>1330822Наговнякал на шарпе поиск n минимальных расстояний среди 100млн восьмиточечных записей. В однопоточном режиме на ноутбучном процессоре 2012 года работает за 4.6 секунды. Опчик, на каком тормозном говне ты кодишь?
>>1330963>>1330913Ну и еще, допустим даже 13 точек я смогу в ОЗУ хранить, но по 13 точкам я найду например 10.000 похожих лиц, которых надо будет еще по 128 точкам прогнать. Тут то что делать? Мускул обосрется наверное отдавать 10к строк по 10к айдишникам
>>1330963https://pastebin.com/L7aUVbW2100 млн записей по 8 точек за 1.8 секунды на моем ноутбуке. Перепиши нормально и на быстром языке да запусти на современном железе.
>>1331166Этот код считает минимальное расстояние до образца. Поиск нескольких ближайших ничего принципиально не меняет, тысяча ищется за 2.5 секунды. Полная проверка по 128 точкам нескольких тысяч выполняется за десятки микросекунд. Суть в том, что подобный код на С на современном железе с avx-512 прекрасно вписывается в требуемую производительность, если даже неоптимальный код на шарпе с кучей переаллокаций на голимом sse4 работает несколько секунд.
возможно тебе подойдет seq2seq. Это когда система сама подбирает минимальный размер хеша, который однозначно кодирует какое-то лицо. То есть не ты подбираешь features, а система делает минимально возможный набор, по которым однозначно идентифицируется сэмпл среди таких же других
>>1331199Хочешь сказать что питон к примеру в 1000 раз медленнее? Я могу допустить что он в 2, 3, 5 раз медленнее, но не 1000 жеж.Попробуй abs(1-1)+1 128кк раз прогнать
Задача называется k nearest neighbors.У тебя есть набор точек в многомерном пространстве, нужно найти ближайшую. Полный перебор работает за o(n) и никуда не годится.Ее решение - построить структуру данных, которая, будет работать как индекс. Для числа измерений n=2,3 лучше всего подходит квадро и октодерево. Лучше всего изучить, как они работают, чтобы была интуиция и для многомерных случаев. То есть набери octotree nearest neighbor и почитай про алгоритм.Но для n=2 мы делим плоскость на 4 квадрата, для n=3 мы делим куб на 8 подкубов. Несложно заметить, что для n=128 нам пришлось бы делить гиперпространство на 2^128 гиперкубов. Это неэффективно. Поэтому для n=128 лучше всего будет работать kd-дерево. Принцип в целом тот же, но мы делим пространство плоскостью на две части вдоль случайной оси, дальше каждое подпространство делим точно так же. kd tree nearest neighbor даст алгоритм - я его не изучал, если что, но пользовался им.Это - точные решения. Но для find face работают еще и приблизительные решения (approximate k nearest neighbors) - они дают приемлемые результаты. Они сводятся к тому, что мы может отобразить гиперпространство на пространство меньшей размерности, приблизительно сохраняя расстояния. Например, изучи как работает geohash. Есть прекрасная opensource библиотека от фейбука - faiss, где оно реализовано.FindFace можно сделать за вечер с помощью нейросетки из интернета и faiss.
>>1330879Вот чувак почти придумал kd-tree. Оставшийся шаг понять, что нам не нужна ширина глаз и т. д., нам достаточно осей в нашем 128-мерном пространстве для деления на типы и подтипы.
>>1331244>Попробуй abs(1-1)+1 128кк раз прогнать0.5 секунды>>1331295Дерево хороший вариант, но его придется перестраивать каждый раз при добавлении новой фотографии.
>>1331445>Дерево хороший вариант, но его придется перестраивать каждый раз при добавлении новой фотографии. Не придется, за O(log n) делается добавление в сбалансированное k-d дерево.
>>1331445>0.5 секундыХм. Видимо потому что у тебя в озу сразу данные. А мне их с диска читать надо. Ну все равно это не выход, 128 точек и инфу об аккаунте в озу хранить очень дорого. А хранить например 14 точек, искать 40.000 ближайших аккаунтов = очень долгий запрос по выборке 128 точек у этих аккаунтов для детального подсчета. Надо будет эти деревья глянуть, где то вчера на библиотеку от спотифай натыкался
>>1331645> 128 точек и инфу об аккаунте в озу хранить очень дорогоА почему бы не хранить не всю инфу об аккаунте а только ключ, и потом по ключу из БД уже брать инфу об аккаунте?
>>1331199> Я могу допустить что он в 2, 3, 5 раз медленнееНу на голой математике без оптимизаций у меня в среднем в 60-90 раз медленнее получается
>>1331680Ну так, считай в базе условно 10 млн лиц, 13 поисковых точек держим в озу. Мы при первом грубом отборе нашли например 40.000 похожих лиц, далее надо более точно найти по 128 точкам уже, это уже надо будет из базы выгружать. Сколько там времени займет выгрузка 40к лиц по айдишнику причем, а не всех подряд. Я думаю не меньше 30 сек, или минуты, не тестил
>>1331741А если 200 млн лиц, или 300 даже, то при грубой выборке мы получим например 1млн похожих лиц, такое из базы уже точно не выгрузить за секунду будет
>>1331741128 точек sizeof(float) + sizeof(long) = (128 4) + 8 = (520 100кк) / (1024 1024) = 49591МБТ.е. всего тебе нужно 50ГБ ОЗУ для 100кк записей которые состоят из 128ми точек + ключа (айдишника профиля в БД). Скажем средний сервер будет иметь 8гб оперативы итого тебе нужно 50 / 8 = всего лишь 7 серверов.
>>1331747>128 точек (умножить на) sizeof(float) + sizeof(long) = (128 (умножить на) 4) + 8 = (520 (умножить на) 100кк) / (1024 (умножить на) 1024) = 49591МБ
>>1330859Очевидно что сервис кешировал результаты и первая выборка всегда делалась по кешу. От того и не 7 сек.
>>1331776Да ниче он там не кэшировал. Люди же всегда разных людей искали, а не только условного путина или еще кого
>>1331777Видел когда то прожки для состовления фотороботов? Ну где срез глаз подставляется, причесочка, хуе мое?
>>1331780А причем тут финдфейс? Подбор размера глаз и прочее будет работать только если человек ровно в камеру смотрит и все масштабы известны. Тут другая система - какая - неизвестно, нейросеть сама какие то точки для себя определила, что они значат никто не знает. Ну если покопаться то думаю можно найти, но это всё равно что в чан с говном лезть
В итоге файндфейс купила гэбня и теперь они будут пилить цифровой ГУЛАГ специально для вас с распознаванием лиц реалтайм.
>>1331445>Дерево хороший вариант, но его придется перестраивать каждый раз при добавлении новой фотографии. Вот же идиот. Написал ему открытым текстом ИСПОЛЬЗУЙ FAISS. Нет, опять возят сопли про то, как за o(n) изобрести велосипед.>>1331680>А почему бы не хранить не всю инфу об аккаунте а только ключ, и потом по ключу из БД уже брать инфу об аккаунте? Потому что он очень тупой.>>1331747>Т.е. всего тебе нужно 50ГБ ОЗУ для 100кк записей которые состоят из 128ми точек + ключа (айдишника профиля в БД). Скажем средний сервер будет иметь 8гб оперативы итого тебе нужно 50 / 8 = всего лишь 7 серверов. А дальше можно прикинуть, что 32-битный флоат это немного оверкилл и восьми бит будет достаточно. И получится, что все дерево влезет бытовой ПК с 16 гигами оперативки.
1) На ГПУ считать такой объем не получится, ну по крайней мере за разумное время. 11 гб в видеокарте максимум, надо будет 5-10 подходов делать, много времени займет. Хоть и написаны циферки 35 гб скорость оперативки и тд, но по факту оно не будет так быстро работать. Да когда данные в видеокарту уже попали, она рассчитывает всё моментально, но загрузить в видеокарту данные занимает время. Ладно еще 5-10 млн фоток сравнить, но если речь о 300 млн, то уйдет минимум пол минуты-минута. 2) Не знаю что там насчет FAISS, но с другими схожими плагинами у меня отказываются строиться такие большие деревья, просто вылетает, 2-3 миллиона по 128 точек ок, дальше всё, хоть и система 64 битная и оперативки хватает, да и жрет оно там по факту куда больше веса самих циферок, так что 200-300 млн фоток не влезут даже в 128 гб озу, не говоря уж о 64 и меньше3) По 10-15-20 точкам искать не вариант, если объем будет в 100кк фоток, там погрешность пиздец будет, надо будет еще дополнительное миллионов 5 записей перебирать по 128 точкам, чтобы точные совпадения найти. Получается мы нашли 5кк схожих фоток по 20 точкам, надо эти 5кк фоток еще из бд выгрузить и проверить их уже, чтобы найти 10-20 самых похожих. Хрень полная
Вот если бы придумать, как поделить 128 мерное пространство на 100-1000 или хоть сколько-нибудь областей например, то было бы норм. Если с 1д, 2д, 3д это хотя бы визуально представить можно, то что там с 128 делать хуй знает, без четкой формулы это представить всё равно невозможно
>>1346577Я запилил, но сервис не мой, у меня мощности нет чтоб весь вк обрабатывать, а так теоретически мог бы запустить, но качество поиска похуже, надо нейронку обучать по новому, не собираюсь этим заниматься, заебало уже. Тестировал на 10млн фотках, ищет моментально
>>1346679Я и так все решения опенсорсные использовал. Бот на питоне, веб на пхп, база mysql, определение лиц dlib, кнн дерево annoy
