Технологический прорыв в бизнес-аналитике: как инженер Александр Полянкин помогает развивать один из самых популярных BI-продуктов с открытым исходным кодом

Александр Полянкин, ведущий разработчик Metabase, рассказывает о технологических инновациях в сфере бизнес-аналитики, разработке Metabot AI и о том, как его команде удалось вывести продукт с открытым исходным кодом в лидеры рынка. В интервью Александр делится инсайтами о том, как искусственный интеллект меняет подход к работе с большими данными, почему традиционные языковые модели не всегда эффективны для специализированных областей, и как команда решает проблему обработки миллионов таблиц.

— Александр, вы являетесь ведущим разработчиком компании Metabase, одного из самых популярных инструментов для бизнес-аналитики с открытым исходным кодом. За время вашей работы компания значительно выросла — с 6 до более 100 сотрудников, а продукты компании сейчас используют миллионы пользователей. Расскажите, как вы пришли к работе над интерфейсами и что именно вас привлекло в этой области?

Мой путь в разработку интерфейсов начался довольно интересно. Изначально я мечтал создавать компьютерные игры, что и подтолкнуло меня к изучению программирования еще в школе. После красного диплома Волгоградского технического университета я стартовал карьеру как бэкенд-разработчик на C#. Но вскоре понял, что именно работа над пользовательскими интерфейсами позволяет непосредственно видеть результаты своего труда и напрямую влиять на то, как пользователи взаимодействуют с продуктом. По-настоящему меня увлекала возможность создавать что-то осязаемое. Когда разрабатываешь серверную часть, результаты твоей работы часто скрыты от глаз пользователя. В интерфейсах же каждое твое решение напрямую влияет на опыт взаимодействия с продуктом. Эта непосредственная связь между твоим кодом и пользовательским опытом казалась мне гораздо более вдохновляющей, чем работа над невидимыми процессами на сервере.

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

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

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

— Одна из ваших последних разработок — Metabot AI, чат-интерфейс для генерации запросов на естественном языке. Вы упоминали о сложностях работы с клиентами, у которых может быть более миллиона уникальных таблиц. Какие технические вызовы пришлось решать при создании этого инструмента?

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

Я разработал многоступенчатый подход к решению этой проблемы. Первым шагом стала векторизация текста запросов пользователя. Мы преобразуем запрос в многомерный вектор, который затем сравнивается с векторными представлениями метаданных наших таблиц. Это позволяет быстро определить наиболее релевантный набор из 15-20 таблиц, которые, вероятно, имеет в виду пользователь. Второй этап — это анализ отобранных таблиц. Если система уверена, что запрос касается конкретной таблицы, она формирует ответ напрямую. Если есть несколько вариантов с похожей релевантностью, мы запрашиваем у пользователя уточнение. И еще одна техническая сложность — оптимизация производительности. Векторные сравнения должны выполняться молниеносно, даже при работе с огромными массивами данных. Я внедрил специализированные индексы и алгоритмы кластеризации, которые значительно ускоряют процесс поиска.

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

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

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

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

— Александр, под вашим руководством был разработан Embedding SDK — библиотека для интеграции компонентов Metabase во внешние приложения. Этот релиз занял третье место на Product Hunt в течение дня и десятое в течение недели. Что делает это решение уникальным и какие технические препятствия пришлось преодолеть при его разработке?

Embedding SDK стал для нас настоящим прорывом, поскольку он кардинально меняет способ использования аналитических инструментов. Традиционно бизнес-аналитика существовала в своей собственной изолированной среде — пользователям приходилось переключаться между рабочими приложениями и инструментами аналитики. Наш SDK позволяет внедрять мощные аналитические компоненты Metabase непосредственно во внешние приложения, создавая цельный пользовательский опыт. 

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

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

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

Наконец, третья трудность — это безопасность. Когда ваши компоненты встраиваются в чужие приложения, возникает множество потенциальных уязвимостей. Мы разработали надежную систему аутентификации и авторизации, которая обеспечивает безопасный доступ к данным даже в условиях интеграции с внешними системами. Успех SDK на Product Hunt подтвердил, что наши усилия были не напрасны. Сообщество разработчиков быстро оценило гибкость и мощь нашего решения, что позволило ему занять высокие позиции в рейтинге среди множества других технологических новинок.

— Вы также имеете насыщенный опыт публичных выступлений, в том числе доклад на HolyJS Spring 2025 — крупнейшей конференции по фронтенд-разработке в России. Как вы считаете, насколько важен обмен знаниями в IT-сообществе и какую роль он играет в развитии отрасли?

Обмен знаниями — это фундаментальный двигатель прогресса в IT-индустрии. Я убежден, что без активного обмена опытом развитие нашей отрасли замедлилось бы в разы. Когда разработчики делятся своими находками, решениями и даже ошибками, мы все вместе избегаем «изобретения велосипеда» и можем сконцентрироваться на действительно новых проблемах. На HolyJS я рассказывал о ключевых технических вызовах при разработке Embedding SDK. Подготовка к этому докладу заставила меня глубже проанализировать нашу работу, систематизировать полученный опыт. 

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

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

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

— В своем предстоящем докладе для международной онлайн-школы Mathshub вы планируете рассказать про использование больших языковых моделей с большим количеством входных данных. Какие сложности возникают при обучении AI на огромных массивах данных и как это влияет на точность их работы?

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

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

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

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

— Александр, отдельно хочется обсудить ваш опыт работы как в крупных компаниях, так и в растущих стартапах. Если оглянуться назад на путь от компании Wrike до нынешней позиции в Metabase, какой проект вы считаете технически самым сложным и почему?

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

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

Я внедрил принципиально новый подход к работе с данными, оптимизировал систему хранения и обработки информации, и мы полностью переписали некоторые критические компоненты. Это был многомесячный марафон, требовавший как глубокого технического понимания, так и способности донести сложные концепции до коллег из разных отделов. В результате мне удалось улучшить производительность системы в 10 раз для крупных отчетов и обеспечить стабильную работу даже с самыми большими объемами данных. Именно эта работа стала одним из ключевых факторов, который позволил компании успешно выйти на рынок enterprise-клиентов и, в конечном итоге, привел к приобретению Wrike компанией Citrix за 2,25 миллиарда долларов. Опыт работы над этим проектом научил меня, что успех сложных технических инициатив на 50% зависит от качества коммуникации и планирования. Даже самое блестящее техническое решение не принесет пользы, если его не удастся эффективно внедрить в условиях большой компании с множеством заинтересованных сторон.

— Это действительно впечатляющий опыт! Александр, глядя в будущее, какие технологические тренды в сфере бизнес-аналитики вы считаете наиболее перспективными в ближайшие несколько лет?

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

Второй важный тренд — это «проактивная аналитика». Традиционно аналитические инструменты отвечали на явно сформулированные вопросы. Однако новое поколение систем будет самостоятельно выявлять значимые паттерны и аномалии в данных, предупреждая пользователей о потенциальных проблемах или возможностях ещё до того, как они сформулируют соответствующий запрос. Это требует гораздо более глубокого понимания бизнес-контекста и отраслевой специфики. Я считаю, что нас ожидает интеграция аналитики непосредственно в рабочие процессы. Как показывает успех нашего Embedding SDK, пользователи не желают переключаться между различными инструментами. Аналитика должна быть доступна в месте, где принимаются решения, будь то CRM-система, маркетинговая платформа или инструмент для управления проектами.

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

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

Источник: argumenti.ru