Агентам потрібні інтерпретовані значення: семантичні шари, онтології та керовані метрики
Бесідний BI зазнає невдачі, коли значення залишаються нероз’ясненими. Що показують дослідження тексту до SQL, та як семантичний шар, онтологія та канонічні ідентифікатори забезпечують надійність відповідей.
Джерела: Make Meaning Machine-Interpretable Before You Trust the Agent
Уявіть собі щоденну нараду у понеділок. Колега вставляє відповідь агента у Slack: дохід на одного клієнта за попередній квартал, акуратно сформатований, коротко пояснений та поданий з повною впевненістю. Один погляд з боку фінансового відділу — і робота зупиняється. Ця цифра стосується бронювань, тоді як визнаний дохід зберігається в іншій таблиці з іншою структурою даних та власним списком виключень. З SQL не було жодних проблем. Ніхто не зрозумів, що саме означає запитання.
Після достатньої кількості таких ситуацій фраза „модель створила коректний SQL“ більше не вважається ознакою успіху. Больші мовні моделі зробили майже всі документи на складі машинночитабельними. Читабельність — це дешево. Але інтерпретованість є рідкісною якістю: що означають такі поняття, як клієнт, дохід, активність, відхід клієнтів та попередній квартал у цій конкретній компанії для прийняття певного рішення.
До появи агентів люди самі інтерпретували запитання перед тим, як їх сформулювати. Якщо під час виконання доручити це агенту, він створить правдоподібну історію, якщо тільки не буде надано спеціально розробленої версії. Єдиний постійний рішення — керувати корпоративним значенням як продуктом: надати йому ідентичність, створювати версії, тестувати його, прив’язувати до фізичних даних та дозволяти людям та програмному забезпеченню використовувати його однаково.
Для більшості команд кроком до готового продукту є керований семантичний або метричний шар. Довгостроковою метою є модель, заснована на онтології, яка об’єднує всі наступні проекції — чи то LookML, SQL-перегляди, контракти API чи інструменти агентів, — щоб жоден продукт не мусив вигадувати власну „правду“.
Чому впевнена відповідь є ризиком
BI на основі чату часто описують як переклад з природної мови у SQL, що приховує складну частину. Складність полягає у тому, щоб прочитати запитання в одній системі координат та передати його значення в іншу.
Розгляньмо запитання «Який був дохід від кожного клієнта у минулому кварталі?» Для складу легко виконати точний запит. Справжня складність полягає у виборі того запиту, який відповідає цьому запитанню. Під доходом можуть розумітися бронювання, виставлені рахунки чи фактично отриманий дохід. Клієнтом може бути сторона, якій здійснюється продаж, сторона, якій виставляється рахунок, або будь-який вузол ієрархії обліку, який відображається у квартальних звітах про продажі. Минулий квартал може відповідати календарним місяцям, фінансовому року чи іншому періоду, який обирають управлінські процеси.
На панелі керування аналітик вже зробив ці вибори. Плитка під назвою «Дохід» виглядає авторитетною, оскільки семантичне рішення вбудоване безпосередньо в цей елемент інтерфейсу. У чаті порядок змінюється – рішення тепер приймається під час виконання програми для довільних запитань, усередині самого програмного забезпечення, що перетворює семантику зі сторінки wiki на інфраструктуру, яка працює під час виконання програми.
Неприємною наслідком є те, що чим краще модель справляється з правдоподібним SQL, тим небезпечнішими стають її помилки. Синтаксична коректність нічого не говорить про семантичну достовірність. Витончене пояснення може настільки плавно відповісти на неправильне запитання, що ніхто цього не помічає, поки записи з досівки не суперечитимуть журналу чату. Команди, які запитують лише про те, чи виконано запит, навчають себе довіряти витонченій неправді.
Вимірні моделі вже містять певний зміст
Усе це не робить складську систему чистим аркушем. Моделювання у стилі Кімболла протягом десятиліть компенсує те, наскільки мало можуть сказати універсальні реляційні схеми. Факти, виміри, показники, рівень деталізації, ієрархії та узгоджені виміри — усе це вкладає бізнес-зміст у структури, які люди можуть запитувати.
Добре спроєктована зоряна схема вже функціонує як неформальний семантичний шар. Сучасні семантичні шари додають ще більше – вони включають визначення метрик, правила обчислень, термінологію, дозволені зв’язки та бізнес-правила, які назви стовпців не можуть розкрити. Формальна онтологія йде ще далі, розділяючи концептуальну модель від її реляційної реалізації та навмисно створюючи відповідні зв’язки між ними.
Краще розглядати це як континуум, а не процес конвертації:
- операційна реляційна схема
- вимірна модель
- семантичний шар
- формальна онтологія
Чим нижче ми рухаємося у цьому списку, тим більше значень записуємо, змушуючи модель менше здогадуватися. Кожен елемент, що залишається неявним, – це ставка на те, що висновки будуть збігатися з визначенням, яке підтвердив би фінансовий директор.
Що продовжують показувати дослідження
Нещодавні дослідження перетворення тексту на SQL приходять до одного результату: чітке формулювання бізнес-значень підвищує точність, і це справедливо навіть для схем, які вже були створені для аналізу.
У тесті, проведеному Фігейредо та його колегами, модель GPT-4 Turbo була використана зі зірковою схемою. Сама схема давала приблизно 58% правильних запитів, а додавання контекстуальної семантики підняло цей показник до близько 89%. Руміантау та Фокєєв додали короткий семантичний документ до аналітичного складу, заснованого на моделі Contoso, і точність піднялася від приблизно 48 до 52 відсотків, тобто до рівня понад шістдесяти відсотків. Ці покращення мають значення, оскільки вихідними даними не були складні транзакційні схеми.
Коли фізична схема містить менше інформації про бізнес, наслідки стають ще серйознішими. Пейнтер та його колеги працювали над операційною базою даних із понад 500 таблицями та підвищили рівень генерації перевірених SQL-запитів з приблизно 8% до приблизно 78% шляхом надання термінології, правил, взаємозв’язків та мапувань. Насіменто та його колеги спостерігали, як точність виконання операцій у складній промисловій базі даних зросла з 41% до 65% лише завдяки використанню концептуальних назв, орієнтованих на бізнес, а ще на 74%, коли стали зрозумілими корисні семантики взаємозв’язків.
Формальні моделі рухаються в тому самому напрямку. У дослідженні Sequeda, Allemang та Jacob отримано точність близько 17% при прямому запитуванні реляційної бази даних підприємства, тоді як використання графа знань, підтримуваного онтологією, дало приблизно 54%. У наступному дослідженні Nascimento зберіг SQL для виконання, але спочатку використав граф знань для поєднання бізнес-концепцій із фізичною схемою. За показником F1 для поєднання схем один лише LLM показав результат близько 0,85. Підхід із графом досяг 0,90, граф разом із LLM — 0,93, а повний процес семантичного поєднання з ідеальним рівнем відтворення даних — 0,996.
Розумне тлумачення полягає у архітектурному підході, а не у просуванні продукту: необхідно чітко визначити відповідність між концепціями та реляційними структурами, усунути семантичну імпровізацію з моделі та залишити виконання у реляційному двигуні, де він вже ефективно працює.
Що зробив і чого не зробив реляційний модель
Реляційний модель Кодда забезпечила незалежність даних: додатки не повинні залежати від того, як фізично зберігаються дані. Це досягнення залишається важливим.
Діалоговий BI вимагає чогось більш конкретного та складнішого. Сама по собі реляційна аналітична схема не визначає всіх бізнес-значень, необхідних для відповіді на запитання. Імена, ключі, обмеження та коментарі допомагають, а вимірні моделі — ще більше. Проте визначення метрик, ролі термінів, часові конвенції, походження даних та правила відповідності концепцій фізичним об’єктам все ще часто залишаються в головах людей або у презентаціях.
Саме тому навколо складів виникли глосарії, метричні сховища, семантичні шари та каталоги. Вони поступово уточнюють те, що аналітик чи ШІ інакше довелося б імпровізувати. Сучасний семантичний шар є практичною відповіддю у місці використання BI. Він залишається вужчим за загальну концептуальну модель підприємства, і саме сприйняття їх як ідентичних призводить до подальших несподіванок у командах.
Додавання онтології з збереженням складу
У практиці інформатики онтологія описує те, що існує в області дослідження — тобто ентитети, взаємозв’язки та обмеження, — написана так, щоб її міг використовувати програмний забезпечення. Вона має спільне походження з реляційною моделлю в логіці предикатів: це твердження про речі та взаємозв’язки між ними.
Бази даних вже давно працюють над цим. W3C Direct Mapping та R2RML визначають, як реляційні дані перетворюються на RDF-лексикони. Ontology-Based Data Access йде ще далі: користувач ставить запит до концептуальної моделі, а система перекладає його у SQL-запити для вже наявних джерел даних. Ontop — зріла відкрита віртуальна графіка знань — робить саме це за допомогою мапувань R2RML та легких онтологій OWL 2 QL.
Вибір OWL 2 QL має не надто привабливу, але корисну логіку. Він належить до родини DL-Lite, обмеження якої є навмисними, щоб запити, опрацьовувані за допомогою онтології, залишалися придатними для використання з великими реляційними базами даних. Виразність була пожертвована заради можливості переписування коду у формат SQL. Робота над онтологіями для складів та багатовимірних моделей також існувала ще до цього, де представлялися виміри, показники та ієрархії, а з концептуальних моделей отримувалися аналітичні структури.
Що досі майже не знаходить застосування, — це мова онтологій, спрямована безпосередньо на сучасні інструменти BI, яка дозволяє об’єднати бізнес-ентитети, взаємозв’язки, показники, рівень деталізації, агрегацію, час, походження даних та мапування складів у єдиній управлюваній моделі.
Впровадження цього підходу не означає переміщення складу до бази даних у вигляді графа. Значення можна описати в онтології, тоді як факти залишаються у реляційних таблицях, а обчислення — у SQL. Матеріалізація графа є необов’язковою, корисною для завдань, які від неї отримують перевагу, і не є критерієм оцінки.
Збережені факти та їхнє значення
Рядки та тріпли RDF тісніше пов’язані, ніж свідчать суперечки щодо інструментів. Рядок вказує на те, що тупл належить до певної названої реляції, а тріпл розділяє пропозицію на суб’єкт, предикат та об’єкт. Сильна нормалізація вже спрямовує реляційні проекти на створення менших фактів. Ці два підходи не є формально еквівалентними, проте їхній зв’язок є корисним.
Для агентів важливим є не розрізнення між таблицею та графом, а різниця між екстенсійними даними та інтенційним значенням: фактами, які зберігаються, та правилами щодо того, що означають ці факти. Онтологія може стверджувати, що один клас включає інший, що два предикати є оберненими, що зв’язок є транзитивним, або що певна комбінація є неможливою. OWL забезпечує формальну семантику для таких тверджень, SHACL перевіряє форму графів, а для більш складних випадків існують багатші логічні фреймворки.
Не кожна онтологія може бути легко переписана у формат SQL, оскільки деякі мови є більш виразними, ніж це можуть обробити ефективні фрагменти коду для переписування. Дослідження в галузі OBDA відкрито стикаються з цією проблемою, пропонуючи варіанти обмеження виразності, апроксимації, матеріалізації чи обробки в окремому кроці. Це обмеження є корисним, адже воно змушує чітко визначати, яка семантика діє на шляху виконання, яка компілюється заздалегідь, а яка не входить до обраного профілю. Сьогодні мало які компанії фіксують такі втрати, тому вони проявляються у суперечках у чат-каналах.
Контекст постачальника — це не ваша онтологія
Постачальники вже роблять кроки у цьому напрямку. Google Cloud є гарним прикладом, адже кілька з його версій 2026 року орієнтовані на корпоративне середовище, яке можуть використовувати машини. Dataplex Universal Catalog було перейменовано на Knowledge Catalog, і тепер воно більше схоже на динамічну графіку контексту, ніж на статичний реєстр. Воно пропонує семантичний пошук, детальні описи, графи взаємозв’язків, перевірені SQL-шаблони, API контексту та шляхи доступу для агентів. Тим часом Open SQL Interface від Looker дозволяє клієнтам JDBC запитувати моделі LookML так, ніби це схеми, повторно використовуючи вже визначені там виміри, агрегати, обчислення та взаємозв’язки.
Такі оновлення підкреслюють основну ідею: агенту потрібно більше, ніж просто доступ до рядків даних. Йому потрібен ретельно підготовлений контекст, семантичні моделі, взаємозв’язки, перевірені приклади та контрольовані інтерфейси.
Незважаючи на це, їм бракує єдиної цілісної онтології підприємства. Семантика LookML, терміни каталогу, визначення графів у BigQuery та контекст, створений агентами, є пов’язаними, але водночас різними формами представлення. Якщо організація не має канонічних ідентифікаторів та чітких відповідностей між ними, обіцянка визначити щось один раз перетворюється на необхідність визначати це щоразу для кожного продукту.
Через цю пастку було втрачено цілі квартали. Граф контексту постачальника може бути дуже цінним, але не є формальним джерелом семантичної істини. Використовуйте його вільно, пам’ятаючи, що використання не означає власності.
Шість принципів дизайну
Основним правилом, яке стоїть над усіма іншими, є те, що значення має бути зрозумілим як для людей, так і для машин одночасно, та залишатися послідовним у різних формах представлення.
Надайте значенню ідентичність. Кожна концепція, взаємозв’язок, показник, політика та твердження щодо якості мають мати стабільний ідентифікатор. Назва — це лише мітка, тоді як ідентифікатор і є тим, що становить сам об’єкт. Термін «клієнт» зустрічається у панелях керування, API, таблицях складу та підказках для агентів, і все це має вказувати на один семантичний об’єкт, або свідомо на окремі об’єкти, якщо в бізнесі дійсно існують окремі концепції. Відділи підтримки та фінансів можуть по-різному визначати активного клієнта, за умови, що вони ніколи не будуть ділитися однаковим ID без попередження.
Зробіть визначення виконуваними. Проза призначена для людей та моделей, але все, що впливає на обчислення, потребує структури: типів, взаємозв’язків, кардинальностей, одиниць вимірювання, формул, рівня деталізації, допустимого часу, обмежень, правил мапування та політик. Описовий абзац у каталозі — це переважно людська конвенція.
У стеках, побудованих на Google Cloud, один з можливих способів розподілу є наступним. Knowledge Catalog містить ідентифікатори, визначення, одиниці вимірювання, власників, період дії, правила, взаємозв’язки та мапування. LookML містить виконувані формули, виміри, операції об’єднання та генерацію запитів. Conversational Analytics інтерпретує природну мову в контексті цих даних, причому перевірені запити використовуються як орієнтири для регресійного аналізу. Ця структура є стабільною лише за умови, що ідентифікатори навмисно перетинають кожну з цих меж.
Явно відображайте семантику карти у фізичні дані. Припустимо, онтологія стверджує, що Клієнт володіє Рахунком. Тоді реалізація повинна назвати відношення чи процес, які роблять це твердження істинним, причому це відображення має мати версію разом із обома його кінцями. Інструменти одним кліком не можуть перетворити OWL у кожен продукт каталогу. Хтось мусить створювати та підтримувати цей міст, інакше слово «семантика» означатиме не більше ніж просто брендування.
Ставіться до відносин як до чогось надзвичайно важливого. Роль набуває сенсу завдяки своїм зв’язкам із процесами, організаціями, видами діяльності, можливостями та витратами, а не завдяки стовпцю під назвою role_type. Клієнти, продукти, контракти, облікові записи та показники працюють так само. Неформальна номенклатура та проза вже допомагають у перекладі з NL на SQL, але саме формальна семантика відносин відрізняє зручність реляційних структур від онтологічної чіткості. Створення такої семантики вимагає справжніх зусиль, а онтологія, яка ігнорує ці зусилля, гине ще на етапі тестування.
Зберігайте метрики всередині однієї моделі. Вимірювання з використанням димензій вже містять ідентичність, формулу, рівень деталізації та поведінку агрегації, а семантичні шари дозволяють ще більше оптимізувати їх функціонування. Ширше значення, включаючи власність, одиниці вимірювання, виключення, походження даних, правила, дати набрання чинності та зв’язки з корпоративними концепціями, часто потрапляє до інших систем. Фрагментація є справжньою архітектурною проблемою: вимірювання з використанням димензій, вимірювання у форматі LookML та терміни каталогу — кожен з них описує частину однієї бізнес-ідеї, але під трьома різними ідентичностями.
Скомпілюйте один раз, подавайте багатьма способами. Один канонічний модель має генерувати або керувати своїми проекціями — такими як LookML, SQL-перегляди, схеми API, записи каталогу, форми графів, контракти інструментів для агентів, документація та тести на перевірку. Платформи можуть використовувати власну синтаксис, але значення не повинні бути вигадкою самої платформи.
LinkML демонструє, що модель, незалежна від технології, може генерувати SQL DDL, BigQuery DDL, JSON Schema, OpenAPI, OWL, SHACL, документацію та інструменти для перевірки. Однак вона не може самостійно обирати факти, виміри, показники, рівень деталізації чи відповідні виміри від імені користувача. Існують дослідження щодо перетворення онтологій у зіркові схеми, але жодна з поширених систем не здійснює повний процес від канонічної онтології через керований сховище вимірів та виконувану семантичну модель до перетворення тексту на SQL на основі онтології. Саме у цьому відсутньому етапі полягає інженерна складність, а генерація DDL — це лише проста демонстрація.
Два підходи та необхідність їх об’єднання
Більшість підприємств не можуть призупинити програму складування та спочатку перебудувати її навколо онтології. Це нормально. Завдання полягає у тому, щоб забезпечити агентам надійне розуміння значень того, що можна відправити, та спроєктувати такий тактичний підхід, який дозволить їм розвиватися.
Згідно з планом А, канонічна онтологія підприємства має семантичну авторитетність, стабільні ідентифікатори та чітку логічну семантику. Фізичні дані не змінюються, а онтологія відображається у відносних та інших форматах представлення. Метрики аналітики стають скомпільованими прогнозами. Агенти отримують формальні концепції, відношення, правила та інформацію про походження, а зміни версіонуються та випускаються так само, як і код. Представлення всередині продуктів генеруються на основі семантики, якою володіє підприємство, або відображаються за її допомогою.
План B починається з вже зайнятої території: це шар метрик під керуванням, поєднаний із каталогом та моделлю контексту, до яких навмисно додаються стабільні канонічні ID. Склад залишається авторитетним джерелом інформації, а мапування семантичних об’єктів на таблиці, стовпці, операції об’єднання та фільтри фіксується. Агенти вибирають сертифіковані поля та метрики замість сирих таблиць, отримуючи контекст від сервісів контексту, перевірених запитів та процедур пошуку, які дотримуються правил доступу. Метрики, мапування, „золоті“ запити та тести семантичної регресії включаються до процесу CI/CD. ID, прив’язані до конкретного продукту, ніколи не перетворюються на корпоративні ідентифікатори, а механізми переходу забезпечують можливість міграції.
Конкретний план B у Google Cloud поєднує Knowledge Catalog для надання контексту та пошуку з Looker, де керована семантична модель дозволяє обмежувати аналітику розмов до сертифікованих семантичних об’єктів, зберігати перевірені запити як орієнтири для аналізу змін та утримувати ідентифікатори підприємства поза межами будь-якого окремого продукту. Knowledge Catalog схожий на онтологію лише у вузькому сенсі, пропонуючи типований контекст та взаємозв’язки для агентів, але не є повноцінною формальною онтологічною системою. Сприймайте його як матеріал, а не як священний текст.
Ризик полягає у такому тактичному семантичному шарі, чиї ідентифікатори та логіка ніколи не можуть бути перенесені до більш формальної моделі. План B, який не може досягти конвергенції, — це глухий кут, прикрашений панелями керування.
Спочатку вирішіть проблему, потім працюйте з таблицями
Розумний підхід до аналітики розмов не повинен починатися з вибору таблиць. Він має починатися з семантичного вирішення проблем.
Візьмімо запитання «Чи зросла відтік серед клієнтів роздрібної торгівлі високої вартості цього кварталу?» Перш ніж щось інше, терміни «відтік», «клієнти роздрібної торгівлі високої вартості» та «цей квартал» мають бути перетворені на керовані об’єкти. У цих об’єктах зберігаються визначення метрики, її класифікація, правила форматування часу, дозволені виміри, мапування джерел та правила її обчислення. Лише після цього шар виконання може сформувати фізичний запит.
Команди, які працюють у циклі, повинні мати змогу описати процес виконання у вісім кроків:
- Запитання та контекст користувача
- Семантичне перетворення на керовані концепції та метрики
- Отримання контексту з фільтрацією за правилами та дозволами
- Мапування семантичних об’єктів на фізичні дані
- Створення запиту чи плану використання інструментів
- Виконання та узгодження результатів
- Відповідь, підкріплена доказами та походженням даних
Підхід зовсім не полягає у простому вставленні аналітичної схеми до запиту та сподіванні на кращий результат. Штучний інтелект все ще може прояснити намір та скласти план, але це відбувається через керовані семантичні об’єкти та контракти інструментів, а не шляхом декодування словникового запасу фінансового директора з таблиці під назвою fct_rev_v3.
Перевірені запити є цінними як тести та приклади, але вони не є семантикою. Вони лише доводять, що певне запитання в певний момент було вирішене шляхом прийнятної реалізації. Справжнє значення все ще потребує власної ідентичності та визначення.
Що не вважається семантичною архітектурою
Каталог, наповнений описами у прозі, сприяє пошуку інформації. Це не є виконуваною семантичною системою.
За замовчуванням спрямування агентів на необроблені схеми складу та називання цього самообслуговуваного BI лише переміщує семантичний ризик на ймовірнісну модель.
Дублювання кожної інформації про склад у граф знань „для ШІ“ без чіткої користі від реалізації створює другу версію корпоративної правди, яка відстає через затримки синхронізації.
Повне розділення метрик від онтології настільки, що одна бізнес-концепція отримує суперечливі ідентичності в BI та в моделях знань, створює проблеми в майбутньому.
Плутання представлення з семантикою, наприклад, шляхом припущення, що граф за своєю природою є більш семантичним, ніж вимірна модель, — це мислення типу „культури вантажу“. Вимірні моделі, семантичні шари, графи знань та онтології кожен по-різному кодують значення, і вибір графа сам по собі не додає значення.
Розглядати метадані чи взаємозв’язки, створені ШІ, як факти без вказання джерела чи статусу перевірки, — ось як правдоподібна вигадка перетворюється на політику.
Мета в одному реченні
Люди хотіли б отримувати дані за минулий місяць так само легко, як запитують про погоду. Це вже не фантазія. Програмному забезпеченню доручається семантична робота, яку раніше без уваги виконували аналітики та інженери, а отримання послідовних відповідей означає усвідомлене виконання цієї роботи.
Ані ШІ, підключене до складу, ані каталог у поєднанні з векторним пошуком не є кінцевою метою. Це керована семантична система, у якій поняття, взаємозв’язки, показники, обмеження, політика, якість та джерело залишаються однаковими для людей та машин, пов’язані формальними відповідностями з базовими даними.
Більша частина основних даних все ще найкраще обробляється за допомогою реляційних та SQL-аналітичних двигунів, і технології семантики чи онтологій ще не можуть їх замінити. Їхнє завдання — довести модель до рівня, який реляційна схема сама по собі ніколи не могла б підтримувати, навіть після того, як дименсійне моделювання та ретельне найменування елементів довели її ступінь деталізації до максимуму.
Якщо створення та підтримка повноцінної аналітичної онтології поки що нереалістично, слід використовувати керований семантичний шар, але зберігати заголовок незмінним. Семантика має мігрувати вгору, з панелей керування та запитів у першокласну корпоративну модель, причому кожен власний шар продукту має розглядатися як скомпільований перегляд.
Метою є не окрема база даних, інструмент чи синтаксис. Це єдине значення, яке людина, панель керування, додаток та штучний інтелект розуміють однаково. Якщо ці чотири елементи не погоджуються, проблема не в ШІ. Це проблема ідентичності, яка була відкладена.
Пов’язана література
- Концепції LangGraph простою мовою: стан, пам’ять та оркестрація — Перш ніж писати код: що означають оркестрація, час виконання, агенти зі станом, короткострокова та довгострокова пам’ять, багатоагентні системи та участь людини в LangGraph.
- Практичні нотатки: Оцінка агента та виявлення відхилень — що таке новий кодувальний агент — Детальний посібник з Практичних нотаток: Оцінка агента та виявлення відхилень — що таке новий кодувальний агент: контракти, перевірки та шаблони коду для команд, які використовують цю схему.