Один из первых клиентов, начавших использовать SingleStore Analyst, задал ему вопрос, который в обычных условиях был бы передан команде по работе с данными. Это был всего лишь второй вопрос, который клиент задал Analyst, но когда пришел ответ, руководитель отдела данных сказал:
«На такой же анализ у моей команды ушло бы две недели».
Не нужно было создавать новый конвейер данных, подавать заявку или планировать спринт. Analyst выполнил запрос к данным, на которых уже работает бизнес, и предоставил результат за считанные минуты.
Многие полезные вопросы остаются без ответа, потому что они недостаточно важны, чтобы тратить на них две недели работы. Analyst меняет этот подход: пользователи могут исследовать управляемые корпоративные данные на обычном языке, задавать уточняющие вопросы по мере погружения в тему и получать результаты достаточно быстро, чтобы успеть ими воспользоваться.
Analyst делает больше, чем просто переводит вопрос на SQL и визуализирует результат. Он интерпретирует полученные данные, выявляя изменения, точки перегиба и различия, а затем предлагает уточняющие вопросы, которые могут объяснить эти находки. Каждый ответ становится началом исследования, а не концом запроса.
Два способа заставить Analyst работать
SingleStore — это распределенная SQL-база данных, которую наши клиенты используют, когда их рабочая нагрузка перерастает возможности специализированного движка. «Живая» запись и интенсивное чтение одних и тех же строк, несколько типов данных в одном пути выполнения и масштабирование чтения, встроенное в платформу, а не добавленное позже.
Команды выбирают таблицы, которые может использовать Analyst, и добавляют бизнес-контекст, необходимый для их интерпретации. После этого пользователи могут задавать вопросы на обычном языке, а Analyst берет на себя SQL, анализирует результаты и представляет ответ.
Для клиентов, чьи операционные данные уже работают в SingleStore, это создает прямой путь от вопроса к ответу. Не нужно развертывать дополнительные системы, перемещать данные или поддерживать синхронизацию второй копии.
Analyst также может работать с данными, реплицированными из Postgres, MySQL, Oracle, SQL Server или MongoDB. Доступ на обычном языке увеличивает число людей, способных делать запросы к набору данных, а агент может выполнять несколько запросов при ответе на один вопрос, поэтому параллелизм может быстро расти. Реплицируйте соответствующие данные в SingleStore с помощью Kafka, SingleStore Flow или существующего инструмента CDC, и SingleStore возьмет на себя эту нагрузку по запросам, в то время как исходная база данных останется системой учета.
Для «живой» аналитики (Live Intelligence) необходимо выполнение трех условий
Спросите любого, кто пытался внедрить ИИ-агента для работы с корпоративными данными, и вам назовут одни и те же три требования.
- Контекст обосновывает каждый ответ правильными данными, сохраняя ваши определения, связи и права доступа.
Контекст обосновывает каждый ответ правильными данными, сохраняя ваши определения, связи и права доступа.
- Параллелизм позволяет тысячам пользователей, приложений и агентов выполнять запросы одновременно, не ожидая друг друга.
Параллелизм позволяет тысячам пользователей, приложений и агентов выполнять запросы одновременно, не ожидая друг друга.
- Доступ в реальном времени означает, что ответы отражают данные такими, какие они есть сейчас, а не копию, экспортированную вчера вечером.
Доступ в реальном времени означает, что ответы отражают данные такими, какие они есть сейчас, а не копию, экспортированную вчера вечером.
Большинство архитектур могут обеспечить два из трех условий. Для выполнения всех трех обычно требуется управляемая система данных плюс отдельная инфраструктура для низкозадержечных запросов и векторного поиска. Конвейеры должны поддерживать синхронизацию этих систем, а приложение берет на себя работу по согласованию копий и обеспечению доступа к ним. Команды могут заставить это работать, но сложность никуда не исчезает; она просто перемещается из базы данных в приложение.
SingleStore по своей архитектуре выполняет все три условия в одном движке. Analyst работает непосредственно с вашими базами данных SingleStore, с теми же строками, в которые приложение записывает данные в момент задания вопроса. Транзакционные записи и аналитические чтения обращаются к одним и тем же данным, поэтому ничего не нужно извлекать, копировать или синхронизировать, и нет графика обновления, от которого можно отстать.
Вопросы, которые люди задают в течение рабочего дня, — это те, где это важнее всего, и где разница между данными «минутной давности» и «прямо сейчас» становится решающей.
- Каков наш уровень мошенничества по платежам, поступившим за последние десять минут?
Каков наш уровень мошенничества по платежам, поступившим за последние десять минут?
- Как на самом деле конвертируется промоакция, которую мы запустили в девять утра?
Как на самом деле конвертируется промоакция, которую мы запустили в девять утра?
- Стоит ли нам изменить цену на этот номер, этот маршрут, этот SKU до прибытия следующей волны посетителей?
Стоит ли нам изменить цену на этот номер, этот маршрут, этот SKU до прибытия следующей волны посетителей?
Большинство баз данных могут ответить на подобные вопросы, используя данные, которые отстают на минуты или часы. Некоторые могут приблизиться к этому с помощью конвейера Kafka в отдельное аналитическое хранилище, ценой эксплуатации обоих. SingleStore обслуживает их на данных, которые отстают на миллисекунды или секунды, работая с теми же строками, в которые приложение продолжает записывать данные. И когда кто-то получает устаревший ответ, не зная об этом, он перестает доверять инструменту. Обычно молча и обычно навсегда.
Мы создали Analyst так же, как предлагаем вам создавать агентов на нашей платформе. Его память диалогов, знание того, что означают ваши таблицы и столбцы, его эмбеддинги и дашборды — все это живет в SingleStore.
Домены — основа для отличных ответов
Домен — это курируемый набор баз данных и таблиц со своими владельцами, пользователями и контекстом. Это единица области действия, единица управления и единица контекста. Перед началом работы с нашим Analyst необходимо настроить активный Домен. Это осознанный выбор, так как вопрос без области действия — это вопрос, на который Analyst не может ответить с уверенностью.
Один набор данных может поддерживать отдельные домены для финансов, маркетинга и руководства. У каждого домена свои владельцы, пользователи, бизнес-контекст и права доступа, поэтому каждая группа видит только те данные, которые для нее одобрены. Это отличается от подключения ИИ-ассистента общего назначения к базе данных с одним набором учетных данных, что может дать каждому пользователю этого подключения одинаковый доступ к данным.
Analyst берет на себя большую часть сложной работы при создании домена. Он начинает с данных, к которым создатель уже имеет доступ, автоматически индексирует выбранные вами таблицы, делает выборку данных из базовых таблиц и пишет черновик того, что, по-видимому, означает каждая таблица и столбец. Он также создает выделенного пользователя базы данных для этого домена, имеющего только права на чтение (READ) и ничего более, только для одобренных вами таблиц. Удалите таблицу из домена, и права будут отозваны. Удалите домен, и пользователь исчезнет вместе с ним.
В систему встроены достаточные защитные механизмы, чтобы предотвратить использование ресурсов, питающих ваши рабочие нагрузки, непредвиденными запросами, сгенерированными Analyst. Включите запись, и каждый вопрос, каждая оценка и SQL, стоящий за каждым ответом, будут доступны для проверки администратором.
Домены созданы для изменений. По мере развития ваших данных и бизнеса владельцы продолжают уточнять область действия, значения и связи, и ответы меняются вместе с ними.
Контекстный движок делает ответы заслуживающими доверия
Точность любой агентной системы в общих чертах обычно является проблемой контекста. Точность зависит от семантического уровня, который кто-то поддерживает вручную. Когда вопрос выходит за рамки того, что было отобрано вручную, качество снижается, и без дорогостоящей системы оценки и команды, занимающейся поддержанием актуальности, это снижение очень трудно даже заметить, не говоря уже о диагностике.
Многие команды в отрасли решают эту проблему с помощью специализированных сложных систем, привязанных к их базе данных. Наш ответ — Context Engine, и он находится внутри домена, а не рядом с ним. Он отображает ваши данные, изучает ваши бизнес-определения, применяет ваши разрешения и хранит историю разговоров, поэтому ответ основан на том, что является истинным для вашего бизнеса прямо сейчас. Он создается один раз и используется для каждого взаимодействия в этом домене. Он состоит из нескольких отдельных частей.
- Business Rules — это место, где ваша компания записывает, что означают специфические для компании термины. Что включает в себя выручка, какие счета не учитываются, когда начинается финансовый год, как ваша команда на самом деле называет вещи. Analyst отвечает через них, поэтому определение сохраняется во всех разговорах, вместо того чтобы пересматриваться от вопроса к вопросу.
Business Rules — это место, где ваша компания записывает, что означают специфические для компании термины. Что включает в себя выручка, какие счета не учитываются, когда начинается финансовый год, как ваша команда на самом деле называет вещи. Analyst отвечает через них, поэтому определение сохраняется во всех разговорах, вместо того чтобы пересматриваться от вопроса к вопросу.
- Learned context — это то, что Analyst получает из реальных вопросов. Analyst предлагает это администратору домена для утверждения, отклонения или редактирования. Ничто из того, что он изучает, не становится активным само по себе, и в этом весь смысл. Ваш контекст накапливается с использованием, а не устаревает.
Learned context — это то, что Analyst получает из реальных вопросов. Analyst предлагает это администратору домена для утверждения, отклонения или редактирования. Ничто из того, что он изучает, не становится активным само по себе, и в этом весь смысл. Ваш контекст накапливается с использованием, а не устаревает.
- Semantic Layer — это живая карта самих данных: какие таблицы входят в область видимости, что означают столбцы и как объединяются сущности. Analyst составляет его черновик во время создания домена, а ваша команда продолжает его формировать. Объединения, которые выводит Analyst, приходят с показателем уверенности и очередью на проверку, вместо того чтобы молча приниматься как должное, что важнее, чем кажется, потому что выведенные объединения могут быть ошибочными.
Semantic Layer — это живая карта самих данных: какие таблицы входят в область видимости, что означают столбцы и как объединяются сущности. Analyst составляет его черновик во время создания домена, а ваша команда продолжает его формировать. Объединения, которые выводит Analyst, приходят с показателем уверенности и очередью на проверку, вместо того чтобы молча приниматься как должное, что важнее, чем кажется, потому что выведенные объединения могут быть ошибочными.
- Trained queries — это доверенные пары «вопрос-SQL», которые вы хотите, чтобы Analyst использовал в качестве эталонных шаблонов. Именно так вы фиксируете точную логику показателей, в которых нельзя допустить ошибку.
Trained queries — это доверенные пары «вопрос-SQL», которые вы хотите, чтобы Analyst использовал в качестве эталонных шаблонов. Именно так вы фиксируете точную логику показателей, в которых нельзя допустить ошибку.
Существует еще один уровень, который клиентам вообще не нужно поддерживать. Наряду с вашим контекстом мы храним глобальное хранилище того, как писать SQL, который работает правильно и эффективно на движке SingleStore, шаблоны и идиомы, которые здесь работают быстро, а также уникальные возможности нашего диалекта SQL. Каждый запрос, который пишет Analyst, учитывает и то, и другое. Результатом являются запросы, которые одновременно учитывают бизнес-логику и особенности движка, что является преимуществом, которое вы получаете только тогда, когда агент и движок происходят из одного места.
Весь контекст версионируется. Вы редактируете черновик, тестируете его на вопросах, на которые на прошлой неделе были получены неверные ответы, сравниваете его с тем, что опубликовано, и публикуете, когда он готов. Никто не экспериментирует в рабочей среде.
Такое разделение труда — это то, что, как мы видим, работает на практике. Люди, которые знают данные, курируют смысл и подтверждают связи, а все остальные просто задают вопросы. Экспертиза фиксируется один раз людьми, которые действительно ею обладают, а затем вся организация может ее использовать.
Лучшие инсайты заслуживают сцены
Чат-интерфейс очень хорош для ответов на вопросы, пока вы учитесь и исследуете. Большинству компаний нужно что-то большее. Им нужно получать ответ на один и тот же вопрос в разное время, каждый понедельник утром в течение следующих двух лет, для чего и были созданы BI-дашборды.
Поэтому, когда Analyst создает визуализации, которые стоит сохранить, вы можете закрепить их прямо на дашборде, и они останутся актуальными. Сохраняется не картинка результата или копия строк под ним. Сохраняются SQL и конфигурация диаграммы. Каждый раз, когда кто-то открывает этот дашборд, эффективный запрос снова выполняется по текущим данным. Дашборд — это не запись того, что было правдой, когда кто-то его создал. Это окно в то, что является правдой сейчас.
Этот цикл — та часть, к которой наши первые клиенты постоянно возвращаются, и именно здесь движок реального времени перестает быть архитектурной схемой и становится чем-то осязаемым, что может увидеть руководитель.
Дашборды наследуют правила доступа домена, из которого они были созданы, поэтому нет второй модели разрешений для поддержки и нет способа передать кому-то диаграмму, построенную на данных, которые им никогда не разрешалось видеть.
Что мы построили сначала и что будет дальше
Мы разработали этот релиз для людей, у которых есть вопросы о бизнесе, но которые не пишут на SQL. Они могут исследовать данные в разговорной форме, изучать результаты на интерактивных диаграммах и сохранять полезные представления на дашбордах, которые остаются актуальными. Эксперты по данным сохраняют контроль над определениями, связями и шаблонами запросов, которые определяют качество этих ответов.
Далее мы расширим аудиторию за счет поддержки встроенного анализа внутри приложений. Управляемая аналитика в реальном времени должна быть доступна каждому в интерфейсах, в которых они уже работают, и она должна быть доступна внутри приложений, которые наши клиенты создают для своих пользователей. Analyst становится тем, что вы встраиваете в свой продукт, а не пунктом назначения, который ваши пользователи должны покинуть, чтобы посетить. Обслуживание многих ваших клиентов из одной системы означает реальную изоляцию между ними, и эта изоляция встроена в движок, а не прикручена поверх него.
Подробнее об этом, когда все будет готово. А пока направьте Analyst на свои данные, выберите таблицы, которые ему разрешено читать, и спросите его о том, что происходит прямо сейчас.
