Хорошие стартовые задачи: weekly KPI review, variance explanation, cohort cut, funnel diagnosis, campaign QA, dashboard commentary. Не начинайте с обещания «задавайте любые вопросы к данным».
Агент должен знать definitions: Revenue, Customer, CAC, MQL, SQL, NRR, Conversion, Active User. Если metric определяется только из названия столбца, ошибки неизбежны.
Для revenue — Finance/warehouse, для pipeline — CRM, для product behavior — event warehouse. Если источники расходятся, agent должен показать конфликт, а не молча выбрать один.
Analytics agent обычно не нуждается в write permission. Разрешайте только SELECT/read tools, ограниченные datasets и views. Separate service account упрощает governance и audit.
Вместо доступа к сотням raw tables дайте verified marts с описанными joins и grain. Это снижает вероятность неправильного соединения данных и ускоряет reasoning.
Agent сначала формулирует analytical plan, затем генерирует SQL/queries, выполняет, проверяет output и только потом пишет narrative. Это облегчает review и debugging.
Запрещайте destructive statements, unrestricted scans чувствительных таблиц и cross joins без необходимости. Для дорогих запросов добавьте limits, dry run или query cost threshold.
Синтаксически правильный SQL может отвечать не на тот вопрос. Сравнивайте result shape, expected ranges, totals и control queries. Для ключевых use cases храните golden answers.
Возьмите 50–200 реальных вопросов и вручную проверенные SQL/results. Это eval foundation. Внутренний data-agent OpenAI, например, описывался как система, где curated question-answer cases и ожидаемые SQL/results используются для защиты качества от регрессий.
Агент может показать correlation и variance, но не должен объявлять причину без design, который поддерживает causal claim. Формулируйте «совпадает с», «вероятная hypothesis», «нужно проверить experiment».
Если tracking изменился, segment incomplete или sample мал, agent должен явно указать limitation. Заполнять gap model inference недопустимо.
Для experiments, surveys и small cohorts добавляйте sample size, confidence intervals или хотя бы warning о низком объёме. Не делайте жёсткие conclusions по нескольким наблюдениям.
Не давайте agent PII, если задача решается агрегированными данными. Маскируйте identifiers, ограничивайте row-level access и сохраняйте audit trail. Data minimization — базовая практика.
Agent может автоматически находить deviations от forecast, seasonal baseline или control limits. Но anomaly — сигнал для анализа, а не автоматическое объяснение.
Weekly business review, funnel validation, campaign reconciliation, cohort retention — encode как repeatable instructions. Это снижает variability по сравнению с ad hoc prompts.
Формат ответа: вывод → цифры → query/data scope → assumptions → limitations → suggested next cut. Пользователь должен понимать, откуда взялась рекомендация.
Если KPI отклонён, agent последовательно разлагает его по segment, source, product, geography и time. Но ограничивайте число автоматических cuts, чтобы не создавать ложные correlations из сотен сравнений.
Question, chosen tables, SQL, tool outputs, final answer, reviewer correction, model/version. Это позволяет воспроизводить ответ и находить regression.
Если query fails, data stale или ambiguity слишком высока, agent должен остановиться и попросить уточнение. Fallback лучше уверенного неправильного ответа.
Routine KPI commentary может быть automated. Board numbers, financial forecast, customer-level action и high-impact budget recommendations требуют analyst/owner review.
Time-to-answer, analyst hours saved, query success, reviewer corrections и adoption. Но экономия времени не должна ухудшать decision quality.
Простые classification/routing и known workflows можно отдавать более дешёвым моделям или rules. Complex diagnosis оставляйте сильной конфигурации. Проверяйте через один и тот же eval.
Маркетинговые аналитики каждую неделю отвечают на десятки одинаковых вопросов по funnel. Agent получает curated warehouse views и metric dictionary, строит SQL и показывает query вместе с выводом. Golden set включает 120 исторических вопросов. Routine requests уходят к agent, а нестандартные и high-impact analyses — аналитикам. Время ответа сокращается, при этом error rate контролируется evals.
Перед SQL agent должен переформулировать запрос пользователя в аналитическую задачу: какая метрика, период, population, comparison и decision. Вопрос «почему упали продажи?» слишком широк. Сначала нужно определить, revenue ли упала, в каком сегменте и относительно какого baseline.
Каждый сложный запрос полезно проверять контрольной агрегацией: общий revenue за период, row count, number of customers. Если итог неожиданно отличается от dashboard или Finance, agent должен остановиться и выяснить причину до интерпретации.
Warehouse evolves: renamed columns, new event taxonomy, migrated CRM fields. Храните schema version и alerts на breaking changes. Production evals должны ловить regressions после data-model updates, а не только после смены модели.
Если пользователь говорит «активные клиенты», а definitions несколько, agent должен уточнить или показать используемое определение. Уверенный выбор скрытой definition создаёт опасную видимость точности.
Хороший analytical answer разделяет: what happened → where → likely hypotheses → what to check next. Не перегружайте ответ десятками cuts. Выделяйте 1–3 наиболее существенных drivers и прикладывайте supporting data.
Сначала используйте его как copilot: analyst видит plan, SQL и result. Затем автоматизируйте repeatable workflows. Полная автономия для high-impact decisions не является обязательной целью; ценность может быть достигнута на уровне ускорения анализа.