Kurumsal RAG mimarisi nasıl kurulur?

Envanter, teknik bir liste değil bir yetki haritasıdır. Her kaynak için üç şey yazılmalı: belge nerede duruyor, kim erişebiliyor, ne sıklıkla değişiyor. Üçüncüsü genellikle atlanıyor ama mimariyi belirliyor: günlük değişen bir kaynak ile yılda bir güncellenen bir kaynak aynı yeniden dizinleme stratejisini kullanamaz.

Ayrıştırmanın amacı metin çıkarmak değil, yapıyı korumaktır. Başlık hiyerarşisi, tablo sınırları ve madde numaraları kaybedildiğinde sonraki adımların hiçbiri telafi edemiyor. Her biçim için ayrı ayrıştırıcı kullanmak, tek bir genel çözüm aramaktan hemen her zaman daha iyi sonuç veriyor.

• PDF: metin katmanı varsa onu kullanın; taranmışsa OCR ve görsel-dil modeli birlikte doğrulama olarak çalışsın.
• Ofis dosyaları: başlık stillerini hiyerarşi olarak çıkarın, yorum ve izlenen değişiklikleri ayırın.
• HTML: gezinme ve altlık bloklarını atın; ana içeriği izole edin.
• Elektronik çizelge: her satırı başlık satırıyla birleştirin.

Doğrulama adımı: on temsilî belgeyi ayrıştırdıktan sonra çıktıyı elle okuyun. Başlıklar duruyor mu, tablolar okunabilir mi, sayfa altlıkları metne karışmış mı? Bu on dakikalık kontrol, sonraki iki haftayı kurtarıyor.

Doğru soru "kaç token" değil: bu belge türünde anlamın kendi içinde tamamlandığı en küçük birim nedir? Mevzuatta bir madde, dokümantasyonda bir alt başlık bölümü, tabloda bir satır artı başlık, destek kaydında bir soru-cevap çifti.

{
  "parca_kimligi": "izin-proseduru-v3#madde-7b",
  "metin": "7/b) Yıllık izin talebi, en az yedi gün önce ...",
  "ust_veri": {
    "belge": "İzin Prosedürü",
    "surum": "v3",
    "yururluk": "2026-01-01",
    "baslik_yolu": ["İzinler", "Yıllık izin", "Talep süreci"],
    "madde": "7/b",
    "dil": "tr",
    "erisim_grubu": "tum-calisanlar"
  }
}

Doğrulama adımı: iki strateji kurup aynı 15 sorguyla karşılaştırın. Sabit uzunlukta bölme ile yapısal bölmenin ilk-beş ilgili oranı arasındaki fark, kararınızı tahmine değil ölçüme dayandırır.

Gömme modeli seçimi bir kerelik bir karar gibi görünür ama taşınma maliyeti yüksektir: model değiştiğinde tüm vektörlerin yeniden üretilmesi gerekir. Bu yüzden seçim kriterleri arasına "sürüm politikası" da girmelidir.

1. 01Türkçe performansı ölçülmüş bir model seçin; varsaymayın.
2. 02Girdi token sınırını parçalama stratejinizle uyumlu doğrulayın.
3. 03Dizine lexical arama yeteneğini de kurun; sonradan eklemek zordur.
4. 04Üst veri alanlarını filtrelenebilir biçimde tanımlayın.
5. 05Yeniden dizinleme süresini ölçün; bu, bakım penceresi planınızdır.

İki listeyi birleştirirken puanları toplamayın: kosinüs benzerliği ile lexical puan aynı ölçekte değil. Sıra tabanlı birleştirme (reciprocal rank fusion) bu sorunu yapısal olarak çözer ve üçüncü bir sinyal eklemeyi de kolaylaştırır.

def karsilikli_sira_birlestir(listeler, k=60):
    puanlar = {}
    for liste in listeler:
        for sira, kimlik in enumerate(liste, start=1):
            puanlar[kimlik] = puanlar.get(kimlik, 0) + 1 / (k + sira)
    return sorted(puanlar, key=puanlar.get, reverse=True)


birlesik = karsilikli_sira_birlestir([
    anlamsal_ara(sorgu, n=50),
    lexical_ara(sorgu, n=50),
])

Yeniden sıralayıcı yalnızca ilk 20-50 adaya uygulanır; tüm dizine uygulanamaz çünkü sorgu ve belgeyi birlikte okur. Etkisini Recall@5 ile p95 gecikmeyi birlikte raporlayarak ölçün.

En sık yapılan mimari hata, yetki filtresini arama sonrasına bırakmak. Bu iki sorun üretir: yetkisiz belge cevaba karışabilir ve filtre sonrası sonuç sayısı beklenmedik biçimde sıfıra düşebilir. Yetki grubu üst veride tutulmalı ve arama sorgusunun parçası olmalı.

Doğrulama adımı: iki farklı yetki seviyesindeki test kullanıcısıyla aynı sorguyu koşturun. Sonuç kümeleri farklı olmalı; aynıysa filtre uygulanmıyor demektir.

Cevap kalitesindeki düşüşün nedeni neredeyse her zaman geri getirmedir. Bu yüzden iki hat ayrı ölçülmeli: geri getirme hattı (Recall@k, MRR, boş dönüş oranı) ve cevap hattı (kaynaklı iddia oranı, kaçış kullanımı, biçim uyumu).