Чому Генеративно-Розширений Захист Даних Є Наступним Рубіжем Аналітики Даних

Три з чотирьох людей кажуть, що їхні організації використовують ІІ. Все ж таки більшість цієї діяльності все ще центрується на неструктурованому контенті: підсумовуванні зустрічей, підготовці електронних листів або автоматизації підтримки клієнтів.

Але іронічно, так багато даних, які насправді керують бізнес-рішеннями – фінансовими звітами, таблицями складу та КПІ – залишаються в основному не зачепленими ІІ.

Причина полягає не в браку амбіцій, а в браку довіри. Коли модель галюцинує речення, це часто можна виправити; коли вона галюцинує число, це катастрофічно. Фінансовий директор не може підписати відповідь, яку він не може перевірити.

Сьогодні структуровані дані живуть по десятках систем, кожна з яких має свої власні правила та відносини. Отримання ІІ для правильного розуміння по цій складності є більш складним завданням, ніж будь-який чат-бот.

Бізнеси та їхні команди – включаючи некваліфікованих користувачів – повинні мати можливість взаємодіяти зі своїми даними простим способом, щоб зменшити затори та отримувати швидкі та точні знання. Без необхідності вивчати SQL.

Деякі рішення з’являються – давайте розглянемо деякі відомі приклади, з їхніми перевагами та їхніми недоліками.

ІІ та структуровані дані – міст занадто далеко

За останні два роки з’явилися кілька спроб зв’язати знання ІІ та структуровані дані.

Багато з них походять від технологічних гігантів з значними ресурсами та даними. Snowflake, наприклад, ввела з її Cortex Analyst, який намагається дозволити користувачам ставити природні мовні питання проти Snowflake сховища даних.

Для покращення точності Cortex має спосіб надання семантичних метаданих – але модель сильно обмежена. По-перше, її потрібно створити вручну, а навіть так, вона може працювати лише з максимально 10 таблицями, чого недостатньо навіть для середньої компанії. Будь-яке збільшення, і довіра розбивається, оскільки точність знижується.

Історія повторюється з спробами Databricks, який прийняв підхід тексту до SQL з AI/BI Genie. Це рішення можна розгорнути лише на малих доменах, втрачаючи точність з збільшенням наборів даних.

Microsoft Power BI Copilot приймає поверхневий генеративний підхід, вбудовуючи ІІ безпосередньо всередині панелей управління для опису візуальних елементів, пропонуючи міри та підготовки звітів. Це покращує дослідження, але не змінює, як аналітика розуміється або верифікується. Кожна відповідь все ж залежить від судження моделі, а коли це судження виходить неправильним, немає аудиторської траси чи детермінірованої логіки, на яку можна спертися.

Колективно, ці системи вказують у правильному напрямку: розгортання ІІ на структурованих підприємствах даних. Але вони також мають критичний недолік. Вони залежать від моделі ІІ для генерації SQL з природної мови, а коли цей SQL неправильний, що відбувається часто, бізнес-користувач застряє. Виконавець, який не може читати SQL, не має можливості діагностувати або виправити результат. Розмова зупиняється.

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

Інший Шлях: Генеративно-Розширений Захист

Генеративно-Розширений Захист (GAR) перевергає поточний підхід RAG (Retrieval-Augmented Generation джерела актуальної інформації та включення її в LLM для підвищення точності).

Натомість запитів GAR використовує генеративний ІІ для розуміння наміру запиту користувача, а потім створює кроки розуміння для генерації відповіді.

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

Це означає, що результати експоненціально точніші, ніж у загальних генеративних двигунах.

У своєму ядрі GAR робить три речі:

1. Автоматично створює семантичний шар. GAR використовує ІІ для відкриття відносин та бізнес-визначень по системах, об’єднуючи дані в одну модель
2. Перекладає бізнес-намір у високорівневу аналітичну мову. Ця мова захоплює запит на рівні бізнес-концепції (“доходи на відвідування за постачальником за Q2”) і компілюється безпосередньо в SQL.
3. Реєструє кожен крок розуміння для аудиторської траси. Походження кожної відповіді можна простежити.

Чому Це Матеріал

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

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

Елемент довіри є критичним для бізнес-користувачів, які залежать від своїх структурованих даних для прийняття інформованих бізнес-рішень. Коли все більше організацій реалізують розширені рішення ІІ, вони будуть вимагати рамок, які приведуть ризик галюцинації та помилки до майже нуля.

Це відбувається, коли запитування безпосередньо зв’язується з вашими даними, коли ІІ може працювати з великими наборами даних без порушення, і коли відповіді надаються з послідовністю та доведенням.