Привет, Хабр! Меня зовут Антон, я аналитик в команде разработки продукта RT.DataGovernance (далее — DG) компании TData.
В этой статье я расскажу, как мы c командой определяли, где и как будем использовать искусственный интеллект, как тестировали обученные модели и как интегрировали их в DG.
Пару слов о нашем продукте
Каждая компания, использующая data-driven подход, нуждается в качественном и эффективном управлении данными. Практики управления данными основаны на теоретических и практических рекомендациях, разработанных профессиональной ассоциацией DAMA (Data Management Association). Зафиксированы и описаны они в известной DAMA DMBOK. Одной из ключевых областей в управлении данными является Data Governance (в честь него и назван наш продукт). Она включает:
Определение политики и процедур управления данными
Назначение ролей и ответственности за управление данными
Разработка планов управления данными
Мониторинг и контроль качества данных
Обеспечение безопасности и конфиденциальности данных
Эти аспекты мы реализовали в нашем продукте через модули Каталога данных и Бизнес-Глоссария. Обращаясь к хранилищам данных, мы сканируем метаинформацию о существующих в нем объектах. Как правило, это схемы, таблицы и представления. DG отображает их метаинформацию: размер объекта, количество строк, колонки, сэмпл данных. После запуска профилирования для данных можно отразить минимальные и максимальные значения, процент пропусков, процент уникальных значений и моду.
В DG реализованы механизмы дополнительного бизнес-описания отсканированных объектов: пользователи могут закрепить за объектом конкретную роль, задать произвольный атрибутивный состав, связать его с другими объектами в DG (например, с терминами) и проставить теги. Это позволяет агрегировать объекты не только по атрибутам, но и по тегам.
Процесс первичного документирования объектов трудоемок. Пользователям требуется задавать описание для таблиц или представлений, назначать ответственных за качество метаданных, устанавливать связи с другими объектами, проставлять теги. Все это требует ручных действий.
Именно к этому процессу мы решили применить алгоритмы искусственного интеллекта.
Пару слов об искусственном интеллекте
Под искусственным интеллектом мы понимаем систему, которая оптимизирует задачи, обычно требующие человеческого внимания.
Рост интереса к ИИ связан с тем, что его применение открывает новые возможности развития продукта. Сами алгоритмы ИИ можно разделить на две большие группы: классические модели (или «классический ML») и генеративные модели. Первая группа приносит бизнес-пользу компаниям через предсказания вероятности какого-либо события. Вторая группа направлена на снижение рутинизации рабочих активностей: алгоритмы берут на себя повторяющиеся задачи, высвобождая время специалистов и делая работу с продуктом заметно комфортнее.
Уже на этапе планирования мы стремились найти решение, которое снизит рутину и при этом не создаст избыточной нагрузки на сервера, где будет развернут наш продукт.
Искусственный интеллект в инструментах Data Governance
Конечно, мы не первые, кто решил интегрировать ИИ в инструменты Data Governance. Рассмотрим несколько примеров.
Известный open-source инструмент OpenMetadata интегрировал AI-компаньона — чат-бот "MetaPilot". Он позволяет составлять SQL-запросы на основе естественного языка.
В Датакаталоге Informatica используется Claire GPT. Это полноценный AI-помощник, который может поддержать диалог о данных на естественном языке. Он может вернуть названия объектов по описанию, построить data-lineage и предоставить оценку качества данных. Невооруженным глазом видно, сколько тысяч человекочасов было вложено в создание и интеграцию Claire GPT.
Примеры впечатляют. Но как нам доказать бизнес-эффект от внедрения AI-помощника? Нашей команде хотелось увидеть результат здесь и сейчас без использования трудоемких решений, которые потребуют фундаментальной переработки архитектуры продукта. Решение должно было быть простым, эффективным и оправдывать вложенные ресурсы.
Выбор процесса для автоматизации
Сценарий для автоматизации должен быть востребован пользователями и не перегружать сервера, на которых развернут наш продукт. Поэтому идея использовать генеративные модели для автогенерации описаний на основе их содержания отпала почти сразу: на тот момент даже "легковесные" модели оставались ресурсоемкими.
Выше я упоминал, что процесс первичного документирования объектов трудоемок. Но максимальной точки рутины он достигает, когда пользователям необходимо вручную отметить объекты, в которых содержатся персональные данные. В этом случае, пользователи должны проверить каждую таблицу вручную, посмотреть на сэмпл данных и определить, содержатся ли в них персональные данные. Если персональные данные есть, то в колонке таблицы (или представления) нужно поставить соответствующий тег. В дальнейшем данные с выбранным тегом маскируются. Это долго, сложно и рискованно — всегда есть шанс пропустить важные данные: в сэмпл просто могут не попасть данные, которые указали бы на принадлежность к ним...
Экспертная оценка ручной разметки данных показала, что двум дата-стюардам пришлось бы размечать назначенный объем данных фулл-тайм около одного года!
Поскольку обеспечение безопасности и конфиденциальности — важная часть процесса управления данными, мы решили автоматизировать именно этот ручной процесс в DG.
Разработка и тестирование первой модели
Постановки задачи было недостаточно. Требовалась ее декомпозиция для направления на разработку в отдел — центр компетенций по разработке ИИ-решений. Изначально ожидалось, что модель будет определять только 4 вида ПДн: адрес, ФИО, дату рождения и мобильный телефон.
Подготовленное MVP показало низкие метрики. Например, витрина с названиями фильмов была ошибочно отмечена как содержащая в себе ПДн с тегом ФИО, так как в выборку попал фильм с названием "Патти Кейкс".
{
"samples": [
{
"value": "Время покажет"
},
{
" value": "Девушка с татуировкой дракона"
},
{
" value": "Не в себе"
},
{
" value": "Морской тв"
},
{
" value": "Мстители"
},
{
" value": "На льду"
},
{
" value": "Девочки из Эквестрии. Радужный рок"
},
{
" value": "JimJam"
},
{
" value": "Патти Кейкс"
},
{
" value": "Капитан Немо"
}
}Выше показан пример сэмпла в формате JSON
Оценка качества модели производилась на датасете из 554 объектов. Он отражал: названия таблицы и колонки, тип данных; название тега, полученный из анализатора; примеры; score. На признаке «score» стоит остановиться подробнее. Этот признак отражает условную метрику Accuracy для загруженного списка примеров. Например, колонка, отмеченная тегом «ФИО», будет иметь «score», равный 0.2, если 20% значений примеров были помечены тегом «ФИО».
После получения датасета, мы решили его дополнить атрибутом «Флаг» (особенность этого атрибута в том, что заполняли мы его вручную). У него было всего два значения: 0 и 1. Если «score» не соответствовал действительности, то ставили «0». Для иллюстрации, если из 10 примеров, которые анализатор отметил тегом «Адрес», восемь действительно, содержали какой-то адрес и их «score» был равен 0.8, то во «Флаге» ставилась единица. Эта работа может показаться кропотливой, но именно такая «двойная» валидация модели «глазами» показала, что для разработки по-настоящему качественной модели потребуется более детальные спецификации и четкое техническое задание.
По усредненным результатам, метрика Accuracy была равна около 0.3. Это означало, что только 3 значения из 10 были верно отмечены. С таким результатом модель в бой отпускать было нельзя.
Разработка и тестирование второй модели
Второй подход позволил учесть дополнительные требования к алгоритмам. Теперь к основным 4 тегам были добавлены еще 4: номер СНИЛС, номер паспорта, номер ИНН и почтовый индекс.
Мы более тщательно подготовили и разметили данные, сосредоточились на изучении структуры типов ПДн и их нестандартных форматов. Дополнительно разработали кастомные словари. В рамках этого процесса были определены примеры очевидного наличия персональных данных (полные ФИО, email в формате user@user.com) и их скрытые формы. Например, в нескольких колонках данные были представлены как пара числового кода и префикса «#EMAIL». Это явно указывает на связь с электронной почтой.
Параллельным процессом было преодоление ряда противоречий. Например, данным с «ФИО» мог проставиться тег «Адрес» и наоборот. Организации с аббревиатурами "ООО" и "ЗАО" тоже могли отмечаться таким же тегом. Сложностью при разметке стали случаи, когда компоненты адреса (номера домов, корпусов и квартир) были распределены по разным строкам. Анализ же результатов работы первой модели позволил выявить нестандартные форматы представления ФИО, среди них: слитное написание ФИО, использование латинской раскладки, применение символа «_» в качестве разделителя между фамилией и именем.
Помимо более тщательного анализа данных с ПДн были применены дополнительные манипуляции. Для определения тега "ФИО" был добавлен дополнительный препроцессинг и создан кастомный словарь, в который попадали "необычные" имена и фамилии. Тоже самое было сделано и для тега "Адрес".
По сути перед командой стояла задача NER (Named Entity Recognition). Требовалось из текстовых данных (в нашем случае из адресов, имен и фамилий) выделить именованные сущности: имена, адреса, названия организаций, даты. А уже на основе этих сущностей, проставлять соответствующие теги.
Полученная модель была создана на основе регулярных выражений. Она решает задачу мультиклассовой классификации — то есть пока модель проставляет только один тег. Решение оценивалось метрикой F-1 (ожидается, что в дальнейшем модель будет решать уже задачу мультилейблинга (когда данные будут помечаться уже более чем одним тегом). Но для этого уже будет нужно внедрять генеративные модели, а точнее LLM). Натренированную модель обернули в docker и направили разработчикам нашей команды.
Интеграция алгоритмов искусственного интеллекта в RT.DataGovernance
Кроме модели, мы подготовили интерфейс: добавили цветовой индикатор (цвет информирует о наличии ПДн) и специальный дашборд для визуализации количества, объектов, содержащих ПДн. Также был подготовлен специальный функционал для запуска скрипта анализа проверки содержания персональных данных.
Добавление нового функционала в RT.DataGovernance будет способствовать выполнению требований информационной безопасности (далее - ИБ) в части обработки и хранения ПДн.
Первые результаты
Теперь верификация уже размеченных данных занимает не годы, а вполне осязаемые сроки в 2-3 недели. Результаты разметки сразу используются в прикладных активностях ИБ – настройке мониторингов и контроля доступа к данным объектам. Это позволило ускорить процесс демократизации данных в компании.
Заключительное слово
Внедрив доработку в продакшн, мы расширили функциональность продукта, решили прикладную бизнес-задачу и показали осязаемые результаты, оптимизировав рутинные операции и сократив воронку объектов, требующих человеческого участия.
Хочу отметить, что проект был кросс-командным. В разработке решения участвовали продуктовая команда, команда ИИ и ответственные от ИБ. Это координация нескольких направлений принесла несомненную пользу развитию нашего продукта.
Планы на будущее
Мы планируем и дальше развивать алгоритмы искусственного интеллекта. Ожидаем, что модель будет решать задачи мультилейблинга с помощью больших языковых моделей и использовать более легкие LLM-модели без GPU. В идеале, конечно, и увеличить количество определяемых тегов.
Надеюсь, было интересно. А как вы внедряли алгоритмы искусственного интеллекта в Вашу компанию?
