Почему LLM – не лучший выбор для анализа данных: две неочевидные причины, о которых обычно молчат

Представьте: вы приходите на конференцию в 2026 и слышите в десятый раз за день фразу «Теперь мы анализируем данные с помощью LLM». Звучит красиво. Модно. И вы даже купили такой курс. Но потом вы тихо спрашиваете себя: но почему у меня все равно ничего не работает?

Я не против больших языковых моделей (они великолепны). Но есть класс задач, для которых они подходят примерно так же, как скальпель для рубки дров. Сегодня я хочу поговорить о двух фундаментальных ограничениях, которые почти никогда не упоминают в курсах «Claude + данные = магия». Оба связаны не с галлюцинациями (это уже стало общественным достоянием), а с самой природой архитектуры генеративных нейросетей.

Мы хотим, чтобы аналитика открыла нам возможности для оптимизации: сделать больше при тех же ресурсах. Больше качественных лидов. Ниже CPL. Выше ROMI. Лучше конверсия. Ради этого строятся четыре слоя аналитики: сбор данных → обработка → хранение → визуализация. Все это нужно бизнесу, чтобы зарабатывать больше и расти быстрее.

Но на практике пока мы полируем данные, дашборды и SQL-запросы, процесс становится самоцелью. «Так принято», «выделили ответственного» – и вот уже мы гордимся не результатом в деньгах, а количеством отчетов.

Десятки и сотни отчетов построены – большинство из них не открывают. А если открывают, то времени их копать катастрофически не хватает. Но по большому счету для роста эффективности маркетинга не нужны отчеты и дашборды. Нужны инсайты – те, что подсвечивают важную динамику, показывают, где утекают деньги или где можно успешно масштабироваться.

Инсайт – это не красивая визуализация и не «интересная корреляция». Это значимая, воспроизводимая закономерность в данных, которая:

Иными словами – это рычаг, который двигает целевую метрику: CPL вниз, ROMI вверх, конверсию в заказ – тоже вверх. Все остальное – просто красиво оформленный шум.

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

И LLM способны неплохо описывать то, что видят в таблицах. Но абсолютно не подходят для поиска инсайтов.

Спойлер:

LLM блестяще справляются с неструктурированными данными – текстами, статьями, диалогами, где объем измеряется страницами или тысячами токенов. Но когда мы переходим к данным в реальном маркетинге, все резко меняется.

Даже у самых продвинутых моделей на сегодня, например у Claude, контекстное окно ограничено размером в 1 000 000 токенов. Это максимум, который нельзя получить в UI, но можно вызвать по API. Звучит внушительно, пока не переведешь в реальные цифры диджитал-маркетинга:

Теперь посчитаем, сколько строк генерирует даже небольшой (!) проект за 12 месяцев: 10+ миллионов строк. Это довольно скромный масштаб компании с бюджетом на маркетинг до 1 млн ₽ в месяц и несколькими источниками трафика.

Смотрите, в LLM влезает 6-9 тысяч строк из десятков миллионов. То есть контекстно окно вмещает в себя менее 0.01% (одной сотой процента) необходимого объема данных. Разрыв более чем в 1000 (!) раз. И это мы с вами не говорим о крупном бизнесе, где счет идет на миллиарды строк данных в год.

И это не «пока не оптимизировали токенизатор» и не «ждем следующую версию». Это фундаментальное, архитектурное ограничение: контекстное окно LLM физически не может вместить необходимый объем исходных маркетинговых данных, с которым мы работаем каждый день.

Конечно, размер доступного контекстного окна будет расти, но вместе с ним растет и количество данных, которые в среднем обрабатывает бизнес.

Если что, агрегация — это когда данные сводят к более высоким уровням обобщения. Условно вместо того, чтобы смотреть на каждую отдельную сессию со всеми ее нюансами, мы считаем суммы, средние и доли по крупным группировкам: дням, кампаниям, устройствам, источникам, регионам и т.д.

Для дашбордов и управленческих отчетов это абсолютный must-have — пытаться глазами проанализировать десятки миллионов строк просто невозможно (и опасно для психики). Но удобство имеет свою цену: при агрегации исчезает огромное количество измерений и деталей.

Давайте посмотрим, как это выглядит на практике.

Теперь давайте агрегируем данные по трем параметрам:

Видите разницу? В изначальных данных в примере у нас 10+ разных измерений (User ID, Medium, Регион, конкретная страница входа, время на сайте и т.д.). При агрегации остаются только три. Все остальное просто исчезает — и вместе с ним часто исчезают настоящие инсайты.

Так вот, чтобы влезть в ограниченное контекстное окно LLM, данные всегда приходится сильно агрегировать. Но именно на этом этапе и происходит главное: агрегация схлопывает детали, а вместе с ними – те самые неочевидные, но критически важные закономерности, которые и являются настоящими инсайтами.

Приведу два простых примера, чтобы показать, как это работает на практике.

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

Это агрегированные данные: в первый день 3 пользователя, во второй день 3 пользователя и в третий день 4 пользователя. Итого 10.
ОК, открываем исходные данные:

Видим, что Антон заходил дважды (во второй и третий день), Петя и Маша тоже дважды. Реальных уникальных пользователей без агрегации всего 7, а не 10. По факту число пользователей завышено на 43%. Условно аналогичная «погрешность» будет ждать вас при подсчете конверсии, цены лида, ROMI и других метрик.

Давайте посмотрим на пример ниже. Две кампании. На первый взгляд все очевидно: бюджет из кампании 1 выводим, в кампанию 2 заливаем:

Теперь чуть понижаем уровень агрегации и смотрим разбивку по устройствам:

Оказывается: в кампании 1 и mobile, и desktop конвертят лучше, чем в 2 в соответствующих сегментах. Просто в кампании 1 значительно больше мобильного трафика, у которого конверсия в принципе ниже (это типичная ситуация для многих рынков).

Это называется «искажение агрегации» или вариация парадокса Симпсона – когда агрегация создает ложную картину, а настоящая закономерность прячется на более детальном уровне.

Подробнее писал об этом и других когнитивных искажениях, которые по определению свойственны человеку, в статье ТОР-10 когнитивных искажений в аналитике диджитал-маркетинга: почему мозг бьет по ROMI молотком [осторожно, здесь еще больше примеров, которые могут взорвать вам мозг!].

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

LLM блестяще воспроизводит паттерны из обучающего корпуса. Но настоящий инсайт – это неожиданное открытие. То, чего в корпусе не было. То, что противоречит предыдущему опыту команды или рынка.

В качестве релевантного примера приведу хакатон, который проводил Андрей Дорожный в Эрмитаже. Американскую нейросеть "попросили" определить, какие предметы изображены на картинах. Она с трудом справлялась, определяла персону, кровать, галстук, вазу, но был один предмет, который она неизменно определяла как пиццу. Но это была не пицца.

Итак, внимание, вопрос! Что это был за предмет?

Подсказка: это как бы класс картин, в каком-то смысле как портрет, натюрморт…

Подождите кликать на скрытое изображение ниже! Подумайте хотя бы 10 секундочек, предположите варианты :)

Отлично! Все дело в том, что в обучающих данных иконы встречались (крайне) редко, а пицца – часто и в очень характерных ракурсах.

Ровно также работают нейросети, LLM в том числе. LLM не умеет систематически искать неожиданное. Она может имитировать поиск неожиданного только в пределах того, что уже видела в похожем виде. А это, конечно, не то, чего мы ожидаем от настоящего интеллектуального анализа данных.

LLM изменили мир текста, кода и идей. Но когда дело доходит до сотен миллионов строк сырых маркетинговых данных и поиска настоящих, неожиданных рычагов роста – их потолок становится слишком очевидным.

Мы с командой с 2022 года строим аналитический движок Thinking Machine (или просто «Машина»). В канале Кузин из Smart Data Hub пишу, как мы строим не универсальный молоток, а узкоспециализированный инструмент, который работает именно там, где LLM физически и концептуально не тянут.