Привет, Хабр.

Мы в Диасофт развиваем Digital Q.Sensor BI — промышленную BI‑платформу, в которую команда продукта встраивает мультиагентные ИИ‑системы. И поэтому хорошо понимаем, почему вокруг AI‑native аналитики сегодня столько споров.

Сторонники self‑service BI со встроенными LLM обещают бизнесу свободу: дашборд теперь собирает не BI‑разработчик за три недели, а сам аналитик за десять минут — обычным текстовым запросом. Скептики возражают: вместе со свободой компании могут получить сотни несогласованных отчетов, цифры с неясным происхождением и решения, принятые на основе галлюцинаций языковой модели.

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

В дискуссии приняли участие Грачья Алексанян, директор Win Solutions, Мария Филатова, предприниматель и эксперт в сфере цифровых технологий, Александр Фудин, руководитель продукта компании «Севентек», Анастасия Кривцова, операционный директор COMETAL, Данила Петров, руководитель отдела аналитики агентства по работе с Китаем Asia Pacific, а со стороны Диасофт — Данила Ильичев, инженер‑аналитик продукта Digital Q.Sensor BI.

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

Если захотите посмотреть дискуссию целиком — заходите на Rutube.

Кстати, тех, кто дочитает статью до конца, ждет бонус.

Революция без революции или чудо, которое никто не видел

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

Именно на этот этап LLM повлияли сильнее всего. Генерация SQL‑запросов и конфигураций графиков — задача, которую современные модели решают хорошо, а в связке с семантическим слоем — еще лучше. Кто‑то говорит, что все чудесным образом изменилось, но, на мой взгляд, произошло смещение «бутылочного горлышка». Раньше узким местом был весь процесс производства, теперь же саму разработку можно возложить на ИИ, поэтому узким местом становится подготовка данных. При этом она выполняется фактически один раз: единожды настраивается ETL‑процесс и семантический слой, а дальше дашборд по запросу пользователя собирается за минуты. Для важных дашбордов после этого нужна верификация, но даже с ней производство сокращается с двух‑трех недель до часов, максимум одного дня.

Впрочем, эксперты, с которыми я говорил, уверены, что сдвиг начался задолго до трансформеров. Демократизацию аналитики запустили вполне детерминированные инструменты. За последние годы Excel оброс Power Query и Power Pivot, ими овладело огромное количество людей, и практически каждый сотрудник в той или иной степени с их помощью строил свои таблицы. Данные накапливали, анализировали и сопоставляли прямо в подразделениях, потому что инструменты стали доступными, и теперь главное требование — скорость. Правда, вместе с этой доступностью в компании пришли и первые «теневые» пайплайны на VBA и Power Query, живущие вне контроля ИТ.

Если смотреть шире, происходящее сложно назвать революцией. Компании строили self‑service и data‑driven‑команды еще в 2017 году и решали ровно ту задачу, о которой все говорят сейчас: дать бизнес‑пользователю возможность самостоятельно формировать аналитику. Дашборды всегда делал тот, кто работает с данными, вопрос был только в упаковке и доступности инструмента. Примерно с 2016 года в российских компаниях начали выделяться CDO и дата‑офисы, причем зачастую как роль скорее бизнесовая, чем техническая: бизнес‑домены данных, data governance, data quality, мастер‑данные. Так что фундаментально мало что изменилось. Какие вопросы стояли перед аналитиками, такие и стоят, выросли лишь скорость и объемы, а заказчики и сами данные остались прежними.

Добавлю наблюдение, которое вендоры self‑service, включая нас, обычно предпочитают не озвучивать. Да, линейные сотрудники стали чаще строить дашборды в BI‑инструментах, но качество остается под вопросом. По оценкам, звучавшим от экспертов в нашем разговоре, около 80% этих дашбордов — та же поверхностная визуализация табличных данных, которые раньше жили в Excel, а теперь выгружаются напрямую из базы. Настоящие проблемы начинаются там, где источник не один: согласованность данных, единые справочники, единый дата‑слой.

Если сложить все это вместе, картина получается такая: технология сняла ограничение на скорость производства дашбордов, но не сняла ни одного ограничения на качество данных под ними. В этот зазор между «собрать за минуты» и «собрать правильно» и упирается спор о свободе и хаосе.

Автоматизируя хаос, получаем автоматизированный хаос

Свобода self‑service заканчивается там, где начинаются данные. Принцип garbage in — garbage out старше самой дисциплины BI, но LLM добавили к нему существенный нюанс. Раньше мусор на входе давал очевидно некорректный график, а теперь дает аккуратный, грамотно оформленный и убедительно прокомментированный отчет. Стоимость ошибки не изменилась, зато её стало заметно труднее заметить.

В ходе дискуссии от экспертов прозвучала затертая до дыр формула, которая описывает это точнее всего: автоматизируя хаос, мы получим автоматизированный хаос. Поэтому стоит четко разделять две задачи. Собрать дашборд на уже имеющихся данных с помощью ИИ действительно можно за минуты, максимум за день. Но если данных нет, если у компании разрозненные Excel‑файлы, каждый сотрудник ведет учет по‑своему, а финансисты месяц за месяцем собирают P&L вручную, то никакая нейросеть не поможет. Корректное построение отчетности и дашборд как визуализация — разные задачи.

Почему именно регулярная управленческая отчетность так плохо поддается автогенерации, вопрос не риторический. P&L и cash flow опираются на закрытие периода, сверки между учетными системами и учетную политику. Это не запрос к витрине, а согласованный контур из десятков источников, где расхождение в одну проводку разбирают вручную. LLM ускоряет визуализацию, но путь данных до нее не сокращает. Удобнее всего раскладывать это через типы задач: Ad hoc отчет действительно делается за часы, но регулярный P&L в компании с оборотом хотя бы 200–300 миллионов рублей никто не соберет с нуля за неделю‑две, и вопросы будут к данным, а не к дашборду. При этом есть задачи, где ИИ можно применять без подготовки: разобрать организационно‑штатную расстановку на пару сотен человек, проверить гипотезу о перетоке клиентов между каналами. В такие задачи можно передать модели все накопленное, от текстов и PDF до картинок и даже голоса, посмотреть, какое направление она подскажет, а уже потом строить регулярную отчетность. Граница применимости определяется по цене решения, которое будет принято на основе результата.

Здесь важно проговорить то, что мы повторяем на каждой встрече с заказчиками: грязные данные не являются проблемой ИИ. Если аналитик берет некачественные данные из случайной Excel‑выгрузки, плохой дашборд можно собрать и вручную. Когда в компании не настроен процесс получения качественных данных, проблемы будут и с ИИ, и без него. Автоматизируется процесс создания дашборда, а хорошие данные нужны в любом случае. Тормозить внедрение на том основании, что «инструмент новый, значит, и риски от него», — логика знакомая, но ошибочная. Shadow‑аналитика на несогласованных выгрузках существовала и в мире ручной сборки, просто масштабировалась медленнее.

Самая недооцененная часть подготовительной работы — нормализация справочников, классическая задача MDM‑систем. Казалось бы, именно ее языковая модель должна решать легко, ведь сопоставление строк, дедупликация и классификация коротких текстов — хрестоматийные NLP‑задачи. Проблема в том, что модель группирует по семантической близости формулировок, а бизнес‑категории строятся по логике учета, которая в самих формулировках не записана. Простой пример: возьмите товарную номенклатуру из позиций «корм собачий со вкусом свинины», «свинина», «корм со вкусом курицы» и просто «курица». Какова вероятность, что ИИ сложит все это в правильные категории? Взвешенный подход тут выглядит так: там, где анализируются абстрактные понятия и достаточно результата уровня «похоже на правду», ИИ хорош и без нормализации. Но когда категории жестко заданы бизнесом, нормализацию придется прорабатывать вместе с моделью под контролем человека. Отказываться от ИИ в этой работе тем не менее не стоит: данных много, и это, возможно, единственный путь к дашбордам, которые отражают реальную картину.

Из всего этого следует вывод, неожиданный для сторонников «аналитики без аналитиков». Специалисты, которые раньше настраивали BI, никуда не ушли. Они работают на том уровне данных, куда обычного пользователя допускать нельзя, иначе он создаст дубли и разрушит то, на чем все держится. Компании за последние годы серьезно выросли в управлении данными: справочники, семантические слои, единые правила. Демократизация верхнего слоя не упраздняет специалистов по данным, а концентрирует их там, где цена ошибки максимальна.

Есть и хорошая новость: сам фундамент, ETL и семантический слой, тоже перестают быть чисто ручной работой. Мой коллега по Диасофту Виктор Овчинников недавно подробно разбирал на Хабре, как слой обмена данными становится главным тормозом корпоративных ИИ‑проектов. В аналитике действует та же логика, и делегировать модели нужно правильные вещи. Применять ИИ в подготовке данных можно и нужно, только не в формате «вот три таблицы, объедини их». С помощью ИИ настраиваются ETL‑процессы и семантический слой. Показать модели три таблицы и спросить, как они должны соединяться и как их очистить, — работа, которая выполнялась и раньше, просто теперь часть ее можно переложить на машину. ИИ здесь не агент, который чистит данные, а помощник, который вместе с человеком настраивает детерминированные процессы.

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

Почему коммерческому директору нельзя просто «спросить у нейросети»

Допустим, с данными все идеально: витрины собраны, справочники нормализованы, семантический слой описан. Остается интерфейс, и здесь маркетинговое «просто спросите у ИИ» сталкивается с фундаментальным свойством естественного языка. Язык неоднозначен, а метрика точна. Академические бенчмарки text‑to‑SQL вроде Spider и BIRD годами фиксируют одну и ту же картину: даже лучшие системы едва достигают точности человека‑эксперта, и главный источник ошибок не синтаксис SQL, а неверно понятая семантика вопроса. Модель, например, не знает, что именно в какой‑то компании называется «продажами».

Из этого легко развернуть сценарий — сеть из 150 магазинов, коммерческий директор спрашивает у модели, что у него с продажами за вчера. Продажи по категориям, по магазину, по региону? В валовой марже, в себестоимости, со списаниями или без? Руководитель либо получает в ответ длинную серию уточняющих вопросов, либо, что хуже, уверенное «вы продали на полтора миллиарда», а через три итерации выясняется, что это полтора миллиарда в себестоимости, но решения уже приняты. Человеческий мозг лучше работает с визуальной информацией. Специалист один раз разобрался в данных, объяснил, как считаются показатели, и дальше пользователь каждое утро видит красное и зеленое в одном и том же, повторяемом дашборде. Генеративный ИИ, напротив, может выдавать разный результат, вплоть до неуместных смайликов и иероглифов (для мультиязыковых моделей, конечно же).

Индустрия нашла ответ на неоднозначность языка задолго до чат‑ботов. Это семантический слой (в более узком смысле — metrics layer), где определение каждого показателя фиксируется в коде один раз, с формулой, фильтрами и гранулярностью, и переиспользуется всеми потребителями, от дашборда до API. Но кто‑то должен эти определения формализовать, и здесь скрыта ирония: аналитик в этой схеме фактически заменился на промпт‑инженера. Сформулировать для сложного отчета, откуда что брать, как посчитать и какие индикаторы вывести, — отдельная и серьезная компетенция. Фактически мы меняем одного специалиста на другого, с несколько иным набором навыков. Компетенция не исчезла, она мигрировала.

Есть и более глубокая линия скепсиса. Она касается не качества конкретного ответа, а самой возможности встроить генеративную модель в процессы, где решения потом защищают перед советом директоров или регулятором. Механика потери доверия проста: раз использовали, два использовали, а дальше первое же сомнение в цифре, первый вопрос «а как это считалось», и доверие рушится. Какой‑то объем расчетов при работе с ИИ приходится принимать на веру, ведь разматывать всю цепочку вычислений в обратную сторону бессмысленно: чем перепроверять за кем‑то, проще сделать самому. «Черный ящик» никуда не девается. Самая радикальная версия этого скепсиса звучит так: любой генеративный ИИ — это Т9, который просто очень много прочитал. Добиться, чтобы на один и тот же вопрос он несколько раз дал один и тот же ответ, технически невозможно, а когда это станет возможно, перед нами будет уже не генеративный ИИ, а следующий уровень технологий.

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

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

С интерпретируемостью ситуация иная. На уровне весов интерпретации действительно нет: я не знаю ни одного человека, который бы понимал, почему модель предсказала именно тот или иной токен. Я легко могу предположить, что таких людей в мире и вовсе нет. Математика процесса полностью известна, но между ней и реальным осмыслением поведения модели остается уровень абстракции, который пока не поддается содержательному объяснению. Однако для задач аналитики такой уровень объяснимости и не требуется. Я точно так же не понимаю, как работает мозг моих коллег, но это не мешает совместной работе. В устройстве их нейронных связей я не разбираюсь, я проверяю результат по критериям, которые считаю достаточными. Если запрос, написанный нейросетью, можно открыть и прочитать, его можно верифицировать. Требовать от модели большего — значит требовать того, чего мы не требуем ни от одного участника рабочего процесса.

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

Так у меня сложилась формула компромисса: не объяснимая модель, а проверяемые артефакты. Пусть генерация остается вероятностной, важно, чтобы каждый ее продукт ‑от SQL‑запроса до конфигурации графика — был зафиксирован, читаем и воспроизводим как код. Осталось понять, в какой среде это возможно. Спойлер: такая среда уже существовала под нашим носом.

BI как рельсы для ИИ

Среду, где артефакты генерации фиксируются и проверяются, не нужно изобретать. Это и есть BI‑платформа, просто переосмысленная. BI перестает быть приложением только для людей и становится средой выполнения для агентов, где каждый запрос, датасет и график версионируется и доступен для ревью, примерно как код в репозитории.

Поэтому похороны BI, о которых любят писать в презентациях ИИ‑стартапов, откладываются: хоронить предлагали ту часть, которая нужнее всего. BI устарел бы, если бы можно было зайти в чат с любой моделью, написать «нарисуй мне дашборд» и получить готовый результат. Но так не получится: это сложная многоступенчатая задача, и без ограничений модель с ней не справится, ей нужны рельсы. Вне заданных рамок результат генерации непредсказуем, и принимать на его основе бизнес‑решения я бы не стал. Если же задать фреймворк, где графики строятся так, а данные получаются так, у модели остается значительно меньше возможностей для ошибки. Мы в Диасофте не строим обвязку вокруг ИИ. Мы трансформируем существующий BI, который был фреймворком для человека, и встраиваем в него ИИ, способный заместить человека в части задач.

Расскажу, как это выглядит в нашем продукте, поскольку абстракция «рельсов» должна проверяться конкретикой. Ассистенты появились в Digital Q.Sensor BI около полутора лет назад. Они помогали технологу и аналитику писать SQL‑запросы и строить графики: в обоих случаях нужен код, а пользователю удобнее, когда код пишется за него и остается только проверить результат. Сейчас мы перевели продукт на рельсы нашей мультиагентной платформы Digital Q.GPT и сделали агента‑дашбордиста. По запросу пользователя и указанию на источники данных он строит полноценный дашборд: пишет запросы для каждого графика, применяет фильтры, связывает все в цельную картину. Раньше таким коротким путем создавались только простые дашборды, например круговая диаграмма из пары таблиц за десять минут в no‑code‑редакторе, а сложные, с дриллдаунами и нетривиальными фильтрами, поручали разработчикам, и это занимало заметно больше времени. Теперь код полностью делегируется ИИ, за человеком остаются верификация и доводка. Визуальное оформление модели пока дается хуже, его дорабатывает человек, зато функциональность, интерактивность и работа с данными получаются хорошо. Следующий шаг в наших планах — агент, который проверяет целостность данных: анализирует источник и явно сообщает, что вот здесь данные неинтерпретируемые и нужно добавить описания полей.

Ключевой вопрос к такой архитектуре остался из предыдущего раздела: где гарантия, что сгенерированное можно проверить? Ответ заложен в саму конструкцию. Платформа, помимо интерфейса для человека, предоставляет точки подключения для ИИ, и агент работает через те же объекты, которыми раньше оперировал человек. Запросы, датасеты и графики теперь создает нейросеть, но все в той же BI‑системе. Любой график можно открыть и посмотреть, что у него внутри, любой запрос прочитать. Интерфейс классического BI никуда не делся, просто теперь он нужен человеку в том числе для ревью машинной работы. Холст остался тем же, но изменился художник. И ничто не мешает человеку подойти к холсту и дорисовать что‑то самому.

Тот же принцип масштабируется с визуализации на уровень ниже, на пайплайны данных. Здесь, пожалуй, есть самое важное инженерное различие: модель сама решает задачу или модель может написать код, который решит эти задачу за нее. Обработку данных не стоит поручать ИИ напрямую. Ему поручают создать инструмент, пайплайн или ETL‑процесс, который дальше работает сам. Это как в разработке: если мне нужен аналог YouTube, я не прошу модель показывать мне видео, я прошу разработать платформу. Причина в природе языковых моделей: в длинном пайплайне достаточно одной ошибки, чтобы все не работало. Пусть модель один раз построит схему, откуда данные берутся, как преобразуются и куда складываются. Человек ее проверит, и с этого момента схема используется повсеместно, детерминированная и зафиксированная. Недетерминированность генерации перестает быть проблемой, потому что сгенерированный артефакт исполняется уже детерминированно. Весь вопрос в компромиссе между скоростью, когда мы просто все отдаем ИИ, и структурностью, которая дает предсказуемость.

Мне казалось, что такое разделение труда — позиция вендора BI, то есть моя профессиональная заинтересованность. Но в ходе дискуссии BI‑инструменты активнее всех отстаивали как раз те, кто внедряет и развивает именно ИИ. Мне запомнилась метафора с голосовым управлением. Команды в машине, умный дом — все это удобно, но не отменяет того, что сама техника куплена, настроена и работает. Новые способы управления, гибкость, возможность «нарисовать и покрутить» — это про нейросеть. А то, что обрабатывает данные внутри и держит слой единой правды, не позволяя плодить десятки версий одной отчетности, — это BI‑движок. Некорректно говорить, что одно умирает, а второе остается. Руководитель наговорил запрос в телефон, ИИ его понял, BI корректно обработал — вот рабочая связка.

Есть и практический аргумент, который в спорах «BI против ИИ» обычно ставит точку быстрее архитектурных схем, — экономика и безопасность. Почти во всех компаниях есть управленческая и налоговая отчетность, которую не хочется раньше времени показывать вовне. Как только финансовый директор или специалист по безопасности задает вопрос, что нейросеть делает с его данными и куда они уходят, сильные облачные модели отпадают. Локальные слабее по качеству, и встает вопрос стоимости владения. GPU‑инфраструктура требует больших денег на старте, плюс дефицитная и дорогая компетенция MLOps, плюс администрирование, обновления, контроль деградации модели, постоянный бенчмаркинг. По оценкам, звучавшим в дискуссии, собственная ИИ‑инфраструктура обходится в пять‑десять раз дороже классического BI с преднастроенными моделями. С другой стороны, хоть топовыми облачными моделями можно добиваться впечатляющих результатов, но готовы ли корпорации отдать им свои данные, и как эти данные будут использованы в будущем?

Полный запрет внешних моделей, впрочем, тоже не стратегия. Shadow AI устроен так же, как shadow IT, только распространяется быстрее, потому что для него не нужно ничего устанавливать. Показательный случай: одна компания задала внешней модели вопрос про свой ИТ‑бюджет за конкретный период, и модель выдала цифры, которые сотрудники подтвердили как настоящие. Кто‑то уже успел их туда загрузить. Вывод напрашивается сам: раз люди все равно будут пользоваться внешними нейросетями, нужно дать им корпоративные инструменты безопасности — маскирование, шифрование, разделение ролей и полномочий, чтобы работать со сторонними моделями, не разворачивая свою инфраструктуру и не теряя данные. Правда, у маскирования есть ограничение: для персональных данных оно работает хорошо, а вот для полноценной аналитики на числах маскирование почти неприменимо.

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

Человек в контуре: надолго, но в другой роли

Ответ на вопрос «какой человек» проще всего искать в командах, где цена аналитической ошибки особенно наглядна, например в аналитике международных сделок. Опыт таких команд показывает, что ИИ — инструмент одновременно самостоятельный и ведомый. В какую сторону направишь, туда и смотрит. Какой контекст задашь, в том и работает, а не задашь — не заглянет и упустит важное. Поэтому к инструменту должен быть приставлен аналитик, у которого этот общий контекст есть. Главный запрос практиков к технологиям — ускорение сбора и обработки данных, а выводы из них они предпочитают делать самостоятельно.

У инженеров по автоматизации есть классическое наблюдение, сформулированное Лизанной Бейнбридж еще в 1983 году и известное как «иронии автоматизации»: чем надежнее автоматическая система, тем реже человек вмешивается и тем хуже он готов к моменту, когда вмешаться все‑таки придется. К аналитике на LLM это применимо почти дословно. Модели сделали вход в аналитику простым: даже примитивный промпт возвращает данные, которые выглядят объемно и компетентно, а неспециалист не заметит скрытые в них ошибки и передаст их наверх. В будущем инструменты станут лучше и ошибок будет меньше, но звучать результаты будут еще убедительнее. Парадокс, который мне кажется главным прогнозом всей этой истории: чем качественнее генерация, тем дороже человек, способный найти оставшиеся ошибки.

На мой взгляд, роль человека в верификации поменялась. Раньше аналитик был внизу производственной цепочки. Он собирал, а принимал работу кто‑то сверху, ведь если аналитик сделал дашборд, его по‑хорошему должен кто‑то проверить. Теперь дашборд собирает модель, а аналитик поднялся на уровень приемки. Время, которое он тратил на сборку дашбордов, теперь тратит на проверку и более содержательные задачи. Руководитель сможет общаться с системой напрямую, минуя аналитика, только когда будет готов верить ИИ на слово, что данные берутся из нужных источников и отображается именно то, что требуется. Ядро верификации — человек. Если искусственный интеллект верифицирует искусственный интеллект, ни интерпретируемости, ни доверия не возникает. Хотя, возможно, со временем этот взгляд придется пересмотреть.

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

И о доверии — последнее, о чем я много думал после этих разговоров. Сам я доверяю ИИ до определенного предела. В поиске информации, в черновых решениях — да, полностью свою работу — пока нет. Наиболее очевидный риск ближайших лет выглядит так: компании слишком рано сочтут задачу решенной и сократят аналитиков, затем выяснится, что ИИ допустил ошибки, исправлять их некому, и специалистов придется нанимать заново. Индустрия разработки уже прошла через это с генерацией кода. Доверие — не момент времени, а культура. Решили с помощью ИИ одну задачу, потом вторую, потом третью, и когда он начнет стабильно решать задачи компании, можно думать о полном переходе. Human in the loop, по моей оценке, останется с нами на десятилетия, но требования к человеку в контуре будут снижаться. Уже сейчас не обязательно уметь делать дашборды, достаточно уметь проверить за моделью. Готовить данные пока нужно уметь самостоятельно, но, скорее всего, и это будет автоматизировано. А нарабатывать доверие нужно начинать уже сейчас. А ещё лучше, если вы начали уже вчера.

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

Вместо вывода

Свобода или хаос? После всех споров я убежден, что вопрос поставлен некорректно, как и большинство вопросов формата «или/или». Self‑service на LLM дает свободу ровно в той мере, в какой под ним построена инженерия: нормализованные данные, семантический слой, платформа, где каждый сгенерированный запрос можно открыть и прочитать, и человек, который этим правом пользуется. Уберите любой из этих слоев, и та же технология начнет производить хаос, причем быстро, аккуратно и очень убедительно.

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

Если у вас есть свой опыт внедрения LLM в аналитический контур, удачный или неудачный, не стесняйтесь рассказать о нем в комментариях. Особенно интересны случаи, когда self‑service успел создать проблемы до того, как его поставили на рельсы.

Также мы предлагаем протестировать платформу Digital Q.Sensor BI самостоятельно, получив бесплатный дистрибутив на 6 месяцев. Доступ предоставляется всем корпоративным пользователям.