Визуализация данных *

Чем отличается настоящий аналитический агент от генератора SQL, почему семантический слой важнее размера языковой модели и почему локальная LLM ещё не означает технологическую независимость?

В 2026 году AI‑ассистент или AI‑агент появился едва ли не у каждого российского BI‑вендора. Проблема в том, что одинаковая наклейка «AI» скрывает совершенно разные механизмы: где‑то это чат к данным, где‑то генератор SQL, где‑то помощник разработчика дашбордов, а где‑то — мультиагентная система с оркестратором, отдельными ролями и проверкой результата.

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

Как мы исследовали AI‑агентов

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

Задача состоит в следующем: есть некие параметры, часть из которых может быть объединена в каскады, нужно вычислить покрытие параметров, при этом учитывать, что если есть тесты на каскад, в котором присутствует параметр, то параметр считается покрытым.

Видим, что нам необходимо проверять на покрытие именно сущности, а не ветвление, сценарии или код, как это делают, допустим, coverage.py или pytest-cov

Это вторая статья из цикла про прототип Plyra — мой домашний прототип для которого я еще толком не сформулировал класс, но похоже как будто на Smart Knowledge Mesh или по крайней мере фронтенд для него. В первой я рассказывал про существующие проблемы в работе со сложными и запутанными знаниями и то как я пришел к идее прототипа. Здесь я попробую объяснить идею через сравнение с космосом и тому куда в итоге переедет «клубок» запутанности.

Всем привет! Меня зовут Сергей Ронжин, я архитектор CPM/IBP-платформы Optimacros для интегрированного планирования, бюджетирования и бизнес-аналитики. В статье поделюсь своим опытом – расскажу о планировании в FMCG-бизнесе и том, какую цену платят компании, когда допускают ошибки в этом процессе. Чтобы добавить статье пользы, поделюсь практическими советами, как от «планирования ради плана» перейти к «планированию для прибыли». Статья будет полезна моделерам и архитекторам CPM/IBP-решений, а также бизнес-пользователям FMCG-компаний и специалистам по планированию.

Шесть российских RPA‑платформ, более 300 критериев и тысячи страниц документации. В начале исследования мы ожидали увидеть привычный для enterprise‑рынка разрыв между несколькими лидерами и остальными участниками. Вместо этого обнаружили сформировавшееся ядро зрелых платформ, каждая из которых способна работать в крупном корпоративном контуре.

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

В конце июля июля мы опубликовали исследование «RPA Круг Громова 2026». В этой статье расскажу, как мы его делали, какие гипотезы не подтвердились и на что смотреть заказчику, если пункт «умеет создавать программных роботов» уже ничего не объясняет.

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

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

В Инновационном центре «Безопасный транспорт» при ЦОДД интерактивную отчётность и дашборды создают в BI‑системе «Visiology». Платформа позволяет кастомизировать визуализацию, собирая из различных виджетов полноценные отчёты.

Но как из сырых данных создать комплексные интерактивные карты, пригодные для оперативной аналитики? Какие инструменты позволяют вывести многомерную геопространственную информацию на дашборд в браузере пользователя — в реальном времени, без долгой загрузки и потери производительности? В этой статье мы разберём, какие JavaScript‑библиотеки и подходы лежат в основе современных картографических визуализаций, и покажем на примере наших дашбордов, как превратить телеметрию транспорта в наглядные и полезные отчёты.

Подключите OpenSearch Dashboards к Manticore Search, исследуйте данные в Discover и создавайте визуализации и дашборды в знакомом интерфейсе.

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

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

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

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

Всем привет! С вами снова я, тимлид команды разработки «Графини» Павел Мирошин. Надеюсь, вы успели отдохнуть и не слишком грустите по ушедшему лету. Я вот не успел — трудился над новым релизом. Но оно того стоило.

Этот маленький промежуточный релиз с летним вайбом — 2026H1.1 «Салон» — скрывает в себе очень важную и долгожданную фичу: «Алертинг» или, по-нашему, «Оповещения». Мы не стали копировать решение у наших зарубежных коллег, а разработали своё видение этого сервиса.

Под катом обзор этого функционала, а также рассказ о других обновлениях релиза.

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

На Apache Superset я перенёс один отчёт. Одна таблица, пара графиков, день работы. Это была годовая цель: показать, что умею. Пользуются при этом по-прежнему исходной версией в Power BI.

Перенос в компании идёт всерьёз: есть коллеги, которые публикуют на Superset отчёты десятками. И чем ближе отчёт к одной таблице, тем легче он едет. Мои — не такие.

Поэтому я открыл свою самую тяжёлую модель — 22 таблицы, 206 колонок, 86 мер — и прочитал её целиком. Двадцать мер из восьмидесяти шести меняют расчёт в зависимости от того, до какого уровня развернули матрицу: из-за них сверка «итог в итог» после переноса сходится идеально и ничего не доказывает. Шесть производственных договорённостей зашиты прямо в формулы и не описаны больше нигде.

Разбираю, что на самом деле переносится при миграции BI и почему документацию в ландшафте на 800+ отчётов придётся отдавать машине.

Бизнес-вопрос редко звучит как готовая аналитическая задача. Руководитель может спросить: «Какие подразделения требуют внимания?», «Пользуются ли приложением?» или «Почему результат изменился?». В этих формулировках понятен общий интерес, но ещё нет показателей, правил расчёта и структуры будущего отчёта.

Можно сразу выбрать несколько доступных метрик и построить графики. Но тогда система будет отвечать не на исходный вопрос, а на то, что оказалось проще посчитать.

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

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

Маркетолог прислал мне скрин дашборда и одно слово: «пусто».

На скрине — панель «Количество пришедших по реферальной ссылке за период». Ноль. Под ней — график регистраций. Тоже ноль. Ссылка, по которой он пришёл, вела на дашборд с фильтром по конкретному slug — тому самому, который он неделю крутил в закупке.

Я открыл ту же ссылку, поменял в урле from=now-6h на from=now-30d и увидел 16 регистраций.

Дефолтный интервал в Grafana — 6 часов. У бота ночью в этой гео никого нет. Аналитика работала идеально и показывала абсолютно честный ноль.

Это самая безобидная из историй, которые тут будут. Дальше — про то, как мы строили продуктовую аналитику для Telegram-бота с AI-персонажами на ~300K MAU, ~75 RPS в пике и ~1.5M событий в день: без ClickHouse, без Amplitude, без единой event-таблицы. Двенадцать дашбордов в Grafana поверх боевой MySQL. Три из них какое-то время врали, и это выяснилось не сразу.

Главный парадокс всего проекта помещается в одну строку: через систему проходит полтора миллиона событий в день, и ни одно из них не записано как событие. Есть только строки в продуктовых таблицах и их created_at. Всё, что вы прочитаете ниже, — следствие этого факта.

Статья — не туториал «подключите MySQL к Grafana за 10 шагов». Это разбор того, что происходит, когда продуктовые метрики приходится доставать из схемы, которую проектировали под продукт, а не под аналитику, — и когда по этим метрикам прямо сейчас решают, лить трафик дальше или нет.

Дисклеймер: проект под NDA, поэтому названия, точные объёмы и часть деталей изменены. Порядок величин, схема и сами проблемы — настоящие.

Фраза «покажите нам всё» звучит как плохое требование. В ней нет конкретного пользователя, перечня показателей, периода, источников и даже понятного результата. Но за ней обычно стоит нормальная потребность: заказчик видит много разрозненных данных, регулярно получает отчёты вручную и боится потерять что‑то важное при переходе к новой аналитической системе.

Проблема начинается, если воспринять эту фразу буквально. Тогда в первый релиз пытаются включить все таблицы, показатели, фильтры и варианты детализации. Система растёт ещё до того, как становится понятно, кто и для чего будет ею пользоваться.

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

Но «всё» нельзя использовать как границу проекта. Его сначала нужно разобрать на решения, роли, показатели, источники и сценарии проверки.

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

Мы поговорили с тремя командами, которые используют продукты из экосистемы Инфостарт Маркетплейс в повседневной работе:

В 1С ежедневно накапливаются данные о контрагентах, номенклатуре, остатках, продажах, договорах и сотрудниках. Они нужны не только для учета: руководители используют их в дашбордах, аналитики — в BI-системах, а смежные сервисы — для обмена справочниками и показателями.

Сложность начинается в момент, когда данные требуется получить за пределами учетной системы. Иногда достаточно один раз сохранить список в Excel. В других случаях нужна обновляемая таблица или отчет с отборами и группировками. Разберем три способа, доступных без разработки отдельного решения.

Искусственный интеллект уже умеет за считанные минуты собирать дашборды, которые выглядят вполне профессионально. Проблема в том, что убедительный интерфейс легко маскирует слабую постановку задачи и сомнительные выводы. В этой статье — эксперимент с тремя промптами для Claude Design и разбор того, где заканчиваются возможности модели и начинается работа аналитика.

Запрос на дашборд часто начинается со списка показателей и заканчивается красивым отчётом, по которому непонятно, что делать дальше. На примере BI-дашборда для сравнения подразделений разбираю, как перейти от пожеланий к конкретному решению, проверить сопоставимость данных и построить структуру отчёта от отклонения к деталям.

Ниже не попытка восстановить всю работу над проектом по дням, а структура подхода, к которой я пришёл на практике.

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

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

Я разобрал свежие кейсы OpenAI, Anthropic и Hex: что действительно улучшает ответы, какие очевидные подходы уже провалились, из чего складывается реальная стоимость и как за шесть шагов проверить

Что общего у Бенджамина Франклина, японских пенсионеров и американских зумеров? Всех их спрашивали о смерти, бессмертии и о том, сколько они хотят прожить. Только данные разбросаны по сотням статей, сайтов, стат. сборников и архивов.

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

Я решил, это исправить. В этой статье я расскажу, как родился проект «Кто хочет жить вечно», почему вопрос бывает важнее ответа и как я собирал со всего интернета материалы, упаковывая их в инфографику на 40 графиков.