В основе всех продуктов для обнаружения аномальных явлений лежит сложная сеть моделей прогнозирования. Чтобы любая из этих моделей функционировала, нам нужны глубокие и продуманные функции, тщательное моделирование подзадач и возможность объединять данные из набора баз данных.
Например, один из обнаруженных нами типов атак на электронную почту называется компрометацией деловой электронной почты (BEC). Распространенной атакой BEC является «выдача себя за VIP-персону», при которой злоумышленник выдает себя за генерального директора или другого VIP-пользователя в компании, чтобы убедить сотрудника предпринять какие-либо действия. Некоторые входные данные для модели, обнаруживающей такого рода атаки, включают:
- Модель, оценивающая, насколько похоже имя отправителя соответствует VIP (с указанием олицетворения)
- Модели НЛП, примененные к тексту сообщения
- Известные модели общения вовлеченных лиц
- Личность вовлеченных лиц, извлеченная из базы данных сотрудников
- … И многое другое
Все эти атрибуты тщательно спроектированы и могут зависеть друг от друга в направленной графической форме.
В этой статье описывается система графов атрибутов Abnormal, которая делает этот тип взаимосвязанного моделирования масштабируемым. Эта система позволила нам расширить нашу команду машинного обучения, продолжая при этом быстро внедрять инновации.
Атрибуты
Мы храним все исходные данные сущностей в виде многофункциональных благотворительных объектов (например, благотворительный объект, представляющий электронное письмо или вход в учетную запись). Это обеспечивает гибкость в отношении типов данных, которые мы регистрируем, обеспечивает простую обратную совместимость и понятные структуры данных. Но как только мы захотим преобразовать эти данные во что-то, что будет использоваться механизмами и моделями науки о данных, мы должны преобразовать их в атрибуты. Атрибут - это просто типизированный объект (float / int / string / boolean) с числовым идентификатором атрибута.
Атрибуты и функции. Атрибуты концептуально аналогичны функциям, но они могут быть не совсем готовы к использованию в модели машинного обучения. Они должны быть готовы к преобразованию в форму, пригодную для использования моделями. Вся тяжелая работа должна происходить во время извлечения атрибутов, например, при выполнении вывода модели или гидратации из базы данных.
Основные принципы, над которыми мы работаем, включают:
- Атрибуты могут полагаться на несколько режимов ввода (другие необработанные атрибуты, выходные данные моделей, данные, гидратированные из поиска в базе данных или объединения)
- Атрибуты должны быть плоскими данными (то есть примитивами) и представляться в столбчатой базе данных.
- Атрибуты должны быть легко преобразованы в функции (например, вам может потребоваться преобразовать категориальный атрибут в горячий вектор)
- Нам всегда нужно будет изменять и улучшать атрибуты с течением времени
Атрибуты потребления - после преобразования данных в столбчатый формат их можно использовать разными способами: загружать в хранилище столбцов для аналитики, отслеживать в показателях для отслеживания распределительных сдвигов и преобразовывать непосредственно в готовый фрейм данных функции. для обучения с минимальной лишней логикой.
Направленный граф атрибутов
Вычисление атрибутов в виде ориентированного графа обеспечивает огромную гибкость для параллельной разработки несколькими инженерами. Если каждый атрибут объявляет свои входные данные, мы можем гарантировать, что все запрашиваются и вычисляются в правильном порядке. Это позволяет использовать атрибуты нескольких типов:
- Необработанные особенности
- Эвристика, использующая многие другие функции в качестве входных данных
- Модели, которые делают прогнозы на основе многих других характеристик
- Вложения
График гидратации атрибутов:
Явное кодирование графа атрибутов кажется сложным, но оно избавит вас от головной боли в будущем, когда вы захотите использовать один атрибут в качестве входных данных для другого.
Управление версиями атрибутов
Мы неизбежно захотим повторить итерацию атрибутов, и худшее чувство - это осознание того, что атрибут, который вы хотите изменить, используется десятью последующими моделями. Как внести изменения без переобучения всех этих моделей? Как вы проверяете и инсценируете изменение?
Такая ситуация возникает часто. Некоторые частые случаи:
- Атрибут - это результат модели или вложения, вы хотите повторно обучить модель, но этот атрибут используется другими моделями или эвристикой.
- Атрибут полагается на базу данных, обслуживающую агрегированные функции, и мы хотели бы поэкспериментировать с различными агрегатными разбиениями.
- У нас есть тщательно разработанная эвристическая функция, и мы хотели бы обновить логику
Если для каждого атрибута используется версия и последующие потребители регистрируют, какую версию они хотят использовать, то мы можем легко увеличить версию (продолжая вычислять предыдущие версии), не затрагивая потребителей.
Масштабирование команды машинного обучения
Помимо возможности гибкого моделирования сложных проблем, этот график моделей позволяет нам масштабировать нашу команду инженеров машинного обучения. Раньше у нас был жесткий конвейер функций и моделей, который действительно мог разрабатывать только один инженер машинного обучения. Теперь у нас может быть несколько инженеров машинного обучения, которые разрабатывают модели для подзадач, а затем объединяют полученные функции и модели вместе позже.
Еще так много предстоит сделать
Нам нужно выяснить, как более эффективно повторно извлечь этот график атрибутов для исторических данных и хороших процессов для отмены старых атрибутов. Мы хотели бы создать систему, которая позволила бы нашим аналитикам безопасности и всем сотрудникам компании легко добавлять атрибуты и позволяла бы им автоматически переходить в последующие модели и анализ. Нам необходимо улучшить нашу способность отображать релевантные атрибуты и оценки моделей, важные для данного решения, обратно клиенту, чтобы понять причины, по которым событие помечено. И многое другое ... Если вас интересуют эти проблемы, то да, нанимаем!
