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

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

Рабочее разделение простое. Модель понимает вопрос и составляет запрос. Считает код. Модель объясняет результат словами. Числа через неё не проходят ни разу.

Почему нельзя считать моделью

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

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

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

Что модель делает хорошо

Переводит вопрос в запрос. «Сколько заказов из Петербурга сорвали срок в прошлом квартале» → готовый SQL. Здесь она сильна: синтаксис знает, структуру таблиц вы дали, а результат проверяется запуском.

Объясняет готовые числа. Получив посчитанную таблицу, пишет осмысленный текст: что выросло, что просело, на что посмотреть. Числа она при этом не трогает — берёт как есть.

Ищет аномалии в описании. Не в данных, а в их описании: несогласованные единицы, поля с разным смыслом в разных выгрузках, дубликаты по смыслу — «СПб» и «Санкт-Петербург».

Пишет разовый скрипт разбора. Достать нужное из кривого файла, привести форматы, склеить источники. Проверяется результатом.

Что она делает плохо

Считает. Любые суммы, доли, отклонения. Даже когда данные перед глазами.

Читает числа с картинки. Диаграмма, скриншот таблицы — значения приблизительные, а выглядят точными. Мультимодальность этого не меняет.

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

Отвечает «нет данных». По умолчанию она достроит недостающее, если не разрешить пустой ответ явно.

Как устроить проверку

Три меры, каждая дешёвая.

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

Считать контрольные величины отдельно. Общее количество строк, сумма по всей выборке. Если они не сходятся с разрезом — что-то отфильтровалось не так.

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

Условие несогласия

Если у вас настроенная витрина и аналитик, который знает данные, модель даст немного: она ускорит написание запроса, но узкое место в такой работе — не запрос, а понимание, что спрашивать.

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

Чего я делать не стал бы

Не стал бы вставлять числа из ответа модели в отчёт без пересчёта. Это самый дорогой класс ошибок: неверное число расходится по презентациям и всплывает через квартал.

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

Не стал бы давать модели доступ на запись в базу. Чтение покрывает всю аналитику, а цена ошибки при записи несоизмерима.

Открытый вопрос

Разделение «модель формулирует, код считает» решает арифметику и не решает главного: правильный ли вопрос задан. Модель составит корректный запрос к неверно понятой задаче, код честно посчитает, и отчёт будет внутренне безупречным.

Поймать это можно только знанием предметной области — то есть тем самым аналитиком, очередь к которому мы и убирали. Похоже, здесь честный предел: ускорить получение чисел можно, а понимание, какие числа нужны, не ускоряется ничем.