ClickHouse спонсировал этот пост. Insight Partners является инвестором ClickHouse и TNS.
Более десяти лет индустрия данных преследовала мечту об аналитике самообслуживания. Обещание было простым: дайте каждому доступ к данным, и идеи потекут. На практике успеха добились лишь немногие организации. Препятствия оказались выше, чем ожидалось, и даже когда вы их преодолели, финишная черта продолжала двигаться.
Проблема трех частей
Задача распадается на три взаимосвязанные проблемы.
Во-первых, это контроль доступа. Обеспечить управляемый и безопасный доступ к данным во всей организации сложно. Разным командам нужны разные разрешения. Требования соответствия различаются в зависимости от региона. Персональные данные нуждаются в защите. Чтобы сделать это правильно, требуется существенная инфраструктура и постоянное обслуживание.
Во-вторых, это удобство использования. Даже при наличии доступа инструменты остаются пугающими. Прямой доступ к базе данных требует свободного владения SQL. Инструменты бизнес-аналитики (BI), несмотря на их визуальные интерфейсы, не всегда интуитивно понятны. Каждая платформа имеет свою собственную терминологию: измерения и метрики, оси и метки, меры и поля. Пользователи сталкиваются с сотнями типов диаграмм с небольшими различиями. Кривая обучения крутая, и подъем никогда не заканчивается.
В-третьих, существуют бизнес-определения, иначе говоря, семантическое понимание. Где хранятся данные? Что означают эти названия столбцов? Как финансовый отдел определяет «ежемесячных активных пользователей» по сравнению с тем, как это определяет продукт? Эти институциональные знания живут в разрозненной документации, потоках Slack и головах людей. Подключение новых членов команды к вашим данным занимает недели или месяцы.
Каждая деталь сложна. Вместе они оказались неразрешимыми для многих организаций.
Где на самом деле помогает ИИ
Некоторые варианты использования ИИ могут показаться решениями для поиска проблем, но большие языковые модели (LLM) устраняют реальные болевые точки в рабочих процессах аналитики.
- На практике генерация SQL становится все более надежной. LLM уже широко используются при генерации кода, включая SQL. Барьер изучения SQL, который удерживал многих бизнес-пользователей от прямого доступа к данным, может быть значительно снижен. Конечно, есть куда совершенствоваться. Более сложные запросы по-прежнему могут быть сложными, а менее распространенные диалекты SQL подвержены ошибкам. Но каждое поколение моделей в целом улучшало качество генерации SQL и повышало способность рассуждать при наличии четких сигналов схемы и бизнес-контекста.
- Понимание контекста. Как и людям, специалистам LLM нужен контекст о системах и данных, с которыми они взаимодействуют. О внутренних системах часто распространяется разбросанная документация, и людям может быть трудно ее найти и переварить. LLM разработали широкие контекстные окна и могут искать и читать внешний контекст из различных источников. Они могут принести пользователю семантическое понимание, даже если сам пользователь его не предоставляет. Здесь есть свои проблемы; требуется предварительная и постоянная работа для обеспечения существования метаданных, их актуальности и доступности для LLM.
- Интерфейсы чата демократизируют взаимодействие. Вам больше не нужно осваивать особенности инструментов BI. Никакой прокрутки библиотек диаграмм. Никакой борьбы с панелями конфигурации. Интерфейс разговорный. Введите то, что вы хотите. Говори это. Прикрепите скриншот макета. Выражайте свои потребности так, как если бы вы просили коллегу построить это, не отнимая при этом ничьего времени.
Эти достижения устраняют практические барьеры, с которыми сталкиваются пользователи, которые ограничивают доступ к аналитике.
Проблема привязки к поставщику
Прогресс достигнут, но проблемы остаются. Доступ по-прежнему требует управления. Инструменты должны эффективно интегрироваться с базами данных. И здесь нынешняя ситуация усложняется.
Многие крупные поставщики проприетарного программного обеспечения предлагают отличные собственные решения. Они обеспечивают хороший опыт, который расширяет встроенный контроль доступа и делает платформы более доступными. Это законные решения, которые работают в их экосистемах.
Но они не охватывают весь спектр вариантов использования. Их невозможно отделить от поставщика. Вы не можете развернуть собственный внутренний интерфейс в стиле ChatGPT, который может использовать каждый, независимо от знаний поставщика. И что особенно важно, они не могут обеспечить унифицированный доступ к нескольким источникам данных.
Реальность с множеством источников
У большинства предприятий нет единого поставщика данных. Есть хранилище аналитических данных, оперативная база данных Postgres, поддерживающая основное приложение, MySQL, поддерживающий другой сервис, и, возможно, где-то скрывается Oracle ERP. Помимо баз данных, общение ведется в Slack, платежная информация — в Stripe, а данные учетной записи — в Salesforce. Пользователям часто приходится сопоставлять оперативные данные из этих источников с аналитическими данными в хранилище.
Традиционное решение? Создайте «единый источник правды», реплицируя все на склад. На практике этот подход имеет примерно такой же уровень успеха, как и сама аналитика с полным самообслуживанием. В большинстве организаций все еще есть хранилища данных.
Пять лет назад концепция сетки данных обещала решить эту проблему с помощью таких механизмов, как Trino и Presto: запрашивать что угодно и где угодно из единого интерфейса. Они работают, но они сложны, тяжеловесны и возвращают нас к исходной точке доступа и удобства использования.
Введите МСР
LLM и протокол контекста модели (MCP) предлагают интересную альтернативу. Вместо «мета-движка», расположенного над всеми уровнями данных, серверы MCP предоставляют необработанные функциональные возможности практически любой базы данных через общий совместимый протокол. Вместо того, чтобы переводить диалект «мета-SQL» через плагины в последующий синтаксис, LLM просто пишут собственный SQL для каждой базы данных.
Это элегантное техническое решение проблемы интеграции, но мы не можем использовать для его реализации опыт сторонних поставщиков.
Стек агентских данных с открытым исходным кодом
Нам нужен открытый стек, который позволит создавать эти возможности собственными силами, работать с любым поставщиком данных, используя открытые протоколы, и позволит пользователям взаимодействовать на разговорном языке.
Этот стек состоит из трех основных компонентов:
- Уровень базы данных предоставляет аналитические возможности в реальном времени в любом масштабе. Ему необходимо обрабатывать одновременные запросы с высокой пропускной способностью и низкой задержкой. Это важно, когда агенты ИИ могут генерировать гораздо больше запросов, чем люди-аналитики.
- Уровень протокола (MCP) создает стандартный интерфейс между приложениями ИИ и источниками данных. Разработчики предоставляют данные через серверы MCP, а приложения искусственного интеллекта подключаются как клиенты MCP. Это работает для баз данных, файловых систем, инструментов разработки, веб-API и инструментов повышения производительности.
- Интерфейс чата (например, LibreChat) дает пользователям и организациям полный контроль над своими данными, агентами и разговорами, одновременно поддерживая развертывания корпоративного уровня.
Ключевое слово повсюду — «открыто». Компоненты с открытым исходным кодом. Открытые протоколы. Открытые стандарты. Это предотвращает привязку к поставщику и позволяет организациям адаптироваться к своим конкретным потребностям.
Реальное внедрение
Это уже реальность для многих организаций, внедривших эти стеки в производство.
Shopify использует LibreChat для реализации рефлексивного искусственного интеллекта во всей компании. Благодаря почти универсальному внедрению и тысячам настраиваемых агентов команды подключаются к более чем 30 внутренним серверам MCP, демократизируя доступ к важной информации.
В сфере здравоохранения cBioPortal использует этот стек, чтобы дать возможность исследователям рака задавать совершенно новые вопросы о геномике и траекториях лечения. По словам их команды: «Это делает открытия доступными исследователям».
ClickHouse использует эти системы для своего хранилища данных, ориентированного на искусственный интеллект, обрабатывая примерно 70% запросов к хранилищу для сотен пользователей, при этом объем использования быстро растет.
Мы уже там?
Галлюцинации все еще существуют, и их не всегда легко обнаружить, особенно когда мы предоставляем доступ пользователям, которые не являются экспертами в предметной области. Вопрос «Сколько букв R в клубнике?» В течение некоторого времени проблема была постоянной шуткой, и она продолжает считать социальные сети основным барометром недавно выпущенных моделей.
На первый взгляд это звучит как тривиальная проблема, но это забавная демонстрация проблем, которые могут создать LLM. Мы могли бы ожидать, что модель генерирует запрос SQL, отправляет его в базы данных для обработки наших данных, а модель возвращает нам выходные данные. Мы можем проверить правильность SQL и знать, что база данных выполнит его правильно.
Однако это оставляет нам несколько открытых вопросов:
Это, пожалуй, самая большая область неопределенности при внедрении ИИ в нашу аналитику. Хотя эти проблемы естественным образом решаются с каждым поколением модели, в настоящее время на практике они требуют осторожности и внимания.
В приведенных выше реальных примерах команды, внедряющие платформы искусственного интеллекта, отслеживают качество запросов и результатов, используя индивидуальные решения для наблюдения LLM. Офлайн- и онлайн-оценки позволяют оценивать эти переменные, позволяя командам измерять эффективность, выявлять регрессии и постоянно улучшать производительность системы. Сделать это эффективно и просто по-прежнему остается открытой задачей и самой большой возможностью для улучшения в будущем.
Что это значит для вас
У открытого стека есть очевидные практические преимущества.
Благодаря открытому уровню UX, такому как LibreChat, вы получаете знакомый интерфейс чата без жесткой привязки к какому-либо поставщику. Ни поставщик вашей базы данных, ни ваш поставщик ИИ. Разверните его один раз, и он будет работать одинаково независимо от того, используете ли вы модели OpenAI, Anthropic или Google или интегрируетесь с ClickHouse, Postgres, Snowflake или Oracle.
Когда интерфейс диалоговый, кривая обучения выравнивается. Пользователям не нужно становиться экспертами по SQL или опытными пользователями инструментов бизнес-аналитики. Им просто нужно знать, какие вопросы задавать. Это значительно снижает нагрузку на поддержку и повышение квалификации, позволяя строителям сосредоточиться на том, что они делают лучше всего: строительстве.
Интеграция опирается на открытые стандарты, такие как MCP, а не на API-интерфейсы конкретного поставщика. По мере того, как LLM продолжают совершенствоваться в генерировании SQL и анализе контекста данных, ваш стек автоматически становится лучше. Вы не ждете, пока поставщик обновит свой собственный уровень интеграции.
При открытом стеке ваши данные не исчезнут в чужом черном ящике. У вас есть контроль над анализом использования, оценкой качества ответов и реальной ценностью системы. Сегодня это непростая задача, но ваш стек остается открытым для принятия новых методологий по мере развития пространства.
В конечном счете, вы владеете своим стеком. Вы можете развивать его с течением времени. Заменяйте компоненты по мере появления лучших вариантов. Добавляйте новые источники данных без перестройки интерфейса. Меняйте поставщиков ИИ, не переучивая пользователей новому UX. Прибор и наблюдение за использованием, производительностью и потреблением. Эта гибкость имеет значение, когда вы создаете инфраструктуру, рассчитанную на годы, а не месяцы.
Тот же интерфейс. Тот же пользовательский опыт. Сменные модели и подключаемые интеграции.
Самообслуживание не было неправильным, оно было ранним
Обещание аналитики самообслуживания не было ошибочным. Это опережало технологии, доступные для его реализации. LLM не решают все проблемы, но они начинают решать правильные проблемы для этого варианта использования: генерация кода и интерфейсы на естественном языке.
Мы являемся создателями популярной системы управления базами данных с открытым исходным кодом, ориентированной на столбцы, которая позволяет пользователям создавать аналитические отчеты с использованием SQL-запросов в режиме реального времени. Мы понимаем, что данные растут в режиме реального времени, и считаем, что результаты должны быть быстрыми, очень быстрыми. Узнайте больше ТЕНДЕНЦИОННЫЕ ИСТОРИИ YOUTUBE.COM/THENEWSTACK Технологии развиваются быстро, не пропустите ни одной серии. Подпишитесь на наш канал YouTube, чтобы смотреть все наши подкасты, интервью, демонстрации и многое другое. ПОДПИСАТЬСЯ Группа, созданная в Sketch. Аласдер Браун провел последнее десятилетие, проектируя, создавая и эксплуатируя платформы данных: от аналитики в реальном времени для ведущих брендов до крупнейших в мире национальных государственных систем киберзащиты. Он является сторонником простых архитектур данных и часто… Подробнее от Аласдера Брауна
