Хабр, привет! Меня зовут Андрей Вихров, я создавал аналитические системы и внедрял data governance (DG) в крупных компаниях больше 15 лет, а сейчас занимаюсь метаданными в Data Office МТС. Тема порядка в данных для меня не нова, а какие выгоды можно извлечь из нее сегодня — стоит отдельного рассказа.
В компании накоплен огромный массив данных — только в дата-каталоге зарегистрировано более 500 тысяч таблиц. С ними ежедневно работают сотни специалистов: от продуктовых аналитиков до инженеров данных, строящих витрины для ML-моделей.
Но в каталоге описаны в основном таблицы — их назначение, поля, владельцы, а вот терминов и тем более их связей на порядок меньше. И это объяснимо: формировать термины сложнее, в производственный процесс они вписываются с трудом, а польза от них неочевидна.
Поэтому каталог чаще всего помогает находить описания по уже известной таблице, но не ответы на конкретные бизнес-запросы. С ними аналитику всё равно приходится разбираться самому, изучая материалы и консультируясь с коллегами, что отнимает много времени.
Логичный выход — автоматизировать процесс. Но если опытный аналитик справляется (рано или поздно) с задачей в существующих условиях, то ИИ-агент этого сделать уже не сможет, поскольку опирается только на метаданные.
В нашем случае сложились два фактора. За годы работы над DG мы накопили экспертизу в описании и структурировании метаданных. А появление LLM дало возможность создавать семантические слои на промышленной основе и использовать их для ответа на вопросы пользователей. Объединив одно с другим, мы создали и пилотируем систему Метан (метаданные + аналитика).
Метан состоит из двух компонентов:
Метан-тулкита, полуавтоматически строящего AI-ready метаданные.
Метан-чата, который на их основе основе работает как интеллектуальный интерфейс к данным: понимает вопросы, подбирает источники, генерирует SQL и объясняет свои решения.
По сути, с его помощью метаданные становятся новыми данными — активом, приносящим осязаемую выгоду. Дальше расскажу, как устроен основанный на них Метан и что уже получилось.
Архитектура — знания поверх данных
Основа концепции Метана — разделение семантического слоя описания данных на два уровня:
уровень знаний (онтология): сущности, их дата-элементы и связи. «Количество уникальных абонентов», «название приложения», «дата начала периода» — элементы с определениями, типами, синонимами, примерами значений. Мы называем их «объектами онтологии» или «терминами», далее в тексте используются оба варианта.
уровень данных (физика): таблицы и поля. Один дата-элемент может быть реализован в нескольких таблицах с разной гранулярностью и глубиной хранения.
Разделение логического и физического уровней описания данных — идея не новая. Метан развивает её, используя сильные стороны каждого уровня как при создании метаданных, так и при навигации по ним.
Механика поиска — что, где, как
Поскольку пользователь мыслит объектами онтологии, агент следует той же логике: сначала находит нужные термины, затем подбирает лучшую физическую реализацию. В метан-чате это происходит в интерактивном диалоге, состоящем из трех этапов: «Что?», «Где?», «Как?».
Рассмотрим на примере поиска данных по Kion:
1. «Что?». Агент анализирует запрос и определяет, какие объекты онтологии упоминаются. В нашем случае он находит три термина и предлагает подтвердить понимание сути запроса:
На этом этапе пользователь может задать дополнительные вопросы про предложенные термины (он же находится на уровне знаний), и на основе ответов попросить другие варианты.
2. «Где?». Зная нужные термины, агент подбирает соответствующие таблицы и ранжирует их:
Можно согласиться или попросить подробнее рассказать об альтернативах и выбрать одну из них.
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: "<ссылка на термин>" # Связь слоя данных со слоем знанийТипизация: встроили правила в структуру
Один из ключевых механизмов — типизация. Вот как она работает:
Каждый объект онтологии имеет тип, который определяет правила работы с ним как при сборке AIMeta, так и при её использовании.
Сущности делятся на Fact (события), Masterdata (объекты) и Dictionary (классификаторы), а их дата-элементы на Key, Timekey (темпоральный ключ), Title, Measure и Attribute.
Каждый тип содержит правила, которые агент применяет автоматически. Например, встретив Measure
msisdn_countагент понимает, что нужна агрегация черезSUM, а встретив Timekeyperiod_start_dtу факта — фильтрует по периоду.
Единожды описав правила работы с типом дата-элемента, мы обеспечиваем их применение во всех таблицах и разных слоях хранилища, где есть этот тип. При подключении новой предметной области достаточно описать онтологию с правильными типами, а детали можно добавить в описание отдельных элементов.
Описание: нашли компромисс между AI и каталогом
Описание следует структуре MD-шаблона, на примере термина это разделы ## Определение, ## Использование, ## Сэмплы, ## Особенности.
Такой чёткий формат LLM парсит без ошибок, причем основное описание умещается в одно текстовое поле, которое можно совместить с существующим дата-каталогом, что важно для актуализации описаний. При этом часть ключевых атрибутов (например, бизнес-правила, синонимы, тип) выносятся в отдельные поля для нативного машинного доступа.
Полуавтоматическая генерация AIMeta
Создать семантический слой вручную для сотен и тысяч таблиц нереально. Поэтому на помощь приходит полуавтоматическая генерация, которая позволяет Метан-тулкиту переработать разнородные материалы в сжатый и структурированный вид.
Готовим материалы
Для создания AIMeta мы собираем все, что содержит знания о данных: Confluence-страницы продуктов, дата-каталог, справочники значений, lineage, логи SQL-запросов и задачи аналитиков. Для разных продуктов доступны разные источники.
Отдельный этап подготовки — обработка логов запросов по скоупу таблиц. На выходе получается:
Дистиллят запросов — полезная метаинформация, извлеченная из всего массива SQL: алиасы, джойны, литералы (текстовые условия), востребованность полей.
Golden set — топ-30 популярных типов SQL-запросов и созданные на их основе запросы на естественном языке. Для создания такого сета запросы предварительно типизируются.
Из материалов создаем AIMeta
Разнородные источники пропускаются через LLM-агент, который, руководствуясь манифестом, извлекает нужные фрагменты и располагает их в целевой структуре.
Подготовка проходит в пять шагов:
Создание онтологии — LLM-агент формирует сущности, дата-элементы и связи.
Маппинг на слой данных — термины привязываются к полям таблиц, создаются недостающие термины.
Описание — генерируется базовое описание терминов и таблиц.
Обогащение — добавляются синонимы, примеры значений, правила использования. На этом шаге активно активно используется подготовленный ранее дистиллят запросов.
Проверка — прогоняется набор базовых тестов с автофиксами: на полноту, синтаксис и тому подобное.
Результат визуализируется для ревью инженером. На каждом шаге человек также может вмешиваться, но только для точечных корректировок, что принципиально проще написания всего с нуля.
Результат тестируем и тюним на основе тестов
Качество тестируется на 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-хранилище, где одни и те же дата-элементы переиспользуются в разных слоях и разных продуктах.
Мы поделили существующие решения на три основных класса, в каждом из них нашлись идеи, которые мы смогли применить у себя:
Text2SQL (Vanna.ai, DAIL-SQL) работают с DDL и few-shot примерами. На компактных схемах они показывают хорошие результаты, но на широких витринах страдают от комбинаторного взрыва, а примеры приходится поддерживать вручную. Мы взяли идею примеров, но используем их не как few-shot для модели, а как сырье для обогащения онтологии и формирования golden set тестов.
Метрические слои (MetricFlow, Cube) строятся вокруг ручного проектирования метрик и измерений поверх таблиц. Требуют хорошо структурированных данных и значительных ресурсов на поддержку. Мы взяли идею состава объектов семантического слоя и структуризации сущностей.
Онтологические платформы (Palantir Foundry, MS Fabric IQ) идеологически ближе всего — в них онтология используется как первоклассная сущность для AI-агентов. Но это экосистемы полного цикла, требующие миграции, а также предполагающие ручное моделирование. Мы взяли фокус на сущностях, но строим онтологию полуавтоматически поверх существующего хранилища.