LLM в инструментах Data Governance и их практическое применение

Привет, Хабр! Меня зовут Антон, я аналитик в команде разработки продукта RT.DataGovernance (далее — DG) компании TData.

В моей прошлой статье об ИИ в DG было упущением не описать контекст технологического развития, внутри которого, так или иначе, принималось решение о начале интеграции ИИ в наш продукт. Здесь я также постараюсь дать более подробный ответ, почему сначала мы выбрали решения классического ML. Ну и опишу, как мы все-таки внедрили LLM в DG в контуре нашего клиента ПАО "Ростелеком".

Повышение требований к информационной безопасности

В 2023 году усилились требования к информационной безопасности. И вот почему. Согласно отчету "Россия: утечки информации ограниченного доступа, 2022–2023 годы " от экспертно-аналитического центра (ЭАЦ) InfoWatch, объем скомпрометированной информации в России составил от 1,12 млрд до 1,58 млрд записей. Более 80% утечек случились в результате кибератак. Средняя утечка информации содержала в среднем 1,7 млн записей ПДн (персональных данных).

Компании, пострадавшие от утечек, теряли репутацию среди пользователей. Так как защита персональных данных прямая обязанность компаний, то страдать они стали и потерей рубля. За утечки ПДн в Российском законодательстве в 2023 году были предусмотрены штрафы: от 60 тыс. до 100 тыс. и 300 тыс. п��и повторном нарушении. В 2025 году наказания ужесточились. Теперь компании могут потерять от 3 млн до 15 млн рублей за первую утечку и от 1% до 3% от своего оборота (максимально 500 млн) за повторную утечку.

Один из способов защиты от утечек данных - их маскирование. Замаскированные данные обесценивают потенциальную утечку тем, что вместо настоящих значений они получают такое значение, которое невозможно не только расшифровать, но даже как-то интерпретировать. Также маскирование защищает от внутренних угроз. Сотрудники компании, работающие с данными с ПДн, имеют доступ к структуре данных, но не реальным значениям.

В DG решение о том, какие данные должны быть замаскированы, определяются не только человеком, но и алгоритмами искусственного интеллекта, обученными методами машинного обучения. ИИ в DG нам не только поспособствовал защите от утечек, но и сэкономил около двух лет работы дата-стюардов по разметке таких данных. Выбор такого технического решения был продиктован условиями. О них будет рассказано ниже.

Ретроспектива в развитии LLM

Задача маскирования персональных данных отвечала на вызов времени - повышение и достижение информационной безопасности. Эта задача отлично автоматизировалась. Но почему к ней нельзя было применить LLM? Ответ: уровень зрелости самих больших языковых моделей и инфраструктуры вокруг них.

Так как решение об автоматизации процесса принималось в 2024 году, погрузимся в технический контекст этого периода.

2023 год стал годом осмысления возможностей больших языковых моделей. Осуществлялся постепенный переход от "чатов" в сторону агентов, которые могли самостоятельно планировать задачи, использовать внешние инструменты и выполнять многошаговые рабочие процессы. Кроме этого, LLM выходили на новую аудиторию. Им стали пользоваться не только технические специалисты, но и их начальники. Возможности и потенциальную пользу их применения уже нельзя было игнорировать. Этому способствовал выход модели GPT-4.

GPT-4 стала своеобразным эталоном для индустрии. Модель, действительно, стала умнее. Ей можно было доверить задачи куда серьезнее, чем просто написать письмо на почту. По логике развития, она не могла быть долго единственным лидером. Началась гонка за качество между разными моделями больших компаний. C GPT стали соперничать коммерческие модели Gemini и Claude. Параллельно развивались и опен-соурс модели: Llama, Qwen и Mistrall. Такие решения можно было разворачивать локально и бесплатно. Единственное, требовалось, как минимум, хорошее железо.

Вместе с развитием моделей, продолжалось и их осмысление. Все больше и больше появлялось техник настройки заточки больших языковых моделей под различные бизнес-процессы (RAG, промпт-инженеринг). Стали появляться фреймворки, упрощающие работу с промптами (LangChain). Разрабатывались и улучшались векторные базы данных. Накапливались лучшие практики, накапливались и проблемы...

На мой взгляд, к проблемам использования LLM на ранних этапах можно отнести:

• Стабильность. Под ней понимается постоянная доступность. Сервисы, созданные на основе LLM должны быть доступны 99,9% времени в течение месяца. Нельзя допускать, чтобы автоматизированный процесс прервался и не был закончен из-за ошибки на стороне LLM.

• Безопасность. Нет гарантии, что отправляемые вовне чувствительные данные не будут использоваться компанией-разработчиком LLM в каких-либо целях. Сами данные, создаваемые внутри компании - ценный актив, делиться которыми может быть нарушением соглашения о неразглашении.

• Экономика. Модели обрабатывают и генерируют в ответах токены (устойчивые части слов). Чем длиннее текстовый запрос - тем больше токенов получает на вход модель. Чем точнее ответ модели - тем больше токенов модель возвращает на выход. Миллион таких токенов стоят тысячи рублей. Плохо оптимизированная unit-экономика может привести к дополнительным расходам.

• Галлюцинации. Несмотря на то, что LLM обучены на большом корпусе текстов, многого они могут не знать. Это может привести к тому, что модели могут генерировать искаженную от действительности информацию.

• Инфраструктура. Развертывание и поддержка локальной модели LLM с одной стороны решает вопрос безопасности и экономики, но с другой - разовые затраты на закупку оборудования (видеокарты, оперативная память, SSD-накопители), их поддержка в исправном состоянии и инференс (результат работы) самой модели могут превысить сам бизнес-эффект. Или, проще говоря, инфраструктура не окупится.

На момент выбора технического решения, вышеописанные проблемы не позволили выбрать такой использование LLM для маскирования ПДн. Так как отрасль активно развивается, многие проблемы сегодня удалось разрешить. В 2025 году мы интегрировали LLM в DG.

Оценка внедрения LLM и ее бизнес-ценность в RT.DataGovernance

В 2025 году мы решили интегрировать LLM в процесс описания объектов хранилищ данных. Подключаясь к ним для сканирования метаинформации объектов, DG позволяет оставить бизнес-описание к объекту. Это описание полезное, но его создание не всегда быстрое. LLM явно ускорило этот процесс. В нашем решении LLM на вход получает словарь из технических атрибутов объекта с комментарии к ним от инженеров данных (которые отсканированы из хранилища), а на выход возвращает бизнес-описание объекта.

По названию объектов и их техническим атрибуты не всегда получается определить, для чего они собраны и что описывают. Это затрудняет поиск конкретного и точного объекта. Вместо того, чтобы сразу обратиться к нужной таблице или витрине, бизнес-пользователь вынужден обращаться к помощи: либо напрямую обращаться к владельцу объекта за консультацией либо выходить за границу продукта, во внешние системы за точной схемой положения таблицы.

Потенциал внедрения LLM в процесс описания объектов сразу убивает двух зайцев: дата-стюарды тратят в разы меньше времени на описание объектов, а пользователи - в разы меньше времени на поиск нужного им объекта.

Перед интеграцией, кроме бизнес-эффекта, мы оценили внедрение по следующим критериям:

1. Ликвидация бизнес-боли. Внедрение LLM должно упрощать реальные задачи, а не быть просто модной фичей. Описание объектов - ручной процесс, а если речь будет идти о больших хранилищах с легаси объектами, то задача в целом не решаемая ручными ресурсами. Одновременно, цена ошибка минимальна. Ошибочное описание объекта может исправить человек. Внедрив LLM в процесс описания, мы снижаем рутину.

2. LLM должны ускорять, а не замедлять работу. Хранилище содержит около 140 тысяч объектов, каждый из которого в идеале необходимо описать. Автогенерация способна не только описать уже отсканированные объекты, но и те, которые будут созданы в будущем. Автоматизация процесса описания объектов явно экономит человекодни в настоящем и будущем.

3. Наличие контекста для более точных ответов модели. Ожидается, что модель при возвращении ответов, должна ориентироваться не на саму себя, а на контекст. В нашем сценарии LLM будет смотреть на названия атрибутов и комментарии к ним.

4. Большая языковая модель должна быть безопасна. LLM, которая и��пользуется в функционале - локальная. Все данные, которые она будет использовать и обрабатывать, будут находится внутри контура компании. Это гарантирует, что никакая информация с ПДн и коммерческой тайной не выйдет во всемирную сеть.

5. Модель должна иметь возможность улучшаться и соответствовать комплаенсу. Сгенерированные моделью ответы, могут быть не очень высоко оценены. У администраторов системы должна быть возможность настраивать работу модели, повышая точность ответов и корректируя ответы согласно комплаенсу.

6. Работа модели должна быть дешевле работы человека. Нельзя допускать того, чтобы генерация моделью ответов стоила больше, чем труд сотрудника над этой задачей.

Генерация описаний объектов хранилищ данных в RT.DataGovernance

Для генерации описаний к объектам мы использовали модель Qwen2.5-72B-Instruct, которая развернута внутри контура Ростелеком. Это локальная модель, поэтому нам удалось преодолеть такие ограничения как безопасность и экономика.

Каким образом мы связаны с моделью? Внутри Ростелеком развернут хороший сервис - Нейрошлюз. Это отечественный аналог OpenRouter, платформы‑агрегатора, которая предоставляет единый доступ ко многим моделям искусственного интеллекта. Сам Нейрошлюз предоставляет API к конкретным моделям.

Для того, чтобы управлять работой моделью из DG, мы создали коннектор, отдельные параметры которого можно настраивать в Административной панели.

Мы можем настраивать следующие параметры:

Т.е. кроме самого промпта, мы можем настраивать гиперпараметры модели, к которой подключились. Это позволяет повышать точность ответов, тонко настраивая работу самой модели.

Новая парадигма использования ИИ в инструментах управления данными

Если в начале использования ИИ в DG перед моделями было больше вопросов в стабильности, качестве и, в целом, полезности, то сегодня сомнений в их качестве все меньше и меньше. Модели становятся умнее и стабильнее. Уровень зрелости моделей возрос до того, что их можно использовать не столько как вспомогательный инструмент, а как полноценного участника процесса, который легко контролируется человеком.

На сегодняшний день модели ИИ находятся на высоком качественном уровне. Они стали стабильнее и надежнее. Эта тенденция развития моделей ИИ дает новый виток для развития DG. И мы в TData стараемся разрабатывать сервисы, которые будут иметь реальный прикладной эффект, который значительно выше, чем затраты на его реализацию.