TL;DR
DataGovAgent — мультиагентный фреймворк для автоматизации управления данными (очистка, валидация, трансформация). Вместо генерации всего решения за один проход использует последовательный пайплайн из трёх ролей: Планировщик создаёт схему операций с формальными контрактами (что должно быть на входе/выходе каждого шага), Исполнитель генерирует реализацию под эти контракты, Проверяющий запускает результат и при ошибке анализирует какой контракт нарушен. Это называют Agentic Assembly Line — конвейер специализированных агентов.
Основная проблема одношаговой генерации: код запускается, но не решает задачу. Например, GPT-5 на сложных workflow генерирует синтаксически корректный код в 86% случаев (CRR), но правильно выполняет бизнес-задачу только в 46% (TSR). Модель не понимает зависимости между шагами: выход шага 1 не соответствует входу шага 2, промежуточные результаты теряются, финальный результат не удовлетворяет требованиям. В простых задачах разрыв меньше (85% CRR vs 49% TSR), но всё равно каждый второй "рабочий" код не выполняет цель.
Решение — разбить на роли с governance contracts (контрактами управления). Контракт = пара (pre, post): что требуется на входе, что гарантируется на выходе. Планировщик строит цепочку операций так, чтобы post-условие шага N удовлетворяло pre-условию шага N+1. Если не удовлетворяет — вставляет "ремонтный" шаг (например, приведение типа или заполнение пропусков). Проверяющий после выполнения анализирует какой контракт нарушен и даёт целевой feedback. Итерации повторяются до успеха. Это поднимает Task Success Rate с 49% до 64% на простых задачах (+15 п.п.) и с 46% до 60% на сложных (+14 п.п.), при этом сокращает отладочные итерации с 14.9 до 3.3 раз.
Схема метода
ПЛАНИРОВЩИК:
Вход: NL описание задачи + схема данных + примеры
Действия:
1. Оценить выполнимость задачи на этих данных
2. Разбить на операции (DAG узлов)
3. Для каждой операции определить контракт:
- Pre: требования к входным данным
- Post: гарантии на выходе
4. Проверить цепочку: post(шаг N) → pre(шаг N+1)
5. При несоответствии — вставить "ремонт" (casting, imputation)
Выход: DAG абстрактных операций с контрактами
ИСПОЛНИТЕЛЬ:
Вход: Один узел DAG + его контракт
Действия:
1. Retrieval: найти похожие операции в библиотеке
2. Использовать их как in-context примеры
3. Сгенерировать Python код под контракт
Выход: Исполняемый код для узла
ПРОВЕРЯЮЩИЙ:
Вход: Код + контракты + данные
Действия:
1. Запустить в sandbox
2. При ошибке:
- Захватить stack trace
- Определить какой контракт нарушен
- Сформировать целевой feedback
3. Передать feedback Исполнителю
4. Повторить до успеха или лимита итераций
Выход: Валидированный код
Все три роли работают последовательно. Это не one-shot генерация, а конвейер — каждый агент выполняет свою функцию и передаёт результат следующему.
Пример применения
Задача: Готовишь данные для анализа клиентской базы онлайн-школы. Нужно: убрать дубликаты email, привести даты регистрации к единому формату (YYYY-MM-DD), заполнить пропуски в поле "город" на основе телефонного кода, классифицировать клиентов по активности (более 3 покупок = "активный").
Промпт:
Задача: обработать таблицу клиентов по следующим шагам:
1. Удалить дубликаты по email (оставить последнюю запись)
2. Привести даты регистрации к формату YYYY-MM-DD
3. Заполнить пропуски в "город" на основе телефонного кода
4. Добавить колонку "статус": >3 покупок = "активный", иначе "неактивный"
Данные: [прикрепить CSV или описать структуру]
Используй подход Governance Contracts:
1. Сначала в роли Планировщика: разбей задачу на операции, для каждой определи:
- Pre: что требуется на входе (формат, обязательные поля)
- Post: что гарантируется на выходе
- Проверь что выход каждого шага соответствует входу следующего
2. Выполни операции по порядку
3. После каждого шага в роли Проверяющего: проверь выполнены ли post-условия. Если нет — опиши что пошло не так и исправь.
Покажи контракты до выполнения и результаты проверок после каждого шага.
Результат:
Модель сначала опишет план с контрактами для каждого шага: - Шаг 1: pre (есть колонка email), post (каждый email уникален) - Шаг 2: pre (есть колонка с датами), post (все даты в YYYY-MM-DD, нет невалидных) - Шаг 3: pre (есть телефонный код и справочник кодов→город), post (все города заполнены где возможно) - Шаг 4: pre (есть числовое поле "покупки"), post (новая колонка "статус" со значениями активный/неактивный)
Затем выполнит каждую операцию и покажет результаты проверки контрактов. Если на каком-то шаге post-условие не выполнено (например, остались невалидные даты), опишет проблему и предложит исправление.
Почему это работает
Проблема LLM: при генерации сложного многошагового кода модель держит в "рабочей памяти" всю цепочку зависимостей. К середине workflow она теряет контекст начальных шагов — возникают несоответствия типов данных, пропадают промежуточные результаты, финальный код синтаксически корректен но логически не работает. Как строительство дома где каждый этаж строят не проверив фундамент предыдущего — дом рушится на финише.
Сильная сторона LLM: модель отлично работает когда есть формальная спецификация — чёткие критерии "правильно/неправильно". Она может проверить соответствие формату, сравнить требования и факт, найти нарушенное условие. Это то же что делает модель в code review или при валидации JSON — если есть схема, она точно скажет где отклонение.
Как работает метод: Governance Contracts создают формальную спецификацию для каждого шага. Pre/post условия — это как type hints в Python, только для логики: "на входе должны быть строки формата DD.MM.YYYY, на выходе — формат YYYY-MM-DD без исключений". Планировщик строит цепочку так, чтобы контракты сходились: post шага 1 = pre шага 2. Если не сходится — вставляет промежуточный шаг. Проверяющий после выполнения сравнивает факт с post-условиями и при расхождении точно знает ЧТО сломалось, не перебирает весь код.
Рычаги управления:
Детальность контрактов: Можешь задавать строгие условия (формат до символа, диапазоны значений) или мягкие (общие требования). Строгие — меньше ошибок, но больше времени на проверку.
Число итераций: Установи лимит отладочных циклов (например, max 3 попытки). Для простых задач хватит 1-2, для сложных может понадобиться 5-7.
Способ описания контрактов: Можешь использовать формальный синтаксис (Pre: type=date, format=YYYY-MM-DD) или естественный язык (На входе даты должны быть в формате год-месяц-день через дефис). Формальный — точнее, естественный — проще писать.
Поведение при нарушении: Укажи что делать если контракт не выполнен — остановиться и запросить уточнение у тебя, или попытаться автоматически исправить. Для критичных задач лучше остановка, для экспериментов — автоисправление.
Шаблон промпта
Задача: {описание задачи с несколькими шагами}
Данные: {описание или прикрепление данных}
Используй подход Governance Contracts для многошаговых задач:
ШАГ 1 — ПЛАНИРОВАНИЕ (роль: Планировщик):
1. Разбей задачу на последовательность операций
2. Для каждой операции определи контракт:
- PRE (предусловия): что требуется на входе — формат данных, обязательные поля, допустимые значения
- POST (постусловия): что гарантируется на выходе — формат результата, критерии корректности
3. Проверь цепочку зависимостей: POST операции N должен удовлетворять PRE операции N+1
4. Если не удовлетворяет — добавь промежуточную операцию (приведение типа, заполнение пропусков, валидация)
Выведи план в формате:
Операция 1: {название}
PRE: {требования к входу}
POST: {гарантии на выходе}
Операция 2: ...
ШАГ 2 — ВЫПОЛНЕНИЕ (роль: Исполнитель):
Для каждой операции из плана:
1. Сгенерируй код/инструкции для выполнения
2. Убедись что выход соответствует POST контракту
ШАГ 3 — ПРОВЕРКА (роль: Проверяющий):
После выполнения каждой операции:
1. Проверь выполнены ли POST условия
2. Если нет — опиши:
- Какое условие нарушено
- Что в результате не так
- Как исправить
3. Повтори операцию с исправлениями
4. Ограничение: максимум {N} итераций на операцию
Покажи результаты проверки после каждого шага.
Что подставлять:
- {описание задачи} — твоя многoshаговая задача (обработка данных, трансформации, вычисления)
- {описание данных} — структура таблицы или прикреплённый файл
- {N} — лимит итераций отладки (3-5 для большинства задач)
Формат контрактов:
Можешь использовать формальный или естественный язык. Примеры:
Формальный:
PRE: column="email", type=string, unique=false
POST: column="email", type=string, unique=true, no_nulls=true
Естественный:
PRE: Есть колонка email с возможными дубликатами
POST: Каждый email встречается один раз, пустых значений нет
Выбирай в зависимости от задачи. Для технических задач (API, форматы данных) — формальный точнее. Для бизнес-логики — естественный понятнее.
🚀 Быстрый старт — вставь в чат:
Вот шаблон Governance Contracts для сложных многошаговых задач. Адаптируй под мою задачу: {твоя задача}.
Задай вопросы, чтобы заполнить:
- Какие операции нужны
- Какие контракты (PRE/POST) для каждой
- Как проверять выполнение
[вставить шаблон выше]
LLM спросит про структуру данных, желаемый результат каждого шага и критерии корректности — это нужно чтобы сформировать точные контракты. Она возьмёт паттерн трёх ролей из шаблона и адаптирует под твою задачу.
Ограничения
⚠️ Барьер входа: Метод требует умения структурировать задачу и формулировать формальные требования к данным. Если ты не понимаешь что должно быть на входе/выходе каждого шага — промпт не поможет. Контракты работают только когда ты можешь чётко описать критерии корректности.
⚠️ Не для простых задач: Для одношаговых или простых операций (например, "отфильтруй строки где возраст >18") overhead трёх ролей избыточен. Governance Contracts окупаются на workflow из 3+ зависимых шагов, где ошибка в середине ломает всё.
⚠️ Зависит от качества модели: Проверка контрактов требует способности модели к точному анализу данных. Слабые модели могут "проверять" контракт формально (код запустился = ОК), не понимая логику. На сложных задачах в исследовании даже топ-модели достигали только 60-64% успеха — это лучше чем 46-49% одношаговой генерации, но не панацея.
⚠️ Объём контекста: Длинные цепочки операций с детальными контрактами съедают контекстное окно. Для очень сложных workflow (10+ шагов) может потребоваться разбиение на части или работа в нескольких чатах с передачей промежуточных результатов.
Как исследовали
Исследователи создали DataGovBench — бенчмарк из 150 реальных задач по управлению данными, разделённых на два уровня сложности. 100 operator-level задач — одношаговые операции типа "удали дубликаты", "приведи даты к формату", "заполни пропуски". 50 DAG-level задач — многошаговые workflow из 3-5 зависимых операций, как в примере выше. Все задачи взяты из реальных данных Statista — туризм, e-commerce, спорт.
Ключевая фишка бенчмарка — reversed-objective методология для генерации "грязных" данных. Вместо ручного добавления мусора они инвертировали задачу: если оригинальная задача "удалить дубликаты email", reversed задача "добавить дубликаты email реалистичным способом". LLM генерировала код для создания шума, имитирующего реальные проблемы данных. Это дало измеримый и воспроизводимый бенчмарк.
Протестировали 20 моделей — GPT-5, o1, o3, Claude-4, DeepSeek-V3, Gemini, Qwen и другие. Измеряли три метрики: CRR (Code Runnable Rate) — процент кода который запускается без синтаксических ошибок, TSR (Task Success Rate) — процент задач решённых полностью правильно, ATS (Average Task Score) — средний балл качества даже для частично верных решений.
Главное открытие: огромный разрыв между "код работает" и "задача решена". GPT-5 на сложных DAG-задачах показал 86% CRR (код запускается) vs 46% TSR (задача решена правильно). Почти половина синтаксически корректного кода логически неверна — типичные проблемы: потеря промежуточных результатов, несоответствие типов между шагами, финальный output не удовлетворяет требованиям. На простых задачах разрыв меньше (85% CRR vs 49% TSR), но всё равно критичен.
Затем разработали DataGovAgent и сравнили с baseline'ами: прямая генерация топ-моделями и два мультиагентных фреймворка (ChatDev, CAMEL). DataGovAgent с GPT-5 поднял TSR с 49% до 64% на простых задачах (+15 п.п.) и с 46% до 60% на сложных (+14 п.п.). При этом радикально сократил Average Debug Iterations — среднее число попыток отладки — с 14.9 до 3.3 раз по сравнению с ChatDev.
Почему такой эффект? Governance Contracts устранили основную причину ошибок — рассогласование между шагами. Вместо "генерируй весь код сразу и надейся что сработает" система явно проверяет каждое сочленение: выход шага 1 → вход шага 2. При несоответствии автоматически вставляет "ремонт" (type casting, заполнение nulls). Проверяющий после выполнения знает ЧТО проверять (post-условия), не гадает "а всё ли правильно" — это даёт целевой feedback вместо общих фраз "что-то не работает".
Интересно: лидеры среди open-source моделей (DeepSeek-V3) на сложных задачах сравнялись с топ закрытыми (o4-mini) — обе показали 56% TSR на DAG-задачах, обогнав GPT-5 (46%). Это значит для data governance качество reasoning важнее чем размер модели — хорошая архитектура генерации кода компенсирует недостаток параметров.
Адаптации и экстраполяции
🔧 Техника: Упрощённые контракты для нетехнических задач
Governance Contracts изначально сформулированы для data science, но принцип применим к любым многошаговым задачам. Для нетехнических применений убери формальную терминологию — оставь суть "что должно быть до, что гарантируется после".
Пример: подготовка аналитической записки
Задача: Написать аналитическую записку о рынке онлайн-образования для инвесторов (3-5 страниц).
Используй упрощённые контракты:
ПЛАНИРОВАНИЕ:
Разбей на части. Для каждой части опиши:
- ДО: какая информация нужна на входе
- ПОСЛЕ: что должно быть готово, критерии готовности
Моё видение структуры:
1. Executive summary
2. Размер и динамика рынка
3. Ключевые игроки
4. Тренды
5. Риски и возможности
Построй план с контрактами для каждой части.
ВЫПОЛНЕНИЕ:
Пиши последовательно. После каждой части — проверь выполнены ли ПОСЛЕ-условия.
ПРОВЕРКА:
В конце каждой части спроси себя:
- Выполнен ли контракт этой части?
- Готов ли результат для следующей части?
Если нет — опиши что не так и доработай.
В ответе модель создаст контракты типа:
Часть 1 (Executive summary):
ДО: готовы части 2-5 с ключевыми цифрами и выводами
ПОСЛЕ: 1 страница, содержит главные тезисы каждой части, читается за 3 минуты, понятна без контекста
Часть 2 (Размер рынка):
ДО: определены метрики (GMV, число пользователей, CAGR)
ПОСЛЕ: есть цифры за последние 3-5 лет, динамика понятна, источники надёжные
Это структурирует работу и предотвращает ситуацию "написал 4 части, а финал не вяжется с началом".
🔧 Техника: Контракты для проверки логики аргументации
При построении аргумента в тексте/презентации/питче используй PRE/POST для проверки логических связей.
ЗАДАЧА: Обосновать запуск нового продукта
Построй аргументацию с контрактами:
Аргумент 1: "Рынок растёт"
POST: доказано что рынок растёт минимум 20% год к году
Аргумент 2: "Мы можем захватить долю"
PRE: доказан рост рынка (из аргумента 1)
POST: доказано наше конкурентное преимущество + оценка achievable market share
Аргумент 3: "Это прибыльно"
PRE: доказана achievable market share (из аргумента 2)
POST: доказана unit-экономика + break-even точка
Проверь: POST каждого аргумента удовлетворяет PRE следующего?
Если нет — укажи разрыв и заполни.
Модель проверит логические скачки и скажет если аргумент 2 опирается на данные которых нет в аргументе 1.
🔧 Техника: Debugging Loop для итеративной доработки
Роль Проверяющего можно использовать отдельно — для итеративного улучшения любого результата.
ТЫ — Проверяющий. Твоя задача: найти нарушения контракта и дать целевой feedback.
КОНТРАКТ (критерии успеха):
{твои критерии — конкретные, измеримые}
РЕЗУЛЬТАТ:
{то что проверяем}
ИНСТРУКЦИЯ:
1. Проверь каждый критерий из контракта
2. Для нарушенных критериев:
- Опиши ЧТО именно не так (конкретно, с примерами)
- Объясни ПОЧЕМУ это нарушает контракт
- Предложи КАК исправить (targeted fix, не "переделай всё")
3. Выведи список:
✅ Выполнено: ...
❌ Нарушено: [критерий] — [что не так] — [как исправить]
Не исправляй сам — только feedback.
Это превращает модель в code reviewer для любого контента. После получения feedback попроси исправить только нарушенные части — это эффективнее чем переделывать с нуля.
Ресурсы
DataGovBench: Benchmarking LLM Agents for Real-World Data Governance Workflows — Zhou Liu, Zhaoyang Han, Guochen Yan, Hao Liang, Bohan Zeng, Xing Chen, Yuanfeng Song, Wentao Zhang — Peking University, ByteDance
Упоминания: - DCAI (2025) — curated library of data governance operators (библиотека операций для retrieval) - Statista (2025) — источник реальных данных для бенчмарка