Переизобретая аналитику будущего: как и почему LLM-агенты меняют анализ продуктов, но все не так просто

Привет! AI-агенты — самая горячая тема года и не просто так: это действительно мощная концепция, которая неизбежно заставляет пересматривать устоявшиеся подходы во многих сферах. Одна из самых интересных областей для агентов — аналитика и BI, и последние полгода я активно занимаюсь в том числе этим.

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

Обо всем этом и поговорим.

Давайте разбираться!

Как мы здесь оказались

Появление мощных языковых моделей — это большой прорыв. Они собрали в себе большую часть знаний человечества, недурно умеют писать код, знают много всякой сложной специфики и самый главный их плюс — естественный язык. Концепция же агентов далеко не новая, но именно возможность понимать и хорошо делать работу на простом языке позволила добавлять вокруг LLM интересные технические обвесы и все в конечном итоге получило второе дыхание ^[1] и перешло на новый виток развития.

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

Если LLM работает по схеме промпт-ответ, то в агента мы хотим отправлять задачу и получить решение.

Два слова про аналитику и немного о хорошем

Аналитика — это очень широкий термин. Кто-то изучает финансовые документы, кто-то технические метрики систем, кто-то данные и поведение ^[2] людей — и все они занимаются аналитической работой. Аналитику можно разбивать на разные группы (описательная и прогностическая, целевая или с открытым исходом и тд), но в ней всегда есть место для агентов. Потому что анализ данных это не просто интерпретация данных, а активное взаимодействие с ними: выдвигаем гипотезу, проверяем, делаем выводы и так много раз похожие действия по кругу.

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

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

Итак!

Text2SQL

Хорошие открытые модели (типа Qwen Coder) неплохо пишут SQL. Подаете описание таблиц (как просто полей, так и их смысловое описание), и даже сложные (но не ОЧЕНЬ сложные) запросы с кучей join вполне себе работают. Да, сейчас LLM в зубодробительных или хитрых запросах проигрывают опытным аналитикам, но во-первых, результат можно использовать как шаблон для доведения до ума человеком, а во-вторых, нас в рамках агентов интересует именно сама возможность запрос на человечьем с описанием таблиц и логики превращать в SQL и исполнять его. Это строительный блок.

Что может пойти не так: тяжелые запросы, непонимание бизнес-контекста и неумение составить тот самый сложный запрос, который нам нужен именно сейчас

Vision-аналитика

Мое любимое! С добавлением мультимодальности открылись новые чакры для применения LLM и агентов на их основе. Вот у нас есть будничные дашборды из графаны (например, от нашего большого RAG), их можно скриншотить и передавать в модель. Если правильно запромптить такого агента, дать ему возможность итеративно получать новую инфу (если графиков много), то он может подкинуть интересных мыслей на тему того, а что же это за странный скачок time-to-first-token случается у приложения в 8 утра. Финальный ответ оно вам не даст, но много черновых гипотез для проверки человеком предоставит точно.

Чтобы это хоть как-то завелось, помимо скриншотика придется передать описанией всей системы, паттерны потребления ее пользователями, описание метрики и вообще все, что обычно есть в голове аналитика, который смотрит на такой же график. Без проработки — никак.

И да, vision api — ну очень дорогие.

LLM-based UI и дашборды по запросу

Если огрубить, то основные способа три:

1. Конфигурационный (Agent + Frontend charts)
   Фронт уже умеет строить графики, а на беке запромпчен агент, который знает о возможностях строить воот такие графики и пересобирает конфиг с дашбордом под входящие данные

2. Если уже есть BI-инструмент (типа Metabase/Grafana/Tableau), то собирать под них

3. Полностью писать код на беке для рендеринга на фронте (дорого по токенам, но возможности безграничны)

Да, между просто «данные» и «красивый график» лежит пропасть в виде etl, безопасности, слоев доступа и общего несовершенства данных, но здесь речь именно про то, что можно уникально завизуализировать все, что потребуется. И для несложных данных — это работает.

NLQ (Natural Language Query) над детерминированным анализом

Тот случай, когда все данные уже красиво подготовлены (тут важно, чтобы они влезали в контекст), а затем все общение происходит на естественном языке в виде диалога. Здесь настолько важен размер контекста, что про это стоит написать еще раз. NLQ — очень классно, можно закинуть данные, после чего задавать любые вопросы и просить сделать что угодно.

NLQ требует одновременного «видения» всего датасета, но реальные данные (тысячи+ строк) могут легко превысить контекст даже самых контекстных моделей. И чем больше контекста, тем вероятнее что система сдеградирует от «умного аналитика» до простого чатбота, который может работать только с кусками данных и что-то там пописывает, что похоже на правду, но ей не является.

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

Это прикольно, НО! Здесь есть просто жирнющий недостаток, но об этом мы поговорим сильном позже.

Автономные исследование или анализ

Агенту даются инструменты (API, БД, внешние источники), ставится задача, после чего его «отпускают в свободное плавание» для самостоятельного анализа. Мощная вещь, но здесь критически важно очень четко описать задачу и поставить ограничения (на токены/время/количество инсайтов), у агента всегда есть вероятность провалиться в черную дыру бессмысленных генераций и это будет стоить очень дорого.

Отдельно стоило бы добавить про «подготовку данных», но, скорее всего тут вилка простая: упорядоченный данные или DWH уже есть — и тогда все хорошо, либо их нет — но тогда через все легаси/корпоративщину никакому агенту не продраться. Данные это важно.

Итак.

У нас есть автономность, зрение ^[3], NLQ, и возможность собрать монстр-машину аналитики в виде многоагентной системы, объединяющий все это воедино.

Попробуем?

Agentic Analytics: новая парадигма

Традиционная схема аналитики упрощенно выглядит следующим образом:

1. Поступает задача от бизнеса

2. Ее переводят в техническое представление

3. Затем сбор данных/метрик или сложный SQL

4. Из полученных данных делается дашборд

5. Затем изучение, гипотезы и выводы

   {пункты 2-5 итеративно повторяются}

Так почему бы не замахнуться на перевод этой схемы на агентные рельсы?

На бумаге агенты умеют понимать задачу, писать sql, видеть и строить графички и делать все это автономно. Но реальность такова, что по отдельности — неплохо работает, но целиком не заводится. Что-то получается, выглядит прикольно — да, но это не то.

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

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

Агентные системы — это в первую очередь про инженерию, дисциплину и формализацию.

Почему это сложнее, чем кажется

Когда мне поставили задачу создать агентную систему, которая могла бы сравниться по перфомансу с опытными аналитиками (это долго и сложно и мы ее еще строим), то первым делом я набрал несколько типовых буднично решаемых задач и вместе с несколькими сотрудниками пошел их разбирать.

И вот что оказалось.

Что происходит, когда ты показываешь дашборд со множеством графиков или огромную эксельку с кучей метрик четырем разным людям и просишь вслух их прокомментировать? По шагам, проговаривая каждый этап вслух и задавая одни и те же вопросы?

Они вообще начинают по разному рассуждать! Начинают с разного, где-то пересекаются (не всегда), по разному интерпретируют разные флуктуации данных и приходят к разным выводам. А когда ты просишь формализовать причины, по которым был сделан именно такой финальный вывод, то это вообще сложно свести во что-то единое. Как говорится, кто во что горазд.

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

Все внимание ^[4] мира приковано к интерпретируемости моделей, но у нас вообще нет интерпетируемости выбора людей. И именно это — одна из самых сложных проблем построения агентных систем.

Такая «цифровизация процесса работы» качественно повышает шансы на хороший результат. Но это прям работа и ее результатом может послужить семантический слой.

Семантическое слой — это набор базовых смыслов, понятий и терминов, вокруг которых будет строиться наша аналитическая система. Это как хороший system design для проектов, вот прям его брат-близнец.

Пара примеров:

• для BI: описание и логика ^[5] ключевых метрик типа ARPU, Churn Rate, Retention и как именно они подружены между собой

• для NLQ (nature language query): что такое «неудачные попытки» и как их искать?

• для каталога данных: «активный пользователь» — это тот, у кого была активная сессия или кто выполнил хотя бы одно действие?

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

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

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

Ну наконец-то агентизация!

Если документ составлен, то можно переходить к самому сладенькому, а именно агентизации этого процесса.

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

Как выбрать LLM и фреймворк

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

Но для старта можно взять chatgpt-4o-mini, так как это сразу снимает вопросы инфры, модель достаточно мощная, чтобы задачу вообще сложную решить, и дешевая, чтобы не сжечь на это бюджет маленькой страны. Если вопросов безопасности данных не стоит, то можно сразу кидаться сразу в модель даткой, если есть — ей же нагенерировать аналогичной синтетики.

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

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

Галлюцинации

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

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

Самодельные агенты действительно могут сваливаться в странные галлюцинации (типа качественного придумывания содержимого, которого нет), но чем лучше декомпозирована задача и чем лучше она запромчена, чем лучше валидируется результат, тем надежнее вся система целиком.

Помните я говорил про жирный недостаток NLQ? Гораздо более страшно в LLMках для аналитики то, как легко они переобуваются. Умение обосновать все что угодно, умение смотреть на что угодно под каким угодно углом и стремление всегда угодить пользователю — вот действительно большая проблема языковых моделей.

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

Тяжелый энтерпрайз:

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

Но этой статьи не было бы, если бы все это не работало и не заслуживало внимания.

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

Заменят ли агенты людей? Нет. Точнее, всех точно нет. Но через несколько лет аналитика, скорее всего, будет совершенно другой.

Ждем.

P.S.: мне нравится писать всякое разное, но гораздо приятнее это делать для большего количества людей, поэтому если статья вам понравилась, то можно поддержать мой совсем начинающий канальчик в тг ^[6], в котором мне хотелось бы делиться интересностями

Спасибо!