ML и LLM в аналитике данных: возможности, ограничения и сценарии применения

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

В этой статье рассмотрены два ключевых класса ИИ-систем, с которыми аналитик данных сталкивается чаще всего: машинное обучение (Machine Learning, ML) и большие языковые модели (Large Language Models, LLM). ML опирается на статистику и обучение по историческим примерам — он прогнозирует числа, оценивает вероятности и выделяет сегменты. LLM работает с текстом и контекстом — она понимает формулировки задач и генерирует ответы на естественном языке. Оба класса дополняют друг друга, но требуют разной подготовки данных и разного подхода к внедрению.

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

Машинное обучение (Machine Learning, ML) — это класс систем искусственного интеллекта, при котором система автоматически выявляет закономерности в данных и использует их для прогнозирования, классификации или группировки объектов. В отличие от LLM, ML-модели не генерируют текст: они оперируют числами, категориями и вероятностями, обучаясь на размеченных или неразмеченных исторических наблюдениях. Результат работы модели — конкретное числовое предсказание, вероятность события или принадлежность объекта к сегменту.

На практике ML применяется для широкого спектра аналитических задач. Кластеризация позволяет разделить клиентов, товары или магазины на однородные группы без заранее заданных меток — например, выделить сегменты покупателей по паттернам поведения. Аналитика склонности оценивает вероятность целевого действия: покупки, отклика на акцию или оттока. Аналитика времени до события отвечает на вопрос не «произойдёт ли событие», а «когда оно произойдёт» — например, через сколько дней клиент совершит повторную покупку или покинет сервис. Прогнозирование LTV (Lifetime Value) клиента объединяет несколько задач в одну: оценивает суммарную ценность клиента за весь период взаимодействия с компанией, что критично для маркетингового бюджета и программ лояльности.

Популярность ML в аналитике данных объясняется интерпретируемостью результата и переиспользуемостью. Модель один раз обучена — дальше работа выполняется по регламенту, без участия аналитика. Однако на практике эффективность ML напрямую зависит от качества разведочного анализа, включающего предварительное исследование и подготовку набора данных для обучения модели.

При построении решений на основе ML первой проблемой становится нестабильность результата из-за переобучения. На историческом периоде модель демонстрирует высокую точность, но на текущем наблюдается резкий спад. Кроме того, пропуски в данных, выбросы, некорректные значения — некачественные данные резко негативно сказываются на результате.

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

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

LightGBM ориентирован на скорость: быстрый подбор признаков и гиперпараметров даже на витрине с миллионами строк.

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

CatBoost показывает быстрый результат «из коробки» на типичных табличных данных: категориальные признаки обрабатываются нативно, без ручного кодирования, а модель устойчивее к переобучении. На практике CatBoost принципиально хватает для большинства задач, где за 20% усилий достигается 80% результата.

Продвинутым методом является разбиение прогнозирования на понятные бизнес-компоненты, каждый из которых обслуживается отдельной моделью бустинга. Например, итоговый прогноз продаж строится по формуле: спрос = посетители * вероятность покупки категории * вероятность выбора товара * количество единиц — так видно не только сколько товара будет продано, но и за счёт чего формируется спрос: трафика в точку, конверсии в категорию, выбора конкретного SKU и размера чека. На практике это четыре связанных слоя: прогноз потока клиентов с учётом календаря, сезона и промо; оценка вероятности покупки в категории; распределение спроса между SKU с учётом цены, скидки и наличия; прогноз количества единиц в чеке.

Когда прогноз распадается на четыре связанных модели, одного успешного обучения недостаточно — здесь нужен MLOps (Machine Learning Operations): инженерная практика, которая переносит принципы DevOps на машинное обучение и автоматизирует весь жизненный цикл — от подготовки данных и обучения до развёртывания и сопровождения в продуктиве. MLOps объединяет разработку и эксплуатацию ML-систем: версионирует код, данные и артефакты моделей, оркестрирует многошаговый пайплайн, автоматизирует валидацию и выпуск новых версий в production. Для описанной выше цепочки из четырёх слоёв это означает регламентный пересчёт каждой модели, контроль качества на каждом этапе и прослеживаемость итогового прогноза. В продуктиве непрерывно отслеживаются метрики точности и дрейф данных; при деградации качества или смене промо-механик пайплайн автоматически запускает дообучение — без ручного вмешательства аналитика. Так ML-решение превращается из разового эксперимента в устойчивый сервис, который адаптируется к изменениям бизнеса.

Большие языковые модели (Large Language Models, LLM) — это класс систем искусственного интеллекта, предназначенных для обработки и генерации текста на естественном языке. В основе их работы лежит обучение на больших массивах данных, включающих книги, статьи, документацию, программный код и другие текстовые источники. Благодаря этому модель способна понимать контекст запроса, извлекать информацию из предоставленных данных, рассуждать в рамках поставленной задачи и формировать ответ в удобном для пользователя виде.

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

Популярность LLM объясняется низким порогом входа и универсальностью подхода. Для получения ответа не требуется знание SQL, структуры хранилища данных или особенностей используемых информационных систем. Один и тот же инструмент может использоваться аналитиками, разработчиками и бизнес-пользователями, выступая в роли единой точки доступа к данным и знаниям организации. Однако на практике эффективность такого подхода напрямую зависит от качества предоставленного модели контекста и степени формализации бизнес-логики, что становится особенно заметно при интеграции LLM с корпоративными хранилищами данных.

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

Рекомендуется придерживаться следующего принципа: давайте LLM ровно столько, сколько нужно для решения задачи, и ни больше ни меньше. Таким образом, к запросу «Какой объём продаж в магазине “Дуговой” за 2026 год?» необходимо добавить указания, в какой таблице в хранилище данных лежат факты продаж, как получить идентификатор магазина по его наименованию (возможно, необходимо указать дополнительную информацию для этого, например, регион), учитывать ли НДС, и если да, то нужно ли запросить данные из поля или применить формулу. Эти указания — чисто технические, они могут быть неизвестны аналитику, но если их не указать, числа в отчёте будут далеки от реальности. Более того, их легко забыть, не учесть, рутинно прописывать каждый раз — всё это делает инструмент неудобным в использовании, смещая фокус с решения бизнес-проблем на решение технических.

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

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

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

Построить и поддерживать платформу, предоставляющую весь контекст LLM для решения задач различных ИИ-агентов, позволяет фреймворк от Lasmart —
AI-ready DWH. При подключении любого ИИ-агента результаты останутся воспроизводимыми, точно соответствующими вопросу пользователя, а на пути их достижения будут лежать эффективные SQL-запросы и уточнения от модели в случае неоднозначности инструкций.