>У кого есть предположения
Ну наверное по фичам распределяет, на этапе препроцессинга можно кучу инфы получить
А нейронки для пидоров, думаю там они их для маркетинга приплели
Типа такого что ли? В случае с лицами не будет работать. К тому же нейронка распознает лицо под углом, повернутое и тд, главное чтоб оба глаза видны были
> В случае с лицами не будет работать
Кококо, у меня древний фотик ебало находит без всяких твоих нейронок, ставлю литр пивчана, что там нихуя не нейронки
Одно дело просто лицо найти, хули там надо то, 2 глаза да рот определить. Другое дело найти похожие лица, а в идеале одного и того же человека, да еще и на разных фотках
>Одно дело просто лицо найти
Ну ебись с нейронками тогда
Другого варианта и нет. Разве что у них сама нейронка какой то хэш генерировала, ну это хз. Твой же фотик так не мог, правильно?
Чет я нихуя не понял, там разные челы и у всех совпадение 100%, лол.
Просто дети Коржа на аватарку поставили
Понятно, а что за сервис? Почему ты считаешь, что там не наебка?
Потому что это тот сайт который я и делал?
>сайт
поиск Макса Коржа?
Кого угодно
>Кого угодно
А вот вопрос, почему лиц? Какая алгоритму на хуй разница, по идее должен распознавать все что угодно, любые объекты в различных ракурсах.
Возможно супералгоритм работает не на "обычных" CPU, которые можно в любом магазине купить, а ребята ради этого заморочились и перенесли "алгоритм" на железо, т.е. на FGPA.
Ну если обучить на дорожные знаки, то будет знаки распознавать и тд
Они писали, что финд фейс на 4 серверах стоял не самых мощных. У меня есть только еще идея перенести базу на blazingDB какую нибудь, больше нет вариантов
>Ну если обучить на дорожные знаки, то будет знаки распознавать и тд
Тогда почему они не обучают? Нахождение лиц менее перспективно, чем оценивание дорожной обстановки.
>Тогда почему они не обучают? Нахождение лиц менее перспективно, чем оценивание дорожной обстановки
лол че? почти все современные машины знаки на панель приборов выводят
> почти все современные машины знаки на панель приборов выводят
давай пруфвидосик
В гугле забанили что ли блять? У мерседеса такое есть, у ауди и бмв вроде тоже, про теслу молчу
> У мерседеса такое есть, у ауди и бмв вроде тоже, про теслу молчу
У хуерса, ты рекламных роликов насмотрелся?
Ты раздел с /б не перепутал?
Подписался на интересный тред.
мимодаун, который в этом ничего не смыслит
мимодаун, который в этом ничего не смыслит
То есть пруфоф нет.
Теперь можешь пройти нахуй.
>Максимум который мне удалось добиться, это 7 секунд (!!!!) для поиска среди 1 млн фотографий.
Насколько быстро надо?
ОП, лучше скажи, как ты собрался выкачивать все эти миллионы миллиарды фото ВК для анализа? Особенно учитывая что VK API имеет пиздецовые ограничения по количеству запросов.
Я уже всю беларусь выкачал
100 млн за 1 секунду c:
Ну ладно, если не за 1, то за 7 хотя бы, в 100 раз быстрее то есть. Пока только blazingdb и mapd нагуглил, надо будет убунту второй системой ставить, пока ебаться лень с этим, через пару дней может попробую
Сколько у тебя реально получается запросов к API в секунду пока не сработает ограничение? Сколько весят фотки беларуси?
в апи всё написано. 4 запроса в секунду. но это по аццесс токену, а не по ип
>Максимум который мне удалось добиться, это 7 секунд (!!!!) для поиска среди 1 млн фотографий.
Ну и? А среди 100к фотографий? Распараллелил на сколько тебе нужно - получил те самые 0.5 секунд на ответ, или как быстро там он работал.
Пока что вопрос масштабирования. Ну и да, наверняка они ебались с оптимизацией.
1 ядро ищет в 1 млн за 7 сек. В 100 млн надо будет 100 ядер, лол. И это еще учесть что тесты были на core i7, а на серверах ставят зеоны с отключенным бустом на 2 ггц, то есть надо будет 150 ядер. А если 300 млн фоток, то говорить даже нечего
Нужен алгоритм который каким то образом будет разделять миллионы дескрипторов лиц на типы и подтипы, например по ширине глаз, соотношению размеров носа и рта и тд. А дальше бинарное дерево поиска.
Такое не сделать, я пробовал сделать некие опорные точки, например лицо со всеми координатам 0, или 10000000 и тд, всё равно чушь выдает всякую. Пробовал взять 10 разных лиц за эталон, думал что лицо определенного человека всегда будет похоже на лицо одного из эталонных, а хуй там. Вообще лица разных людей всегда в одном и том же диапазоне разницы, то есть взять 3 разных людей у них всегда будут примерно одни и те же расстояния друг от друга. По сути нейронка лишь может сказать на сколько процентов один человек похож на другого и всё, даже если жирного с тощим сравнивать, или тощего с тощим и тд
ну и да, у людей настолько ничтожная разница в расстояниях глаз, носа и тд, что по фотке это просто нереально высчитать. Разве что в студийных условиях, но у нас то фотки то с мобильника, то еще какие
Наговнякал на шарпе поиск n минимальных расстояний среди 100млн восьмиточечных записей. В однопоточном режиме на ноутбучном процессоре 2012 года работает за 4.6 секунды. Опчик, на каком тормозном говне ты кодишь?
Java
Покажи код
Ну и еще, допустим даже 13 точек я смогу в ОЗУ хранить, но по 13 точкам я найду например 10.000 похожих лиц, которых надо будет еще по 128 точкам прогнать. Тут то что делать? Мускул обосрется наверное отдавать 10к строк по 10к айдишникам
https://pastebin.com/L7aUVbW2
100 млн записей по 8 точек за 1.8 секунды на моем ноутбуке. Перепиши нормально и на быстром языке да запусти на современном железе.
я чето не понял, твой код из массива минимальное значение просто находит что ли?
Этот код считает минимальное расстояние до образца. Поиск нескольких ближайших ничего принципиально не меняет, тысяча ищется за 2.5 секунды. Полная проверка по 128 точкам нескольких тысяч выполняется за десятки микросекунд. Суть в том, что подобный код на С на современном железе с avx-512 прекрасно вписывается в требуемую производительность, если даже неоптимальный код на шарпе с кучей переаллокаций на голимом sse4 работает несколько секунд.
возможно тебе подойдет seq2seq. Это когда система сама подбирает минимальный размер хеша, который однозначно кодирует какое-то лицо. То есть не ты подбираешь features, а система делает минимально возможный набор, по которым однозначно идентифицируется сэмпл среди таких же других
Хочешь сказать что питон к примеру в 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.
У тебя есть набор точек в многомерном пространстве, нужно найти ближайшую. Полный перебор работает за 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.
Вот чувак почти придумал kd-tree. Оставшийся шаг понять, что нам не нужна ширина глаз и т. д., нам достаточно осей в нашем 128-мерном пространстве для деления на типы и подтипы.
Уменьшить количество точек автоэнкодером?
>Попробуй abs(1-1)+1 128кк раз прогнать
0.5 секунды
Дерево хороший вариант, но его придется перестраивать каждый раз при добавлении новой фотографии.
>Дерево хороший вариант, но его придется перестраивать каждый раз при добавлении новой фотографии.
Не придется, за O(log n) делается добавление в сбалансированное k-d дерево.
>0.5 секунды
Хм. Видимо потому что у тебя в озу сразу данные. А мне их с диска читать надо. Ну все равно это не выход, 128 точек и инфу об аккаунте в озу хранить очень дорого. А хранить например 14 точек, искать 40.000 ближайших аккаунтов = очень долгий запрос по выборке 128 точек у этих аккаунтов для детального подсчета. Надо будет эти деревья глянуть, где то вчера на библиотеку от спотифай натыкался
> 128 точек и инфу об аккаунте в озу хранить очень дорого
А почему бы не хранить не всю инфу об аккаунте а только ключ, и потом по ключу из БД уже брать инфу об аккаунте?
> Я могу допустить что он в 2, 3, 5 раз медленнее
Ну на голой математике без оптимизаций у меня в среднем в 60-90 раз медленнее получается
Ну так, считай в базе условно 10 млн лиц, 13 поисковых точек держим в озу. Мы при первом грубом отборе нашли например 40.000 похожих лиц, далее надо более точно найти по 128 точкам уже, это уже надо будет из базы выгружать. Сколько там времени займет выгрузка 40к лиц по айдишнику причем, а не всех подряд. Я думаю не меньше 30 сек, или минуты, не тестил
А если 200 млн лиц, или 300 даже, то при грубой выборке мы получим например 1млн похожих лиц, такое из базы уже точно не выгрузить за секунду будет
128 точек sizeof(float) + sizeof(long) = (128 4) + 8 = (520 100кк) / (1024 1024) = 49591МБ
Т.е. всего тебе нужно 50ГБ ОЗУ для 100кк записей которые состоят из 128ми точек + ключа (айдишника профиля в БД). Скажем средний сервер будет иметь 8гб оперативы итого тебе нужно 50 / 8 = всего лишь 7 серверов.
>128 точек (умножить на) sizeof(float) + sizeof(long) = (128 (умножить на) 4) + 8 = (520 (умножить на) 100кк) / (1024 (умножить на) 1024) = 49591МБ
лол. Если уж на то пошло, то можно и 1 сервер хоть со 128 гб взять. Правда стоят они пиздец
Очевидно что сервис кешировал результаты и первая выборка всегда делалась по кешу.
От того и не 7 сек.
Да ниче он там не кэшировал. Люди же всегда разных людей искали, а не только условного путина или еще кого
Видел когда то прожки для состовления фотороботов?
Ну где срез глаз подставляется, причесочка, хуе мое?
А причем тут финдфейс? Подбор размера глаз и прочее будет работать только если человек ровно в камеру смотрит и все масштабы известны. Тут другая система - какая - неизвестно, нейросеть сама какие то точки для себя определила, что они значат никто не знает. Ну если покопаться то думаю можно найти, но это всё равно что в чан с говном лезть
Эта махия.
Обратный инженегринг в помощь.
В итоге файндфейс купила гэбня и теперь они будут пилить цифровой ГУЛАГ специально для вас с распознаванием лиц реалтайм.
>1 ядро
считай на GPU, дурачок
Так на ЧС нейроночка в реалтайме всех распознавала.
>Дерево хороший вариант, но его придется перестраивать каждый раз при добавлении новой фотографии.
Вот же идиот. Написал ему открытым текстом ИСПОЛЬЗУЙ FAISS. Нет, опять возят сопли про то, как за o(n) изобрести велосипед.
>А почему бы не хранить не всю инфу об аккаунте а только ключ, и потом по ключу из БД уже брать инфу об аккаунте?
Потому что он очень тупой.
>Т.е. всего тебе нужно 50ГБ ОЗУ для 100кк записей которые состоят из 128ми точек + ключа (айдишника профиля в БД). Скажем средний сервер будет иметь 8гб оперативы итого тебе нужно 50 / 8 = всего лишь 7 серверов.
А дальше можно прикинуть, что 32-битный флоат это немного оверкилл и восьми бит будет достаточно. И получится, что все дерево влезет бытовой ПК с 16 гигами оперативки.
Файндфейс использовал алгоритм state of the art 2015, сейчас уже есть версия 2018 этого алгоритма
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 самых похожих. Хрень полная
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 делать хуй знает, без четкой формулы это представить всё равно невозможно
Тащемта разрабы ФФ сами говорили, что у них на простом монгодб всё работает
Ты уже запилил и выложил на http://searchface.ru/?
Я запилил, но сервис не мой, у меня мощности нет чтоб весь вк обрабатывать, а так теоретически мог бы запустить, но качество поиска похуже, надо нейронку обучать по новому, не собираюсь этим заниматься, заебало уже. Тестировал на 10млн фотках, ищет моментально
>
На чём писал? Предоставишь код на гитхабе?
Я и так все решения опенсорсные использовал. Бот на питоне, веб на пхп, база mysql, определение лиц dlib, кнн дерево annoy
Судя по интервью с разрабами, у них нейросеть выделяла то ли 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, но это будет только на одной и той же фотографии. Что значат эти точки - не известно, нельзя сказать что эти точки описывают глаза, а эти нос. Если например закрасить рот на одной фотке и сравнить их, то ВСЕ точки немного поменяются