İçeriğe geç
edumintsBlog
LLM2 dk okuma

Belgeler Sadece Parça Yığınları Değildir

Kaynak: dev.to

Paylaş
İçindekiler 7 başlık

Bilgi getirim (retrieval) sistemleriyle ilgili rahatsız edici bir gerçek var: Belgeleri daha anlamaya çalışmadan önce onları parçalayarak yok ediyorlar. Bir teknik dökümanı her 500 kelimede bir makasla kestiğinizi düşünün. Başlıklar, bölümler veya düşünce bütünlüğü önemsenmeden yapılan bu işlem, RAG (Retrieval-Augmented Generation) sistemlerinde sıkça karşımıza çıkar.

Yanlış Soruyu Soruyoruz#

RAG tartışmalarında en çok "Optimal parça (chunk) boyutu nedir?" sorusu sorulur. Ancak asıl soru, belgeleri nasıl böleceğimiz değil, her belgenin aynı şekilde bölünmesinin doğru olup olmadığıdır.

  • Öğrenme Çıkarımı: Yeni bir konuyu öğrenirken bilgiyi rastgele zaman dilimlerine bölmek yerine, mantıksal kavram bütünlüğüne göre gruplandırarak çalışmalıyız.

Bu Belgeyi Hayal Edin#

"Hız Sınırlama Stratejisi" adında, dört bölümden oluşan teknik bir belge düşünün: neden var olduğu, algoritma, kod örneği ve istisnalar. Sabit boyutlu bölme işlemi uygulandığında başlık bir parçada, kod örneği diğerinde, istisnalar ise bambaşka bir parçada kalır. Metin korunur ancak anlamsal bütünlük kaybolur.

Bilgi Getirimi Mükemmel Çalışıyor#

Bir kullanıcı "Hız sınırı aşıldığında ne olur?" diye sorduğunda, sistem kodun olduğu parçayı getirir. Matematiksel olarak benzerlik yüksektir, ancak kodun arkasındaki nedenler ve istisnalar eksiktir. Model kodun ne yaptığını açıklayabilir ama neden öyle davrandığını açıklayamaz.

  • Pratik Çıkarım: Yazılım geliştirirken sadece kodu değil, kararların arkasındaki mantığı (ADR) da belgelemeli ve bu bağlamı kodla bir arada tutmalıyız.

Yapı Anlambilimdir#

Belge yapısı (başlıklar, listeler, bölümler) sadece görsel birer süs değildir; bilginin kendisidir. Başlıklar fikirlerin sınırını çizer, listeler birlikte anlaşılması gereken maddeleri gösterir. Bu yapısal işaretler kaybolduğunda, anlam da kaybolur.

Anlamın Sabit Bir Boyutu Yoktur#

Sormamız gereken soru "Bu belgeyi nasıl bölmeliyim?" değil, "Kendi başına anlam ifade eden en küçük birim nedir?" olmalıdır. Bu bazen bir paragraf, bazen bir API referans tablosu veya mimari karar dökümanıdır.

  • Yazılım Geliştirme Çıkarımı: RAG projelerinde sabit karakterli bölme yerine, Markdown veya HTML ayrıştırıcıları kullanarak başlık hiyerarşisine dayalı semantik bölme yöntemleri uygulanmalıdır.

Bilgi Getirildi Ama Anlama Başarısız Oldu#

Arama motoru ilgili metni bulur ve yapay zeka modeli bunu açıklar. Ancak gerçek cevap hala eksiktir. Bu başarısızlığın sebebi arama algoritması değil, belgenin daha en başta parçalanarak anlam bütünlüğünün bozulmuş olmasıdır.

Belge Bir Argümandır#

Belgeler sadece peş peşe gelen kelimeler değildir; yazarın inşa ettiği bir düşünce akışıdır. Bu yapıyı bozup rastgele parçalarsak, modellerin bunu sonradan birleştirmesini bekleyemeyiz. Belgeler token dizileri değil, görünür kılınmış birer argümandır.

Orijinal makaleye buradan ulaşabilirsiniz.

Kaynak ve atıf

Bu yazı, dev.to üzerinde yayımlanan içerikten yararlanılarak Edumints tarafından yapay zekâ desteğiyle Türkçe hazırlandı. Ayrıntılar ve yazarların kendi anlatımı için orijinaline bakabilirsin:

  • dev.to/valerykot/documents-arent-bags-of-chunks-3cha