Эта статья является частью заключительного проекта осеннего курса AC-215 Гарварда 2021 года
Авторы:
Кристофер Ли
Чад Стоутон
Введение
Мы все привыкли пользоваться онлайн-сервисами, особенно бесплатными онлайн-сервисами, не задумываясь о том, сколько информации о себе мы предлагаем взамен. Современные откровения о масштабах сбора данных технологическими компаниями, такими как Google и Facebook, и о том, как эти данные используются, привели к растущей обеспокоенности по поводу конфиденциальности в Интернете. Регуляторные органы начали более внимательно следить за практикой сбора данных, и такие законодательные акты, как европейский GDPR и CCPA в Калифорнии, сделали первые шаги к более эффективному надзору.
Даже в условиях растущей осведомленности об онлайн-слежке большинство пользователей не читают политики конфиденциальности, в которых указано, какой объем информации они соглашаются предоставлять о себе. И кто мог их винить? Политики конфиденциальности часто бывают длинными, замысловатыми и спрятанными в каком-то уголке веб-сайта, вдали от гораздо более интересного сервиса, для использования которого они пришли.
Наше приложение предназначено для того, чтобы вернуть пользователям некоторую власть за счет быстрого обобщения содержания политик конфиденциальности и предоставления пользователям простого интерфейса, позволяющего им точно видеть, как их отслеживают.
Краткое содержание политики конфиденциальности
Политики конфиденциальности — это длинные и сложные документы с большим количеством информации. Чтобы научить нашу машину понимать их, нам нужно разбить их на более удобоваримые фрагменты. В качестве отправной точки мы использовали набор данных APP-350, представляющий собой набор политик конфиденциальности, построчно аннотированных экспертами в области права и конфиденциальности. APP-350 содержит более 15 000 абзацев, каждый из которых снабжен 60 метриками, описывающими их значение.
Показатели APP-350 очень подробные. Например, он отмечает не только то, что политика говорит о том, что поведение пользователя в сети может отслеживаться, но и то, какие технологии используются для этого. Хотя эта точность хороша, наша цель — упростить политики конфиденциальности для пользователей. Нашим первым шагом было объединение этих 60 метрик в 6 более удобных для пользователя категорий. Для нашего производственного приложения мы сосредоточились на четырех наиболее распространенных и важных показателях:
- Идентификаторы — такие технологии, как файлы cookie и пиксели, которые позволяют службам отслеживать пользователей как на их сайте, так и за его пределами.
- Местоположение — технологии, отслеживающие физическое местоположение пользователя.
- Контакты — некоторые сервисы собирают информацию о контактах, хранящихся на устройстве пользователя.
- Обмен третьей стороной — оставляет ли за собой право служба передавать какую-либо информацию, которую она собирает о пользователях, третьим сторонам, которые могут регулироваться их собственной политикой конфиденциальности.
Как только мы определили наши целевые категории, мы могли начать обучать наши модели их распознаванию.
Был один улов; это не простая проблема классификации. Любое предложение или абзац может принадлежать к любому числу этих категорий или ни к одной из них. Предложение, в котором говорится: «Мы стремимся предоставить лучший сервис для наших пользователей», не содержит никакой информации ни об одной из наших четырех метрик. И наоборот, предложение «мы можем передавать историю вашего местоположения нашим партнерам» указывает как на то, что служба отслеживает местоположение, так и на то, что служба передает информацию третьим лицам. Из-за этого нам понадобился новый подход к классификации.
Модели
Наше решение проблемы множественной классификации заключалось в разработке ансамблевых моделей, состоящих из подмоделей, каждая из которых обучена распознавать наличие или отсутствие одной категории. Этот набор моделей бинарного отклика может эффективно классифицировать любой образец, даже если он принадлежит к нескольким категориям или ни к одной.
Для решения этой задачи мы разработали два набора моделей. Первые, которые мы будем называть «быстрыми» моделями, представляют собой набор сверточных нейронных сетей с вложениями. В быстрых моделях вводимый текст векторизуется с помощью пользовательского векторизатора, адаптированного к тексту APP-350. Вложения создаются в самой модели с использованием слоя вложений TensorFlow и передаются через оставшиеся плотные и сверточные слои модели.
Быстрые модели показали достойные результаты. Их самым большим преимуществом является то, что они чрезвычайно быстры во время вывода, что важно как для простоты использования, так и из-за ограничений вычислительных ресурсов.
Второй набор моделей, который мы назовем «тяжелыми», является более сложным. Вместо использования одного слоя вложений вложения предложений генерируются с использованием тонко настроенной модели DistilBERT. DistilBERT уже имеет очень впечатляющее понимание естественного языка. Его встраивания, обученные с помощью моделирования маскированного языка и прогнозирования следующего предложения, предоставляют множество семантических и контекстуальных значений, которые можно использовать для последующих задач (например, для оценки политик конфиденциальности). Мы дополнительно улучшили эти вложения, выполнив точную настройку MLM, используя немаркированные данные из более чем 400 000 политик конфиденциальности, которые мы собрали из Интернета. Эта настройка улучшила способность DistilBERT контекстуализировать язык, используемый конкретно в политиках конфиденциальности.
Как только эта настройка была завершена, мы подключили DistilBERT к набору головок бинарной классификации. Эти головки представляли собой CNN, очень похожие на те, что использовались в «быстрой» модели, где DistilBERT брал на себя роль слоя встраивания, обогащая входные токены контекстными знаниями, полученными из немаркированных данных. Базовые веса DistilBERT были заморожены во время обучения с учителем, что позволило головкам бинарной классификации тренироваться более эффективно с помощью обучения с переносом.
Этот набор моделей значительно повысил точность по сравнению с «быстрыми» моделями. Однако его вычислительная производительность во время логического вывода страдает, если только он не запущен на хост-машине с поддержкой графического процессора.
Оценка политики конфиденциальности
Как только мы смогли классифицировать предложения и абзацы, нашей следующей задачей было представить эту информацию пользователю в быстро усваиваемой форме. Первый, самый простой подход заключался в том, чтобы предоставить пользователям список разделов, которые дали положительный результат в каждой категории. Однако мы также хотели предоставить оценку, чтобы пользователи могли с первого взгляда воспринимать информацию. Для этого мы разработали две скоринговые метрики.
Первая оценка используется при запуске «быстрых» моделей. Это максимальное значение сигмовидного вывода активации последнего слоя модели для каждого параграфа в политике. По сути, это мера того, насколько модель уверена в том, что она нашла категорию, искать которую она была обучена. Это дает пользователю представление о том, насколько вероятно, что служба собирает информацию каждого типа.
Это вполне приемлемая метрика, но для тяжелых моделей мы хотели что-то более надежное, с более интуитивной интерпретацией.
Во время обучения тяжелых моделей мы собрали данные о частоте ошибок типа I и типа II для каждой из головок бинарной классификации в наборе данных для проверки. Затем мы использовали эти точки данных, чтобы вычислить вероятность истинно положительного теста для любого заданного результата, используя правило Байеса. Как только мы узнали вероятность того, что тип отслеживания присутствует в абзаце при условии, что он был обнаружен моделью, мы могли рассчитать вероятность ложного срабатывания. Возведя это число в степень количества положительных тестов, которые модель вернула по всей политике, мы смогли вычислить вероятность того, что ни один из них не содержит заданную категорию отслеживания. Наконец, вычитая это из 1, мы получаем итоговую оценку, которая является мерой вероятности того, что по крайней мере 1 положительный результат был действительно положительным. Это дает нам нашу окончательную метрику оценки:
В этой формуле b — это вероятность выборки, содержащей данную категорию, a — вероятность того, что модель вернет положительный результат, а n — количество положительных результатов, возвращенных моделью. Это все известные величины, измеренные во время обучения модели.
Эта оценка интерпретируется как вероятность того, что эта политика содержит хотя бы один абзац, в котором говорится, что она отслеживает такого рода информацию. Это позволяет пользователю быстро понять результаты.
Архитектура развертывания
Есть две службы, которые заставляют работать приложение Политики конфиденциальности: интерфейсная служба и служба API. Служба API состоит из модели вывода на основе BERT и конечных точек на основе FastAPI. Интерфейсная служба построена с помощью React Native. Внешний интерфейс может получить доступ к модели вывода, вызывая конечные точки API. Ниже представлена архитектура нашего проекта:
Служба API
Служба API состоит из обращенных наружу конечных точек FastAPI и модели логического вывода, которая предварительно обучена и предоставляется службе через сохраненные веса модели. Это означает, что мы можем развертывать новые модели в службе API, просто внося изменения в файлы весов, не нарушая конечные точки API. Новые архитектуры моделей могут быть развернуты путем изменения кода, создающего серверную модель, опять же без нарушения API. Конечная точка API предоставляет ответ JSON, который внешний интерфейс может понять и использовать для отображения результатов.
Передняя служба
Интерфейсная служба имеет форму, которая может принимать ввод от конечного пользователя. Форма предназначена для принятия URL-адреса политики конфиденциальности от пользователя. Как только пользователь отправляет URL-адрес, интерфейсная служба вызывает службу API в запросе POST с URL-адресом как частью тела запроса. Затем HTML-код из URL-адреса собирается и анализируется серверной частью, оставляя текстовую версию политики конфиденциальности, которую можно обработать и передать в модель. Поскольку этот вызов API является асинхронным, внешний интерфейс будет ожидать получения ответа. Чтобы пользователь знал, что вызов выполняется, мы отображаем страницу загрузки с анимированным значком в ожидании ответа API. После получения ответа внешний интерфейс анализирует данные ответа и заполняет вкладки для каждой из четырех категорий: ИДЕНТИФИКАТОРЫ, МЕСТОПОЛОЖЕНИЕ, 3RD_PARTY и КОНТАКТЫ.
Каждая вкладка отображает оценку, связанную с категорией, в виде калибровочной диаграммы слева. Справа на вкладке отображается список предложений, найденных в анализируемой политике конфиденциальности, которые попадают в категорию вкладки.
Проблемы и будущая работа
В начале разработки нашей самой большой проблемой была нехватка помеченных данных. Аннотирование политик конфиденциальности — трудоемкий и длительный процесс. APP-350 — отличный набор данных, но в конечном счете он довольно мал. Мы решили эту проблему в наших тяжелых моделях, используя множество немаркированных данных в сочетании с трансферным обучением для создания надежных прогностических моделей. Однако без размеченных данных можно сделать очень многое. В будущем мы хотели бы реализовать метод приема отзывов пользователей, указывающий, согласны ли они с выводами модели. Затем эти данные можно использовать для дальнейшего обучения модели.
На более поздних этапах разработки нашей основной задачей был доступ к адекватной инфраструктуре хостинга. Наши тяжелые модели требуют больших вычислительных мощностей, даже для логических выводов. Графический процессор делает это незначительным, и модели хорошо работают локально и в Google Collab с включенным графическим процессором. Однако облачная платформа Google, на которой размещена окончательная версия нашего приложения, не позволяет таким пользователям, как мы, с ограниченной историей использования службы получать доступ к системам с поддержкой графического процессора. Мы решили эту проблему, сериализовав наши прогнозы, запустив ансамблевую модель политик конфиденциальности по одному абзацу за раз, а не по всем абзацам параллельно. Это позволяет использовать превосходную пропускную способность ЦП, доступных в наших облачных ресурсах, и снижает потребность в параллельной обработке. Время вывода все еще больше идеального, но использование этого метода приводит его в допустимые пределы. Даже с этим улучшением тяжелые модели остаются нестабильными в нашей доступной среде Kubernetes, что иногда приводит к тайм-аутам API.
В будущих разработках мы хотели бы улучшить производительность модели и расширить наш доступ к более мощной вычислительной инфраструктуре хоста, чтобы обеспечить более быстрое использование тяжелых моделей в производственной среде. Кроме того, помеченные данные, созданные пользователями, могут обеспечить более контролируемое обучение и повысить производительность более легких архитектур моделей.
Мы с нетерпением ждем продолжения разработки приложения «Политика конфиденциальности» и надеемся, что оно позволит пользователям лучше понять, как их личные данные собираются службами, которыми они пользуются каждый день.
