Bir üretim firmasının genel müdürü, geçen ay toplantı masasına bin iki yüz sayfalık kalite prosedürü dokümanını koydu ve şunu söyledi: "Bunu kimse okumuyor. Yeni mühendis her şeyi yanındaki ustaya soruyor, usta da emekli oluyor." İsteği netti: yapay zeka bu dokümanı bilsin, sorulara buradan cevap versin. İlk cümlesi de tahmin edeceğiniz gibiydi: "Modeli bizim verilerle eğitin."
Orada durduk. Çünkü sektörün bu isteğe verdiği kabul görmüş cevap model eğitmek değil; adı RAG — Retrieval-Augmented Generation. Modeli aylarca eğitip dondurmak yerine, sorulan soruyla ilgili belgeleri o anda bulup modelin önüne koyarsınız; model cevabı sizin verinizden üretir. Öğrenciyi ezberletmek yerine sınava açık kitapla sokmak gibi düşünün — kitap güncellendikçe cevaplar da güncellenir.
Üç adımda çalışma prensibi
Mekanizma kulağa karmaşık geliyor ama omurgası üç adım. Önce belgelerinizi parçalara böler, her parçayı embedding denen sayısal bir vektöre çevirir ve bir vektör veritabanına yazarsınız; bu vektörler metnin anlamını sayılarla temsil eder. Kullanıcı soru sorduğunda soru da aynı yöntemle vektöre çevrilir ve veritabanında ona en yakın parçalar bulunur — "anlamca benzer" parçalar, kelimeleri farklı olsa bile yakalanır. Son adımda bulunan parçalar ve soru, modele "yalnızca bu kaynaklara dayanarak cevapla" talimatıyla gönderilir.
Sonuç: cevap sizin belgelerinizden geliyor, hangi dokümana dayandığı gösterilebiliyor ve belge değiştiğinde sistem yeniden eğitim istemiyor. Kurumsal tarafta denetlenebilirlik isteyenler için bu üçlü, meselenin ta kendisi.
Somutlaştırayım: kalite mühendisi "vinç operatörü sertifikası kaç yılda yenilenir?" diye soruyor. Sistem, bin iki yüz sayfanın içinden ilgili prosedürün ilgili maddesini buluyor, modele veriyor; model cevabı yazıp altına kaynağı iliştiriyor: falanca doküman, bölüm 7.3. Mühendis tek tıkla asıl maddeye gidip doğruluyor. Ustaya sormakla arasındaki fark, ustanın her zaman masasında olmaması — ve sistemin kaynağını her seferinde gösterebilmesi.
Demoyu herkes kurar, üretimi detaylar belirler
Açık konuşayım: hafta sonunda etkileyici bir RAG demosu kurmak artık marifet değil. Marifet, altı ay sonra hâlâ doğru cevap veren sistemde. Sahada pilotları üretime taşırken canımızı yakan dört detay şunlar:
- Parçalama (chunking): Belgeyi kör bir bıçakla beş yüz karakterde kesmek bağlamı öldürür; tablo ortadan bölünür, madde başlığından kopar. Başlık hiyerarşisine saygılı, örtüşmeli parçalama şart.
- Arama kalitesi: Yalnızca vektör benzerliği yetmiyor; ürün kodu, madde numarası gibi kesin ifadelerde klasik anahtar kelime araması hâlâ kral. İkisini hibrit kullanıp sonuçları yeniden sıralamak (re-rank) cevap kalitesini gözle görülür yükseltiyor.
- Yetki sızıntısı: İK dosyasına erişemeyen kullanıcı, chatbot'a sorarak içeriğini öğrenememeli. Erişim kontrolü arama katmanına inmek zorunda; en çok atlanan ve en tehlikeli konu bu.
- Güncelleme akışı: Prosedür değişti, vektörler değişmedi — sistem artık eski bilgiyi kendinden emin bir dille anlatıyor. Belge güncellenince ilgili vektörlerin de yenilenmesi otomatik bir boru hattına bağlanmalı.
Bu dördüncü madde masum görünür ama en sinsi olanıdır. Yanlış cevap veren sistemi kullanıcı affeder; güncel olmayan bilgiyi güvenle anlatan sistem ise sessizce güven kaybettirir, sonra kimse kullanmaz.
Yetki maddesini de bir vakayla açayım, çünkü "bizde öyle şey olmaz" diyen herkese aynı soruyu soruyoruz. Bir kurumda pilot sırasında test kullanıcısı, chatbot'a yönetici primleriyle ilgili bir soru sordu ve sistem, erişiminin olmaması gereken bir İK dosyasından gayet düzgün bir cevap üretti. Belgeler vektör veritabanına aktarılırken erişim etiketleri taşınmamıştı; arama katmanı herkese her şeyi buluyordu. Üretime çıkmadan yakalandı — ama yakalanmasaydı, "faydalı iç araç" bir anda veri ihlali başlığına dönüşecekti.
Fine-tuning ile yarıştırmayın, tamamlayın
"RAG mı fine-tuning mi?" sorusunu sık duyuyoruz ve soru çoğu zaman yanlış kurulmuş. Bilginiz sık değişiyorsa, kaynak göstermek önemliyse ve "model neden böyle dedi?" sorusuna cevap vermek zorundaysanız RAG doğru araç. Fine-tuning ise modele bilgi yüklemekten çok üslup, format ve alan diline alışkanlık kazandırmakta işe yarar — kurumsal yazışma tonu, belirli bir çıktı şablonu gibi. İkisi rakip değil; olgun sistemlerde yan yana da görülüyorlar. Ama başlangıç noktası neredeyse her senaryoda RAG'dir, çünkü kurulumu haftalar değil günler ölçeğindedir ve yanılınca düzeltmesi ucuzdur.
Türkçe içerikle çalışacaklara özel bir not: embedding modelinizin Türkçe ile arası iyi olmak zorunda. Çok dilli modellerin Türkçe performansı arasında ciddi fark var; yanlış seçim, "anlamca yakını bul" vaadini daha ilk adımda sakatlıyor. Biz pilotlarda birkaç embedding modelini kendi belgelerimizden ürettiğimiz soru-cevap çiftleriyle yarıştırıp öyle seçiyoruz. Yarım günlük bir kıyas, aylarca sürecek "neden alakasız parçalar geliyor?" tartışmasını kapatıyor.
Altyapı seçiminde de telaşa gerek yok. Vektör veritabanı pazarı şu sıralar hareketli ve herkes kendi ürününü tek doğru gibi anlatıyor; oysa orta ölçekli bir kurum arşivi için Postgres üzerine pgvector eklentisi gibi mütevazı bir başlangıç çoğu zaman fazlasıyla yeterli. Ölçek gerçekten büyürse özelleşmiş çözümlere geçiş yolu açık. Pilotta altyapı tartışmasına haftalar gömmek yerine cevap kalitesine odaklanmak, bizim gördüğümüz en sağlıklı öncelik sırası.
Bir de beklenti yönetimi: RAG halüsinasyonu bitirmez, ehlileştirir. Model, önüne konan parçalarda cevap yoksa boşluğu doldurmaya meyillidir; "kaynaklarda bulamadım" demeyi sisteme açıkça öğretmek ve cevapları kaynağa linkletmek gerekir. Kaynak gösteren cevap, kullanıcıya doğrulama imkânı verir — kurumsal kullanımda bu, doğruluk oranı kadar önemli.
İki haftalık pilotun anatomisi
O üretim firmasıyla nasıl ilerledik? Prosedürün en çok sorulan iki bölümünü aldık, on beş iş gününde bir pilot kurduk. Kalite ekibinden yirmi gerçek soru topladık — bizim uydurduklarımız değil, sahada gerçekten sorulanlar — ve sistemin cevaplarını uzmanlara puanlattık. İlk turda yirmi sorunun on beşi tam doğruydu; parçalama ve yeniden sıralama ayarından sonra on sekize çıktı. Kalan ikisi zaten dokümanda cevabı olmayan sorulardı; onların da "bu bilgi prosedürde yok" diye dönmesi, yanlış cevap vermesinden kıymetli.
Benimseme tarafında öğrendiğimiz ders de şu: asistanı ayrı bir uygulama olarak sunmak yerine ekibin zaten yaşadığı yere gömmek gerekiyor — kurumun kullandığı mesajlaşma aracına, intranet aramasına, sahadaki tablete. Ayrı sekmede açılması gereken en iyi asistan bile birkaç hafta sonra unutuluyor. Kullanım metriklerini baştan koyduk: kim, ne sıklıkla, hangi konularda soruyor ve hangi cevaplara "yardımcı olmadı" deniyor. Bu geri besleme, sistemin ikinci ayında birinci ayından iyi olmasının tek yolu.
Pilotun bütçesi, çoğu yöneticinin tahmininin altında çıkıyor; asıl maliyet sonradan, sistemin bakımını ve içerik güncelleme disiplinini kimse üstlenmediğinde doğuyor. Bu yüzden tekliflerimize her zaman güncelleme akışını ve sahiplik planını da yazıyoruz.
Kurum içi bilgi asistanı fikrini masanızda tartışıyorsanız bir yazın; kendi belgelerinizle iki haftada ayağa kalkan bir pilot, aylarca sürecek toplantı turundan daha çok şey öğretir.