ИИ для аналитика данных: что меняется в работе, а что остаётся за человеком

Карта задач: где ИИ помогает, а где нет

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

Слой кода

Здесь модель сильнее всего. Написать запрос по известной схеме, переписать формулу из Excel в pandas, объяснить чужой скрипт, предложить регулярное выражение для разбора адресов — такие задачи хорошо описываются словами, а результат легко проверить запуском. Если код работает и проходит ваши проверки, неважно, кто его написал.

Слой данных

Модель не видит ваших данных, если вы их ей не показали, и не знает бизнес-смысла полей. Она может предложить способы очистки и проверки, но решить, что считать дублем клиента или ошибочной записью, может только человек, который знает процесс. В этом слое модель — консультант, а не исполнитель.

Слой текста

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

• Черновики SQL и Python по описанию задачи и схеме таблиц.
• Объяснение и рефакторинг чужого кода, поиск очевидных ошибок.
• Регулярные выражения, разбор дат, нормализация справочников.
• План проверки датасета: какие поля, какие подозрительные значения, что посчитать.
• Тексты отчётов, резюме для руководства, комментарии к графикам.
• Перевод пояснений и документации на другой язык.

Рамка решения: какую задачу отдавать модели

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

1. 01Результат легко проверить, ошибка дешёвая — отдавайте модели смело: регулярное выражение, форматирование, черновик письма.
2. 02Результат легко проверить, ошибка дорогая — модель пишет, вы обязательно проверяете: запрос для финансового отчёта, расчёт метрики для руководства.
3. 03Результат трудно проверить, ошибка дешёвая — используйте модель для идей, а не для ответов: варианты гипотез, структура исследования.
4. 04Результат трудно проверить, ошибка дорогая — модель только как помощник в рассуждении, решение и расчёт за вами: выводы о причинах, прогнозы для бюджета.

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

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

Подготовка данных: пошаговый процесс

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

1. 01Опишите модели структуру таблицы: поля, типы, несколько обезличенных строк, известные проблемы.
2. 02Попросите план проверки: какие поля проверить на пропуски, дубли, выбросы, неверные форматы.
3. 03Запустите проверки сами и передайте модели только агрегированные результаты: сколько пропусков, какие форматы встречаются.
4. 04Вместе с моделью сформулируйте правила очистки словами и согласуйте спорные с владельцем данных.
5. 05Попросите код, который реализует эти правила, с комментариями к каждому шагу.
6. 06Запустите код на полных данных, посчитайте строки и ключевые суммы до и после.
7. 07Сохраните код и правила рядом — это и есть документация очистки.

Ключевой принцип — просить у модели не очищенную таблицу, а код очистки. Код можно прочитать, прогнать повторно на новых данных и показать коллеге. Таблица, которую модель «почистила» в чате, не воспроизводится, и никто не знает, какие строки она тихо выбросила или изменила.

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

Код: SQL и Python вместе с моделью

Как ставить задачу

Качество кода почти полностью зависит от постановки. Хорошая постановка включает диалект или библиотеку, схему таблиц с ключами, смысл неочевидных полей, определение метрики словами и описание ожидаемого результата: какие колонки и что означает одна строка — клиента, день или заказ. Фраза «одна строка на клиента» сразу задаёт уровень детализации и помогает заметить, если клиент в результате встречается дважды.

Как проверять

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

Пример: переход из Excel в Python

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

Отчёты и выводы: факт отдельно, интерпретация отдельно

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

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

• Факт: метрика изменилась, в каком сегменте и за какой период.
• Гипотеза: возможная причина, явно помеченная как предположение.
• Проверка: какие данные или действия подтвердят или опровергнут гипотезу.
• Решение: что можно делать уже сейчас, а что только после проверки.

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

Пример: еженедельное письмо руководству

Представим условную ситуацию. Каждую неделю аналитик отправляет руководителю короткое письмо о ключевых метриках. Таблица считается проверенным запросом, а модель получает уже готовые цифры и пишет по ним текст: что выросло, что снизилось, на что обратить внимание. В инструкции к модели прямо сказано: не добавлять причин, которых нет в таблице, и помечать любые предположения словом «гипотеза».

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

Типичные ошибки модели и как их поймать

Большинство ошибок модели в аналитике выглядят правдоподобно: запрос выполняется без предупреждений, цифра похожа на правду, текст гладкий. Поэтому важно знать заранее, где искать.

Размножение строк в джойнах

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

Неверная обработка пустых значений

Условие «не равно» не возвращает строки с пустым значением, а среднее считается только по заполненным. Ловится явным подсчётом пустых значений в ключевых полях и вопросом к себе: что означает пустое поле для бизнеса — ноль, неизвестность или ошибку?

Подмена определения метрики

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

Выдуманные таблицы и поля

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

Арифметика «в уме»

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

Границы периодов и часовые пояса

Условие «до последнего дня месяца включительно» для поля с датой и временем теряет события этого дня. Ловится проверкой итогов по дням на стыке периодов; лечится полуоткрытым интервалом и явным указанием часового пояса.

Данные, доступ и безопасность

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

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

• Узнайте, какие сервисы ИИ одобрены в компании и для каких данных.
• Передавайте схему и примеры структуры вместо полных выгрузок.
• Заменяйте имена, телефоны и номера документов на условные значения.
• Не вставляйте в чат ключи доступа, пароли и строки подключения к базам.
• Если сомневаетесь — спросите ответственного за безопасность до, а не после.

Какие навыки становятся важнее

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

1. 01Знание предметной области: что означает каждое поле и как устроен процесс за данными.
2. 02Определения метрик: единые формулы, записанные и согласованные с бизнесом.
3. 03Проверка результата: контрольные суммы, сверка с источником, тесты на крайние случаи.
4. 04Чтение кода: понимать, что делает запрос, даже если писали его не вы.
5. 05Статистическое мышление: отличать случайное колебание от изменения и корреляцию от причины.
6. 06Коммуникация: объяснить вывод так, чтобы им можно было воспользоваться, и честно сказать, где данных недостаточно.

SQL и статистику по-прежнему нужно знать. Без них невозможно заметить, что модель посчитала среднее вместо медианы или забыла про выбросы. ИИ снимает необходимость помнить синтаксис, но не необходимость понимать, что происходит.

Ещё один недооценённый навык — умение сказать «не знаю». Если данных недостаточно для вывода, честный ответ ценнее красивой версии, которую модель охотно сформулирует за вас.

Как встроить ИИ в работу команды

Разовые вопросы в чате дают разовую пользу. Гораздо больше выигрывает команда, которая договорилась, где модель участвует в процессе, а где нет. Например, черновик запроса пишет модель, а ревью делает коллега; текст отчёта готовит модель, а цифры в нём подставляются из проверенной витрины.

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

• Описание ключевых таблиц и связей между ними.
• Определения метрик в том виде, в каком их принимает бизнес.
• Фильтры по умолчанию: тестовые записи, отмены, внутренние клиенты.
• Несколько эталонных запросов, которые точно считают правильно.
• Список известных ловушек в данных: поля, которые часто понимают неверно.

Наконец, договоритесь, как отмечать результаты, полученные с помощью модели, и кто их проверил. Это не формальность: если через месяц цифра вызовет вопросы, важно понимать, откуда она взялась.

Чек-лист аналитика, работающего с ИИ

1. 01Определите, насколько легко проверить результат и насколько дорога ошибка.
2. 02Передайте схему таблиц, типы полей и смысл ключевых значений.
3. 03Запишите определение метрики словами до того, как просить запрос.
4. 04Укажите ожидаемую детализацию результата: что означает одна строка.
5. 05Просите код преобразования, а не готовый результат.
6. 06Сверяйте число строк и итоговые суммы с источником.
7. 07Проверяйте джойны на размножение строк.
8. 08Проверяйте обработку пустых значений и границы периодов.
9. 09Не доверяйте арифметике модели — считайте кодом.
10. 10Отделяйте факт от интерпретации в выводах отчёта.
11. 11Сверяйте цифры в тексте с проверенной таблицей перед отправкой.
12. 12Не отправляйте персональные и чувствительные данные без разрешения.
13. 13Сохраняйте код, правила и определения рядом с результатом.

Термины

• Языковая модель — система, которая генерирует текст и код по описанию задачи; не имеет доступа к вашим данным, пока вы их не передали.
• Контекст — всё, что модель получает вместе с задачей: схема, определения, примеры.
• Гранулярность — уровень детализации результата: что означает одна строка таблицы.
• Контрольная сумма — независимо посчитанный итог, с которым сверяется результат.
• Витрина данных — подготовленная и проверенная таблица для отчётов.
• Обезличивание — замена данных, по которым можно узнать человека, на условные значения.

Итог

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