Типичная сцена в небольшой компании: собственник хочет понять, почему выручка в сентябре просела, и пишет бухгалтеру или маркетологу. Ответ приходит через день в виде выгрузки на сорок строк, которую ещё нужно расшифровать. Вопрос простой, путь к ответу — нет. ИИ-аналитика обещает убрать этот путь: вы пишете «покажи продажи по точкам за сентябрь против августа» и получаете таблицу с объяснением. В статье разберём, как это устроено, где подход действительно работает, а где создаёт ложную уверенность.
Что скрывается за словами «ИИ-аналитика»
На практике под этим термином чаще всего понимают связку из трёх вещей: ваших данных (CRM, учётная система, касса, рекламные кабинеты), языковой модели и слоя, который переводит человеческий вопрос в запрос к данным. Модель не «знает» ваши цифры. Она умеет написать SQL-запрос или формулу, выполнить его через инструмент и объяснить результат словами.
Это важное уточнение. Если загрузить в чат таблицу на десять тысяч строк и попросить «посчитай средний чек», модель может ошибиться в арифметике или потерять часть строк. Если же дать ей доступ к базе и инструмент для выполнения запросов, расчёт делает база данных, а модель отвечает только за формулировку запроса и интерпретацию. Второй вариант надёжнее на порядок, и именно он имеется в виду дальше.
Как проходит один вопрос: от фразы до ответа
Чтобы понимать ограничения, полезно видеть цепочку целиком.
- Вопрос. Руководитель пишет в Telegram или в веб-интерфейс: «Какие товары чаще всего возвращали в прошлом квартале и на какую сумму?»
- Понимание схемы. Модель получает описание таблиц: что такое «возврат» в вашей базе, в каком поле дата, как связаны заказы и товары. Без этого описания она будет гадать.
- Генерация запроса. Модель пишет SQL с фильтром по датам и группировкой по товарам.
- Проверка и выполнение. Запрос проходит через ограничения (только чтение, лимит строк, доступ только к разрешённым таблицам) и выполняется в базе.
- Ответ. Модель получает результат и формулирует его: таблица, короткий вывод, при необходимости график.
Самое слабое звено — второй шаг. Если в компании «клиент» в CRM и «контрагент» в 1С — разные сущности, а «выручка» для продаж — отгрузка, а для финансов — оплата, модель выберет одно из толкований и не предупредит. Поэтому до внедрения нужен словарь терминов, его часто называют семантическим слоем: что значит каждая метрика и как она считается.
На какие вопросы ИИ отвечает хорошо
Опыт показывает, что подход даёт больше всего пользы в трёх типах вопросов.
Факты и срезы
«Сколько заявок пришло с сайта за неделю», «какая точка продала больше всего кофе в выходные», «сколько клиентов не делали заказ больше 90 дней». Это запросы с однозначной логикой, модель справляется с ними стабильно.
Сравнения
«Сравни средний чек в мае и июне по категориям» — здесь модель экономит время, которое ушло бы на две выгрузки и сводную таблицу. Главное, чтобы периоды и категории были определены в схеме.
Уточняющие цепочки
Самая ценная часть: можно задавать вопросы последовательно. «Выручка упала на 12%. — По каким категориям? — В этой категории кто основные клиенты? — Когда они последний раз покупали?» Аналитик на такую цепочку потратил бы полдня, система отвечает за минуты.
Где подход буксует
Честный список ограничений важнее списка возможностей.
- Вопросы «почему». Модель покажет, что продажи упали в одном регионе, но причину (ушёл менеджер, конкурент снизил цену) она не знает — этих данных просто нет в базе. Хорошая система скажет об этом прямо, плохая придумает правдоподобное объяснение.
- Грязные данные. Дубли клиентов, незаполненные поля, разные написания одного города. ИИ не чистит данные, он честно считает по тому, что есть. Если в CRM у половины сделок нет источника, отчёт по источникам будет бессмысленным.
- Сложная бизнес-логика. Расчёт маржи с учётом бонусов поставщиков, возвратов и логистики лучше один раз заложить в витрину данных, а не доверять модели воспроизводить его каждый раз.
- Неоднозначные формулировки. «Покажи лучших клиентов» — лучших по выручке, по частоте, по марже? Зрелые системы задают уточняющий вопрос, а не выбирают молча.
Отдельная тема — склонность моделей выдавать уверенный ответ там, где его нет. Как с этим бороться на уровне архитектуры, мы разбирали в статье про галлюцинации ИИ. Для аналитики базовое правило простое: ответ всегда сопровождается запросом, который его породил, и его можно проверить.
Что должно быть готово до внедрения
ИИ-аналитика не заменяет наведение порядка в данных, а делает его обязательным. Минимальный набор:
- Данные собраны в одном месте: база данных или хотя бы набор связанных таблиц. Если сейчас реклама живёт в кабинете, продажи в CRM, а остатки в 1С, сначала стоит собрать их в единую картину.
- Описаны 10–20 ключевых метрик: название, формула, источник. Это и есть словарь для модели.
- Определены права: кто может задавать какие вопросы. Менеджеру по продажам не нужен доступ к зарплатам.
- Решён вопрос с конфиденциальностью: уходят ли данные в облачную модель или используется модель на своём сервере (Qwen, Llama, Mistral).
Варианты реализации: от готовых инструментов до своего агента
Выбор зависит от того, кто будет задавать вопросы и откуда.
Готовые BI-инструменты с ИИ-функциями. Metabase, Power BI и Looker Studio в разных формах позволяют задавать вопросы на естественном языке. Плюс — быстро и без разработки. Минус — ограниченная настройка словаря, не всегда удачная работа с русским языком, привязка к интерфейсу самого инструмента.
Агент в Telegram поверх вашей базы. Руководитель пишет вопрос в бот, получает ответ с таблицей и графиком. Под капотом — модель (Claude, GPT-5 или Gemini), набор инструментов для запросов к базе и описание схемы. Такой агент строится за одну-две недели, если данные уже в порядке. Мы в AiKrok обычно начинаем именно с этого формата: он не требует обучать команду новому интерфейсу, все и так сидят в мессенджере.
Гибрид с утренней сводкой. Фиксированный отчёт приходит сам каждое утро, а вопросы по нему можно задать тут же в чате. Про сам формат сводок есть отдельная статья: ежедневная сводка в Telegram. Этот вариант лучше всего приживается у собственников, которые не хотят каждый день формулировать вопросы, но хотят иметь возможность копнуть глубже.
Пример: дистрибьютор с тремя складами
Компания продаёт стройматериалы, учёт в 1С, продажи в amoCRM, три склада в разных городах. Директор раз в неделю просил менеджера свести остатки и продажи, на это уходило около половины рабочего дня, а цифры регулярно расходились с бухгалтерией из-за разных дат отгрузки и оплаты.
Что сделали: выгрузки из 1С и CRM по расписанию складываются в PostgreSQL, поверх описан словарь из пятнадцати метрик с чётким разделением «отгружено» и «оплачено». Директор задаёт вопросы в Telegram. Типичный диалог: «Какие позиции на складе в Кутаиси лежат без движения больше 60 дней? — Сколько это в деньгах по закупочной цене? — Кто из клиентов покупал их за последний год?» Три вопроса, пять минут, готовый список для обзвона.
Что не получилось сразу: первые две недели модель путала единицы измерения (упаковки и штуки), пока в словарь не добавили правило пересчёта. Это нормальный этап, его стоит закладывать в план.
Как измерять, что система полезна
Ориентиры, которые имеет смысл отслеживать с первого дня:
- Доля вопросов, на которые получен верный ответ с первого раза. Первый месяц это может быть 60–70%, после доработки словаря — заметно выше.
- Сколько вопросов задают в неделю и кто. Если спрашивает только собственник, система не прижилась в команде.
- Время от вопроса до решения. Не до ответа, а до действия: списали неликвид, позвонили клиенту, скорректировали закупку.
Если ответы используются для принятия решений, уместно раз в месяц сверять несколько случайных ответов с ручным расчётом. Это дёшево и даёт спокойствие.
С чего начать
Не нужно начинать с большого проекта. Разумная последовательность выглядит так:
- Выпишите десять вопросов, которые вы задаёте команде чаще всего. Это и будет первый тестовый набор.
- Проверьте, в каких системах лежат данные для ответа на них и можно ли их выгружать автоматически.
- Определите термины: что такое выручка, клиент, заявка, возврат в вашей компании.
- Соберите минимальную версию: одна база, один словарь, один канал (например, Telegram). Прогоните десять вопросов, посмотрите, где система ошибается.
- Расширяйте словарь и источники по мере появления новых вопросов.
Если набор вопросов и систем понятен, но непонятно, как это связать технически, мы готовы разобрать вашу ситуацию на бесплатной консультации. Чаще всего первую рабочую версию можно запустить за две недели — при условии, что данные уже где-то собраны, а не разбросаны по личным таблицам сотрудников.