Agenci danych napędzane ontologią w Microsoft Fabric IQ: Praktyczny przewodnik
Dowiedz się, w jaki sposób Microsoft Fabric IQ łączy modele semantyczne, ontologie oraz MCP, aby przenieść agenty AI w przedsiębiorstwach od wydobywania danych do zorganizowanego rozumowania biznesowego.
Źródła: Microsoft Fabric IQ and Data Agents for Ontology based Consumption
TL;DR AI w środowiskach korporacyjnych przechodzi znaczącą transformację. Pierwsza fala generatywnej AI w firmach koncentrowała się głównie na odzyskiwaniu danych. Następna fala agentów korporacyjnych pójdzie dalej niż tylko pobieranie informacji — będą one rozumować w oparciu o ustalone znaczenia biznesowe.
Question
↓
LLM
↓
Vector Search / RAG
↓
Documents
↓
Answer
Nowoczesny model opiera się na rozumowaniu w oparciu o znaczenia biznesowe:
Business Question
│
▼
Agent / Planner
│
┌─────────┴─────────┐
▼ ▼
Semantic Model Ontology
"How measured?" "What does it mean?"
│ │
└─────────┬─────────┘
▼
Enterprise Data
│
▼
Insight / Decision
│
▼
Action
Ta różnica ma ogromne znaczenie.
Zwykła baza danych może powiedzieć agentowi coś w rodzaju:
customers.CustomerId = sales.CustomerId
Z drugiej strony ontologia może powiedzieć agentowi:
Customer ── PURCHASES ──> Product
A model semantyczny może pójść o krok dalej i powiedzieć mu:
Total Revenue = governed enterprise measure
To reprezentuje trzy zupełnie różne poziomy zrozumienia.
Microsoft łączy te koncepcje w ramach Fabric IQ, gdzie model semantyczny dostarcza wiarygodnych wskaźników analitycznych, ontologia oferuje wspólne słownictwo i strukturę relacji przedsiębiorstwa, warstwa grafowa umożliwia przeglądanie powiązanych danych, a agenci danych prezentują całą tę inteligencję poprzez rozmowę. Microsoft przedstawia Fabric IQ jako warstwę kontekstu biznesowego, która przekształca surowe dane analityczne i operacyjne w koncepcje biznesowe, nad którymi agent może faktycznie rozumować.
Architektoniczny element, który sprawia, że to jest naprawdę interesujące, polega na następującym:
Można opublikować agenta danych Fabric i udostępnić go za pośrednictwem Model Context Protocol (MCP), dzięki czemu agenci Microsoft Foundry — lub jakikolwiek inny agent kompatybilny z MCP — mogą korzystać z zarządzanej inteligencji przedsiębiorstwa jak z kolejnego narzędzia.
Microsoft teraz obsługuje dokładnie taki przepływ: opublikowany Fabric Data Agent może pojawić się jako narzędzie MCP dla agenta Foundry, a jeden agent Foundry może następnie koordynować kilka Fabric Data Agentów wraz z innymi narzędziami i źródłami wiedzy.
1. Dlaczego ontologia nagle znów staje się ważna
Ontologia nie jest nowym pomysłem.
Grafy wiedzy również nie są czymś nowym.
Również modele semantyczne nie są nowością.
To, co faktycznie się zmieniło, to osoby, które je używają.
Historcznie technologie semantyczne w przedsiębiorstwach były wykorzystywane głównie przez:
- platformy wyszukiwawcze
- narzędzia BI
- systemy integracji danych
- zarządzanie taxonomiami
- aplikacje oparte na grafach
- ekspertów w danej dziedzinie
Teraz pojawia się nowy użytkownik:
agenty AI.
A tu agenty napotykają prawdziwą przeszkodę.
Wielkie modele językowe dobrze przetwarzają informacje, które otrzymują, ale bazy danych korporacyjne prawie nigdy nie opisują biznesu w sposób, w jaki ludzie naturalnie o nim myślą.
Naprzимер:
CUSTOMER_MASTER.CUST_ID
SALES_TXN.CUST_ID
SALES_TXN.PROD_NM
SALES_TXN.NET_REV
Człowiek natomiast myśli w kategoriach takich jak:
Customer
│
│ PURCHASES
▼
Product
│
└── generates → Revenue
Różnica pomiędzy tymi dwoma sposobami reprezentacji jest źródłem dużej niepewności agenta.
Z brakiem semantycznego uzasadnienia agent jest zmuszony do zgadywania:
- które tabele odpowiadają którym koncepcjom biznesowym
- które połączenia są rzeczywiście ważne
- co faktycznie reprezentuje dana kolumna
- którą definicję metryki należy traktować jako autorytatywną
- w jaki sposób entity są ze sobą powiązane
- czy dwa różnie nazwane pola faktycznie oznaczają to samo
To jest problem do przyjęcia w demonstracji z pięcioma tabelami.
W przypadku setek produktów do przetwarzania danych korporacyjnych staje się to naprawdę ryzykowne.
Funkcja Ontology w Fabric została stworzona specjalnie jako masowo czytelny, wspólny słownik biznesowy składający się z typów entytetów, właściwości, relacji, ograniczeń oraz powiązań z rzeczywistymi danymi w OneLake. Ten słownik może być używany zarówno przez użytkowników ludzkich, jak i przez agenty.
2. Ale „Graph wiedzy” nie oznacza jednej architektury
Wizualny schemat decyzyjny towarzyszący tej dyskusji pomaga wyjaśnić, dlaczego wybór podejścia opartego na grafie i ontologii nie jest rozwiązaniem uniwersalnym.
[Wstaw: Schemat decyzyjny dla rozwiązań opartych na grafie i ontologii]
Nie istnieje jedyny poprawny sposób na zaprojektowanie grafu.
Krajobraz ten można w przybliżeniu podzielić na pięć wzorców.
Wzorzec 1 — RDF / Semantic Graph wiedzy
To jest tradycyjne podejście sieci semantycznej:
Subject ─ Predicate ─> Object
Zazwyczaj łączy się je z:
RDF
RDFS
OWL
SPARQL
Zalety: bogata semantyka, interoperacyjność oparta na standardach, udoskonalone metody modelowania ontologii oraz obsługa formalnego rozumowania.
Koszty: większa złożoność modelowania, konieczność specjalistycznych umiejętności oraz infrastruktura, która często przewyższa potrzeby rzeczywistej aplikacji.
3. Etykietowane grafy właściwości
Model etykietowanego grafu właściwości (LPG) przyjmuje podejście skupione bardziej na aplikacji:
(Customer)
│
│ PURCHASED
│ {date, quantity}
▼
(Product)
Zarówno węzły, jak i krawędzie mogą mieć własne właściwości.
Narzędzia takie jak Neo4j upopularniły ten model, ponieważ naturalnie pasuje do aplikacji wymagających intensywnego przeszukiwania grafu.
Zalety: intuicyjne modelowanie grafów, wysoka wydajność w przeszukiwaniu, udoskonalone algorytmy grafowe oraz solidne doświadczenie w tworzeniu aplikacji.
Kompromisy: sam schemat grafu nie stanowi zautomatyzowanego semantycznego słownika przedsiębiorstwa — ta warstwa znaczeń musi nadal być modelowana i zarządzana oddzielnie.
Microsoft Fabric Graph stosuje ten podejście LPG, mapując tabele OneLake na typy węzłów i krawędzi oraz umożliwiając przeszukiwanie za pomocą GQL. Implementacja GQL przez Microsoft odpowiada standaryzowanemu językowi zapytań grafowych ISO.
4. Lżejsza droga: ontologia plus graf w pamięci
Nie każdy agent wymaga pełnej bazy danych grafowych przedsiębiorstwa.
Dla aplikacji typu czat, scenariuszy opartych na krawędziach, asystentów o wąskim zakresie działania lub projektów typu proof-of-concept można przedstawić prostą ontologię w postaci zwykłego JSON:
{
"entities": {
"Customer": {},
"Product": {}
},
"relationships": {
"Purchases": {
"from": "Customer",
"to": "Product"
}
}
}
Kwarter warstwy aplikacyjnej może następnie załadować tę definicję do NetworkX, Memgraph, biblioteki RDF lub dowolnej innej struktury grafu w pamięci.
Ta metoda jest szybka do wdrożenia i tania w eksploatacji.
Zaletą jest to, że kwestie zarządzania, bezpieczeństwa, śledzenia pochodzenia danych, skalowania, synchronizacji informacji oraz wspólnego zarządzania definicjami semantycznymi musisz rozwiązywać samodzielnie.
5. Dlaczego Microsoft Fabric wyróżnia się na tym tle
Fabric podchodzi do tego problemu z innej perspektywy.
Zamiast wychodzić z założenia, że wszystkie dane przedsiębiorstwa muszą zostać przeniesione do bazy danych grafowych, architektura może zacząć od założenia, że dane przedsiębiorstwa pozostają tam, gdzie są, w OneLake, a inteligencja semantyczna i relacyjna jest dodawana na ich podstawie.
W formie diagramu:
Fabric IQ
│
┌─────────────────┼──────────────────┐
│ │ │
▼ ▼ ▼
Semantic Model Ontology Graph
│ │ │
trusted metrics business meaning traversal
│ │ │
└─────────────────┼──────────────────┘
│
OneLake
Microsoft wyraźnie rozdziela te obowiązki: modele semantyczne dostarczają wiarygodnych wskaźników kluczowych efektywności oraz struktur analitycznych, ontologia dostarcza wspólną terminologię biznesową, graf umożliwia przemieszczanie się po powiązanych danych, a agenci obsługujący dane lub operacje zapewniają inteligentną interakcję i działania oparte na tym kontekście.
To rozdzielenie zadań ma znaczenie pod względem architektury.
6. Model semantyczny, ontologia i graf to trzy różne rzeczy
Często używa się tych terminów, jakby były synonimami. Tak nie jest.
Pożyteczny sposób na to spojrzenie:
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?"
Model semantyczny Power BI może definiować miary takie jak:
Total Revenue
Average Order Value
Customer Count
Revenue by Segment
Ontologia może definiować entity i relacje takie jak:
Customer
Product
Customer ── PURCHASES ──> Product
To graf faktycznie tworzy i przemieszcza się po tych połączeniach:
Customer A
│
├── PURCHASES → Laptop
│
├── PURCHASES → Monitor
│
└── PURCHASES → Dock
Agent danych następnie udostępnia całą tę informację poprzez interakcję w języku naturalnym.
Fabric umożliwia również bezpośrednie wygenerowanie ontologii na podstawie istniejącego modelu semantycznego: tabele przekształcają się w typy entytetów, kolumny w właściwości, a relacje już zdefiniowane w modelu semantycznym stają się relacjami ontologii.
7. Budowa: Minimalny produkt danych sprzedażowych
Aby skupić się na architekturze, a nie inżynierii danych, przykład jest celowo prosty.
Wykorzystywane są tylko dwie tabele źródłowe:
NP_SalesDataProduct_LH
customers
──────────────
CustomerId
CustomerName
Segment
City
State
Country
sales
──────────────
OrderId
OrderDate
CustomerId
ProductName
ProductCategory
Quantity
UnitPrice
DiscountPct
Revenue
SalesChannel
Relacja między nimi jest prosta:
customers.CustomerId
1
│
*
sales.CustomerId
To wystarcza, aby przejść przez całą architekturę, nie pozwalając na to, by złożoność modelowania przeszkodziła w zrozumieniu podstawowej lekcji.
8. Krok 1 — Stworzenie produktu danych Fabric
Dwa pliki CSV są ładowane do Fabric Lakehouse:
NP_SalesDataProduct_LH
│
├── Tables
│ └── dbo
│ ├── customers
│ └── sales
│
└── Files
├── customers.csv
└── sales.csv
[Wstaw zrzut ekranu: Lakehouse pokazujące klientów i sprzedaż]
Na tym etapie masz już działającego Fabric Data Agenta.
Może on odpowiadać na pytania takie jak jaki jest łączny przychód, które kategorie produktów generują największy dochód oraz jak przychód jest rozkładany według segmentów klientów.
Jednak pod maską dzieje się coś godnego uwagi.
Ponieważ nie zdefiniowano żadnych dodatkowych semantyk, agent musi sam wywnioskować sposób połączenia danych:
customers.CustomerId
=
sales.CustomerId
a także musi sam wywnioskować, że:
Revenue → SUM(Revenue)
To daje Ci punkt odniesienia do porównania.
9. Krok 2 — Dodanie modelu semantycznego
Następnie wprowadzasz umowę analityczną.
Customer
1
│
*
Sales
z zdefiniowanymi miarami takimi jak:
Total Revenue =
SUM(sales[Revenue])
i:
Total Orders =
DISTINCTCOUNT(sales[OrderId])
W tym momencie agent nie musi już zgadywać, co oznacza „Łączne przychody”.
To określenie należy do warstwy semantycznej.
To wskazuje na ważną zasadę dla agentów przedsiębiorstw:
Agenty powinni korzystać z zarządzanych metryk, zamiast za każdym razem, gdy pojawia się pytanie, odtwarzać obliczenia przedsiębiorstwa na podstawie surowych kolumn.
10. Krok 3 — Dodanie ontologii
Od tego momentu przechodzimy od definicji analitycznych do znaczenia na poziomie biznesowym.
Ontologia w tym ćwiczeniu definiuje zaledwie dwa typy entytetów:
Customer
Product
Klient odpowiada:
customers.CustomerId
customers.CustomerName
customers.Segment
customers.City
customers.State
customers.Country
using:
KEY = CustomerId
Z kolei produkt pochodzi bezpośrednio z istniejącej tabeli sales:
sales.ProductName
sales.ProductCategory
using:
KEY = ProductName
Jeszcze raz nie było potrzeby tworzenia oddzielnego fizycznego tabeli Produkt, aby to zadziałało.
11. Zdefiniuj relację biznesową
Następnie dodaje się relację:
Customer
│
│ PURCHASES
▼
Product
Ciekawym aspektem jest tu to, jak działa powiązanie danych.
Sama tabela sales pełni rolę mostu dla tej relacji:
Customer.CustomerId
↑
sales.CustomerId
sales.ProductName
↓
Product.ProductName
Zatem surowy wiersz sprzedaży wygląda tak:
sales row:
CustomerId = C001
ProductName = Laptop Pro
przekształca się w:
Customer(C001)
│
│ PURCHASES
▼
Product(Laptop Pro)
To jest moment, w którym zwykły rekord relacyjny staje się czymś, co biznes faktycznie postrzega jako wiedzę.
Model ontologiczny Fabric został stworzony specjalnie dla tego procesu: najpierw definiuje się typy entytetów i ich relacje, a następnie te abstrakcyjne definicje powiązuje się z konkretnymi danymi przechowywanymi w OneLake.
12. Co zmienia się dla agenta?
Weźmy to pytanie:
Które produkty kupują klienci typu Enterprise?
Bez ontologii agent musi rozumować w sposób następujący:
Find customers table
↓
Find Segment
↓
Filter Enterprise
↓
Determine CustomerId join
↓
Join sales
↓
Find ProductName
Gdy ontologia jest dostępna, proces rozumowania sprowadza się do:
Customer
│
Segment = Enterprise
│
└── PURCHASES ──> Product
Pytanie odpowiada niemal bezpośrednio samemu modelowi.
Microsoft przedstawia tę zmianę jako przechodzenie od myślenia agentów w kategoriach pojedynczych tabel do podejścia opartego na zdefiniowanych entytetach, relacjach, definicjach, regułach oraz mapowaniach źródeł.
13. Krok 4 — Stworzenie agenta danych Fabric
Agent danych jest tym, co przekształca to wszystko w interfejs w języku naturalnym:
User
│
▼
NP_Sales_DataAgent
│
┌─────────────┼─────────────┐
▼ ▼ ▼
Lakehouse Semantic Model Ontology
│ │ │
raw facts trusted KPIs relationships
│ │ │
└─────────────┼─────────────┘
▼
OneLake
Microsoft opisuje Fabric Data Agents jako warstwę do odpowiadania na pytania w języku naturalnym, skupioną na określonym domenie danych, przy czym ontologia dostarcza głębszego kontekstu biznesowego, z którego te agenty czerpią informacje.
14. Następnie następuje ważny krok architektoniczny: MCP
Fabric Data Agent nie musi pozostać zamknięty wewnątrz Fabric.
Można go opublikować.
Gdy zostanie opublikowany, Fabric udostępnia ten agent jako serwer Model Context Protocol.
Koncepcyjnie przepływ wygląda w ten sposób:
Fabric Data Agent
│
│ Publish
▼
MCP Server
│
├── tool description
├── input schema
└── governed execution
W tym momencie inteligencja danych w Twojej firmie staje się czymś wielokrotnie wykorzystywalnym – narzędziem agenta, które mogą wywoływać inne systemy.
15. Microsoft Foundry staje się warstwą orkiestracji
To otwiera drogę do znacznie ciekawszej architektury.
USER
│
▼
Microsoft Foundry Agent
│
planning / orchestration
│
┌───────────────────┼───────────────────┐
│ │ │
▼ ▼ ▼
CRM Tool Search Tool Fabric MCP
│
▼
Fabric Data Agent
│
┌───────────────────┼───────────────┐
▼ ▼ ▼
Semantic Model Ontology Lakehouse
│ │ │
└───────────────────┼───────────────┘
▼
OneLake
Rozdzielenie zadań ma tutaj kluczowe znaczenie.
Agent Foundry odpowiada za rozumowanie w ramach procesów pracy.
Agent Fabric Data odpowiada za przetwarzanie danych.
W obecnej formie integracja Foundry firmy Microsoft umożliwia agentowi Foundry odkrywanie opublikowanych agentów Fabric Data Data poprzez Fabric IQ / OneLake Catalog i traktowanie ich jako narzędzi MCP. Jeden agent Foundry również nie jest ograniczony do jednej domeny – może łączyć i wykorzystywać kilka agentów Fabric Data Data jednocześnie.
16. Przykład zastosowania
Załóżmy, że użytkownik składa do agenta Foundry prośbę w następujący sposób: znaleźć segment klientów, który przyczynia się najwięcej do przychodów, określić, które produkty wpływają na wyniki tego segmentu, oraz przekształcić te informacje w rekomendację, której zespół sprzedaży może skorzystać.
Oto jak mogłaby przebiegać realizacja tego zlecenia:
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
Ważne nie jest to, że model językowy wydał rekomendację. Kluczowe jest to, że rekomendacja opierała się na ustalonej reprezentacji biznesowej, a nie została wymyślona na poczekaniu z surowych tabel lub na podstawie domysłów semantycznych.
17. MCP zmienia architekturę agentów przedsiębiorstwa
Bez MCP zespoły zazwyczaj łączą elementy w ten sposób:
Agent A → custom Fabric integration
Agent B → another custom Fabric integrationAgent C → another SQL implementationAgent D → another Power BI integration
Z upływem czasu każdy agent gromadzi dogłębną, ale kruchą wiedzę na temat podstawowej platformy danych.
Gdy istnieje MCP, sytuacja wygląda inaczej:
Enterprise Agents
┌───────────┼───────────┐
▼ ▼ ▼
Agent A Agent B Agent C
│ │ │
└───────────┼───────────┘
│
MCP Tool
│
▼
Fabric Data Agent
│
▼
Governed Data IQ
Agent danych Fabric przekształca się w produkt analityki danych stworzony specjalnie do wykorzystania przez agenty, zamiast w indywidualną integrację, którą każdy zespół musi budować od nowa. To zmiana pozornie niewielka, ale istotna pod względem architektonicznym.
18. Inna opcja: bezpośrednie udostępnienie ontologii
Istnieje druga ścieżka, którą warto rozważyć.
Zamiast kierować wszystko przez Fabric Data Agent, samą ontologię Fabric można udostępnić za pośrednictwem MCP dowolnemu kompatybilnemu zewnętrznemu agentowi. Microsoft dokumentuje serwer Ontology MCP, który zawiera narzędzia do wykrywania typów entytetów ontologii oraz do wykonywania zapytań wobec niej.
To daje nam dwa odrębne wzorce:
PATTERN A
External Agent
│
│ MCP
▼
Fabric Data Agent
│
▼
Ontology
W przeciwieństwie do:
PATTERN B
External Agent
│
│ MCP
▼
Fabric Ontology
Wybierz pierwszy wzorzec, gdy chcesz skorzystać z własnej warstwy rozumowania konwersacyjnego i agenta danych Fabric. Wybierz drugi, gdy zewnętrzny agent posiada już własną zaawansowaną logikę planowania i potrzebuje jedynie bardziej bezpośredniego dostępu do semantycznego modelu przedsiębiorstwa.
19. Zalety i wady wzorca Fabric
Zalety
Semantyka centralizowana. Definicje biznesowe znajdują się w jednym zarządzanym miejscu, zamiast być kopiowanych i wklejanych do każdego promptu.
Bazuje na OneLake. Nie ma ścisłego wymogu kopiowania całej bazy danych do oddzielnej platformy grafowej.
Trzy warstwy działające razem. Wskaźniki analityczne oraz semantyka na poziomie relacji mogą współistnieć w modelu semantycznym, ontologii i grafie.
Zaprojektowane dla agentów. Zarówno Fabric Data Agents, jak i warstwa ontologii zostały stworzone specjalnie jako źródła danych dla agentów AI.
Otwarte poprzez MCP. Powstała warstwa inteligencji może być wykorzystywana zarówno przez Foundry, jak i przez niestandardowe klienty MCP.
Jasne rozdzielenie zadań.
Fabric → data intelligence
Foundry → orchestration intelligence
To rozdzielenie tworzy wyraźnie czystą granicę na poziomie przedsiębiorstwa.
20. Kompromisy
Istnieje kilka ważnych zastrzeżeń.
Znaczna część tego nadal stanowi technologię w wersji wstępnej. Obsługa ontologii, kilka integracji z Fabric IQ i Foundry oraz powiązane funkcje MCP pozostają cechami wersji wstępnej, dlatego przed użyciem ich w produkcji należy sprawdzić je pod kątem aktualnych warunków wersji wstępnej Microsoftu.
Zarządzanie ontologiami to ciągła praca. Gdy kilka domen zacznie definiować własne entytety takie jak Customer, Account, Product, Contract i podobne, ktoś musi zajmować się nadawaniem nazw, wersjonowaniem oraz synchronizacją pomiędzy domenami.
Ontologia nie może naprawić złych danych. Nawet jeśli otoczymy niskojakościowy zbiór danych elegancką semantyką biznesową, wyniki pozostaną niskiej jakości.
Ontologia nie zawsze jest konieczna. W przypadku prostego agregowania KPI, bezpośrednie zapytanie modelu semantycznego może być prostsze i wystarczające.
Nie każdy przypadek użycia grafów pasuje tutaj. Skomplikowane algorytmy grafowe, specjalistyczne rozumowanie w stylu RDF lub wysoce spersonalizowane obciążenia grafowe mogą wymagać zamiast tego dedykowanej platformy do grafów.
Dlatego właśnie przydatna jest stopniowa struktura decyzyjna.
21. Plan działań, który bym wykorzystał
Zamiast od razu rozpoczynać pracę nad ontologią na poziomie całej firmy, sensowne jest budowanie jej etapami.
Faza 1 — Produkty danych
Sources
↓
OneLake
↓
Domain Data Products
Celem jest stworzenie wiarygodnych, jasno przypisanych danych domenowych.
Faza 2 – Semantyka analityczna
Data Product
↓
Semantic Model
↓
Measures / KPIs / Dimensions
Na tej fazie określany jest sposób, w jaki organizacja mierzy różne rzeczy.
Faza 3 – Semantyka biznesowa
Semantic Models + Data Products
↓
Ontology
↓
Entities / Relationships / Rules
Na tej fazie określone zostaje to, co faktycznie oznaczają te mierzone wartości.
Faza 4 – Inteligencja połączona
Ontology
↓
Graph
↓
Traversal / dependency / impact analysis
Na tym etapie struktury grafowe są wykorzystywane tylko wtedy, gdy przeszukiwanie relacji rzeczywiście jest uzasadnione.
Faza 5 – Agenci danych domenowych
Ontology + Semantic Model + Data
↓
Data Agent
Tutaj zgromadzoną wiedzę domenową przekształca się w coś bardziej przystępnego pod względem komunikacyjnym.
Faza 6 – MCP
Data Agent
↓
Publish
↓
MCP
Na tym kroku produkt komunikacyjny jest przekształcany w funkcjonalność, którą mogą wykorzystywać inne agenty.
Faza 7 – Orkiestracja agentów przedsiębiorstwa
Foundry Agent
│
┌──────────────────┼──────────────────┐
▼ ▼ ▼
Sales Data Agent Supply Agent Finance Agent
│ │ │
└──────────────────┼──────────────────┘
│
Fabric IQ
Microsoft już zmierza w tym kierunku: agenci Foundry mogą pobierać dane z kilku opublikowanych agentów Fabric Data Agents za pośrednictwem Fabric IQ, przy czym każdy z tych agentów jest dostępny jako narzędzie MCP.
Kierunek rozwoju
Większa zmiana architektoniczna wygląda następująco:
GENERATION 1
LLM + RAG
│
Documents
rozwijające się w:
GENERATION 2
LLM + Tools + Data
│
SQL / APIs / RAG
a ostatecznie w:
GENERATION 3
Agent Systems
│
┌─────────────┼─────────────┐
▼ ▼ ▼
Documents Tools Enterprise IQ
│
┌──────────┼──────────┐
▼ ▼ ▼
Semantics Ontology Graph
│ │ │
└──────────┼──────────┘
▼
Enterprise Data
Kluczowym czynnikiem w tej dziedzinie będzie coraz mniej kwestia tego, który model jest najsilniejszy.
Zamiast tego będzie to zależeć od tej organizacji, która stworzyła najbogatszą warstwę kontekstu przedsiębiorstwa, z której mogą czerpać te modele.
Microsoft określa swój ogólny kierunek jako Microsoft IQ, gdzie Fabric IQ dostarcza informacje o jednostkach biznesowych i danych, współpracując z Work IQ, Foundry IQ oraz Web IQ.
To ujęcie jest trafne.
Nie można polegać na agencie, by zarządzał częściami biznesu tylko dlatego, że dobrze radzi sobie z wyszukiwaniem dokumentów.
Musi on rozumieć:
To, czym są poszczególne rzeczy.
To, jak są ze sobą powiązane.
To, w jaki sposób organizacja je faktycznie mierzy.
Które definicje mają autorytet.
Jaki jest obecny stan tych rzeczy.
A ostatecznie:
Które działania mają sens biorąc pod uwagę to wszystko.
Wniosek: Od RAG do rozumowania przedsiębiorstwa
RAG dał sztucznej inteligencji w przedsiębiorstwach sposób dostępu do wiedzy.
Używanie narzędzi dało agentom sposób dostępu do systemów.
Ontologia daje im coś zupełnie innego:
znaczenie.
Gdy to znaczenie zostanie połączone z określonymi metrykami, relacjami grafowymi, aktualnymi daniami operacyjnymi oraz mechanizmami orkiestracji agentów, otrzymujemy znacznie bardziej przekonującą architekturę:
DATA
│
▼
SEMANTICS
│
▼
ONTOLOGY
│
▼
CONNECTED INTELLIGENCE
│
▼
DATA AGENTS
│
▼
MCP
│
▼
ENTERPRISE AGENTS
│
▼
DECISIONS
│
▼
ACTIONS
To właśnie stanowi rzeczywistą wartość oferowaną przez analizy oparte na ontologii i agentach.
To nie jest zwykły chatbot przymocowany do bazy danych.
Jest to architektura inteligencji przedsiębiorstwa, w której produkty danych dostarczają faktów, modele semantyczne zaufanych miar, ontologie znaczeń, grafy relacji, agenci domenowi dostarczają informacji, a MCP umożliwia łączenie wszystkich tych elementów w szerszym ekosystemie agentów.
To połączenie sprawia, że budowa następnej generacji sztucznej inteligencji przedsiębiorstw staje się znacznie bardziej interesująca.
Literatura pokrewna
- MCP dla agentów AI: standaryzacja integracji narzędzi w LangGraph — Ten artykuł wyjaśnia, co dokładnie standaryzuje MCP w systemach AI opartych na agentach, porównując ad hoc integracje narzędzi z tymi opartymi na MCP w ramach orkiestratora LangGraph.
- Wysyłanie danych za pomocą RTK Query: praktyczny przewodnik po mutacjach — Dowiedz się, jak używać builder.mutation() w RTK Query do wysyłania zapytań typu POST, zarządzania stanami ładowania i błędów oraz tworzenia funkcjonalnego komponentu formularza.