Привет, Хабр! Меня зовут Игорь Дмитриев, я Data Business Partner в Wildberries & Russ — и по совместительству ленивый человек. Если я вижу возможность что-то автоматизировать — я это обязательно автоматизирую, потому что мне просто лень делать работу руками. В итоге всё, что только можно, я обложил автоматизациями, которые работают за меня, повышают мою эффективность и помогают улучшать результаты. Также я стараюсь внедрять автоматизацию в процессы, которые касаются моей работы. Сегодня я расскажу о своём опыте именно в автоматизации сопровождения данных.
Забегая вперед, скажу: в этой статье я покажу, на каком уровне зрелости («прожарки») описания данных можно уже подключать LLM и ИИ-агенты будут меньше галлюцинировать, какой уровень целевой и какой уровень точности между ними.
Но обо всем по порядку)
Почему сопровождение описания данных — это боль
Во-первых, это медленно. Если у вас маленькая организация и данных немного, ручной подход ещё как-то работает. Но если вы выходите на уровень крупного бизнеса с сотнями тысяч таблиц, описание данных фатально отстаёт. Доходит до смешного: новых таблиц, требующих разметки, за день создаётся больше, чем успевает физически описать весь отдел сопровождения данных. В итоге описание устаревает быстрее, чем вы успеваете его делать. На практике я сталкивался с ТЗ на подготовку аналитического отчета, в котором фигурировало более 100 различных источников. В организации не было нормального бизнес-каталога и качественных метаданных. В таких условиях даже банальная задача — корректно собрать актуальный список всех нужных таблиц — превратилась в сложный детективный квест.
Во-вторых, это чревато неверными бизнес-решениями. Ещё до работы в РВБ я столкнулся со следующим кейсом-инцидентом: один и тот же бизнес-параметр был исторически посчитан в разных витринах разными способами. В итоге высшему руководству по двум разным направлениям легли на стол отчеты, в которых бизнес-показатель за один и тот же период не совпадал. Естественно, руководитель немедленно обратил на это внимание. Чтобы не попадать в такие ситуации, необходимо качественное описание не только физических данных, но и логического слоя (глоссария). Иначе аналитики просто берут любые данные, опираясь лишь на догадки по названиям столбцов.
В-третьих, это рискованно. Когда вы выдаёте доступ к плохо размеченным или вовсе не размеченным категориями ИБ таблицам, вы можете допустить утечку. С введением оборотных штрафов за утечки персональных данных (до 3% от годовой выручки) этот риск становится критическим для любого крупного бизнеса. Но если мы не принимаем риски и закрываем доступ к данным без описания (блокируем доступ к данным), то потребитель вовсе не получает данные, и процессы останавливаются, а бизнес теряет деньги.
И отдельно то, что объединяет все эти проблемы: ручная работа плохо масштабируется. Упираешься в бизнес-экспертов, в безопасников, в само сопровождение — всюду не хватает рук. Становится очевидно, что описывать всё “вручную” — путь в никуда. Нужен системный подход. В этой статье мы рассмотрим, как ИИ (в частности LLM) помогает автоматизировать сопровождение данных. А чтобы классифицировать эту эволюцию, я использую метафору степеней прожарки стейков.
«Прожарка» данных
Уровень | Описание |
|---|---|
Rare | Данные можно безопасно распространять и можно управлять ими. |
Medium | Данные уже могут использоваться аналитиками без бесконечного «А что там лежит?» в чатах. На этом уровне можно подгружать описание в ИИ — и он начинает подсказывать, что можно сделать, работая в качестве второго пилота. |
Well-Done | Данные готовы для потребления ИИ-агентом. Высокий уровень, где вы стремитесь к тому, чтобы ИИ ходил в любую базу организации и сразу давал инсайт и запрос. Это требует отличного понимания данных со стороны бизнеса. |
Теперь о каждом уровне подробнее.
Rare
На этом уровне есть три базовых атрибута, которые должны требовать все ИБ в любой организации: владелец, физическая модель и разметка конфиденциальности. Разберем каждый атрибут: зачем он нужен и как его можно (или нельзя) автоматизировать.
Физическая модель
Зачем нужна: Это базовый технический профиль: названия таблиц, списки колонок, типы данных (int, varchar, date) и ключи связей. Без физической модели вы не сможете сформировать SQL-запрос к данным и не поймете структуру хранения базы. Стоит добавить, что для физической модели крайне важны описания: на уровне СУБД обычно доступны комментарии (поля description) для таблиц, столбцов и других сущностей. По возможности они должны быть заполнены.
Как автоматизировать: Каркас из системных таблиц всегда должен извлекаться на 100% автоматически с помощью коннекторов дата-каталогов (DataHub, OpenMetadata). Однако, если поля description пустые, исторически их приходилось восстанавливать вручную — сводить реестры в Excel, вести справочники в Wiki или Confluence.
Для автоматизации и радикального сокращения трудозатрат на этом этапе рекомендуется:
Вводить строгий Naming Convention (стандарт именования) для таблиц, столбцов и иных сущностей БД, требовать заполнение поля
description.Подключать AI-утилиты как отдельные плагины к каталогу. После базового извлечения метаданных, если описание отсутствует, алгоритм пытается восстановить его автоматически: либо расшифровывая название (опираясь на Naming Convention), либо обращаясь к корпоративным базам знаний через RAG или MCP-серверы для обогащения контекста.
Владелец (Data Owner)
Зачем нужен: Чтобы понимать, к кому идти с вопросами по качеству данных, кто согласовывает доступы и кто несет ответственность за инциденты. Без владельца данные считаются «сиротскими», и выдача доступов к ним — это нарушение политик безопасности.
Как автоматизировать: Здесь автоматизация сильно ограничена. ИИ может лишь худо-бедно предлагать кандидатов на основе контекста (например: если известен бизнес-домен, алгоритм предлагает владельца этого домена). Но ответственность нельзя назначить скриптом — на практике владельцев всегда назначают декларативно и утверждают вручную.
Разметка конфиденциальности
Зачем нужна: Это критический фильтр. Без знания, лежат ли в массиве персональные данные (ПДн) или коммерческая тайна, вам просто не дадут (и не должны давать) предоставлять доступ к данным из-за риска утечек. Вы должны точно знать, кому, что и куда вы распространяете.
Как автоматизировать: Это важнейшая точка пользы LLM на старте. Вообще, существуют два принципиально разных подхода к определению чувствительных данных:
Анализ описания (метаданных). Установление тегов классов ИБ на основании названий таблиц, столбцов и бизнес-терминов, не заглядывая внутрь.
Анализ самих данных (сигнатур). Глубокое сканирование физического содержимого таблицы в поиске специфических паттернов (цифр карт, номеров и т.д.).
Оба этих подхода должны внедряться в организации совместно, так как у каждого есть как свои плюсы, так и минусы, и способы их обойти. Вместе они позволяют обеспечить надежный уровень защиты. Однако внедрение первого подхода сильно проще с точки зрения трудозатрат, но уже сильно повышает уровень зрелости защиты данных. Поэтому в нашей реализации и в рамках данной статьи рассматривается именно первый подход — алгоритм разметки не обращается напрямую к данным, а работает по описаниям. Но читатель должен понимать: для полноценной DLP-системы этого мало, и требуется внедрение второго (сканирующего по сигнатурам) метода.
Medium
На втором уровне начинается более продвинутый слой описания метаданных — переход от технического хранения к бизнес-смыслу. Здесь у нас появляются бизнес-глоссарий и логический слой.
Логический слой — это абстракция над физической моделью. Если физическая модель отвечает на вопрос «как это хранится в базе» (например, таблица clients_v2_f, колонка c_inn), то логический слой показывает «что это значит для бизнеса» (сущность «Клиент», атрибут «ИНН»). Он скрывает техническую сложность: системные префиксы, сложные джойны, партиционирование. По сути, логический слой — это мост между «птичьим» языком баз данных и терминами, которыми оперируют бизнес-пользователи.
Этот подход к разделению физической и логической моделей базируется на фундаментальных принципах управления метаданными, заложенных в международных стандартах. Например, стандарт реестров метаданных ISO/IEC 11179 вводит строгое разделение концептуального «смысла» данных (бизнес-смысл) и их физического «представления» в системе, что является основой для любой интеграции.
Создание такого логического слоя и глоссария — огромный труд. В организациях сбор бизнес-терминов обычно лежит на дата-стюардах: ресурсов уходит много, коммуникации между доменами ещё больше, а весь контекст глоссария организации ни один человек в голове не удержит. Здесь ИИ может помогать в формировании глоссария: он видит физическую модель, знает, что уже описано, и предполагает: «Вот этот термин глоссария связан с этим полем физической модели». Это работает хорошо, если у вашей физической модели есть качественное описание.
На практике это можно автоматизировать через MCP-сервер каталога метаданных. Дата-стюард заходит в чат с агентом, который подключён к каталогу через MCP, и просит: «Дай метаданные по таблице X». Агент обращается к каталогу и возвращает физическую модель. Далее стюард просит агента проанализировать существующие бизнес-термины глоссария и соотнести их с полями: привязать существующие термины и предложить создать новые сущности для тех полей, которые ещё не покрыты. Без ИИ эта работа занимала бы часы ручного перебора — с агентом это минуты. В данном случае агент не заменяет дата-стюарда, а усиливает его, скрывая от него этапы взаимодействия с каталогом и частично анализа, но контроль при этом не пропадает.
Создание логического описания хорошо, но не понимая, как данные связаны, трудно строить инсайты — одной таблицы часто недостаточно. Сами связи можно частично вытаскивать из хранилища (первичные ключи и т. д.), но для конечного потребителя это не так интересно. На практике связи полезнее восстанавливать из реальных SQL-запросов. Из логов можно извлечь массу полезного: какие таблицы чаще всего джойнятся между собой, какие фильтры применяются, какие агрегации используют аналитики. Сам парсинг логов выполняется при помощи LLM — модель разбирает запрос, выделяет связи и паттерны использования, которые затем обогащают метаданные.
Well-Done
Самый высокий уровень — это про соответствие бизнес-смыслу. Такое описание обычно собирают руками при помощи бизнес-аналитиков, но его также можно восстанавливать в полуавтоматическом режиме — парся при помощи LLM существующие SQL-запросы, а также используя уже собранное физическое и логическое описание данных.
Здесь стоит отдельно сказать про стандарт OSI (Open Semantic Interchange) — открытую, вендор-нейтральную инициативу по определению и обмену семантическими метаданными. OSI задаёт единый формат, в котором описываются бизнес-сущности и их связи с физическими таблицами. Ключевые элементы семантического слоя по OSI:
Факты — количественные атрибуты уровня строки (суммы, количества).
Метрики — агрегированные показатели поверх фактов (
SUM,AVG,COUNT), то есть ваши KPI.Измерения — категориальные признаки для фильтрации и группировки (кто, что, где, когда).
Связи — как логические таблицы соединяются между собой.
Фильтры — часто используемые условия фильтрации.
Проверенные запросы — примеры вопросов на естественном языке с готовыми SQL-ответами.
Всё это конфигурируется через YAML-спецификацию, которая одновременно читаема и для человека, и для машины. Например, критически важная «валовая выручка», которая технически хранится в столбце x, получает бизнес-имя, описание и правило расчёта — и это определение становится единым для всех потребителей.
Эта тема сегодня сверхпопулярна в мировой Data-индустрии. На рынке закрепились мощные игроки, использующие OSI как стандарт для семантического слоя метрик — например, dbt Semantic Layer, Snowflake, Cube.dev.
Использование открытых стандартов позволяет добиться совместимости с уже существующими на рынке инструментами. Например, тот же dbt реализует управление семантикой через MetricFlow. Это значит, что инвестиции в семантический слой не привязывают вас к одному инструменту — стандартизированное описание легко портируется между различными ИИ-агентами и инструментами работы с данными, в том числе и BI.
Почему логический словарь так критичен для Text-to-SQL?
Может показаться, что для генерации SQL-запроса ИИ-агентом достаточно “скормить” в LLM всё физическое описание базы и логическое описание — и она сама во всем разберется. На практике такой подход работает, но часто не очень хорошо, особенно на опенсорсных моделях. Огромный объем сырой структуры заставляет модель галлюцинировать: она путает десятки таблиц и выбирает неверные поля. Проводились профильные исследования, доказывающие, что сокращение передаваемого описания исключительно до нужного логического контекста улучшает качество работы LLM при решении задачи text-to-sql. Но этого не достаточно, существуют на практике случаи, когда подходы text-to-sql на физическом и логическом описании данных могут решить задачу неправильно, посмотрим на примере:
-- "Сколько активных клиентов было в системе за март?"
-- LLM видит все таблицы базы и пытается "угадать" логику, например, так:
SELECT COUNT(client_id)
FROM users_db
WHERE registration_date BETWEEN '2024-03-01' AND '2024-03-31'
AND status = 'active';
Результат: Чушь с точки зрения бизнес-логики. Модель посчитала всех, у кого в столбце БД просто стоит статус “active”. При этом “активный клиент” по стандартам компании — это тот, кто сделал >= 1 заказа на сумму > 1000 руб.
Решение такого рода задач требуют либо ещё более скурпулёзного подхода к описанию логического слоя, либо описание семантического слоя. Я голосую за семантический слой просто потому, что такое разделение проще и понятнее для бизнеса. Кроме того, есть ещё и другие преимущества семантического слоя, например, он позволяет унифицировать метрики по всей компании.
Также есть исследования влияния семантического слоя на качество решения задачи text-to-sql у Snowflake В рамках своего продукта Cortex Analyst они показывают, что связка агентного ИИ с правильно описанным семантическим слоем даёт прирост точности в среднем на 20% по сравнению с запросами без семантики. Это позволяет достичь целевой планки — более 90% точности SQL в реальных use cases. Без семантического маппинга модель вынуждена угадывать бизнес-логику по названиям столбцов, и ошибки неизбежны.
Уровень well-done — это наш горизонт. Мы видим, что семантический слой по стандарту OSI — ключ к точной работе ИИ-агентов с данными, и двигаумся в этом направлении.
Что дальше?
В этой части мы разобрали теорию уровней зрелости описания данных («прожарку») и поверхностно коснулись картины автоматизации описания данных с помощью ИИ. Мы увидели, почему качественная метаинформация — это не блажь аналитиков, а фундамент для внедрения любых Text-to-SQL решений. Но уверен, что вам уже захотелось узнать детали или просто обсудить некоторые тезисы и мы готовы вас поддержать. Во второй, более технической статье, я пошагово разберу:
Подробную архитектуру агентской системы по авторазметке категорий информационной безопасности в нашем хранилище.
Метрики качества работы системы: как интересующие ИБ, так и бизнес.
Подводные камни тестирования и промпт-инжиниринга.
Также мы проводим исследования: как влияет описание данных на задачу text-to-sql и как построить систему ИИ-помощников для дата-стюардов, чтобы они показывали максимальную эффективность. Если вам интересен какой-то из этих вопросов или у вас есть собственный опыт в этих вопросах, то пишите в комментарии, обсудим. Если будет много вопросов по какому-то из них, то готовы на отдельную статью с реальными цифрами, бенчмарками и тестами.
А пока давайте встретимся в комментариях к этой статье и обсудим ваши вопросы. До встречи в следующей части!