Нейросети для аналитика данных: от выгрузки до дашборда

Нейросети для аналитика данных ускоряют почти каждый этап работы: пишут SQL по описанию задачи, чистят выгрузку в pandas, подсказывают статистический тест, собирают черновик дашборда и переводят выводы на язык руководителя. Но у этой скорости есть цена. Модель уверенно выдаёт числа, которые не посчитаны, и запросы, которые работают, но отвечают на другой вопрос. Аналитик, который это понимает, получает ускорение в разы, а тот, кто не понимает, — отчёт с ошибкой в ключевой цифре.

В статье — рабочий процесс от сырой выгрузки до дашборда с правилами, которые не дают модели ошибаться молча. Готовые инструкции для агентов — работа с датасетами, SQL и Python, оценка моделей — собраны на полке скиллов для аналитика данных.

Главное правило: модель пишет код, а не считает

Языковая модель, которая «читает» таблицу и называет среднее, не вычисляет его. Она порождает правдоподобное число — иногда точное, иногда отличающееся на 5%, иногда просто выдуманное. На таблице из 20 строк ошибку легко заметить, на выгрузке из 50 000 — нет. Поэтому первое правило аналитика: любая цифра в выводах должна быть результатом выполненного кода, а не текста модели.

На практике это означает выбор инструмента. В чатах ChatGPT и Claude есть режим анализа данных, где модель пишет код на Python и выполняет его в изолированной среде — результат виден вместе с кодом. Агенты в терминале вроде Claude Code или Codex CLI делают то же самое на вашем компьютере: пишут скрипт, запускают, смотрят на результат и исправляют. Обычный чат без выполнения кода подходит для написания запроса или скрипта, который вы запустите сами, но не для получения цифр.

Второе правило вытекает из первого: сначала описание данных, потом выводы. Попросите модель перечислить столбцы, типы, число строк, долю пропусков и диапазон дат. Если она ошиблась уже здесь — неверно прочитала разделитель или приняла дату за строку, — дальше верить ей нельзя. Эта проверка занимает минуту и отсекает половину будущих ошибок.

SQL: как получать запросы, которые не врут

Модели пишут SQL хорошо, если знают схему. Без схемы они придумывают названия таблиц и полей, и запрос падает — это самый безопасный сценарий. Хуже, когда названия угаданы правильно, а связи нет: соединение по неверному ключу размножает строки, и выручка в отчёте вырастает в 3 раза. Поэтому в промпт всегда передаются DDL нужных таблиц, диалект СУБД и 3–5 строк примера данных без персональной информации.

Обратите внимание на три детали. Бизнес-определение метрики («выручка — только оплаченные заказы») записано явно, иначе модель выберет своё. Часовой пояс указан, иначе заказы на границе месяца уйдут не туда. И есть контрольный запрос: сумма по месяцам должна совпасть с общей суммой — это ловит задвоение и потерянные строки за 10 секунд.

Ещё три частые ошибки моделей в SQL: деление целых чисел, которое даёт 0 вместо 0,37; COUNT по полю с NULL вместо COUNT(*) или наоборот; фильтр по дате через BETWEEN с timestamp, который теряет последний день периода. Их стоит прямо перечислить в файле с правилами для агента или в начале чата — модель будет их избегать. Если запрос будет работать регулярно, попросите модель ещё и план выполнения через EXPLAIN с пояснением, где могут быть медленные места.

Очистка и подготовка данных

Очистка — самая трудоёмкая и самая подходящая для модели часть работы. Разные форматы дат в одном столбце, города с опечатками («Калининград», «Калинингад», «г. Калининград»), суммы с пробелами и символом рубля, объединённые ячейки из Excel — модель пишет код для каждого случая быстрее, чем вы найдёте нужную функцию в документации pandas.

Главный риск очистки — тихое изменение данных. Модель, которой сказали «приведи названия городов к единому виду», может объединить «Советск» и «Светлый», если сочтёт их опечаткой. Поэтому просите не только код, но и отчёт: сколько строк изменено каждым шагом, какие уникальные значения были до и стали после, сколько строк удалено и почему. Сопоставление «было — стало» для словарных полей стоит просмотреть глазами — это 2–3 минуты, которые спасают от неприятного открытия на встрече с руководителем.

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

Разведочный анализ и статистика

В разведочном анализе модель полезна как генератор гипотез: по описанию данных она предлагает 10–15 срезов, которые стоит посмотреть, и сама строит распределения, корреляции, динамику по периодам. Она не устаёт и не пропускает очевидное вроде проверки выбросов или сезонности. Но интерпретация найденного остаётся за вами — модель не знает, что в марте сменили поставщика, а в июле отключали сайт на три дня.

Со статистикой нужна осторожность. Модели нередко выбирают тест по привычке, а не по данным: t-тест для сильно скошенного распределения выручки, хи-квадрат при слишком маленьких ожидаемых частотах, сравнение десяти групп попарно без поправки на множественные сравнения. Результат выглядит научно, с p-значением и доверительным интервалом, но вывод может быть неверным.

Отдельная ловушка — корреляция, которую модель подаёт как причину. Фраза «клиенты, которые открывали рассылку, покупают в 2 раза чаще» не значит, что рассылка увеличивает продажи: рассылку открывают те, кто и так заинтересован. Просите модель к каждому выводу добавлять альтернативные объяснения — она это умеет, если попросить.

Дашборды, графики и отчёты руководителю

Для разовых графиков модель пишет код на matplotlib или plotly, и за несколько итераций можно получить аккуратный график для отчёта. Просите сразу базовые правила: подписанные оси с единицами измерения, ось Y с нуля для столбчатых диаграмм, не больше 5–7 цветов, заголовок, который формулирует вывод, а не описывает график («Заявки из поиска выросли на 18% после смены посадочной», а не «Заявки по источникам»).

Для дашбордов в BI-системах — Yandex DataLens, Superset, Metabase, Power BI — модель полезна на этапе проектирования. Опишите, кто пользуется дашбордом и какие решения он принимает, и попросите структуру: какие 3–5 ключевых показателей наверху, какие срезы ниже, какие фильтры нужны, какие вопросы пользователь должен получать ответом за 10 секунд. Затем — формулы вычисляемых полей и SQL для витрин. Сам дашборд собираете вы, но проектирование занимает час вместо дня.

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

Хороший анализ проваливается, если руководитель не понял вывод за первые 30 секунд. Модель хорошо переводит результаты с языка аналитика на язык решений: из таблицы на 40 строк и трёх графиков она делает одну страницу по схеме «что обнаружили — почему это важно — что предлагаем — какой риск, если не делать ничего». Цифры для такого текста вы даёте сами из результатов выполненного кода.

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

Какие данные можно отдавать модели

Для большинства аналитических задач модели не нужны сами данные — ей нужна схема. SQL пишется по DDL и описанию полей, код очистки — по примеру из 5–10 строк, в которых реальные значения заменены похожими. Настоящие данные обрабатывает код, запущенный у вас, и тогда персональная и коммерческая информация вообще не покидает компанию.

Если нужен анализ файла в облачном чате, загружайте агрегаты вместо сырых записей: выручку по дням и каналам, а не список заказов с именами и телефонами. Персональные данные клиентов в зарубежном сервисе — это трансграничная передача по статье 12 закона № 152-ФЗ, и с 30 мая 2025 года утечка такой базы обходится организации в штраф от 3 до 15 млн ₽. Для работы с реальными данными в облаке используйте сервис с договором и хранением в России, а доступ агента к базе давайте с правами только на чтение и только к нужным витринам.

Подключить агента к базе данных или к таблицам можно через MCP-серверы — как это устроено, разобрано в гайде MCP: как подключить сервисы к ассистенту. Работа с Excel и Google Таблицами без программирования — в материале работа с документами и таблицами, а если финансовая аналитика тоже на вас, пригодится гайд нейросети для финансиста.

Автор: Артём Беспалов, маркетинговое ИИ-агентство «Термос Беспалова», Калининград.

Источники: закон № 152-ФЗ «О персональных данных» · КонсультантПлюс о штрафах за утечки с 30.05.2025 (проверено 25.09.2026).