AI, который не просит хлеба

Статья о том, как мы шаг за шагом строили наш AI. Время чтения 10+ минут.



Введение. Стартап в области компьютерного зрения, используемый low-cost разработку в качестве базовой концепции. Команда вполне соответствует духу: 3 — 5 студентов разработчиков разного уровня и направления, в зависимости от дня недели и времени суток (от 0.25 до 1.25 ставки). Мой опыт игры в пятнашки здесь очень пригодился.

Коротко о продукте (пк + софт) — интеллектуальная система видео наблюдения, подключаемая к локальной сети и производящая обработку видео своими силами. Два обязательных условия: наличие интерфейса пользователя с различными правами и максимальная автономность алгоритмов.

С технической стороны ограничений на железо не было, главное — чтоб работало хорошо; а вот с финансовой были. На все про все ~500$. Разумеется только новые и современные комплектующие. Выбор их не велик, но есть!

С железом определились, далее софт. Выбор пал на микросервисную архитектуру с использованием докера по некоторым, достаточно весомым причинам.

Разработка фичей шла от простых и необходимых (работа с потоками и видео файлами) к сложным, с периодическим review. Собрали MVP, несколько спринтов оптимизации заметно приблизили нас к заветной цели — выполнять все 4 пункта одновременно, а не по отдельности:

  1. 16+ ip-камер (FHD/25fps) трансляция, воспроизведение по событию или времени и запись
  2. Параллельная работа всех имеющихся CV алгоритмов
  3. Пользователь интенсивно пользуется интерфейсом без задержек — смотрит стримы
  4. Загрузка ЦП менее 90% и все работает (!)

Немного о стеке, выбор пал на: С/С+, Python + TensorFlow, PHP, NodeJS, TypeScript, VueJS, PostgreSQL + Socket.io и прочие мелочи.

Реализованные фичи были сознательно скрыты, чтоб подробнее остановится, пожалуй, на самой интересной и восхитительной фичи из области CV и в некоторой степени — ML.

«Уникальные User»


Пример использования — собирать историю визитов каждого конкретного посетителя, причем сотрудников учитывать отдельно, даже если мы не знаем что это сотрудник (Пример — ТРЦ).
И казалось бы, вроде как эта задача решена 100500+ раз и телефоны и все что угодно уже умеет распознавать лица и запоминать их, отправлять куда то, сохранять. Но 95% решений используются в СКУД, где сам пользователь стараясь быть распознанным, стоит перед камерой 5Мп на расстоянии 30-50см в течении нескольких секунд, пока его лицо не сверится с одним или несколькими лицами из БД.

В нашем случае такие условия были роскошью. Пользователи двигались хаотично, смотря в свой смартфон на достаточном расстоянии от камеры, установленной на потолке. Дополнительно, сложности вносили сами камеры, чаще всего — это бюджетные камеры с 1.3-2Мп и какой то непонятной цветопередачей, всегда разной.

Частично, эта проблема решилась формированием ТЗ на условия установки камер, но в целом система должна была уметь распознавать и в таких условиях (естественно — хуже).

Подход к решению: задача была декомпозированна на 2 задачи + структура БД.

Краткосрочная память


Отдельный сервис, где в основном протекает real-time процесс, на входе кадр с камеры (на самом деле другого сервиса), на выходе — http запрос с нормированным 512-и мерным Х-вектором (face-id) и некоторыми мета-данными, например time stamp.
Внутри нее множество интересных решений в области логики и оптимизации, но на этом всё; пока что всё…

Долгосрочная память


Отдельный сервис, где требования к real-time не стоит остро, но в некоторых случая это важно (например — человек из стоп листа). В целом ограничились 3 секундами на обработку.
На входе в сервис — http от краткосрочной памяти с 512-и мерным вектором внутри; на выходе — Id посетителя.

Первые мысли очевидны, решение задачи достаточно просто: получил http → сходил в БД, взял, что есть → сравнил с начинкой http, если есть такой, то он и есть; если нет, то новый.
Плюсов такого решения не счесть, а минус только один — оно не работает.

Задачу решили, хоть и пошли путем самурая, пробуя различные подходы, периодически посматривая просторы интернета. В общем решение оказалось в меру лаконичным. Концепция достаточно проста и основывается на кластеризации:

  1. Каждый вектор (а-вектор) будет принадлежать какому либо User; каждый кластер (не более М векторов, из коробки M =30) принадлежит какому либо User. Принадлежит ли а-вектор кластеру А — не факт. Вектора в кластере определяют взаимодействие кластера, вектора в User определяют только историю User.
  2. Каждый кластер будет иметь центроид (по сути — А-вектор) и собственный радиус (далее — range) взаимодействия с другими векторами или кластерами.
  3. Центроид и range будут функцией кластера, а не статикой.
  4. Близость векторов определяется квадратом евклидова расстояния (в особых случаях — иначе). Хотя здесь есть еще несколько других достойных методов, но мы просто остановились на этом.

Примечание: т.к. мы использовали нормированные вектора, то расстояние между ними было гарантированно от 0 до 2. Далее о алгоритме реализации концепции.

#1 Круг подозреваемых. Центроид, как хэш-функция


Х-вектор, полученный от краткосрочной памяти сравнивается с имеющимися в БД центроидами кластеров (А-вектор) на предмет близости, далекие, где range[X,A] > 1 — отбрасывались. Если никого не оставалось — создается новый кластер.

Далее ищется минимум между Х-вектором и всеми оставшимися а-векторами (min_range[X,a])

#2 Уникальные свойства кластера. Саморегулируемая сущность


Вычисляется собственный range_A кластера, чей вектор самый близкий к Х-вектору. Здесь используется обратная линейная функция от количества векторов (N), уже находящихся в этом кластере (const*(1 — N/2M)); из коробки const =0,67).

#3 Валидация и непонимание. Если ни кто — то кто !?


Если range_А > min_range[X,a], то Х-вектор помечается как принадлежащий к А-кластеру. Если нет — то… Ох… Это чем то похоже на описание математической модели недопонимания.
Определились с тем, что в этом случае будем создавать новый кластер, тем самым сознательно шли на ошибку 1-го рода «Пропуск цели».

#4 Дообучение. Как циферки формируют признаки


Субъективный опыт — это когда данные становятся инструментом. Ранее мы распознали, но возможно с ошибкой. Стоит ли доверять Х-вектору, чтоб использовать его в следующем матчинге !? Проверяем! Х-вектор должен:

  • быть достаточно близок к центроиду А (range_А > range[X, А])
  • быть полезным и разнообразным, ведь с одной стороны мы минимизируем риск ошибки, с другой — копии нам тоже не нужны (Config_Max[0,35] > range[X,a] > Config_Max[0,125]). Тем самым, конфиги определяют скорость и правильность «обучения».

Выполняя эти условия, Х-вектор попадает в состав кластера А ( до этого он просто принадлежал User). Если векторов в кластере становится больше допустимого, то убираем самый центральный (min_range[А,a]) — он вносит меньше всего разнообразия и является лишь функцией остальных; к тому же центроид и так участвует в матчинге.

#5 Работа над ошибками. Превращаем недостатки в достоинства


В каждом сложном выборе мы делали шаг в сторону ошибки «Пропуск цели» — создавали новый кластер и User. Пришло время пересмотреть их… все. После #4 мы имеем модифицированный кластер А. Далее мы пересчитываем его центроид (А-вектор) и ищем минимальное расстояние ко всем имеющимися центроидам в нашем 512-ти мерном пространстве. В этом случае расстояние считается более сложно, но это сейчас не так важно. Когда расстояние min_range[A,B] будет меньше, чем некоторая величина (из коробки range_unity=0,25) мы объединяем два множества, считаем новый центроид и избавляемся от менее «полезных» векторов, если их слишком много.
Другими словами: если существует 2+ кластера, в действительности, принадлежащих одному User, то они, спустя некоторую серию детекций, станут близки и объединяться в один вместе со своими историями.

#6 Комбинаторика признаков. Когда машина… думает !?


Здесь стоит определить новый термин в этой статье. Фантомный вектор — вектор, который был получен не в результате деятельности краткосрочной памяти, а в результате функции над N-шт векторов кластера (a1,a2,a3,a4…). Разумеется, полученные таким образом вектора хранятся и учитываются отдельно и не представляют из себя ни какой ценности до тех пор, пока в результате матчинга не будут определены, как ближайшие (см #3). Основная польза фантомных векторов — ускорение обучения кластера на его ранних этапах.

Система уже запущена в продакшен. Результат был получен на реальных данные вне тестовой среды на 5000+ User; так же там была замечена пачка «слабых» мест, которые были усилены и учтены в этом тексте.

Интересно то, что такой подход ни имеет пользовательских настроек и вся работа ни как не управляется, все абсолютно автономно. Дополнительно, анализ временных рядов позволяет классифицировать User на различные, свои категории аналогичным методом, тем самым строить ассоциаций. Именно так и решился вопрос — кто есть сотрудники, а кто — посетители.

Роль пользователя системы проста — нужно периодически проверять почту или интерфейс системы на наличие новых отчетов о работе.

Результат


Величина близости при распознании, основанном на долгосрочной памяти ~0,12-0,25 у умеренно обученного кластера (содержит 6-15 а-векторов). Далее обучение замедляется по причине повышения вероятности «копий векторов», но в долгосрочной перспективе близость стремится к величинам ~0,04-0,12, когда кластер содержит уже 20+ а-векторов. Замечу, что внутри краткосрочной памяти, от кадра к кадру, этот же параметр имеет значение ~0,5-1,2, что звучит примерно как: «Человек больше похож* на себя в очках 2 года назад, чем 100мс назад». Такие возможности открывает использование кластеризации в долгосрочной памяти.

Загадка


В результате одного из тестов получилось интересное наблюдение.

Начальные условия:

  • На двух абсолютно одинаковых ПК развернута абсолютно одинаковая система видео наблюдения с абсолютно одинаковыми настройками. Они подключены к одной единственной ip-камере, расположенной грамотно, согласно ТЗ.

Действие:

  • Системы запускают в одно и то же время и оставляют на неделю в покое со всеми работающими алгоритмами. Трафик соответствует нормальному трафику без изменений.

Результат:

  • Количество созданных User, кластеров и а-векторов одинаково, а центроиды разные, не значительно — но разные. Вопрос — почему? Кто знает — пишите в комментариях или сюда)

Жаль, что о многом я не могу написать здесь, но возможно, кое-что я смогу описать так же подробно в другой статье. Возможно, все это уже описано в какой-то замечательной методичке, но к моему сожалению, я такую так и не нашел.

В заключении скажу, что наблюдать изнутри, как автономная AI система классифицирует окружающее себя пространство, реализуя по пути различные заложенные в нее фичи — очень интересно. Люди много чего не замечают в силу наличия накопленного опыта восприятия (шаг #4).


Очень надеюсь, что эта статья будет полезна кому либо в его проекте.
Ads
AdBlock has stolen the banner, but banners are not teeth — they will be back

More

Comments 3

    0
    Самая простая история, почему центроиды могут различаться — не зафиксирована случайность инициализации.
      0
      Вопрос — почему? Кто знает — пишите в комментариях

      Если я правильно понял вы подключаетесь напрямую к ip камере («Они подключены к одной единственной ip-камере»). У вас не являются идентичными кадры которые попадаю на вход обоих алгоритмов. Может меняться компрессия потока, может где-то пропуск кадра случаться, и.т.д. Резные кадры => чуть отличающиеся хэши.

      Чтобы убедиться что проблема не в этом — запишите несколько суток видео и прогоните на обоих ваших комплексах.
      Но, конечно, может и в других местах проблема возникать. Например вы используете разные видюхи для запуска (TensorRT под разные видеокарты имеет несколько разные алгоритмы оптимизаций, могут какие-то знаки после запятой изменяться).

    Only users with full accounts can post comments. Log in, please.