Azure SQL’de Vektör Arama: Kurumsal RAG Uygulamaları İçin Mimari Rehber

Azure SQL ve SQL Server 2025, vektör aramayı veritabanının içine taşıyor: VECTOR veri tipiyle embedding’ler iş verisinin yanında saklanabiliyor, VECTOR_DISTANCE fonksiyonuyla benzerlik araması yapılabiliyor ve DiskANN tabanlı vektör indeksleriyle büyük veri setlerinde yaklaşık arama hızlandırılabiliyor. Bu, kurumsal RAG (Retrieval-Augmented Generation) uygulamalarında ayrı bir vektör veritabanına ihtiyaç duymadan başlamayı mümkün kılıyor. Ancak mimari karar yalnızca veri tipiyle verilmez: ölçek, hibrit arama, embedding maliyeti ve kişisel verilerin korunması birlikte düşünülmelidir.

Bu rehber, kurumsal verileri yapay zekâ uygulamalarına bağlamak isteyen mimarlar, yazılım ekipleri ve veri platformu yöneticileri için hazırlandı. Kod örneklerini SQL Server 2025 üzerinde test ettik.

Kısaca: SQL Server ve Azure SQL’de Vektör Desteği

Durumlar Kasım 2026 itibarıyla Microsoft dokümantasyonuna göredir; önizleme özellikleri üretimde kullanılmadan önce güncel durumu kontrol edin.

Temel Kavramlar

Örnek: Vektör Saklama ve Benzerlik Araması

Aşağıdaki örnek, kavramı göstermek için üç boyutlu vektörler kullanıyor. Gerçek uygulamalarda embedding modelleri genellikle yüzlerce veya binlerce boyutlu vektörler üretir.

CREATE TABLE dbo.Documents (
    Id int IDENTITY PRIMARY KEY,
    Title nvarchar(200) NOT NULL,
    Embedding vector(3) NOT NULL
);

INSERT INTO dbo.Documents (Title, Embedding) VALUES
  (N'Yedekleme politikası', '[0.9, 0.1, 0.0]'),
  (N'Geri yükleme testi',   '[0.8, 0.2, 0.1]'),
  (N'Satış raporu',         '[0.0, 0.1, 0.9]');

DECLARE @q vector(3) = '[0.85, 0.15, 0.05]';

SELECT TOP (2) Title,
       VECTOR_DISTANCE('cosine', @q, Embedding) AS distance
FROM dbo.Documents
ORDER BY distance;
-- Yedekleme politikası and Geri yükleme testi come first

Microsoft, arama yapılacak vektör sayısı 50.000’in altındaysa kesin aramayı (VECTOR_DISTANCE ile) önerir. Tablo çok daha fazla satır içerebilir; önemli olan, WHERE koşullarıyla aramaya giren vektör sayısının bu sınırın altında kalmasıdır. Daha büyük veri setlerinde vektör indeksi (CREATE VECTOR INDEX) ve VECTOR_SEARCH fonksiyonu ile yaklaşık arama kullanılır.

Mimari Karar 1: Azure SQL mi, PostgreSQL pgvector mı?

Kural olarak, verinin zaten durduğu platformda başlamak en az riskli seçimdir: embedding’leri ayrı bir sisteme kopyalamak, senkronizasyon, yetki yönetimi ve tutarlılık sorunları getirir. PostgreSQL tarafını PostgreSQL Nedir? yazımızda ele aldık.

Mimari Karar 2: Ne Zaman Ayrı Bir Vektör Veritabanı Gerekir?

İlişkisel veritabanındaki vektör desteği çoğu kurumsal RAG senaryosu için yeterlidir. Ayrı bir vektör veritabanı şu durumlarda değerlendirilmelidir:

• Vektör sayısı yüz milyonlar seviyesine çıkıyorsa ve arama yükü çok yüksekse.
• Vektör aramasına özgü gelişmiş özelliklere (çok vektörlü arama, özel sıralama yöntemleri) ihtiyaç varsa.
• Vektör araması, iş veritabanının performansını etkileyecek kadar yoğunsa.

Ayrı bir sistem, yetki modelinin ve verinin iki yerde yönetilmesi demektir. Bu yükü almadan önce ilişkisel veritabanının sınırlarına gerçekten ulaşıldığını ölçün.

Mimari Karar 3: Hibrit Arama

Vektör araması anlamca benzer içeriği bulur; ancak ürün kodu, sözleşme numarası veya özel isim gibi tam eşleşme gerektiren aramalarda zayıf kalabilir. Hibrit arama, tam metin araması ile vektör aramasının sonuçlarını birleştirir:

SQL Server’da tam metin araması ve vektör araması aynı veritabanında çalışabildiği için hibrit arama, verinin ayrı sistemlere dağıtılmasını gerektirmez. İki sonuç listesi genellikle sıralamaya dayalı bir birleştirme yöntemiyle (örneğin Reciprocal Rank Fusion) tek bir listeye dönüştürülür.

Embedding Maliyeti ve Depolama

KVKK: Hangi Veriler Vektörleştirilmemeli?

Embedding’ler, kaynak metnin anlamını taşır; kişisel veri içeren bir metnin embedding’i de kişisel veriyle ilişkilidir. RAG sistemleri ayrıca bulunan içeriği bir dil modeline gönderir. Bu nedenle:

• Gerekmeyen kişisel veriyi dışarıda bırakın: T.C. kimlik numarası, iletişim bilgileri ve sağlık verisi gibi özel nitelikli kişisel veriler, yanıt üretmek için gerekli değilse vektörleştirilecek içerikten çıkarılmalı veya maskelenmelidir.
• Erişim kontrolünü aramaya taşıyın: Kullanıcı yalnızca yetkisi olan belgelerin parçalarını görmelidir. Row-Level Security gibi mekanizmalar vektör aramasına da uygulanmalıdır; aksi halde RAG, yetki sınırlarını aşan bir sızıntı kanalına dönüşür.
• Model servisinin konumunu değerlendirin: Dil modeli ve embedding servisi yurt dışındaysa, gönderilen bağlam yurt dışına aktarım kapsamında değerlendirilebilir.
• Kayıt tutun: Hangi kullanıcının hangi soruyla hangi içeriğe eriştiği denetlenebilir olmalıdır.

Sahada karşılaştığımız bir örnek: maskelenmemiş verilerle beslenen bir RAG uygulaması, kullanıcılara normalde göremeyecekleri bilgileri yanıt içinde gösterebiliyordu. Bu tür riskleri veri yönetişimi yazımızda, Azure SQL’deki güvenlik kontrollerini Azure SQL KVKK rehberimizde anlattık.

Aryasoft ile Kurumsal RAG Mimarisi

Aryasoft, RAG uygulamalarınız için veritabanı katmanını tasarlar: verinin nerede duracağı, vektör aramasının nasıl yapılacağı, erişim kontrolünün aramaya nasıl taşınacağı ve kişisel verilerin nasıl korunacağı. SQL Server, Azure SQL ve PostgreSQL deneyimimizle, mevcut veri platformunuzdan en az değişiklikle başlayan bir mimari öneririz. Platform seçimini ayrıntılı ele aldığımız RAG için veritabanı seçimi yazımıza ve veri analitiği ve yapay zekâ hizmetlerimize göz atabilirsiniz.

Sıkça Sorulan Sorular

Kaynaklar

Bu rehberdeki teknik bilgiler Kasım 2026’da aşağıdaki resmi dokümantasyonla karşılaştırıldı.

1. Microsoft Learn: Vector Search and Vector Index
2. Microsoft Learn: Vector data type
3. Microsoft Learn: VECTOR_DISTANCE
4. Microsoft Learn: CREATE VECTOR INDEX
5. Microsoft Learn: VECTOR_SEARCH
6. pgvector