AI в BI
Видимо, кто-то до сих пор верит, что SQL придумали для секретарш, и потому надеется научить ему ИИ. Обывателю кажется, что "подай-принеси" данные делать несложно, но мы-то с вами знаем, кого и куда порой приходится натягивать, чтобы всё сошлось, а ведь дата стюарды отнюдь нерезиновые!
Тем не менее позыв позитивный, и надо его поддержать. Так что в этой неравной битве встану на сторону машин, тем более что за рабочие места секретарш я спокоен.
Попробую разложить тизер из прошлого поста. Итак, я уверен, что нейросеть не должна генерить SQL.
Это плохо контролируемый процесс, а вольности тут недопустимы, отвечать-то всё равно нам.
Как быть?
Мы ведь с вами делаем дашборды, в которых заказчик может тыкать только выданные виджеты, фильтры, смотреть предустановленные метрики и срезы. Так вот с этими недосекретаршами ситуация аналогичная - их нужно ограничить.
🧞♂️ План
1️⃣ Описываем в кубе необходимые бизнес метрики со всякими сложными SQL выражениями, джойнами и прочим. Добавляем к ним дескрипшны.
2️⃣ Пишем https://modelcontextprotocol.io/docs/getting-started/intro сервер с перечислением нужных нейросети инструментов. Для демки мы использовали https://github.com/vercel/mcp-handler. Также вам понадобятся Дима и Гриша.
3️⃣ Суём машине в контекст наши инструменты, инструкции по их использованию, а потом закидываем вопрос юзера. Если выплывет, устраиваем на полставки.
🧙♀️ Какие инструменты писать?
dataset_meta
Подносим ИИшнице меню на выбор, в нём перечень всех полей датасета с описаниями, т.е. meta куба.
dimension_values
Юзер редко знает, как точно называется продукт в базе, когда интересуется выручкой по нему. Так что пусть машина сбегает и посмотрит, какие варианты вообще есть.
get_date
ИИ уже такого от вас натерпелся, что первым делом по привычке спрашивает, как долго он был в отключке. Сверяем часы, если нужно, чтобы данные в ответах были актуальными.
dataset_query
Когда многомиллиардная разработка наконец осознаёт, что от неё хотят, то формирует json запроса в куб
Вишенкой стали методы для выбора и построения графиков, расчета позиции спавна виджетов и прочего визуального.
🦄 Как это выглядит?
import { createMcpHandler } from '@vercel/mcp-handler'
import { z } from 'zod'
const handler = createMcpHandler(
(server) => {
server.tool(
'dataset_query',
'Get data with Cube query',
{
measures: z.array(z.string()),
dimensions: z.optional(
z.array(z.string())
),
filters: z.optional(
z.array(
z.object({
member: z.string(),
operator: z.string(),
values: z.array(z.string()),
})
)
),
// ...
})
})
🧚 Что надо учесть?
1. Можно использовать разные модели для планирования решения и реализации. Это скажется и на скорости и на стоимости, так многие делают.
2. За ИИ всегда надо проверять. В неудачных дублях скринкаста он дергал функцию генерации конфига виджета дважды, потому что первое изделие не прошло сертификацию. Мы используем zod, как в примере.
3. Мультитенантность и RLS тоже не стоит доверять нейросети, для этого потребуются низкоуровневые методы
4. ИИ получает доступ к данным. Передача ценных данных между юрлицами, а тем более трансграничная, не всегда допустима.
5. Видос я ускорил.
6. Всё равно кто-то попросит скриншот дашборда в мессенджер... каждый день
