Понимание того, как мы измеряем производительность BAuth, нового метода аутентификации, разрабатываемого neXenio в сотрудничестве с Bundesdruckerei и Институтом Хассо Платтнера. Если вы раньше не слышали о BAuth, вы можете начать с этого обзорного поста.
Как вы уже догадались, производительность BAuth является ключевым фактором. Если он не может различать пользователей, его нельзя использовать в качестве фактора аутентификации. Нам необходимо убедиться, что наши классификаторы работают с минимально возможной временной и пространственной сложностью, сохраняя при этом частоту ошибок близкой к нулю.
Конфиденциальность
Как упоминалось в последнем посте, BAuth должен выполнять строгие требования к конфиденциальности. Мы гарантируем, что никакие личные данные никогда не покидают устройство пользователя по очевидным причинам.
Конфиденциальность как требование усложняет машинное обучение. Это называется одноклассной классификацией и означает, что мы можем использовать данные только одного пользователя для обучения, не имея возможности сравнивать с данными других пользователей. Тот факт, что у нас нет доступа к данным наших пользователей, затрудняет оценку эффективности наших классификаторов:
- Насколько хорошо они обучены?
- Насколько хорошо они могут обнаружить реального пользователя (истинные положительные результаты)?
- Насколько хорошо они могут обнаруживать мошенничество (истинный минус)?
Тестовая среда
Конечно, у нас есть модульные тесты, чтобы убедиться, что наши алгоритмы работают должным образом. Но единичные методы модульного тестирования не помогают нам проверить, как все системы работают вместе. Это потребует моделирования поведения пользователя с течением времени, чтобы увидеть, как работает BAuth. Итак, мы потратили много времени, чтобы придумать довольно интересный способ сделать это:
Запись данных датчика
BAuth собирает данные датчиков с аппаратных датчиков устройства в фоновом режиме. Эти данные используются для извлечения признаков. У нас есть разработки и предварительные версии приложения, которые позволяют нам записывать и экспортировать эти необработанные данные при соблюдении определенных условий. Таким образом, у нас есть записи от разных пользователей, которые содержат образцы их выполнения определенных действий без присмотра.
Воспроизведение данных датчика
Мы можем использовать эти записи в нашей тестовой среде. Мы обманываем систему, заставляя думать, что ранее записанные данные датчиков в настоящее время агрегируются, имитируя точно такое же поведение, которое выполнялось во время записи.
Мы переназначаем временные метки записанных данных и используем Robolectric для имитации системных часов, позволяя нам воспроизводить минуты записи всего за несколько миллисекунд.
Пересчет
Теперь, когда у нас есть некоторые данные реальных датчиков в нашей тестовой системе, мы позволяем ей работать так же, как на реальном устройстве. Объекты извлекаются, классификаторы запускаются, данные сохраняются. Все хорошее, что мы хотим видеть.
Когда пересчет завершен (когда в записи, которую мы воспроизводим в данный момент, больше нет данных датчиков), мы снова можем экспортировать все агрегированные данные в запись. На этот раз он содержит не только необработанные данные датчика, но также характеристики и классификации.
Вам может быть интересно, почему мы не записываем характеристики и классификации, пока записываем необработанные данные датчиков. Это потому, что если мы изменим одну незначительную вещь (например, функцию), вся система может выдавать совершенно разные данные (например, классификации). Мы хотим иметь возможность тестировать текущее состояние, а не состояние, которое было при первоначальной записи.
Визуализация
Теперь мы можем визуализировать состояние системы в любой момент времени. Мы используем Jupyter Notebooks и Matplotlib для создания различных диаграмм. Эти диаграммы уменьшают сложность, которая естественным образом связана с тысячами многомерных точек данных, с которыми работает система.
Чтобы получить представление о том, какие действия выполнялись, мы можем построить классификации с течением времени. В этой записи пользователь шел по нашему офису. 4 капли - это двери, которые пользователь должен был открыть, прерывая прогулку.
Мы часто проверяем, как выглядят разные функции по сравнению друг с другом. Здесь мы видим некоторые функции, основанные на необработанных данных датчика ускорения. Этот тип графика позволяет нам оценить, какие функции могут быть полезны для наших классификаторов, а какие не требуются.
Если мы загружаем несколько записей от разных пользователей, мы также можем проверить, как одни и те же функции создают разные кластеры в зависимости от пользователя. Функции, которые создают уникальные кластеры, очень важны для наших конкретных классификаций, поскольку они позволяют нам различать пользователей.
Мы также можем анимировать эти диаграммы, чтобы увидеть, как значения меняются с течением времени.
Оценка
Теперь у нас есть некоторое представление о том, что делает система и как выглядят значения. Однако нам нужны некоторые показатели, чтобы понять, действительно ли наша система улучшилась или нет. Для этого у нас есть тесты, которые вычисляют матрицу классификации.
Допустим, мы записали данные датчиков от нескольких пользователей, когда они шли. Мы воспроизводим некоторые данные от одного пользователя, чтобы обучить классификаторы, а затем запрашиваем у классификаторов данные от другого пользователя. Повторение этого снова и снова для всех возможных пользовательских комбинаций приводит к хорошей матрице.
То, что вы видите выше, - это классификации, основанные на данных некоторых членов команды. Значения, выделенные жирным шрифтом, указывают на то, что система классифицировала данные как принадлежащие одному и тому же пользователю. Вот почему все значения по диагонали выделены жирным шрифтом - они действительно положительные. Все остальные значения не должны выделяться жирным шрифтом, иначе они будут ложными.
Мы ожидаем, что система распознает пользователя, если классификаторы были обучены для этого пользователя. Мы также стараемся минимизировать количество ложных срабатываний, делая классификаторы более строгими.
Извлечение некоторых часто используемых показателей из этой матрицы, а именно оценки F1, точности, отзыва и точности, помогает нам мгновенно увидеть, как изменения кода влияют на общую производительность. Мы всегда следим за F1 Score и следим за тем, чтобы он оставался близким к 1.
Кстати, матрица, показанная выше, на самом деле является уценкой, которую выводят наши тесты при запуске. Вы можете прочитать об этом здесь:
Заключение
Очевидно, что требуется гораздо больше данных, чтобы сделать вывод о реальной производительности BAuth. Чтобы получить данные от большего количества пользователей в различных ситуациях, мы раздаем предварительные версии избранным людям. Они могут согласиться на совместное использование данных об использовании, что позволяет нам рассчитывать наши классификационные матрицы для людей, которые не работают в neXenio.
Мы уверены, что BAuth способен обеспечить уровень безопасности, позволяющий ему конкурировать с существующими методами аутентификации, будучи гораздо менее громоздким или навязчивым.
Если вам интересен этот проект, смело выходите на связь!
