Çoğu RAG eğitimi notebook aşamasında biter. Birkaç düzgün PDF yüklerler, metni her bin karakterde bir bölerler, parçaları bir vektör veritabanına doldururlar ve buna bir mimari derler. Bir Cuma öğleden sonrasında bu demo mükemmel çalışır. Üretim ortamında (production) ise aynı boru hattı (pipeline) sessizce bir sorun kaynağına dönüşür.
Bir geri getirme (retrieval) sistemindeki asıl darboğaz nadiren model veya istemdir (prompt). Asıl mesele veri alımıdır (ingestion). Bir RAG boru hattı yalnızca beslendiği şeyi geri getirebilir ve eğer besleme gürültülü, bayat veya eksikse, model kendinden emin bir saçmalık sunacaktır. Kullanıcılar botun halüsinasyon gördüğünden şikayet ettiğinde, hata genellikle kimsenin yakından izlemediği bir veri boru hattının çok daha yukarısındadır.
Beyaz Tahta Tuzağı
Mimari diyagramlar, veri alımını "Dokümanlar → Vektör DB" şeklinde etiketlenmiş tek bir ok gibi gösterir. Gerçeklik çok daha karışıktır. Kaynak sistemler haber verilmeksizin değişir. HTML düzenleri yeniden tasarlanır. URL'ler genel açılış sayfalarına yönlendirilir. JavaScript çerçeveleri (frameworks), ilk HTTP yanıtından sonra içeriği değiştirir. Veri alımını tek seferlik bir kurulum görevi olarak görmek yapılan ilk hatadır. Bu, herhangi bir ETL boru hattı kadar titizlik gerektiren, devam eden bir veri mühendisliği problemidir.
RAG Hataları Neden Genellikle Besleme Hatalarıdır?
Şunu hayal edin: Bir kullanıcı dahili asistanınıza mevcut iade politikasını soruyor. Model, vektör deposundan en üstteki parçayı çekiyor ve 30 günlük bir süre belirtiyor. Asıl politika geçen çeyrekte 60 güne çıktı. LLM yanlış cevabı uydurmadı. Sadece kötü girdiye güvendi. Geri getirme katmanı eski bir sayfayı sundu ve embedding anlamsal olarak yeterince yakın göründüğü için model bunu doğru bilgi (ground truth) olarak kabul etti.
Bu desen sürekli tekrarlanır. Ekipler, veri kümesi (corpus) navigasyon altbilgileri (footers), yinelenen basın bültenleri ve tabloları ortadan ikiye bölen parçalarla dolu olduğunda, temperature ve top-k değerlerini ayarlamak için saatlerini harcıyor. Üretimi (generation) optimize etmeden önce, sisteminizin neleri bilmesine izin verildiğini denetleyin.
Veri Alımını Mahveden Yedi Tuzak
1. İlk Çalıştırma Bir Yalandır
İlk taramanızdaki yeşil bir onay işareti neredeyse hiçbir şey ifade etmez. Üretim verisi canlıdır. Dokümantasyon sayfaları yeniden yapılandırılır, blog kalıcı bağlantıları (permalinks) bozulur ve site haritaları (sitemaps) bölümleri sessizce düşürür. Eğer boru hattının hata vermeden tamamlandığını doğrulamakla yetiniyorsanız, kör uçuşu yapıyorsunuz demektir. Çıktıyı doğrulamanız gerekir. Beklenen dokümanların mevcut olup olmadığını, yapılarının hala ayrıştırılabilir (parse) olup olmadığını ve bir kaynak sonuçları farklı şekilde sayfalamaya (paginate) karar verdiği için toplam metin hacminin çöküp çökmediğini kontrol edin.
2. Tarama (Crawling) Veri Alımı Değildir
HTML çekmek işin kolay kısmıdır. Ham bir tarama her şeyi yakalar: çerez banner'ları, "İlgili Makaleler" yan çubukları, reklam blokları ve alt bilgi telif hakkı bildirimleri. Eğer bu ham HTML'i safça parçalara (chunking) ayırırsanız, her bir metin parçası navigasyon menüsünün fragmanlarını da beraberinde taşır. Bir kullanıcı API hız sınırlarını sorduğunda, geri getirici (retriever) %40'ı yan çubuk bağlantılarından oluşan bir parça sunabilir. Temiz çıkarma (extraction) önemlidir. Ana içerik alanını belirlemeniz, gereksiz kalıpları (boilerplate) ayıklamanız ve her sayfada tekrarlanan öğeleri kaldırmanız gerekir. Aksi takdirde bir bilgi tabanı değil, web sitesi arayüzü (chrome) için bir arama motoru inşa ediyorsunuz demektir.
3. Parçalama (Chunking) Anlamı Bozar
Sabit boyutlu parçalama, hemen hemen her hızlı başlangıç kılavuzunda varsayılan yöntemdir ve tehlikelidir. Bir dokümanı sadece karakter sayısına göre bölerseniz, tabloları ortadan ikiye keser, numaralandırılmış bir prosedürdeki 4. ve 5. adımları ayırır ve madde işaretlerini başlıklarından koparırsınız. Sadece bir fiyat tablosunun ikinci yarısını içeren bir parça anlamsal olarak işe yaramazdır. Yapı duyarlı parçalama (structure-aware chunking), orijinal formata saygı duyar. Başlık hiyerarşisini ayrıştırın. Mümkün olduğunca tabloları bütün halde tutun. Aynı H2 veya H3 altında paragraf sınırlarından bölün. Eğer yeterince kısalar ise listeleri tek bir parça içinde koruyun. Amaç eşit boyutlu bloklar oluşturmak değil, tutarlı anlam birimleri oluşturmaktır.
4. Güncellik Sorunu
Bir dahili wikinin statik bir anlık görüntüsü basit moddur. Canlı webden sürekli veri toplamak zordur. Bir sayfanın en son ne zaman toplandığını, o zamandan beri değişip değişmediğini ve bilginin ne kadar süre geçerli kalacağını bilmeniz gerekir. Bayat veri, her zaman görünürde eski bir tarih anlamına gelmez. Bazen bir sayfa metnini günceller ancak aynı URL'yi korur, bu nedenle içerik özetleme (hashing) olmadan sisteminiz bunu asla fark etmez. Kaynak değişkenliğine dayalı net yenileme kuralları oluşturun. Bir finansal veri akışı saatlik kontroller gerektirebilir. Bir şirketin "hakkımızda" sayfası ise üç aylık kontroller gerektirebilir. Özellikle alanınız, eski gerçeklerin gerçek zararlara yol açabileceği düzenlemeye tabi veya güvenlik açısından kritik rehberlik içeriyorsa, zaman damgalarını kaydedin ve yaşam süresi (time-to-live) sınırları belirleyin.
5. Yinelenen Veri Kirliliği
Web siteleri tekrarlarla doludur. Aynı ürün açıklaması kategori sayfasında, ürün sayfasında ve bir tanıtım açılış sayfasında görünür. Aynı basın bülteni /news/, /press/ ve /blog/ altında bulunur. Vektör araması otomatik olarak tekilleştirme (deduplication) yapmaz. Veritabanınızda birbirine neredeyse tıpatıp benzeyen on parça (chunk) bulunuyorsa, bunlar top-k geri çağırmanızdaki (retrieval) çeşitli ve ilgili sonuçları gölgede bırakabilir. Gömme (embedding) işleminden önce kanonik takip veya içerik tekilleştirme yapmanız gerekir. Eğer iki parça aynı şeyi söylüyorsa, yetkili kaynağı tutun ve kopyaları atın. Geri çağıırıcınızın (retriever) sınırlı kapasitesi vardır. Bunların boşa gitmesine izin vermeyin.
6. Eksik Meta Veri
Meta verisi olmayan bir vektör veritabanı, bağlam hafızası olmayan yoğun bir metin arama motorundan ibarettir. Akıllı geri çağırma, ham gömmelerin (embeddings) sağlayamayacağı filtreleme ve sıralama sinyallerine dayanır. Kaynak URL'sini, yakalama tarihini, belge kategorisini ve sürüm numarasını saklayın. Eğer API dokümantasyonu alıyorsanız, sürümleme (versioning) esastır. Bu olmadan, bir sorgu v1 ve v2 özelliklerini aynı yanıtta harmanlayabilir. Eğer İK politikalarını alıyorsanız, bölge
Veri alım sağlığını yalnızca pipeline panelleriyle ölçmeyi bırakın. Başarılı işler ve temiz loglar, temiz bir korpusun garantisi değildir. Veritabanını açın ve kullanıcılarınızın gerçekten erişeceği parçaları (chunks) okuyun. Eğer metin telif hakkı uyarıları, bölünmüş tablolar ve güncelliğini yitirmiş politika sayfalarıyla doluysa, sorununuz LLM değildir. Önce veri akışını düzeltin. Geri kalan her şey, çöpün üzerine ince ayar yapmaktan ibarettir.