ИИ для аналитиков: SQL, гипотезы и отчёты

Аналитику часто приносят вопрос без готового технического задания: «Почему просели повторные продажи?», «В каком сегменте растут возвраты?» или «Что показать руководителю на встрече?». ИИ для аналитика полезен на всём пути от такого вопроса до SQL-запроса, проверяемой гипотезы, графика и короткого отчёта. Но это не кнопка «проанализировать всё»: надёжный результат появляется, когда вычисления выполняет база данных или код, а модель помогает ставить вопросы, управлять шагами и объяснять результат.

Разберём три режима работы — чат, агент с инструментами и регулярный аналитический контур — и соберём процесс, в котором можно проверить каждый вывод.

Короткий ответ: где ИИ полезен аналитику

ИИ для аналитика полезен как связующее звено между бизнес-вопросом, кодом и объяснением. Он помогает уточнить метрику, написать и проверить черновик SQL, предложить проверяемые гипотезы, выбрать график и собрать отчёт. При этом точные расчёты выполняет база данных, Python или BI, а аналитик проверяет определения, запросы, допущения и выводы.

Что меняется в работе аналитика

ИИ ускоряет переход между языком бизнеса и языком данных. Руководитель формулирует проблему обычными словами, аналитик уточняет метрику и период, а модель предлагает разрезы, черновик SQL, варианты проверки и форму результата. После выполнения запроса та же модель может превратить таблицу агрегатов в executive summary или объяснить, какой график покажет отклонение без искажения.

Это не отменяет основные обязанности аналитика. Кто-то должен определить, что считается активным клиентом, какая дата относится к продаже, как обрабатываются возвраты и можно ли сравнивать два периода. Модель может увидеть названия orders, customers и refunds, но не узнает внутреннее значение статуса closed_7 без словаря данных.

Полезно разделять роли:

• база данных, Python или BI выполняют точные вычисления;
• ИИ переводит вопрос в план анализа, генерирует код, предлагает гипотезы и объясняет результат;
• аналитик подтверждает определения, проверяет расчёт и отделяет наблюдение от причины;
• владелец процесса решает, можно ли действовать по выводу.

Так анализ данных с ИИ остаётся воспроизводимым: SQL, параметры, входной период и итоговую таблицу можно сохранить и пересчитать.

База выполняет расчёт, а ИИ связывает бизнес-вопрос, запрос, проверку и понятный отчёт.

Три режима: чат, агент и регулярный контур

Чат помогает думать и писать

В простом режиме модель ничего не выполняет в корпоративной базе. Аналитик описывает таблицы, связи и бизнес-вопрос, получает черновик SQL, запускает его в своей среде и возвращает результат в чат. Этот режим подходит для разовой задачи, обучения SQL, поиска возможных разрезов и подготовки текста отчёта.

Например, можно передать схему трёх таблиц и спросить, как сравнить долю повторных покупок по каналам. Модель предложит JOIN, правило определения повторной покупки и группировку. До запуска аналитик проверит, не размножает ли соединение строки и какую дату использует запрос.

Агент выполняет разрешённые действия

Агент отличается тем, что у модели есть инструменты: подключение к базе, среда выполнения кода, файловая система или API. Он может сам прочитать схему, составить SELECT, выполнить его, увидеть ошибку, исправить запрос и сохранить результат. Такой режим нужен, когда анализ состоит из нескольких итераций и его хочется повторять.

Прямой доступ не означает полный доступ. Для аналитического агента создают отдельную роль только для чтения, ограничивают разрешённые схемы и строки, задают лимит времени запроса и журналируют действия. В PostgreSQL read-only transaction запрещает операции изменения данных, а Row-Level Security позволяет ограничивать видимые строки для роли. OWASP также рекомендует давать агентным инструментам минимальные привилегии и оставлять подтверждение человеком для высокорисковых действий.

Регулярный контур работает по расписанию

Третий режим — регламент: например, каждый понедельник проверить продажи за прошлую неделю, сравнить их с медианой восьми предыдущих недель, найти сегменты с отклонением выше заданного порога и подготовить отчёт. Здесь расписание запускает сохранённые SQL-запросы, агент анализирует компактные результаты, а система отправляет JSON, CSV, HTML или ссылку на дашборд адресатам.

Формат и ограничения зависят от BI-платформы. Looker, например, поддерживает разовые и регулярные доставки дашбордов в разрешённые администратором каналы. У push API Power BI есть лимиты на число строк и частоту запросов, а связанный механизм real-time streaming уже помечен Microsoft как готовящийся к выводу. Поэтому фраза «отправить JSON в BI» — это архитектурное направление, а не универсальная команда для любой системы: перед внедрением нужно сверять актуальный API выбранной платформы.

Что подготовить до первого запроса

ИИ для аналитики начинает ошибаться не только из-за модели. Чаще не хватает контекста, который сотрудники передают друг другу устно. До запроса соберите короткую карточку анализа:

1. Решение. Что изменится после отчёта: бюджет, приоритет сегмента, работа с возвратами или только следующий этап исследования.
2. Метрика. Формула, единица измерения, источник и владелец. Например, повторная покупка — новый оплаченный заказ того же customer_id в течение 90 дней.
3. Период и сегменты. Даты, часовой пояс, канал, регион, продукт и исключения.
4. Схема. Таблицы, ключи, типы полей и направление связей.
5. Контрольные значения. Число заказов, сумма выручки и количество уникальных клиентов за известный период.
6. Формат результата. Таблица, график, JSON, HTML-отчёт или пять строк для руководителя.

Официальная справка по анализу данных в ChatGPT также советует использовать ясные заголовки, одну запись на строку и явно указывать столбцы, расчёты и группировки. Это универсальная рекомендация: даже хороший инструмент не исправляет неоднозначную модель данных автоматически.

Как ИИ помогает писать и проверять SQL

ИИ для SQL полезен как напарник: он быстро создаёт первый вариант, объясняет незнакомую конструкцию, предлагает CTE и помогает найти причину ошибки. Качество запроса резко растёт, если передать не только названия таблиц, но и диалект базы, ключи, определения метрик и ожидаемую форму ответа.

Представим задачу: найти категории, где доля возвратов за последние 30 дней выросла относительно предыдущих 30 дней. Модели нужны определения оплаченного заказа и возврата, поля дат, связь заказа с товаром, правило часового пояса и минимальный объём категории. Без последнего условия в топ могут попасть категории с двумя заказами и одним возвратом.

PostgreSQL показывает план запроса через EXPLAIN. Важно помнить, что EXPLAIN ANALYZE уже выполняет запрос: его применяют осознанно, особенно если запрос не ограничен чтением. Для первого запуска агента полезны отдельная тестовая база или реплика, read-only роль, ограниченный период и небольшой LIMIT там, где он не искажает агрегат.

Как ИИ помогает ставить и проверять гипотезы

Модель хорошо расширяет пространство поиска. Получив схему и первый агрегат, она может предложить проверить канал, регион, тип клиента, задержку доставки, цену или изменение состава ассортимента. Это экономит время на старте, но длинный список догадок ещё не является анализом.

Рабочая гипотеза содержит четыре элемента:

• наблюдение: что именно изменилось и по сравнению с чем;
• возможный механизм: почему фактор может влиять на метрику;
• проверка: какой SQL или эксперимент различит объяснения;
• критерий: какой результат поддержит гипотезу, а какой её ослабит.

Например: «Доля повторных покупок в мобильном канале снизилась на 4 п.п. после изменения срока доставки. Если причина связана с задержкой, падение должно быть сильнее в заказах с доставкой более трёх дней и сохраняться после контроля региона и категории». Агент может написать запросы для сегментов, но аналитик должен проверить полноту данных и не называть корреляцию причиной.

Лучше просить модель ранжировать гипотезы по проверяемости, потенциальному влиянию и стоимости анализа. После каждого запроса сохраняйте не только вывод, но и гипотезы, которые данные не поддержали. Иначе агент будет снова предлагать правдоподобные версии, уже опровергнутые командой.

Почему модель не должна «считать глазами» все строки

Количество строк само по себе ничего не гарантирует: десять тысяч коротких записей и десять тысяч длинных комментариев занимают разный объём. Кроме того, продукты обрабатывают файлы по-разному. Анализ может выполняться кодом, поиском по частям документа или передачей части данных в контекст модели.

Поэтому запрос «прочитай всю таблицу и найди всё важное» не даёт проверяемого результата. Справка ChatGPT предупреждает, что большой, сложный или плохо структурированный файл может быть разобран неполностью, и советует указывать конкретные листы, строки и столбцы. Для точных значений сервис может запускать Python, а код и допущения нужно проверять.

Надёжная архитектура устроена иначе. SQL, Python или BI обрабатывает исходные строки и возвращает профиль данных, агрегаты, аномальные группы и контрольные примеры. Модель получает компактный результат вместе с запросом и метаданными. Она объясняет, что видно в выборке, задаёт следующий вопрос и готовит текст. Если нужно исследовать отдельные записи, агент запрашивает именно их, а не пытается удержать всю базу в диалоге. Подробнее работа с тяжёлыми файлами разобрана в статье «ИИ для анализа данных».

Как превратить SQL-результат в отчёт, график или данные для BI

После выполнения запроса передайте модели сам SQL, период, определения метрик и итоговую таблицу. Попросите сначала перечислить вычисленные факты, затем гипотезы и ограничения. Только после этого формируйте текст для руководителя.

Пример executive summary:

За 1–31 августа доля повторных покупок снизилась с 28,4% до 25,1% относительно июля. 71% снижения приходится на мобильный канал в двух регионах; в этих сегментах одновременно выросла доля доставок дольше трёх дней. Данные показывают связь, но не доказывают причину. Следующий шаг — сравнить клиентов с одинаковой категорией первой покупки и проверить изменение после контроля срока доставки. Расчёт основан на оплаченных заказах без тестовых аккаунтов; 1,8% заказов исключены из-за пустого customer_id.

У такого текста видны период, величина изменения, вклад сегмента, ограничение и следующая проверка. Он полезнее фразы «продажи снизились из-за логистики».

Для графика модель может предложить временной ряд, несколько панелей по регионам или диаграмму «срок доставки — повторная покупка». Аналитик проверяет шкалу, единицы, нулевую точку, порядок категорий и соответствие чисел SQL-выборке. HTML-отчёт удобен, когда нужно объединить текст, таблицу и интерактивные графики в одном файле. Но такой файл тоже должен показывать дату обновления, фильтры и источник данных.

ИИ для BI может подготовить машиночитаемый контракт: названия полей, типы, единицы, период и ключ обновления. Затем обычный интеграционный слой отправляет JSON или CSV через поддерживаемый API, кладёт файл в хранилище либо обновляет таблицу, к которой подключён дашборд. Модель не должна сама придумывать контракт на каждом запуске.

Как автоматизировать цикл и сохранить контроль

Полностью автономный агент может сам предложить гипотезы, выполнить серию запросов и собрать отчёт. Практически полезнее сначала задать ему регламент:

1. Получить свежесть источников и контрольные счётчики.
2. Выполнить только утверждённые SELECT-шаблоны или запросы в разрешённых схемах.
3. Сравнить период с фиксированным baseline.
4. Искать аномалии только в заданных сегментах и при минимальном объёме выборки.
5. Для каждой аномалии сохранить SQL, параметры, число строк и контрольные суммы.
6. Отделить факт, гипотезу и рекомендацию следующей проверки.
7. Отправить отчёт человеку, если порог превышен или качество данных ухудшилось.

Такой процесс можно запускать по расписанию, но стабильность обеспечивают не слова в промпте. Права доступа, запрет записи, таймауты, лимиты стоимости, валидация формата и журнал действий задаются вне модели. NIST AI 600-1 рассматривает измерение и документированный контроль рисков как часть жизненного цикла генеративного ИИ.

Для пилота выберите одну метрику и один сегмент. Сначала запустите процесс параллельно с существующим отчётом, сравните результаты за несколько периодов и зафиксируйте допустимое расхождение. Автоматическую отправку руководителям подключайте после того, как запросы и правила эскалации прошли ручную проверку.

Восемь промптов для аналитика

1. Понять схему. «Вот описание таблиц и связей: [схема]. Объясни зерно каждой таблицы, возможные связи один-ко-многим, риски размножения строк и вопросы, которые нужно уточнить до анализа».
2. Сформулировать метрику. «Нужно измерить [бизнес-показатель]. Предложи точное определение: числитель, знаменатель, период, исключения, единица и контрольные значения. Не пиши SQL, пока не перечислишь неоднозначности».
3. Написать SQL. «Для [диалект БД] создай read-only SQL по этой схеме: [схема]. Цель: [вопрос]. Верни запрос, объяснение каждого CTE, ожидаемое зерно результата и список допущений».
4. Проверить SQL. «Проверь запрос ниже на неверные JOIN, дубли, NULL, границы дат, знаменатели, утечку будущих данных и лишнее сканирование. Предложи контрольные запросы, но не меняй бизнес-определение без вопроса».
5. Поставить гипотезы. «По наблюдению [факт] предложи не более пяти гипотез. Для каждой укажи механизм, SQL-проверку, критерий поддержки, альтернативное объяснение и необходимые данные».
6. Разобрать результат. «Вот SQL, параметры и итоговая таблица. Сначала перечисли только факты, прямо следующие из данных. Затем отдели гипотезы, ограничения выборки и следующие проверки. Не утверждай причинность».
7. Подготовить отчёт. «Сделай executive summary на 120–160 слов: период, главное изменение, вклад сегментов, качество данных, ограничение и следующий шаг. Все числа бери только из приложенной таблицы».
8. Выбрать визуализацию. «Предложи до трёх графиков для [решение аудитории]. Для каждого укажи поля, агрегацию, оси, сортировку, подписи, риск искажения и контрольную таблицу для сверки».

Когда выбрать чат, агента или обычный SQL

ИИ для аналитика особенно полезен там, где нужно переходить между вопросом, кодом и объяснением. Если формула уже стабильна и требуется только пересчитать таблицу, достаточно обычного SQL или ETL. Если неизвестно, какую метрику считать и как интерпретировать результат, ценность модели выше.

FAQ

Может ли ИИ сам написать рабочий SQL-запрос?

Да, если он знает диалект, схему, связи и определения метрик. Первый вариант всё равно нужно проверить на зерно, JOIN, даты, NULL, фильтры и стоимость выполнения. Запускайте его с ограниченными правами.

Нужно ли загружать в чат все исходные данные?

Нет. Для большой базы лучше выполнить SQL или Python рядом с данными и передать модели агрегат, контрольные строки, код и метаданные. Это уменьшает объём передаваемой информации и делает расчёт повторяемым.

Может ли агент самостоятельно искать аномалии?

Может, если ему заданы метрика, baseline, сегменты, минимальный объём, порог отклонения и действие после срабатывания. Без этих правил агент будет находить статистический шум и придумывать слишком много объяснений.

Заменит ли ИИ аналитика?

Он сокращает время на черновой SQL, исследование гипотез, объяснение и оформление. Ответственность за определения, качество данных, причинные выводы и решение остаётся у людей, которые знают процесс.

С чего начать внедрение?

Возьмите один еженедельный отчёт. Сохраните проверенный SQL, словарь метрик и контрольные суммы; затем поручите ИИ объяснять результат и предлагать следующий тест. Ведите анализ в одном рабочем контексте, прикладывайте результаты и превращайте удачную инструкцию в повторяемый сценарий. Подключение к базе и автоматическую доставку добавляйте после проверки прав и результата на тестовом контуре.

Что читать дальше

• ИИ для анализа данных — как работать с большими таблицами, Python и пакетной обработкой.
• ИИ для Excel и Google Таблиц — как выбрать безопасный способ работы с табличными данными.
• Промпты для сводной таблицы — как поставить задачу на группировку и проверить результат.
• ИИ для руководителя — как превращать анализ в решение, не скрывая ограничения данных.

Больше материалов по теме — в разделе «Данные, Excel и аналитика».