Еще недавно ИИ в работе с данными использовали как вспомогательный инструмент. Нейросеть помогала написать запрос, найти информацию или подготовить отдельный документ. Теперь ей можно передать целый набор повторяющихся задач и подключить к корпоративным системам, каталогам и инструментам разработки. Часть работы выполняет агент, а специалист определяет правила, проверяет результат и принимает верхнеуровневые решения.
Как меняется работа с корпоративными данными под влиянием ИИ, рассказали эксперты на седьмом митапе MWS.
MWS Meetup — это регулярные технические встречи для разработчиков и инженеров в онлайн- и офлайн-формате. Участники разбирают прикладные задачи из разработки, инфраструктуры и облачных технологий. Итоги предыдущего митапа о Go-разработке можно почитать в предыдущем материале.
В этом посте:
Что такое Data Governance 2.0
Как агент берет на себя рутину аналитика
Почему работающий код не гарантирует удачное решение
Как описать данные, чтобы нейросеть поняла их смысл
Во что упирается следующий уровень автоматизации
Переход к управляемой автоматизации
Что такое Data Governance 2.0
Классическое управление данными строится вокруг набора инструментов. Компания описывает данные, назначает владельцев, следит за качеством, каталогизирует источники и контролирует доступ. Когда в процессы добавляются ИИ-агенты, этого становится недостаточно. Нужно управлять не только самими данными, но и моделями, промптами, цепочками вызовов, а также их полномочиями, стоимостью и качеством ответов.
Эти объекты требуют собственных правил и механизмов контроля. Традиционный Data Governance остается фундаментом, но поверх него возникает дополнительный уровень управления.
В MWS, например, этот подход рассматривают как Data Governance 2.0. Он включает классическое управление данными, Model Governance, управление рисками ИИ и управление стоимостью. Последний компонент становится особенно важным по мере роста числа ИИ-кейсов. Компании нужно понимать не только, работает ли конкретный сценарий, но и сколько ресурсов он потребляет, какие компоненты формируют стоимость и насколько оправдано его использование.
Для этого сам ИИ-кейс должен быть описан формально. В манифесте фиксируются источники данных, владельцы, разрешенные и запрещенные действия агента, условия остановки, место человека в контуре и метрики качества.
Такой подход позволяет заранее определить границы автономности системы. Например, агент может искать информацию в каталоге и объяснять термины, но не должен самостоятельно выдавать права доступа или изменять исходные данные.
Отдельная задача заключается в проверке качества. Нужно оценивать промежуточные этапы работы системы, включая качество разбиения данных, поиск релевантных фрагментов и подтверждение ответа источниками.
В MWS для этого используют несколько показателей:
hit rate — показывает, удалось ли найти релевантный документ,
precision — оценивает релевантность найденных данных,
citation rate — показывает наличие корректной ссылки на источник.
Такой подход позволяет понять, на каком этапе возникает проблема — например, модель неправильно сформулировала ответ или система не нашла нужные данные. Поэтому оценивать ИИ приходится не только по итоговому ответу. В корпоративной системе важно видеть, какие данные использовал агент, как он пришел к результату и можно ли проверить его действия.
Такой подход позволяет отделить ошибку самой модели от проблемы в данных или поисковом контуре.
Как агент берет на себя рутину аналитика
Второй вопрос касается изменения повседневной работы специалистов по данным. Значительная часть времени аналитика уходит на задачи, которые не требуют непосредственно аналитического мышления.
До внедрения агентов около 30% времени занимали документация и DDL-скрипты, еще 25% приходилось на поиск информации и согласования. На собственно анализ и проектирование оставалось около четверти рабочего времени.
Поэтому в аналитике хорошо работают специализированные агенты. В MWS, например, каждый такой сценарий оформляют как скилл — набор инструкций, который задает агенту порядок действий для конкретной задачи.
Он содержит описание роли, алгоритм действий, требования к входным и выходным данным, примеры и шаблоны. Через MCP-сервер похожий сценарий можно подключить к корпоративным системам, включая Jira, Confluence и GitLab.
Это позволяет автоматизировать хорошо формализованные процессы. Например, один из скиллов MWS берет задачу из Jira и на ее основе автоматически готовит бизнес-требования по принятому в компании шаблону. Другой формирует физическую модель данных, DDL-скрипты, правила загрузки и сопутствующие спецификации.
При этом меняется не только скорость работы. Раньше аналитик начинал работу с пустого документа и последовательно собирал требования, искал шаблоны, писал скрипты и согласовывал результат. Теперь значительную часть этой работы выполняет агент, а специалист проверяет получившийся результат и исправляет ошибки.
«Создание бизнес-требований раньше занимало не меньше 8 часов, тогда как с использованием скилла процесс удалось сократить до получаса. Но в любом случае человек остается ответственным за проверку результата».
Дмитрий Гаврилов, руководитель Центра компетенций аналитики MWS
По мнению эксперта, автоматизировать имеет смысл повторяемые и структурированные задачи, для которых известны входные и выходные данные, существуют правила и есть возможность проверить результат. Переговоры с заказчиком, интерпретация неоднозначных требований, архитектурные решения и приоритизация задач по-прежнему требуют участия специалиста.
В результате агент смещает работу специалиста с подготовки типовых артефактов к проверке, проектированию и принятию решений.
Почему работающий код не гарантирует удачное решение
В дата-инжиниринге ИИ уже давно используется для генерации программного кода, но сам факт успешного выполнения программы еще не говорит о качестве решения.
Алексей Николаев, руководитель Центра компетенции дата-инжиниринга MWS, в своем докладе привел пример использования агентов в работе команды. За полдня инженеры с помощью ИИ создали программу для автоматического разбора записей о работе Spark. Она выполняла поставленную задачу, но оказалась слишком медленной: обработка одного дня записей занимала около 30 часов. Инженер переделал решение оптимизировав работу приложения до 20 минут, показав, что быстро сгенерированный код еще не означает эффективное решение.
Для дата-инжиниринга это принципиальный момент. Агент может написать код, который корректно выполняется, но не учитывать нагрузку на инфраструктуру, объем данных и другие ограничения реальной системы. Поэтому результат его работы приходится проверять не только на ошибки, но и на производительность.
Поэтому в MWS эффективность агентов связывают с метриками Data Governance. Команда собирает данные об использовании ресурсов, отслеживает путь данных (Lineage) между системами и контролирует загрузку хранилищ. Одним из примеров стала автоматизация работы с OpenLineage. По словам Алексея, раньше OpenLineage использовали примерно в 10% проектов. Хотя командам было понятно, зачем нужен инструмент для отслеживания пути данных между системами, его внедрение оставалось рутинной задачей. Теперь часть этой работы автоматизирует специальный агент-интегратор.
«Мы не говорим инженерам, как делать и что делать. Мы показываем неоптимальные точки и даем инструменты для решения задач».
Алексей Николаев, руководитель Центра компетенции дата-инжиниринга MWS
Следующий шаг в этом направлении — Spark-оптимайзер. Он будет брать код и лог выполнения, сопоставлять их и предлагать изменения. Пока что специалисты сами смотрят на показатели в системе мониторинга и выбирают задачи, которые требуют оптимизации, но в перспективе агент должен самостоятельно реагировать на аномальные показатели и предлагать изменения в виде pull request.
Агент может искать проблемы и предлагать решения, но при окончательной оценке важно учитывать реальное поведение системы, иначе автоматизация ускоряет создание неэффективного кода.
Как описать данные, чтобы нейросеть поняла их смысл
Отдельный доклад Андрея Вихрова, руководителя направления в Группе развития методологии работы с данными MWS, был посвящен метаслою AI-ready и генерации SQL по запросу на естественном языке.
Text2SQL кажется простой задачей, пока нейросети не приходится работать с корпоративным хранилищем, в котором тысячи таблиц и множество похожих объектов. Обычный few-shot-подход, когда модели передают примеры запросов, плохо масштабируется. Проблема заключается в том, что нейросети нужно не просто показать синтаксис SQL, а дать понимание того, что именно означает каждая сущность в конкретной компании.
«Как найти нужные данные, если не знаешь, где искать. У нас есть таблицы dwh.fct_subs_activity_v1, v2, final, backup, new... И как понять, какая из них актуальна?»
Андрей Вихров, руководитель направления в Группе развития методологии работы с данными MWS
Андрей предложил решать эту задачу через онтологию — запись знаний с помощью понятий и связей. В таком подходе данные разделяются на два уровня:
первый описывает смысл и бизнес-сущности,
второй связывает их с физической реализацией в таблицах и полях.
Это важно из-за особенностей корпоративных хранилищ. Один и тот же показатель может существовать сразу в нескольких таблицах, отличаться по гранулярности,степени детализации или дробности объекта, или обновляться с разной периодичностью. Поэтому вопрос пользователя сначала сопоставляется с терминами бизнес-уровня, после чего система ищет подходящие физические источники.
Основой системы стал машиночитаемый манифест в формате YAML. Этот файл хранит и смысловое описание данных, и их физическую структуру. Его можно сохранять в Git как обычный код, а другие системы — подключать к нему для работы. Дополнительную роль играет типизация элементов данных. Для разных объектов задаются типы, которые помогают агенту понять, как их использовать при построении запроса.
Такой подход одновременно сокращает объем контекста и снижает вероятность ошибочного использования данных. Вместо того чтобы передавать модели большое количество разрозненных описаний, система дает ей более компактную структуру знаний.
На пилотных доменах показатель качества достиг 90%. Стоимость описания одного поля при этом составляла около одного рубля благодаря использованию разных моделей на разных этапах конвейера.
Таким образом, основной ресурс для корпоративного Text2SQL — не количество примеров запросов, а качество метаданных и формализация бизнес-смысла. Нейросеть может генерировать SQL, но ей все равно нужно объяснить, что именно находится за таблицами и полями.
А подробнее об этом решении можно почитать в материале.
Во что упирается следующий уровень автоматизации
Техническая часть внедрения ИИ постепенно становится более понятной. Намного сложнее определить, кто отвечает за результат, как измерять экономический эффект и какие полномочия можно передать агенту.
Особенно заметно это на уровне Data Governance. Для каждого ИИ-кейса приходится определять, что агент имеет право делать самостоятельно, где требуется дополнительная проверка и какие операции должны быть запрещены. Чем больше полномочий получает система, тем важнее формализовать эти границы заранее.
Есть и более практическая проблема: инструмент уже работает, но командам также нужно время на его освоение. В MWS большинство описанных решений пока находится на стадии пилотов. Чтобы специалисты начали пользоваться агентами, их приходится подключать к процессу, показывать сценарии применения и объяснять ограничения.
Эта же логика относится к стоимости использования нейросети. В MWS в стоимость запроса закладывают не только токены. Учитывают поиск документов (retrieval), преобразование текста в векторы (embeddings), обращение к внешним инструментам, хранение данных, системы наблюдения и даже время, которое тратит человек на проверку ответа. Такой расчет позволяет увидеть реальную стоимость задачи.
Меняется и роль специалистов по данным. Data Steward постепенно превращается из человека, который в основном поддерживает описания и каталоги, в специалиста, отвечающего за то, насколько корректно ИИ понимает корпоративные данные. На встрече эту роль описали как переход к работе с контекстом.
Чем больше автономности получает агент, тем важнее становятся качество метаданных, правила доступа, оценочные наборы и наблюдаемость.
Переход к управляемой автоматизации
На седьмом митапе MWS рассмотрели несколько разных сценариев применения ИИ в работе с данными, но во всех них повторяется одна и та же схема.
Сначала компания должна привести в порядок данные, правила и процессы, затем описать задачу так, чтобы агент мог работать в заданных рамках, и только после этого передавать ему часть операций.
Для аналитика это означает автоматизацию подготовки документов и других повторяемых артефактов. Для инженера — поиск неоптимальных решений и автоматизацию рутинных операций вокруг инфраструктуры. Для Data Governance — расширение зоны контроля на модели, агентов, стоимость и риски. Для корпоративной аналитики — переход от простого поиска таблиц к работе с формализованным слоем бизнес-знаний.
Агент способен взять на себя часть задач, но человек обязан понимать, что именно делает агент и как проверяется его работа.Главная сложность не в том, сможет ли нейросеть выдать ответ или написать код. Проблема в наличии системы, которая позволяет проверить результат, измерить его качество и безопасно встроить в рабочие процессы.
А вы как считаете?
