Kendinden Emin Bir Cevabın Neden Cevapsızlıktan Daha Kötü Olabileceği
Şirket içi sohbet robotunuzu (chatbot) inşa etmeyi bitirdiniz. İçine sahip olduğunuz tüm İK politikalarını, mühendislik spesifikasyonlarını ve işe alım belgelerini yüklediniz. Yeni bir çalışan, müşteri yemekleri için seyahat masrafı limitini soruyor. Bot anında yanıt veriyor. Kendinden çok emin görünüyor. Belirttiği limit kişi başı 75 dolar.
Asıl politika 50 dolar diyor. Bot cevabı uydurdu. Dosyalarınızı hiç açmadı. Sadece yıllar öncesine dayanan eğitim verilerindeki kalıplardan yola çıkarak tahmin yürüttü. Ham büyük dil modellerini (LLM) özel belgelerle çalıştırmanın acı gerçeği budur. Bu modellerin şirket içi bilginize erişimi yoktur. İhtiyaç duydukları gerçekler eğitim ağırlıklarının dışında kaldığında, bilgisizliklerini itiraf etmek yerine uydururlar. Üretim aşamasında (production) bu durum artık eğlenceli olmaktan çıkar ve bir risk faktörüne dönüşür.
Retrieval-Augmented Generation (RAG) veya Geri Getirme ile Zenginleştirilmiş Üretim, tam olarak bunu çözmek için geliştirildi. Modele her şeyi hatırlamasını söylemek yerine, bilgileri araştırmasına izin verirsiniz.
Tahmin Etmekten Okumaya
Ham bir LLM'i, fotoğrafik hafızası olan ancak siz şirkete katılmadan önce ayrılmış dahi bir meslektaşınız gibi düşünün. Etkileyici metinler yazabilirler, mantık bulmacalarını çözebilirler ve kavramları basit terimlerle açıklayabilirler. Ancak onlara geçen çeyreğin API değişikliklerini sorarsanız, sadece kulağa mantıklı gelen bir şeyler uyduracaklardır. Başka seçenekleri yoktur.
RAG, o meslektaşa bir dosya dolabına erişim sağlar. Bir kullanıcı soru sorduğunda, sistem soruyu körü körüne modele fırlatmaz. Önce ilgili belgeleri getirir, bunları bağlam (context) olarak isteme (prompt) ekler ve ancak ondan sonra modelden okumasını ve yanıt vermesini ister. Model, gerçekleri hatırlama aşamasından, tam önünde duran gerçekleri anlama aşamasına geçer.
Bu akış net bir şekilde ikiye ayrılır: çevrimdışı hazırlık ve çevrimiçi yanıt.
Aşama 1: Hazırlık Aşaması (Çevrimdışı)
Henüz kimse bir soru yazmadan çok önce, karmaşık belge koleksiyonunuzu aranabilir bir bilgi tabanına dönüştürmelisiniz. Bu temel çalışma, RAG sisteminizin başarılı mı olacağını yoksa sessizce mi başarısız olacağını belirler.
Document loaders (belge yükleyiciler) başlangıç noktanızdır. Bu bağlantılar; PDF'lerden, Notion çalışma alanlarından, SharePoint klasörlerinden, web sayfalarından ve şirket içi wikilerden ham metni çeker. Gerçeklerin ilk kez can yakacağı yer burasıdır. Bir yükleyici, bir Word belgesinden temiz metin çıkarabilir ancak içinde gömülü bir metin katmanı olmayan, aslında sadece bir görüntüden ibaret olan taranmış bir PDF'de takılıp kalabilir. Yükleyici boş bir metin döndürür, veritabanınız hiçbir şey kaydetmez ve kullanıcınız daha sonra herhangi bir uyarı almadan "Bilmiyorum" yanıtıyla karşılaşır. Yükleyicilerinizin gerçekte ne çıkardığını her zaman doğrulayın. Boru hattına (pipeline) güvenmeden önce her kaynaktan birkaç belge üzerinde rastgele kontroller yapın.
Ardından, text splitting (metin bölme) veya diğer adıyla "chunking" gelir. Seksen sayfalık bir güvenlik politikasını tek parça halinde bir isteme (prompt) veremezsiniz; bağlam sınırlarını aşar ve sinyali gürültü içinde kaybedersiniz. Bunun yerine belgeleri parçalara (chunk) ayırırsınız. İşin püf noktası doğru boyutu seçmektir. Tek bir cümle gibi çok küçük parçalar genellikle kritik bağlamı kaybeder. "Tüm talepler yönetici tarafından onaylanmalıdır" ifadesini içeren bir parça, bu kuralın yalnızca uluslararası seyahatler için geçerli olduğunu belirtmeyi unutabilir. Tam bölümler gibi çok büyük parçalar ise gömlemeyi (embedding) seyreltir ve aynı anda on beş farklı konuyu kapsadıkları için geri getirme işlemini karıştırır. Uygulamada birçok ekip, cümlelerin bölünme noktasında bozulmaması için 50 token'lık bir örtüşme (overlap) ile 300 ila 500 token arası parçalarla başlar. Bunu içeriğinize göre ayarlayın. API dokümantasyonu daha küçük parçalara tolerans gösterir. Hukuki sözleşmeler ise koşullu mantığı korumak için genellikle daha büyük parçalara ihtiyaç duyar.
Parçalara ayrıldıktan sonra her bir parça bir embedding'e (gömme) dönüştürülür. Bu, metni, parçanın anlamsal anlamını temsil eden bir sayı listesi, yani bir vektör çıktı veren bir modelden geçirmek anlamına gelir. Benzer fikirler bu matematiksel alanda birbirine yakın yerlerde bulunur. "401k eşleştirme politikası" ve "emeklilik katkı payı kuralları", "401k eşleştirme politikası" ve "ofis yazıcı kurulumu"ndan daha yakın konumlanacaktır. Bu vektörler; Pinecone, Weaviate veya Chroma gibi açık kaynaklı bir alternatif olan bir vector database (vektör veritabanı) içinde saklanır. Vektör deposu sadece bir veri yığını değildir. Yaklaşık en yakın komşu araması (approximate nearest-neighbor search) için optimize edilmiş bir dizindir; bu da milyonlarca belge arasında bile en alakalı parçaları milisaniyeler içinde bulmanızı sağlar.
Aşama 2: Canlı Yol (Çevrimiçi)
When a user finally asks, "What is our travel reimbursement policy for client dinners?", the live pipeline kicks in.
The