Агенты в дата-платформах 🤖

Я уже полгода вожусь с разными дата агентами и другими GenAI решениями для данных. Кодинг / контекст ассистенты уже поменяли индустрию кардинально, а с внутренними агентами ситуация еще интереснее 😘.

Допустим, у вас в проде крутится дата агент-оркестратор. Он рулит десятком других агентов, те дёргают ещё по 10 тулов каждый.

Сценарий успеха: автоматизировали дата-платформу на 95%, радикально порезали косты, оставили 4 инженеров на on-call и одного визионера-архитектора минимум людей. Звучит топ (для менеджмента 🍷).

Какие подводные камни могут быть на этом пути? (Список не полон и нужны посты для раскрытия каждого)

1. Garbage in — garbage out во всем, начиная со спеки 🗑️

Как удостовериться, что требования на систему (написанные, конечно же, тоже с помощью GenAI) были полными и учитывало весь контекст? Claude генерит тонны кода, решающие неверную задачу. Раньше garbage in давал вам один кривой пайплайн (с фиксом на PR), а теперь - двадцать, и кривую дата платформу в придачу.

2. Недетерминированность и «а сколько процентов вас устроит?» 🎲

Какой процент корректности ок для полностью автоматизированных задач? Автозапуск backfilling, пропуск DQ-тестов при низком риске — 93%? 97%? 99%? Любая из этих цифр (часто взятая с потолка) нуждается в риск-менеджменте и готовности тушить прод, когда агент решит что-то оптимизировать сломать.

Context mismatch: агент просто решил не запускать tooling и начинает принимать решения хорошо, если только на неполном контексте, а иногда еще и нагаллюцинированном.

3. Инфраструктурные косты 💸

Если вы на on-prem - готовьтесь к x5-10 росту нагрузки (консервативно, если у вас еще нет ральф луперов в 5-10 окнах claude). Если в клауде - 👋 вашим бюджетам на compute (кек, особенно если у вас ещё и мультиклауд). Из интересного: скорее всего увидим активное улучшение дата-каталогов и меты. Агенты, пытаясь «понять» незнакомую таблицу, часто делают SELECT-ы прям в базу, а если дата профайлинг уже сделан, то метаданные превращают все это в one write - multiple reads на кешах.

4. On-call 🚨

Техническая сторона: галлюцинации + шквал false-positive алертов. Нужны десятки итераций для калибровки guardrails и eval-метрик вашего агента, и доработки corner cases.

Еще веселее человеческая сторона. GenAI решает простые алерты (пока 😂). А онбординг человека это понять паттерны на пуле таких базовых задач для набивки руки и контекста. Что будет делать джун, когда его первым инцидентом станет сложнейший нетипичный сбой? Спокойно закопается в код для дебага Пойдёт в панике промптить, надеясь на то, что он по устаревшему runbook что-то да соберет.

5. Демократизация разработки с GenAI 🧟

С развитием coding-агентов и text-to-pipeline генерация пайплайнов / etl frameworks уходит в массы. Если вы боттлнек, то бизнес вас обойдёт. Либо технически - нагенерив SQL на 5000 строк для своей витрины, либо политически - через эскалацию до VP с фразами «дата-команда тормозит time-to-market».

6. Security / prompt injection 🔓

Если агент смотрит на данные (таблицы, логи, тикеты, конфиги) любой текст может стать инструкцией.

Банальный пример: поле comment в таблице. До 2025 -> ну лежит там мусор, ок, 2026 -> Агент залогирует перс данные, выдаст доступы, выполнит "полезную" команду, подсунутую через контент. В DQ внезапно стал еще и security, и вашему DQ фреймворку нужны совсем другие тесты (Вы еще не делаете LLM-as-a-Judge? Тогда мы идем к вам :D)

7. Accountability: кто виноват? ⚖️
Генерация документации / постов / емейлов - первое, что делегируют LLM и даже уже не читают. Как ты тестировал? Ну запустил агента, вот output, а то что там явным текстом прописано, что есть проблемы, уже не важно, главное заполнить тест план =).

Так же появляется размытость accountability между командой, которая делала дата агента, и продуктовой командой, которая его использует.

---

В общем, добро пожаловать в эру data janitors and debuggers по GenAI-инцидентам, будет хуже весело 🙂

P.S. А есть русскоязычные коммьюнити по дата агентам, или есть смысл сделать тг чат для брейншторминга?