1. Начните с конкретных аналитических jobs
Хорошие стартовые задачи: weekly KPI review, variance explanation, cohort cut, funnel diagnosis, campaign QA, dashboard commentary. Не начинайте с обещания «задавайте любые вопросы к данным».
2. Создайте semantic layer
Агент должен знать definitions: Revenue, Customer, CAC, MQL, SQL, NRR, Conversion, Active User. Если metric определяется только из названия столбца, ошибки неизбежны.
3. Зафиксируйте source of truth
Для revenue — Finance/warehouse, для pipeline — CRM, для product behavior — event warehouse. Если источники расходятся, agent должен показать конфликт, а не молча выбрать один.
4. Начните с read-only доступа
Analytics agent обычно не нуждается в write permission. Разрешайте только SELECT/read tools, ограниченные datasets и views. Separate service account упрощает governance и audit.
5. Используйте curated views
Вместо доступа к сотням raw tables дайте verified marts с описанными joins и grain. Это снижает вероятность неправильного соединения данных и ускоряет reasoning.
6. Создайте schema documentation
- Таблица / view.
- Grain.
- Primary key.
- Metric definitions.
- Allowed joins.
- Known data quality issues.
- Refresh cadence.
- Owner.
7. Разделите question → plan → query → result → interpretation
Agent сначала формулирует analytical plan, затем генерирует SQL/queries, выполняет, проверяет output и только потом пишет narrative. Это облегчает review и debugging.
8. Проверяйте SQL до исполнения
Запрещайте destructive statements, unrestricted scans чувствительных таблиц и cross joins без необходимости. Для дорогих запросов добавьте limits, dry run или query cost threshold.
9. Проверяйте результат, а не только запрос
Синтаксически правильный SQL может отвечать не на тот вопрос. Сравнивайте result shape, expected ranges, totals и control queries. Для ключевых use cases храните golden answers.
10. Создайте golden query set
Возьмите 50–200 реальных вопросов и вручную проверенные SQL/results. Это eval foundation. Внутренний data-agent OpenAI, например, описывался как система, где curated question-answer cases и ожидаемые SQL/results используются для защиты качества от регрессий.
11. Оценивайте semantic correctness
12. Отделяйте analysis от causality
Агент может показать correlation и variance, но не должен объявлять причину без design, который поддерживает causal claim. Формулируйте «совпадает с», «вероятная hypothesis», «нужно проверить experiment».
13. Работайте с missing data
Если tracking изменился, segment incomplete или sample мал, agent должен явно указать limitation. Заполнять gap model inference недопустимо.
14. Учитывайте sampling и statistical uncertainty
Для experiments, surveys и small cohorts добавляйте sample size, confidence intervals или хотя бы warning о низком объёме. Не делайте жёсткие conclusions по нескольким наблюдениям.
15. Защитите персональные данные
Не давайте agent PII, если задача решается агрегированными данными. Маскируйте identifiers, ограничивайте row-level access и сохраняйте audit trail. Data minimization — базовая практика.
16. Создайте уровни доступа
17. Добавьте anomaly detection
Agent может автоматически находить deviations от forecast, seasonal baseline или control limits. Но anomaly — сигнал для анализа, а не автоматическое объяснение.
18. Используйте reusable workflows
Weekly business review, funnel validation, campaign reconciliation, cohort retention — encode как repeatable instructions. Это снижает variability по сравнению с ad hoc prompts.
19. Создайте evidence-first answer
Формат ответа: вывод → цифры → query/data scope → assumptions → limitations → suggested next cut. Пользователь должен понимать, откуда взялась рекомендация.
20. Введите drill-down rules
Если KPI отклонён, agent последовательно разлагает его по segment, source, product, geography и time. Но ограничивайте число автоматических cuts, чтобы не создавать ложные correlations из сотен сравнений.
21. Логируйте traces
Question, chosen tables, SQL, tool outputs, final answer, reviewer correction, model/version. Это позволяет воспроизводить ответ и находить regression.
22. Создайте fallback
Если query fails, data stale или ambiguity слишком высока, agent должен остановиться и попросить уточнение. Fallback лучше уверенного неправильного ответа.
23. Human review по уровням риска
Routine KPI commentary может быть automated. Board numbers, financial forecast, customer-level action и high-impact budget recommendations требуют analyst/owner review.
24. Измеряйте продуктивность
Time-to-answer, analyst hours saved, query success, reviewer corrections и adoption. Но экономия времени не должна ухудшать decision quality.
25. Измеряйте quality
- Golden-set accuracy.
- SQL/result correctness.
- Metric-definition adherence.
- Hallucinated data rate.
- Reviewer correction rate.
- High-severity error count.
26. Оптимизируйте cost после baseline
Простые classification/routing и known workflows можно отдавать более дешёвым моделям или rules. Complex diagnosis оставляйте сильной конфигурации. Проверяйте через один и тот же eval.
27. 30-дневный запуск
- Неделя 1: 3 jobs, semantic layer, baseline.
- Неделя 2: read-only prototype и curated views.
- Неделя 3: golden queries, evals, security review.
- Неделя 4: controlled rollout и correction logging.
28. Правила принятия решений (Decision Rules)
- Не давать raw-data access без необходимости.
- Не принимать causal claim из простой correlation.
- Не scale agent без golden eval set.
- Не скрывать stale/missing data.
- Не использовать board/financial numbers без review.
29. Практический пример
Маркетинговые аналитики каждую неделю отвечают на десятки одинаковых вопросов по funnel. Agent получает curated warehouse views и metric dictionary, строит SQL и показывает query вместе с выводом. Golden set включает 120 исторических вопросов. Routine requests уходят к agent, а нестандартные и high-impact analyses — аналитикам. Время ответа сокращается, при этом error rate контролируется evals.
30. Как работать с business questions
Перед SQL agent должен переформулировать запрос пользователя в аналитическую задачу: какая метрика, период, population, comparison и decision. Вопрос «почему упали продажи?» слишком широк. Сначала нужно определить, revenue ли упала, в каком сегменте и относительно какого baseline.
31. Как проверять totals
Каждый сложный запрос полезно проверять контрольной агрегацией: общий revenue за период, row count, number of customers. Если итог неожиданно отличается от dashboard или Finance, agent должен остановиться и выяснить причину до интерпретации.
32. Как работать с изменением схемы
Warehouse evolves: renamed columns, new event taxonomy, migrated CRM fields. Храните schema version и alerts на breaking changes. Production evals должны ловить regressions после data-model updates, а не только после смены модели.
33. Как управлять неоднозначностью
Если пользователь говорит «активные клиенты», а definitions несколько, agent должен уточнить или показать используемое определение. Уверенный выбор скрытой definition создаёт опасную видимость точности.
34. Как строить narrative
Хороший analytical answer разделяет: what happened → where → likely hypotheses → what to check next. Не перегружайте ответ десятками cuts. Выделяйте 1–3 наиболее существенных drivers и прикладывайте supporting data.
35. Как внедрять agent у аналитиков
Сначала используйте его как copilot: analyst видит plan, SQL и result. Затем автоматизируйте repeatable workflows. Полная автономия для high-impact decisions не является обязательной целью; ценность может быть достигнута на уровне ускорения анализа.
Связанные руководства
- Почему дашборды не улучшают решения
- Почему AI не даёт измеримого эффекта
- Дерево выручки
- Как внедрить ИИ-агента для операционного управления кампаниями (Campaign Operations Agent)
- Как внедрить ИИ-агента оптимизации медиа (AI Media Optimization Agent)
- Как внедрить оркестрацию ИИ-агентов (AI Workflow Orchestration)