Метан: как data governance и ИИ вместе создают интерфейс к данным

Хабр, привет! Меня зовут Андрей Вихров, я создавал аналитические системы и внедрял data governance (DG) в крупных компаниях больше 15 лет, а сейчас занимаюсь метаданными в Data Office МТС. Тема порядка в данных для меня не нова, а какие выгоды можно извлечь из нее сегодня — стоит отдельного рассказа.

В компании накоплен огромный массив данных — только в дата‑каталоге зарегистрировано более 500 тысяч таблиц. С ними ежедневно работают сотни специалистов: от продуктовых аналитиков до инженеров данных, строящих витрины для ML‑моделей.

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

Поэтому каталог чаще всего помогает находить описания по уже известной таблице, но не ответы на конкретные бизнес‑запросы. С ними аналитику все равно приходится разбираться самому, изучая материалы и консультируясь с коллегами, что отнимает много времени.

Логичный выход — автоматизировать процесс. Но если опытный аналитик справляется (рано или поздно) с задачей в существующих условиях, то ИИ‑агент этого сделать уже не сможет, поскольку опирается только на метаданные.

В нашем случае сложились два фактора. За годы работы над DG мы накопили экспертизу в описании и структурировании метаданных. А появление LLM дало возможность создавать семантические слои на промышленной основе и использовать их для ответа на вопросы пользователей. Объединив одно с другим, мы создали и пилотируем систему Метан (метаданные + аналитика).

Метан состоит из двух компонентов:

• Метан‑тулкита, полуавтоматически строящего AI‑ready метаданные. 

• Метан‑чата, который на их основе основе работает как интеллектуальный интерфейс к данным: понимает вопросы, подбирает источники, генерирует SQL и объясняет свои решения.

По сути, с его помощью метаданные становятся новыми данными — активом, приносящим осязаемую выгоду. Дальше расскажу, как устроен основанный на них Метан и что уже получилось.

Архитектура — знания поверх данных 

Основа концепции Метана — разделение семантического слоя описания данных на два уровня: 

• уровень знаний (онтология): сущности, их дата‑элементы и связи. «Количество уникальных абонентов», «название приложения», «дата начала периода» — элементы с определениями, типами, синонимами, примерами значений. Мы называем их «объектами онтологии» или «терминами», далее в тексте используются оба варианта.

• уровень данных (физика): таблицы и поля. Один дата‑элемент может быть реализован в нескольких таблицах с разной гранулярностью и глубиной хранения.

Разделение логического и физического уровней описания данных — идея не новая. Метан развивает её, используя сильные стороны каждого уровня как при создании метаданных, так и при навигации по ним.

Механика поиска — что, где, как

Поскольку пользователь мыслит объектами онтологии, агент следует той же логике: сначала находит нужные термины, затем подбирает лучшую физическую реализацию. В метан‑чате это происходит в интерактивном диалоге, состоящем из трех этапов: «Что?», «Где?», «Как?».

Работа Метан‑чата на основе двухуровневого семантического слоя

Рассмотрим на примере поиска данных по Kion:

1. «Что?». Агент анализирует запрос и определяет, какие объекты онтологии упоминаются. В нашем случае он находит три термина и предлагает подтвердить понимание сути запроса:

Шаг 1. Поиск терминов

На этом этапе пользователь может задать дополнительные вопросы про предложенные термины (он же находится на уровне знаний), и на основе ответов попросить другие варианты.

2. «Где?». Зная нужные термины, агент подбирает соответствующие таблицы и ранжирует их:

Шаг 2. Выбор таблиц (имена таблиц заменены)

Можно согласиться или попросить подробнее рассказать об альтернативах и выбрать одну из них.

3. «Как?». Ориентируясь на выбранную таблицу агент генерирует SQL с комментариями: какие допущения сделаны, какие фильтры добавлены и почему. 

Шаг 3. Построение SQL. Фильтрregion = 'GLOB' взят из бизнес‑правил таблицы

На каждом этапе агент объясняет свои решения, а пользователь может его направлять — скорректировать набор терминов, выбрать другую таблицу, уточнить условия. В итоге он получает не просто SQL, а управляет процессом его создания. По обратной связи мы видим что такой UX очень нравится пользователям. 

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

Как устроен семантический слой AIMeta

AIMeta (семантический слой Метана) описывает предметную область на четырех уровнях: продукт (общие правила), термины (суть данных), таблицы (гранулярность, периодичность, сочетание полей) и поля (маппинг на термины).

Структура AIMeta задается с помощью манифеста — YAML‑шаблона, который определяет иерархию объектов и правила их описания. Вот выжимка из структуры манифеста:

products:
  - product_name: "Customer App Tracker"
    product_descr: "Описание продукта, сущности, особенности данных"
 
terms:
  - term_name: "Количество уникальных абонентов"
    term_type: "Measure"        
    parent_term: "Пользовательская сессия"  # тип - "Fact"
    synonyms: [...]               
    term_rules: "Правила использования в SQL-запросах"
    term_descr: "Определение, использование, сэмплы, особенности"
 
tables:
  - table_name: "agg_application_sessions_m"
    granularity: "Время: month | Аналитика: приложение x абонент"
    table_descr: "Назначение, обновление, глубина, особенности"
    table_rules: "Правила использования в SQL-запросах"
 
fields:
  - field_name: "msisdn_count"
    term_id: "<ссылка на термин>"   # Связь слоя данных со слоем знаний

Типизация: встроили правила в структуру

Один из ключевых механизмов — типизация. Вот как она работает: 

1. Каждый объект онтологии имеет тип, который определяет правила работы с ним как при сборке AIMeta, так и при её использовании.

2. Сущности делятся на Fact (события), Masterdata (объекты) и Dictionary (классификаторы), а их дата‑элементы на Key, Timekey (темпоральный ключ), Title, Measure и Attribute.

3. Каждый тип содержит правила, которые агент применяет автоматически. Например, встретив Measure msisdn_count агент понимает, что нужна агрегация через SUM, а встретив Timekey period_start_dt у факта — фильтрует по периоду.

Единожды описав правила работы с типом дата‑элемента, мы обеспечиваем их применение во всех таблицах и разных слоях хранилища, где есть этот тип. При подключении новой предметной области достаточно описать онтологию с правильными типами, а детали можно добавить в описание отдельных элементов.

Описание: нашли компромисс между AI и каталогом

Описание следует структуре MD‑шаблона, на примере термина это разделы ## Определение, ## Использование, ## Сэмплы, ## Особенности.

Такой чёткий формат LLM парсит без ошибок, причем основное описание умещается в одно текстовое поле, которое можно совместить с существующим дата‑каталогом, что важно для актуализации описаний. При этом часть ключевых атрибутов (например, бизнес‑правила, синонимы, тип) выносятся в отдельные поля для нативного машинного доступа.

Полуавтоматическая генерация AIMeta

Создать семантический слой вручную для сотен и тысяч таблиц нереально. Поэтому на помощь приходит полуавтоматическая генерация, которая позволяет Метан‑тулкиту переработать разнородные материалы в сжатый и структурированный вид. 

Генерация семантического слоя AIMeta в Метан‑тулкит

Готовим материалы

Для создания AIMeta мы собираем все, что содержит знания о данных: Confluence‑страницы продуктов, дата‑каталог, справочники значений, lineage, логи SQL‑запросов и задачи аналитиков. Для разных продуктов доступны разные источники. 

Отдельный этап подготовки — обработка логов запросов по скоупу таблиц. На выходе получается: 

• Дистиллят запросов — полезная метаинформация, извлеченная из всего массива SQL: алиасы, джойны, литералы (текстовые условия), востребованность полей. 

• Golden set — топ-30 популярных типов SQL‑запросов и созданные на их основе запросы на естественном языке. Для создания такого сета запросы предварительно типизируются.

Из материалов создаем AIMeta

Разнородные источники пропускаются через LLM‑агент, который, руководствуясь манифестом, извлекает нужные фрагменты и располагает их в целевой структуре.

Подготовка проходит в пять шагов:

1. Создание онтологии — LLM‑агент формирует сущности, дата‑элементы и связи.

2. Маппинг на слой данных — термины привязываются к полям таблиц, создаются недостающие термины.

3. Описание — генерируется базовое описание терминов и таблиц.

4. Обогащение — добавляются синонимы, примеры значений, правила использования. На этом шаге активно активно используется подготовленный ранее дистиллят запросов.

5. Проверка — прогоняется набор базовых тестов с автофиксами: на полноту, синтаксис и тому подобное.

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

Результат тестируем и тюним на основе тестов

Качество тестируется на golden set. Агент генерирует свой SQL для каждого вопроса, после чего сравнивает результат с эталоном. Основная метрика — доля полей в сгенерированном SQL (разделы SELECT и WHERE), совпавших с эталонным запросом, аналог метрики «recall». Сейчас на пилотных областях ее уровень составляет порядка 90%.

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

Есть ли подводные камни?

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

Проблема	Решение
LM это дорого	> Разные модели для разных задач. Фронтирные модели используются для формирования онтологии и установления связей, лёгкие — для обогащения описаний и извлечения фактов, средние — для работы чата с пользователем. В результате сложилась ставка описания «один рубль за поле таблицы».
LLM галлюцинирует	> Ограничение на работу только с AIMeta и нулевая температура Сейчас большинство остающихся ошибок связано с неточным описанием, галлюцинации единичны.
LLM утонет в потоке информации	> Порционное приготовление.  Мы готовим AIMeta порциями по продуктам, а у крупных продуктов — по функциональным областям. Это позволяет помещать всю необходимую информацию в контекстное окно и иметь возможность оценить результат.
На Сonfluence много мусора	> Структурирование, лимитирование размера, механизм корректировок.  Грубые ошибки корректируются тюнингом по golden set, более тонкие — экспертной корректировкой на описаниях через UI. Достигнутая точность ответов показывает что проблема в основном решена, но здесь еще есть куда расти.
Термины привяжутся не туда	> Фокус на точность привязки в ущерб дедупликации. Стратегия работает потому что ложная привязка искажает SQL, а дубль термина — нет. Плюс дубли терминов можно постепенно мёрджить в рамках процедур дедупликации.

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

Как Метан меняет работу людей

У дата‑стюардов функционал сдвигается к контекст‑инжинирингу

Автоматизация не убирает человека из процесса подготовки метаданных, но сдвигает фокус с создания описаний с нуля к управлению тем, как понимает данные ИИ. Такую роль можно назвать «контекст‑инженер» или «инженер по семантике». 

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

Если дата‑стюард отвечает за корректность метаданных, то контекст‑инженер — за то, чтобы агент на основе этих метаданных принимал верные решения, причем количественно измеряемые на тестах.

У аналитиков появляется прозрачность процесса

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

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

• Контекст контролируется через знакомую структуру описания объектов онтологии (терминов), с возможностью точечно уточнять описания

Вместо заключения

В индустрии продолжается дискуссия: заменит ли ИИ традиционный data governance? Не станут ли ненужными каталоги и глоссарии, если модель может разобраться сама?

На нашем примере можно убедиться в обратном. LLM не заменит data governance, а сделает его работу еще полезнее. Полуавтоматическая генерация позволит создавать описания в разы быстрее, а агент будет подсказывать, где их не хватает, — через ошибки в тестах и уточняющие вопросы пользователей.

Чем точнее описания, тем лучше будет работать агент. А чем лучше работает агент, тем выше будет мотивация поддерживать эти описания. Кажется, именно этого сейчас не хватает классическому data governance.

Буду рад вопросам и обсуждению в комментариях. Особенно интересен опыт коллег, которые строят семантические слои для Text2SQL — с какими проблемами столкнулись, какие подходы сработали?

Что взяли из существующих решений

При поиске готовых решений мы не встречали вариантов с аналогичной архитектурой, но идея семантической навигации по данным развивается активно. Существующие подходы решают свои задачи, но сложно применимы к нашей реальности — сотни широких денормализованных витрин в legacy‑хранилище, где одни и те же дата‑элементы переиспользуются в разных слоях и разных продуктах.

Мы поделили существующие решения на три основных класса, в каждом из них нашлись идеи, которые мы смогли применить у себя:

1. Text2SQL (Vanna.ai, DAIL‑SQL) работают с DDL и few‑shot примерами. На компактных схемах они показывают хорошие результаты, но на широких витринах страдают от комбинаторного взрыва, а примеры приходится поддерживать вручную. Мы взяли идею примеров, но используем их не как few‑shot для модели, а как сырье для обогащения онтологии и формирования golden set тестов.

2. Метрические слои (MetricFlow, Cube) строятся вокруг ручного проектирования метрик и измерений поверх таблиц. Требуют хорошо структурированных данных и значительных ресурсов на поддержку. Мы взяли идею состава объектов семантического слоя и структуризации сущностей.

3. Онтологические платформы (Palantir Foundry, MS Fabric IQ) идеологически ближе всего — в них онтология используется как первоклассная сущность для AI‑агентов. Но это экосистемы полного цикла, требующие миграции, а также предполагающие ручное моделирование. Мы взяли фокус на сущностях, но строим онтологию полуавтоматически поверх существующего хранилища.