5 milyondan fazla belge işlerken edinilen Production RAG deneyimi

• 8 ay boyunca bir RAG (arama destekli üretim) projesi yürütülürken, gerçekten etkili olan yöntemlerle zaman kaybı olan yöntemler ayırt edildi
• Başlangıçta Langchain ve Llamaindex kullanılarak prototip hızla tamamlandı, ancak gerçek kullanıcı geri bildirimlerinde performans sınırlarıyla karşılaşıldı
• Belge arama performansını iyileştiren en büyük etkenlerin sorgu üretimi, yeniden sıralama, chunking stratejisi, metadata kullanımı, sorgu yönlendirme olduğu görüldü
• Pratikte vektör veritabanı, embedding, reranking, LLM gibi bileşenler esnek biçimde seçilerek özel bir pipeline kuruldu
• Tüm deneyim ve birikim açık kaynak proje agentset-ai/agentset içinde bir araya getirilerek paylaşıldı

---

8 aylık Production RAG kurulum deneyiminin özeti

• Toplam 9 milyon sayfa (Usul AI), 4 milyon sayfa (isimsiz bir hukuk yapay zeka şirketi) gibi büyük veri setlerinde RAG sistemleri kurma ve işletme deneyimi paylaşılıyor
• Başlangıçta YouTube eğitimlerini takip ederek Langchain'den Llamaindex'e geçilip birkaç gün içinde prototip tamamlandı, ancak gerçek dağıtımda yalnızca kullanıcıların fark edebileceği düşük performans sorunu ortaya çıktı
• Birkaç ay boyunca sistem bileşenleri parça parça düzeltilerek en iyi performansa ulaşıldı

Performans iyileştirmesine gerçekten katkı sağlayan unsurlar (ROI sırasına göre)

1. Sorgu Üretimi (Query Generation)

   • Kullanıcının son sorgusu tüm bağlamı taşıyamadığı için, LLM ile konuşma içeriği incelenip anlamsal sorgular ve birden fazla anahtar kelime sorgusu üretiliyor
   • Bu sorgular paralel işlenip yeniden sıralayıcıya verilerek arama kapsamını genişletme ve hibrit aramadaki önyargıyı telafi etme etkisi elde ediliyor

2. Yeniden Sıralama (Reranking)

   • Yaklaşık 5 satır kodla uygulanabilen yeniden sıralamanın performansa etkisi hayal edilenden çok daha büyük
   • Çok sayıda chunk girdisi (ör. 50 adet) içinden üst sıralardaki bazı chunk'ların (ör. 15 adet) yeniden sıralanıp seçilmesi en yüksek ROI'yi sağlıyor
   • Yalnızca yeniden sıralama bile, tasarımı zayıf bir pipeline'ın eksiklerini önemli ölçüde telafi edebiliyor

3. Chunking Stratejisi (Chunking Strategy)

   • Tüm geliştirme sürecinde en çok zaman alan bölüm
   • Veri yapısı ve kalıpların doğru anlaşılması, mantıksal birimler halinde chunking yapılması ve metin ya da cümlelerin ortadan bölünmediğinin elle denetlenmesi gerekiyor
   • Her chunk'ın kendi başına anlamını koruması gerekiyor

4. LLM girdisinde metadata kullanımı

   • LLM'e yalnızca basit chunk metni gönderilmiyor, metadata (title, author vb.) da eklenerek bağlam ve yanıt kalitesi büyük ölçüde iyileştiriliyor

5. Sorgu Yönlendirme (Query Routing)

   • RAG ile yanıtlanamayacak türler için (ör. makale özeti, yazar bilgisi talebi vb.) hafif bir yönlendirici eklenip ilgili sorgular API+LLM işleme yoluna ayrılıyor

Kullanılan stack

• Vektör veritabanı: Azure → Pinecone → Turbopuffer (ucuz ve varsayılan olarak anahtar kelime aramayı destekliyor)
• Belge çıkarma: özel yöntem kullanıldı
• Chunking aracı: temel olarak Unstructured.io, kurumsal pipeline için özel çözüm kullanıldı (Chonkie hakkında da olumlu görüş var)
• Embedding modeli: text-embedding-large-3 kullanıldı (başka modeller test edilmedi)
• Yeniden sıralayıcı: None → Cohere 3.5 → Zerank (çok yaygın değil ama pratikte oldukça iyi)
• LLM: GPT 4.1 → GPT 5 → GPT 4.1 (çoğunlukla Azure kredileri kullanıldı)

Açık kaynak olarak yayınlanması ve sonuç

• Tüm öğrenimler ve sahadaki deneyim açık kaynak proje agentset-ai/agentset ile somutlaştırıldı
• MIT lisansı ile yayınlandı; serbestçe kullanılabilir ve iletişime geçilebilir

[GN⁺]

Hacker News yorumu

• Sentetik sorgu üretiminden bahsedilen kısmın gerçekten önemli olduğu hissediliyor; çünkü gerçek kullanıcılar sorguları çoğu zaman çok belirsiz giriyor. Bu yüzden başta LLM sentetik sorgular üretiyor. Ancak her seferinde üretilen sentetik sorguya göre sonuç sapması büyüdüğü için, tek bir LLM çağrısıyla sorgunun üç farklı versiyonunu çeşitlendirerek üretmek, bunları paralel aratmak ve ardından reciprocal rank fusion ile güçlü bir sonuç listesi birleştirmek kullanılıyor. Arama tarafında hybrid dense + sparse bm25 tercih ediliyor; çünkü yalnızca dense, uzmanlık terimlerinde zayıf kalıyor. Buna bir de reranker eklenince aramayla ilgili sorunların çoğu çözülüyor
  • Dense modelin teknik terimlerde zayıf kalmasını telafi etmek için hybrid yaklaşım (bm25 + dense search) kullanılmasını ilgi çekici buluyorum. SPLADE gibi anlamsal ve sözcüksel arama dengesini iyi kuran v3 modellerinin performansı da iyi görünüyor, ama bunun daha basit bir çözümle ikame edilip edilemeyeceğini hep merak ediyorum
  • Bu tür ayrıntılı sorgu üretimi/optimizasyonunun sonuçta Amazon, Microsoft, OpenAI gibi RAG çözümü sağlayıcılarının ilgilenmesi gereken bir alan olduğu vurgulanıyor
  • Bu yöntemlerin şu an için best practice olduğu doğru, ancak performansı bir kademe daha yukarı taşıyabilecek ek stratejilerde (embedding modeline seçici dallanma, çeşitli re-ranker kombinasyonları vb.) hâlâ eksik bir şey varmış gibi bir boşluk hissediliyor
  • Son ipucu olarak, LLM’in kullanıcının arama niyetini nasıl yorumladığını sonuçlarla birlikte kullanıcıya göstermek öneriliyor; böylece kullanıcı, LLM’in doğru anlayıp anlamadığını doğrudan kontrol edebiliyor
• Self-hosted seçeneği konusunda kafa karışıklığı hissediliyor. İlgili belgelerde en az 6 üçüncü taraf servis hesabı gerektiği yazıyor; bunun gerçek anlamda self-hosted kavramından çok uzak olduğu belirtiliyor
  • İlgili kodun kendisinin doğrudan self-host edilebildiği açıklanıyor. “Self-hosted” terimi için net bir resmî standart olmadığı düşünülüyor. Örneğin bir self-hosted serviste offsite backup özelliği varsa, bu onun self-hosted olmadığı anlamına gelmez; yalnızca iyi tasarlanmış bir hizmet olduğu anlamına gelir
  • Bu tür self-hosted pazarlaması doğal sayılabilir, çünkü şirketin asıl iş modeli barındırılan sürümü satmak üzerine kurulu; bu yüzden tamamen bağımsız bir self-hosted ürünü zorunlu olarak sunmaları gerekmiyor
  • Kısıtlı ağ ortamlarında çalışma deneyimi paylaşılıyor. Son 20 yıldır tamamen izole iç ağ ortamlarında çalışıldığı için son teknoloji dalgalarının çoğunun kaçırılmış olabileceği düşünülüyor. YouTube da otomobil tamiri dışında neredeyse hiç izlenmiyor; çevrimiçi bağlantıyı zorunlu kılan teknoloji trendlerine karşı biraz mesafeli olunuyor
  • Kişi, açık kaynak sürümü çok memnuniyetle kullandığını söylüyor; barındırma bağımlılığı istenmiyorsa her şeyi doğrudan Rust ile yazmanın da pratik bir yaklaşım olduğu görüşünde
• Büyük LLM tabanlı reranker’ların (Qwen3-reranker vb.) eskiden beri cross-encoder’da beklenen performansı verdiği, bu yüzden mutlaka denenmesi gerektiği söyleniyor. Ancak hesaplama maliyeti oldukça yüksek. Ayrıca metadata/tablo bilgisi insanlar için fazla temel ve açık görünse de metin chunk’larında tekrar edilmediğinden, bunu LLM girdisine enjekte etmek modelin çok daha “akıllı” görünmesini sağlıyor. Yalnız basit RAG ile iyi ele alınamayan karmaşık sorgulara (ör. en güncel 20 belgenin özeti gibi) dikkat etmek gerekiyor. Bu yüzden UI aramaya odaklanacak şekilde tutulup chat UX azaltılıyor ve modelin gerçekten gördüğü bilgiler kullanıcıya da gösteriliyor
  • Kullanıcı açısından LLM’in context işleme yapısını doğru biçimde anlatmanın çok zor olduğu görüşüne tamamen katılınıyor. Chat UX’in dışına çıkan açık örnekler az; büyük şirketlerin bunu deneyip bırakmasının nedeni gerçekten “sonuç alamamaları” mı, buna dair kuşku da var. Gerçekte büyük ölçekli tüketici uygulamalarında context/akıl yürütme maliyeti ana gider kalemlerinden biri olduğu için bunun yönetilmesi gerekiyor; bu nedenle context explicit UI göz ardı edilmiş olabilir. Buna karşılık şirket içi RAG sistemlerinde maliyet baskısı daha düşük olduğundan, deneyimsel olarak sonuç kalitesine ve çalışan zamanından tasarrufa çok daha fazla odaklanıldığı hissediliyor
  • Teknik optimizasyonlar önemli olsa da, bunun müşterinin gerçek iş verimliliğini ne kadar artırdığına dair daha fazla gerçek kullanım örneği görmek isteniyor; aksi hâlde bu sadece bir başka teknoloji modası olarak kalabilir
• Milyonlarca sayfanın (özellikle teknik dokümanların) RAG ile işlenmesi konusunda 1,5 yıl önce yazılmış bir derleme paylaşılmış: https://jakobs.dev/learnings-ingesting-millions-pages-rag-azure/
  • Teknik arama için bir RAG sistemi geçen yıl da kurulmuştu; şimdi dönüp bakınca birçok kısmın neredeyse aynı olduğu hissediliyor
• Bu tür RAG sistemlerini kurmak veya benimsemek isteyen biri açısından, dokümanları Google Workspace klasörlerine API ile yükleyip Google AI search API ile aratmanın pratik bir mimari olup olmayacağı merak ediliyor; örneğin kullanıcı bazında farklı klasörlere ayırmak gibi. Ya da bunun Azure tarafında benzer şekilde gerçekleştirilip gerçekleştirilemeyeceği düşünülüyor
• Embedding sürümlemesinin nasıl yapıldığı merak ediliyor. Veri güncellemeleri, belirli bir sürümü göstermek ya da tarihe göre filtrelemek gerektiğinde ne yapılacağı soruluyor; hatta chunk’ın başına context sürümünü ekleme fikri de düşünülüyor
  • Vektör deposunda özgün metin ve metadata’nın (sürüm bilgisi dâhil) birlikte tutulması yeterli. Örneğin turbopuffer’da attribute filtering kolay olduğu belirtilerek doküman bağlantısı paylaşılıyor
  • Sorunun kendisinin oldukça faydalı ve önemli bir soru olduğu düşünülüyor
• Kullanılan LLM sürüm sırasının GPT 4.1 → GPT 5 → tekrar GPT 4.1 olmasının ve stack içindeki diğer bileşen sürümleriyle (ör. text-embedding-large-3) uyumsuz görünmesinin garip olduğu hissediliyor
  • OP yanıtı: GPT-5 çıkar çıkmaz denendi, ancak çok fazla context (100 bin tokene kadar) girildiğinde GPT-4.1’den daha kötü performans verdiği için tekrar 4.1’e dönüldü. Özellikle a) instruction following zayıftı ve system prompt’u iyi izlemiyordu, b) yanıtlar fazla uzun olup UX’e ciddi zarar veriyordu, c) 125 bin token context window sınırı nedeniyle çok büyük girdiler hata üretiyordu. Bu sorunlar, “RAG” içinde çok sayıda chunk verildiğinde daha belirginleşti; daha genel görevlerde GPT-5 daha iyi olabilir
• AWS savunucusu değilim ama S3 Vectors’ın şu anda bu alanda state-of-the-art olduğu vurgulanıyor. Buna Bedrock Knowledge Base de bağlanırsa Discovery/Rebalance çok kolaylaşacağı için piyasadaki en basit çözüm olabilir; yakında resmî olarak çıktığında rakiplerin çoğunu geride bırakacağı düşünülüyor
  • Şakacı biçimde “schlep” değil “shill” kelimesinin doğru olduğu şeklinde bir düzeltme yapılıyor
  • S3 Vectors’ın neden SOTA olduğu merak ediliyor; sonuçta bunun da yalnızca bir vektör deposu olup olmadığı sorgulanıyor
• Embedding tabanlı RAG’in pratikte her zaman en iyi yöntem olmadığı söyleniyor. Tek bir görev ya da demo için iyi olsa da gerçek dünyada sık sık sınırlarına çarpıldığı deneyimleniyor
  • Bunun mutlaka böyle olmadığına dair deneyim de paylaşılıyor. Üzerinde çalışılan Honeycomb ürünü Query Assistant blogu da 2023’ten beri veri sorgulama temelli çalışıyordu ve bu özelliğin çok sade bir amaca göre tasarlanmış olması nedeniyle LLM tabanlı ürünler için aslında ideal yönü gösterdiği düşünülüyor. Non-LLM işleme ile birleştirmenin iyi olduğu belirtiliyor
  • RAG sürekli farklı biçimlerde yeniden yorumlanıyor ve kullanım alanı çok geniş. Biz RAG’i agentic search içinde bir araç olarak entegre ettik; aynı anda gerçek zamanlı kaynak aramasıyla klasik chunk yaklaşımını da karıştırıyoruz. Yakında gelecek büyük context window’lar sayesinde tek bir istekte tüm dokümanı vermek de mümkün olabilir
  • Hangi alternatifin önerildiği soruluyor; bunun sorgu üretim yöntemini mi kastettiği soruluyor
  • ChatGPT örneğinde de güncel bilgiye ulaşmak için RAG’in etkili olduğu, bu pratik faydanın bugün tüm büyük sağlayıcıların bunu sunmasının nedeni olduğu vurgulanıyor
  • Neye kıyasla söylendiğinin netleştirilmesi isteniyor
• Chunk seçme stratejisine çok zaman ve emek harcandığı söylenmişti; kullanılan somut stratejiler hakkında daha ayrıntılı bilgi duymak isteniyor