TL;DR
DAR (Data Agnostic Researcher) — многоагентная система, которая самостоятельно исследует базы данных без явных запросов от пользователя. Вместо реактивного "ответь на мой вопрос" система проактивно формулирует исследовательские вопросы, генерирует и выполняет SQL-запросы, проверяет результаты и пишет отчёты — полностью автономно, от начала до конца.
Классические Text-to-SQL системы ждут конкретного вопроса от человека. Но 90% корпоративных данных остаются неиспользованными — не потому что сложно написать запрос, а потому что никто не знает что спрашивать. Люди не замечают возможности, не видят связи между таблицами, не формулируют гипотезы. Узкое место — не вычисления, а человеческое внимание и инициатива. Пока аналитик думает "а что бы тут проверить?", паттерны остаются скрытыми.
DAR решает это через трёхслойную архитектуру с 9 специализированными агентами: слой инициализации понимает задачу и извлекает метаданные схемы, слой выполнения синтезирует запросы с итеративной валидацией (4 агента с циклами проверки), слой синтеза собирает отчёт с встроенным контролем качества (4 агента с порогами оценки). На тестовом датасете asset-incident DAR завершил полный анализ за 16 минут против 8.5 часов у профессионального аналитика — ускорение в ~32 раза.
Схема метода
СЛОЙ 1: ИНИЦИАЛИЗАЦИЯ (один промпт с разделением ролей)
├─ Research Initiator: парсит задачу → формулирует цели
├─ Meta Extractor: извлекает схему БД → список таблиц, колонок, связей
└─ Plan Generator: создаёт план → последовательность шагов анализа
СЛОЙ 2: ВЫПОЛНЕНИЕ (итеративный цикл, повторяется до валидации)
├─ Query Understanding: цели → queryable компоненты
├─ Query Generation: генерирует SQL → конкретные запросы
├─ Query Execution: выполняет → получает результаты
├─ Query Review: проверяет результат → если плохо, возвращает на Generation
└─ Validation Gate: |Result| > 0 ∧ Error = ∅ → PASS/FAIL
└─ FAIL → обратно к Query Review (max N итераций)
└─ PASS → переход к синтезу
СЛОЙ 3: СИНТЕЗ (итеративный цикл с порогом качества)
├─ Structure Planner: план отчёта → секции, нарратив
├─ Scratch Research: черновик → первая версия находок
├─ Revision Agent: улучшает черновик → связность, полнота
├─ Quality Check: оценка ≥ θ → PASS/FAIL
│ └─ FAIL → обратно к Revision (max J итераций)
│ └─ PASS → финал
└─ Report Composer: собирает финальный отчёт → Markdown
Все агенты работают последовательно, но с условными возвратами.
Пример применения
⚠️ Ограничение применимости: DAR в оригинале работает с SQL базами через BigQuery. Для прямого подключения к корпоративной БД нужен API/код. Но принципы многоагентного исследования применимы к любым данным в чате.
Задача: У тебя CSV с продажами по регионам за год (10 тыс строк: дата, регион, продукт, выручка, менеджер). Нужно найти неочевидные паттерны — не просто "суммы по месяцам", а реальные инсайты: аномалии, связи, риски.
Промпт:
Ты — исследовательская система из 9 специализированных агентов.
Задача: автономно исследовать данные и найти паттерны без моих явных вопросов.
ДАННЫЕ: [прикрепить CSV или вставить sample]
АРХИТЕКТУРА:
Этап 1: ИНИЦИАЛИЗАЦИЯ
- Research Initiator: сформулируй 3-5 исследовательских вопросов на основе структуры данных
- Meta Analyst: опиши схему данных, типы колонок, диапазоны значений, пропуски
- Plan Generator: создай план анализа — какие срезы, группировки, сравнения проверить
Этап 2: ВЫПОЛНЕНИЕ (для каждого вопроса из плана)
- Query Understanding: переведи вопрос в конкретные операции над данными
- Query Generation: опиши что нужно посчитать/сгруппировать
- Query Execution: выполни анализ (ты можешь анализировать данные напрямую)
- Query Review: проверь результат — есть ли инсайт? Если нет, предложи другой угол
- Validation: результат содержит находку? Да → дальше. Нет → вернись к Query Review
Этап 3: СИНТЕЗ
- Structure Planner: план отчёта — какие секции, какая логика
- Scratch Research: черновик находок — опиши паттерны, цифры, контекст
- Revision: улучши черновик — убери противоречия, добавь связность
- Quality Check: оценка 1-10. Если <7 → вернись к Revision (макс 2 итерации)
- Report Composer: собери финальный отчёт в формате:
- Executive Summary (3 главных инсайта)
- Detailed Findings (паттерны с доказательствами)
- Recommendations (конкретные действия)
ВАЖНО:
- Не жди моих вопросов — сам формулируй гипотезы
- Каждая находка должна иметь числовое подтверждение
- Если результат анализа пустой/неинтересный — попробуй другой угол
- Покажи промежуточные шаги каждого агента
Начинай с Этапа 1.
Результат:
Система пройдёт через все 3 слоя, показывая рассуждения каждого агента. В инициализации ты увидишь сформулированные исследовательские вопросы (например: "Есть ли сезонность по регионам?", "Какие менеджеры показывают аномальную динамику?", "Коррелируют ли провалы в продуктах?"). В выполнении — несколько итераций анализа с проверками: если первый срез не дал инсайта, система сама предложит другой угол. В синтезе — структурированный отчёт с конкретными находками, числами и рекомендациями. Промежуточные провалы валидации и ревизии будут видны — система сама корректирует курс.
Почему это работает
Слабость LLM: При запросе "проанализируй данные" модель выдаёт поверхностный обзор — описательную статистику, очевидные суммы, общие слова. Почему? Один промпт = один путь рассуждений. Модель генерирует текст последовательно и не возвращается назад, чтобы переосмыслить подход. Если первый угол анализа оказался неинтересным — поздно, она уже пошла дальше. Нет проверки "а этот результат вообще полезен?", нет второй попытки с другой гипотезой.
Сильная сторона LLM: Модель отлично справляется с ролевыми инструкциями и структурированными рабочими процессами. Когда ты явно задаёшь роль ("ты Query Review агент"), модель фокусируется на этой функции. Когда выстраиваешь цепочку "сделай → проверь → если плохо, вернись" — модель следует этой логике. Multi-turn reasoning (рассуждение через несколько ходов) работает лучше single-shot ответа. Conditional branching (условные ветвления) позволяет модели самостоятельно корректировать курс.
Как метод использует это: DAR разбивает монолитный запрос на специализированные роли с явными условиями перехода. Вместо "проанализируй" даёшь структуру: "Research Initiator формулирует вопросы → Query Understanding переводит в операции → Query Generation создаёт запросы → Query Review проверяет полезность → если результат пустой, вернись к Generation". Каждая роль — узкая задача с чётким входом/выходом. Итеративные циклы с валидацией заставляют модель пробовать разные углы, пока не найдёт инсайт. Quality gates (пороги качества) перед финальным отчётом предотвращают поверхностные выводы. Вместо одного прохода — многоходовая игра с проверками и возвратами.
Рычаги управления:
Число итераций (max N для Query Review, max J для Revision) → уменьши до 1-2 для быстрого первого прохода, увеличь до 5 для глубокого копания. Больше итераций = больше углов анализа, но дольше и дороже.
Порог качества θ → установи 7/10 для быстрого результата, 9/10 для тщательной проработки. Высокий порог заставляет Revision агента несколько раз улучшать отчёт.
Число исследовательских вопросов в Research Initiator → 3-5 для широкого обзора, 1-2 для фокусированного анализа конкретной гипотезы.
Детализация промежуточных шагов → добавь "покажи рассуждения каждого агента" для прозрачности и отладки, убери для компактного финального результата.
Специфика ролей → вместо безликих "Agent A/B" дай конкретные экспертизы: "Risk Analyst" (ищет аномалии), "Growth Strategist" (ищет возможности), "Operations Auditor" (ищет неэффективности). Конкретная роль = острее фокус анализа.
Шаблон промпта
Ты — многоагентная исследовательская система. Автономно исследуй данные и найди паттерны без явных вопросов от меня.
ДАННЫЕ: {источник_данных}
ЦЕЛЬ: {исследовательская_задача}
АРХИТЕКТУРА:
=== ЭТАП 1: ИНИЦИАЛИЗАЦИЯ ===
Роль: Research Initiator
Задача: Сформулируй {N} исследовательских вопросов на основе структуры данных и цели.
Формат вывода: Пронумерованный список вопросов.
Роль: Meta Analyst
Задача: Опиши схему данных — типы полей, диапазоны, пропуски, особенности.
Формат вывода: Таблица или структурированное описание.
Роль: Plan Generator
Задача: Создай план анализа — какие срезы, группировки, сравнения проверить для каждого вопроса.
Формат вывода: Для каждого вопроса → список аналитических операций.
=== ЭТАП 2: ВЫПОЛНЕНИЕ (для каждого вопроса из плана) ===
Роль: Query Understanding
Задача: Переведи исследовательский вопрос в конкретные операции над данными.
Формат вывода: "Нужно: [операция 1], [операция 2], ..."
Роль: Query Generation
Задача: Опиши что именно посчитать/сгруппировать/сравнить.
Формат вывода: Детальное описание расчётов.
Роль: Query Execution
Задача: Выполни анализ (используй свои возможности работы с данными).
Формат вывода: Результаты расчётов, таблицы, статистика.
Роль: Query Review
Задача: Оцени результат — есть ли инсайт? Интересен ли паттерн?
Если НЕТ → предложи альтернативный угол анализа → вернись к Query Generation.
Если ДА → результат валиден, переходи дальше.
Максимум {max_iterations_execution} попыток на вопрос.
=== ЭТАП 3: СИНТЕЗ ===
Роль: Structure Planner
Задача: Спланируй структуру отчёта — секции, логика, порядок находок.
Формат вывода: Outline отчёта.
Роль: Scratch Research
Задача: Напиши черновик отчёта — опиши паттерны с числовыми доказательствами.
Формат вывода: Полный текст черновика.
Роль: Revision Agent
Задача: Улучши черновик — убери противоречия, добавь связность, проверь обоснованность выводов.
Формат вывода: Улучшенная версия.
Роль: Quality Checker
Задача: Оцени отчёт по шкале 1-10 (связность, обоснованность, полнота).
Если оценка < {quality_threshold} → вернись к Revision Agent.
Если оценка ≥ {quality_threshold} → переходи к финалу.
Максимум {max_iterations_synthesis} итераций улучшения.
Роль: Report Composer
Задача: Собери финальный отчёт в формате:
- Executive Summary (3 главных инсайта)
- Detailed Findings (паттерны + числовые доказательства)
- Recommendations (конкретные действия)
ПРАВИЛА:
- Не жди моих дополнительных вопросов — формулируй гипотезы сам
- Каждая находка должна иметь числовое подтверждение
- Покажи работу каждого агента (можешь сворачивать детали, но покажи переходы)
- Если результат анализа неинтересен — Query Review должен предложить другой угол
Начинай с Этапа 1. Работай последовательно через все роли.
Что подставлять:
- {источник_данных} — прикреплённый файл, описание таблиц, или sample данных
- {исследовательская_задача} — что нужно узнать (например: "найти риски в продажах", "понять почему упала конверсия")
- {N} — число исследовательских вопросов (3-5 оптимально)
- {max_iterations_execution} — сколько попыток на один вопрос (2-3 для скорости, 5 для глубины)
- {quality_threshold} — порог качества отчёта 1-10 (7 для быстрого, 9 для тщательного)
- {max_iterations_synthesis} — сколько раз улучшать отчёт (2 оптимально)
🚀 Быстрый старт — вставь в чат:
Вот шаблон многоагентной исследовательской системы. Адаптируй под мою задачу: [твоя задача и данные].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит про источник данных (файл/таблицы/описание), цель исследования (какой бизнес-вопрос решаем), параметры глубины (быстрый обзор или тщательный копание) — это нужно для настройки числа итераций и порогов качества под твою задачу. Она возьмёт многоагентную структуру из шаблона и подставит твой контекст.
Оригинал из исследования
DAR в исследовании реализован через Google ADK (Agent Development Kit) и BigQuery с нативными AI-функциями:
- Agents: LLMAgents (Gemini), Workflow agents (SequentialAgent patterns), Custom agents (BigQuery connectors)
- Reasoning: Chain-of-Thought prompting, ReAct pattern (Reasoning + Acting), self-reflection loops
- Memory: Session services для short-term memory, stage variables для working memory между агентами
- In-database AI:
ML.GENERATE_TEXT,AI.GENERATE,AI.GENERATE_BOOLдля анализа прямо в BigQuery без экспорта данных
Структура из статьи:
Initialization Layer:
├─ Research Initiator (ARI): orchestration, task decomposition
│ └─ Tools: list_table_ids, list_dataset_ids, list_table_info, list_dataset_info
└─ Plan Generator (TPG): synthesizes execution strategy
Execution Layer (4-agent sequential workflow):
├─ Query Understanding (AQU): objectives → queryable components
├─ Query Generation (AQG): SQL with BigQuery AI functions
├─ Query Execution (AQE): runs queries, retrieves results
└─ Query Review (AQR): analyzes failures, generates revised queries
└─ Validation: val = PASS ⟺ |Result| > 0 ∧ Error(Result) = ∅
Synthesis Layer (4-agent workflow):
├─ Structure Planner (ASP): report architecture
├─ Scratch Research (ASR): first-pass synthesis
├─ Revision (ARV): refinement loop
└─ Report Composer (ARC): final Markdown assembly
└─ Escalation Checker: Quality(Report) ≥ θ ⇒ Proceed | < θ ⇒ Return to ARV
Ключевое отличие: Оригинал работает с SQL базами через BigQuery API — автоматически извлекает схемы таблиц, пишет SQL-запросы, выполняет их в облаке, использует нативные AI-функции базы данных для анализа. Это требует код и инфраструктуру.
Что применимо в чате: Сама архитектура многоагентного исследования — разделение на инициализацию/выполнение/синтез, итеративные циклы с валидацией, качественные пороги перед финалом. Ты не можешь подключиться к SQL базе из ChatGPT, но можешь применить эти принципы к CSV/Excel данным или любому контенту, который нужно исследовать.
Адаптации и экстраполяции
🔧 Техника: Конкретные экспертные роли → острее анализ
Вместо безликих "Query Review" и "Revision Agent" дай агентам конкретные экспертизы под тип данных:
Для финансовых данных:
Роль: Risk Auditor (вместо Query Review)
Задача: Ищи аномалии, выбросы, подозрительные паттерны.
Если находка неубедительна → попробуй другой риск-индикатор.
Роль: Compliance Checker (вместо Revision Agent)
Задача: Проверь отчёт на обоснованность — каждое утверждение должно иметь числовое подтверждение.
Для маркетинговых данных:
Роль: Growth Hunter (вместо Query Review)
Задача: Ищи возможности роста — недоиспользованные сегменты, успешные паттерны.
Если паттерн очевиден → копай глубже, ищи неочевидное.
Роль: Narrative Sharpener (вместо Revision Agent)
Задача: Сделай выводы actionable — каждая рекомендация должна содержать конкретное действие.
Эффект: Конкретная роль заставляет модель думать с позиции этой экспертизы, а не абстрактно "улучшить". Bias в нужную сторону.
🔧 Техника: Competitive Analysis → два параллельных агента с разными гипотезами
Добавь соревнование гипотез в Execution Layer:
=== ЭТАП 2: ВЫПОЛНЕНИЕ (модифицированный) ===
Роль: Hypothesis Generator
Задача: Для каждого вопроса сформулируй ДВЕ конкурирующие гипотезы.
Пример: Вопрос "Почему упали продажи?"
Гипотеза A: Сезонность
Гипотеза B: Изменение в ассортименте
Роль: Analyst A (оптимист)
Задача: Проверь гипотезу A — ищи подтверждающие данные, но будь честен с цифрами.
Роль: Analyst B (скептик)
Задача: Проверь гипотезу B — ищи альтернативные объяснения, проверяй устойчивость паттернов.
Роль: Evidence Judge
Задача: Сравни доказательства обеих гипотез. Какая сильнее? Или обе верны частично?
Формат: "Гипотеза X сильнее потому что [числовые аргументы]"
Эффект: Два агента проверяют разные направления параллельно → меньше шанс пропустить важный паттерн. Judge агент синтезирует выводы, избегая confirmation bias (подтверждения первой гипотезы).
🔧 Техника: Progressive Depth → начни с широкого обзора, углубляйся в аномалии
Измени структуру Execution Layer на двухфазную:
=== ЭТАП 2А: ШИРОКИЙ ОБЗОР ===
Роль: Scanner
Задача: Быстрый проход по всем вопросам — поверхностный анализ, базовая статистика.
Цель: Найти 2-3 самых интересных направления (аномалии, сильные паттерны).
Формат: Для каждого вопроса → оценка интересности 1-10 + краткое обоснование.
=== ЭТАП 2Б: ГЛУБОКОЕ КОПАНИЕ ===
Роль: Deep Diver
Задача: Возьми топ-2 направления из Scanner → детальный анализ.
- Разные срезы данных
- Проверка устойчивости паттерна
- Поиск причинно-следственных связей
Максимум {N} итераций на направление.
Эффект: Не тратишь итерации на неинтересные вопросы. Scanner быстро отсекает пустые направления, Deep Diver фокусируется на реальных находках. Экономия токенов + глубже анализ важного.
Экстраполяция: Комбинация с Chain-of-Verification
Добавь CoVe (Chain-of-Verification) в Synthesis Layer для проверки фактов:
=== ЭТАП 3 (модифицированный): СИНТЕЗ С ВЕРИФИКАЦИЕЙ ===
Роль: Scratch Research
[как раньше]
Роль: Fact Extractor
Задача: Извлеки все фактические утверждения из черновика.
Формат: Список "Утверждение → Источник данных"
Роль: Verification Agent
Задача: Для каждого утверждения проверь:
1. Есть ли прямое числовое подтверждение в данных?
2. Нет ли противоречия с другими частями анализа?
3. Корректна ли интерпретация цифр?
Если утверждение слабо обосновано → пометь для удаления или перепроверки.
Роль: Revision Agent
Задача: Используя Verification Agent feedback, улучши черновик:
- Удали слабо обоснованные выводы
- Усиль доказательства для спорных моментов
- Добавь оговорки там, где уверенность низкая
[далее Quality Checker и Report Composer как раньше]
Эффект: CoVe предотвращает hallucinations в выводах. Модель может "придумать" паттерн, который кажется логичным, но не подтверждён данными. Verification Agent ловит это до финального отчёта.
Ограничения
⚠️ SQL базы требуют API/код: Оригинальный DAR работает с SQL базами через BigQuery. Для подключения к своей корпоративной БД нужен Python/API. В обычном чате ChatGPT/Claude можно применить принципы к CSV/Excel данным (загрузи файл в Advanced Data Analysis), но не к производственным SQL базам.
⚠️ Trade-off скорость vs глубина: При увеличении числа итераций растёт вероятность ошибок и противоречий. Исследователи отмечают "sweet spot" — DAR эффективен как инструмент быстрого первого прохода (10-20 минут), но при попытке углубления (больше итераций, более строгие пороги) начинает выдавать слабо обоснованные находки и внутренние противоречия. Для глубокого анализа человек всё равно нужен.
⚠️ Контекстуальная интерпретация — человеческая сила: DAR находит паттерны в данных, но не понимает бизнес-контекст. Человек-аналитик знает про сезонные кампании, изменения в продуктовой линейке, особенности рынка — это позволяет правильно интерпретировать цифры. Система может сказать "выручка упала на 30% в марте", но только человек знает "потому что мы специально приостановили рекламу на редизайн". Используй DAR для первичной разведки, человека — для валидации и интерпретации.
⚠️ Стоимость токенов: Многоагентная система с итеративными циклами = много токенов. Один полный исследовательский прогон с 5 вопросами, 3 итерациями выполнения и 2 итерациями синтеза может сжечь 50-100к токенов (на больших датасетах/сложных задачах). В GPT-4 это $1-2 за прогон, в Claude — аналогично. Для регулярного использования учитывай бюджет.
Как исследовали
Команда из Mantis Analytics взяла реалистичный бизнес-кейс: база данных с двумя связанными таблицами — 26 критических объектов (активы: заводы, офисы, склады с гео-данными, числом сотрудников, контактами) и 11,489 инцидентов (события с временем, локацией, типом, уровнем серьёзности). Типичная задача для BI-аналитики: найти паттерны, риски, аномалии.
Дали одинаковое задание профессиональному аналитику (data analyst + data scientist с опытом) и системе DAR: "Проведи exploratory analysis, найди значимые паттерны, сформулируй actionable insights, напиши отчёт". Никаких конкретных вопросов — полная свобода в подходе.
Замеряли только время: сколько ушло на анализ + написание отчёта. Почему не качество? Потому что ground truth для "правильного анализа" не существует — это творческая задача, где возможны разные углы. Оценка качества требовала бы отдельного масштабного исследования с панелью экспертов. Время — объективная метрика, показывающая главную ценность DAR: ускорение первого прохода.
Результаты удивили масштабом разрыва: Человек потратил 5 часов 45 минут на анализ + 1 час 25 минут на отчёт = 7 часов 10 минут total. DAR завершил всё за 16 минут (15 минут анализ + 1 минута отчёт). Ускорение ~27-32x в зависимости от фазы.
Но цифры не показывают полную картину. Качественное сравнение отчётов выявило complementary strengths: человек дал глубокую интерпретацию с контекстом, нюансами, экспертными суждениями — "почему это важно для бизнеса", "как это связано с отраслевыми трендами". DAR выдал более сухой, но структурированный и evidence-based отчёт — чёткие паттерны, числовые подтверждения, конкретные (хотя и brief) рекомендации.
Ключевой инсайт исследования: DAR не заменяет аналитика, а берёт на себя "первый проход" — быстро сканирует данные, находит что проверить, генерирует гипотезы. Человек подключается на втором этапе — валидирует находки, добавляет контекст, формулирует глубокие выводы. В практических workflows это даёт division of labour: AI делает exploratory grunt work (который раньше съедал 70-80% времени), человек фокусируется на high-value интерпретации и принятии решений.
Ресурсы
Статья: "Beyond Text-to-SQL: Autonomous Research-Driven Database Exploration with DAR"
Код: github.com/MantisAnalytics/DAR (open source)
Данные: kaggle.com/datasets/viktoriaskorik/incidents-dataset
Авторы: Ostap Vykhopen, Viktoria Skorik, Maxim Tereschenko, Veronika Solopova (Mantis Analytics)
Технологии: Google ADK (Agent Development Kit), BigQuery Generative AI, Gemini models