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
Türkçe dokümanlar için OpenAI text-embedding-3-large; İngilizce + çoklu dil için Cohere multilingual ve açık kaynakta BGE-M3 üst sıralarda. Açık kaynak modelleri tercih ediliyorsa GPU üzerinde batch inference için vLLM veya Text Embeddings Inference (TEI) servisleri kurulması; tek tek API çağrısından 10x verim getirir.
4. Vektör Veritabanı: Qdrant vs Pinecone vs pgvector
- pgvector: Mevcut PostgreSQL kullanıyorsanız ek altyapı gerekmez; 1M vektöre kadar pratik.
- Qdrant: Açık kaynak, on-premise kurulabilir, payload filtreleme güçlü, 100M+ vektöre ölçeklenir.
- Pinecone: Yönetilen servis, sıfır operasyon, gigaölçek için ideal — ama veri firma dışına çıkar.
- Weaviate / Milvus: Hibrit özellikler ama operasyon yükü yüksek.
5. Hybrid Search: Vektör + Keyword
Sadece semantic vector search kullananlar; ürün kodu, sipariş numarası, sözleşme maddesi gibi keskin lexical aramalarda başarısız oluyor. Üretimde kullanışlı RAG sistemleri BM25 (keyword) + dense vector retrieval kombinasyonu kullanır; iki sonuç listesi reciprocal rank fusion ile birleştirilir. Bu tek değişiklik retrieval doğruluğunu %15-25 artırır.
6. Re-ranking Aşaması
Top-50 doküman çekildikten sonra bir cross-encoder (örn. Cohere Rerank veya BGE-Reranker) ile relevance puanlaması yapın; gerçekten alakalı olan top-5 LLM'e gönderilir. Bu adım atlandığında LLM'e "alakalı görünen ama yanlış" doküman verilir; halüsinasyon kaçınılmaz hale gelir.
7. Prompt Engineering ve Citation Forcing
LLM'e "şu dokümanlardan yararlanarak şu soruyu yanıtla" demek yetmez; her cevabın hangi chunk'tan geldiğini explicit citation olarak istemek gerekir ("Cevabın her cümlesinde [doc_id] referansı bulunsun"). Bu, hem halüsinasyonu fiilen %60 azaltır hem de kullanıcıya kaynak güvencesi verir.
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
Her sorgu için: kullanıcı, soru, retrieval sonuçları, LLM cevabı, citation skoru, kullanıcı feedback (👍/👎) — hepsi loglanır. Haftalık olarak negatif feedback alan sorgulamalar incelenir; eksik chunk varsa eklenir, prompt eksik ise iyileştirilir. RAG sistemi statik değildir — sürekli evrim gerektirir.
AIOR olarak son 18 ayda 7 farklı kurumsal RAG projesi devreye aldık. Hepsinde ortak çıkardığımız ders: model seçiminden çok mimari seçimi başarı belirliyor. Aynı GPT-4 modeli, kötü chunking + zayıf re-ranking ile kullanılınca işe yaramaz, doğru pipeline'da magic gibi çalışıyor.
