Агент Data Engineering від Adobe: онбординг скорочується з тижнів до днів

Кожен, хто брав участь у розгортанні Adobe Experience Platform, знає, як минають перші шість тижнів: хтось складає таблиці маппінгу, хтось женеться за експортом із Marketo, а дата-інженер о 23:00 перебудовує схеми, бо loyalty ID прийшли як рядки. Саме цю ситуацію Adobe тепер намагається автоматизувати. 20 квітня Adobe анонсувала Data Engineering Agent — новий агентний воркфлоу, побудований на Experience Platform Agent Orchestrator, який «незабаром» стане загальнодоступним.

Що сталося

Як повідомив Adobe for Business у дописі авторства Хионг Ву, Data Engineering Agent розроблено для спрощення циклів роботи з даними для інженерів, архітекторів і споживачів даних — зокрема фахівців із маркетингових операцій. Позиціювання чітке: традиційний онбординг даних у Experience Platform часто займає тижні, а іноді й місяці. Adobe стверджує, що агент скоротить цей час до днів.

Агент ще не запущений. Adobe описує його як «незабаром доступний», побудований на Experience Platform Agent Orchestrator і керований через розмовний інтерфейс AI Assistant. Користувачі взаємодіють за допомогою запитів природною мовою в рамках воркфлоу з людиною в контурі управління: агент пропонує, людина затверджує.

Охоплення широке. На боці онбордингу агент підтягуватиме дані з таких джерел, як Amazon S3, Data Landing Zone та Marketo, перевірятиме якість даних, затверджуватиме рекомендовані AI поля для створення схем, налаштовуватиме семантичне збагачення та створюватиме dataflow за допомогою AI Assistant для інгестії в Experience Platform. На боці SQL він генеруватиме оптимізовані, схемо-свідомі SQL-запити з попереднім переглядом перед виконанням, моніторитиме та усуватиме неполадки SQL-завдань без перемикання між інструментами, перевірятиме готовність датасетів перед запуском завдань і направлятиме користувачів через автоматичне усунення проблем у разі збоїв.

Кінцевими споживачами є звичні для Adobe продукти: Real-Time Customer Data Platform, Customer Journey Analytics та Journey Optimizer. Чисті дані на вході — швидша активація на виході. Adobe також зазначає, що агент надаватиме операційні інсайти з візуалізацією ліній походження, залежностей і зв'язків, а також контекстні знання про продукт на основі Experience League, форумів спільноти та публічної документації GitHub.

Моя думка: Adobe наздоганяє агентну дата-інженерну нарацію, яку Snowflake і Databricks розповідають вже рік, але прицілюється безпосередньо в маркетинговий шар даних, де Adobe все ще утримує відносини.

Технічна архітектура

Якщо відкинути маркетингову лексику, архітектура — це класична схема оркестратора з використанням інструментів. Agent Orchestrator виступає планувальником. AI Assistant — розмовним інтерфейсом. Сам агент звертається до наявних примітивів Experience Platform: конекторів джерел, реєстру схем (Experience Data Model), dataflow та Query Service. Новизна полягає в тому, що мовна модель створює артефакти, які дата-інженер зазвичай формував вручну.

Онбординг працює приблизно так. Користувач вказує агенту на файл або джерело — наприклад S3, Data Landing Zone чи Marketo. Агент перевіряє дані, пропонує маппінг полів до XDM, позначає проблеми якості, пропонує семантичне збагачення та будує dataflow. Людина затверджує перед публікацією. Цей шлюз затвердження виконує чимало роботи. Дрейф схем у датасеті профілю клієнта може тихо отруювати CDP місяцями, перш ніж хтось помітить, що сегмент недораховує. Блокування публікації для перевірки — правильне рішення.

Для SQL схема аналогічна. Агент читає цільову схему, генерує схемо-свідомий запит, показує попередній перегляд, а потім моніторить виконання. Якщо завдання зазнає збою або датасет не готовий, агент сигналізує про проблему і пропонує усунення. Це суттєва зміна порівняно з поточним воркфлоу, де аналітик пише запит, запускає його й дізнається про збій лише тоді, коли кампанія в Journey Optimizer дає збій.

Очевидна точка порівняння — решта аналітичного стеку. Команди, що використовують dbt, вже мають тестування та відстеження ліній походження як концепції першого класу, задокументовані в документації dbt. Snowflake і Databricks обидва постачають SQL-копілоти в агентному стилі. Ставка Adobe полягає в тому, що клієнти Experience Platform воліють тримати підготовку даних усередині периметру Adobe, а не підключати зовнішній шар трансформацій. Ця ставка виправдана для маркетингових команд середнього ринку. Для підприємств, що вже стандартизувалися на lakehouse, продати це складніше.

Незручний висновок: агент допомагає лише тоді, коли ваші дані вже надходять у форматах, зручних для Adobe. Сміття на вході — сміття на виході, навіть за допомогою LLM.

Хто відчує наслідки

Три групи мають звернути увагу. По-перше, партнери з впровадження Adobe. Значна частина їхнього доходу формується з оплати тижнів дата-інженерних робіт з онбордингу транзакцій електронної комерції, активності лояльності та профілів клієнтів — саме тих датасетів, які Adobe наводить як приклади. Якщо тижні стискаються до днів, рахунки теж скорочуються. Партнери, що ціноутворюють за витраченими зусиллями, це відчують. Ті, хто ціноутворює за результатами, будуть у порядку.

По-друге, штатні дата-інженерні команди в компаніях, що використовують Adobe. Нікого не звільняють, але робота зміщується. Менше часу на написання логіки маппінгу, більше — на перевірку результатів агента, управління поведінкою моделі та роботу з крайніми випадками, де агент помиляється. Команди, з якими я працював і які впроваджували SQL-копілоти, виявили, що навантаження від перевірки є реальним: уважно читати згенерований SQL, щоб йому довіряти, займає майже стільки ж часу, скільки написати його самому, принаймні в перший квартал. Врахуйте це в бюджеті.

По-третє, фахівці з маркетингових операцій. Adobe прямо зазначає, що споживачі даних, включно з маркетинговими опс, є цільовими користувачами. Це суттєве розширення кола тих, хто взаємодіє зі схемами та dataflow. Водночас це і міна в питанні управління. Коли аналітик маркетингових операцій може інгестувати новий експорт із Marketo через чат-інтерфейс, поняття «схвалене джерело даних» стає розмитішим. Очікуйте, що наступні 90 днів будь-якого розгортання Adobe включатимуть дискусію про те, хто отримує доступ до агента і як виглядає політика затвердження.

Виробничі інциденти, які я спостерігав в iGaming та fintech, майже завжди простежуються до однієї з двох причин: зміна схеми, про яку ніхто не повідомив, або SQL-завдання, що тихо повернуло дані неправильної форми. Агент, який показує попередній перегляд SQL перед виконанням і перевіряє готовність датасету, усуває обидві проблеми — якщо команди справді читають ці попередні перегляди. Це велике «якщо», коли інтерфейс здається розмовним і швидким.

План дій для дата-команд

Якщо ви управляєте аналітикою або інфраструктурою даних клієнтів на Adobe, ось чеклист для першого тижня.

Проінвентаризуйте поточний беклог онбордингу. Перелічіть кожен датасет, що застряг у пайплайні, систему-джерело та кількість інженерних днів, яку він споживає. Коли агент стане доступним, вам знадобиться порівняння «до і після», яке можна реально виміряти. «З тижнів до днів» — це твердження Adobe. Ваше твердження має бути конкретним щодо ваших датасетів.

Зафіксуйте політику людини в контурі управління до увімкнення агента. Вирішіть, хто затверджує схеми, хто затверджує dataflow і хто затверджує виконання SQL для виробничих датасетів. Запишіть це. Агентні інструменти безпечно відмовляють лише тоді, коли ланцюжок затвердження чітко визначений.

Інструментуйте відстеження ліній походження незалежно. Adobe стверджує, що агент візуалізуватиме лінії походження, залежності та зв'язки. Добре. Але не покладайтеся лише на це. Ведіть зовнішній запис того, які датасети живлять які аудиторії Real-Time CDP та кампанії Journey Optimizer. Якщо агент щось неправильно налаштує, вам знадобиться власна карта.

Стрес-тестуйте попередні перегляди SQL. Перш ніж довіряти згенерованим агентом запитам у виробництві, проведіть спринт, де інженери навмисно перевіряють кожен попередній перегляд. Каталогізуйте режими відмов. «Схемо-свідомий» не означає «семантично-свідомий», і різниця проявляється у звітності по виручці.

Переглянете партнерські контракти, якщо платите за інженерні тижні. Якщо онбординг справді стискується, припущення у вашому технічному завданні застаріли. Висновок: ставтеся до агента як до мультиплікатора продуктивності для досвідчених інженерів, а не як до їхньої заміни — і ваше розгортання буде нудним у найкращому сенсі цього слова.

Ключові висновки

• Adobe Data Engineering Agent, побудований на Experience Platform Agent Orchestrator, незабаром автоматизує онбординг, підготовку SQL, збір даних та усунення неполадок у Experience Platform.
• Adobe стверджує, що час онбордингу скорочується з тижнів (іноді місяців) до днів для таких датасетів, як транзакції електронної комерції, активність лояльності та профілі клієнтів.
• Підтримувані джерела на момент запуску включають Amazon S3, Data Landing Zone та Marketo, із постачанням даних у Real-Time CDP, Customer Journey Analytics та Journey Optimizer.
• Агент використовує воркфлоу з людиною в контурі управління з підказками природною мовою, попереднім переглядом SQL перед виконанням та автоматичними інструкціями з усунення проблем.
• Партнери з впровадження, що виставляють рахунки за зусилля, політики управління маркетинговими опс та договірні припущення — все це потребує перегляду в наступному кварталі.