Solid приєднується до ініціативи Open Semantic Interchange від Snowflake

Кожна велика компанія, з якою мені доводилося працювати, постійно веде одну й ту саму суперечку: що саме вважати «активним клієнтом»? У фінансовому відділі одне визначення, у команді зростання — інше, а ML-платформа тихо вигадала третє, поки ніхто не дивився. Семантичні шари мали стати суддею. Але поки що вони здебільшого залишаються ще одним гравцем на полі.

Саме на цьому тлі Solid щойно приєдналася до Open Semantic Interchange — ініціативи під керівництвом Snowflake, спрямованої на те, щоб семантичні визначення були портативними між інструментами. Це схоже на спробу встановити єдиний стандарт колії для значення даних — після двох десятиліть, коли кожен постачальник прокладав власну.

Що сталося

Solid оголосила про приєднання до Open Semantic Interchange (OSI) — ініціативи з відкритим вихідним кодом під керівництвом Snowflake, мета якої — створити універсальну, нейтральну щодо постачальників специфікацію для семантичних моделей. Прес-реліз було опубліковано через PR Newswire 13 липня 2026 року, і, як повідомляв Yahoo Finance Singapore, OSI має забезпечити узгоджені метрики та визначення в дашбордах, ноутбуках і моделях машинного навчання.

Екосистема навколо OSI вже охоплює BI, управління даними, інженерію даних, AI, фінансові послуги та виробництво. Snowflake, позиціонуючи себе як «компанію AI Data Cloud», просуває специфікацію як сполучну тканину, що дозволяє семантичним метаданим переміщатися між платформами без необхідності щоразу моделювати їх вручну.

Позиція Solid — це сторона AI-агентів. Компанія описує себе як AI-нативний контекстний шар для корпоративного AI, який автоматично створює, оцінює та підтримує семантичний контекст для AI-агентів, а не будується для дашбордів і ручного моделювання. Він безперервно тестує точність, виявляє зміни в даних і працює з будь-яким сховищем даних або AI-платформою.

Йоні Лейтерсдорф, CEO та співзасновник Solid, охарактеризував цей крок як ставку на портативність: «Наша участь гарантує, що семантичний контекст зможе автоматично і безперешкодно переміщатися між AI-агентами, сховищами даних, BI-інструментами та аналітичними платформами, дозволяючи організаціям будувати надійні AI-системи на основі спільного, сумісного розуміння свого бізнесу — без прив'язки до конкретного постачальника».

Джош Клар, директор з управління аналітичними продуктами в Snowflake, назвав OSI «критично важливим кроком у побудові фундаменту» для спільної основи між даними та AI. Слово «фундамент» тут несе велике смислове навантаження, але намір зрозумілий: одна специфікація, багато інструментів.

Технічна анатомія

Якщо відкинути мову прес-релізу, OSI намагається вирішити нудну, але дорогу проблему. Семантичний шар — це файл, де ви записуєте, що насправді означає «дохід», «щомісячний активний користувач» або «валова маржа» у термінах SQL, вимірів, фільтрів і об'єднань. У кожного BI-інструменту є такий. У dbt є. У Cube, LookML, MicroStrategy, Power BI — у всіх є. Жоден із них не взаємодіє з іншими. Якщо ви хочете перейти з інструменту A до інструменту B, хтось витрачає квартал на переписування визначень і суперечки щодо граничних випадків.

Пропозиція OSI — нейтральний щодо постачальників формат файлів і специфікація метаданих, яку будь-який із цих інструментів може читати та записувати. На практиці це означає спільний спосіб опису сутностей, мір, вимірів, об'єднань, фільтрів, ієрархій, а також — що важливо для спільноти AI — описів природною мовою та бізнес-правил, необхідних LLM для міркування про них. Якщо ви коли-небудь намагалися підключити агента до запиту вашого сховища і спостерігали, як він вигадує метрику, бо не знає, що означає «відтік» у вашій компанії, — ви розумієте суть проблеми.

Місце Solid — це шар підтримки. Традиційні семантичні шари, на кшталт тих, що ви вручну створювали б у dbt або LookML, передбачають, що людина сідає, моделює бізнес і оновлює файл, коли щось змінюється. Це працює для стабільного дашборду. Але все руйнується, як тільки у вас з'являються агенти, що приймають автономні рішення на основі схем, які змінюються щотижня. Пропозиція Solid — автоматично створювати та переоцінювати цей контекст, тестувати точність і сигналізувати, коли зміни в даних непомітно зламали значення.

Поєднайте ці дві ідеї, і архітектура виглядає так: OSI визначає дротовий формат для семантики, Snowflake (згідно з документацією Snowflake) забезпечує обчислювальний і управлінський субстрат, а Solid вирішує проблему актуальності та правильності на стороні агента. Це теорія. Нудна частина — чи є специфікація достатньо виразною, щоб охопити заплутані об'єднання та віконні функції, що становлять реальну бізнес-логіку, чи вона зупиниться на найменшому спільному знаменнику, який усі терплять, але ніхто насправді не використовує.

Хто програє

Очевидний програшний варіант, якщо OSI набере популярність, — це закритий семантичний шар як конкурентна перевага. Постачальники, які роками замикали клієнтів у пропрієтарних мовах моделювання, відчують тиск так само, як пропрієтарні SQL-діалекти відчули його після появи стандартів ANSI. Якщо головний захист вашого BI-інструменту полягає в тому, що перехід означає переписування п'яти тисяч визначень метрик, формат обміну — погана новина.

Snowflake, очевидно, виграє, якщо це спрацює. Спільний семантичний шар, що живе над сховищем, робить саме сховище стабільним якорем, тоді як інструменти над ним стають товаром. Це та сама гра, яку Databricks веде з Delta та Unity Catalog. Очікуйте, що Databricks або приєднається до OSI, або зробить форк, або випустить щось підозріло схоже впродовж кількох кварталів. Моя думка: вони приєднаються, неохоче, а потім сперечатимуться про місця в керівних органах.

Для AI-нативних аналітичних постачальників — а їх зараз десятки — це тест Роршаха. Якщо ваш продукт залежить від того, що він є єдиним джерелом семантичної істини, відкритий обмін підриває вашу позицію. Якщо ваш продукт справді кращий у складних завданнях (актуальність контексту, вирівнювання агентів, оцінка), ви отримуєте більший доступний ринок, бо можете підключатися до будь-чого. Solid явно робить ставку на другий варіант.

Корпоративні команди даних, тим часом, отримують 90-денний головний біль. Кожен CTO, який затвердив три проекти семантичних шарів, що перекриваються, незабаром отримає листа від архітектора із запитанням: чи варто призупинитися, мігрувати чи почекати, поки OSI дозріє. Кожен, хто пережив міграцію шару метрик, знає: дешевої відповіді немає. Правильний крок зазвичай — уповільнитися, а не прискоритися, коли формується стандарт.

Посібник для команд із даних

Якщо ви зараз керуєте аналітичною інфраструктурою, ось кілька конкретних кроків. По-перше, проведіть аудит того, де насправді живуть ваші визначення метрик. Не де вони мають бути, а де вони є. У більшості компаній це суміш dbt-моделей, пропрієтарного шару одного BI-інструменту, сторінки у вікі з 2023 року та гілки в Slack. Ви не зможете прийняти жодний формат обміну, поки не знаєте, чим обмінюватися.

По-друге, розглядайте специфікацію OSI як обмеження проектування ще до того, як офіційно її приймете. Коли ви пишете нові визначення метрик, запитуйте: чи витримали б вони переклад у нейтральний щодо постачальників формат. Глибоко вкладена логіка, специфічна для конкретного інструменту, — це тепер зобов'язання. Нудний, портативний SQL і чітке вимірювальне моделювання — це активи.

По-третє, якщо ви будуєте AI-агентів над своїм сховищем, вже сьогодні відокремте шар «що означає ця метрика» від шару «як її запитати», навіть якщо робите це вручну. Саме цей інтерфейс стандартизує OSI, і якщо ваша кодова база вже має таку форму, подальша міграція буде завданням відображення, а не переписування.

По-четверте, нічого не вириваєте з коренем. Стандарти займають більше часу, ніж свідчать прес-релізи. Слідкуйте за реальними еталонними реалізаціями, тестами на відповідність і за тим, чи Databricks та основні BI-постачальники додадуть підтримку читання/запису. До того часу OSI — це перспективний напрямок, а не виробнича залежність. Для високопропускних аналітичних навантажень, що перебувають поза семантичною дискусією, такі рушії, як ClickHouse, залишаються окремим рішенням і не залежать від цього ні в той, ні в інший бік.

Ключові висновки

• Solid приєдналася до Open Semantic Interchange під керівництвом Snowflake — ініціативи з відкритим вихідним кодом, що будує нейтральну щодо постачальників специфікацію для семантичних моделей у BI, інженерії даних та AI-інструментах.
• Реальна ціль — AI-агенти, яким потрібен узгоджений бізнес-контекст для надійного міркування про корпоративні дані, а не лише узгодженість дашбордів.
• Диференціатор Solid — автоматизована, безперервно тестована підтримка семантичного контексту, на відміну від застарілих семантичних шарів, що моделюються вручну.
• Закриті семантичні шари втрачають захищеність, якщо OSI набере популярність; сховища даних та справді диференційований інструментарій контексту виграють від цього.
• Командам із даних варто провести аудит того, де насправді живуть визначення метрик, і починати писати нові у формі, яка витримає переклад у нейтральний формат, — не виривати при цьому працюючі системи.

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