# Meta Veri Tasarımı: RAG'de Filtrelemenin Temeli > Source: https://sukruyusufkaya.com/blog/rag-meta-veri-tasarimi > Updated: 2026-08-23T23:10:33.270Z > Type: blog > Category: yapay-zeka **TLDR:** Meta veri tasarımı, RAG'de doğru parçayı doğru kullanıcıya getirmenin temelidir: zorunlu alan seti, yetki alanı, tarih ve sürüm alanı, filtreleme RAG kalitesi. Meta veri tasarımı, bir RAG (Retrieval-Augmented Generation) sisteminde her belge parçasına, anlamının yanında onu tanımlayan yapısal alanları — kaynak, tarih, sürüm, bölüm, dil, belge türü ve en önemlisi erişim/yetki bilgisini — bilinçli olarak eklemektir. Bu alanlar sayesinde getirme yalnızca "anlamca en yakın parça hangisi" sorusuna değil, "hangi parça bu kullanıcı, bu bağlam ve bu an için uygun" sorusuna da cevap verir. Kısacası meta veri tasarımı, RAG'de filtrelemenin temelidir. RAG'in getirme kalitesi çoğu zaman embedding, chunking ve reranking üçlüsüyle anlatılır; ama üretim ortamında bu üçlü doğru kurulsa bile sistem, meta veri katmanı zayıfsa sessizce yanlış cevaplar üretir. Doğru cümleyi bulur ama yanlış sürümden getirir; anlamca isabetlidir ama kullanıcının görmeye yetkili olmadığı bir belgeden alıntılar; ilgili paragrafı yakalar ama bunun hangi departmana, hangi tarihe, hangi geçerlilik durumuna ait olduğunu bilemez. Bu yazıda meta veri tasarımını bir danışman titizliğiyle ele alıyoruz: meta verisiz aramanın sınırı nedir, zorunlu alan seti nasıl belirlenir, yetki ve gizlilik alanları nasıl kurulur, tarih ve sürüm alanı geçerliliği nasıl yönetir, otomatik çıkarım nerede güvenilir nerede değil, şema değişikliği nasıl yönetilir ve pratik bir tasarım şablonu neye benzer. Bu yazı, RAG'in genel mantığını bildiğinizi varsayar; temeli tazelemek isterseniz RAG nedir kapsamlı rehberi, getirmenin anlamsal tarafı için embedding nedir ve vektör veritabanı nedir, parçalama tarafı için chunking nedir iyi bir başlangıçtır. Biz burada özel açımıza — meta veri tasarımı ve filtreleme — odaklanıyoruz ve bu konuları tekrar etmiyoruz. ## Meta Verisiz Aramanın Sınırı Nedir? Meta veri tasarımının neden gerekli olduğunu anlamak için önce onsuz ne olduğunu görmek gerekir. Salt anlamsal aramaya dayanan bir RAG, her parçayı yalnızca bir vektör — anlamının sayısal temsili — olarak tanır. Bu güçlüdür: "iade koşulları" sorusu, belgede "para iadesi şartları" yazsa bile doğru parçayı yakalayabilir. Ama bu güç aynı zamanda bir körlüktür: sistem parçanın ne zaman yazıldığını, hangi sürüme ait olduğunu, kime ait olduğunu ve kimin görmeye yetkili olduğunu bilmez. Anlam vardır, bağlam yoktur. Bu körlük üretimde dört tipik hataya yol açar. Birincisi sürüm karışıklığıdır: bir prosedürün 2023 ve 2025 sürümleri aynı bilgi tabanındaysa, anlamsal arama ikisini de "çok ilgili" bulur ve model rastgele birine — belki eskisine — dayanarak yanlış cevap verir. İkincisi yetki sızıntısıdır: tüm belgeler tek havuzdaysa, bir çalışan masum bir soru sorarak görmemesi gereken bir maaş tablosuna veya gizli sözleşmeye anlamsal olarak "yakın" bir parçaya ulaşabilir. Üçüncüsü bağlam karışması: aynı terim iki farklı üründe, iki farklı ülke mevzuatında veya iki farklı departmanda farklı anlama gelir; meta verisi olmayan bir parça bu ayrımı yapamaz. Dördüncüsü kaynak gösterememe: parça hangi belgeden, hangi bölümden, hangi tarihten geldiğini taşımıyorsa, kullanıcıya güvenilir bir atıf sunulamaz. Bu dört hatanın ortak kökü şudur: anlamsal benzerlik gerekli ama yeterli değildir. "Anlamca yakın" her zaman "doğru" demek değildir. Meta veri tasarımı tam olarak bu boşluğu doldurur — anlama, ölçülebilir bir bağlam ekler. Filtreleme RAG sistemlerinin bu tuzaklara düşmesini, aramayı önce doğru alt kümeye daraltarak engeller. Böylece sistem "en benzer parça" yerine "uygun parçalar arasında en benzer olanı" getirir; bu ikisi arasındaki fark, kurumsal bir uygulamada güven ile risk arasındaki farktır. RAG'de en tehlikeli hata sınıfı, sistemin anlamca doğru ama bağlamca yanlış parça getirmesidir; çünkü bu hata gözle fark edilmez. Cevap akıcıdır, kaynağı vardır, ama kaynak yanlış sürümdür veya yetkisiz bir belgedir. Meta veri tasarımı olmayan bir RAG, bu hatayı yapıp yaptığını bile bilmez. Filtre katmanı, işte bu görünmez hatayı görünür ve önlenebilir kılar. ## RAG'de Zorunlu Alan Seti Nedir? Meta veri tasarımının ilk pratik adımı, bir zorunlu alan seti tanımlamaktır: neredeyse her kurumsal RAG'in her parçasında bulunması gereken minimum alanlar. Buradaki disiplin, "her şeyi topla" değil, "her alanın bir amacı olsun" ilkesidir. Bir alanı ancak onu getirmeyi filtrelemek, erişimi kontrol etmek, kaynak göstermek veya kaliteyi izlemek için kullanacaksanız eklersiniz; hiçbir amaca hizmet etmeyen alan yalnızca bakım yükü ve tutarsızlık kaynağıdır. Aşağıdaki alan seti, çoğu kurumsal senaryo için sağlam bir temeldir. Bunu bir başlangıç şablonu olarak alın ve kurumunuzun ihtiyacına göre daraltın veya genişletin: Bu alan setini okurken üç noktayı ayırt etmek gerekir. Birincisi, alanların bir kısmı filtre içindir (belge türü, dil, erişim düzeyi, geçerlilik), bir kısmı sıralama ipucudur (tarih, sürüm), bir kısmı da kaynak gösterme ve yönetişim içindir (doc_id, bölüm, sahiplik). Aynı alan birden çok amaca hizmet edebilir; önemli olan her alanın en az bir amacının net olmasıdır. İkincisi, alanların değer tipi ve sözlüğü baştan tanımlanmalıdır: "belge türü" serbest metin değil, kontrollü bir liste olmalıdır — aksi halde "politika", "Politika", "policy" gibi tutarsız değerler filtreyi bozar. Üçüncüsü, alanların çoğu parça (chunk) düzeyinde de, belge düzeyinde de tutulabilir; pratikte belge düzeyi meta veri, indeksleme sırasında her parçaya kopyalanır (denormalizasyon) ki filtreleme parça düzeyinde hızlı çalışsın. Zorunlu alan seti, bir kurumsal RAG'in en fazla değer üreten ama en çok ihmal edilen yatırımlarından biridir. Bu setin tasarımı, aslında bir veri modelleme çalışmasıdır; kurumsal bir RAG rehberinin veri katmanıyla doğrudan ilişkilidir. Konuyu uçtan uca bir mimari içinde görmek için kurumsal RAG rehberi ve genel veri disiplini için veri yönetişimi nedir yazıları bağlam sağlar. ## Doküman Etiketleme ve Kontrollü Sözlük Nasıl Kurulur? Zorunlu alan setindeki en esnek — ve en kolay bozulan — alan etiketlerdir. Doküman etiketleme, belgelere veya parçalara konu, ürün, departman, süreç veya gizlilik gibi anlamlı etiketler atama işidir; iyi yapıldığında filtrelemeyi ve daraltmayı güçlendirir, kötü yapıldığında ise bir kaos kaynağıdır. Serbest bırakılmış etiketler kısa sürede tutarsızlaşır: "insan kaynakları", "İK", "HR", "ik-politika" aynı şeyi kasteder ama filtre için dört farklı değerdir. Bu yüzden doküman etiketleme, bir kontrollü sözlük (taksonomi) etrafında disipline edilmelidir. Kontrollü sözlük, izin verilen etiket değerlerinin ve aralarındaki ilişkilerin tanımlı olduğu bir yapıdır. Basit haliyle düz bir liste (onaylı konular), gelişmiş haliyle hiyerarşik bir ağaç (ürün > alt ürün > özellik) olabilir. Amaç, aynı kavramın tek bir kanonik değerle temsil edilmesidir. Etiket atarken serbest yazım yerine bu sözlükten seçim yaptırmak — veya otomatik atanan etiketleri sözlüğe eşlemek (kanonikleştirme) — filtrenin güvenilirliğini korur. Varlık bazlı etiketleme için named entity recognition teknikleri, ham metinden aday etiket çıkarmada yardımcı olur; ama çıkan varlıkların mutlaka kontrollü sözlüğe eşlenmesi gerekir. İyi bir doküman etiketleme disiplini birkaç ilkeye dayanır. Birincisi azlık: çok sayıda nadir etiket, filtreyi zayıflatır; birkaç iyi tanımlı, sık kullanılan etiket, çok sayıda gürültülü etiketten değerlidir. İkincisi tutarlılık: aynı belge, kim etiketlerse etiketlesin aynı etiketleri almalıdır; bu, net tanımlar ve örneklerle sağlanır. Üçüncüsü amaç odaklılık: bir etiketi ancak onunla filtreleme veya yönlendirme yapacaksanız ekleyin. Doküman etiketleme, meta veri tasarımının en çok elle dokunulan parçasıdır; bu yüzden hem otomatik önerinin hem insan denetiminin dengeli kullanıldığı bir süreç kurmak, uzun vadede en sürdürülebilir yaklaşımdır. Doküman etiketleme projelerinde en yaygın bozulma, zamanla kontrolsüz büyüyen etiket sayısıdır. Herkes kendi etiketini eklerse, birkaç ay içinde yüzlerce nadir, çakışan ve yazım farklılıkları olan etiket birikir; bu noktada etiketler filtre için işe yaramaz hale gelir. Çözüm, etiket eklemeyi bir sözlük yönetim sürecine bağlamaktır: yeni etiket, mevcut sözlükte karşılığı yoksa ve gerçekten filtre değeri üretecekse eklenir. ## Yetki ve Gizlilik Alanları: İzin Getirmede mi Üretmede mi? Meta veri tasarımının en kritik ve en az affedilen kısmı yetki ve gizlilik alanlarıdır. Buradaki tek bir tasarım hatası, teknik bir aksaklık değil, doğrudan bir veri sızıntısı ve KVKK ihlali anlamına gelir. Bu bölümdeki çerçeve tanımsal ve bilgilendirme amaçlıdır; hukuki tavsiye değildir ve kurumunuzun hukuk, uyum ve güvenlik birimleriyle birlikte uygulanmalıdır. En temel ilke şudur: izin kontrolü üretme adımında değil, getirme adımında yapılır. Yaygın ama tehlikeli bir yanılgı, tüm belgeleri tek havuza koyup "modele söyleriz, yetkisiz bilgiyi göstermez" demektir. Bu güvenilmezdir; çünkü model bir güvenlik sınırı değildir ve prompt injection gibi saldırılarla kandırılabilir. Doğru tasarımda her parçaya bir yetki alanı meta verisi yazılır — örneğin departman, gizlilik sınıfı, izinli rol listesi veya erişim kontrol listesi kimliği. Sorgu geldiğinde sistem, kullanıcının kimliğinden yetkilerini çözer ve vektör aramasını yalnızca bu yetkilere uyan parçalar üzerinde çalıştırır. Böylece model, kullanıcının görmeye yetkili olmadığı bir parçayı hiçbir zaman bağlam olarak almaz; yetkisiz belge, aramaya bile girmez. Yetki alanı modellemesinde birkaç yaklaşım vardır ve doğru seçim kurumun erişim modeline bağlıdır. Rol tabanlı yaklaşımda her parça, ona erişebilecek rollerle etiketlenir; kullanıcının rolü filtreyi belirler. Öznitelik tabanlı yaklaşımda erişim; departman, proje, ülke, gizlilik seviyesi gibi özniteliklerin bir kombinasyonuyla belirlenir ve daha ince ayar sağlar. En sık hata, yetki alanını statik ve kaba tanımlamaktır; oysa gerçek kurumlarda erişim, kişinin rolüne, projesine ve zamanına göre değişir. Yetki filtresi bu dinamikliği yansıtmalı, kaynak sistemdeki izinlerle senkron kalmalıdır — bir belgenin erişimi kaynakta değiştiğinde, RAG indeksindeki yetki alanı da güncellenmelidir. Gizlilik alanları, yetkiyle yakından ilişkili ama ayrı bir konudur. Bir parçanın kişisel veri içerip içermediği, hangi gizlilik sınıfına ait olduğu ve hangi işlemlere tabi olduğu (maskeleme, saklama süresi, silme) meta veri olarak taşınmalıdır. Kişisel veri içeren parçalarda, getirme öncesi maskeleme veya erişimin daha da daraltılması gerekebilir. Kişisel verinin ne olduğunu kişisel veri nedir, maskeleme yöntemlerini veri anonimleştirme nedir yazılarında ele alıyoruz. KVKK çerçevesi için KVKK nedir ve uyumlu bir mimari kurmak için KVKK uyumlu yapay zeka nedir temel oluşturur. Ayrıca model çıktısını sınırlayan koruyucu katmanlar için guardrail nedir ve saldırı yüzeyini anlamak için prompt injection nedir yazıları, yetki tasarımını tamamlar. RAG güvenliğinde en pahalı hata, sistemi önce herkese açık kurup yetki alanını sonradan eklemeye çalışmaktır. Bir belge yetki meta verisi olmadan indekslenmişse, geriye dönük "bunu kim görebilir" bilgisini üretmek hem zor hem risklidir; çünkü kaynak sistemdeki izinler o an ne olduğu değil, indeksleme anındaki hâliyle yeniden kurgulanmalıdır. Güvenli meta veri tasarımı, yetki ve gizlilik alanlarını ilk günden, belge sisteme alınırken planlar. ## Tarih, Sürüm ve Geçerlilik Alanları Nasıl Yönetilir? Kurumsal bilginin en sinsi düşmanı eskimedir. Bir prosedür güncellenir ama eski sürümü bilgi tabanında kalır; bir fiyat listesi değişir ama önceki de indekste durur. Salt anlamsal arama bu iki sürümü ayırt edemez ve model, güncel olan yerine eski olana dayanarak yanlış ama kendinden emin bir cevap üretebilir. Tarih ve sürüm alanı, meta veri tasarımının bu soruna verdiği yanıttır: sisteme "hangi bilginin daha yeni ve hangisinin yürürlükte olduğunu" öğretir. Tarih alanı en az iki değeri taşımalıdır: içeriğin oluşturulma tarihi ve son güncelleme tarihi. Bazı senaryolarda üçüncü bir değer daha kritiktir: geçerlilik penceresi — bilginin ne zamandan ne zamana kadar yürürlükte olduğu. Örneğin bir kampanya koşulu yalnızca belirli tarihler arasında geçerliyse, geçerlilik penceresi bu belgeyi süresi dışında otomatik eler. Sürüm alanı ise aynı belgenin ardışık revizyonlarını ayırt eder ve "en güncel sürüm" filtresini mümkün kılar; böylece sistem, bir belgenin yalnızca yürürlükteki sürümünü getirir, eskilerini arşiv olarak işaretler. Tarih ve sürüm alanı iki farklı mekanizmayla kaliteyi artırır. Birincisi filtreleme: geçerliliği geçmiş veya arşiv işaretli parçalar aramadan çıkarılır; bu, yanlış sürüm riskini kökten azaltır. İkincisi sıralama ipucu: iki parça benzer ölçüde ilgiliyse, sistem daha yeni olanı tercih edecek şekilde ayarlanabilir (güncellik önceliği). Bu ikinci mekanizma, geçerlilik penceresinin net olmadığı, "genellikle en yeni doğrudur" senaryolarında değerlidir. Güncelliğin RAG kalitesindeki rolünü daha geniş bir çerçevede veri kalitesi nedir yazısında ele alıyoruz. Pratikte tarih ve sürüm alanı, kaynak sistemin üst verisinden gelir; ama bu üst verinin güvenilirliği kritiktir. Bir belge sisteme kopyalanırken tarihi kaybolur veya kopyalama tarihi gerçek güncelleme tarihinin yerini alırsa, alan yanıltıcı olur. Bu yüzden tarih alanının kaynağı ve doğruluğu, meta veri tasarımının doğrulama katmanında özellikle denetlenmelidir. Eski sürümleri silmek yerine arşiv olarak işaretleyip aramadan çıkarmak genellikle daha güvenlidir; çünkü tarihsel sorular için eski sürüme hâlâ ihtiyaç olabilir, ama varsayılan aramada görünmemelidir. ## Filtreleme ve Anlamsal Aramayı Nasıl Birleştiririz? (Hibrit Filtre + Vektör) Meta veri tasarımının teknik kalbi, filtreleme ile anlamsal aramanın nasıl birleştiğidir. İki yaygın sıralama vardır ve aralarındaki fark hem doğruluğu hem performansı etkiler. Ön-filtreleme (pre-filtering) yaklaşımında sistem önce meta veri filtresini uygular — yetki alanı, dil, geçerlilik, belge türü — ve arama uzayını uygun parçalara daraltır; sonra bu daraltılmış küme içinde vektör benzerliğiyle sıralama yapar. Son-filtreleme (post-filtering) yaklaşımında ise önce geniş bir vektör araması yapılır, sonra sonuçlar meta veriyle elenir. Bu iki yaklaşımın önemli sonuçları vardır. Ön-filtreleme, yetki ve geçerlilik gibi kritik filtrelerde doğru olandır: yetkisiz veya süresi geçmiş bir parça, aramaya hiç girmemelidir; onu önce eleyip sonra benzerlik hesaplamak hem güvenli hem doğrudur. Son-filtreleme ise bir tuzak taşır: eğer geniş vektör araması zaten yalnızca birkaç yüz aday getiriyorsa ve bunların çoğu filtreye takılıyorsa, geriye çok az — hatta sıfır — sonuç kalabilir ("boş sonuç" sorunu). Bu yüzden kritik filtreler ön-filtreleme ile, düşük riskli daraltmalar ise duruma göre uygulanır. Modern vektör veritabanları meta veri filtrelemeyi doğrudan destekler; bunun mekaniğini vektör aramada meta veri filtreleme yazısında ele alıyoruz. Filtreleme RAG kalitesini yalnızca doğru parçayı bularak değil, yanlış parçayı eleyerek de artırır; ama aşırıya kaçarsa doğru parçayı da eleyebilir. Çok katı bir filtre — örneğin sorunun ima ettiğinden daha dar bir tarih penceresi — doğru cevabı içeren parçayı dışarıda bırakır ve sistem "bilgi bulunamadı" der. Bu yüzden filtre tasarımı ölçülerek ayarlanır: hangi filtrenin isabeti artırdığı, hangisinin kapsamı düşürdüğü bir değerlendirme kümesiyle test edilmelidir. Anlamsal ve anahtar kelime aramasını birleştiren hibrit yaklaşımla meta veri filtresi bir araya geldiğinde en güçlü sonuç elde edilir; bu bileşimi hibrit arama RAG ve uygulama ayrıntısını hibrit arama, meta veri filtreleme ve sorgu yeniden yazma rehberi yazısında derinleştiriyoruz. Sağlam bir zihinsel model şudur: meta veri filtresi "hangi parçalar bu kullanıcı ve bu bağlam için uygun" sorusunu yanıtlar; anlamsal benzerlik ise "uygun olanlar arasında hangisi soruya en yakın" sorusunu. Bu sıra önemlidir. Önce güvenlik ve geçerlilik filtresiyle uygun kümeyi belirleyin, sonra o küme içinde benzerlikle sıralayın. Bu iki adımı karıştırmak, hem güvenlik açığı hem kalite kaybı üretir. ## Otomatik Çıkarım ve Doğrulama: Meta Veri Nereden Gelir? Meta veri alanlarını tanımlamak bir şey, onları güvenilir biçimde doldurmak başka bir şeydir. Her parça için tarih, sürüm, bölüm, dil, etiket ve yetki değerlerini elle girmek büyük ölçekte imkânsızdır; bu yüzden meta verinin çoğu otomatik çıkarımla üretilir. Ama otomatik çıkarıma kör güven, meta veri tasarımının en tehlikeli hatalarından biridir. Doğru yaklaşım, alanın kritikliğine göre değişen bir güven modeli kurmaktır. Otomatik çıkarım birkaç kaynaktan gelir. Bir kısmı kaynak sistemin üst verisinden doğrudan aktarılır (oluşturma tarihi, yazar, klasör, izinler); bu genellikle en güvenilir kaynaktır, çünkü insan sürecinin ürünüdür. Bir kısmı belgenin yapısından çıkarılır: başlık hiyerarşisi bölüm alanını, belge ayrıştırma (document parsing) tablo ve düzen bilgisini verir. Belge ayrıştırmanın zorluklarını document parsing yazısında ele alıyoruz. Bir kısmı ise içerikten model veya kuralla çıkarılır: dil tespiti, tarih ayrıştırma, konu/varlık etiketleme. İçerikten çıkarım en esnek ama en hataya açık olandır. Kritik ayrım şudur: düşük riskli alanlarda otomatik değer doğrudan kullanılabilir, kritik alanlarda ise bir doğrulama katmanı şarttır. Yanlış tespit edilen bir dil, en fazla küçük bir isabet kaybı yaratır — düşük risk. Ama yanlış çıkarılan bir yetki alanı gizli bir belgeyi herkese açabilir, yanlış ayrıştırılan bir tarih eski bir belgeyi güncel gösterebilir — yüksek risk. Bu yüzden yetki ve geçerlilik gibi kritik alanlarda otomatik çıkarımın üzerine üç katman konur: kural tabanlı doğrulama (değer beklenen sözlüğe ve aralığa uyuyor mu), güven skoru (çıkarım ne kadar emin) ve düşük güvende insan onayı. Bu, otomatik çıkarımın hızıyla insan denetiminin güvenilirliğini dengeler. Bu boru hattı, meta veri kalitesini bir kez kurulup unutulan değil, ölçülüp iyileştirilen bir süreç haline getirir. Otomatik çıkarımın doğruluğunu düzenli örnekleme ile denetlemek — örneğin her ay belirli sayıda parçanın meta verisini elle kontrol etmek — kalitenin sessizce bozulmasını önler. Türkçe içerikte otomatik çıkarımın ek zorlukları vardır: dil tespiti kısa metinlerde yanılabilir, tarih formatları çeşitlidir, varlık etiketleme Türkçe morfolojiye duyarlı olmalıdır. Bu yüzden Türkçe ağırlıklı bir bilgi tabanında çıkarım kurallarını Türkçeye göre ayarlamak ve bir Türkçe test kümesiyle doğrulamak gerekir; embedding tarafındaki benzer nüansları Türkçe için embedding modeli seçimi yazısında ele alıyoruz. ## Çok Kiracılı (Multi-Tenant) RAG'de Erişim İzolasyonu Kurumsal RAG'in ileri bir senaryosu, tek bir sistemin birden çok kiracıya — farklı müşterilere, iş birimlerine veya yan kuruluşlara — hizmet vermesidir. Burada meta veri tasarımı, yalnızca kalite değil, sıkı bir izolasyon meselesidir: bir kiracının verisi hiçbir koşulda başka bir kiracının aramasında görünmemelidir. Bu, yetki alanı tasarımının en katı biçimidir ve tek bir sızıntı bile güven sözleşmesini bozar. Çok kiracılı izolasyon iki temel mimariyle kurulabilir. Fiziksel izolasyonda her kiracının verisi ayrı bir indekste veya koleksiyonda (namespace) tutulur; sorgu, kiracının kimliğine göre yalnızca kendi indeksine yönlenir. Bu yaklaşım en güçlü izolasyonu sunar ama yönetim ve maliyet yükü getirir. Mantıksal izolasyonda ise tüm kiracılar aynı indekste yaşar, ama her parça bir kiracı (tenant) meta verisi taşır ve her sorguya zorunlu bir kiracı filtresi eklenir. Bu esnek ve ekonomiktir ama filtrenin asla atlanmaması, bir yazılım güvencesi haline getirilmelidir. Namespace tabanlı izolasyonun ayrıntısını namespace isolation yazısında bulabilirsiniz. Mantıksal izolasyonda kritik risk, kiracı filtresinin bir kod yolunda unutulmasıdır. Bu yüzden doğru tasarım, kiracı filtresini isteğe bağlı bir parametre değil, sorgu katmanının zorunlu bir ön koşulu yapar: kiracı bağlamı olmadan hiçbir arama çalışmaz. Ayrıca kiracı filtresi ön-filtreleme ile uygulanmalı — asla son-filtreleme ile değil — ki başka kiracının parçası aramaya hiç girmesin. İş yükü ve kaynak izolasyonu için workload isolation desenleri, performans ve güvenlik sınırlarını birlikte düşünmeye yardımcı olur. Çok kiracılı bir RAG'de yetki alanı, kiracı kimliğini de içeren bileşik bir yapıya dönüşür: önce kiracı, sonra kiracı içi rol ve gizlilik. Çok kiracılı RAG'de en tehlikeli hata, kiracı filtresini uygulama mantığına bırakmaktır — "geliştirici her sorguya eklemeyi unutmaz" varsayımı. Unutur. Doğru tasarım, kiracı filtresini sorgu katmanının değiştirilemez bir parçası yapar; kiracı bağlamı çözülemezse sorgu reddedilir, boş küme değil hata döner. İzolasyon, iyi niyete değil, mimari zorunluluğa dayanmalıdır. ## Meta Veri Kalitesi Nasıl Ölçülür? Meta veri tasarımının kalitesi, ölçülmediği sürece yönetilemez. "İyi görünüyor" hissi, üretimde sessizce biriken meta veri hatalarını gizler: boş kalan alanlar, tutarsız değerler, yanlış atanan yetkiler. Meta veri kalitesini ölçmek için birkaç somut boyut ve gösterge kullanılabilir; bunlar, filtrenin gerçekten işe yarayıp yaramadığını kanıta bağlar. İlk boyut eksiksizliktir (completeness): zorunlu alanların ne kadarı dolu? Yetki alanı boş olan bir parça, filtreye takılamaz ve ya sızar ya da hiç getirilemez; bu yüzden kritik alanların doluluk oranı yakından izlenmelidir. İkinci boyut geçerliliktir (validity): alan değerleri beklenen sözlüğe ve aralığa uyuyor mu? "belge türü" alanında sözlük dışı bir değer, çıkarım veya etiketleme hatasına işaret eder. Üçüncü boyut tutarlılıktır (consistency): aynı belgenin parçaları çelişkili meta veri taşıyor mu, aynı kavram farklı etiketlerle mi geçiyor? Dördüncü boyut doğruluktur (accuracy): meta veri değeri gerçeği yansıtıyor mu — örneklem denetimiyle ölçülür. Meta veri kalitesine odaklanan bir skor kavramını meta veri filtreleme ve genel veri kalitesi çerçevesini veri kalitesi nedir yazılarında ele alıyoruz. Bu boyutları RAG'in genel değerlendirmesine bağlamak gerekir; çünkü meta veri kalitesi bir amaç değil, araçtır — amaç, getirme isabetidir. Bir değerlendirme kümesinde, filtre açıkken ve kapalıyken isabet ve gürültüyü karşılaştırmak, meta verinin gerçekten değer üretip üretmediğini gösterir. Örneğin yetki filtresi açıkken hiçbir yetkisiz parça gelmemeli; geçerlilik filtresi açıkken eski sürüm getirilmemeli. Bu tür hedefli testler, meta veri tasarımının etkisini soyut bir iddia olmaktan çıkarıp ölçülebilir bir sonuca dönüştürür. RAG değerlendirmesinin bütününü, kardeş yazımız RAG değerlendirme yöntemi ve metrik tarafını RAG değerlendirme metrikleri yazısında derinleştiriyoruz. ## Şema Değişikliği ve Sürüm Yönetimi Nasıl Yapılır? Meta veri şeması, bir kez tasarlanıp donan bir yapı değildir; iş ihtiyaçları değiştikçe yeni alanlar eklenir, değer sözlükleri güncellenir, bazı alanların anlamı incelir. Bu değişiklikler yönetilmezse, meta veri katmanı zamanla bir tutarsızlık yığınına dönüşür. Bu yüzden meta veri şemasını yaşayan bir sözleşme gibi düşünmek gerekir: değişiklikler planlı, sürümlü ve geriye dönük etkileri hesaplanmış olmalıdır. En sık üç değişiklik türü ve her birinin getirdiği yük şudur. Yeni alan ekleme en yaygın ve en zararsız görünen değişikliktir; ama eski parçalarda bu alan boştur, dolayısıyla o alanla filtreleme eski içeriği eler. Çözüm, geriye dönük doldurma (backfill): eski parçaların yeni alanını otomatik çıkarım veya kuralla üretmek. Alan anlamını değiştirme en tehlikeli olandır; aynı alan adı eski ve yeni parçalarda farklı şey ifade ederse filtre sessizce yanlış çalışır. Bu durumda şema bir sürümle işaretlenmeli, mümkünse yeni bir alan açılmalıdır. Değer sözlüğünü güncelleme ise etiketlerin yeniden eşlenmesini (kanonikleştirme) gerektirir; eski değerler yeni sözlüğe haritalanmalıdır. Bu değişikliklerin sessiz bir riski şema kaymasıdır (schema drift): kaynak sistem veya çıkarım süreci, beklenmeyen değerler veya yapılar üretmeye başlar ve filtre farkında olmadan bozulur. Örneğin bir kaynak sistem tarih formatını değiştirir ve ayrıştırma sessizce başarısız olur. Şema kaymasını erken yakalamak için, meta veri değerlerini beklenen şemaya karşı sürekli izlemek gerekir; bu izlemenin mantığını schema drift yazısında ele alıyoruz. Meta veri sürümlemesi, bu değişikliklerin izlenebilir ve geri alınabilir olmasını sağlar; hangi parçanın hangi şema sürümüyle indekslendiğini bilmek, sorun ayıklamayı çok kolaylaştırır. ## Pratik Bir Meta Veri Tasarım Şablonu Şimdiye kadar ele aldığımız ilkeleri somut bir şablona indirelim. Aşağıdaki adımlar, sıfırdan bir meta veri tasarımı yaparken izlenebilecek pratik bir sıradır. Amaç, kusursuz bir şema kurmak değil; ölçülüp iyileştirilebilen sağlam bir başlangıç kurmaktır. Meta veri tasarımı, tıpkı chunking gibi, bir kez kurulup unutulan değil, kalite ölçüldükçe olgunlaşan bir parametredir. Bu şablonu uygularken sık düşülen tuzaklardan kaçınmak, başarının yarısıdır. En yaygın hata, meta veriyi sonradan eklenecek bir "iyileştirme" sanmaktır; oysa yetki alanı ve geçerlilik gibi alanlar, belge indekslenirken konmazsa geriye dönük eklemek hem zor hem risklidir. İkinci hata, filtre olarak kullanılmayacak alanları toplamaktır — bu, kaliteyi artırmaz, yalnızca bakım yükü ve tutarsızlık üretir. Üçüncü hata, otomatik çıkarıma kritik alanlarda kör güvenmektir. Dördüncü hata, şemayı donmuş sanıp değişiklik yönetimi kurmamaktır. Bu tuzakların ortak dersi şudur: meta veri tasarımı bir kerelik bir kurulum değil, RAG'in yaşayan bir katmanıdır. ## Meta Veri Tasarımının Performans ve Maliyet Etkisi Meta veri tasarımı yalnızca doğruluk değil, performans ve maliyet meselesidir de. İyi tasarlanmış bir filtre katmanı, arama uzayını daralttığı için vektör aramasını hızlandırabilir ve gereksiz parçaları modele taşımadığı için token maliyetini düşürebilir. Ama kötü tasarlanmış bir meta veri katmanı, tam tersine, gecikme ve maliyet yükü üretir. Bu dengeyi anlamak, meta veri tasarımını mühendislik bir karar haline getirir. Performans tarafında en önemli mekanizma, filtrelerin indekste nasıl desteklendiğidir. Bir meta veri alanı üzerinde sık filtreleme yapılacaksa, o alanın indekslenmesi aramayı hızlandırır; indekssiz bir alan üzerinde filtreleme ise tüm kümeyi taramaya zorlayarak yavaşlatır. Yüksek kardinaliteli alanlar (çok sayıda benzersiz değer) ile düşük kardinaliteli alanlar (birkaç değer) farklı davranır; filtre tasarımı bunu hesaba katmalıdır. Ön-filtreleme genellikle son-filtrelemeden hem daha güvenli hem daha verimlidir, çünkü benzerlik hesabını yalnızca uygun parçalar üzerinde yapar. Vektör veritabanı seçiminin bu davranışa etkisini vektör veritabanı nedir yazısında ele alıyoruz. Maliyet tarafında meta verinin iki etkisi vardır. Olumlu etki: iyi bir filtre, modele gereksiz parça göndermeyi önleyerek token maliyetini düşürür; her elenen alakasız parça, tasarruf edilen token demektir. Olumsuz etki: meta veri üretimi (özellikle model tabanlı çıkarım) ve saklaması bir maliyet taşır; her parçaya onlarca alan eklemek indeks boyutunu ve işlem yükünü artırır. Doğru denge, filtre değeri üretmeyen alanları eklememek ve çıkarımı alanın kritikliğine göre ölçeklemektir. Kısacası meta veri tasarımı, doğruluk-performans-maliyet üçgeninde bilinçli bir denge kurar; bu üçgenin RAG genelindeki mantığını kurumsal RAG rehberi yazısında bütünsel olarak ele alıyoruz. ## Meta Veri Tasarımı ile Sorgu Tarafını Birleştirmek Şimdiye kadar meta verinin belge tarafını — parçalara hangi alanların ekleneceğini — konuştuk. Ama filtreleme bir çift taraflı iştir: filtrenin işe yaraması için sorgunun da doğru filtre değerlerini üretmesi gerekir. Kullanıcı "geçen yılın İK politikası ne diyordu" diye sorduğunda, sistem bu sorudan bir tarih filtresi ve bir departman filtresi çıkarabilmelidir. Meta veri tasarımı, bu sorgu tarafı çıkarımı düşünülmeden eksik kalır. Sorgu tarafı filtre çıkarımı birkaç biçimde çalışır. Bir kısmı bağlamdan gelir: kullanıcının kimliği yetki alanını, oturum bağlamı dili ve departmanı belirleyebilir; bu filtreler soruya bakılmadan otomatik uygulanır. Bir kısmı sorudan çıkarılır: "2024'te", "hukuk departmanı", "X ürünü" gibi ifadeler, ilgili meta veri alanlarına eşlenir. Bu çıkarım, sorgu yeniden yazma (query rewriting) katmanının bir parçasıdır ve hibrit arama ile birlikte RAG kalitesini belirgin artırır; ayrıntısını hibrit arama ve sorgu yeniden yazma rehberi yazısında ele alıyoruz. Sorgu tarafı çıkarımın bir dengesi vardır. Fazla agresif filtre çıkarımı — kullanıcının kastetmediği bir daralmayı zorlamak — doğru parçayı eleyebilir ve boş sonuç üretir. Fazla temkinli çıkarım ise filtrenin değerini kullanamaz. Doğru yaklaşım, güvenli filtreleri (yetki, kiracı, dil) her zaman uygulamak; niyet bağımlı filtreleri (tarih, ürün) ise güvenle çıkarılabildiğinde ve gerektiğinde uygulamaktır. Bir başka sağlam desen, katı filtre boş sonuç verdiğinde filtreyi kademeli gevşetmektir: önce geçerlilik penceresini genişlet, sonra tarih filtresini kaldır, ama yetki filtresini asla gevşetme. Böylece sistem, güvenlikten ödün vermeden kapsamı korur. Bu ince ayarlar, meta veri tasarımının yalnızca bir şema değil, bir davranış tasarımı olduğunu gösterir. Fonksiyon çağırma ile sorgudan yapılandırılmış filtre üretmenin mekaniğini function calling nedir yazısında bulabilirsiniz. Boş sonuç sorununu yönetmenin altın kuralı: filtreleri iki sınıfa ayırın. Güvenlik filtreleri (yetki alanı, kiracı, gizlilik) hiçbir koşulda gevşetilmez — çünkü gevşetmek sızıntıdır. Niyet filtreleri (tarih, ürün, belge türü) ise sonuç boşsa kademeli gevşetilebilir. Bu ayrım, hem güvenliği korur hem kullanıcının cevapsız kalmasını önler. ## Küçük Bir Vaka: Yetki ve Sürümün Aynı Anda Devrede Olduğu Bir Sorgu İlkeleri somutlaştırmak için tek bir sorgunun meta veri katmanından nasıl geçtiğini izleyelim. Bir satış müdürü kurumsal RAG asistanına şunu soruyor: "Kurumsal müşterilerde geçerli güncel iskonto politikası nedir?" Bu soru, arka planda birden fazla meta veri alanını aynı anda devreye sokar ve iyi bir meta veri tasarımının değerini net gösterir. Önce güvenlik ve bağlam filtreleri uygulanır. Sistem, kullanıcının kimliğinden yetki alanını çözer: satış müdürü, satış ve fiyatlandırma belgelerine erişebilir ama İK veya hukuk gizli belgelerine erişemez. Bu yetki filtresi, aramaya girmeden önce, ön-filtreleme ile uygulanır; yetkisiz belgeler arama uzayına hiç girmez. Aynı anda dil filtresi (Türkçe) ve kiracı filtresi (varsa müdürün iş birimi) devreye girer. Böylece arama uzayı, güvenli ve uygun bir alt kümeye daralır. Sonra niyet filtreleri çıkarılır. "Güncel" kelimesi bir geçerlilik filtresine eşlenir: sistem yalnızca yürürlükteki sürümü getirir, arşiv işaretli eski iskonto politikalarını eler — işte tarih ve sürüm alanı burada devreye girer. "Kurumsal müşteriler" ifadesi bir müşteri segmenti etiketine eşlenir ve doküman etiketleme sayesinde yalnızca bu segmentle ilgili parçalar öne çıkar. Bu daraltılmış ve güvenli küme içinde, sistem anlamsal benzerlikle en ilgili parçaları sıralar ve reranker en iyilerini seçer. Son adımda model, yalnızca bu güvenli, güncel ve segmentle ilgili parçalara dayanarak cevabı yazar ve kaynağı — belge, bölüm, sürüm ve tarih — gösterir. Dikkat edin: bu sorguda modelin "zekâsı" tek başına belirleyici değildir; belirleyici olan, meta veri tasarımının doğru parçayı doğru kullanıcıya, doğru sürümden getirmesidir. Meta verisiz bir sistemde aynı soru, eski bir iskonto politikasından veya yetkisiz bir belgeden yanlış cevap üretebilirdi. Filtreleme RAG'i tam olarak bu noktada güvenilir kılar; ve bu güvenilirlik, tek tek yetki alanı, tarih ve sürüm alanı ve doküman etiketleme kararlarının toplamıdır. ## Belge Türüne Göre Meta Veri Nasıl Farklılaşır? Tek bir zorunlu alan seti iyi bir başlangıçtır; ama olgun bir meta veri tasarımı, belge türüne göre alanları farklılaştırır. Çünkü bir sözleşmenin, bir teknik dokümantasyonun, bir SSS sayfasının ve bir mevzuat metninin RAG'de nasıl bulunması gerektiği birbirinden farklıdır. Aynı şablonu her türe zorlamak, bazı türlerde gereksiz boş alanlar, bazılarında ise eksik bağlam üretir. Bu yüzden zorunlu alan setinin üstüne, türe özgü alanlar eklemek isabeti belirgin biçimde artırır. Bir sözleşme türünde taraflar, imza tarihi, yürürlük ve bitiş tarihi, sözleşme türü ve gizlilik seviyesi kritik meta veri alanlarıdır; kullanıcı "X firmasıyla olan gizlilik sözleşmesi ne zaman bitiyor" diye sorduğunda, sistem bu soruyu ancak taraf ve tarih alanlarıyla doğru daraltabilir. Bir teknik dokümantasyonda ise ürün, sürüm, bileşen ve API adı gibi alanlar öne çıkar; burada tarih ve sürüm alanı özellikle önemlidir, çünkü yazılım sürümleri arasında davranış değişir ve eski sürümün belgesi yeni sürüm için yanıltıcıdır. Bir SSS veya destek içeriğinde soru-cevap yapısı, kategori ve çözüm durumu; bir mevzuat metninde madde numarası, yürürlük tarihi ve ilgili düzenleme meta veri olarak taşınmalıdır. Bu farklılaşma, doküman etiketleme disiplininin neden türe duyarlı olması gerektiğini de açıklar. Her türün kendi kontrollü sözlüğü ve kendi zorunlu alanları olabilir; bir belge sisteme alınırken önce türü belirlenir, sonra o türe ait şema uygulanır. Pratik bir yaklaşım, ortak bir çekirdek alan seti (kaynak, tarih, dil, yetki alanı) üzerine türe özgü alanları bir uzantı gibi eklemektir. Böylece hem tutarlılık hem esneklik korunur. Belge türünü otomatik belirleme, meta veri çıkarımının ilk adımlarından biridir ve sonraki tüm şema kararlarını etkiler; bu yüzden tür tespiti, güvenilir olması gereken kritik alanlardandır. Türe göre farklılaşan bir meta veri tasarımı, tek tip bir şemaya kıyasla hem daha az boş alan hem daha yüksek filtre isabeti üretir; ve bu, kurumsal bir bilgi tabanında farklı içerik türlerinin bir arada yaşadığı gerçek dünya senaryolarında fark yaratır. ## Parça Düzeyi mi, Belge Düzeyi mi Meta Veri Tutulur? Meta veri tasarımında sık sorulan teknik bir soru, alanların belge düzeyinde mi yoksa parça (chunk) düzeyinde mi tutulacağıdır. Cevap "ikisi de, ama farklı biçimde"dir ve bu ayrımı anlamak, hem filtre performansını hem tutarlılığı belirler. Bazı alanlar doğası gereği belgeye aittir (yetki alanı, belge türü, sahiplik, sürüm); bir belgenin tüm parçaları bu alanları paylaşır. Bazı alanlar ise parçaya özgüdür (bölüm/başlık, parçadaki tablo bilgisi, parça sırası); aynı belgenin farklı parçaları farklı değerler taşır. Pratikte filtreleme parça düzeyinde çalıştığı için, belge düzeyi alanlar da her parçaya kopyalanır (denormalizasyon). Yani bir sözleşmenin yetki alanı, o sözleşmeden çıkan yüzlerce parçanın her birine yazılır; böylece vektör araması sırasında filtre, ayrı bir belge tablosuna bakmadan, doğrudan parça meta verisi üzerinden hızlıca çalışır. Bu, arama hızını artırır ama bir maliyet getirir: belge düzeyi bir alan değişince (örneğin belgenin erişimi kısıtlanınca), o belgeden türeyen tüm parçaların meta verisi güncellenmelidir. Bu güncelleme atlanırsa, parçalar eski yetkiyle kalır ve sızıntı riski doğar. Bu yüzden meta veri tasarımı, denormalizasyonun getirdiği tutarlılık sorumluluğunu baştan planlamalıdır. Belge ve parça arasındaki bağ (parçanın hangi belgeden geldiği) net tutulmalı; belge düzeyi bir alan değiştiğinde, ona bağlı tüm parçaları bulup güncelleyen bir mekanizma kurulmalıdır. Bir başka tasarım deseni, değişmesi olası kritik alanları (özellikle yetki) parçaya kopyalamak yerine, sorgu anında belge kimliğinden dinamik çözmektir; bu, tutarlılığı garanti eder ama sorgu karmaşıklığını artırır. Doğru seçim, alanın değişim sıklığına ve kritikliğine bağlıdır: nadiren değişen alanlar güvenle kopyalanır, sık değişen ve kritik alanlar için dinamik çözüm veya sıkı senkronizasyon gerekir. Bu incelik, meta veri tasarımını basit bir "alan ekleme" işinden, bir veri tutarlılığı mühendisliğine dönüştürür. ## Meta Veri, Kaynak Gösterme ve Doğrulanabilirlik RAG'in kurumsal değerinin büyük kısmı, ürettiği cevabı bir kaynağa bağlayabilmesinden gelir; ve bu kaynak gösterme yeteneği, doğrudan meta veri tasarımına dayanır. Bir parça hangi belgeden, hangi bölümden, hangi sürümden ve hangi tarihten geldiğini taşımıyorsa, model cevabı üretse bile onu güvenilir bir atıfla sunamaz. Kullanıcı "bu bilgi nereden geliyor" diye sorduğunda, cevabın arkasındaki belgeyi, bölümü ve tarihi gösterebilmek, güvenin temelidir. Meta verisiz bir RAG, akıcı ama doğrulanamaz cevaplar üretir; ve doğrulanamayan bir cevap, kurumsal bir bağlamda risklidir. Kaynak gösterme için gereken meta veri alanları, filtreleme için gerekenlerle büyük ölçüde örtüşür ama bazı ek alanlar da ister. Belge kimliği ve bölüm, kullanıcının kaynağa tıklayıp doğrulayabilmesi için gereklidir; tarih ve sürüm, kullanıcının bilginin ne kadar güncel olduğunu değerlendirmesini sağlar; sayfa veya konum bilgisi, uzun belgelerde tam yeri işaret eder. İyi bir meta veri tasarımı, bu alanları kaynak gösterme deneyimini düşünerek planlar: kullanıcı yalnızca "bir belgeye" değil, "belgenin doğru bölümüne, doğru sürümüne" yönlendirilmelidir. Doğrulanabilirlik, kaynak göstermenin ötesinde bir yönetişim boyutu da taşır. Bir cevabın hangi parçalara dayandığını ve o parçaların hangi meta veriye sahip olduğunu kaydetmek, sonradan bir denetim veya sorun ayıklama gerektiğinde kritiktir: yanlış bir cevap çıktığında, sorunun yanlış parçadan mı, eski sürümden mi, yoksa modelin yanlış yorumundan mı kaynaklandığını meta veri izi sayesinde ayırt edebilirsiniz. Bu iz, RAG değerlendirmesinin ve sürekli iyileştirmenin de temelidir; kaynak parçaların meta verisini kayıt altına almak, kaliteyi kanıta bağlamanın ilk adımıdır. Kaynak gösterme ve dayanaklılığın RAG kalitesindeki rolünü RAG değerlendirme yöntemi yazısında daha geniş ele alıyoruz. ## Meta Veri Tazeliği ve Kaynakla Senkronizasyon Nasıl Sağlanır? Meta veri, bir kez üretilip donan bir değer değildir; kaynak sistemdeki belge değiştikçe, silindikçe veya erişimi güncellendikçe, RAG indeksindeki meta verinin de bunu yansıtması gerekir. Bu tazelik ve senkronizasyon, meta veri tasarımının en çok ihmal edilen ama üretimde en çok soruna yol açan boyutudur. Kaynak ile indeks arasındaki her tutarsızlık, ya eski bilgiyle ya yanlış yetkiyle bir cevap üretme riski taşır. Senkronizasyonun en kritik biçimi erişim değişiklikleridir. Kaynak sistemde bir belgenin erişimi kısıtlandığında (örneğin gizli sınıfına alındığında), bu değişikliğin RAG indeksindeki yetki alanına gecikmeden yansıması gerekir; aksi halde artık yetkisiz olması gereken bir parça, eski yetkisiyle aramada görünmeye devam eder. Bu yüzden erişim değişiklikleri, mümkünse gerçek zamanlı veya çok kısa gecikmeli senkronize edilmelidir. İçerik değişiklikleri biraz daha toleranslıdır ama yine de bir tazelik hedefi (belge güncellenince en geç ne kadar sürede indekse yansıyacağı) tanımlanmalıdır. Silme işlemleri özel dikkat ister: kaynakta silinen bir belge indeksten de çıkarılmalıdır; aksi halde artık var olmayan bir belgeden cevap üretilir. Silinen belgeler için genellikle bir "mezar taşı" (tombstone) işareti kullanılır, böylece silme işlemi izlenebilir kalır. Senkronizasyon iki temel yaklaşımla kurulur. Toplu (batch) yenilemede indeks periyodik olarak yeniden kurulur veya değişenler taranır; basit ama gecikmelidir. Olay tabanlı (event-driven) yenilemede ise kaynak sistemdeki her değişiklik bir olay üretir ve indeks anında güncellenir; daha karmaşık ama daha tazedir. Kritik alanlar (yetki, geçerlilik) için olay tabanlı, düşük riskli alanlar için toplu yaklaşım pratik bir dengedir. Güncelliğin RAG kalitesindeki genel rolünü veri kalitesi nedir yazısında ele alıyoruz. Meta veri tazeliği, tıpkı yetki alanı gibi, sonradan eklenen bir özellik değil, en baştan tasarlanması gereken bir yaşam döngüsü sorumluluğudur; bir belgenin sisteme nasıl gireceğini planlarken, nasıl güncelleneceğini ve nasıl çıkacağını da planlamak gerekir. ## Meta Veri Tasarımını Küçük Bir Pilotla Denemek Meta veri tasarımını teoride anlamak bir şey, onu bir kurumsal RAG'de sağlam biçimde hayata geçirmek başka bir şeydir. En sık hata, en baştan "tüm belge türleri için kusursuz bir şema" kurmaya çalışmaktır; böyle bir çaba, kapsamın genişliği altında ezilir ve değer üretmeden tükenir. Doğru yaklaşım, tıpkı RAG'in kendisinde olduğu gibi, dar ve ölçülebilir bir pilotla başlamaktır. Küçük bir kapsamda meta veri tasarımının etkisini kanıtlamak, geniş bir vaatten her zaman daha inandırıcıdır. İyi bir meta veri pilotu, tek bir belge türü ve tek bir departmanla başlar. Örneğin yalnızca İK politikaları üzerinde çalışan bir asistan için, önce bu türün zorunlu alan seti (kaynak, bölüm, tarih, sürüm, geçerlilik durumu, erişim düzeyi) tanımlanır; sonra bu belgeler için basit ama disiplinli bir doküman etiketleme ve çıkarım boru hattı kurulur. Bu dar kapsam, şemayı hızlıca test etmeyi ve hataları erken görmeyi sağlar. Pilotun bir değerlendirme kümesiyle desteklenmesi kritiktir: gerçek kullanıcı sorularından oluşan etiketli bir liste üzerinde, filtre açıkken ve kapalıyken isabet ölçülür; böylece meta verinin gerçekten değer üretip üretmediği kanıta bağlanır. Pilottan üretime geçerken sıra önemlidir. Önce dar kapsamda şema olgunlaştırılır ve filtre etkisi ölçülür; sonra ikinci bir belge türü veya departman eklenir ve şemanın türe göre nasıl farklılaşması gerektiği görülür; ancak bu adımlar kanıtlandıkça kapsam genişletilir. Bu "ölç, iyileştir, sonra büyüt" döngüsü, kâğıt üzerinde iyi görünen ama üretimde çöken meta veri tasarımlarını, gerçekten işe yarayanlardan ayırır. Pilot boyunca yetki alanı ve gizlilik gibi kritik alanların ilk günden doğru kurulması şarttır; bunlar "sonra ekleriz" denilecek alanlar değildir. Kurumunuza özel bir meta veri pilotu ve RAG mimarisi tasarlamak için yapay zeka danışmanlığı ile başlayabilir, ekiplerinizin yetkinliği için kurumsal eğitim seçeneklerini değerlendirebilirsiniz. ## Meta Veri Tasarımı ve Değerlendirme Kümesinin İlişkisi Meta veri tasarımının kalitesini kanıta bağlamanın tek yolu, onu bir değerlendirme kümesiyle test etmektir; ve bu iki disiplin birbirini besler. Bir değerlendirme kümesi, gerçek kullanıcı sorularından ve her sorunun "doğru cevabının hangi belgede olduğu" işaretinden oluşur. Bu küme, yalnızca genel RAG kalitesini değil, meta veri filtrelerinin etkisini de ölçmeyi mümkün kılar: aynı soru setini filtre açık ve kapalı çalıştırıp isabet ve gürültü farkını görmek, filtrenin değerini soyut bir iddia olmaktan çıkarır. Değerlendirme kümesi tasarlanırken meta veri boyutlarını özellikle test eden sorular eklenmelidir. Örneğin, aynı bilginin eski ve yeni sürümü olan bir konu için bir soru koyup, sistemin güncel sürümü getirip getirmediğini ölçmek, tarih ve sürüm alanının işe yarayıp yaramadığını doğrudan sınar. Farklı yetki seviyelerindeki kullanıcılar için aynı soruyu koyup, her kullanıcının yalnızca yetkili olduğu parçaları alıp almadığını kontrol etmek, yetki alanı tasarımını test eder. Belirli bir ürün veya departmanla ilgili bir soru koyup, doküman etiketleme filtresinin doğru daraltma yapıp yapmadığını ölçmek, etiket kalitesini sınar. Bu tür hedefli test senaryoları, meta veri tasarımının her boyutunu ayrı ayrı kanıta bağlar. Bu ilişkinin en değerli sonucu, meta veri tasarımının bir kerelik bir kurulum değil, sürekli iyileştirilen bir katman haline gelmesidir. Değerlendirme kümesi büyüdükçe ve gerçek kullanıcı sorularıyla zenginleştikçe, hangi filtrenin işe yaradığı, hangisinin fazla katı olduğu, hangi alanın eksik veya tutarsız olduğu ortaya çıkar; ve her bulgu, şemayı iyileştirmek için somut bir girdi olur. Kısacası meta veri tasarımı ile değerlendirme, bir kalite döngüsünün iki yarısıdır: tasarım filtreyi kurar, değerlendirme onu kanıta bağlar, kanıt tasarımı iyileştirir. RAG değerlendirmesinin bütününü kardeş yazımız RAG değerlendirme yöntemi ve metrik tarafını RAG değerlendirme metrikleri yazısında derinleştiriyoruz. ## Meta Veri Tasarımını Kim Sahiplenir? Meta veri tasarımı, tek bir kişinin değil, birkaç yetkinliğin birlikte sahiplenmesi gereken bir iştir; çünkü hem iş bilgisi, hem veri mühendisliği, hem de uyum boyutu taşır. Sahipliğin baştan tanımlanmaması, RAG projelerinde en sık atlanan ama en belirleyici eksiklerden biridir. Meta veri kalitesi, kimsenin sürekli sorumlu olmadığı bir alanda sessizce bozulur. Tipik olarak şu roller devreye girer. Alan uzmanı, hangi belgelerin hangi etiketlere, gizlilik sınıflarına ve geçerlilik durumlarına ait olduğunu bilir; kontrollü sözlüğün ve doküman etiketleme kurallarının anlamlı olmasını sağlar. Veri/ML mühendisi, çıkarım ve doğrulama boru hattını, indeksleme ve filtre mekaniğini kurar. Uyum/hukuk sorumlusu, yetki alanı ve gizlilik alanlarının KVKK ve kurum politikalarıyla uyumunu güvence altına alır. Ürün sahibi ise soru tiplerini, filtre ihtiyaçlarını ve başarı ölçütlerini tanımlar. Bu yetkinlikleri kazandıran eğitim çerçevesini kurumsal RAG rehberi yazısında ele alıyoruz. Küçük bir kurumda bu roller tek kişide birleşebilir; büyük bir kurumda ayrı ekipler olabilir. Önemli olan rollerin sayısı değil, her sorumluluğun bilinçle birine verilmesidir. Özellikle bir sorumluluk çoğu projede sahipsiz kalır: meta veri kalitesinin sürekli izlenmesi ve şema değişikliğinin yönetilmesi. Bu sahiplik kimseye verilmezse, sistem zamanla bozulur ve kimse fark etmez. "Herkesin işi kimsenin işi" tuzağı, meta veri tarafında özellikle geçerlidir. Kurumunuza özel bir meta veri tasarımı ve RAG mimarisi kurmak için yapay zeka danışmanlığı ile başlayabilir, ekiplerinizin yetkinliği için kurumsal eğitim seçeneklerini inceleyebilir ve tüm kavramları öğrenme merkezinde derinleştirebilirsiniz. ## Meta Veri Tasarımının Olgunluk Aşamaları Nelerdir? Meta veri tasarımı, bir kurumda tek adımda kusursuz kurulmaz; kademeli olarak olgunlaşır. Bu olgunluk yolculuğunu bir merdiven gibi görmek, kurumun bugün nerede olduğunu ve bir sonraki adımın ne olması gerektiğini anlamayı kolaylaştırır. Her basamak, bir öncekinin üstüne inşa edilir ve ancak ölçülmüş bir ihtiyaç doğduğunda çıkılır; erkenden karmaşıklık eklemek, meta veri tasarımında da en pahalı hatalardan biridir. İlk basamak, meta verisiz veya en az meta verili bir başlangıçtır: yalnızca kaynak ve belge kimliği tutulur, filtreleme yoktur, arama salt anlamsaldır. Bu, hızlı bir pilot için kabul edilebilir ama üretim için yetersizdir; çünkü yetki, sürüm ve geçerlilik körlüğü taşır. İkinci basamak, zorunlu alan setinin ve temel filtrelerin devreye girmesidir: kaynak, tarih, sürüm, dil ve en kritik olarak yetki alanı eklenir; getirme artık filtreli çalışır. Çoğu kurumsal RAG'in ulaşması gereken minimum olgunluk budur. Üçüncü basamak, doküman etiketleme ve kontrollü sözlüğün olgunlaşması, otomatik çıkarım ve doğrulama boru hattının kurulmasıdır. Dördüncü basamak ise meta veri kalitesinin sürekli ölçüldüğü, şema değişikliğinin sürümle yönetildiği ve tazeliğin senkronizasyonla güvence altına alındığı yaşayan bir sistemdir. Bu merdivende önemli olan, her kurumun kendi ihtiyacına uygun basamakta durabilmesidir; her kurumun en üst basamağa çıkması gerekmez. Küçük ve dar kapsamlı bir bilgi tabanı için ikinci basamak yeterli olabilirken, çok kiracılı ve regüle bir kurumsal sistem dördüncü basamağı zorunlu kılar. Doğru strateji, bulunduğun basamağı dürüstçe tespit etmek ve bir sonrakine ancak ölçülmüş bir ihtiyaç için çıkmaktır. Bu olgunluk bakışı, meta veri tasarımını "hep ya da hiç" bir karar olmaktan çıkarır ve onu, kurumun RAG olgunluğuyla birlikte büyüyen bir yatırıma dönüştürür. Kurumsal RAG olgunluğunun bütününü kurumsal RAG rehberi yazısında ele alıyoruz. ## Meta Veriye Neyi Dahil Etmemeli? Gürültü ve Aşırı Tasarım Meta veri tasarımında az konuşulan ama kritik bir disiplin, neyi dahil etmemek gerektiğidir. Yaygın bir sezgi, "ne kadar çok meta veri o kadar iyi"dir; oysa bu yanlıştır. Amaçsız her alan, kaliteyi artırmaz; yalnızca bakım yükü, tutarsızlık riski ve gürültü üretir. Aşırı tasarlanmış bir şema — onlarca nadir kullanılan alan, her biri kendi doldurulma ve doğrulanma yükünü taşıyan — pratikte az ve iyi tasarlanmış bir şemadan daha kötü performans gösterir. Bu yüzden meta veri tasarımı bir ekleme sanatı olduğu kadar bir eleme sanatıdır. Dahil edilmemesi gereken tipik alanlar şunlardır. Hiçbir sorguda filtre veya sıralama için kullanılmayacak alanlar: eğer bir alanı hiç filtrelemeyecek, sıralamayacak, kaynak göstermeyecek veya izlemeyecekseniz, o alan yalnızca yer kaplar. Güvenilir biçimde doldurulamayan alanlar: çıkarımı sürekli hatalı olan ve doğrulanamayan bir alan, filtreyi güçlendirmek yerine yanıltır; böyle bir alan, güvenilir hale gelene kadar dahil edilmemelidir. Serbest metin etiketler: kontrollü bir sözlüğe bağlanmamış etiketler, kısa sürede tutarsızlaşır ve filtre için işe yaramaz hale gelir. Aşırı ince taneli alanlar: gerçek bir soru tipine karşılık gelmeyen, teorik olarak "faydalı olabilir" diye eklenen alanlar, çoğu zaman boş kalır ve şemayı şişirir. Doğru zihinsel model, her alan için tek bir soru sormaktır: "Bu alanı hangi somut sorguda, hangi amaçla kullanacağım?" Bu soruya net bir cevap veremiyorsanız, alan henüz dahil edilmemelidir. Bu disiplin, meta veri şemasını yalın, bakımı kolay ve gerçekten filtre değeri üreten bir yapı olarak tutar. Aşırı tasarımdan kaçınmak, yalnızca performansı değil, ekibin şemayı doğru ve tutarlı doldurma kabiliyetini de korur; çünkü basit bir şemayı herkes doğru doldurabilir, karmaşık bir şema ise tutarsız doldurulmaya mahkûmdur. Meta veri tasarımının bu "yeterince ama fazlası değil" dengesi, uzun vadede sürdürülebilir bir sistemin sırrıdır. ## Meta Veri Tasarımını Genel Veri Yönetişimiyle Nasıl Hizalarız? Bir kurumsal RAG'in meta veri tasarımı, boşlukta durmaz; kurumun genel veri yönetişimiyle hizalandığında en güçlü hale gelir. Çoğu kurumda belgeler, ait oldukları kaynak sistemlerde zaten bir tür meta veriyle — sahiplik, gizlilik sınıfı, saklama politikası, erişim izinleri — yönetilir. Meta veri tasarımının doğru yaklaşımı, bu mevcut yönetişimi görmezden gelip sıfırdan bir şema kurmak değil, ondan beslenmek ve onunla tutarlı kalmaktır. Kaynak sistemdeki gizlilik sınıfı, RAG'in yetki alanına doğrudan eşlenmelidir; kaynak sistemdeki saklama politikası, RAG'in geçerlilik ve silme davranışını belirlemelidir. Bu hizalanma iki yönlü değer üretir. Birincisi tutarlılık: aynı belge, kaynak sistemde ve RAG'de aynı gizlilik ve erişim kurallarına tabi olur; bu, bir belgenin kaynakta gizli ama RAG'de açık olması gibi tehlikeli çelişkileri önler. İkincisi verimlilik: mevcut yönetişimden gelen meta veri, en güvenilir çıkarım kaynağıdır — çünkü insan sürecinin ürünüdür — ve sıfırdan çıkarım yapmaya kıyasla hem daha doğru hem daha ucuzdur. Bu yüzden meta veri tasarımının ilk adımlarından biri, kurumun mevcut veri yönetişimini ve kaynak sistemlerdeki meta veriyi haritalamaktır. Bu haritalamanın genel çerçevesini veri yönetişimi nedir yazısında ele alıyoruz. Hizalanmanın bir başka boyutu, sorumluluk ve süreç paylaşımıdır. Kurumun veri yönetişimi zaten bir sahiplik, sınıflandırma ve yaşam döngüsü süreci tanımlıyorsa, RAG'in meta veri tasarımı bu süreçlere bağlanmalı, paralel ve çelişen bir süreç kurmamalıdır. Örneğin bir belgenin gizlilik sınıfı değiştiğinde, bu değişiklik hem kaynak sistemi hem RAG indeksini güncellemeli; iki sistem ayrı ayrı yönetilmemelidir. Bu bütünlük, meta veri tasarımını izole bir RAG detayı olmaktan çıkarıp, kurumun bilgi yönetişiminin bir uzantısı haline getirir. Kısacası en sağlam meta veri tasarımı, tekerleği yeniden icat etmez; kurumun mevcut yönetişimini RAG'in getirme katmanına taşır ve orada filtreye dönüştürür. Bu bakış, hem uyum hem sürdürülebilirlik açısından en dayanıklı yaklaşımdır. ## Meta Veriyle Sorgu Yönlendirme ve Koleksiyon Seçimi Meta veri yalnızca bir sorgunun içindeki parçaları filtrelemek için değil, sorgunun hangi indekse veya koleksiyona gideceğini belirlemek için de kullanılır. Büyük ve çeşitli bir bilgi tabanında, tüm belgeleri tek bir devasa indekste tutmak yerine, onları anlamlı koleksiyonlara (örneğin departmana, ürüne, dile veya belge türüne göre) ayırmak hem performansı hem isabeti artırabilir. Bu durumda sorgu geldiğinde, sistem önce sorgunun ve kullanıcının meta verisine bakarak hangi koleksiyonlarda arama yapacağına karar verir; bu karara sorgu yönlendirme (routing) denir ve meta veri tasarımının doğal bir uzantısıdır. Sorgu yönlendirme birkaç sinyalden beslenir. Kullanıcının kimliği ve yetki alanı, hangi koleksiyonlara erişebileceğini belirler; sorgunun dili, hangi dil koleksiyonuna gideceğini; sorgudan çıkarılan konu veya ürün, hangi tematik koleksiyonun uygun olduğunu gösterir. İyi bir yönlendirme, aramayı yalnızca ilgili koleksiyonlarla sınırlayarak hem gecikmeyi hem gürültüyü azaltır; kötü bir yönlendirme ise ya doğru koleksiyonu atlar (kapsama kaybı) ya da gereksiz yere hepsini tarar (performans kaybı). Bu yüzden yönlendirme kararları da, filtreler gibi, bir değerlendirme kümesiyle test edilmelidir. Yönlendirme ile filtreleme birbirini tamamlar: yönlendirme kaba taneli bir ön seçim (hangi koleksiyon), filtreleme ise ince taneli bir eleme (koleksiyon içinde hangi parçalar) yapar. İkisinin birlikte tasarlanması gerekir. Örneğin çok kiracılı bir sistemde kiracı kimliği önce yönlendirmeyi belirler (kiracının koleksiyonu), sonra kiracı içi yetki alanı filtreyi belirler. Bu iki katmanlı yaklaşım, hem güvenliği hem performansı güçlendirir. Ancak yönlendirmenin bir tuzağı vardır: fazla agresif yönlendirme, doğru cevabın beklenmedik bir koleksiyonda olduğu durumlarda onu kaçırabilir. Bu yüzden belirsiz durumlarda birden çok koleksiyonda paralel arama yapıp sonuçları birleştirmek daha güvenlidir. Sorgu yönlendirme, meta veri tasarımının en üst basamaklarından biridir ve genellikle sistem belirli bir ölçeğe ve çeşitliliğe ulaştığında değer üretir; küçük bir bilgi tabanında tek koleksiyon ve iyi bir filtre çoğu zaman yeterlidir. Yönlendirmenin sorgu yeniden yazma ile ilişkisini hibrit arama ve sorgu yeniden yazma rehberi yazısında ele alıyoruz. Yönlendirme kararının bir başka faydası maliyet tarafındadır: aramayı yalnızca ilgili koleksiyonlarla sınırlamak, taranan vektör sayısını ve dolayısıyla hesaplama yükünü azaltır. Büyük ölçekli bir bilgi tabanında bu, hem gecikmeyi hem işletme maliyetini belirgin biçimde düşürebilir. Ancak yönlendirmeyi ölçeğe uygun tasarlamak gerekir; küçük bir sistemde koleksiyonlara bölmenin getirdiği yönetim karmaşıklığı, sağladığı hızdan fazla olabilir. Bu yüzden koleksiyon stratejisi, tıpkı diğer meta veri kararları gibi, kurumun ölçeğine, çeşitliliğine ve gerçek soru dağılımına bakılarak, ölçülerek verilir. Doğru kurgulanmış bir yönlendirme ve filtreleme ikilisi, meta veri tasarımının kaliteyi, güvenliği, performansı ve maliyeti aynı anda iyileştirebilen bir kaldıraç olduğunu net biçimde gösterir. ## Özet: Meta Veri Tasarımı Neden RAG'de Filtrelemenin Temelidir? Kısaca özetleyelim: meta veri tasarımı, bir RAG sisteminde her belge parçasına anlamının yanında onu tanımlayan yapısal alanları — kaynak, belge türü, bölüm, tarih, sürüm, dil, yetki alanı ve etiketler — planlı biçimde eklemektir. Bu alanlar getirmeyi salt anlamsal benzerlikten filtreli aramaya taşır: sistem önce kullanıcının yetkisine, sorunun bağlamına ve bilginin geçerliliğine uyan parçaları eler, sonra bunlar arasından anlamca en yakınını seçer. Böylece RAG, doğru cümleyi bulmakla kalmaz; onu doğru kullanıcıya, doğru sürümden ve doğru bağlamda getirir. Bu yazı boyunca gördüğümüz gibi, meta veri tasarımı tek bir tekniğe indirgenemez; meta verisiz aramanın körlüğünden başlayıp zorunlu alan setine, yetki ve gizlilik alanlarına, tarih ve sürüm alanına, otomatik çıkarım ve doğrulamaya, şema değişikliği yönetimine ve pratik bir tasarım şablonuna uzanan bütünsel bir disiplindir. Her biri ayrı bir kaldıraçtır: doküman etiketleme isabeti daraltır, yetki alanı gizliliği korur, tarih ve sürüm alanı eskimeyi ayıklar, filtreleme RAG doğruluğunu benzerlik kadar belirler. Bu parçaların hiçbiri tek başına yeterli değildir; birlikte tasarlandıklarında bir bütün olarak RAG'in getirme katmanını güvenilir kılarlar. En önemli mesaj şudur: RAG'de kalite yalnızca anlamsal benzerlikten gelmez; filtreleme, benzerlik kadar belirleyicidir. Meta verisiz bir sistem, anlamca isabetli ama bağlamca yanlış cevaplar üretebilir ve bunu fark etmez. İyi bir meta veri tasarımı ise yetki alanıyla gizliliği korur, tarih ve sürüm alanıyla eskimeyi ayıklar, doküman etiketleme ile isabeti artırır, ve filtreleme RAG doğruluğunu görünür ve ölçülebilir biçimde yükseltir. Bu katman, RAG'in en az konuşulan ama en çok fark yaratan yatırımlarından biridir. Temel kavramları tazelemek için RAG nedir, embedding nedir ve chunking nedir rehberlerine, getirmenin ileri tarafı için hibrit arama RAG ve reranker nedir yazılarına, kaliteyi kanıta bağlamak için kardeş yazımız RAG değerlendirme yöntemi yazısına bakabilirsiniz. Kurumunuza özel bir RAG mimarisi ve meta veri tasarımı için bültene katılın ve bizimle iletişime geçin; ekiplerinizin yetkinliği için kurumsal eğitim seçeneklerini değerlendirebilir, tüm kavramları öğrenme merkezinde derinleştirebilirsiniz.