RAG Sistemlerinde Metadata Filtreleme Nasıl Yapılır?

RAG sistemlerinde metadata filtreleme, vektör araması öncesinde veya sonrasında verileri yapılandırılmış etiketlerle süzerek LLM yanıtlarının doğruluğunu artırır.

Geri Getirme ile Zenginleştirilmiş Üretim (Retrieval-Augmented Generation - RAG) mimarilerinde yalnızca semantik benzerliğe güvenmek, büyük ölçekli kurumsal veri havuzlarında yetersiz kalır. Büyük dil modellerinin (LLM) doğru ve güncel bağlama ulaşabilmesi, vektör uzayındaki yoğun gömmelerin (dense embeddings) yapılandırılmış metaveri alanlarıyla disipline edilmesine bağlıdır. İşletme sahipleri, yazılım mimarları ve teknik karar vericiler için RAG Sistemlerinde Metadata Filtreleme Nasıl Yapılır? sorusu, yanıt kalitesini maksimize ederken gecikme süresini (latency) ve altyapı maliyetlerini optimize etmenin merkezinde yer alır. Bu rehber; şema tasarımından rol tabanlı erişim kontrolüne (RBAC), ön filtreleme (pre-filtering) ve tek aşamalı (single-stage) filtreleme algoritmalarından donanım optimizasyonuna kadar tüm teknik adımları kapsamaktadır.

Vektör Aramasının Sınırları: Neden Sadece Semantik Benzerlik Yetmez?

Semantik arama mekanizmaları, metinleri yüksek boyutlu vektör uzaylarına izdüşürerek kavramsal yakınlığı hesaplar. İki metin parçası arasındaki benzerlik genellikle kosinüs benzerliği ($\text{similarity} = \cos(\theta) = \frac{\mathbf{A} \cdot \mathbf{B}}{\|\mathbf{A}\| \|\mathbf{B}\|}$) veya Öklid mesafesi üzerinden ölçülür. Ancak salt matematiksel yakınlık, bilginin operasyonel geçerliliğini, zaman boyutunu veya erişim izinlerini hesaba katmaz. Kurumsal ölçekteki doküman kütüphanelerinde binlerce benzer ifade yer alabilir; bu durum vektör aramasının alakasız belgeleri "yüksek benzerlik skoruna sahip" şeklinde değerlendirmesine yol açar.

Salt vektör aramasının yetersiz kaldığı temel durumlar şunlardır:

• Zamansal Ayrım Yetersizliği: "2023 yılı finansal raporu" ile "2026 yılı finansal bütçe hedefleri" anlamsal olarak birbirine son derece yakındır; ancak sorgu güncel yılı hedeflediğinde vektör araması eski veriyi getirebilir.

• Kategori ve Ürün İzolasyonu: Bir e-ticaret platformunda "kablosuz kulaklık şarj sorunu" araması yapıldığında, farklı modellerin aynı kelimeleri içeren kullanım kılavuzları semantik olarak eşleşir ve yanlış modelin sorun giderme adımı bağlama dahil edilir.

• Güvenlik ve Yetki Duvarları: Çok kiracılı (multi-tenant) sistemlerde semantik benzerlik, farklı müşterilerin veya departmanların verilerini birbirinden izole edemez.

"Kelimelerin Anlamı" Neden Hatalı Bağlam Getirebilir? (Gürültülü Veri Sorunu)

Vektör gömme (embedding) modelleri, metnin yazıldığı tonu ve sözcük dizilimini yoğunlaştırarak soyut bir anlamsal temsil üretir. Ancak bu temsil, yapılandırılmış kısıtlamaları içermez. Örneğin, kurumsal bir bilgi bankasında "İzin politikası nasıl işler?" sorusu yöneltildiğinde; Türkiye, Almanya ve ABD ofislerinin insan kaynakları politikaları kavramsal olarak neredeyse farksız vektör temsilleri üretir. Kullanıcı Türkiye ofisi çalışanı olsa dahi, embedding modeli Almanya ofisinin kılavuzunu daha yüksek bir benzerlik skoruyla döndürebilir.

Bu olgu, geri getirme aşamasında "gürültülü veri" (noisy retrieval) problemine neden olur. Model, kullanıcının niyet ettiği coğrafi, departmansal veya sürümsel kısıtları anlamlandırmak için gerekli yapısal referans noktalarına sahip değildir. Çözüm, arama uzayını yalnızca semantik vektör mesafelerine bırakmak yerine, verinin doğasını niteleyen kesin etiketlerle sınırlandırmaktır.

LLM Yanıt Doğruluğu ve Halüsinasyon Riski Arasındaki Doğrudan İlişki

Büyük dil modellerinin ürettiği halüsinasyonların (olmayan bilgiyi gerçek gibi sunma) önemli bir bölümü, bağlam penceresine (context window) yanlış veya çelişkili verilerin iletilmesinden kaynaklanır. Bir LLM, kendisine sağlanan metin parçaları (chunks) arasında zamansal veya mantıksal bir çelişki gördüğünde, bu çelişkiyi kendi parametrik hafızasındaki olasılık dağılımlarına göre tamamlama eğilimine girer.

Metadata filtreleme, bağlam penceresine girecek metin parçalarını önceden doğrulayarak halüsinasyon riskini doğrudan azaltır. Sisteme iletilen bağlam ne kadar temiz, güncel ve amaca yönelik olursa, modelin deterministik ve doğrulanabilir yanıtlar üretme oranı o kadar yükselir.

RAG Sisteminde Metadata Filtreleme Nedir ve Nasıl Çalışır?

RAG mimarisinde metadata filtreleme; dokümanların parçalanması (chunking) sırasında her bir metin bloğuna anahtar-değer (key-value) çiftleri şeklinde yapılandırılmış öznitelikler atanması ve arama anında bu öznitelikler üzerinden mantıksal sorguların çalıştırılması prensibidir. Bu yaklaşım, NoSQL veya ilişkisel veritabanlarındaki WHERE koşullarının vektör uzayına entegre edilmiş halidir.

Vektör veritabanlarında saklanan her kayıt temel olarak üç bileşenden oluşur:

1. Vektör Gömme (Dense/Sparse Embedding): Metin parçasının matematiksel temsili (örn. 1536 veya 3072 boyutlu dizi).

2. Ham Metin Parçası (Payload/Chunk): LLM'e bağlam olarak gönderilecek orijinal metin içeriği.

3. Metaveri (Metadata Attributes): Filtreleme ve sıralama için kullanılacak JSON formatındaki yapılandırılmış etiketler.

{
  "id": "doc_8492_chunk_03",
  "values": [0.0231, -0.0451, 0.0892, "..."],
  "metadata": {
    "tenant_id": "enterprise_corp_a",
    "document_type": "sla_contract",
    "department": "legal",
    "access_level": 3,
    "valid_until": "2027-12-31",
    "language": "tr",
    "created_at": 1725667200
  }
}

Yapılandırılmış (Structured) ve Yapılandırılmamış (Unstructured) Verinin Hibrit Kullanımı

Modern kurumsal sistemlerde bilgi hem serbest metin (raporlar, e-postalar, sözleşmeler) hem de ilişkisel tablolar (müşteri numaraları, işlem tarihleri, fiyatlar) biçiminde bulunur. Hibrit arama mimarisi, yapılandırılmamış metinlerin semantik derinliğini yapılandırılmış verilerin deterministik kesinliğiyle birleştirir.

Kullanıcı "Hukuk departmanının 2026 yılı sözleşme fesih şartları nelerdir?" sorgusunu yönelttiğinde, sistem iki aşamalı bir çözümleme yapar. Doğal dil işleme katmanı sorgudan department: legal, year: 2026 ve doc_type: contract metaveri filtrelerini çıkarırken, "sözleşme fesih şartları" ifadesini embedding modeline ileterek vektör araması gerçekleştirir. Böylece milyarlarca satırlık veri havuzu anında daraltılır.

Metaveri Şeması (Metadata Schema) Tasarlarken Dikkat Edilmesi Gereken Kurallar

Veri parçalama (chunking) stratejisi kurgulanırken metaveri şeması rastgele oluşturulmamalıdır. Şema tasarımı, sorgu maliyetlerini ve bellek kullanımını doğrudan etkiler.

Metaveri şeması oluştururken şu kurallara dikkat edilmelidir:

• Kardinalite Dengesi: Çok yüksek kardinaliteye sahip alanlar (milyonlarca benzersiz değer içeren UUID'ler gibi) endeksleme boyutunu artırabilir. Sık filtrelenen alanlar için payload endeksleri (payload index) oluşturulmalıdır.

• Tip Güvenliği: Tarih ve sayısal aralık filtrelemeleri yapılacak alanların string yerine Integer veya Float olarak tanımlanması gerekir. Aksi halde büyüktür/küçüktür (, $\le$) operasyonları çalıştırılamaz.

• Veri Fazlalığından Kaçınma: Her chunk içine megabaytlarca metaveri eklemek, vektör veritabanının RAM tüketimini katlar. Sadece arama ve yetkilendirme aşamasında kullanılacak kritik alanlar metaveriye eklenmelidir.

Metadata Filtreleme Yöntemleri: Pre-Filtering mi, Post-Filtering mi?

Vektör aramalarında filtreleme operasyonunun hangi aşamada yapıldığı, sistemin gecikme süresi (latency), bellek tüketimi ve arama doğruluğu (recall) üzerinde belirleyici bir rol oynar. Literatürde ve endüstriyel uygulamalarda üç temel yaklaşım öne çıkar: Post-Filtering (Sonradan Filtreleme), Pre-Filtering (Ön Filtreleme) ve Single-Stage Filtering (Tek Aşamalı / Hibrit Filtreleme).

1. Post-Filtering:
   [Tüm Vektör Uzayında k-NN Arama] -> [En Yakın N Sonuç] -> [Metadata Filtresi] -> [Eksik Sonuç Riski]

2. Pre-Filtering (Geleneksel):
   [Metadata Filtresi] -> [Eşleşen Alt Küme] -> [İzole Vektör Araması] -> [Yüksek Latency Riski]

3. Single-Stage / Iterative Filtering (Modern):
   [Vektör Grafiği (HNSW) Taraması Sırasında Eşzamanlı Metadata Doğrulaması] -> [Hızlı ve Tam İsabet]

Post-Filtering (Sonradan Filtreleme): Nedir, Hangi Durumlarda Performans Kaybına Yol Açar?

Post-filtering yaklaşımında vektör veritabanı önce tüm veri seti üzerinde yaklaşık en yakın komşu (ANN - Approximate Nearest Neighbor) aramasını çalıştırır ve en yüksek benzerliğe sahip ilk $k$ adet sonucu (örneğin $k=100$) döndürür. İkinci adımda, bu 100 sonuç üzerinden yapılandırılmış metaveri filtresi uygulanarak uymayan kayıtlar atılır.

Bu yöntemin kritik bir dezavantajı vardır: Sonuç Kümesinin Tükenmesi (Recall Collapse). Eğer aranan metaveri kriteri tüm veri setinin yalnızca küçük bir yüzdesini kapsıyorsa (örneğin belirli bir kullanıcının özel dosyaları), ilk 100 vektör sonucu arasında bu kritere uyan yalnızca 1 veya 2 doküman bulunabilir (hatta hiç bulunmayabilir). Bu durum, LLM'e yetersiz bağlam gitmesine ve sistemin yanıt verememesine yol açar. Bu nedenle post-filtering, dar filtreleme senaryolarında kurumsal standartlara uygun değildir.

Pre-Filtering (Ön Filtreleme): Hız ve Altyapı Maliyetini Optimize Etme Yöntemi

Pre-filtering yaklaşımında, sistem önce metaveri kriterlerine göre geleneksel bir boolean/indeks taraması yapar. Eşleşen kayıtların kimlikleri (ID listesi) belirlenir ve vektör araması yalnızca bu filtrelenmiş alt küme üzerinde yürütülür.

Geleneksel veritabanlarında pre-filtering, eğer filtrelenen alt küme için özel bir vektör indeksi önceden inşa edilmemişse yüksek hesaplama maliyetine yol açabilir; çünkü HNSW (Hierarchical Navigable Small World) gibi gelişmiş vektör grafikleri tüm veri kümesine göre optimize edilmiştir. Ancak modern altyapılarda bu kısıt optimize edilmiştir.

Modern Vektör Veritabanlarında Tek Aşamalı (Single-Stage) Filtreleme Yaklaşımı

Yeni nesil vektör veritabanları (Pinecone, Qdrant, Milvus, Weaviate ve pgvector destekli PostgreSQL), HNSW grafik gezintisi sırasında metaveri koşullarını dinamik olarak değerlendiren "tek aşamalı" (single-stage) veya "yinelemeli" (iterative) filtreleme mekanizmaları kullanır.

Bu yöntemde vektör grafiğinde gezinirken, bir düğümün (node) komşularına bakılırken aynı anda payload indeksi kontrol edilir. Filtre şartını sağlamayan düğümler doğrudan atlanır ve arama yalnızca geçerli düğümler üzerinden devam eder. Böylece hem post-filtering'deki sonuç tükenmesi sorunu ortadan kalkar hem de geleneksel pre-filtering'in getirdiği ek hesaplama yükü bertaraf edilir.

Kurumsal Kullanım Senaryoları ve Entegrasyon Stratejileri

Kurumsal ölçekte RAG sistemlerinin devreye alınmasında en büyük engellerden biri veri güvenliği, yasal uyumluluk (KVKK, GDPR, HIPAA) ve güncel bilgiye erişim zorunluluklarıdır. Metadata filtreleme, bu gereksinimlerin teknik olarak karşılanmasını sağlayan anahtar mekanizmadır.

Rol Tabanlı Erişim Kontrolü (RBAC): Veri Gizliliği ve Yetkilendirme Filtreleri

Büyük bir şirkette tüm çalışanların şirket içi LLM asistanını kullandığı bir senaryoda; İnsan Kaynakları bordro verileri, yönetim kurulu kararları veya Ar-Ge patent taslakları herkesin erişimine açık olamaz. Çok kiracılı (multi-tenant) sistemlerde tek bir vektör koleksiyonu üzerinden RBAC uygulanabilir.

Kullanıcı sisteme giriş yaptığında kimlik doğrulama servisinden (OAuth, SAML, Active Directory) kullanıcının rolü ve yetki seviyesi alınır. Yapılan her arama sorgusuna otomatik olarak bir güvenlik filtresi enjekte edilir:

# LangChain / Pinecone Entegrasyon Örneği
retriever = vectorstore.as_retriever(
    search_kwargs={
        "k": 5,
        "filter": {
            "tenant_id": {"$eq": user_session.tenant_id},
            "allowed_roles": {"$in": user_session.roles},
            "security_clearance": {"$lte": user_session.clearance_level}
        }
    }
)

Bu filtre sayesinde, arama algoritması kullanıcının yetkisi dışındaki dokümanları hiçbir aşamada görmez. LLM'e sadece kullanıcının görmeye izinli olduğu parçalar iletilir; böylece veri sızıntısı riski ortadan kaldırılır.

Zamana Duyarlı (Temporal) Verilerde Filtreleme ile Güncel Bilgiye Ulaşım

Mevzuat, vergi kanunları, şirket içi operasyon prosedürleri ve ürün fiyat listeleri sürekli güncellenir. Bir sistemde hem 2024 hem 2026 yılına ait dökümanlar bulunabilir. Zamana duyarlı metadata filtreleme, kullanıcının talebine göre en güncel versiyonun seçilmesini sağlar.

• Geçerlilik Aralığı Filtreleme: valid_from <= current_date AND valid_to >= current_date filtresi ile süresi dolmuş sözleşmeler ve kılavuzlar otomatik olarak elenir.

• Sürüm Bazlı Arama: Dokümanlara eklenen version: "3.2" veya is_latest: true bayrakları, modelin eski sürümlerdeki teknik hataları yanıt olarak üretmesini engeller.

E-Ticaret ve Müşteri Hizmetlerinde Ürün/Kategori Bazlı Kısıtlamalar

E-ticaret asistanlarında kullanıcı "5000 TL altındaki Bluetooth kulaklıkların şarj sürelerini karşılaştır" dediğinde, sistem LLM tabanlı bir sorgu ayrıştırıcı (Self-Query Retriever) kullanarak doğal dilden yapılandırılmış filtre üretir:

{
  "query": "Bluetooth kulaklık şarj süresi",
  "filter": {
    "$and": [
      {"category": {"$eq": "kulaklik"}},
      {"connectivity": {"$eq": "bluetooth"}},
      {"price": {"$lte": 5000}},
      {"in_stock": {"$eq": true}}
    ]
  }
}

Bu yapılandırma, stokta olmayan veya bütçeyi aşan ürünlerin anlamsal olarak ne kadar yakın olursa olsun elenmesini sağlar.

Uygulama Aşamasındaki Riskler, Sınırlandırmalar ve Maliyet Yönetimi

Metadata filtreleme mekanizması her ne kadar doğruluğu artırsa da, yanlış kurgulandığında sistem performansında darboğazlara ve altyapı maliyetlerinde artışa neden olabilir. Karar vericilerin gecikme (latency), bellek (RAM/CPU) ve filtreleme derinliği arasındaki ödünleşimleri (trade-offs) doğru yönetmesi gerekir.

Gecikme Süresi (Latency) ve Donanım (CPU/RAM/GPU) İhtiyacının Dengelenmesi

Vektör veritabanlarında metaveri alanlarının endekslenmesi ek bellek tüketimi demektir. Özellikle Inverted Index (ters yüz edilmiş indeks) veya B-Tree indeksleri oluşturulduğunda, RAM gereksinimi veri büyüklüğüne bağlı olarak %30 ila %60 oranında artabilir.

Sistem mimarisinde gecikme süresini 50 ms altında tutabilmek için şu prensipler uygulanmalıdır:

1. Yalnızca filtreleme koşullarında (WHERE, $in, $gte) kullanılacak alanlar endekslenmelidir. Sadece arayüzde gösterilecek bilgiler (örneğin yazarın e-posta adresi) vektör veritabanı yerine ilişkisel ana veritabanında tutulmalıdır.

2. Karmaşık iç içe (nested) JSON yapıları yerine düz (flat) anahtar-değer yapıları tercih edilmelidir.

Aşırı Filtreleme (Over-Filtering) Riski: LLM'in İhtiyaç Duyduğu Bağlamı Yok Etmek

Filtreleme kurallarının çok katı tutulması, arama uzayını gereğinden fazla daraltarak modelin ihtiyaç duyduğu tamamlayıcı bilgileri dışarıda bırakabilir. Buna literatürde "Over-Filtering" (Aşırı Filtreleme) denir.

Örneğin, "Şirket içi uzaktan çalışma politikasında yemek yardımı var mı?" sorusunda sistem hem category: remote_work hem de category: meal_allowance gibi aşırı spesifik iki ayrı filtreyi AND mantığıyla bağlarsa, genel "Sosyal Haklar Kılavuzu"ndaki ilgili paragraf filtrelenebilir. Bu riski önlemek için:

• Katı AND mantığı yerine, hiyerarşik filtreleme veya eşik değerine bağlı genişleyen (fallback) filtreleme mekanizmaları kurgulanmalıdır.

• Gerekli durumlarda filtre sonucu 0 dönerse, filtre kriterleri bir kademe gevşetilerek (örneğin sadece departman filtresi korunarak) sorgu tekrarlanmalıdır.

Veri Güncelleme Sıklığı ve Endeksleme (Indexing) Performansı

Sık güncellenen kurumsal ortamlarda (örneğin dakikada binlerce fiyat veya stok güncellemesi alan sistemler), vektör indekslerini ve bunlara bağlı metaveri alanlarını anlık olarak yeniden indekslemek yüksek CPU tüketimine yol açar.

Bu gibi dinamik senaryolarda; sık değişen veriler (fiyat, stok durumu, son görülme tarihi) vektör veritabanında bir metaveri olarak saklanmak yerine, vektör aramasından dönen document_id üzerinden harici bir önbellek katmanından (Redis, Key-Value Store) milisaniyeler içinde çekilerek doğrulanmalıdır.

RAG Mimarisinde Sürdürülebilir Başarı İçin İnsan Denetimi (Human-in-the-Loop)

Metadata filtreleme ve vektör arama entegrasyonu ne kadar sofistike olursa olsun, hiçbir yapay zeka mimarisi sıfır hata garantisi veremez. Üretim ortamında çalışan RAG sistemlerinin uzun vadeli başarısı, düzenli insan denetimi (Human-in-the-Loop) ve sürekli değerlendirme (evaluation) süreçlerine bağlıdır.

Sistemin başarısını ölçmek için endüstri standardı olan RAG Üçlüsü (RAG Triad) metrikleri takip edilmelidir:

1. Bağlam Uygunluğu (Context Relevance): Geri getirilen ve filtrelenen metin parçaları kullanıcının sorusuna gerçekten doğrudan yanıt veriyor mu?

2. Dayanaklılık (Groundedness / Faithfulness): LLM'in ürettiği nihai yanıt, sağlanan filtrelenmiş bağlama ne kadar sadık kalıyor? Halüsinasyon içeriyor mu?

3. Yanıt Uygunluğu (Answer Relevance): Üretilen yanıt kullanıcının ilk başta sorduğu soruya eksiksiz ve doğrudan cevap veriyor mu?

Kurumsal organizasyonlarda konu alanı uzmanları (Domain Experts), sistem logları üzerinden dönemsel kontroller yapmalıdır. Kullanıcıların "başarısız/hatalı yanıt" olarak işaretlediği sorgular incelenmeli; hatanın yanlış chunking stratejisinden mi, eksik metaveri etiketlemesinden mi yoksa aşırı katı filtreleme kurallarından mı kaynaklandığı tespit edilerek şemalar güncellenmelidir. Yapay zeka sistemleri nihai karar verici değil; insan uzmanlığını destekleyen, filtrelenmiş ve doğrulanmış bilgi sağlayan güçlü birer operasyonel araç olarak konumlandırılmalıdır.