Azure SQL Vektör Arama: Optimizer Zekâsı Devrede
Yapay zeka tabanlı arama denince akla önce vektör indeksleri gelir: saniyede kaç sorgu, ne kadar gecikme, hangi geri çağırma oranı? Bu ölçütler önemli, ama gerçek üretim iş yüklerinde vektör benzerliği tek başına yetmez. Filtreler, join’ler, güvenlik politikaları, sıralama mantığı ve canlı operasyonel veriler devreye girdiğinde asıl soru, veritabanının SQL sorgusunun bütünü içinde doğru sonucu nasıl bulacağı. Microsoft, Azure SQL üzerinde bu problemi optimizer düzeyinde ele alan yeni bir yaklaşımı duyurdu.
Üretimdeki AI arama neye benziyor?
Bir kurumsal destek uygulamasında, parola sıfırlaması sonrası VPN bağlantı sorununu araştıran bir destek mühendisini düşünelim. Mühendis “VPN connection fails after password reset” gibi bir aramayla benzer olayları ve bilinen çözümleri görmek ister. Ama sonuçların yalnızca anlamsal olarak benzer olması yetmez: kayıtların hala açık olması, ilgili ürün alanına ait olması, ilişkili tablolardan müşteri bilgisiyle zenginleştirilmesi ve mevcut güvenlik politikaları altında görünür olması gerekir. Bu koşulların bir kısmı yalnızca sorgu yürütüldüğünde bilinen değerlere (seçilen ürün alanı, kiracı kimliği, güncel kullanıcı bağlamı) dayanır.
Kavramsal olarak sorgu şuna benzer:
DECLARE @ProductArea NVARCHAR(50) = 'Networking';
DECLARE @TenantId UNIQUEIDENTIFIER = @CurrentTenantId;
SELECT TOP (10) WITH APPROXIMATE
t.TicketId,
t.Title,
t.PriorityLevel,
t.TicketStatus,
c.CustomerName,
p.ProductName,
s.distance
FROM VECTOR_SEARCH(
TABLE = dbo.SupportTicketEmbeddings,
COLUMN = IssueEmbedding,
SIMILAR_TO = @query_vector,
METRIC = 'cosine'
) AS s
JOIN dbo.SupportTickets t
ON s.TicketId = t.TicketId
JOIN dbo.Customers c
ON t.CustomerId = c.CustomerId
JOIN dbo.Products p
ON t.ProductId = p.ProductId
WHERE t.TicketStatus = 'Open'
AND p.ProductName = @ProductArea
AND c.TenantId = @TenantId
ORDER BY s.distance;Uygulama tarafında basit görünen bu istek, veritabanı açısından çok katmanlı bir optimizasyon problemi: anlamsal olarak ilgili kayıtları bulmak, ilişkisel koşulları uygulamak, gereksiz vektör keşfini ve mesafe hesaplamasını en aza indirerek istenen sayıda uygun sonucu döndürmek.
Vektör arama veritabanının dışındayken ne oluyor?
Vektör aramanın ayrı bir vektör veritabanında yapıldığı mimarilerde iş akışı genellikle birkaç adıma bölünür:
- Sorgu embedding’i harici vektör veritabanına gönderilir.
- Sabit sayıda aday kimliği (örneğin en yakın 100 eşleşme) alınır.
- Bu adaylar ilişkisel veritabanına iletilir.
- Filtreler, join’ler, izinler ve iş kuralları SQL tarafında uygulanır.
- Yeterli sayıda satır kalmazsa daha fazla aday istenip sorgu tekrarlanır.
Bu modelde vektör veritabanı hangi embedding’lerin benzediğini bilir; ama SQL tarafında değerlendirilen ilişkisel koşullardan, join’lerden, güvenlik kurallarından ve canlı iş verilerinden haberdar olmayabilir. İlişkisel veritabanı ise yalnızca harici sistemin seçtiği aday kümesini görür. İki sistem, isteğin farklı parçalarını birbirinden bağımsız optimize eder. Sonuçta uygulama karmaşıklığı artar, ekstra veri hareketi doğar; aday sayısı seçimi, yeniden deneme, veri ile güvenlik sınırlarının uyumlanması gibi yükler geliştiriciye kalır.
Vektör aramayı SQL sorgu işlemenin parçası yapmak
Buradaki sorun vektörlerin nerede saklandığından çok, vektör aramanın sorgunun yürütülmesinde nasıl rol aldığı. Azure SQL’de vektörler ne opak blob’lar olarak tutuluyor ne de veritabanına dışarıdan bağlanan bir servis üzerinden yönetiliyor. Vektör arama; filtre, join, agregasyon ve güvenlik yüklemleri gibi ilişkisel operatörlerle tam anlamıyla birleştirilebildiği için optimizer, onu tüm sorgu bağlamında maliyetlendirebilir. Böylece izole bir adım gibi ele almak yerine alternatif yürütme stratejilerini karşılaştırıp verimli bir plan seçer.
Bu yaklaşımda DiskANN, geniş vektör koleksiyonlarında verimli aday üretimini üstlenir; SQL optimizer ise bu aday üretimini sorgunun geri kalanıyla bütünleştirir. Vektör arama, ilişkisel işlemeyle aynı optimizasyon çerçevesinin parçası haline gelir.
Post-filtering’ten iteratif filtrelemeye
Azure SQL’in daha önceki DiskANN tabanlı vektör aramasında post-filtering modeli kullanılıyordu: vektör indeksi önce sabit bir aday kümesi dönduruyor, ilişkisel yüklemler sonradan uygulanıyordu. Yüklemler geniş ve adayların büyük bölümü uygun olduğunda bu model iyi çalışır. Filtreler seçici hale geldikçe ise adayların önemli bir kısmı elenir ve yeterli sonuç elde etmek zorlaşır.
Yeni sürümde iteratif filtreleme devreye giriyor. Yüklemler artık yalnızca sabit bir aday kümesi üretildikten sonra değil, vektör arama sırasında da uygulanıyor. İki yaklaşımın karşılaştırması:
Önce: Post-filtering
SELECT TOP (20) t.id, t.title, s.distance
FROM VECTOR_SEARCH(
TABLE = wikipedia_articles,
COLUMN = title_vector,
SIMILAR_TO = @query_vector,
METRIC = 'cosine',
TOP_N = 20 /* Over-fetch */
) AS s
WHERE category = 'Technology'
ORDER BY s.distance;Sonuç: bazen 10, bazen 3, bazen 0 kayıt dönebilir; TOP_N değerinin ne olması gerektiği tahminle belirlenir.
Sonra: İteratif filtreleme
SELECT TOP (10) WITH APPROXIMATE
t.id, t.title, s.distance
FROM VECTOR_SEARCH(
TABLE = wikipedia_articles AS t,
COLUMN = title_vector,
SIMILAR_TO = @query_vector,
METRIC = 'cosine'
) AS s
WHERE t.category = 'Technology'
ORDER BY s.distance;Sonuç: yeterli eşleşen kayıt olduğu sürece istenen sayıda uygun sonuç elde edilir; sabit bir over-fetch değeri seçmeye gerek kalmaz. Aday keşfi ile ilişkisel eşleşme birlikte çalıştığından motor, sorgunun geri kalanının nasıl davranacağını bilmeden tek bir aday sayısına bağlanmak zorunda değildir.
WITH APPROXIMATE ve akıllı karar mekanizması
WITH APPROXIMATE ifadesi, yaklaşık en yakın komşu sonuçlarının kabul edilebilir olduğunu Azure SQL’e bildirir; yürütme stratejisini ise motora bırakır.
Derleme zamanında optimizer, mevcut yaklaşımları tüm sorgu bağlamını ve tahmini yürütme maliyetini kullanarak değerlendirir. Yüklemlerin çok seçici olmadığı büyük vektör koleksiyonlarında yaklaşık en yakın komşu (ANN) araması iyi çalışabilir. Yüksek seçicilikte filtre içeren sorgularda ise ek ANN keşfi yerine kesin en yakın komşu araması daha uygun olabilir. Karar; yüklem seçiciliği, veri dağılımı, mevcut ilişkisel ve vektör indeksleri, istenen sonuç sayısı gibi etkenlere göre iş yüküne özgüdür ve garantili bir karar matrisi sunmaz.
Çalışma zamanında yürütme motoru, kaynaklara ve sorgu koşullarına uyum sağlayabilir. Filtreli Top-K isteğini karşılamak için ek uygun satırlara ihtiyaç duyulduğunda Azure SQL, gereken yerde ANN ile kesin komşu (KNN) araması arasında geçiş yapabilir. Böylece uygulamanın bir over-fetch değeri tahmin etmesine gerek kalmadan uygun sonuçlar döndürülür.
Aynı T-SQL yüzeyi, sorguya ve kaynaklara bağlı olarak farklı yürütme stratejilerini destekleyebilir. Geliştiricinin ANN ile kesin komşu araması arasında seçim yapması gerekmez; niyet ifade edilir, yürütme kararını Azure SQL verir.
Vektör aramayı SQL yaparak elde edilenler
Her veritabanı bir vektör indeksi ekleyebilir. Asıl zorluk, vektör aramayı üretim iş yüklerinin zaten güvendiği optimizer, yürütme motoru, güvenlik modeli ve sorgu işleme altyapısıyla bütünleştirmek. Azure SQL, vektörleri birinci sınıf bir SQL veri tipi olarak ele alarak anlamsal aramanın şu alanlardan faydalanmasını sağlıyor:
- Maliyet tabanlı optimizasyon
- Uyarlamalı yürütme
- Güvenlik ve yönetişim
- Transaksiyonel tutarlılık
- Ölçekte ilişkisel işleme
Ortaya çıkan tablo, yalnızca “veritabanı içinde vektör arama” değil; SQL gibi davranan bir vektör arama. AI uygulamaları giderek canlı operasyonel veri üzerinde çalıştıkça bu farkın vektör indeksinin kendisinden daha belirleyici hale geldiği söylenebilir.
Nasıl başlanır?
Vektör desteğini ve iteratif filtrelemeyi denemek için iki yol öne çıkıyor. İlki yerel geliştirme: Azure SQL Developer, Azure SQL Database motorunu bir konteyner içinde makinenize getirir; yerel geliştirme ve CI için ücretsizdir, Azure aboneliği veya kredi kartı gerektirmez ve yerel prototipleme için doğal vektör yeteneklerini destekler. İkincisi bulut deneyimi: Azure SQL Database ücretsiz teklifi ile başlangıç mümkün. Kota ve kullanım koşullarının güncel ayrıntıları için resmi belgelere başvurmakta fayda var.
Kaynaklar ve İleri Okuma
- Beyond Vector Indexes: Azure SQL Brings Optimizer Intelligence to Vector Search (Orijinal yazı)
- DiskANN Vector Index Improvements — Azure SQL Dev Corner
- Azure SQL Developer duyurusu
- Azure SQL Database ücretsiz teklif dokümanı
- DiskANN iyileştirmeleri örnek T-SQL
- Project Akupara — Approximate Nearest Neighbor Search
- Azure SQL’de DiskANN Vektör İndeksleri: Gerçekten Neler Değişti?
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
3 comments