Microsoft Build 2026: Veri Platformunda Agentic Dönem

Merhaba,

Bu yazıda, Microsoft Build 2026‘da veri platformu tarafında duyurulan yenilikleri baştan sona ele alacağım. Geçtiğimiz hafta Redmond’da düzenlenen MVP Summit 2026‘ya katılma fırsatı buldum; bu yazıyı da hem oradan edindiğim bağlamla hem de Build 2026’nın halka açık duyurularıyla, herkesin doğrulayabileceği resmî kaynaklara dayanarak hazırladım. Konu başlıkları geniş olduğu için yazıyı bir rehber formatında kurguladım: Microsoft Fabric, Azure SQL ve SQL Server 2025, Cosmos DB, Azure HorizonDB ve Power BI tarafındaki gelişmeleri, her birinin “ne işe yaradığı” ve “nasıl çalıştığı” dengesiyle inceleyeceğiz.

Kaynak ve kapsam notu: MVP Summit içeriği NDA kapsamındadır; dolayısıyla bu yazıda Summit’e özel hiçbir bilgi paylaşmıyorum. Aşağıdaki tüm teknik ayrıntılar halka açık Build 2026 kaynaklarına (resmî bloglar, Microsoft Learn, Build canlı blogu) dayanır ve her birinin bağlantısını metin içinde verdim. Ayrıca GA (genel kullanıma hazır) ile Preview (önizleme) ayrımını özellikle koruyorum; üretim kararı verirken bu ayrım kritik önem taşır.

İçindekiler

1. Agentic veri platformu nedir?
2. Microsoft Fabric: Build 2026 ile gelen yenilikler
3. Veritabanları: Azure HorizonDB ve Cosmos DB
4. SQL Server 2025 ve Azure SQL: agentic geliştirici deneyimi
5. Vektör ve embedding temelleri
6. Uçtan uca örnek: bir destek asistanı senaryosu
7. Değerlendirme: öne çıkanlar, beklentiler ve dikkat edilmesi gerekenler
8. Nereden başlamalı?
9. Sık karşılaşılan yanlış bilgiler
10. Kaynaklar

1. Agentic veri platformu nedir?

Özet: Build 2026’nın veri tarafındaki ana teması, veriyi yapay zeka ajanlarının güvenle kullanabileceği bir zemine dönüştürmek. Üç yapı taşı öne çıkıyor: MCP (standart ve güvenli erişim), ontoloji / anlam katmanı (ajanın verinin ne anlama geldiğini anlaması) ve ajan-hazır veri entegrasyonu (ajanın yalnızca okumakla kalmayıp veri akışlarını yazıp çalıştırabilmesi).

Build 2026 boyunca en sık karşılaştığımız kavram “agentic” oldu. Bu kelime ilk bakışta bir pazarlama söylemi gibi görünse de altında somut bir mühendislik yaklaşımı var. Önceki dönemde yapay zeka modellerine veriyi “bul ve getir” görevini veriyor, ardından modelin doğru kaynağa ulaşmasını umuyorduk. Build 2026’da Microsoft bu modele üç temel yetenek kazandırıyor: güvenli ve standart bir erişim yöntemi, verinin iş anlamını tanımlayan bir katman ve ajanın veri süreçlerini doğrudan yönetebilmesi.

Bu üç yapı taşının teknik karşılıkları şöyle:

• MCP (Model Context Protocol): Ajanların veriye bağlandığı ortak protokol. Bunu “yapay zeka için standart bir bağlantı arabirimi” gibi düşünebilirsiniz; Cosmos DB’den SQL’e kadar pek çok yerde karşımıza çıkıyor.
• Ontoloji / anlam katmanı: Modelin “aktif müşteri” veya “iade oranı” gibi kavramları sizin işletmenizde tanımlandığı biçimde anlaması. Bu katman olmadan en güçlü model bile yanlış sonuç üretebilir.
• Ajan-hazır veri entegrasyonu: Ajan artık yalnızca veriyi okumakla kalmıyor, veri akışlarını oluşturup çalıştırabiliyor da.

Build 2026’nın çizdiği “agentic veri yığını”nı kavramsal olarak şu şekilde özetleyebiliriz:

Buradan çıkarılacak temel mesaj şu: artık “yapay zeka projesi” ile “veri stratejisi” birbirinden ayrı iki başlık değil. Ajanın ürettiği sonucun kalitesi, doğrudan eriştiği verinin kalitesine, anlamına ve erişim güvenliğine bağlı. Aşağıdaki bölümlerde bu katmanları tek tek inceleyeceğiz.

2. Microsoft Fabric: Build 2026 ile gelen yenilikler

Özet: Data Factory “agent-ready” hale geldi; Fabric data agents GA oldu (GPT 5.X yükseltmesiyle); Fabric IQ ontolojisi (Preview) ortak iş semantiği sunuyor; Power BI Agent Skills (Preview) ham veriden rapora uçtan uca agentic geliştirme getiriyor; GPU hızlandırmalı Data Warehouse (Early Access) “7 kata kadar” performans iddiasıyla geldi.

2.1. Data Factory artık “agent-ready”

Build 2026’nın Fabric tarafındaki en dikkat çekici başlıklarından biri, Fabric Data Factory’nin “agent-ready” hale gelmesi. Resmî Fabric Updates blogundaki ifadeyle bu, yapay zeka ajanlarının ve Copilot tarzı asistanların; Pipeline, Copy job, Connections & Gateways ve Dataflow Gen2 gibi tüm Data Factory öğelerini tek bir değerlendirilmiş (evaluated) yetenek seti üzerinden oluşturabilmesi, çalıştırabilmesi ve teşhis edebilmesi anlamına geliyor. Airflow ve MCP desteği de bu yapıya ekleniyor.

Buradaki kritik kavram “değerlendirilmiş yetenek seti”. Ajan, veritabanına rastgele komut göndermiyor; yalnızca önceden tanımlı ve denetlenmiş yetenekler üzerinden çalışıyor. Bu yaklaşım, “ajan üretim ortamında ne yapacağını öngöremeyiz” endişesini büyük ölçüde ortadan kaldırıyor. Microsoft aynı yazıda veri entegrasyonunu, yapay zekayı güvenilir kaynaklara dayandıran “temel katman” olarak konumlandırıyor.

2.2. Fabric data agents genel kullanıma açıldı (GA)

Fabric tarafındaki en önemli gelişme ise Fabric data agents’ın genel kullanıma (GA) açılması. Microsoft Learn’deki kavram dokümanında da açıkça belirtildiği gibi, data agent artık genel kullanıma hazır bir özellik. Bu ajanları, belirli bir veri alanına göre hizalanmış birer “sanal analist” olarak düşünebilirsiniz. Hem Fabric içinde çalışıyorlar, hem de Microsoft Foundry, Copilot Studio ve Microsoft 365 Copilot üzerinde bir bilgi kaynağı olarak kullanılabiliyorlar.

Fabric Analytics ekibinin Build 2026 yazısına göre bu sürümle gelen başlıca iyileştirmeler şunlar (çoğu hâlâ Preview):

• GPT 5.X model yükseltmesi — Microsoft’un iç kıyaslamalarında yaklaşık %20 doğruluk artışı.
• Service principal desteği (kimliksiz, programatik erişim) — üretim senaryoları için kritik.
• Foundry üzerinde gözlemlenebilirlik, yapay zeka destekli kurulum, geliştirilmiş NL2SQL ve Code Interpreter.

Çalışma mantığı şöyle özetlenebilir: Bir data agent oluştururken ona hangi veri kaynaklarına (lakehouse, warehouse, semantik model, KQL) bakacağını ve hangi kurallarla yanıt üreteceğini tanımlarsınız. Kullanıcı doğal dilde soru sorduğunda ajan, NL2SQL ile sorguyu kendisi üretir ve sonucu çalıştırır:

// Kullanıcının doğal dildeki sorusu (Teams / M365 Copilot içinde):
"Geçen çeyrekte en çok iade alan 5 ürünü ve iade oranlarını göster."
// Fabric data agent, semantik modele göre sorguyu kendisi üretir:
SELECT TOP (5)
p.ProductName,
COUNT(r.ReturnId)                                            AS ReturnCount,
CAST(COUNT(r.ReturnId) AS float) / NULLIF(COUNT(o.OrderId),0) AS ReturnRate
FROM   Sales.Orders   AS o
JOIN   Sales.Returns  AS r ON r.OrderId   = o.OrderId
JOIN   Dim.Product    AS p ON p.ProductId = o.ProductId
WHERE  o.OrderDate >= DATEADD(QUARTER, -1, GETDATE())
GROUP BY p.ProductName
ORDER BY ReturnRate DESC;

Dikkat: Data agent özelliğinin kendisi GA olsa da, onu Copilot Studio veya Microsoft 365 Copilot üzerinden tüketme yolları büyük ölçüde hâlâ Preview aşamasında. Üretim planını yaparken bu ayrımı göz önünde bulundurmanızı öneririm.

2.3. Fabric IQ: ortak iş semantiği için ontoloji katmanı (Preview)

Build 2026 canlı blogunda yer alan ifadeye göre Fabric IQ ontoloji katmanı (Preview), ajanların insanlar, veri, iş akışları ve operasyonlar arasındaki ilişkileri anlamasını sağlayan ortak bir iş semantiği sunuyor. Ayrıntıya Microsoft Learn’deki “What is Ontology (Preview)” sayfasından erişebilirsiniz.

Bunu bir örnekle açıklayalım: İşe yeni başlayan, çok yetkin bir çalışan düşünün. Ne kadar yetkin olursa olsun, “bizim şirkette ‘aktif müşteri’ ne demek, ‘iade’ hangi koşulda sayılır” gibi tanımları bilmeden doğru rapor üretemez. Ontoloji katmanı tam olarak bu “kurumsal sözlük” işlevini görüyor ve modelin halüsinasyon oranını düşüren en etkili araçlardan biri olarak öne çıkıyor. Durumu: Preview.

2.4. Power BI Agent Skills: uçtan uca agentic geliştirme (Preview)

Power BI tarafındaki en önemli yenilik ise Agent Skills for Power BI (Preview). Power BI ekibinin Build 2026 yazısına göre bu özellik, “ham veriden semantik modellere ve etkileşimli raporlara” uzanan uçtan uca agentic geliştirme imkânı sunuyor.

“Agent Skills for Power BI (Preview), announced at Build, bring true end-to-end agentic development to Power BI — from raw data to semantic models to interactive reports.” — Power BI Updates Blog

Uygulamada bunun karşılığı; bir ekran görüntüsünden veya metin isteminden semantik model oluşturma, otomatik rapor üretme ve PBIP (Power BI Project) formatı üzerinden görselleri iteratif olarak geliştirme. Kısacası analistin “veriyi al, modelle, görselleştir” döngüsünün önemli bir kısmı ajana devredilebiliyor. Durumu: Preview — ancak yön açık: Power BI bir raporlama aracından, agentic bir analitik geliştirme ortamına doğru evriliyor.

2.5. GPU hızlandırmalı Fabric Data Warehouse (Early Access Preview)

Build 2026’da öne çıkan performans başlıklarından biri de Fabric Data Warehouse’un, uygun sorgular için yürütme motoru içinde NVIDIA GPU hızlandırması kullanmaya başlaması oldu (Early Access Preview). CoddSpeed adı verilen bu motor, SIGMOD 2026’da “Best Industry Paper” ödülünü de aldı. Fabric ekibinin teknik yazısında Microsoft, raporlama yüklerinde “üç karşılaştırılabilir bulut veri ambarına göre 7 kata kadar daha hızlı” olduğunu belirtiyor.

Bu rakamı değerlendirirken dikkat: “7 kat” değeri Microsoft’un kendi iç kıyaslamasından geliyor (Mayıs 2026, 100 GB ölçek) ve yalnızca 64 eşzamanlı kullanıcı senaryosunda geçerli. Tek kullanıcıda yaklaşık 3 kat, 16 kullanıcıda ise yaklaşık 6 kat. Karşılaştırılan üç rakip ürün isimlendirilmemiş. Dolayısıyla bunu bağımsız onaylı bir kıyaslama olarak değil, üreticinin kendi koşullarındaki bir ölçüm olarak değerlendirmek doğru olur.

3. Veritabanları: Azure HorizonDB ve Cosmos DB

Özet: Azure HorizonDB (Public Preview) — agentic uygulamalar için tasarlanmış, yönetilen PostgreSQL; gömülü DiskANN ve veritabanı içi yapay zeka çağrısı. Cosmos DB: MCP Toolkit GA, Semantic Reranking (Preview), Global Secondary Indexes GA, ayrıca integrated embeddings (Preview) ve agent memories / agentic retrieval araç setleri. Cosmos DB in Fabric ise zero-ETL ile OneLake’te tek doğruluk kaynağı sağlıyor.

3.1. Azure HorizonDB: agentic uygulamalar için yönetilen PostgreSQL (Public Preview)

Azure HorizonDB, agentic uygulamalar için tasarlanmış, tam yönetilen ve PostgreSQL uyumlu yeni bir servis. Tech Community’deki tanıtım yazısına göre; bildiğiniz tüm  pgvector  ekosistemine ek olarak gömülü DiskANN vektör arama, semantik hibrit arama, veritabanı içinde yapay zeka modeli çağırma ( azure_ai  / Foundry) ve Microsoft Fabric entegrasyonu sunuyor. Bağımsız teknik basın (InfoQ) tarafından da doğrulanan ölçek değerleri ise 3.072 vCore’a kadar, 128 TB kapasite ve çok bölgeli alt-milisaniye commit.

-- PostgreSQL uyumlu olduğu için tanıdık bir kullanım sunar:
CREATE EXTENSION IF NOT EXISTS vector;
CREATE TABLE docs (
id        bigserial PRIMARY KEY,
content   text,
embedding vector(1536)        -- embedding = metnin "anlam koordinatı"
);
-- Embedding'i veritabanının içinde üretmek (veri dışarı çıkmadan):
UPDATE docs
SET    embedding = azure_ai.generate_embeddings(content)
WHERE  embedding IS NULL;
-- DiskANN ile hızlı benzerlik araması (RAG'in temelini oluşturur):
SELECT id, content
FROM   docs
ORDER  BY embedding <=> azure_ai.generate_embeddings('iade politikası nedir?')
LIMIT  5;          -- <=> kosinüs mesafesi: değer küçükse daha benzer demektir

Şunu da ekleyeyim: HorizonDB ilk olarak Aralık 2025’teki Ignite’ta “early preview” aşamasında duyurulmuştu; Build 2026’da geçtiği eşik Public Preview. Konumlandırma açısından, AWS Aurora ve Google AlloyDB’ye yönelik doğrudan bir yanıt niteliğinde.

3.2. Cosmos DB: MCP Toolkit, Semantic Reranking ve GSI

Cosmos DB ekibi bu üç özelliği Build günü yayımladığı “Announced at MS Build 2026” yazısında bir arada duyurdu. Global Secondary Indexes’i anlamak için şöyle düşünebilirsiniz: Bir telefon rehberinin ikinci bir kopyasını, soyadına göre değil şehre göre sıralarsanız, “İstanbul’daki kayıtlar” sorgusu artık tüm rehberi taramak zorunda kalmaz. GSI de farklı bir partition key’e göre düzenlenmiş, change feed ile otomatik senkron tutulan salt-okunur bir kopya oluşturur. (GA ayrıntıları için ilgili duyuruya bakabilirsiniz.)

MCP Toolkit’i bir ajana bağlamak da oldukça basittir:

{
"servers": {
"cosmosdb": {
"command": "npx",
"args": ["-y", "@azure/cosmos-mcp-toolkit"],
"env": {
"COSMOS_ENDPOINT": "https://<hesap>.documents.azure.com:443/",
"COSMOS_DATABASE": "retail",
"AUTH_MODE": "aad"     // Entra ID ile kimliksiz, güvenli erişim
}
}
}
}

3.3. Cosmos DB’nin yapay zeka tarafı: integrated embeddings ve agent memories

Cosmos DB tarafındaki yenilikler bu üç başlıkla sınırlı değil. RAG senaryoları için önemli iki gelişme daha var. Birincisi integrated embeddings (Public Preview): İlgili devblog yazısına göre, veriniz değiştikçe embedding’leriniz otomatik olarak senkron kalıyor; böylece “kaydı güncelledim ama vektörünü güncellemeyi unuttum” türünden hataların önüne geçiliyor. İkincisi ise agent memories ve agentic retrieval için yeni araç setleri: ajanların konuşma hafızasını ve getirme (retrieval) mantığını Cosmos DB üzerinde standart desenlerle kurmanıza imkân tanıyor.

Neden önemli? “Embedding’i kim, ne zaman güncelleyecek?” sorusu RAG projelerinin sık gözden kaçan bir bakım yüküdür. Integrated embeddings bu yükü platforma devreder; agent memories ise sohbet eden bir ajanın hafıza katmanını sıfırdan geliştirme ihtiyacını ortadan kaldırır.

3.4. Cosmos DB in Fabric: zero-ETL ile OneLake entegrasyonu

Cosmos DB in Fabric, operasyonel verinizi zero-ETL ile OneLake’e senkron tutar. Her veritabanı, RU tüketmeden, Delta Lake formatında ve neredeyse gerçek zamanlı olarak OneLake’e yansıtılır. Böylece analitik ve raporlama için tek bir doğruluk kaynağı elde edersiniz; ayrıca bir ETL boru hattı yazıp bakımıyla uğraşmanız gerekmez.

Tarih notu: Bu özellik aslında Kasım 2025’teki Ignite’ta GA olmuştu, bir Build 2026 duyurusu değil. Ancak agentic mimarinin temel taşlarından biri olduğu için burada “kurucu zemin” olarak yer veriyorum.

4. SQL Server 2025 ve Azure SQL: agentic geliştirici deneyimi

Özet: SSMS’te GitHub Copilot Agent Mode (Preview) execution plan okuyup eksik indeks önerebiliyor ve refactor yapabiliyor. VS Code MSSQL v1.43’te Schema Designer (GA) ve Data API Builder (GA) ile bir tablodan REST, GraphQL ve MCP uç noktaları üretilebiliyor.

Build 2026, geliştirici araçlarına da agentic bir yaklaşım kazandırdı. Microsoft bu gelişmeleri “The Era of the Agentic Database Developer” başlıklı yazıda toplamış. Öne çıkan iki başlık şöyle:

• SSMS — GitHub Copilot Agent Mode (Preview): Yalnızca kod tamamlamakla kalmıyor; veritabanı nesneleri arasındaki bağlamı okuyarak çok adımlı çıkarım yapabiliyor ve iş akışlarını yürütebiliyor. Örneğin execution plan’i inceleyip eksik indeksi tespit edebiliyor veya bir stored procedure’ü yeniden düzenleyebiliyor.
• VS Code MSSQL eklentisi (v1.43, Haziran 2026):
  • Schema Designer (GA): Doğal dil tanımından tablo, sütun ve ilişkileri üretiyor.
  • Data API Builder (GA): Tablolarınızdan REST, GraphQL ve MCP uç noktaları oluşturuyor.

Bu başlıklar içinde özellikle Data API Builder’ın MCP uç noktası üretebilmesi önemli; çünkü sıradan bir SQL tablosunu, kısa sürede ajanların güvenle erişebileceği bir servise dönüştürüyor. Haziran 2026 sürüm notunda yer alan bu yetenek şöyle kullanılıyor:

# Data API Builder (DAB) CLI:
dab init --database-type mssql \
--connection-string "@env('SQL_CONNSTR')"
# Bir tabloyu REST + GraphQL + MCP olarak yayımla:
dab add Product --source dbo.Product --permissions "anonymous:read"
dab start
# Artık ajan, /mcp uç noktası üzerinden Product verisini güvenle sorgulayabilir.

5. Vektör ve embedding temelleri

Özet: Bu yetenekler Build 2026’da değil, 2025 boyunca olgunlaştı (yaz 2025 / Ignite Kasım 2025); ancak agentic senaryoların kurucu zeminini oluşturuyor. Azure SQL ve SQL Server 2025’te native VECTOR tipi ve  VECTOR_DISTANCE  GA; DiskANN / ANN araması Preview;  AI_GENERATE_EMBEDDINGS/CHUNKS  ile veritabanı içinde RAG Preview.

Bu bölümdeki özellikler Build 2026’da duyurulmadı; bir kısmı yaz 2025’te (Azure SQL native vektör GA duyurusu), bir kısmı ise Kasım 2025 Ignite’ta (SQL Server 2025’in vektör desteği) geldi. Yine de agentic mimarinin temelini oluşturdukları için bu rehberde yer vermek gerekiyor. İki kavramı netleştirelim: embedding, bir metni “anlam koordinatına” dönüştürmektir; benzer anlamlar bu uzayda birbirine yakın konumlanır. Vektör indeksi (DiskANN) ise bu koordinatlar için bir tür “anlam dizini” görevi görür ve milyarlarca satırı tek tek taramadan en yakın komşuyu bulmanızı sağlar.

5.1. Azure SQL — native VECTOR tipi (GA, yaz 2025)

-- Embedding'i doğrudan ilişkisel tabloda saklayabilirsiniz:
CREATE TABLE Articles (
Id        int IDENTITY PRIMARY KEY,
Title     nvarchar(200),
Body      nvarchar(max),
Embedding VECTOR(1536)        -- native VECTOR tipi (GA)
);
-- Benzerlik araması (kosinüs):
DECLARE @q VECTOR(1536) = /* sorgunun embedding'i */;
SELECT TOP (5) Id, Title,
VECTOR_DISTANCE('cosine', Embedding, @q) AS Distance
FROM   Articles
ORDER  BY Distance;        -- küçük mesafe = daha benzer

Sık karıştırılan bir ayrıntı:  VECTOR_NORM  bir vektörün büyüklüğünü hesaplar; asıl normalleştirme işlemini  VECTOR_NORMALIZE  yapar.

5.2. SQL Server 2025 — VECTOR tipi GA, DiskANN Preview

-- Milyarlarca vektörde hızlı yaklaşık arama için DiskANN indeksi (Preview):
CREATE VECTOR INDEX vec_idx ON Articles(Embedding)
WITH (METRIC = 'cosine', TYPE = 'diskann');
-- Yaklaşık (ANN) arama — VECTOR_SEARCH (Preview):
SELECT a.Id, a.Title, s.distance
FROM   VECTOR_SEARCH(
TABLE      = Articles AS a,
COLUMN     = Embedding,
SIMILAR_TO = @q,
METRIC     = 'cosine',
TOP_N      = 10
) AS s
ORDER BY s.distance;

GA mı, Preview mi?  VECTOR  tipi ve  VECTOR_DISTANCE  GA; ancak ANN / VECTOR_SEARCH / float16 hâlâ  PREVIEW_FEATURES  arkasında Preview. (RTM: 18 Kasım 2025.)

5.3. Veritabanı içinde RAG kurmak (Preview)

Bu başlıktaki yaklaşım, embedding’i uygulama katmanında değil, doğrudan veritabanının içinde üretmeye dayanıyor. Böylece veri dışarı çıkmadan vektörleşip aranabiliyor; bu da hem veri gizliliği hem de gecikme açısından avantaj sağlıyor. Klasik bir RAG akışı üç adımda kurulabilir:

-- 1) Harici yapay zeka modelini bir kez tanımla:
CREATE EXTERNAL MODEL MyEmbedder
WITH (
LOCATION   = 'https://<foundry-endpoint>/embeddings',
API_FORMAT = 'Azure OpenAI',
MODEL_TYPE = EMBEDDINGS,
MODEL      = 'text-embedding-3-small',
CREDENTIAL = [MyFoundryCredential]
);
-- 2) Uzun metni parçalara böl ve her parçayı motor içinde embed et:
INSERT INTO Chunks (DocId, ChunkText, Embedding)
SELECT  d.Id,
c.chunk,
AI_GENERATE_EMBEDDINGS(c.chunk USE MODEL MyEmbedder)
FROM    Documents d
CROSS APPLY AI_GENERATE_CHUNKS(d.Body, CHUNK_SIZE = 512) AS c;
-- 3) Soru geldiğinde aynı modelle embed edip ara:
DECLARE @q VECTOR(1536) =
AI_GENERATE_EMBEDDINGS(N'kargo ne zaman gelir?' USE MODEL MyEmbedder);
SELECT TOP (5) ChunkText
FROM   Chunks
ORDER  BY VECTOR_DISTANCE('cosine', Embedding, @q);

Bu fonksiyonlar ( AI_GENERATE_EMBEDDINGS / AI_GENERATE_CHUNKS ) SQL Server 2025’te Preview aşamasında olup Azure SQL’e gelmektedir. Sözdizimi GA ile değişebilir.

6. Uçtan uca örnek: bir destek asistanı senaryosu

Özet: Tüm parçaları tek bir senaryoda birleştiriyoruz — müşteri destek RAG asistanı: operasyonel veri Cosmos DB’de, bilgi tabanı SQL Server 2025 vektörlerinde, analitik OneLake’te, arayüz ise Fabric data agent ve Microsoft 365 Copilot tarafında. Katmanlar birbirine MCP ile bağlanıyor.

Tekil özellikleri gördükten sonra, bunların birlikte nasıl çalıştığını somut bir senaryo üzerinde inceleyelim: bir e-ticaret şirketinin müşteri destek asistanı. Amacımız şu: Müşteri “siparişim nerede ve iade edebilir miyim?” diye sorduğunda, asistan hem o müşterinin canlı sipariş verisini hem de iade politikası dokümanlarını kullanarak dayanaklı bir yanıt üretsin.

Mimari kararlar ve hangi Build 2026 bileşeni nereye oturuyor:

Adım 1 — Bilgi tabanını SQL Server 2025’te vektörleyin (veritabanı içinde):

-- Politika/SSS dokümanlarını parçala ve motor içinde embed et:
INSERT INTO Kb_Chunks (DocId, ChunkText, Embedding)
SELECT d.Id, c.chunk,
AI_GENERATE_EMBEDDINGS(c.chunk USE MODEL MyEmbedder)
FROM   KnowledgeDocs d
CROSS APPLY AI_GENERATE_CHUNKS(d.Body, CHUNK_SIZE = 512) AS c;
CREATE VECTOR INDEX kb_vec ON Kb_Chunks(Embedding)
WITH (METRIC = 'cosine', TYPE = 'diskann');   -- Preview

Adım 2 — Müşterinin canlı siparişini Cosmos DB’den MCP ile çekin. Ajan, MCP Toolkit üzerinden (yukarıdaki  mcp.json ) Cosmos DB’ye bağlanır ve  customerId  ile güncel sipariş/kargo durumunu okur. GSI sayesinde bu sorgu tüm partition’ları taramaz, tek partition’a iner.

Adım 3 — Soruyu bilgi tabanında arayın, ardından reranking ile süzün:

-- Kullanıcı sorusu: "Açılmış ürünü iade edebilir miyim?"
DECLARE @q VECTOR(1536) =
AI_GENERATE_EMBEDDINGS(N'açılmış ürün iade edilebilir mi?' USE MODEL MyEmbedder);
-- Önce hızlı vektör araması ile aday havuzunu oluştur:
SELECT TOP (20) ChunkText, VECTOR_DISTANCE('cosine', Embedding, @q) AS d
FROM   Kb_Chunks ORDER BY d;
-- Ardından Cosmos DB Semantic Reranking ile en alakalı 3 parçayı öne al (Preview).

Adım 4 — Yanıtı birleştirin. Ajan, elindeki iki bağlamı (canlı sipariş ve politika parçaları) modele vererek dayanaklı yanıtı üretir:

“12 Haziran’da kargoya verilen siparişiniz şu anda dağıtımda. Açılmış ürünlerde iade, ambalaj hasarsızsa teslim tarihinden itibaren 14 gün içinde mümkündür (Politika §4.2). İade talebini başlatmamı ister misiniz?”

Adım 5 — Geri besleme analitiğe akar. Cosmos DB’deki bu etkileşimler zero-ETL ile OneLake’e yansıdığı için, bir Fabric data agent’a “bu hafta en çok hangi konuda iade sorusu geldi?” diye sorabilir ve ürün ekibine içgörü sağlayabilirsiniz. Böylece döngü kapanır: operasyon → asistan → analitik → operasyonun iyileştirilmesi.

Değerlendirme: Bu mimaride “embedding’i kim güncelleyecek” sorusuyla hiç uğraşmadık; çünkü integrated embeddings ve veritabanı içi embedding fonksiyonları bu yükü platforma devrediyor. Birkaç yıl önce aynı senaryo, üç ayrı servis, bir kuyruk ve ayrı bir senkronizasyon işi gerektiriyordu. Build 2026 ile bu sürecin büyük kısmı platformun içine taşınmış durumda.

7. Değerlendirme: öne çıkanlar, beklentiler ve dikkat edilmesi gerekenler

Özet: Genel yön doğru, ancak özelliklerin önemli kısmı hâlâ Preview. Önerim, GA olan temellerle (VECTOR, MCP Toolkit, data agents) başlayıp Preview özellikleri pilotta denemek. Rekabet tarafında Microsoft’un asıl avantajı tek platform bütünlüğü (OneLake) ve Microsoft 365 dağıtımı. En büyük risk ise Preview özelliklerin GA takvimine ve üretici kıyaslamalarına gereğinden fazla güvenmek.

7.1. Nasıl bir yol izlerdim?

Bu kadar çok yeniliğin arasında, sahadaki tecrübemin önerisi net: önce GA olan temellere yatırım yapmak, Preview özellikleri ise kontrollü bir pilotla denemek. Somut bir 90 günlük plan şöyle olabilir:

• 0–30 gün: Tek bir gerçek senaryo seçin (yukarıdaki destek asistanı gibi). Bilgi tabanını Azure SQL / SQL Server 2025 VECTOR (GA) ile vektörleyin ve MCP Toolkit (GA) ile bir ajana bağlayın.
• 30–60 gün: Fabric data agent (GA) kurarak analitik tarafı bağlayın; Fabric IQ ontolojisini (Preview) sınırlı bir alanda deneyin ve halüsinasyon oranındaki değişimi ölçün.
• 60–90 gün: Semantic Reranking ve DiskANN/ANN gibi Preview bileşenleri üretimde değil, gölge (shadow) modda çalıştırın; kaliteyi karşılaştırın ve GA aşamasında üretime alın.

7.2. Rekabet açısından bir değerlendirme

Bana göre Microsoft’un asıl gücü tek bir üründe en iyisi olmaktan çok, tüm bileşenlerin OneLake’te buluşması ve ajanın Microsoft 365 üzerinden kullanıcının zaten önünde olması. Veri mühendisliği tarafında Databricks hâlâ güçlü bir alternatif; ancak “iş kullanıcısının önüne ajanı koyma” konusunda Microsoft’un dağıtım avantajı ciddi. MCP’yi açık bir standart olarak benimsemesi de yerinde bir tercih: rakip araçları dışlamak yerine birlikte çalışabilirliği önceliyor.

7.3. Önümüzdeki dönem için beklentiler

• Bugün Preview olan birçok bileşenin (Semantic Reranking, ANN/VECTOR_SEARCH, Azure SQL tarafındaki AI_GENERATE_* fonksiyonları) bir sonraki büyük etkinlikte — muhtemelen Ignite 2026 — GA olmasını bekliyorum.
• MCP’nin, bugün REST’in olduğu gibi, “destekleniyor mu?” diye sorulmayan, varsayılan bir beklenti haline gelmesi olası.
• Fabric IQ ontolojisi, data agent kalitesinin asıl belirleyicisi olacak; “modeli büyütmek” yerine “ontolojiyi düzeltmek” daha çok konuşulacak.
• HorizonDB’nin GA tarihi ve fiyatlandırması, Aurora ve AlloyDB karşısındaki gerçek konumunu belirleyecek kritik başlıklardan biri.

Bu bölümdeki değerlendirme ve beklentiler kişisel görüşümdür; Microsoft’un resmî açıklaması değildir.

7.4. Dikkat edilmesi gerekenler

• Preview yoğunluğu: Demoların etkisiyle Preview özellikleri erkenden üretime almak. GA takvimi garanti değildir.
• Üretici kıyaslamaları: “7 kat” gibi değerler üreticinin kendi koşullarından gelir; kendi verinizle bir POC yapmadan karar vermeyin.
• Bağımlılık dengesi: OneLake ve MCP cazip bir bütünlük sunuyor; yine de “ne ölçüde tek platforma bağlanıyorum?” sorusunu bilinçli sorun. MCP’nin açık olması bu riski hafifletiyor.
• Yönetişim: Ajan artık veri yazıp çalıştırabiliyor. İzin modelini, denetim (audit) kayıtlarını ve service principal kapsamlarını ilk aşamadan itibaren tasarlayın.

8. Nereden başlamalı?

Karar vericiler için

• Veri stratejisi ile yapay zeka stratejisi artık aynı başlık; önce veri kalitesine ve semantiğine yatırım yapın.
• MCP bir standart hâline geliyor; mimaride birinci sınıf bir bileşen olarak konumlandırın.
• Üretim planını GA özellikler üzerine kurun, Preview özelliklere temkinli yaklaşın.
• Ajan yönetişimini (izin, audit, service principal) erken aşamada gündeminize alın.

Geliştiriciler için

• İlişkisel RAG: Azure SQL / SQL Server 2025 VECTOR (GA) + DiskANN (Preview).
• NoSQL RAG: Cosmos DB MCP Toolkit (GA) + integrated embeddings (Preview).
• Analitik ajanları: Fabric data agents (GA) + Fabric IQ (Preview).
• SQL’i ajana açın: Data API Builder ile MCP uç noktası üretin.
• PostgreSQL: Azure HorizonDB Public Preview’a kaydolun.

9. Sık karşılaşılan yanlış bilgiler

Araştırma sırasında doğrulayamadığım birkaç iddiaya da rastladım. Sosyal medyada karşılaşırsanız temkinli yaklaşmanızı öneririm:

• “Azure SQL Hyperscale GA oldu ve yerleşik vektör indeksi içeriyor.”
• “Fabric’te birleşik Database Hub kontrol paneli geldi.”
• “Cosmos DB, Azure’da DiskANN sunan ilk veritabanı.”
• “Cosmos DB in Fabric Build 2026’da GA oldu.” (Doğrusu: Kasım 2025.)
• “Azure SQL için DiskANN private preview, SQL 2025 için public preview.” (Yanlış sürüm bilgisi.)

10. Kaynaklar

1. Cosmos DB DevBlog — Announced at MS Build 2026: MCP Toolkit, Semantic Reranking, GSI & more
2. Cosmos DB DevBlog — GA of Global Secondary Indexes
3. Microsoft Learn — Semantic reranker (Cosmos DB)
4. Cosmos DB DevBlog — Integrated embeddings (Public Preview)
5. Cosmos DB DevBlog — Agent memories & agentic retrieval toolkits
6. Microsoft News — Build 2026 Live Blog
7. Tech Community — Azure HorizonDB
8. Fabric Updates Blog — Building the agentic analytics stack
9. Fabric Updates Blog — GPU-accelerated Fabric Data Warehouse
10. Microsoft Learn — What is Ontology (Preview) — Fabric IQ
11. Fabric Updates Blog — Build 2026: Fabric Data Factory
12. Fabric Updates Blog — Power BI at Build 2026: The Agentic Era
13. Azure Blog — FabCon & SQLCon 2026
14. Microsoft Learn — Data agent in Microsoft Fabric
15. Fabric Updates Blog — The Era of the Agentic Database Developer
16. Azure SQL DevBlog — VS Code MSSQL — June 2026
17. Microsoft Learn — Copilot in SSMS — Agent Mode
18. Azure SQL DevBlog — GA of native VECTOR type in Azure SQL
19. Microsoft Learn — Vectors in SQL Server
20. Azure SQL DevBlog — SQL Server 2025 embraces vectors
21. Microsoft Learn — VECTOR (Transact-SQL)
22. Microsoft Learn — CREATE EXTERNAL MODEL
23. Fabric Blog — GA of Cosmos DB in Microsoft Fabric & Mirroring

Pervasive SQL ile başlayan ve SQL Server 2000’den bugüne uzanan veritabanı yolculuğumda, Microsoft’un veri platformundaki gelişmeleri yakından takip etme fırsatı buldum. Build 2026’nın bu yıl çizdiği “agentic” yönü de, veri ve yapay zekanın artık aynı stratejinin parçası olduğunu net biçimde gösteriyor. Yazıdaki teknik başlıkların tamamını resmî kaynaklara dayandırdım; 7. bölümdeki değerlendirme ise tümüyle kişisel görüşümü yansıtıyor. Sizin bu konudaki senaryolarınızı ve görüşlerinizi de yorumlarda paylaşmanızı, beni izlemeye ve takip etmeye devam etmenizi öneririm. 🙂

Not: GA/Preview durumları ve özellik davranışları zamanla değişebilir; üretim kararından önce ilgili resmî dokümanı bir kez daha doğrulamanızı tavsiye ederim.