Привет! Меня зовут Игорь Дмитриев, я Data Business Partner в Wildberries & Russ — и, по совместительству, ленивый человек. Если вижу возможность что-то автоматизировать — обязательно это делаю. Всё, что можно, я обложил автоматизациями: они работают за меня, повышают эффективность и улучшают результаты. Также стараюсь внедрять автоматизацию в процессы, связанные с моей работой. Сегодня расскажу о своём опыте в автоматизации сопровождения данных.

Забегая вперёд

В этой статье я покажу, на каком уровне зрелости («прожарки») описания данных уже можно подключать LLM, чтобы ИИ-агенты меньше галлюцинировали. Расскажу, какой уровень описания данных целевой, и какой уровень точности между ними.

Но обо всём по порядку.

Почему сопровождение описания данных — это боль

Во-первых, это медленно. В небольших организациях с малым объёмом данных ручной подход ещё работает. Но в крупном бизнесе с сотнями тысяч таблиц описание данных фатально отстаёт. Новых таблиц создаётся больше, чем отдел успевает описать. В итоге метаданные устаревают быстрее, чем их успевают создавать. Бывали случаи, когда подготовка аналитического отчёта требовала более 100 источников. Без нормального бизнес-каталога и качественных метаданных даже простая задача — найти нужные таблицы — превращалась в детективный квест.

Во-вторых, это ведёт к неверным бизнес-решениям. Ранее я сталкивался с ситуацией, когда один и тот же бизнес-показатель рассчитывался по-разному в разных витринах. В итоге руководству поступали отчёты с разными значениями за один и тот же период. Чтобы избежать таких инцидентов, нужно качественное описание не только физических данных, но и логического слоя — глоссария. Иначе аналитики работают вслепую, полагаясь только на названия столбцов.

В-третьих, это рискованно. Доступ к плохо размеченным или вовсе не размеченным таблицам может привести к утечке данных. С введением штрафов до 3% от годовой выручки за утечку персональных данных этот риск становится критическим. Но если закрывать доступ ко всем неразмеченным данным, бизнес теряет в скорости и эффективности. Получается замкнутый круг.

Всё это сводится к одной проблеме: ручная работа не масштабируется. Не хватает экспертов, безопасников, ресурсов на сопровождение. Описывать всё вручную — путь в никуда. Нужен системный подход. В этой статье — о том, как ИИ, в частности LLM, помогает автоматизировать сопровождение данных. Для классификации уровней зрелости я использую метафору «прожарки стейка».

«Прожарка» данных: три уровня зрелости

Я выделяю три уровня зрелости описания данных — от Rare до Well-Done. Каждый уровень — шаг к более полной автоматизации и безопасному использованию данных.

Уровень 1: Rare (слабая прожарка)

На этом уровне данные только начинают описываться. Достаточно трёх базовых атрибутов, которые требует любая служба ИБ: владелец, физическая модель и разметка конфиденциальности.

Физическая модель

Зачем нужна: Это технический профиль — названия таблиц, столбцов, типы данных (int, varchar, date), ключи. Без неё невозможно сформировать SQL-запрос. Важны и описания: в СУБД обычно есть поля description для таблиц и колонок. Их стоит заполнять.

Как автоматизировать: Каркас физической модели всегда извлекается автоматически через коннекторы дата-каталогов (DataHub, OpenMetadata). Если поля description пустые, раньше их восстанавливали вручную — через Excel, Wiki, Confluence.

Чтобы сократить трудозатраты:

• Ввести строгий Naming Convention (стандарт именования) и требовать заполнение описаний.
• Подключать AI-утилиты как плагины к каталогу. Если описание отсутствует, ИИ пытается его восстановить: либо расшифровывая название (по Naming Convention), либо обращаясь к корпоративным базам знаний через RAG или MCP-серверы.

Владелец (Data Owner)

Зачем нужен: Чтобы знать, к кому обращаться по вопросам качества данных, кто согласовывает доступ и несёт ответственность за инциденты. Без владельца данные считаются «сиротскими», и выдача доступа нарушает политики безопасности.

Как автоматизировать: Автоматизация здесь ограничена. ИИ может предложить кандидата на основе контекста (например, по бизнес-домену), но назначать владельца должен человек. Ответственность нельзя делегировать скрипту.

Разметка конфиденциальности

Зачем нужна: Это критический фильтр. Без понимания, содержатся ли в таблице персональные данные или коммерческая тайна, вы не можете безопасно предоставлять доступ. Риск утечки слишком высок.

Как автоматизировать: Это одна из ключевых точек пользы LLM на старте. Есть два подхода:

• Анализ описания (метаданных): Присвоение тегов ИБ на основе названий таблиц, столбцов и бизнес-терминов — без доступа к данным.
• Анализ содержимого (сигнатур): Глубокое сканирование таблиц на паттерны (номера карт, телефонов и т.д.).

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

Уровень 2: Medium (средняя прожарка)

Здесь начинается переход от технического к бизнес-смыслу. Появляются бизнес-глоссарий и логический слой.

Логический слой — это абстракция над физической моделью. Если физическая модель отвечает на вопрос «как хранится», логический слой — на вопрос «что это значит для бизнеса». Например, таблица clients_v2_f и колонка c_inn превращаются в сущность «Клиент» и атрибут «ИНН». Это мост между языком баз данных и языком бизнеса.

Такое разделение заложено в международных стандартах, например, ISO/IEC 11179, который строго разделяет концептуальный «смысл» данных и их физическое «представление».

Создание логического слоя — трудоёмкий процесс. Обычно этим занимаются дата-стюарды. Но ИИ может помочь: он анализирует физическую модель и предлагает, какие поля соответствуют каким бизнес-терминам. Особенно эффективно, если у физических данных уже есть качественные описания.

Это можно автоматизировать через MCP-сервер дата-каталога. Дата-стюард в чате с ИИ-агентом запрашивает метаданные по таблице. Агент обращается к каталогу, анализирует глоссарий и предлагает: привязать существующие термины или создать новые. Без ИИ эта работа занимает часы, с ним — минуты. Агент не заменяет стюарда, а усиливает его, беря на себя рутину.

Однако одной таблицы часто недостаточно. Чтобы строить инсайты, нужно понимать связи между данными. Часть связей можно извлечь из первичных ключей, но более полезные паттерны — из SQL-запросов. Анализ логов запросов показывает, какие таблицы джойнятся, какие фильтры и агрегации используются.

Парсинг логов выполняется с помощью LLM: модель разбирает запросы, выделяет связи и паттерны, которые затем обогащают метаданные.

Уровень 3: Well-Done (полная прожарка)

Это уровень соответствия бизнес-смыслу. Описание собирают бизнес-аналитики, но его можно восстанавливать полуавтоматически: парсить SQL-запросы и использовать уже готовые физические и логические описания.

Здесь важен стандарт OSI (Open Semantic Interchange) — открытая, вендор-нейтральная инициатива по обмену семантическими метаданными. OSI задаёт единый формат описания бизнес-сущностей и их связи с физическими таблицами. Ключевые элементы:

• Факты — количественные атрибуты (суммы, количества).
• Метрики — агрегированные показатели (SUM, AVG, COUNT), то есть KPI.
• Измерения — категориальные признаки (кто, что, где, когда).
• Связи — как логические таблицы соединяются.
• Фильтры — часто используемые условия.
• Проверенные запросы — примеры вопросов на естественном языке с готовыми SQL-ответами.

Всё это описывается в YAML — формате, понятном и человеку, и машине. Например, «валовая выручка» получает бизнес-имя, описание и правило расчёта — и становится единым стандартом для всех.

OSI сегодня популярен в мировой Data-индустрии. Его используют dbt Semantic Layer, Snowflake, Cube.dev. Открытые стандарты обеспечивают совместимость с инструментами. Например, dbt реализует семантику через MetricFlow — значит, инвестиции в слой не привязывают вас к одному вендору. Описание легко переносится между ИИ-агентами, BI-системами и другими инструментами.

Почему логический слой критичен для Text-to-SQL

Может показаться, что ИИ-агенту достаточно физического и логического описания, чтобы генерировать SQL. На практике — нет. Большой объём сырой структуры заставляет модель галлюцинировать: она путает таблицы и выбирает неверные поля.

Исследования показывают: сокращение описания до нужного логического контекста повышает качество text-to-sql. Но и этого не всегда достаточно.

Пример: ИИ посчитал «активных клиентов» как всех, у кого в столбце стоит статус «active». На самом деле, по бизнес-логике — это те, кто сделал хотя бы один заказ на сумму свыше 1000 рублей.

Такие ошибки возникают, когда семантический слой не описан. Решение — либо более детальное описание логики, либо переход к семантическому слою. Я выбираю второе: это понятнее для бизнеса и позволяет унифицировать метрики.

Исследования Snowflake в рамках Cortex Analyst показывают: семантический слой повышает точность text-to-sql на 20% по сравнению с запросами без него. В реальных кейсах это позволяет достичь более 90% точности. Без семантики модель вынуждена угадывать логику по названиям — и ошибки неизбежны.

Итог

Уровень Well-Done — наш горизонт. Семантический слой по стандарту OSI — ключ к точной работе ИИ-агентов с данными. Мы движемся в этом направлении.

Привет, Хабр! Меня зовутИгорь Дмитриев, я Data Business Partner в Wildberries & Russ — и по совместительству ленивый человек. Если я вижу возможность что-то автоматизировать — я это обязательно автоматизирую, потому что мне просто лень делать работу руками. В итоге всё, что только можно, я обложил автоматизациями, которые работают за меня, повышают мою эффективность и помогают улучшать результаты. Также я стараюсь внедрять автоматизацию в процессы, которые касаются моей работы. Сегодня я расскажу о своём опыте именно в автоматизации сопровождения данных.

Забегая вперед, скажу: в этой статье я покажу, на каком уровне зрелости («прожарки») описания данных можно уже подключать LLM и ИИ-агенты будут меньше галлюцинировать, какой уровень целевой и какой уровень точности между ними.

Но обо всем по порядку)

Почему сопровождение описания данных — это боль

Во-первых, это медленно.Если у вас маленькая организация и данных немного, ручной подход ещё как-то работает. Но если вы выходите на уровень крупного бизнеса с сотнями тысяч таблиц, описание данных фатально отстаёт. Доходит до смешного: новых таблиц, требующих разметки, за день создаётся больше, чем успевает физически описать весь отдел сопровождения данных. В итоге описание устаревает быстрее, чем вы успеваете его делать. На практике я сталкивался с ТЗ на подготовку аналитического отчета, в котором фигурировало более 100 различных источников. В организации не было нормального бизнес-каталога и качественных метаданных. В таких условиях даже банальная задача — корректно собрать актуальный список всех нужных таблиц — превратилась в сложный детективный квест.

Во-вторых, это чревато неверными бизнес-решениями.Ещё до работы в РВБ я столкнулся со следующим кейсом-инцидентом: один и тот же бизнес-параметр был исторически посчитан в разных витринах разными способами. В итоге высшему руководству по двум разным направлениям легли на стол отчеты, в которых бизнес-показатель за один и тот же период не совпадал. Естественно, руководитель немедленно обратил на это внимание. Чтобы не попадать в такие ситуации, необходимо качественное описание не только физических данных, но и логического слоя (глоссария). Иначе аналитики просто берут любые данные, опираясь лишь на догадки по названиям столбцов.

В-третьих, это рискованно.Когда вы выдаёте доступ к плохо размеченным или вовсе не размеченным категориями ИБ таблицам, вы можете допустить утечку. С введениемоборотных штрафов за утечки персональных данных(до 3% от годовой выручки) этот риск становится критическим для любого крупного бизнеса. Но если мы не принимаем риски и закрываем доступ к данным без описания (блокируем доступ к данным), то потребитель вовсе не получает данные, и процессы останавливаются, а бизнес теряет деньги.

И отдельно то, что объединяет все эти проблемы: ручная работа плохо масштабируется. Упираешься в бизнес-экспертов, в безопасников, в само сопровождение — всюду не хватает рук. Становится очевидно, что описывать всё “вручную” — путь в никуда. Нужен системный подход. В этой статье мы рассмотрим, как ИИ (в частности LLM) помогает автоматизировать сопровождение данных. А чтобы классифицировать эту эволюцию, я использую метафору степеней прожарки стейков.

«Прожарка» данных

Данные можно безопасно распространять и можно управлять ими.

Данные уже могут использоваться аналитиками без бесконечного «А что там лежит?» в чатах. На этом уровне можно подгружать описание в ИИ — и он начинает подсказывать, что можно сделать, работая в качестве второго пилота.

Данные готовы для потребления ИИ-агентом. Высокий уровень, где вы стремитесь к тому, чтобы ИИ ходил в любую базу организации и сразу давал инсайт и запрос. Это требует отличного понимания данных со стороны бизнеса.

Теперь о каждом уровне подробнее.

На этом уровне есть три базовых атрибута, которые должны требовать все ИБ в любой организации: владелец, физическая модель и разметка конфиденциальности. Разберем каждый атрибут: зачем он нужен и как его можно (или нельзя) автоматизировать.

Физическая модель

Зачем нужна:Это базовый технический профиль: названия таблиц, списки колонок, типы данных (int, varchar, date) и ключи связей. Без физической модели вы не сможете сформировать SQL-запрос к данным и не поймете структуру хранения базы. Стоит добавить, что для физической модели крайне важны описания: на уровне СУБД обычно доступны комментарии (поляdescription) для таблиц, столбцов и других сущностей. По возможности они должны быть заполнены.

Как автоматизировать:Каркас из системных таблицвсегдадолжен извлекаться на 100% автоматически с помощью коннекторов дата-каталогов (DataHub, OpenMetadata). Однако, если поляdescriptionпустые, исторически их приходилось восстанавливать вручную — сводить реестры в Excel, вести справочники в Wiki или Confluence.

Для автоматизации и радикального сокращения трудозатрат на этом этапе рекомендуется:

1. Вводить строгийNaming Convention(стандарт именования) для таблиц, столбцов и иных сущностей БД, требовать заполнение поляdescription.
2. Подключать AI-утилиты как отдельные плагины к каталогу. После базового извлечения метаданных, если описание отсутствует, алгоритм пытается восстановить его автоматически: либо расшифровывая название (опираясь на Naming Convention), либо обращаясь к корпоративным базам знаний через RAG или MCP-серверы для обогащения контекста.

Владелец (Data Owner)

Зачем нужен:Чтобы понимать, к кому идти с вопросами по качеству данных, кто согласовывает доступы и кто несет ответственность за инциденты. Без владельца данные считаются «сиротскими», и выдача доступов к ним — это нарушение политик безопасности.

Как автоматизировать:Здесь автоматизация сильно ограничена. ИИ может лишь худо-бедно предлагать кандидатов на основе контекста (например: если известен бизнес-домен, алгоритм предлагает владельца этого домена). Но ответственность нельзя назначить скриптом — на практике владельцев всегда назначают декларативно и утверждают вручную.

Разметка конфиденциальности

Зачем нужна:Это критический фильтр. Без знания, лежат ли в массиве персональные данные (ПДн) или коммерческая тайна, вам просто не дадут (и не должны давать) предоставлять доступ к данным из-за риска утечек. Вы должны точно знать, кому, что и куда вы распространяете.

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

1. Анализ описания (метаданных). Установление тегов классов ИБ на основании названий таблиц, столбцов и бизнес-терминов, не заглядывая внутрь.
2. Анализ самих данных (сигнатур). Глубокое сканирование физического содержимого таблицы в поиске специфических паттернов (цифр карт, номеров и т.д.).

Оба этих подхода должны внедряться в организации совместно, так как у каждого есть как свои плюсы, так и минусы, и способы их обойти. Вместе они позволяют обеспечить надежный уровень защиты. Однако внедрение первого подхода сильно проще с точки зрения трудозатрат, но уже сильно повышает уровень зрелости защиты данных. Поэтому в нашей реализации и в рамках данной статьи рассматривается именно первый подход — алгоритм разметки не обращается напрямую к данным, а работает по описаниям. Но читатель должен понимать: для полноценной DLP-системы этого мало, и требуется внедрение второго (сканирующего по сигнатурам) метода.

На втором уровне начинается более продвинутый слой описания метаданных — переход от технического хранения к бизнес-смыслу. Здесь у нас появляются бизнес-глоссарий и логический слой.

Логический слой— это абстракция над физической моделью. Если физическая модель отвечает на вопрос «как это хранится в базе» (например, таблицаclients_v2_f, колонкаc_inn), то логический слой показывает «что это значит для бизнеса» (сущность «Клиент», атрибут «ИНН»). Он скрывает техническую сложность: системные префиксы, сложные джойны, партиционирование. По сути, логический слой — это мост между «птичьим» языком баз данных и терминами, которыми оперируют бизнес-пользователи.

Этот подход к разделению физической и логической моделей базируется на фундаментальных принципах управления метаданными, заложенных в международных стандартах. Например, стандарт реестров метаданныхISO/IEC 11179вводит строгое разделение концептуального «смысла» данных (бизнес-смысл) и их физического «представления» в системе, что является основой для любой интеграции.

Создание такого логического слоя и глоссария — огромный труд. В организациях сбор бизнес-терминов обычно лежит на дата-стюардах: ресурсов уходит много, коммуникации между доменами ещё больше, а весь контекст глоссария организации ни один человек в голове не удержит. Здесь ИИ может помогать в формировании глоссария: он видит физическую модель, знает, что уже описано, и предполагает: «Вот этот термин глоссария связан с этим полем физической модели». Это работает хорошо, если у вашей физической модели есть качественное описание.

На практике это можно автоматизировать черезMCP-серверкаталога метаданных. Дата-стюард заходит в чат с агентом, который подключён к каталогу через MCP, и просит: «Дай метаданные по таблице X». Агент обращается к каталогу и возвращает физическую модель. Далее стюард просит агента проанализировать существующие бизнес-термины глоссария и соотнести их с полями: привязать существующие термины и предложить создать новые сущности для тех полей, которые ещё не покрыты. Без ИИ эта работа занимала бы часы ручного перебора — с агентом это минуты. В данном случае агент не заменяет дата-стюарда, а усиливает его, скрывая от него этапы взаимодействия с каталогом и частично анализа, но контроль при этом не пропадает.

Создание логического описания хорошо, но не понимая, как данные связаны, трудно строить инсайты — одной таблицы часто недостаточно. Сами связи можно частично вытаскивать из хранилища (первичные ключи и т. д.), но для конечного потребителя это не так интересно. На практике связи полезнее восстанавливать из реальных SQL-запросов. Из логов можно извлечь массу полезного: какие таблицы чаще всего джойнятся между собой, какие фильтры применяются, какие агрегации используют аналитики. Сам парсинг логов выполняется при помощи LLM — модель разбирает запрос, выделяет связи и паттерны использования, которые затем обогащают метаданные.

Самый высокий уровень — это про соответствие бизнес-смыслу. Такое описание обычно собирают руками при помощи бизнес-аналитиков, но его также можно восстанавливать в полуавтоматическом режиме — парся при помощи 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 на физическом и логическом описании данных могут решить задачу неправильно, посмотрим на примере:

Результат:Чушь с точки зрения бизнес-логики. Модель посчитала всех, у кого в столбце БД просто стоит статус “active”. При этом “активный клиент” по стандартам компании — это тот, кто сделал >= 1 заказа на сумму > 1000 руб.

Решение такого рода задач требуют либо ещё более скурпулёзного подхода к описанию логического слоя, либо описание семантического слоя. Я голосую за семантический слой просто потому, что такое разделение проще и понятнее для бизнеса. Кроме того, есть ещё и другие преимущества семантического слоя, например, он позволяет унифицировать метрики по всей компании.

Также есть исследования влияния семантического слоя на качество решения задачи text-to-sql уSnowflakeВ рамках своего продукта Cortex Analyst они показывают, что связка агентного ИИ с правильно описанным семантическим слоем даётприрост точности в среднем на 20%по сравнению с запросами без семантики. Это позволяет достичь целевой планки — более90% точности SQLв реальных use cases. Без семантического маппинга модель вынуждена угадывать бизнес-логику по названиям столбцов, и ошибки неизбежны.

Уровень well-done — это наш горизонт. Мы видим, что семантический слой по стандарту OSI — ключ к точной работе ИИ-агентов с данными, и двигаумся в этом направлении.

Что дальше?

В этой части мы разобрали теорию уровней зрелости описания данных («прожарку») и поверхностно коснулись картины автоматизации описания данных с помощью ИИ. Мы увидели, почему качественная метаинформация — это не блажь аналитиков, а фундамент для внедрения любых Text-to-SQL решений. Но уверен, что вам уже захотелось узнать детали или просто обсудить некоторые тезисы и мы готовы вас поддержать. Во второй, более технической статье, я пошагово разберу:

1. Подробнуюархитектуру агентской системыпо авторазметке категорий информационной безопасности в нашем хранилище.
2. Метрики качества работы системы: как интересующие ИБ, так и бизнес.
3. Подводные камни тестирования и промпт-инжиниринга.

Также мы проводим исследования: как влияет описание данных на задачу text-to-sql и как построить систему ИИ-помощников для дата-стюардов, чтобы они показывали максимальную эффективность. Если вам интересен какой-то из этих вопросов или у вас есть собственный опыт в этих вопросах, то пишите в комментарии, обсудим. Если будет много вопросов по какому-то из них, то готовы на отдельную статью с реальными цифрами, бенчмарками и тестами.

А пока давайте встретимся в комментариях к этой статье и обсудим ваши вопросы. До встречи в следующей части!