Cortex Analyst від Snowflake: довіряй, але перевіряй

pic

Як ви, ймовірно, вже чули, Snowflake Cortex Analyst наразі доступний у попередньому перегляді в більшості регіонів Snowflake. Це проривна функція в багатьох відношеннях — вона обіцяє зробити з структурованими даними (тобто даними з вимірюванням) те, що Retrieval Augmented Data (RAG) зробив з неструктурованими даними, такими як PDF: дозволяючи запитувати та досліджувати дані за допомогою природної мови.

Цінність Cortex Analyst полягає у його повністю керованій природі. Snowflake формулює це так:

Створення аналітичного рішення самобслуговування з високою якістю для розмовних інтерфейсів вимагає сервісу, який генерує точні текстові відповіді на SQL запити. Для більшості команд розробка такого сервісу, що успішно балансуватиме точність, затримки та витрати, є важким завданням. Cortex Analyst спрощує цей процес, надаючи повністю керовану, складну агентну ІІ систему, яка справляється з усіма цими складнощами, генеруючи дуже точні текстові відповіді на SQL запити.

Це звучить дуже привабливо. Багато з нас вже використовували великі мовні моделі (LLM) для генерації коду, але значущий SQL дуже залежить від базових структур даних, які ви хочете запитувати. Велика мовна модель не може згенерувати значущий SQL, якщо вона "не знає", які базові структури даних використовуються.

Cortex Analyst заповнює цей "пробіл знань" за допомогою своєї власної Семантичної Моделі. Це, по суті, YAML файл, який визначає дані та зв'язки у вашій моделі бізнес термінами. Як тільки ви створите модель даних у вигляді вимірювань, досить легко створити Семантичну Модель для цієї моделі даних, яка відповідає специфікації моделі. Перший раз, коли ви це зробите, мабуть, краще робити це вручну, використовуючи спрощену модель даних для того, щоб зрозуміти, як має бути зазначена Семантична Модель. Snowflake також надав інструмент, щоб допомогти в створенні Семантичної Моделі. В майбутньому я підозрюю, що створення Семантичної Моделі буде одним з тих процесів, які будуть частково автоматизовані при створенні об'єктів в схемі Snowflake. Це насправді лише покращена/анотована версія вже існуючих метаданих.

Для тестування я слідував основному посібнику тут. Це створює додаток Streamlit, який ви можете використовувати для запитів до ваших даних за допомогою природної мови.

Після того, як я налаштував основи і запустив проект, я вирішив спробувати це на моєму власному наборі даних.

Statistics Canada надає велику кількість наборів даних для безкоштовного публічного використання на різноманітні теми. Я вибрав невеликий піднабір даних про міжнародних відвідувачів, що прибувають або повертаються до Канади на літаку. Цей набір даних класифікує відвідувачів та підраховує кількість відвідувачів, які прибули в ряд канадських аеропортів.

Витяг з Семантичної Моделі показано нижче (крапки представляють частини YAML, які я залишив для скорочення):

name: Geo  
expr: GEO  
description: Географічне місцезнаходження прибуття  
data_type: varchar  
synonyms: ["місце прибуття", "порт в'їзду"]  
.  
.  
.  
name: Country_of_residence  
expr: COUNTRY_OF_RESIDENCE  
description: Країна, з якої прибув мандрівник  
data_type: varchar  
synonyms: ["країна"]  
.  
.  
.  
name: Traveller_Type  
expr: TRAVELLER_TYPE  
description: Тип мандрівника  
data_type: varchar  
synonyms: ["тип відвідувача"]  
.  
.  
.  

measures:  
 - name: number_of_travellers  
   expr: number_of_travellers  
   description: мандрівники за дату, країну проживання та географічне місцезнаходження  
   synonyms: ["прибуття", "відвідувачі"]

Зверніть увагу на використання синонімів. Це альтернативні визначення ваших вимірів або вимірів, які ви можете використовувати у запитах природною мовою. У цьому прикладі ми можемо використовувати “місце прибуття” або “порт в'їзду” взаємозамінно в запиті природною мовою, щоб вказати стовпець GEO в нашому наборі даних.

Тепер спробуємо! Після того, як я завантажив свої дані в ту ж саму схему, яку я створив під час посібника, і запустив додаток, я задав своїм новим даним кілька простих питань англійською мовою:

Я почав з питання, яке здається досить базовим, але яке насправді має цікаву особливість:

pic

По-перше, Cortex Analyst надає інтерпретацію запитання англійською мовою. Іншими словами, це перша перевірка того, що запитано:

pic

Зверніть увагу на використання множини аеропорти. Cortex Analyst може інтерпретувати запит як застосування не до «Аеропорту Торонто», а до будь-яких аеропортів, що мають у назві Торонто. Це підтверджується SQL, який генерується запитом:

WITH __stats_can_travellers AS (  
  SELECT  
    geo,  
    date,  
    number_of_travellers  
  FROM cortex_analyst_demo.revenue_timeseries.stats_can_travellers  
)  
SELECT  
  SUM(number_of_travellers) AS total_arrivals  
FROM __stats_can_travellers  
WHERE  
  geo IN ('Toronto - Billy Bishop Toronto City Airport, Ontario', 'Toronto Pearson International Airport, Ontario')  
  AND date = '2024-11-29'  
  -- Генеровано Cortex Analyst  
;

Зверніть увагу на використання конструкції IN. Cortex Analyst достатньо розумний, щоб знайти будь-які значення geo, які містять Торонто в назві, і використовувати їх у предикаті запиту. Ось результати:

pic

Далі я попросив його зробити кілька основних підсумків:

pic

Без проблем:

WITH __stats_can_travellers AS (  
  SELECT  
    geo,  
    date,  
    number_of_travellers  
  FROM cortex_analyst_demo.revenue_timeseries.stats_can_travellers  
)  
SELECT  
  geo AS port_of_entry,  
  SUM(number_of_travellers) AS total_arrivals  
FROM __stats_can_travellers  
WHERE  
  date BETWEEN '2024-11-25' AND '2024-11-30'  
  AND geo IN ('Montreal Trudeau International Airport, Quebec', 'Quebec City Jean Lesage International Airport, Quebec')  
GROUP BY  
  geo  
ORDER BY  
  total_arrivals DESC NULLS LAST  
  -- Генеровано Cortex Analyst  
;

pic

Тепер стало цікаво.

Я запитав те, що, на мою думку, має бути дуже простим питанням:

pic

Інтерпретація запитання виглядає цілком нормально:

pic

Але SQL та результати чітко неправильні:

WITH __stats_can_travellers AS (  
  SELECT  
    date,  
    number_of_travellers  
  FROM cortex_analyst_demo.revenue_timeseries.stats_can_travellers  
)  
SELECT  
  AVG(number_of_travellers) AS average_arrivals_per_day  
FROM __stats_can_travellers  
WHERE  
  date BETWEEN '2024-11-25' AND '2024-11-30'  
  -- Генеровано Cortex Analyst  
;

pic

Набір даних невеликий, але в цей період було набагато більше 125 прибуттів на день.
Ми побачили з попереднього прикладу, що лише в Торонто було 3,203 осіб за один день!

Cortex Analyst, здається, намагається знайти середнє, обчислюючи кількість мандрівників по датах у таблиці statscantravellers, не враховуючи того, що дата повторюється — для однієї і тієї ж дати є записи для кількох географічних місць.

Отже, що станеться, якщо я явно спробую змусити його обчислити середнє?

Я попросив його явно підсумувати кількість прибуттів між двома датами, а потім поділити цей підсумок на кількість днів між цими датами. Тепер я отримую правильну відповідь.

pic

Але по дорозі трапляються деякі цікаві моменти.

По-перше, я отримую інтерпретацію запитання, яка явно визнає, що я намагаюся отримати середнє, хоча я не використовував слово “середнє” у своєму запиті:

pic

Зверніть увагу, що це та ж сама інтерпретація, що й при моїй першій спробі! Але в цьому випадку Cortex Analyst генерує зовсім інший SQL:

WITH __stats_can_travellers AS (  
  SELECT  
    date,  
    number_of_travellers  
  FROM cortex_analyst_demo.revenue_timeseries.stats_can_travellers  
)  
SELECT  
  SUM(number_of_travellers) / NULLIF(COUNT(DISTINCT date), 0) AS average_arrivals_per_day  
FROM __stats_can_travellers  
WHERE  
  date BETWEEN '2024-11-25' AND '2024-11-30'  
  -- Генеровано Cortex Analyst  
;

Навіть назва стовпця тепер така ж, як і в моїй попередній спробі:

pic

Але тепер відповідь правильна.

Cortex Analyst все ще є відносно новим продуктом, і я вважаю, що він обіцяє великі можливості. Цілком ймовірно, що в майбутньому він буде інтегрований до досвіду користувачів Snowflake. Я також підозрюю, що багато з управління метаданими стане більш автоматизованим.

Але навіть так, варто бути обережними та використовувати судження, перш ніж ми зможемо завжди покладатися на відповіді, які він генерує. Безумовно, наразі перший крок при використанні цього буде — зробити "перевірку реальності" на SQL, який генерується.

Загалом, я дуже чекаю, коли зможу більше працювати з цим продуктом, оскільки я бачу, як він може суттєво зменшити навантаження на аналітиків, і потенційно зробити навіть складні запити доступними через природну мову запитів.

Перекладено з: Snowflake Cortex Analyst: Trust But Verify

Leave a Reply

Your email address will not be published. Required fields are marked *