Агенты данных, управляемые онтологией, в Microsoft Fabric IQ: практическое руководство

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

Question
   ↓
LLM
   ↓
Vector Search / RAG
   ↓
Documents
   ↓
Answer

Новая модель основана на рассуждениях на основе бизнес-значений:

Business Question
                           │
                           ▼
                    Agent / Planner
                           │
                 ┌─────────┴─────────┐
                 ▼                   ▼
          Semantic Model          Ontology
          "How measured?"      "What does it mean?"
                 │                   │
                 └─────────┬─────────┘
                           ▼
                    Enterprise Data
                           │
                           ▼
                   Insight / Decision
                           │
                           ▼
                         Action

Это различие имеет огромное значение.

Обычная база данных может сообщить агенту что-то вроде:

customers.CustomerId = sales.CustomerId

В отличие от этого, онтология может сообщить агенту:

Customer ── PURCHASES ──> Product

А семантическая модель может пойти еще дальше и сообщить ему:

Total Revenue = governed enterprise measure

Это представляет собой три совершенно разных уровня понимания.

Microsoft объединяет эти идеи в рамках Fabric IQ: семантическая модель обеспечивает надежные аналитические показатели, онтология предоставляет общий корпоративный словарь и структуру взаимосвязей, слой графов позволяет перемещаться по связанным данным, а Data Agents отображают всю эту информацию в формате диалога. Microsoft рассматривает Fabric IQ как слой бизнес-контекста, преобразующий сырые аналитические и операционные данные в бизнес-концепции, с которыми агент может эффективно работать.

Архитектурная особенность, делающая это по-настоящему интересным, заключается в следующем:

Вы можете опубликовать Fabric Data Agent и сделать его доступным через Model Context Protocol (MCP), так что агенты Microsoft Foundry — или любые другие агенты, совместимые с MCP — смогут использовать управляемую корпоративную информацию как ещё один инструмент.

Microsoft теперь поддерживает именно такой процесс: опубликованный Fabric Data Agent может отображаться агенту Foundry в качестве инструмента MCP, а один агент Foundry может затем координировать несколько Fabric Data Agents наряду с другими инструментами и источниками знаний.

1. Почему онтологии снова стали важны

Онтологии — это не новая идея.

Графы знаний тоже не являются чем-то новым.

Семантические модели также не новы.

На самом деле изменилось то, кто их использует.

Исторически корпоративные семантические технологии в основном использовались:

• платформами поиска
• инструментами BI
• системами интеграции данных
• системами управления таксономиями
• приложениями на основе графов
• экспертами в определенных областях

Теперь появился новый пользователь:

Агенты ИИ.

И здесь агенты сталкиваются с реальными препятствиями.

Большие языковые модели хорошо обрабатывают информацию, предоставленную им, однако корпоративные базы данных почти никогда не описывают бизнес так, как люди естественным образом его воспринимают.

Например:

CUSTOMER_MASTER.CUST_ID
SALES_TXN.CUST_ID
SALES_TXN.PROD_NM
SALES_TXN.NET_REV

Человек же мыслит в таких терминах:

Customer
   │
   │ PURCHASES
   ▼
Product
   │
   └── generates → Revenue

Разница между этими двумя способами представления является причиной значительной неопределенности у агента.

Из-за отсутствия семантической основы агент вынужден догадываться:

• какие таблицы соответствуют тем или иным бизнес-концепциям
• какие соединения действительно допустимы
• что на самом деле представляет собой та или иная колонка
• какое определение метрики следует считать авторитетным
• как связаны между собой объекты
• означают ли два поля с разными названиями на самом деле одно и то же

Это еще терпимая проблема в демо-версии с пятью таблицами.

При использовании сотен корпоративных продуктов для обработки данных это становится действительно рискованным.

Функция Ontology в Fabric разработана специально для создания машинночитаемого, общедоступного бизнес-словаря, состоящего из типов сущностей, свойств, отношений, ограничений и связей с реальными данными OneLake. Этот словарь может использоваться как людьми, так и автоматизированными агентами.

2. Но «граф знаний» не означает единую архитектуру

Визуальная схема принятия решений, сопровождающая это обсуждение, помогает прояснить, почему выбор подхода на основе графов и онтологий не является универсальным решением.

[Вставить: Схема принятия решений по решениям с графами и онтологиями]

Не существует единственного правильного способа проектирования графа.

Эту сферу можно приблизительно разделить на пять типовариантов.

Тип 1 — RDF / Семантический граф знаний

Это традиционный подход семантической сети:

Subject ─ Predicate ─> Object

Обычно он сочетается с:

RDF
RDFS
OWL
SPARQL

Преимущества: богатая выразительная семантика, взаимодействие на основе стандартов, зрелые методы моделирования онтологий и поддержка формального рассуждения.

Недостатки: большая сложность моделирования, необходимость в специализированных навыках и инфраструктура, которая часто превышает потребности самого приложения.

3. Графы свойств с метками

Модель графа свойств с метками (LPG) использует более ориентированный на приложение подход:

(Customer)
    │
    │ PURCHASED
    │ {date, quantity}
    ▼
(Product)

И узлы, и рёбра могут иметь собственные свойства.

Инструменты вроде Neo4j сделали эту модель популярной, поскольку она идеально подходит для приложений, требующих частого просмотра структуры графа.

Преимущества: интуитивное моделирование графов, высокая производительность при просмотре структуры графа, совершенствованные алгоритмы обработки графов и богатый опыт разработки приложений.

Недостатки: сама схема графа не превращается в управляемый корпоративный семантический словарь — этот уровень значений всё равно необходимо моделировать и управлять отдельно.

Microsoft Fabric Graph использует этот подход LPG, преобразуя таблицы OneLake в типы узлов и рёбер, а также предоставляя возможность просмотра структуры графа с помощью GQL. Реализация GQL в Microsoft соответствует стандартизированному ISO языку запросов к графам.

4. Более простой путь: онтология плюс граф в оперативной памяти

Не каждому агенту требуется полная корпоративная база данных графов.

Для приложений в стиле чата, сценариев с ограниченным функционалом, помощников с узким диапазоном задач или проектов типа proof-of-concept достаточно представить простую онтологию в виде обычного JSON:

{
  "entities": {
    "Customer": {},
    "Product": {}
  },
  "relationships": {
    "Purchases": {
      "from": "Customer",
      "to": "Product"
    }
  }
}

Ваш слой приложений может затем загрузить это определение в NetworkX, Memgraph, библиотеку RDF или любую другую структуру графа в памяти.

Такой подход быстро настраивается и дешев в эксплуатации.

Однако проблема заключается в том, что вопросы управления, безопасности, отслеживания происхождения данных, масштабирования, синхронизации информации и совместного управления семантическими определениями требуют вашего личного решения.

5. Почему Microsoft Fabric выделяется среди других

Fabric решает эту проблему с другой точки зрения.

Вместо того чтобы исходить из предпосылки, что вся корпоративная информация должна быть мигрирована в базу данных графов, архитектура может начинаться с предпосылки, что корпоративные данные остаются там, где находятся, в OneLake, а семантическая и связевая информация добавляется поверх них.

В виде диаграммы:

Fabric IQ
                            │
          ┌─────────────────┼──────────────────┐
          │                 │                  │
          ▼                 ▼                  ▼
   Semantic Model        Ontology            Graph
          │                 │                  │
   trusted metrics     business meaning    traversal
          │                 │                  │
          └─────────────────┼──────────────────┘
                            │
                         OneLake

Microsoft четко разделяет эти функции: семантические модели обеспечивают надежные показатели эффективности и аналитические структуры, онтология предоставляет общий бизнес-словарь, граф используется для перемещения по связанным данным, а агенты данных или операций обеспечивают интеллектуальное взаимодействие и действия, основанные на этом контексте.

Такое разделение обязанностей имеет важное значение с архитектурной точки зрения.

6. Семантическая модель, онтология и граф — это три разных понятия

Эти термины часто используются как синонимы. На самом деле это не так.

Полезный способ понимания:

DATA
"What happened?"
       │
       ▼
SEMANTIC MODEL
"How should it be measured?"
       │
       ▼
ONTOLOGY
"What does it mean?"
       │
       ▼
GRAPH
"How is everything connected?"
       │
       ▼
AGENT
"What should I investigate or do?"

Семантическая модель Power BI может определять такие показатели, как:

Total Revenue
Average Order Value
Customer Count
Revenue by Segment

Онтология может определять сущности и связи, такие как:

Customer

Product

Customer ── PURCHASES ──> Product

Граф — это то, что фактически реализует и позволяет перемещаться по этим связям:

Customer A
   │
   ├── PURCHASES → Laptop
   │
   ├── PURCHASES → Monitor
   │
   └── PURCHASES → Dock

Затем агент обработки данных предоставляет всю эту информацию через взаимодействие на естественном языке.

Fabric также позволяет создавать онтологию непосредственно на основе существующей семантической модели: таблицы превращаются в типы сущностей, столбцы — в свойства, а отношения, уже определенные в семантической модели, становятся отношениями в онтологии.

7. Создание продукта: минимальный продукт данных о продажах

Чтобы сосредоточиться на архитектуре, а не на инженерии данных, пример намеренно остается простым.

Используются только две исходные таблицы:

NP_SalesDataProduct_LH

customers
──────────────
CustomerId
CustomerName
Segment
City
State
Country
sales
──────────────
OrderId
OrderDate
CustomerId
ProductName
ProductCategory
Quantity
UnitPrice
DiscountPct
Revenue
SalesChannel

Отношение между ними простое:

customers.CustomerId
         1
         │
         *
sales.CustomerId

Этого достаточно, чтобы рассмотреть всю архитектуру, не позволяя сложности моделирования мешать основной идее.

8. Шаг 1 — Создание продукта данных Fabric

Два файла CSV загружаются в Fabric Lakehouse:

NP_SalesDataProduct_LH
│
├── Tables
│   └── dbo
│       ├── customers
│       └── sales
│
└── Files
    ├── customers.csv
    └── sales.csv

[Вставить скриншот: Lakehouse с отображением клиентов и продаж]

На этом этапе у вас уже есть функционирующий Fabric Data Agent.

Он может отвечать на вопросы о общем объеме доходов, категориях продуктов, приносящих наибольший доход, и распределении доходов по сегментам клиентов.

Но под капотом происходит что-то примечательное.

Поскольку дополнительная семантика не определена, агенту приходится самостоятельно вычислять способ объединения данных:

customers.CustomerId
       =
sales.CustomerId

и ему также приходится самостоятельно определять:

Revenue → SUM(Revenue)

Это дает вам основу для сравнения.

9. Шаг 2 — Добавление семантической модели

Далее вы вводите аналитический контракт.

Customer
    1
    │
    *
Sales

с управляемыми показателями, такими как:

Total Revenue =
SUM(sales[Revenue])

и:

Total Orders =
DISTINCTCOUNT(sales[OrderId])

На этом этапе агенту больше не нужно догадываться о значении «Общий доход».

Это определение относится к семантическому слою.

Это указывает на важный принцип для корпоративных агентов:

Агенты должны использовать управляемые метрики, а не воссоздавать корпоративные расчеты из сырых данных каждый раз, когда поступает вопрос.

10. Шаг 3 — Добавление онтологии

Отсюда переход от аналитических определений к бизнес-значению.

Онтология в этом упражнении определяет всего два типа сущностей:

Customer

Product

Клиент соответствует:

customers.CustomerId
customers.CustomerName
customers.Segment
customers.City
customers.State
customers.Country

использование:

KEY = CustomerId

Товар, в свою очередь, получается непосредственно из существующей таблицы sales:

sales.ProductName
sales.ProductCategory

использование:

KEY = ProductName

Опять же, для работы этого не требовалось создавать отдельную физическую таблицу Product.

11. Определение бизнес-связи

Далее добавляется связь:

Customer
     │
     │ PURCHASES
     ▼
Product

Интересной частью здесь является то, как работает привязка данных.

Сама таблица sales выступает в качестве моста для этой связи:

Customer.CustomerId
        ↑
sales.CustomerId

sales.ProductName
        ↓
Product.ProductName

Таким образом, простая строка данных о продажах вида:

sales row:

CustomerId = C001
ProductName = Laptop Pro

превращается в:

Customer(C001)
       │
       │ PURCHASES
       ▼
Product(Laptop Pro)

Именно в этот момент простая реляционная запись превращается во что-то, что бизнес действительно может распознать как знание.

Модель онтологии Fabric разработана специально для такого рабочего процесса: сначала определяются типы сущностей и их связи, затем эти абстрактные определения привязываются к конкретным данным, хранящимся в OneLake.

12. Что меняется для агента?

Возьмем следующий вопрос:

Какие продукты покупают клиенты категории Enterprise?

Без наличия онтологии агенту приходится рассуждать примерно так:

Find customers table
      ↓
Find Segment
      ↓
Filter Enterprise
      ↓
Determine CustomerId join
      ↓
Join sales
      ↓
Find ProductName

При наличии онтологии процесс рассуждений упрощается до:

Customer
   │
Segment = Enterprise
   │
   └── PURCHASES ──> Product

Этот вопрос практически напрямую соответствует самой модели.

Microsoft описывает этот сдвиг как переход агентов от мышления в терминах отдельных таблиц к управляемому представлению, построенному на основе сущностей, связей, определений, правил и маппингов источников.

13. Шаг 4 — Создание агента Fabric Data

Агент Data преобразует всё это в интерфейс естественного языка:

User
                        │
                        ▼
                NP_Sales_DataAgent
                        │
          ┌─────────────┼─────────────┐
          ▼             ▼             ▼
      Lakehouse    Semantic Model   Ontology
          │             │             │
      raw facts     trusted KPIs   relationships
          │             │             │
          └─────────────┼─────────────┘
                        ▼
                     OneLake

Microsoft описывает Fabric Data Agents как слой для ответов на вопросы на естественном языке, ограниченный определенной областью данных, причем онтология обеспечивает более глубокий деловой контекст, на котором опираются эти агенты.

14. Затем следует важный архитектурный шаг: MCP

Fabric Data Agent не обязан оставаться внутри Fabric.

Его можно опубликовать.

После публикации Fabric предоставляет этот агент в качестве сервера Model Context Protocol.

Концептуально процесс выглядит следующим образом:

Fabric Data Agent
       │
       │ Publish
       ▼
MCP Server
       │
       ├── tool description
       ├── input schema
       └── governed execution

В этот момент ваша корпоративная система анализа данных становится чем-то переиспользуемым — инструментом-агентом, который могут вызывать другие системы.

15. Microsoft Foundry становится слоем оркестрации

Это открывает возможность для гораздо более интересной архитектуры.

USER
                              │
                              ▼
                   Microsoft Foundry Agent
                              │
                   planning / orchestration
                              │
          ┌───────────────────┼───────────────────┐
          │                   │                   │
          ▼                   ▼                   ▼
      CRM Tool            Search Tool        Fabric MCP
                                                  │
                                                  ▼
                                        Fabric Data Agent
                                                  │
                              ┌───────────────────┼───────────────┐
                              ▼                   ▼               ▼
                         Semantic Model       Ontology        Lakehouse
                              │                   │               │
                              └───────────────────┼───────────────┘
                                                  ▼
                                               OneLake

Здесь важно разделение ответственностей.

Агент Foundry отвечает за обработку рабочих процессов.

Агент Fabric Data отвечает за обработку данных.

В текущей версии интеграции Foundry от Microsoft позволяет агенту Foundry находить опубликованные агенты Fabric Data через Fabric IQ / OneLake Catalog и рассматривать их как инструменты MCP. Один агент Foundry также не ограничен одной областью — он может одновременно использовать несколько агентов Fabric Data.

16. Пример работы

Представьте, что пользователь отправляет агенту Foundry запрос следующего содержания: найти сегмент клиентов, вносящий наибольший вклад в доходы, определить, какие продукты способствуют успешной работе этого сегмента, и превратить полученные результаты в рекомендации, которые сможет использовать команда продаж.

Вот как может происходить выполнение этого запроса:

USER
 │
 ▼
Foundry Orchestrator
 │
 │ "I need enterprise sales intelligence."
 │
 ▼
Fabric Data Agent MCP Tool
 │
 ├── Semantic Model
 │      → trusted revenue calculation
 │
 ├── Ontology
 │      → Customer → PURCHASES → Product
 │
 └── Lakehouse
        → transaction data
 │
 ▼
Result:
Enterprise customers generate...
Laptop category contributes...
 │
 ▼
Foundry Agent
 │
 ├── reasoning
 ├── CRM lookup
 ├── recommendation generation
 └── potentially action
 │
 ▼
Sales recommendation

Здесь важно не то, что языковая модель сгенерировала рекомендацию. Важно то, что эта рекомендация основана на структурированном бизнес-представлении, а не создана импровизированно на основе сырых таблиц или предположений относительно семантики.

17. MCP меняет архитектуру корпоративных агентов

Без MCP команды обычно подключают компоненты следующим образом:

Agent A → custom Fabric integration

Agent B → another custom Fabric integrationAgent C → another SQL implementationAgent D → another Power BI integration

Со временем каждый агент накапливает глубокие, хрупкие знания о подложной платформе данных.

При использовании MCP картина меняется:

Enterprise Agents
        ┌───────────┼───────────┐
        ▼           ▼           ▼
     Agent A     Agent B      Agent C
        │           │           │
        └───────────┼───────────┘
                    │
                 MCP Tool
                    │
                    ▼
             Fabric Data Agent
                    │
                    ▼
             Governed Data IQ

Агент обработки данных Fabric превращается в продукт аналитики данных, предназначенный для использования агентами, вместо индивидуальной системы интеграции, которую каждой команде приходится создавать заново. Это кажется незначительным изменением, но имеет важное архитектурное значение.

18. Еще один вариант: прямое предоставление онтологии

Существует ещё один вариант, который стоит рассмотреть.

Вместо того чтобы направлять всё через Fabric Data Agent, саму онтологию Fabric можно сделать доступной через MCP для любого совместимого внешнего агента. Microsoft описывает сервер MCP для онтологий, входящий в комплект с инструментами для поиска типов сущностей онтологии и выполнения запросов к ней.

Это даёт два различных подхода:

PATTERN A

External Agent
      │
      │ MCP
      ▼
Fabric Data Agent
      │
      ▼
Ontology

против:

PATTERN B

External Agent
      │
      │ MCP
      ▼
Fabric Ontology

Выбирайте первый подход, когда хотите использовать собственный слой обработки данных и взаимодействия Fabric. Выбирайте второй, когда у внешнего агента уже есть собственная сложная логика планирования и ему просто нужен более прямой доступ к корпоративной семантической модели.

19. Преимущества и недостатки подхода Fabric

Преимущества

Централизованная семантика. Бизнес-определения хранятся в одном контролируемом месте, вместо того чтобы их копировали и вставляли в каждый запрос.

Создано на базе OneLake. Нет строгой необходимости копировать всю вашу базу данных в отдельную платформу графов.

Три уровня, работающие вместе. Аналитические показатели и семантика на уровне связей могут сосуществовать в рамках семантической модели, онтологии и графа.

Разработано для агентов. Как Fabric Data Agents, так и слой онтологии были созданы специально для того, чтобы служить источниками данных для ИИ-агентов.

Открытость через MCP. Полученный слой интеллекта может использоваться как Foundry, так и пользовательскими клиентами MCP.

Четкое разделение обязанностей.

Fabric → data intelligence

Foundry → orchestration intelligence

Это разделение создает довольно четкую границу на уровне предприятия.

20. Компромиссы

Существует несколько важных ограничений.

Большая часть этого функционала по-прежнему является технологией предварительного просмотра. Поддержка онтологий, несколько интеграций Fabric IQ и Foundry, а также связанные возможности MCP остаются функциями предварительного просмотра, поэтому перед использованием в производственных условиях следует ознакомиться с текущими правилами предварительного просмотра от Microsoft.

Управление онтологиями — это постоянная работа. Как только несколько доменов начнут определять собственные сущности вроде Customer, Account, Product, Contract и подобные, кому-то придется заниматься номенклатурой, версионированием и согласованием между доменами.

Онтология не может исправить плохие данные. Даже если обернуть низкокачественный набор данных в элегантные бизнес-семантики, ответы всё равно будут некачественными.

Онтология не всегда необходима. Для простого агрегирования KPI может оказаться проще и достаточно напрямую обращаться к семантической модели.

Не каждый сценарий использования графов подходит для этого. Сложные алгоритмы обработки графов, специализированное рассуждение в стиле RDF или высокоиндивидуальные задачи с графами могут потребовать использования специализированной платформы для графов.

Именно поэтому полезна поэтапная система принятия решений.

21. План действий, который я бы использовал

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

Этап 1 — продукты на основе данных

Sources
   ↓
OneLake
   ↓
Domain Data Products

Цель здесь — создание надежных данных домена с четко определенными владельцами.

Этап 2 — Аналитическая семантика

Data Product
     ↓
Semantic Model
     ↓
Measures / KPIs / Dimensions

На этом этапе определяется способ измерения показателей организацией.

Этап 3 — Бизнес-семантика

Semantic Models + Data Products
             ↓
          Ontology
             ↓
Entities / Relationships / Rules

На этом этапе определяется реальное значение измеряемых показателей.

Этап 4 — Взаимосвязанная интеллектуальность

Ontology
   ↓
Graph
   ↓
Traversal / dependency / impact analysis

На этой стадии графовые структуры применяются только там, где анализ взаимосвязей действительно необходим.

Этап 5 — Агенты данных домена

Ontology + Semantic Model + Data
                 ↓
             Data Agent

Здесь накопленные знания домена преобразуются в формат, пригодный для общения.

Этап 6 — MCP

Data Agent
    ↓
Publish
    ↓
MCP

На этом шаге продукт, созданный для общения, преобразуется в функциональность, которую могут использовать другие агенты.

Этап 7 — Оркестрация корпоративных агентов

Foundry Agent
                          │
       ┌──────────────────┼──────────────────┐
       ▼                  ▼                  ▼
 Sales Data Agent    Supply Agent       Finance Agent
       │                  │                  │
       └──────────────────┼──────────────────┘
                          │
                     Fabric IQ

Microsoft уже движется в этом направлении: агенты Foundry могут получать данные из нескольких опубликованных Fabric Data Agents через Fabric IQ, причем каждый из этих агентов представлен в виде инструмента MCP.

Какова будет дальнейшая тенденция

Более крупные архитектурные изменения выглядят следующим образом:

GENERATION 1

                        LLM + RAG
                           │
                       Documents

развиваясь в:

GENERATION 2

                    LLM + Tools + Data
                           │
                     SQL / APIs / RAG

и в конечном итоге превращаясь в:

GENERATION 3

                      Agent Systems
                           │
             ┌─────────────┼─────────────┐
             ▼             ▼             ▼
         Documents       Tools       Enterprise IQ
                                         │
                              ┌──────────┼──────────┐
                              ▼          ▼          ▼
                          Semantics   Ontology    Graph
                              │          │          │
                              └──────────┼──────────┘
                                         ▼
                                   Enterprise Data

В этой области ключевым фактором будет всё меньше значить, какая модель наиболее сильна. Вместо этого преимущество будет у той организации, которая создала наиболее богатый контекстный слой предприятия, из которого могут черпать данные эти модели. Microsoft называет своё общее направление развития Microsoft IQ, при этом Fabric IQ обеспечивает контекст о бизнес-элементах и данных, совместно работая с Work IQ, Foundry IQ и Web IQ.

Такой подход остается актуальным.

Нельзя доверять агенту выполнение части работы в компании только потому, что он хорошо умеет находить документы.

Ему необходимо понимать:

Что такое те или иные вещи.

Как они связаны друг с другом.

Как организация на самом деле их измеряет.

Какие определения имеют авторитет.

Каково текущее состояние этих вещей.

И, в конечном счёте:

Какие действия имеют смысл с учётом всего этого.

Заключение: от RAG к корпоративному рассуждению

RAG дал корпоративному ИИ способ получения знаний.

Использование инструментов дало агентам способ взаимодействия с системами.

Онтология даёт им совершенно другое:

значение.

Когда это значение сочетается с управляемыми метриками, графовыми связями, реальными операционными данными и оркестрацией агентов, получается гораздо более привлекательная архитектура:

DATA
 │
 ▼
SEMANTICS
 │
 ▼
ONTOLOGY
 │
 ▼
CONNECTED INTELLIGENCE
 │
 ▼
DATA AGENTS
 │
 ▼
MCP
 │
 ▼
ENTERPRISE AGENTS
 │
 ▼
DECISIONS
 │
 ▼
ACTIONS

В конечном итоге это и есть настоящая ценность аналитики, основанной на онтологиях и агентах.

Это не просто ещё один чат-бот, прикреплённый к базе данных.

Это архитектура корпоративной интеллектуальности, в которой продукты данных предоставляют факты, семантические модели — надёжные показатели, онтологии — смысл, графы — связи, доменные агенты — интеллектуальную информацию, а MCP позволяет объединять всю эту информацию в рамках более широкой экосистемы агентов.

Именно такое сочетание делает создание следующего поколения корпоративного ИИ гораздо более интересным.