Агентам нужно интерпретируемое значение: семантические слои, онтологии и управляемые метрики
Беседный BI терпит неудачу, когда смысл остается неясным. Что показывают исследования текста в SQL, и как семантический слой, онтология и канонические идентификаторы обеспечивают надежность ответов.
Источники: Make Meaning Machine-Interpretable Before You Trust the Agent
Представьте себе еженедельное собрание в понедельник. Коллега вставляет ответ агента в Slack: доход от каждого клиента за предыдущий квартал, аккуратно сформатированный, кратко объясненный и представленный с полной уверенностью. Один взгляд отдела финансов — и все замирают. Эта цифра относится к бронированиям, тогда как признанный доход хранится в другой таблице с иной структурой данных и собственным списком исключений. С SQL всё было в порядке. Никто так и не разобрался, что именно означает поставленный вопрос.
После множества подобных ситуаций фраза «модель сгенерировала корректный SQL» уже не считается признаком успеха. Большие языковые модели сделали почти все документы на складах машинопонимаемыми. Машинопонимаемость — это дешево. Но интерпретируемость — редкость: что означают такие понятия, как клиент, доход, активные пользователи, отток и предыдущий квартал в конкретной компании для принятия конкретного решения.
До появления агентов люди сами интерпретировали запросы перед их формулировкой. Если передать эту задачу агенту во время выполнения, он придумает правдоподобную историю, если только не будет предоставлена специально разработанная версия. Постоянное решение заключается в управлении корпоративным значением как продуктом: присвоить ему идентификатор, вести версионирование, тестировать, связать с физическими данными и обеспечить одинаковое использование как людьми, так и программным обеспечением.
Для большинства команд этап готовности к использованию — это управляемый семантический или метрический слой. Долгосрочной целью является модель, основанная на онтологии, которая компилирует последующие проекции — будь то LookML, представления SQL, контракты API или инструменты агентов, — чтобы ни один продукт не вынужден был создавать собственную «частную истину».
Почему уверенный ответ представляет собой риск
BI на основе чатов часто описывают как преобразование естественного языка в SQL, но это название скрывает сложную часть задачи. Сложность заключается в том, чтобы понять вопрос в одной системе координат и перенести его смысл в другую.
Рассмотрим вопрос: «Каковы были доходы от каждого клиента в прошлом квартале?» Для склада выполнение точного запроса — простая задача. Сложность заключается в выборе того запроса, который соответствует этому вопросу. Под доходами могут пониматься заказы, счета-фактуры или уже учтенные доходы. Клиентом может быть сторона, которой осуществлено продажу, сторона, на которую выставлен счет, или любой узел иерархии счетов, указанный в квартальных отчетах о продажах. Прошлый квартал может соответствовать календарным месяцам, финансовому году или другому временному периоду, выбранному отделом операций.
На панели управления аналитик уже сделал все необходимые выборы. Картинка с надписью «Доходы» выглядит авторитетной, поскольку семантическое решение заложено непосредственно в этот элемент интерфейса. В чате порядок меняется: решение принимается во время выполнения запроса, для произвольных вопросов, внутри программного обеспечения, что превращает семантику из элемента вики-страницы в часть инфраструктуры, работающей в реальном времени.
Неприятным последствием является то, что чем лучше модель справляется с правдоподобными 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 для связывания схем один только большой язык моделирования показал результат около 0,85. Подход с графом дал результат 0,90, комбинация графа и большого языка моделирования — 0,93, а полная семантическая система с идеальным уровнем воспроизведения данных — 0,996.
Разумное толкование заключается в архитектурных аспектах, а не в рекламных целях: необходимо явно определить соответствие между концепциями и реляционными структурами, избавить модель от необходимости в семантической импровизации и оставить выполнение операций в реляционном движке, где он уже эффективно функционирует.
Что сделал и чего не сделал реляционный модель
Реляционная модель Кодда обеспечила независимость данных: приложения не должны зависеть от того, как физически хранятся данные. Это достижение по-прежнему имеет важное значение.
Диалоговый BI требует чего-то более конкретного и сложного. Сама по себе реляционная аналитическая схема не содержит всех бизнес-аспектов, необходимых для ответа на вопрос. Имена, ключи, ограничения и комментарии помогают, а многомерные модели помогают ещё больше. Однако определения метрик, роли терминов, временные конвенции, происхождение данных и правила соответствия концепций физическим объектам по-прежнему часто остаются в головах людей или в презентациях.
Именно поэтому вокруг хранилищ данных появились глоссарии, метрические хранилища, семантические слои и каталоги. Они постепенно превращают в явное то, что аналитик или большая языковая модель иначе пришлось бы выдумывать импровизированно. Современный семантический слой представляет собой практическое решение на этапе использования BI-систем. Он остается более узким, чем общая концептуальная модель предприятия, и именно считание их идентичными приводит к тому, что команды позже сталкиваются с неожиданностями.
Добавление онтологии при сохранении хранилища
В практике информатики онтология описывает то, что существует в рассматриваемой области — а именно сущности, связи и ограничения, — причем она формулируется так, чтобы её мог использовать программный код. Она имеет общее происхождение с реляционной моделью в предикатной логике: это утверждения о вещах и связях между ними.
Базы данных уже давно занимаются этой проблемой. W3C Direct Mapping и R2RML определяют, как реляционные данные преобразуются в RDF-лексиконы. Подход Ontology-Based Data Access идет еще дальше: пользователь запрашивает концептуальную модель, а система преобразует этот запрос в SQL-запрос для уже существующих источников данных. Ontop — зрелая open-source виртуальная графа знаний — делает именно это с помощью маппингов 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 от Looker позволяет клиентам JDBC запрашивать модели LookML так, как будто это схемы, повторно используя уже определенные там размерности, агрегаты, вычисления и связи.
Подобные релизы подчеркивают одну основную идею: агенту нужно нечто большее, чем простой доступ к строкам данных. Ему необходимы тщательно отобранные данные контекста, семантические модели, связи, проверенные примеры и структурированные интерфейсы.
Тем не менее, у них отсутствует единая целостная онтология предприятия. Семантика LookML, термины каталога, определения графов в BigQuery и контекст, создаваемый агентами, представляют собой взаимосвязанные, но разные формы представления информации. Если организация не располагает каноническими идентификаторами и явными связями между ними, обещание определить что-либо один раз превращается в необходимость делать это для каждого продукта отдельно.
Из-за этой ловушки теряются целые кварталы работы. Граф контекста поставщика может быть очень ценным, но не являться формальным источником семантической истины. Можно свободно его использовать, помня при этом, что использование не означает владение.
Шесть принципов проектирования
Главное правило заключается в том, что значение должно быть понятно как людям, так и машинам одновременно, и оставаться последовательным во всех формах представления.
Присвойте значению идентификатор и смысл. Каждая концепция, связь, показатель, правило и утверждение о качестве должны иметь стабильный идентификатор. Название — это лишь метка, тогда как идентификатор и есть сущность самого объекта. Термин «клиент» встречается в панелях управления, API, таблицах склада и подсказках для агентов, и все они должны относиться к одному семантическому объекту или, если в бизнесе действительно существуют отдельные концепции, — к разным объектам. Отделы поддержки и финансов могут по-разному определять понятие «активный клиент», при условии что они никогда не будут использовать один и тот же идентификатор без явного указания на это.
Сделайте определения исполняемыми. Проза предназначена для людей и моделей, но всё, что влияет на вычисления, требует структуры: типов, связей, кардинальностей, единиц измерения, формул, уровня детализации, допустимого времени, ограничений, правил отображения и правил политики. Описательный абзац в каталоге во многом является человеческой конвенцией.
В стеках, построенных на Google Cloud, одно из работоспособных распределений выглядит следующим образом. Knowledge Catalog хранит информацию об идентификаторах, определениях, единицах измерения, владельцах, сроках действия, правилах, взаимосвязях и соответствиях. LookML содержит исполняемые формулы, размерности, операции объединения данных и механизмы генерации запросов. Conversational Analytics анализирует естественный язык на основе этого контекста, причем проверенные запросы служат ориентирами для регрессионного анализа. Такая структура существует только в том случае, если идентификаторы намеренно пересекают границы между этими компонентами.
Явно соотносите семантику с физическими данными. Предположим, что в онтологии указано, что Клиент владеет Учётной записью. В таком случае реализация должна назвать отношение или процесс, делающий это утверждение истинным, причём такая связь должна версионироваться вместе с обеими её сторонами. Инструменты одним кликом не могут преобразовать формат OWL в любой продукт каталога. Кто-то должен создавать и обслуживать такие мосты между форматами, иначе понятие «семантика» будет означать не более чем просто брендинг.
Относитесь к связям как к чему-то первостепенному. Значение роли определяется её связями с процессами, организациями, действиями, возможностями и затратами, а не столбцом с названием role_type. То же самое касается клиентов, продуктов, контрактов, счетов и показателей. Неформальное название и стиль изложения уже способствуют преобразованию текста из естественного языка в SQL, но именно формальная семантика связей отличает удобство использования реляционных структур от онтологической ясности. Их формирование требует значительных усилий, и онтология, игнорирующая эту стоимость, терпит неудачу уже на этапе пилотирования.
Сохраняйте метрики внутри одной и той же модели. Вертикальные метрики уже содержат информацию об идентичности, формуле, уровне детализации и поведении при агрегации, а семантические слои позволяют ещё больше использовать этот потенциал. Более широкое понимание, включающее информацию об владельце, единицах измерения, исключениях, происхождении данных, правилах, датах вступления в силу и связях с корпоративными концепциями, часто оказывается распределённым по другим системам. Фрагментация зачастую является настоящей архитектурной проблемой: вертикальная метрика, метрика в формате LookML и термин каталога — каждый из них описывает часть одной бизнес-идеи, но под тремя разными идентичностями.
Скомпилируйте один раз — используйте множество способов. Один канонический модель должен генерировать или регулировать все свои проекции: LookML, представления SQL, схемы API, записи каталога, структуры графов, контракты инструментов для агентов, документацию и тесты на верификацию. Платформы могут использовать собственную синтаксис, но они не имеют права изобретать смысл.
LinkML демонстрирует, что модель, независимая от технологии, может генерировать SQL DDL, BigQuery DDL, JSON Schema, OpenAPI, OWL, SHACL, документацию и инструменты проверки. Однако она не может выбирать факты, измерения, размерность данных или соответствующие им измерения от имени кого-либо. Существуют исследования по преобразованию онтологий в звездообразные схемы, но ни одна из распространённых систем не обеспечивает полный путь от канонической онтологии через управляемый хранилище измерений и исполняемую семантическую модель до преобразования естественного языка в SQL на основе онтологии. Именно в отсутствии этой цепочки и заключается инженерная сложность, причём генерация DDL — это лишь простая демонстрация.
Два пути и необходимость их слияния
Большинство предприятий не могут временно остановить программу управления складом и сначала перестроить её на основе онтологии. Это нормально. Задача заключается в том, чтобы агенты надёжно определяли смысл того, что можно отправить, и спроектировать такой тактический путь, который позволит им совершенствоваться.
Согласно плану А каноническая корпоративная онтология обладает семантическим авторитетом, имеет стабильные идентификаторы и чёткую логическую семантику. Физические данные не изменяются, а онтология отображается в реляционных и других форматах представления. Метрики аналитики преобразуются в скомпилированные прогнозы. Агенты берут формальные концепции, отношения, правила и информацию о происхождении данных; изменения версионируются и выпускаются так же, как и код. Представления внутри продуктов генерируются на основе семантики, принадлежащей предприятию, или отображаются в соответствии с ней.
План B начинается с уже занятой территории: слой метрик с управлением, сочетаемый с каталогом и моделью контекста, к которым намеренно добавляются стабильные канонические идентификаторы. Хранилище остается источником авторитетных данных, а сопоставление семантических объектов с таблицами, столбцами, операциями объединения и фильтрами фиксируется в записях. Агенты используют сертифицированные поля и метрики вместо необработанных таблиц, черпая контекст из сервисов контекста, проверенных запросов и механизмов поиска, соблюдающих правила доступа. Метрики, сопоставления, «золотые» вопросы и тесты на семантическую регрессию включаются в процесс CI/CD. Локальные идентификаторы продукта никогда не превращаются в корпоративные идентификаторы, а механизмы связи обеспечивают возможность миграции.
Конкретный план Б для Google Cloud сочетает Knowledge Catalog, обеспечивающий контекст и возможность поиска, с Looker, где используется управляемая семантическая модель, ограничивающая анализ диалогов только сертифицированными семантическими объектами, сохраняющая проверенные запросы в качестве точек отката и хранящая корпоративные идентификаторы вне какого-либо отдельного продукта. Knowledge Catalog похож на онтологию лишь в узком смысле, предоставляя типизированный контекст и связи для агентов, но не являясь полноценной формальной онтологической системой. Рассматривайте его как ткань, а не как священный текст.
Риск заключается в том, что такой тактический семантический слой, чьи идентификаторы и логика никогда не могут быть перенесены в более формальную модель, приведет к тупику, украшенному дашбордами.
Сначала решите проблему, затем занимайтесь таблицами
Надежный путь к аналитике на основе диалогов не должен начинаться с выбора таблиц — он должен начинаться с семантического разрешения проблем.
Возьмем вопрос: «Увеличилась ли отток среди клиентов розничной торговли с высокой стоимостью в этом квартале?» Термины «отток», «клиенты розничной торговли с высокой стоимостью» и «этот квартал» должны сначала преобразоваться в соответствующие управляемые объекты. В этих объектах хранятся определения метрик, их классификация, правила временных рамок, допустимые размерности, информация о источниках данных и правила их обработки. Только после этого слой выполнения может сформировать физический запрос.
Команды, работающие с циклами обработки, должны уметь описать процесс выполнения в восьми шагах:
- Вопрос и контекст пользователя
- Семантическое преобразование в управляемые понятия и метрики
- Поиск контекста с учетом правил и разрешений
- Сопоставление семантических объектов с физическими данными
- Создание запроса или плана использования инструментов
- Выполнение запроса и сверка результатов
- Ответ, подкрепленный доказательствами и информацией о происхождении данных
Подход совсем не заключается в простом вставлении аналитической схемы в запрос и ожидании результата. ГЛМ всё ещё может прояснить намерения и составить план, но он работает с управляемыми семантическими объектами и контрактами инструментов, а не путём декодирования словаря CFO из таблицы с именем fct_rev_v3.
Проверенные запросы ценны как тесты и примеры, но они не являются семантикой. Они лишь доказывают, что один вопрос в определённый момент был решён с принятой реализацией. Само значение всё ещё требует собственной идентичности и определения.
Что не считается семантической архитектурой
Каталог, полный описаний в прозе, способствует поиску информации. Он не является исполняемой семантической системой.
По умолчанию направление агентов на необработанные схемы складов и называние этого самообслуживающимся BI лишь переносит семантические риски на вероятностную модель.
Дублирование каждого факта о складе в граф знаний «для ИИ» без четкой выгоды от его использования приводит к появлению второй версии корпоративной правды, отстающей из-за задержек с синхронизацией.
Полное разделение метрик от онтологии так, что одна бизнес-концепция получает противоречивые идентификаторы как в BI, так и в моделях знаний, создает предпосылки для конфликтов в будущем.
Путаница между представлением и семантикой, например, предположение о том, что граф по своей природе более семантичен, чем дименциональная модель, является проявлением ошибочного мышления. Дименциональные модели, семантические слои, графы знаний и онтологии каждый по-своему кодируют значение, и выбор графа сам по себе не добавляет смысла.
Рассматривание метаданных или взаимосвязей, созданных ИИ, как фактов без указания их происхождения или статуса проверки — вот как правдоподобная выдумка превращается в политику.
Цель в одной строке
Люди хотели бы получать данные за прошлый месяц так же легко, как спрашивают о погоде. Это уже не фантазия. Программному обеспечению поручается выполнять семантическую работу, которую раньше без внимания выполняли аналитики и инженеры, и для получения последовательных ответов необходимо сделать эту работу явной.
Ни ИИ, встроенный в склад, ни каталог в сочетании с векторным поиском не являются конечной целью. Речь идет о управляемой семантической системе, в которой понятия, взаимосвязи, показатели, ограничения, правила, качество и происхождение имеют одинаковое значение как для людей, так и для машин, связанные формальными отображениями с данными, находящимися в их основе.
Большая часть основных данных по-прежнему лучше обрабатываться с помощью реляционных и SQL-аналитических движков, и технологии семантики или онтологий пока не способны заменить их. Задача семантики — довести модель до уровня, который реляционная схема сама по себе никогда не могла бы обеспечить, даже при использовании методов дименционального моделирования и тщательного называния элементов.
Если создание и поддержка полноценной аналитической онтологии пока нереалистично, следует внедрить управляемый семантический слой, но сохранить его структуру неизменной. Семантика должна постепенно переходить из дашбордов и интерактивных инструментов в первоклассную корпоративную модель, причем каждый продукт должен иметь свой собственный слой, рассматриваемый как скомпилированный вид данных.
Цель не в единой базе данных, инструменте или синтаксисе. Цель — в едином значении, которое человек, панель управления, приложение и ИИ-агент интерпретируют одинаково. Если у них разные мнения, проблема не в LLM. Это проблема идентичности, которая была отложена.
Связанные материалы
- Концепции LangGraph простым языком: состояние, память и оркестрация — Прежде чем писать код: что означают оркестрация, время выполнения, агенты с состоянием, краткосрочная и долгосрочная память, многопроцессные агенты и участие человека в LangGraph.