Нейросеть закрывает в аналитике не счёт, а всё, что вокруг счёта. Она сводит разрозненные выгрузки к единому виду, переводит вопрос владельца на язык запроса к таблице, разбирает текстовые массивы вроде отзывов и обращений и пишет черновик комментария к отчёту. Сами цифры языковая модель считает ненадёжно, если ей не дать инструмент расчёта: она предсказывает правдоподобный текст, а не выполняет арифметику.
Отсюда простое правило отбора задач: ии для аналитики окупается там, где узкое место — не вычисления, а время на подготовку, объяснение и описание. Ниже — 4 типа задач, которые он реально закрывает, граница между расчётом и пересказом, требования к выгрузке и порядок внедрения на одном отчёте.
4 типа задач, где нейросеть даёт результат#
Первый тип — подготовка. Выгрузки из CRM, кассы и бухгалтерии приходят в разных форматах: где-то дата записана как «01.03», где-то как «1 марта», один и тот же товар назван двумя способами. Модель сводит такие списки к общему виду, находит дубли и показывает строки, которые выпадают из общей логики.
Второй тип — перевод вопроса в запрос. Собственник спрашивает «почему упала выручка в марте», а таблице нужен конкретный срез: по каналам, по товарным группам, по новым и повторным клиентам. Модель раскладывает вопрос на такие срезы и пишет формулу или SQL-запрос, который сотрудник выполняет сам.
Третий тип — разбор текста. Отзывы, переписки менеджеров, причины отказов, комментарии в заявках — массив, который руками читают неделями. Нейросеть раскладывает его по темам, показывает, какая претензия повторяется чаще других, и приводит цитаты-подтверждения. Здесь отдача самая заметная.
Четвёртый тип — описание готового отчёта. По таблице с цифрами модель пишет связный комментарий: что выросло, что упало, где отклонение больше обычного. Черновик экономит время руководителя, но вычитывать его нужно так же внимательно, как текст стажёра в первую неделю работы.
Где нейросеть считает, а где только пишет текст#
Языковая модель подбирает следующий кусок текста по вероятности, а не выполняет вычисление. Поэтому число в ответе выглядит правдоподобно и при этом не сходится с таблицей — чаще всего на суммах по большому списку, на процентах и на сравнении двух периодов.
Рабочая граница проходит так: считает таблица, база или код, а модель формулирует запрос и объясняет результат. Часть сервисов умеет запускать код и получать честную цифру. Один вопрос подрядчику снимает половину неясности: расчёт выполняется кодом или пересказывается моделью по памяти.
Признак проблемы виден без специальных знаний. Сумма частей не сходится с итогом, доли не дают 100 %, в ответе появляется показатель, которого в выгрузке не было. Придуманные значения подаются тем же ровным тоном, что и верные: галлюцинации нейросети в цифрах опаснее, чем в тексте, потому что число перепроверяют реже.
Защита проще, чем кажется: просите не результат, а способ его получить — формулу, запрос, перечень фильтров и период. Формулу проверяют один раз, а дальше применяют повторно каждый месяц. Число из ответа приходится сверять с источником заново при каждом запуске.
Как подготовить данные, чтобы ответу можно было верить#
Требование 1 — одна строка на одно событие: сделка, чек, обращение. Сводные таблицы с объединёнными ячейками и промежуточными итогами внутри модель разбирает плохо: строку «Итого» она принимает за обычную запись и молча учитывает её в расчёте второй раз.
Требование 2 — понятные названия колонок. Поля вида «summa_1» и «status_3» приходится расшифровывать в каждом запросе, а «сумма_с_ндс» и «статус_сделки» читаются сразу. Переименовать поля один раз дешевле, чем спорить с ответами и искать причину расхождения.
Требование 3 — ограниченный объём и явные рамки. Модель удерживает конечный кусок текста за раз, и слишком большая выгрузка вытесняет саму инструкцию. Берите срез: один период, один регион, одно направление. Валюта и правило учёта возвратов должны быть едиными по всему файлу.
К выгрузке приложите короткое пояснение: что означает каждое поле, какие статусы считаются продажей, что делать с отменёнными заказами. Пояснение — часть постановки задачи, и собирается оно по тем же правилам, что описаны в материале про то, что такое промпт.
Порядок внедрения: от одного отчёта к регламенту#
Шаг 1 — взять отчёт, который сотрудник уже собирает руками. Подойдут воронка продаж за месяц, сверка остатков, разбор причин отказов. Ценность именно в том, что готовый результат есть: с ним можно построчно сверить ответ модели и увидеть цену ошибки заранее.
Шаг 2 — прогнать параллельно 3 закрытых периода. Человек делает отчёт как обычно, модель делает свой, расхождения выписываются в отдельный список. За 2–3 недели становится понятно, где она ошибается системно, а где сбой был разовым и связан с формой выгрузки.
Шаг 3 — зафиксировать удачную постановку задачи как шаблон. Рабочий текст запроса вместе с описанием полей сохраняется в общем файле, и следующий отчёт запускается копированием, а не сочинением заново. Без шаблона каждый сотрудник получает свой результат на одних и тех же цифрах.
Шаг 4 — назначить ответственного и заранее описать, что считается сбоем. Например: расхождение с учётной системой больше 1 % или показатель, которого нет в исходной выгрузке. При таком признаке отчёт возвращается к ручной сборке, а шаблон разбирается и правится.
Вывод: с чего начать и чего не ждать от нейросети#
Ждать от модели роли финансового директора не стоит: она не знает вашего учёта, не видит договорённостей с покупателями и не отвечает за последствия. Зато она снимает механическую часть работы — приведение выгрузок к общему виду, чтение больших текстовых массивов, формулировку запроса и первый черновик выводов по готовой таблице.
Разумный первый шаг занимает пару вечеров. Возьмите один регулярный отчёт, выгрузите под него плоскую таблицу с понятными полями, опишите словами, что считать продажей, и попросите не цифру, а формулу. Сверьте результат с ручной версией за 2–3 прошлых месяца и посмотрите на характер расхождений.
Дальше решение принимается по фактам, а не по обещаниям. Если расхождений нет, а времени на сборку уходит вдвое меньше, запрос закрепляется шаблоном и переносится на соседний отчёт. Если цифры плывут, проблема почти всегда в данных, а не в модели: чинить нужно выгрузку, названия полей и правила учёта.