AI Ready: базовый минимум и роскошный максимум для внедрения ИИ в компании

Что мы подразумеваем под AI Ready

AI Ready — это не просто наличие ИИ-агента в контуре. Это способность платформы данных провести весь путь от сбора требований и данных до работающего дата-продукта так, чтобы агенты могли участвовать в этом процессе нативно, эффективно и под контролем человека. Иными словами, AI Ready — это не только про модели и агентов, но и про порядок данных, контекст, интерфейсы, роли, дата-контракты и управляемые процессы.

Зачем на каждом этапе человек

Когда у нас есть дата-продукты, мы хотим автоматически проанализировать данные, спроектировать модель данных и разработать какой-либо дата-продукт, чтобы запустить это в продакшн. Для этого нужно решать инфраструктурные, аналитические и разработческие задачи. Здесь появляются агент-аналитик и агент-разработчик. Но в любом случае каждый этап контролирует человек.

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

Здесь возникает вопрос: зачем нужна мультиагентная система и для чего на каждом этапе присутствие человека? И как все это синхронизируется в общем процессе?

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

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

Элемент контроля идет в рамках процессов дата-каталога: когда у нас получается спецификация, мы утверждаем эту спецификацию и утверждаем дата-контракт. Это делают бизнес-пользователи и руководители групп разработки в дата-каталоге. Когда речь идет о роли разработчика, подключаются механизмы кодогенерации, шаблонизации, и все это интегрировано с CI/CD-процессами, механизмами согласования и скриптами проверки в рамках CI/CD.

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

Но чтобы все это заработало, нужны подготовленные компоненты платформы. Недостаточно просто того, что данные хранятся в каких-то файлах. Недостаточно просто того, что у нас есть дата-каталог с API-интерфейсом, через который могут применяться различные инструменты. Для работы AI-агентов нужны MCP-сервера, нужно где-то обучать скиллы, где-то их версионировать, где-то запускать процессы согласования и динамически выделять ресурсы под те или иные задачи в части ML и в части механизмов расчетов. Все это должно поддерживаться на уровне дата-платформы.

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

Взгляд со стороны фундамента: три ступени на пути к AI Ready

Александр Анисимов из Arenadata предложил спуститься с прикладного уровня ближе к фундаменту и посмотреть, каким требованиям должна удовлетворять платформа данных, чтобы получить заветный статус AI Ready.

Arenadata несет в своей продуктовой корзине весь необходимый спектр продуктов для построения OCP-платформ, lab-платформ, DWH, DataLake, inhouse и прочего. Но требования, которые важно озвучить, справедливы абстрактно для любой платформы — даже, в принципе, за пределами данных.

Есть три ступени для достижения статуса AI Ready. Хорошая новость: ступеней не так много, и первая из них уже пройдена. Важно проговорить каждую в абстрактном контексте.

Первое требование — это порядок наших данных. Чтобы они были надежны, защищены, чтобы был аудит, структура, наблюдаемость, мониторинг и так далее. Важно понимать, что этого достигает любая платформа вне зависимости от требований к AI Ready. Единственное, что меняется, — в контуре появляются агенты. Но мы также хотим защитить свои данные, также хотим наблюдать, что они делают.

По всем продуктам первую ступень уже давно преодолели. Эта ступень нужна была для достижения data-комплаенса, удовлетворения требованиям безопасности. И все это также масштабируется и требуется для AI Ready-платформ. У Arenadata хорошо проработан метастор — единый метастор, к которому обращаются все вычислительные движки. Безопасность — централизованные Ranger-плагины, которые предоставляют не только в рамках ADH, но и других продуктов единое окно управления безопасностью и аудитом. И, наверное, такая нашумевшая технология Iceberg как один из реквизитов получения lakehouse добавила жесткие структуры и дополнительный функционал для структуризации данных и порядка дата-платформы.

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

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

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

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

Что предлагают в Arenadata

Arenadata Streaming — платформа, которая работает в рамках потоковой передачи данных и потоковой аналитики. Там есть Kafka, есть Schema Registry. С точки зрения порядка все уже организовано. Schema Registry — не просто компонент, добавленный в продукт: он интегрирован во все узлы этого продукта. Есть много автоматизаций, потому что пользователям часто не хватает экспертизы, чтобы быстро внедрить схемы и получить необходимый эффект. Поэтому автоматизации позволяют создавать необходимые компоненты для интеграции со Schema Registry, а через Arenadata Streaming Control можно наблюдать изменение схем, редактирование схем, интеграцию с топиками.

Безопасность также централизована и транслируется во все продукты. Есть выбор: можно использовать централизованную безопасность на базе ADPS и Ranger с централизованным аудитом, а можно уходить на стандартные средства аутентификации и авторизации внутри Kafka.

С точки зрения контекста у Arenadata Streaming есть отдельный компонент внутри Kafka-сервиса — Cruise Control, который собирает всю телеметрию и автоматизирует обслуживание кластера. Это идеальная точка входа для предоставления состояния кластера агентам.

Также есть технология, которая позволяет фактически бесконечно долго хранить данные в папке. Это важно для узлов, которые строят стриминговые платформы, стриминговую аналитику, потоковые данные, когда нужна история и быстрое обращение к ней. Мониторинг тоже присутствует — и в ADH, и в ADS, и дальше по всем продуктам.

Сейчас дорабатывается lineage. Исторически lineage уже внедряли в DWH, DataLake, lakehouse. Это достаточно распространенная практика, но потоковые платформы в этом плане отстают. В ближайшем релизе добавляется интеграция с OpenMetadata и далее с рядом каталогов с точки зрения получения информации о lineage из Kafka-коннекторов. В первую очередь для S3-коннектора, для записи в Iceberg, а в следующем релизе — для Debezium-коннектора. Это позволит предоставить полную картину для CDC-pipeline: откуда взяли данные, куда они приземлились, куда дальше поехали, какие трансформации на этом потоковом пути происходили и с какими коннекторами.

Также важен общий платформенный дата-контракт. Контракты данных — это важно. Все будет интегрироваться на уровне всех продуктов, чтобы была единая точка управления контрактными данными, согласованная со Schema Registry.

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

Третий продукт — дата-оркестратор на базе Apache Airflow. Помимо оркестрации, туда добавлен управляемый сервис dbt и DAG. Оркестрация как функция в любой дата-платформе является центральным звеном управления, и туда очень активно и архитектурно корректно встраиваются дополнительные функции в виде dbt и DAG.

С точки зрения порядка dbt привнес модели, структуризацию и прочие вкусности, которые активно используют пользователи. С точки зрения интеграции есть отдельный сервис, который добавляет GitOps-подход и стандартизирует работу по доставке артефактов до Airflow и dbt. Это тоже полезно и достаточно удобно будет управляться через AI-модель.

С точки зрения безопасности это все та же централизованная система, интеграция с Vault. Это кросс-продуктовая функция, которая позволяет все секреты конфигурации или прикладные секреты хранить на стороне централизованного хранилища секретов. Это тоже будет интегрировано с AI-агентами.

С точки зрения контекста ADO как центральная функция оркестрации внутри дата-платформы — хорошее место для интеграции единого слоя дата-контракта, с которым будут интегрированы все остальные продукты и сервисы. Аналогично с data lineage: есть много разных продуктов — ADS, ADH, ADP, и везде могут присутствовать элементы извлечения данных, записи данных в ту или иную систему. Везде децентрализованно есть какая-то функция интеграции с data lineage. Оркестрация как единый центр управления всей платформой — тоже хорошее место, чтобы централизовать эту функцию. Сюда ее будут добавлять и расширять контекст не только для людей, но и для машин.

Open Source тоже не стоит на месте

Помимо доработок, которые вендор несет поверх своих продуктов, нужно понимать: Open Source тоже не стоит на месте. Там очень много функционала добавляется с точки зрения интеграции с AI-системами. За этим активно следят и помогают пользователям решать их задачи. Буквально к каждому source-компоненту уже добавилось несколько фичей, которые помогают интегрироваться с AI-системой, с AI-платформой, автоматизировать старый функционал.

Один из примеров: на базе ADS есть функция CDC. Есть встроенный коннектор Debezium, который поддерживается, и встроенный коннектор Iceberg. Можно фактически организовать CDC-pipeline из коробочки от любой OLTP-базы данных до Lakehouse. Недавно в Debezium добавились SMT-трансформации, которые позволяют любые поля сразу же переводить в векторный тип и строить своего рода pipeline для RAG-системы.

В ADO тоже очень много функций, связанных с ИИ. Среди последних релизов выделяется Open-AI Provider, который позволяет через конкретный стандартизированный интерфейс интегрироваться с AI-агентами без дополнительных затрат. Фактически уже из коробки получается оркестратор не просто для дата-процессов, но и для AI-историй.

В ADH, самом большом продукте с точки зрения наличия компонентов, выделяется Kyuubi как единый общий гейтвей для всех вычислительных движков. До этого добавляли чат-агента, который позволял через этот гейтвей общаться с чатом. Чатом сейчас уже никого не удивишь. Сейчас идет активность по добавлению Data Agent Engine, который позволяет вести конкретную агентскую работу внутри себя, интегрированную с безопасностью и вычислительными движками. Когда вы обращаетесь к нему, агент сразу же будет работать с SQL, с дата-контрактами, со схемами данных и формировать работу через вычислительные движки, при этом имперсонируя вашего пользователя.

AI Ready-статус не приходит сам

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

Одно дело, когда у вас есть старый админ Василий, который уже 20 лет на проекте, и ему можно доверить: он все помнит, все сделает и ничего не удалит. Другое дело — агент. Он залетает и не говорит, что ему чего-то не хватает. Он не говорит, что не знает какие-то схемы данных. Он говорит: «Я все знаю, сейчас я пойду, все удалю и все сломаю». Вы даже не заметите.

Поэтому AI Ready — это не только про агентов. Это про порядок данных, контекст, интерфейсы, роли, контракты, контроль и готовность платформы выдержать присутствие ИИ в контуре.