Всем привет! Я Аня Мавлютова, технический менеджер продуктов Data Governance в Платформе данных в Т-Банке. Работаю в компании больше девяти лет. Начинала свой путь с дата-инженера, последние три года занимаюсь продуктами, которые помогают нашим пользователям работать с данными многократно быстрее и удобнее. В моей зоне ответственности продукты каталога метаданных Data Detective, инструменты Data Quality и сервис управления разметкой чувствительных данных.

В эпоху AI ценность данных компании сильно возросла, на них направлено более пристальное внимание. Процессы operate и observability над данными получили большой фокус: если нет уверенности, что сегодня данные построились в качественном виде, то задачу точно нельзя отдавать агенту. Данных становится в разы больше, поэтому очень важно как можно раньше отлавливать проблемы и ошибки в данных, если они возникли, чтобы предотвратить их увеличение в зависимых процессах.

В статье расскажу, как мы прошли путь от 11 длительных ручных шагов до автоматизации через AI-агента. Почему отказались от low-code-подхода, как работает распознавание intent и почему выбрали агентскую архитектуру вместо цепочки промптов. Спойлер: решение оказалось смелее, чем мы планировали в начале.

Как процесс работы с Data Quality выглядел год назад

У нас в компании много данных, а у данных много пользователей. Часть данных аналитики используют напрямую, часть уходит в интеграции, в AI, в управленческие отчеты. Критично, чтобы в любой точке и в любой цепочке данные были корректными — чтобы в любой момент можно было с уверенностью сказать: «Да, отчет N построен на достоверных цифрах, в нем нет ошибок».

Для оценки качества данных одной взятой таблицы пользователю предоставлялось два инструмента — Data Metrics и Data Checker:

• Data Checker — python-библиотека на языке SodaCL. Она упрощает разработку проверок DQ.

• Data Metrics — инструмент (портал) собственной разработки для управления и мониторинга заведенными проверками.

Сами проверки качества данных пишутся в Helicopter — внутренняя IDE для написания кода и запросов к данным.

Почему выбрали именно такие инструменты — рассказал мой коллега в докладе SmartData 2024 года.

С тех пор наше мнение об этих инструментах не изменилось, выбор был верным. Но нельзя сказать, что путь заведения одной проверки был простым и быстрым. 

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

Это не 11 «просто действий», это 11 действий, о которых надо знать. Без инструкции под рукой нереально сделать. Между действиями — многократные переходы между системами. Плюс знание языка Soda, который, хотя и простой, нигде кроме DQ не используется, а значит, на каждое изменение приходится лезть в документацию. И главное — это не масштабируется. Для каждой новой проверки нужно проделать все то же самое. А еще есть действия, которые пользователю плохо обоснованы, а путь удлиняют.

Пример кода на python для самой простой проверки выглядел так:

import datachecker.data_checker as dc
 
check_str = """
checks for test_schema.test_table:
    - duplicate_count(test_field_name) = 0:
        name: my_super_metric
"""
 
# Отправка значений
dc.run(check_str, "dlh")
 
# Синхронизация метрики из check_str с Data Metrics
dc.sync(
    check_str,
    "dlh",
    metric_set_id = "metric_set_name",
    username = user_param,
    password = user_pass,
    grant_type = 'password'
    )

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

Как мы искали решение

Мы поставили себе задачу: DQ должно быть по клику. Да, в один клик вряд ли можно уложиться, но процесс должен стать таким, чтобы абсолютно любой пользователь мог без инструкции завести проверки, а время на одну проверку должно быть не более 10 минут.

Задачу можно было решить по-разному. Можно было изменить подходы к покрытию таблиц проверками Data Quality, со стороны платформы данных завести за один подход на все-все таблицы проверки или изменить и адаптировать инструменты. Поскольку для нас было важно сохранить ответственность за данные на стороне владельцев таблиц, а процесс должен был стать легко масштабируемым, то мы оставили основной фокус на инструментах для DQ. 

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

• Перенести все, включая мониторинг проверок, в IDE (Helicopter).

• Перейти на low-code-подход: занести все в Data Metrics, запрятать всю работу с кодом в кубики и кнопки. 

Перенос всего в IDE был дорогим и с маленьким выхлопом. Пришлось бы сильно переписать backend Data Metrics, часть функционала урезать. Вместе с этим количество шагов не сократилось бы, ушла бы только смена окон. 

Переход на low-code в адекватные сроки был невозможен: Helicopter не предоставлял Public API по разным внутренним причинам. Без этого невозможна разработка. И даже если бы такой вариант был возможен, нам пришлось бы урезать возможность писать сложные проверки, которые в Soda-язык не входят.

Мы сделали промежуточный вывод: от нескольких инструментов не уйти. Нужно искать решение, как спрятать или сократить часть действий, чтобы в сумме их осталось по минимуму.

Трисет: Data Metrics, код проверок и публикации

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

1. Один раз подготовить пространство в Data Metrics, где будут храниться в дальнейшем все проверки по твоему проекту или домену.

2. Элемент взаимодействия с функционалом: на вход подается название таблицы и опционально — список желаемых проверок на человекочитаемом языке, на выходе — готовый код на Soda.

3. Публикация: готовый CI/CD, который за тебя делает все действия — от тестирования и валидации до деплоя процесса с синхронизацией и постановкой на Cron.

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

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

Мы добавили новый тип публикации — Data Quality. Из параметров необходимо только задать ссылку на пространство Data Metrics и условия запуска на планировщике: во сколько запускаться и ждать ли построения проверяемой таблицы.

Под капотом публикации написали новый код:

• Со стороны библиотеки Data Checker существующие функции адаптировали под требования публикаций. Перевели функции на работу с делегированными токенами, убрали излишние параметры, условия запуска перенесли в новый блок YAML-а с кодом Soda, скорректировали парсинг Soda. Добавили отдельные функции в библиотеку для возможности дебага и валидации.

• Со стороны публикаций настроили набор шагов для деплоя процесса на прод для DQ: валидация, тестирование ноутбука, создание prod-артефакта, синхронизация с Data Metrics, постановка на планировщик. 

Поскольку все функции спрятали от пользователя и в python-коде осталось только формирование строки с YAML-ом на SodaCL, мы добавили новый тип параграфа SodaCL, в котором сразу пишется и валидируется только Soda-код.

Второй же шаг был самым неочевидным: как его реализовывать, как к нему подойти. Но этот шаг должен был принести самое большое ускорение по времени в процессе.

Генерация проверок

Для публикации с готовым CI/CD проделали большую работу, поставленная задача быстро приобрела образ результата, который требуется реализовать. В случае с написанием самого кода проверок все было в разы сложнее. Нас преследовали одновременно две проблемы: 

• Никто не знает язык SodaCL. Хоть он и простой, но используется только в одном процессе (Data Quality). Если изучил язык, реализовал проверки, то на завтра вновь забудется. Каждое новое возвращение к задаче написания проверок вынуждает пользователя вновь погружаться в большой мир документации.

• Бизнес-аспект написания проверок. Надо покрыть таблицу с DQ-проверками, а перед тобой всегда чистый лист. Можно подсмотреть у коллег, можно потратить несколько часов на глубокое исследование. Но это плохо масштабируется: на каждую следующую таблицу новый чистый лист. А таблиц в домене, разумеется, не десяток и даже не сотня.

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

Вот что предприняли в первой итерации с точки зрения определения проверок:

1. Команда, отвечающая за процессы Data Incident Management, провела большое исследование. Собрали все проверки, которые были заведены. Были проведены CustDev более 15 команд, которые активно использовали инструменты DQ. В результате собрали большую сводную таблицу проверок с примерами с их типизацией, популярностью, условиями к заведению.

2. На основе собранной информации поделили проверки на три группы: базовые, расширенные и точечные проверки. 

После этого приступили к системному анализу, как это все можно реализовать.

Команда /datacheck

Когда мы приступали к задаче, в нашу IDE (Helicopter) уже завели чат с подключенной LLM. Мы ощущали большие перспективы в развитии чата, но были только в начале пути. У нас не было агентского режима, но мы умели подключать отдельные MCP Tools.

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

Для дальнейшей проработки нам необходимо было погрузиться в написание MCP Tools и как-то реализовать тулу именно под нашу задачу. 

Поскольку технология работы с mcp tools для команды была новой, задача не выглядела простой и очевидной. Мы решили идти последовательно и начали работу только с базовыми проверками.

Наш план базовых проверок:

• На основе команды пользователя извлечь все таблицы, которые он перечислил в свободном тексте. Таблицы могли быть написаны в разных вариантах, могли быть с ошибками, таблиц могло быть несколько.

• По полученному списку найти в дата-каталоге страницы объектов. Извлечь список колонок (DDL), получить дополнительно список первичных ключей, технические поля, проверить наличие версионирования.

• На основе полученных метаданных по чек-листу предложить код с готовыми проверками.

В результате работы над задачей мы получили команду /datacheck. Пользователям необходимо было ее прямо вызвать в AI-чате в Helicopter. На выходе команда генерировала набор простых проверок, которые проверяли базовый минимум, если по метаданным была получена соответствующая информация.

Как только команда была готова, мы ее раскатили сначала на фокус-группу, затем на всех пользователей. Собрали обратную связь — ее было много и положительной. Маленькие ошибки скорректировали сразу. Сформировали дополнительно backlog на развитие команды /datacheck, что еще можно проверять.

Команда успешно взлетела. Мы получили быстрый adoption. Но нам еще предстояло расширить покрытие видов проверок. Каким-то образом реализовать более сложные проверки, требующие не только метаданных, но и анализа данных внутри таблицы.

Распознавание intent

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

Первая развилка — как вообще вести пользователя. /datacheck может закрывать разные сценарии: предложить проверки для таблицы, сгенерировать набор проверок, сгенерировать конкретный SodaCL по описанию на человеческом языке. Но как понять по одному запросу, что именно хотел пользователь?

Мы рассматривали два подхода.

Много отдельных команд. Например, /datacheck_suggest @table запускает флоу выбора проверок, а /datacheck_translate_to_soda переписывает пользовательский запрос в SodaCL.

Плюс: точно понятно, что хотел пользователь.

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

Одна команда + механизм распознавания intent. Внешне остается одна команда /datacheck, а поведение зависит от текста запроса:

• /datacheck @table — работает как предложение проверок;

• /datacheck @table «хочу, чтобы email всегда был валидным» — пытается сгенерировать код Soda;

• /datacheck @table1 @table2 #ABPLATFORM — генерирует набор проверок;

• /datacheck «рецепт борща» — просит уточнить запрос.

Первый шаг бота — intent-определитель: он анализирует запрос, выбирает сценарий для всего дальнейшего пути, при необходимости уточняет или дает пользователю выбор сценария. Если intent не распознан — возвращает «не понял» и логирует такой кейс как сигнал, что нужно подумать, как обработать этот тип запроса.

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

Минус: появляется дополнительный шаг.

Вывод был однозначным: разные команды сложно масштабировать и объяснять пользователям. Выбрали механизм intent.

Верхнеуровневая архитектура для intent

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

Chain of Prompts — заранее определенная цепочка шагов. Приложение — это последовательность шагов, на каждом из которых выполняется один или несколько AI-вызовов. Каждый следующий промпт получает результат предыдущего: сначала определяется intent, потом извлекаются сущности, строится кандидат на проверку, затем генерируется SodaCL.

Плюс: просто в реализации, хорошо дебажится, высокий контроль.

Минус: сложно встраивать новые use cases, покрывает, по сути, только один сценарий, на деле может оказаться сложнее, чем кажется.

Компоненты и Workflows. Распознавание intent выбирает workflow под этот intent, а workflow вызывает переиспользуемые компоненты.

Плюс: более детерминированное использование AI, покрывает все use cases, в будущем может эволюционировать в агента.

Минус: для каждого нового use case придется добавлять новый workflow.

Полностью агентская система через data-agent. Центральный механизм — агент, который сам решает, какие шаги выполнить, какие инструменты вызвать и как собрать итоговую проверку или набор проверок. Он может использовать tools и skills для получения метаданных, выполнения SQL, профилирования, подбора проверок и генерации SodaCL, сам управляя порядком действий.

Плюс: покрывает все use cases, теоретически может обработать даже те, которые мы изначально не закладывали. Агент данных — целевой способ работы с данными, его развитие — один из приоритетов команды.

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

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

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

В первичном варианте через агента генерацию проверок сделали через набор скиллов. Мы собрали воедино несколько точек:

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

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

• Объяснили, как проводить диагностику таблиц: что и когда нужно проверить.

• Задали широкий чек-лист всех видов проверок, которые агент должен рассмотреть и на основе анализа выше предложить пользователю.

• Добавили обязательный HITL на создание проверок: человек должен оценить, что из этого действительно верно.

• Создали параграф с кодом и дебаг.

В итоге агент в процессе распознает таблицу, получает ее метаданные, категоризирует поля в таблице по типу данных и наполнению, проводит диагностику (запускает запросы). На выходе на основе управляемого чек-листа предлагает пользователю список релевантных проверок. Пользователь проводит визуально по описанию оценку, с какими проверками он согласен, дает агенту подтверждение или корректировки. Далее агент формирует итоговый SodaCL-параграф и в режиме дебага убеждается, что все собрано верно.

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

Какой итог мы получили

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

Какие цифры и пользу мы получили:

• Процесс генерации проверок в среднем занимает не более пяти минут. Замеры проводились многократно. Единственное влияние, которое может сказываться на выход за пять минут, это нагруженность LLM-платформы в часы пик.

• Используя агента, мы смогли получить не только ускорение для создания одной проверки, но и процесс с массовым заведением релевантных проверок. С последним крупным релизом наш агент научился работать сразу с несколькими ноутбуками в IDE, что дает ему возможность по алгоритму покрыть весь список объектов разом. У нас получилось покрыть 373 таблицы проверками за три дня ресурсами трех стажеров.

• Adoption: с момента публичного выступления внутри компании каждую неделю создает в среднем от 330 проверок. Максимальное количество — 2 350 новых проверок за неделю. На текущий момент это от 30 до 58% от всех новых проверок за выбранный период.

Мы прошли большой путь для достижения текущего результата. Повлияло ли что-либо на наше решение в начальной точке, если бы можно было повернуть время назад? Пожалуй, нет, так как на наши решения основное влияние оказали активные технологические изменения на рынке. Появление внутренних LLM, включение AI-чата в наши инструменты работы с данными, масштабирование работы с mcp tools, включение агента, добавление скиллов и субагентов — все это последовательно влияло на открытие новых возможностей.