Онтологія чи семантичний шар? Що потрібно штучному інтелекту від кожного з них.
У чому різниця між онтологіями та семантичними шарами, що відбувається, коли існує лише один з них, де застосовуються графи знань та практичний порядок створення шару контексту.
Джерела: **Ontology vs. Semantic Layer: Why Your AI Agent Needs Both**
Якщо поставити три джерелам одне запитання про суму доходу, відповіді часто різняться: 10,2 млн від відділу фінансів, 10,4 млн від відділу маркетингу, 9,8 млн від AI-асистента в Slack. Ніхто не погоджується. Раніше люди вирішували це під час короткої зустрічі. Агент не буде писати колезі з запитанням про значення певного показника, тому, зустрівши стовпець під назвою rev_ttm_adj_v2, він або вигадує щось, або бере перше знайдене визначення.
За повідомленнями, використання моделюваного доменного знання під час пошуку даних знизило рівень галюцинацій приблизно на 40%. Це справджується лише тоді, коли знання існує у моделюваній формі, а не лише в пам’яті кількох людей, які створили таблиці. Об’єм зберігання та кваліфікація агента мають мало значення, якщо між ними є лише сирі таблиці та SQL-запити, адже бізнес не буде покладатися на результати отримані таким чином.
Шар контексту
Шар контексту називає функцію, а не продукт. Він збирає семантичні визначення, знання в конкретній галузі, історію розвитку, правила управління, показники якості та статус сертифікації та робить їх доступними через один інтерфейс як для людей, так і для агентів.
Онтології та семантичні шари виконують тут основну роботу. Маркетинг виробників часто змішує їх, але кожен з них вирішує іншу проблему, а їхнє створення у неправильній послідовності призводить до проектів ШІ, які виглядають чудово на демо-версії, але зупиняються ще до впровадження в промислове використання.
Розподіл обов’язків у одному реченні
Коротка версія: семантичний шар вирішує питання на кшталт того, який був обсяг доходів, тоді як онтологія — питання на кшталт того, що таке клієнт.
Семантичний шар відповідає за метрики. Він визначає, як розраховуються дохід, кількість активних користувачів на місяць та життєва цінність, які дані використовувати та які фільтри застосовувати, щоб усі команди та інструменти отримували ідентичні результати.
Онтологія відповідає за значення. Вона визначає, що вважається клієнтом, як клієнти пов’язані з замовленнями, що робить когось клієнтом преміум-класу, та чи може програмне забезпечення робити нові висновки на основі вже збережених даних.
Онтологія: концепції, взаємозв’язки, міркування
Типове визначення – це чітке формальне описування спільної концептуалізації, яке складається з трьох частин:
- Класи: типи елементів у домені, наприклад Клієнт, Продукт, Замовлення, Регіон.
- Властивості та взаємозв’язки: спосіб, яким ці елементи пов’язані між собою. Клієнт здійснює замовлення, а продукт належить до певної категорії.
Онтології пишуться за стандартами W3C, такими як RDF та OWL, тож машини можуть не лише їх читати, а й робити з ними логічні висновки. Припустимо, онтологія стверджує, що клієнт класу Platinum має річний дохід понад 1 мільйон, а факти показують, що Acme має дохід 2 мільйони. Система самостійно робить висновок, що Acme належить до класу Platinum, причому ніхто не писав конструкції типу „якщо-то“. Семантичні шари та інструменти BI не можуть цього зробити — вони виконують заздалегідь визначені обчислення та ніколи не виводять фактів, які не були визначені.
Онтології також з’єднують словники між системами. CRM використовує термін «Клієнт», ERP — «Клієнт», фінансові системи — «Рахунок», а онтологія приводить усі ці поняття до одного бізнес-об’єкта. Агент, який керується таким підходом, слідує за з’єднаною схемою замість того, щоб здогадуватися на основі роз’єднаних таблиць. У охороні здоров’я стандартом є SNOMED CT, у фінансових послугах — FIBO, а в регульованих секторах формальна онтологія майже є обов’язковою.
Ціна також є очевидною. Palantir перетворила корпоративні онтології на окрему ринкову категорію, проте їх створення є складним процесом: потрібні інженери, які працюватимуть безпосередньо в проекті, ручне моделювання, час створення повноцінної онтології становить від шести до вісімнадцяти місяців, а кадри знань у галузі формальної логіки є дуже обмеженими.
Семантичний шар: показники та цифри, які узгоджуються
Цей напрямок роботи є більш практичним. У 1990-х роках Business Objects запровадила Universe — інструмент для подання бізнес-термінології поруч із складними схемами. Основна проблема залишається незмінною: дохід розраховується по-різному, цифри суперечать одна одній, що знижує довіру. Сьогодні ризики ще більші, адже раніше невідповідності призводили лише до незручних діаграм, а тепер можуть спричинити використання вигаданих чисел у звітах, які впливають на прийняття рішень.
Сучасний семантичний шар складається з чотирьох частин:
- Хранилище метаданих, яке відображає зв’язок між такими елементами, як mrr_calc_v3, та щомісячними повторюваними доходами.
- Механізм бізнес-логіки, який зберігає формули для вимірювань в одному місці, щоб їх можна було визначити один раз та використовувати знову.
- Механізм перекладу запитів, який створює операції об’єднання та фільтрацію даних.
- Контроль доступу, який послідовно застосовує дозволи на рівні рядків та стовпців.
Технології розвиваються дуже швидко. dbt додав Семантичний шар, який працює за допомогою MetricFlow — цей інструмент зберігає визначення метрик у форматі YAML під контролем версій та компілює їх у різні версії SQL. У вересні 2025 року Snowflake, Salesforce, dbt Labs та BlackRock розпочали проєкт Open Semantic Interchange (OSI), а його версія 1.0, випущена у січні 2026 року, надала нейтральний формат для обміну семантичними метаданими. Такі продукти, як Cube, AtScale, LookML, DAX, Databricks Metric Views та Snowflake Semantic Views, всі рухаються в одному напрямку — а саме до того, що семантичний шар стає звичайним елементом інфраструктури для обробки даних, готових до використання в ШІ.
Проте існує обмеження. Цей шар може точно вказати, як розраховується дохід, але не те, як клієнт під’єднується до ринку та його правил, ані чи заслуговує обліковий запис на позначку високого ризику згідно з правилами домену. Джессіка Талісман у своїй статті для Metadata Weekly чітко це сформулювала: семантичні шари відповідають за пошук інформації, а онтології — за контекст та логіку.
Що погіршується, якщо є лише один шар
- Лише семантичний шар дає точні, але поверхневі відповіді. Який канал приніс найбільший обсяг продажів минулого місяця? Є точна відповідь. Чому він знизився, чи має витрати зрости? Мовчання, адже ніщо не моделює взаємозв’язок між каналами, витратами та профілями клієнтів.
- Онтологія сама по собі добре описує концепції, але не справляється з графіками. Чи це Acme Platinum? Цілком логічно. Що принесла Acme минулого місяця? Знову три суперечливі відповіді, тому що система не має жодних посилань на таблицю даних чи правила агрегації.
Цифри галузі підтверджують це. Gartner прогнозує, що до кінця 2027 року понад 40% проєктів з штучним інтелектом будуть скасовані через високі витрати, нечітку користь та недостатній контроль. Серед 248 керівників з управління даними, яких опитали, 63% визнали, що у них відсутні практики для підтримки штучного інтелекту. Рідко коли причиною є сама модель; дані, які лежать в її основі, не мають семантичного обґрунтування.
Тренд розвивається також у протилежному напрямку. У прогнозі саміту Gartner 2026 року передбачається, що до 2030 року універсальні семантичні шари стануть частиною інфраструктури даних та кібербезпеки як критично важливих елементів, а компанія Futurum прогнозує зростання їхнього використання з 16% цього року до 30% у 2031 році. Microsoft презентує можливість вбудованої підтримки онтологій у Fabric IQ, тоді як Timbr.ai пропонує семантичні шари з функціями міркувань. Ці два підходи рухаються один до одного.
Графи знань та таксономії
Граф знань зберігає окремі екземпляри, тож фактичні клієнти та замовлення відображаються у вигляді вузлів. Онтологію можна вважати схемою, а граф знань — самими даними. Агент, який аналізує зв’язки під час виконання, переміщується по цьому графу.
Таксономія — це спрощена онтологія: ієрархії батьківських та дочірніх елементів без жодних висновків та бічних посилань. Каталоги продуктів, класифікація доменів даних та позначення персональних даних зазвичай починаються саме з цього, і це гарна відправна точка. Повна онтологія стає необхідною лише тоді, коли агенту потрібно робити висновки між категоріями, наприклад, щоб з’ясувати, чи впливає зниження рівня в категорії А на наявність товарів у категорії B.
Як все взаємопов’язано
Шар контексту складається з двох частин:
- Контекст даних: онтологія, семантичний шар, граф знань, історія походження даних, показники якості та політика доступу. Він пояснює ШІ, в якій галузі він працює.
- Контекст застосунку: уподобання користувача, історія розмов, документи домену та отримані факти (пам’ять плюс RAG). Він пояснює ШІ, з ким він спілкується.
Одне запитання проходить через чотири етапи:
- Онтологія визначає таке поняття, як визнання доходів, разом із приєднаними до нього правилами.
- Семантичний шар перетворює це на обчислення: які таблиці необхідно об’єднати та як здійснити агрегацію.
- Граф знань пов’язує поняття з його показниками, ланцюгом походження та користувачами на наступних етапах.
- MCP надає агенту контекст у момент здійснення висновків.
Тут зустрічаються два роки дискусій щодо проектування контексту: надійний результат вимагає структурованого контексту, а онтології та семантичні шари є двома найскладнішими елементами. MCP вирішує проблему доставки, а не змісту. Якщо надати агенту неконтрольовані таблиці та SQL, протокол буде вірно передавати хибну інформацію.
Підхід одного постачальника
Один з постачальників баз даних описує своє рішення як відкриту семантичну стеку, що також називається OSI, яка об’єднує метрики, визначення, необроблені дані, граф контексту та онтологію замість іншого семантичного шару BI. Вона складається з трьох шарів:
- Нижній – семантичний шар: визначення метрик, правила обчислень та відповідності між вимірами та даними. Він базується на стандарті Ant-OSI, працює з промисловим OSI та вже використовується в продакшені в Ant Group.
- Середній – граф контексту: метрики, об’єкти, події, лінійні зв’язки та споживачі, пов’язані між собою у вигляді мережі, якою LLM може працювати значно ефективніше, ніж із необробленими схемами чи YAML.
- Верхній – шар онтології: бізнес-семантика, узгоджена з семантикою баз даних, із термінами, специфічними для робочого простору, та концепціями на рівні всієї компанії, які пов’язані між собою та розвиваються за власними графіками.
Основний принцип полягає у семантиці коду. Визначте семантику один раз, а потім дозвольте інструментам BI створювати панелі керування, агентам писати SQL-запити, а інструментам управління відстежувати ланцюжок змін — усе на основі цього ж визначення, без окремих семантик для BI, AI та управління. Під час тестування продукту у клієнтів цього постачальника точність перетворення природної мови на дані значно перевершувала альтернативи. Стверджується, що моделі не роблять продукти унікальними, адже всі називають однакові технології LLM; справжню різницю створює якість семантичного контексту. Використання правильних бізнес-визначень замість сирих таблиц значно підвищує точність перетворення природної мови на SQL, ніж налаштування запитів.
З чого почати
Почніть з семантичного шару, коли:
- Команди не погоджуються щодо значення понять «дохід» чи «активні користувачі».
- Проєкт стосується аналітики розмов чи взаємодії з даними через чат.
Починайте з онтології у таких випадках:
- Організація працює у сфері фінансів, охорони здоров’я чи уряду з суворими вимогами до дотримання правил.
- Штучний інтелект має здійснювати міждисциплінарні міркування, наприклад, за критеріями клієнта, продукту чи регуляції.
- Одна й та сама концепція має різні назви у кількох системах.
- Необхідна автоматизована класифікація чи виявлення аномалій на основі правил.
Для більшості підприємств практичний порядок дій є таким:
- Спочатку створіть семантичний шар, централізувавши основні показники, щоб BI та ШІ використовували однакові визначення.
- Спочатку робіть онтологію простою – як бізнес-глосарій, а не як повноцінну структуру OWL.
- Додайте механізми керування: інформацію про походження даних, показники якості, власників та сертифікацію.
- Зробіть усе це доступним для агентів через MCP, що перетворює шар контексту з діаграми на інфраструктуру.
dbt не надає онтології, а онтологія у стилі Palantir не підходить кожній команді. Розвиток від глосарію до формальної онтології є набагато реалістичнішим, ніж спроба все створити одразу.
Власний план розвитку виробника також демонструє поступовість. У короткостроковій перспективі семантичний шар потрапляє до кожного робочого простору, де є централізовано керовані показники та пошукова термінологія. У середньостроковій перспективі з’являються глосарії, ієрархії категорій та взаємозв’язки ентитетів спочатку у вигляді таксономії, а потім отримують можливість взаємодії між системами та базове міркування, розвиваючись поступово для кожної галузі. Довгострокове питання полягає у тому, що відбувається, коли галузі, які окремо моделювали свою семантику, змушені її об’єднати, та як забезпечити еволюцію локальних та глобальних визначень.
Пов’язана література
- Чому AI-агентам потрібен шар управління, а не просто кращі запити — Запити впливають лише на одну взаємодію, а не на весь робочий процес. Як шар управління, що складається з правил, обмежень контексту, повноважень та підтвердження завершення, робить кодувальні агенти надійними.
- Чому пам’ять кодувального агента повинна містити лише критичні дані та як її організувати — Пам’ять агента має фіксувати лише те, що модель не змогла вгадати. Чотири тести для кожної запису, три вимоги до зберігання та чому markdown підходить у git.