Şirket Verisiyle Konuşan Asistan Mimarisi

Kazanimlar:

• Uçtan uca bir kurumsal RAG asistanının bileşenlerini ve veri akışını tasarlamak
• Çok kaynaklı veriyi (wiki, ticket, PDF, veritabanı) tek bir asistanda birleştirmek
• Ölçeklenebilirlik, önbellekleme ve gecikme (latency) için mimari kararlar almak

Önceki ünitelerde parçaları tek tek öğrendik: embedding, vektör veritabanı, chunking, retrieval. Şimdi bunları birleştirip kendi şirket verinizle konuşan bir asistanın uçtan uca mimarisini kuralım. Amaç, bir çalışanın "İzin politikamız ne?" diye sorabildiği, cevabın gerçek iç dokümanlara dayandığı, kaynak gösterdiği ve birden fazla veri kaynağını birleştiren bir sistem. Bu ünite mimarinin bütününü, veri akışını ve üretim seviyesindeki kararları işler.

Uçtan Uca Bileşenler

Bir kurumsal RAG asistanı iki ayrı hattan oluşur. İndeksleme hattı (offline) veriyi hazırlar; sorgu hattı (online) soruyu cevaplar.

İndeksleme hattı bileşenleri:

1. Konektörler (connectors): Kaynaklardan veri çeken bağlayıcılar — wiki, ticket sistemi, dosya deposu, veritabanı, e-posta.
2. Normalizasyon: Farklı formatları (PDF, HTML, DOCX) temiz metne çevirme; header/footer temizliği.
3. Chunking + metadata: Parçalama ve etiketleme (kaynak, tarih, yetki).
4. Embedding + yükleme: Vektörleri ve metadata'yı vektör veritabanına yazma.

Sorgu hattı bileşenleri:

1. Sorgu ön-işleme: Yeniden yazma, bağımsızlaştırma.
2. Retrieval: Hybrid arama + metadata filtresi + re-ranking.
3. Prompt oluşturma: Bağlam + soru + talimatları şablona yerleştirme.
4. Üretim: Modelden grounded (bağlama dayalı) cevap + kaynaklar.
5. Son-işleme: Citation formatlama, güvenlik kontrolü, loglama.

İpucu: İndeksleme hattını sorgu hattından fiziksel olarak ayırın. İndeksleme ağır ve periyodiktir (geceleyin toplu çalışır); sorgu hattı hafif ve anlık olmalı. İki hattı karıştırmak, kullanıcı beklerken ağır işlem yapmaya zorlar.

Veri Akışını Görselleştirmek

[İNDEKSLEME - offline]Kaynaklar → Normalize → Chunk+Metadata → Embed → Vektör DB (wiki, ticket, PDF, DB)[SORGU - online]Kullanıcı sorusu → Ön-işleme → Retrieval (hybrid+filtre+rerank) → Prompt (bağlam+soru+talimat) → Model → Cevap+Kaynak → Kullanıcı

Çok Kaynaklı Veriyi Birleştirmek

Gerçek şirketlerde cevap tek yerde durmaz. "Bir müşteriye iade nasıl yapılır?" sorusunun cevabı hem yardım makalesinde (prosedür), hem ticket geçmişinde (gerçek örnekler), hem de politika PDF'inde (kurallar) olabilir. Asistan hepsini tek havuzda aramalı.

Kritik nokta: kaynakları tek vektör deposunda birleştirirken her parçanın `kaynak_turu` metadata'sını taşıması gerekir. Böylece hem hepsinde arayabilir hem de gerekirse "sadece resmî politikaları getir" gibi filtreleyebilirsiniz. Ayrıca farklı kaynakların güvenilirlik seviyesi farklıdır: resmî politika > yardım makalesi > bir çalışanın ticket notu. Re-ranking veya prompt'ta bu önceliği belirtebilirsiniz.

Kaynak

İçerik türü

Güven

Güncelleme sıklığı

Politika PDF

Resmî kural

Yüksek

Aylık

Yardım makalesi

Prosedür

Orta-yüksek

Haftalık

Ticket geçmişi

Gerçek örnek

Orta

Sürekli

Wiki

Karışık/güncel not

Değişken

Sürekli

Ölçeklenebilirlik, Önbellek ve Gecikme

Üretimde üç konu öne çıkar. Gecikme (latency): Kullanıcı 2 saniyeden fazla bekleyince deneyim bozulur. Çözüm: cevabı akış (streaming) hâlinde göstermek — model yazdıkça ekrana dökülür. Önbellek (cache): Sık sorulan sorular ve tekrar eden bağlamlar için önbellek, hem hızı artırır hem maliyeti düşürür. Ölçek: Kullanıcı arttıkça retrieval ve model çağrılarını yatay büyütebilmek gerekir.

Maliyet tarafında pratik kural: en pahalı adım genelde büyük modele giden token sayısıdır. Bu yüzden re-ranking ile bağlamı 4 iyi parçaya indirmek hem kaliteyi hem maliyeti iyileştirir. Basit sınıflandırma veya yönlendirme için daha küçük/hızlı bir model, nihai cevap için daha güçlü bir model kullanmak (örneğin claude-opus-4-8) yaygın bir tasarımdır.

Dikkat: İndekslemeyi "bir kez yap, unut" olarak kurmayın. Dokümanlar değişir, silinir, eklenir. Tazeleme (re-indexing) stratejisi kurun: değişen dokümanları algılayıp yalnızca onları yeniden işleyin. Bayat indeks, güncel görünen ama yanlış cevap üretir.

Zayıf Mimari / Güçlü Mimari

Zayıf (tek betik, her şey karışık):

Kullanıcı sorunca: dokümanları o an oku, parçala, embed et, ara, cevapla.# Sorun: her soruda tüm indeksleme tekrar; saniyeler süren gecikme,# kaynak ayrımı yok, filtre yok, tazeleme yok.

Güçlü (ayrık hatlar + metadata + önbellek + streaming):

İndeksleme: gece toplu çalışır, değişen dokümanları tazeler.Sorgu: hafif hat — ön-işleme → hybrid retrieval+filtre → rerank → prompt → model (streaming) → citation → log.Sık sorular ve kaynak önbelleğe alınır.

Üç Mini Vaka

Vaka 1 — Karışık hat, ağır gecikme. Bir startup, her soruda PDF'leri baştan işleyen tek betik yazmış; her cevap ortalama 11 saniye sürüyormuş. İndeksleme hattı ayrılıp veriler önceden vektör deposuna alınınca sorgu süresi 1,3 saniyeye inmiş ve streaming ile "ilk kelime" 400 ms'de görünmüş.

Vaka 2 — Çok kaynak, yanlış öncelik. Bir destek asistanı politika PDF'i ile eski ticket notlarını eşit ağırlıkta değerlendiriyordu; model bazen bir çalışanın iki yıl önceki yanlış notunu resmî kural gibi sundu. kaynak_turu metadata'sı ve prompt'ta "çelişkide resmî politikayı esas al" talimatı eklenince yanlış-öncelik hataları %89 azaldı.

Vaka 3 — Bayat indeks. Bir İK asistanı 3 ay güncellenmeyen indeksle çalışıyordu; izin politikası değişmiş ama asistan eski günü söylüyordu. Değişen dosyaları algılayan günlük tazeleme kurulunca güncel-cevap oranı %70'ten %99'a çıktı.

Sık yapılan hatalar

• İndeksleme ve sorgu hatlarını karıştırmak: Kullanıcı beklerken ağır işlem yapılır; gecikme patlar.
• Kaynak türünü metadata'ya koymamak: Öncelik ve filtreleme yapılamaz; güvensiz kaynak resmî gibi görünür.
• Tazeleme stratejisi kurmamak: İndeks bayatlar; güncel görünen yanlış cevaplar üretilir.
• Streaming'i atlamak: Kullanıcı boş ekrana bakar; algılanan gecikme yüksek olur.
• Her adımda en büyük modeli kullanmak: Maliyet gereksiz artar; yönlendirmeyi küçük modele bırakın.

Özetle

• Kurumsal RAG asistanı iki ayrı hattan oluşur: offline indeksleme ve online sorgu; bunları fiziksel olarak ayırın.
• İndeksleme = konektör + normalize + chunk/metadata + embed/yükle; sorgu = ön-işleme + retrieval + prompt + üret + son-işleme.
• Çok kaynaklı veri tek havuzda birleştirilir ama kaynak_turu metadata'sı ve güven önceliği korunur.
• Gecikme için streaming ve önbellek, maliyet için bağlam daraltma ve model seçimi kritiktir.
• Tazeleme (re-indexing) olmadan indeks bayatlar; değişen dokümanları düzenli yeniden işleyin.

Uygulama görevi

Kendi ekibiniz için bir asistanın mimari şemasını çizin. (1) En az üç gerçek veri kaynağı belirleyin ve her biri için bir konektör ihtiyacını, güncelleme sıklığını ve güven seviyesini yazın. (2) İndeksleme ve sorgu hatlarını kutu-ok diyagramıyla ayrı ayrı çizin. (3) "Bu asistanda gecikmeyi nerede, maliyeti nerede düşürürüm?" sorusuna en az iki somut karar yazın. (4) Tazeleme stratejinizi bir cümleyle tanımlayın: hangi kaynak ne sıklıkla yeniden indekslenecek?

Kontrol listesi

• [ ] İndeksleme ve sorgu hatlarını ayrı ayrı ve doğru bileşenlerle çizebiliyorum.
• [ ] Çok kaynaklı veriyi kaynak_turu ve güven önceliğiyle birleştirebiliyorum.
• [ ] Gecikme için streaming/önbellek, maliyet için model seçimi kararlarını verebiliyorum.
• [ ] Tazeleme (re-indexing) stratejisinin neden zorunlu olduğunu biliyorum.
• [ ] Mimarimde en pahalı adımın genelde büyük modele giden token olduğunu göz önünde tutuyorum.