RAG tarafında çalışan biriyseniz, şu cümle size tanıdık gelebilir: “Biz sadece doğru dokümanı çekiyoruz.” Güzel. Ama eğitim verisi, öğrenci kaydı, yetki sınırı gibi konular devreye girince iş öyle basit kalmıyor (ben de ilk duyduğumda şaşırmıştım). Hele konu FERPA ise… bir anda semantik arama ile hukuk aynı masaya oturuyor ve ortam hafif geriliyor.
Editör masasındayken bu tip konulara takılmayı seviyorum. Geçen ay, 2024’ün sonlarına doğru İstanbul’da bir kurumsal AI demosunu incelerken benzer bir akış gördüm: kullanıcıya özel bilgi filtreleniyor sanılıyor ama aslında önce her şey toplanıyor, sonra süzülüyor. İşin aslı şu ki, güvenlikte “sonra bakarız” çoğu zaman geç kalmak demek.
Şimdi gelelim işin can alıcı noktasına.
Vallahi, FERPA’yı burada sadece hukuki bir kısaltma gibi düşünmeyin. Bu düzenleme, eğitim kayıtlarının kim tarafından görülebileceğini çok net sınırlıyor (ciddiyim). Yani mesele yalnızca modelin yanlış cevap vermesi değil; yanlış verinin arama hattına hiç girmemesi gerekiyor (şaşırtıcı ama gerçek). Bakın şimdi, tam da kilit fark burada başlıyor.
Asıl sorun modelde değil, akışta
Kendi deneyimimden konuşuyorum, Pek çok ekip RAG’i şöyle kuruyor: vektör veritabanından en alakalı ilk 20 belgeyi alıyor, sonra bunların içinden yişe yarayan olanları seçiyor. Kağıt üstünde mantıklı duruyor. Hatta demo sırasında fena da görünmüyor. Neden önemli bu? Ama pratikte bu yapı riskli — yetkisiz veri önce sistemin içine sızmış oluyor; sonra temizlemeye çalışıyorsunuz, ki bu tam anlamıyla işi tersine yapmak demek.
Bunu mutfak örneğiyle anlatayım. Önce tüm tezgâha çiğ et koyup ardından “sadece sebzeleri kullanacağım” demek gibi, hani. Evet, sonunda tabağa et koymamış olabilirsiniz ama hijyen meselesi çoktan bozulmuştur — bu kadar basit. Retrieval dünyasında da aynı hikâye var; aday havuzuna giren veri. Temas edilmiş sayılıyor, isterse sonunda context’e düşmesin.
Geçen sene Berlin’de konuştuğum bir mühendis arkadaşım bunu kendi üniversite projesinde yaşamıştı. Filtreyi post-processing’e bırakmışlar ve küçük bir metadata hatası yüzünden başka öğrencinin not dökümleri kısa süreliğine context’e düşmüş. Kimse fark etmemişti… ta ki log analizi yapılana kadar. Açık konuşayım, böyle olaylarda şansınız varsa ucuz kurtulursunuz (buna dikkat edin). Şansınız yoksa — neyse, oraya girmeyeyim.
Neden “top-k al sonra filtrele” modeli zayıf kalıyor?
Hata yüzeyi büyüyor, bu kadar. Yanlış alan adı yazarsınız, metadata eksik gelir, exception bir yerde sessizce yutulur ya da indeksleme sırasında bir tenant etiketi atlanır — hepsi aynı yere çıkar: uygunsuz veri candidate set’e girer ve siz bunun farkında bile olmayabilirsiniz, ki işte asıl korkunç olan bu. Daha fazla bilgi için Kod Karo’da Video Arama: Canlı Kod Editörüne Yeni Soluk yazımıza bakabilirsiniz. Daha fazla bilgi için PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımıza bakabilirsiniz.
Bir de şu var: LLM tarafı bazen beklediğinizden fazla özgüven gösteriyor. Bunu Claude Sonnet 4 Bazen Fazla Detay Verir: Uydurma mı, Özgüven mi? yazısında tartışmıştık; model bazen eli boş olsa bile doluymuş gibi davranabiliyor (en azından benim deneyimim böyle). RAG’de kötü filtreleme ile birleşince sonuç daha da tatsız oluyor. İkisi bir araya gelince… hmm, nasıl desem, patlama beklenmedik bir anda geliyor. Wi-Fi’de Anten Sayısı: Hız Efsanesi Ne Kadar Doğru? yazımızda bu konuya da değinmiştik.
Ve işler burada ilginçleşiyor. Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımızda bu konuya da değinmiştik.
Kural 1: Sıralamadan önce filtrele
Lafı gevelemeden söyleyeyim: erişim kontrolü query seviyesinde başlamalıdır. Önce kim olduğunuzu doğrulayın, sonra o kimliğe uygun belge kümesini daraltın. Bu yaklaşım hem güvenlik açısından daha sağlamdır hem de bir hata olduğunda hasarı en küçük tutmanızı sağlar — “önce al sonra eleyelim” mantığına kıyasla gece uyku kaliteniz de farklı olur, inanın.
| Yöntem | Davranış | Risk |
|---|---|---|
| Önce getir sonra filtrele | Tüm adaylar skorlanır | Yetkisiz veri ara aşamalarda görünür |
| Sorguda filtre uygula | Sadece izinli belgeler döner | Daha düşük saldırı yüzeyi |
| Sadece LLM çıktısını denetle | Cevap sonrası kontrol yapılır | Zaten geç kalınmıştır |
# Kötü örnek
all_docs = vector_store.similarity_search(query, k=20)
authorized = [d for d in all_docs if d.metadata["student_id"] == session.student_id]
# Daha doğru örnek
authorized = vector_store.similarity_search(
query,
k=20,
filter={
"student_id": session.student_id,
"institution_id": session.institution_id
}
)Açık konuşayım, bu kod parçası kulağa basit geliyor. Gerçekten basit. Ama sahada, özellikle çok kiracılı sistemlerde, bu farkın ne kadar kritik olduğunu görünce insan “nasıl olur da bunu atlıyoruz” diye düşünüyor. Pinecone, Weaviate, Qdrant ve pgvector gibi araçların çoğu pre-filter destekliyor; yani mesele teknik olarak çözümsüz değil, sadece alışkanlık meselesi.
Kural 2: student_id tek başına yetmez
Burası biraz can sıkıcı çünkü birçok ekip ilk etapta sadece öğrenci kimliğini yeterli sanıyor. Değil işte. Bir kurum içinde benzersiz olan student_id başka bir kurumda tekrar edebilir ya da transfer senaryolarında her şey karışabilir — ve o karışıklığı sonradan çözmek, baştan önlemekten çok daha zor. Bu konuyla ilgili Windows Kurulumunu 2 Dakikaya İndiren Küçük Bir Araç yazımıza da göz atmanızı tavsiye ederim.
Kendi test ortamımda Ankara’daki küçük bir üniversite pilotu için buna benzer senaryo kurmuştum; iki farklı tenant’ta aynı ID formatını kullandığınızda çakışma ihtimali bayağı yükseliyor. O an insan düşünüyor: “Bunu nasıl atlamışız?” Cevap basit — çünkü demo verisi temizdir ama gerçek dünya dağınık olur. Her zaman.
Neden institution_id şart?
Eğer sisteminiz çok kurumluysa — ya da ileride öyle olacaksa, ki büyük ihtimalle olacak — institution_id olmadan yapılan filtreleme yarım yamalak kalır. Öğrenci kimliği + bir düşüneyim… kurum kimliği ikilisi birlikte çalışmalı; tıpkı kapının anahtarıyla apartman numarasının birlikte anlam taşıması gibi. Biri olmadan diğeri yeterli değil.
- Kurumlar arası ID çakışmasını önler. — ciddi fark yaratıyor
- Migrasyon ve transfer süreçlerinde sınırı net tutar.
- Tenant izolasyonunu güçlendirir.
- Denetimde açıklanabilirlik sağlar.
FERPA açısından en güvenli yaklaşım şu fikri merkeze alır:
“Doğru cevabı üretmek” kadar “yanlış veriyi hiç görmemek” de önemli.
Kural 3 ve sonrası: Metadata disiplinini gevşetmeyin
Bence en çok ihmal edilen nokta metadata kalitesi oluyor. Alan adı standardınız yoksa studentId, student_id, sid üçlüsü arasında gidip gelen yapılar doğuyor. Filtreler sessizce bozuluyor. Sessizce. Hata mesajı yok, alarm yok — sistem çalışıyor gibi görünüyor ama içeride bir şeyler kırık.
Neyse uzatmayalım; iyi çalışan sistemlerin ortak özelliği genelde sıkıcı olmalarıdır. Etiketleri nettir, tenant alanları sabittir, loglama düzgündür. Ha bu arada log demişken — ben geçen yıl İzmir’de kurulan orta ölçekli bir SaaS platformunda inceleme yaparken gördüm ki ekip retrieval başarısını ölçüyordu ama authorization başarısını ölçmüyordu. İşte tam o noktada küçük görünen şey büyüdü. Sorgu sayısı artınca sorun patladı.
Bu yüzden metrikleri ikiye ayırmak lazım: başarı oranı ayrı, yetkilendirme güvenliği ayrı. Gelen kutusundaki güzel cevap sizi yanıltmasın.
Sessiz hatalar neden tehlikeli?
- Error swallow eden try/catch blokları filtre hatasını gizler.
- Boş sonuç” ile “erişim reddi” arasındaki fark çoğu yerde izlenmez. — ciddi fark yaratıyor
- Eşik değerleri değişince bazı belgeler görünür hale gelebilir.
- Sistem çalışıyor gibi görünür ama uyum kırılmış olur.
Küçük startup ile enterprise arasında fark ne?
Küçük startup tarafında problem genelde hız baskısıdır; herkes MVP peşindedir. Authorization katmanı “sonra ekleriz” diye ötelenir — Anlaşılır, hatta bir noktaya kadar mantıklı. Ama o “sonra” hiç gelmeyebiliyor.
Kurumsal tarafta ise durum daha karmaşık olur çünkü entegrasyon fazladır: öğrenci bilgi sistemi, kimlik sağlayıcı, arama altyapısı, log toplama… hepsi birbirine bağlıdır ve bu bağlantıların her biri potansiyel bir kırılma noktasıdır. Açık konuşayım, enterprise projelerde hata tek noktada çıkmaz; bir yerde başlayan küçük sapma üç servis sonra baş ağrıtır.
Startup için tavsiyem: basit başlayın ama pre-filter kuralını ilk günden koyun. Enterprise için tavsiyem ise: tenant ayrımı + audit trail + redaction politikası olmadan canlıya çıkmayın (bizzat test ettim). Ben olsam pilot ortamda bile sentetik öğrenci kayıtlarını kullanırım. Gerçek veriyle acele etmek… pek parlak fikir değil.
Peki sağlam mimari nasıl görünür?
User Request
↓
AuthN / AuthZ Check
↓
Institution + Student Scope Derivation
↓
Vector Store Pre-Filter Query
↓
Rank Authorized Candidates Only
↓
LLM Context Assembly
↓
Response Generation + Audit Log
// Kritik fikir:
// Yetkisiz belge candidate set'e hiç girmesin.
}
User Request
↓
AuthN / AuthZ Check
↓
Institution + Student Scope Derivation
↓
Vector Store Pre-Filter Query
↓
Rank Authorized Candidates Only
↓
LLM Context Assembly
↓
Response Generation + Audit Log
// Kritik fikir:
// Yetkisiz belge candidate set'e hiç girmesin.
}Ne yalan söyleyeyim, Aşağıdaki kontrol listesi işinizi kolaylaştırır:
- Kullanıcı kimliği session seviyesinde doğrulansın.
- Tenant/institution alanı zorunlu olsun.
- Metadata şeması versiyonlansın. — bunu es geçmeyin
- Erişim denemeleri loglansın. — bunu es geçmeyin
- Cevap sonrası maskeleme yerine önleyici tasarım tercih edilsin.
Düzgün kurulmuş RAG sistemi biraz sıkıcı görünür; aslında iyi haber budur. Gürültülü olmayan güvenlik tasarımı çoğu zaman alkış almaz… ama gece rahat uyutur.
Pratikte neyi test etmelisiniz?
Doğrusu, Editör gözüyle söyleyeyim: ben böyle yazıları okurken hemen kendime küçük test senaryosu çıkarırım. Mesela Ocak 2025’te yaptığım notlarda üç şey özellikle dikkatimi çekmişti: aynı student_id’nin farklı kurumlarda tekrar edilmesi, eksik metadata alanları ve hata mesajlarının sessizce yutulması. Tahmin eder misiniz? Birkaç dakika içinde yapılacak kaba testler bile sizi büyük sürprizlerden kurtarabilir.
- Aynı kullanıcıyla iki tenant üzerinden sorgu atın.
- Bilinmeyen metadata alanıyla request gönderin.
- Erişim reddedildiğinde gerçekten boş mu dönüyor bakın.
- Aynı dokümanın retrieval log’una düşüp düşmediğini kontrol edin.
Sıkça Sorulan Sorular
FERPA uyumlu RAG nedir?
Öğrenci kayıtlarını yalnızca yetkili kullanıcıların görebildiği şekilde çalışan retrieval tabanlı yapıdır.
Veri önce süzülmeli,
sonra sıralanmalıdır.
Neden post-filter yeterli değil?
Çünkü yetkisiz veri zaten işlem hattına girmiş olur.
Bu hem güvenlik riski yaratır hem de denetimde savunması zor bir açık bırakır.
Sadece student id filtresi neden sorun çıkarır?
Aynı öğrenci numarası farklı kurumlarda tekrar edebilir ya da transfer senaryolarında karışabilir.
Kurum sınırı ayrıca belirtmekte fayda var.
Küçük ekipler bunu nasıl yönetebilir?
MVP aşamasında bile pre-filter ve temel audit log eklemek iyi başlangıçtır.
Sonradan yamamak yerine baştan doğru kurmak daha ucuzdur.
34 CFR Part 99 — FERPA Düzenlemeleri
U.S Department of Education — Student Privacy Policy Office
Pinecone Metadata Filtering Dokümantasyonu
>
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.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
