Bir kurumsal müşteri "şirket dokümanlarımızı anlayan bir AI istiyoruz" dediğinde, çoğu firma cevap olarak ChatGPT ya da Claude API'sini gösterir. Bu cevap, sorunun küçük bir parçasıdır. Gerçek mimari; yüklenen 10.000 PDF'in nasıl bölündüğü, hangi embedding modelinin seçildiği, vektör veritabanının indeks parametreleri, retrieval algoritmasının hybrid mi semantic mi olacağı, halüsinasyonun nasıl önleneceği ve sonuçların nasıl izleneceği gibi sorulardan oluşur.
1. Doküman Toplama (Ingestion) Katmanı
RAG sisteminin başarı oranı, hangi modeli seçtiğinizle değil, dokümanları nasıl topladığınızla başlar. Kaynaklar genelde dağınıktır: SharePoint, Google Drive, e-posta arşivleri, ERP eklentileri, scan edilmiş PDF'ler, eski Word dosyaları. Her kaynak için ayrı bir parser yazıp tek bir kanonik formata (Markdown + meta) dönüştürmek; sonraki tüm adımları kolaylaştırır.
2. Chunking Stratejisi
Dokümanı parçalama (chunking) hem retrieval kalitesini hem token maliyetini doğrudan belirler. Sabit 512-token chunk'lar genelde semantik bütünlüğü bozar. Daha iyi bir yaklaşım: önce başlık hiyerarşisine göre böl (h2/h3 sınırları), her chunk'ın başına dokümanın breadcrumb path'ini ekle, ardından uzun chunk'ları semantic similarity ile alt parçalara ayır. Hedef: her chunk kendi başına okunduğunda anlamlı olsun.
3. Embedding Modeli Seçimi
Embedding modeli; dil, doküman türü, veri yerleşimi, gecikme ve maliyet gereksinimleri birlikte değerlendirilerek seçilmelidir. Yönetilen ve açık kaynak modelleri aynı temsili sorgu kümesinde ölçün; toplu çıkarımın sağlayacağı kazanımı da kendi donanımınız ve veri boyutunuzla doğrulayın.
4. Vektör Veritabanı: Qdrant vs Pinecone vs pgvector
- pgvector: PostgreSQL kullanan ekipler için altyapı sadeliği sağlar; kapasiteyi veri boyutu ve sorgu yüküyle test edin.
- Qdrant: Açık kaynak ve şirket içinde çalıştırılabilir; filtreleme ve indeks ayarlarını gerçek veriyle ölçün.
- Pinecone: Yönetilen operasyon sunar; veri yerleşimi, sözleşme ve maliyet koşullarını ayrıca değerlendirin.
- Weaviate / Milvus: Geniş özellik seti sunar; işletim yükünü ve ekip yetkinliğini hesaba katın.
5. Hybrid Search: Vektör + Keyword
Salt semantik arama; ürün kodu, sipariş numarası veya sözleşme maddesi gibi kesin eşleşmelerde zayıf kalabilir. BM25 ve yoğun vektör aramasını birlikte deneyip sonuçları reciprocal rank fusion gibi bir yöntemle birleştirin; katkıyı temsili değerlendirme kümesinde ölçmeden varsaymayın.
6. Re-ranking Aşaması
İlk aday kümeyi bir cross-encoder (örn. Cohere Rerank veya BGE-Reranker) ile yeniden puanlayıp LLM'e gönderilecek bağlamı daraltın. Aday ve sonuç sayısı sabit bir reçete değildir; gecikme, token bütçesi ve temsili değerlendirme kümesindeki recall/precision sonucuyla ayarlanır. Yeniden sıralamayı atlamak, alakalı görünen fakat yanlış bağlam riskini artırabilir.
7. Prompt Engineering ve Citation Forcing
LLM'e yalnızca "bu dokümanlardan yararlan" demek yetmez; doğrulanabilir iddiaların hangi kaynaktan geldiğini açık referanslarla göstermesini isteyin. Kaynak gösterimi tek başına doğruluk garantisi değildir; atıfların gerçekten ilgili metni destekleyip desteklemediği ayrıca ölçülmelidir.
8. Halüsinasyon Tespiti ve Guardrails
Production'da çalışan bir RAG sistemi, kendisinin emin olmadığını kullanıcıya söylemelidir. NLI (Natural Language Inference) tabanlı bir doğrulayıcı modelle, LLM cevabının retrieval'dan gelen kaynaklarla tutarlı olup olmadığını skorlayın. Skor eşik altındaysa cevabı "yeterli kaynak bulunamadı" şeklinde reddet.
9. İzleme ve Sürekli İyileştirme
İzleme planı; veri minimizasyonu, maskeleme, erişim kontrolü ve saklama süresiyle birlikte tasarlanmalıdır. Kişisel veya gizli içeriği gereksiz yere kaydetmeden; değerlendirme skoru, anonimleştirilmiş geri bildirim ve hata sınıfı gibi ölçümler izlenebilir. RAG sistemi statik değildir; temsili test seti düzenli olarak güncellenmelidir.
Pratik sonuç, yalnız model adına bakarak seçilemez. Chunking, erişim yetkisi, retrieval, yeniden sıralama, kaynak doğrulama ve değerlendirme disiplini birlikte ele alınmalı; başarı ölçütleri proje başlamadan tanımlanmalıdır.
