Codecast#59 - RAG ile Kurumsal Bilgiye Erişim: Bankada Doğru Cevap Üretmenin Mühendisliği

Ahmet Hoşgör:

Herkese merhabalar. Coderspace'in podcast serilerinden Codecast ile karşınızdayız. Bir süre ara vermiştik. Çok da keyifli bir konuyla bugün birlikteyiz. Ben Ahmet, Coderspace'in kurucu ortağı.

Bugün Alperen bizlerle. Burgan Bank'ta AI Engineer olarak çalışıyor, Alperen Çelik. Hoş geldin Alperen

Alperen Çelik:

Hoş bulduk.

Ahmet Hoşgör:

Nasılsın, iyi misin? Her şey yolunda mı?

Alperen Çelik:

Harikayım Ahmet. Sen nasılsın?

Ahmet Hoşgör:

İyiyim ben de. Aslında birazcık tabi Codecast'in 4.-5. senesine girerken bu sene biraz daha AI'a biz de odaklanmayı istiyorduk. Sizden de böyle bir talep gelince çok sevindik. Bugün aslında Retrieval-Augmented Generation -RAG diye de isimlendiriliyor- ile kurumsal bilgiye erişip bankada doğru cevap üretmenin mühendisliği dedik başlığa. Bazıları için biraz yabancı gelebilir. Yabancı gelenler de bence dinlediğinde "A evet, ben burada neden bahsedildiğini anlıyorum" diyeceklerdir. Çok da uzak bir konu değil, Chat gptler vs. sağ olsun, herkese. Ama tabii ki teknik arkadaşlar da bizi çok yoğun dinliyor. Onlar zaten işin teknik kısmını merak edecektir. Ben oralara girmeden önce birazcık seni dinlemek isterim. Senin kısa yaşam öykün, kariyer gelişimin, neden bu alana yöneldin? Hem bu alanda çalışıyorsun hem çünkü yüksek lisans da yapıyorsun. Seni tanıyarak başlayabiliriz.

Alperen Çelik:

Tamamdır. Selamlar herkese, ben Alperen. Kocatepe Üniversitesi Mekatronik Mühendisliği lisans çıkışlıyım. Şu anda da Uludağ üniversitesi'nde yapay zeka alanında yüksek lisanslı eğitime devam ediyorum. Aynı zamanda Burgan Bank'ta AI Enginer olarak çalışıyorum. AI ile tanışmam çok erken zamanlara tekabül ediyor. Yaklaşık olarak yedi yıl önce hazırlık ingilizce hazırlık sınıfındayken Kaggle platformuyla tanışma fırsatım oldu ve orada Machine Learning modelleri, farklı veriler, onların manipülasyonları, gelecek tahminleri gibi konuları görünce çok heyecanlandım ve bunu bizim geleceğimizi değiştirecek bir teknoloji olabileceğine aslında inandım ve o andan itibaren kendimi AI alanında geliştirmeye başladım diyebilirim. Zaten mekatronik mühendisliği aslında üç temel disiplinin birleşimi olarak adlandırılıyor: makine, elektronik ve yazılım alanı. Ben de seçtiğim derslerle birlikte hep kendimi yazılım alanında geliştirdim. Çeşitli yarışmalara katıldım Teknofest gibi, Huawei gibi, BTK Akademi gibi birçok yarışmada teorik bilgilerimi pratiğe de döktüm diyebilirim. Sonrasında University of malta'da bir AI Researcher'lık yani staj programı gibi bir fırsatım oldu. Orada global bir takımla birlikte uluslararası arenada özellikle sahillerdeki pet şişelerin tespitine yönelik bir drone çalışması vardı. Orada computer vision alanında çalışmalarda bulundum. Daha sonra, Türkiye'ye döndükten sonra, Bilişim Vadisi'nde bulunan bir teknoloji şirketinde AI Enginer rolüyle iş hayatına başladım diyebilirim. Daha sonrasında -tabii ki burada yapay zeka alanı çok geniş bir alan, computer vision var, NLP tarafı var, Machine Learning tarafı var - ve bunların her birine aslında dokunmak gerçekten çok büyük bir avantaj olduğunu söyleyebilirim. Benim de gerçek hayatta çalışan birçok üründe katkım olduğunu söyleyebilirim. Aynı zamanda hobisel olarak da robotik tarafta ev hobi uğraşı olarak kendimi geliştirmeye devam ediyorum diyebilirim.

Ahmet Hoşgör:

Süper. Evet aslında böyle az zamanda birçok iş yapmışsın. Hem üniversiteyle de çok yoğun ilgilenmişsin ama tabi Burgan Bank'ta da sana bu alanda alan açılmış gibi hissettim ben, hem öncesinde yaptığımız konuşmalardan hem CV'ye, LinkedIn'ine bakınca birçok iş yapmışsınız çünkü. Burada Burgan Bank'ın teknoloji ekiplerinin vizyonu ne? Yapılan işler, içerideki ekip yapısı... Ben bunu iki üç yıl önce sorarken daha farklı hissediyorum ama şu anda özellikle AI, LLM'ler ve acayip bir dönüşümün içerisinde olduğumuz için böyle zamanın hızlı aktığı, zamanın tekerinin hızlandığı dönemlerde olduğumuz için bunun içerisinde Burgan Bank'ı nasıl görüyorsun, onu da sormak isterim.

Alperen Çelik:

Tamamdır. Ya Burgan Bank'ı anlatırken hep şu aklıma geliyor benim, şunu söylüyorum, içeride hem o köklü kurumsal yapının güveni var hem de bir startup'ın o bitmek bilmeyen enerjisi ve çevikliğini size bir arada sunuyor. Bu muazzam bir durum aslında. Aynı zamanda çok yetkin insanların liyakat ile banka bünyesine alınmasından dolayı oldukça kültürel olarak zengin bir ortam sunuyor bizlere.

Yapay zeka ekibimizden bahsedecek olursam, biz on kişiyi aşmayan bir ekibiz aslında. Ama ekipte herkesin farklı alanında uzmanlıkları var. Fakat yöneticimizin vizyonu sayesinde ekip içinde bir kolektif zihin oluşturmanın peşindeyiz her zaman. Yani bir kişi bir şeyden sorumlu mantığıyla değil de herkes yapılan işi anlamalı. Anında kalınan yerden devam edebilmeli, bu kavrayışa sahip olmalı düşüncesindeyiz. Bu bizi inanılmaz çevik yapıyor. Kişiye bağımlılığı azaltıyor. Ekip içi iletişimimizin üst düzey olması sayesinde açık yüreklilikle birbirlerimize feedback verebiliyoruz, bir hatada direkt kendisiyle konuşabiliyoruz veya bir karar alınmasında direkt etken rol oynayabiliyoruz. Zaten bu yapının mükemmelliği sayesinde bizim üç katımız büyüklüğündeki ekiplerin ancak yapabileceği iş sayısındaki işleri yapabiliyoruz diyebilirim.

Yaptığımız projelerden biraz da bahsedeyim. Örnek verecek olursam bizim projelerimizin genelde tek bir sorunu çözen projeler olmuyor. Daha çok bir altyapı yapma üstüne duruyoruz. Birden fazla düğümü çözen, aynı ürünü birçok birimin kullanabileceği sistemler oluşturmanın peşindeyiz. Örneğin bir chatbot yaptık şimdiye kadar. Mesela ON asistan adında bu, vatandaşlarımız web sitemiz üzerinden erişebiliyor. Yakın zamanda mobile de gelecek. Yaptığımız bu chatbot altyapısı yalnızca bir backend olarak düşünmememiz gerekiyor. Aynı zamanda bu chatbotu besleyeceğimiz kapsamlı CMS bir uygulamamız var. Biz buna içeride chatbot seed diyoruz. Bu uygulama sayesinde bilgi ekleme, config ayarlama, raporlama, test yapma, kullanıcıların flow tasarımı gibi birçok özelliği aynı bir uygulamadan kontrol etmesini sağlıyoruz.

Bu Frontend ve Backend sistemi sayesinde iç iş birimlerimizde bir ekip kendi bilgileri ile chatbot yapmak istemesi durumunda, onlara yeni bir chatbot vermemiz teknik olarak sadece dakikalarımızı alıyor diyebilirim. Daha sonra onlar bu CMS ekranımızdaki kendi verilerini, dökumanlarını, web sitelerini belirterek flip flowlarını tasarlayarak anında kendi chatbotlarını yapması mümkün oluyor.

Bunların hepsi bir üründe toplanması ve bir ID, bir API Call ile ulaşabilmesi muazzam bir esneklik sağlıyor. Şu anda bu altyapısı sayesinde onlarca farklı chatbot içeride yapılabiliyor.

Bunun gibi birçok ürünümüz var aslında. Mesela doküman understanding tarafında ya da kurum içi dokümanların arşivlenmesi, kimlik vb. ürünlerin doğrulanması, otomatik template atanması gibi daha aklıma gelmeyen birçok ürünü içeride yapmış durumdayız.

Aynı zamanda agentic yapıların her birim tarafından kendi domaini ile birleştirilip ürünlere dönüşmesi için çok sayıda kurum içi eğitim veriyoruz ve kullandığımız toolları ekip arkadaşlarımızla ve bütün banka çalışanlarıyla sürekli paylaşıp onların da kendi domainleriyle birleştirip uygulama yapmalarını teşvik ediyoruz diyebiliriz.

Ahmet Hoşgör:

Süper. Aslında konunun başlığını verirken RAG ile Kurumsal Bilgiye Erişim: Bankada Doğru Cevap Üretmenin Mühendisliği demiştik.

Burada benim iki sorum var, çok temel: RAG dediğimiz Retrieval-Augmented Generation nedir ve aslında bankada doğru cevap ne demek? Buradan bence başlayıp böyle derinlere inebiliriz.

Alperen Çelik:

Harika bir soru. Bankacılık sektöründe doğru cevaptan daha önemli bir kavram var aslında, o da yanlış cevap vermemek.

Bu aslında cevap vermemenin de doğru cevap sayılabileceği anlamına geliyor bir yerde. Bir chatbot'u ele alalım mesela, bankacılıkta bu chatbotun asla yanıltıcı bilgi vermesini istemeyiz. Bu yüzden hem cevap üretilmeden önce hem de üretildikten sonra mutlaka cevabı değerlendirmemiz gerekmekte.

Aynı şekilde doğru cevap yerine yanlış cevap için birçok kriterimiz var. Bunların başında bir mesaj küfür, hakaret, vs. içermemeli. Mesela bir şirket veya ürün ismi içermemeli, yatırım tavsiyesi kesinlikle vermemeli. Halüsinasyon dediğimiz yani uydurma bilgi vermemeli veya özellikle matematiksel hesaplamalardan kaçınmalı ve vereceği oranlar konusunda çok temkinli olmalı ki bankayı zan altında bırakmasın gibi çok çeşitli kurallarımız mevcut aslında doğru cevap kriterlerimizde. Bu gibi durumlarda cevap vermek yerine fall back adını verdiğimiz yönlendirici ve mesaj vermesi genelde daha sağlıklı oluyor.

Bunların dışında kalan cevaplar doğru cevap olarak tanımlayabiliriz.

Ahmet Hoşgör:

Güzel. Burada peki kurumsal bilgi nerede yaşıyor? Yani bir sürü farklı bilgi var. Sizin burayı beslemeniz gerekiyor tabii ki. Bir de klasik bir arama niye yetmiyor?

Hani bu ikisini merak ediyorum aslında.

Alperen Çelik:

Burada bahsettiğimiz klasik arama aslında Full-Text Search veya Fuzzy Search olarak adlandırabiliriz teknik olarak. Bu search yöntemlerinin en büyük avantajı hız. Gerçekten muazzam hızda search yapabiliyorlar fakat doğruluk da bir o kadar düşüyor. Neden. Örneğin bir chatbotun gard mekanizmasını yapıyor olalım. Amacımız hakaret ve kötü söylemleri tespit etmek olsun. Bunun için mesajdaki her bir kelime grubuna bakmamız gerekiyor ve Fuzzy Search veya Full-Text search ile yapmak istersek eğer biz bunu aklımıza gelebilecek tüm hakaret ve benzeri kelime ve cümle öbeklerini bir yere yazmamız, listelememiz gerekiyor. Daha sonra her bir kullanıcının cümlesindeki kelimeyi bu listedeki kelimelerle karşılaştırmamız gerekiyor.

Bu search yöntemi ne kadar hızlı olsa da başarım oranı istendiği gibi gelmeyecektir. Bir de hız konusunda kullanıcının yazdığı metin uzadıkça hız avantajını da kaybedecektir.

Fakat bizim daha çok odaklanmamız gereken nokta, başarı oranı. Çünkü bir harfin yanlış yazılması veya bir kelimenin sonuna ek getirilmesi veya aklımıza gelmeyen yöresel bir hakaret sözcüğü gibi gerçek dünya verileri karşısında birebir eşleme istediğimiz başarıyı sağlamayacaktır. Burada devreye aslında RAG’ın da kalbinde yer alan semantik search mantığı geliyor. Dilerseniz buradan RAG mimarisine giriş de yapabiliriz.

Ahmet Hoşgör:

Evet iyi olur aslında. Hani eski sistem, o klasik arama niye çalışmıyordu, onu anlamış olduk. Çok mümkün olmuyor, o kadar sınırsız bir bilgiyi yorumlamak. RAG’ı dinlemek bence çok iyi olur. Ben de merak ediyorum, dinleyiciler de, bir kısmı merak ediyordur, bir kısmı da üstüne ek teknik sorular da soracağım, onları da merak ediyorlardır. Senden dinlemek bence süper olacak.

Alperen Çelik:

Harika. O zaman tanımlamayla başlayalım isterseni. Retrieval-Augmented Generation kelimesinden oluşuyor aslında RAG. Türkçe olarak arama ile güçlendirilmiş üretim şeklinde çevriliyor. Bir metafor olarak şöyle düşünebiliriz: kabaca bizim bilgilerimizi toplayıp bir kütüphane kurduğumuzu düşünelim. Doğru cevabı almak için kütüphaneciye “Ya şu bilgileri içeren kaynaklar neler?” diye sorduğumuzu düşünelim. Kütüphanecinin bizim sorumuza benzeyen cümleler içeren kaynakları tek tek kitaplardan bulup getirmesine aslında biz RAG diyoruz.

Peki neden RAG’a ihtiyacımız var? Biraz da buna bakalım. Bir LLM modeli, dünyada insanlık tarafından üretilmiş verileri alarak o verileri bir taklitçi gibi taklit etmeyi öğrenen bir matematiksel model olarak düşünebiliriz aslında. Bu modellerin amacı bir önceki bağlama bakarak sonraki kelimelerin istatiksel olarak en yüksek ihtimalle hangisi olması gerektiğini tahmin etmek.

Bir tane base model aldığımızı düşünelim. Bu modelle “faizler yüzde kaç” diye sorduğumuzu düşünecek olursak bize vereceği cevap muhtemelen Citybank'ın veya Garanti Bankası gibi küresel, çok daha büyük bankaların faiz oranları olacaktır. Fakat biz özellikle Burgan Bank'ın faiz oranları nedir diye sorsak dahi en iyi ihtimalle halüsinasyon görmeden bir cevap üretilecektir fakat her seferinde doğru cevap üretmesi çok mümkün olmayacak. Bunun nedeni model yalnızca eğitilirken toplanan datanın içindeki bilgilerle eğitilmiş olması aslında ve hangi kaynak daha çok geçiyorsa onu daha çok hatırlamasıdır diye düşünebiliriz.

Aslında burada hatırlama kelimesi tam karşılık değil ama öyle düşünebiliriz. Yani burada kütüphanecimizin LLM olduğunu düşünürsek biz bir soru sorduğumuz zaman en eski tozlu parşömenler yerine eline ilk gelen ansiklopediden bilgiyi getirmesi gibi düşünebiliriz bir base model LLM’i. Bu durumun önüne geçmek için temelde iki yöntemle ilerleyebiliyoruz. Birincisi fine tuning, ikincisi RAG yöntemi. Fine tuning yöntemi -çok kısaca burada da bahsetmiş olayım- daha önce büyük verilerle eğitilen bir base modeli alıp, kurumumuza ait verilen bütün verileri bir araya getirip instruct data setleri oluşturup post-training yapmak, yani tekrardan bu modeli eğitmek. Bir nevi LLM’e şunu diyoruz: eski bilgilerini ya da ağırlıklarını unutma ama bu yeni bilgiler daha öncelikli”. Bu sayede bir soru sorduğumuzda kurumumuzla ilgili bilgi almamız biraz daha mümkün oluyor fine tuning yönteminde. Fakat fine tuning yapmanın büyük bir dezavantajı var. Eğer değişken verilerle çalışıyorsak -ki örnek olarak faiz bilgisini sorduğumuzu tekrardan düşünelim- faiz bilgisi değiştiği takdirde bizim tekrardan modeli sıfırdan eğitmemiz gerekiyor. Bu da bileceğiniz üzere çok fazla dezavantaj içeriyor. Hem zaman hem maddi açıdan. Bunun yerine biz daha çok RAG yöntemlerini kullanıyoruz, eğer problemimiz değişken verilerden oluşuyorsa. Temel bir RAG mimarisi şu şekilde çalışıyor: Kurumumuza ait LLM’in bilgi dünyasını beslemek istediğimiz verileri bir araya getiriyoruz. Daha sonra tabi bu veriler çok kaynaklı olabilir yani raporlar olabilir, web siteleri olabilir, resmi gazete olabilir, uygulama esasları, teknik sheetler sabit bilgi gibiler. Birçok veri türü olabilir. Öncelikle bu veri kaynaklarını tek tipleştirmemiz gerekiyor. Genelde Text veya Markdown formatına çeviriyoruz bu bütün kapsamlı bilgileri. Daha sonra bu verileri temizliyoruz ve burada temizlemekten kastım örneğin bir web sitesindeki bilgileri alıyorsak eğer oradaki bannerları, buton isimlerini, sürekli geçen reklam bölgelerini gibi temizlemekten bahsediyorum, onları temizleyip tek bir çıktı haline getiriyoruz. Bu işlemleri yapmak için birçok tool da var aslında, kendi toolarımızı da yazabiliriz. Mesela bir tool örneği vermek gerekiyorsa DogLink adında çok güzel bir tool var. Phytonda çok kolay bir şekilde bu işlemleri de yapabiliyoruz. Daha sonra convert ettiğimiz bu metinleri küçük parçalara bölüyoruz. Bu işlemin adı Chunking. Amacımız büyük bir dokümandan arama yapmak yerine daha küçük cümleler, paragraflar halindeki yapılar, chunklar arasından arama yapıp ilgili bilgiyi LLM’e daha kolay bir şekilde vermek aslında. chunkladığımız bu küçük metinlerin üzerinde işlemler yapabilmek için bu sözsel ifadeleri matematik diline dönüştürmemiz gerekiyor. Bu işlemin adı da embedding işlemi. Aslında yaptığımız şey çok basit. Transformer mimarisinde bulunan encoder mimarisi ile hazırlanmış bir embedding modelini alıyoruz ve insan dilinde olan bu metinleri sayısal bir temsilini oluşturuyoruz şeklinde düşünebilirsiniz.

Artık her bir chunkımızın çok boyutlu uzayda bir temsilini oluşturmuş olduk. Bu sayede örneğin mevduat hesabı ile ilgili bir soru sorduğumuzda bu mesajı da aynı yöntemle embeddinge çevirip vektörler arasında anlamsal olarak yakınlık, uzaklık hesapları yapabiliyoruz. Tabi bu hesabı yapabilmek için bizim bir de vektör store’a ihtiyacımız var. Vektör data baseleri -aslında SQL gibi ilişkisel bir veritabanını düşünebilirsiniz- bu vektörler için embeddinge uğramış vektörler için özel olarak yapılmış bir database şeklinde düşünebiliriz.

Çeşitli açık kaynaklı ya da cloudda kullanabileceğimiz vektör databaseleri var. Bunlardan bazıları Milvus, Qdrant, Chroma gibi embeddinge çevirdiğimiz chunklarımızı açmış olduğumuz bu vektör databaselerinin içine tek tek meta datalarıyla birlikte ekliyoruz şeklinde düşünebiliriz. Artık her şey hazır. Yapmamız gereken tek bir şey var, o da LLM’e bir soru sormadan önce kullanıcının mesajını önce embeddinge çevirerek vektör data baseimize göndermek ve belirlediğimiz bir threshold değeri ile kullanıcının sorusuna benzer contextleri semantik yani böyle anlamsal olarak aramak. Arama yaparken de genelde kosinüs benzerliğini kullanıyoruz. Çeşitli yakınlık uzaklık hesaplamaları var ama genelde kosinüs benzerliği ile birlikte benim sorgumla içeriye koyduğum veriler arasında semantik olarak bir bağlantı bulmaya çalışıyoruz diyebiliriz. Daha sonra database'den gelen benzer içeriklerle LLM’e gidiyoruz ve LLM’in  aslında sistem promptuna şunu ekliyoruz “cevap vermeden önce sana vereceğim konteksi incele, bu konteksten yola çıkarak cevap üret. Eğer kullanıcının sorusu ile konteksteki bilgiler tam eşleşmiyorsa cevap verme” gibi bir sistem promptu eklemede bulunuyoruz.

Bu sayede artık LLM kendi eski bilgilerinden yararlanmak yerine teoride bizim kendi verilerimizi harmanlayarak, tabiri caizse soslayaraki bize sunmuş oluyor.

Neden teorik olarak konteksi kullanarak diye söylüyorum. Burayı biraz açmak istiyorum. Özellikle küçük bir LLM kullanıyorsak -ki küçük kavramı oldukça öznel bir yaklaşım- Türkçe için kullanacak olursak 4B, Yani dört milyar parametreli bir large language model küçük bir model olarak adlandırılıyorken, İngilizce için bu biraz daha değişiyor verinin büyüklüğü daha fazla olduğu için genelde İngilizce’de 1 Milyar parametreli bir model küçük olarak tanımlayabiliyoruz. Bu küçük modellerin konteks bağlılığı genelde daha az oluyor. Bu yüzden tam olarak verilen görevleri anlayamayabiliyor ya da konteks dışından cevaplar üretebiliyor. Bu gibi durumlar çok fazla yaşanıyor aslında. Bu gibi durumların önüne geçebilmek için bizim burada RAG mimarimizi geliştirmemiz gerekiyor.

Ben burada genelde RAG mimarisini üçe ayırıyorum. Burada RAG mimarisini RAG ve post RAG şeklinde ayırıp daha detaylı şekilde aslında inceleyebiliriz.

Pre-RAG’tan kastım şu: konteksleri nasıl alacağımızı, nasıl store edeceğimizle alakalı yaptığımız teknik ve ileri derecedeki işlemlere pre-RAG diyebiliriz. İlk adımımız convert adımı. Yine bir örnek üzerinden gitmekte fayda var. İK için bir chatbot yaptığımızı düşünelim. İK biriminin kullandığı banka içinde çok çeşitli dökümanlar oluyor.

Bunlar tablo verileri olabilir, excel'ler olabilir, taranmış pdfler, görsel içerikler, sunumlar ya da tanımsal ifadeler içeren web siteleri gibi çok çeşitli veriler olabiliyor. Bizim burada yapmamız gereken ilk adım, bu verileri tek bir veri türüne dönüştürmek olmalı. Bu veri türü yapısal olmalı, yani bir JSON gibi, bir Markdown gibi bölünebilir ya da başlıklandırılabilir halde olursa bizim için çok faydalı oluyor. Genelde JSON ya da Markdown formatı kullanıyoruz tekleştirmek için. Daha sonra convert mekanizmamızı çok zengin kurgulayabilmek adına her türlü doküman tipi için ayrı bir process yazmamız lazım. Yani burada aslında kastımız şu: Örneğin karşılaştırmalı tablo verileri içeren bir tablo geldi. Bu tablonun içeriğindeki her bir değeri ayrı bir şekilde biz alırsak o tablo aslında karşılaştırmalı p tablonun bir anlamı kalmıyor ve anlamsız bir veri elde etmiş oluyoruz. Aslında olması gereken chunkın içinde o tablonun sütun başlığı işte, satır değeri veya karşılaştırılan verinin kendisi şeklinde bir chunk yapısına sahip olmamız gerekiyor. Bu sayede o verinin aslında nereye ait olduğu, neyle kıyaslandığı daha açık bir şekilde gözükebiliyor. Bu sayede zengin bir konteks oluşturmuş olabiliyoruz. Aynı şekilde OCR ile yapılan çoğu taranmış belgenin çıktıları gerçekten yetersiz olabiliyor. Dikey mesela yazılmış bir cümle olduğunu düşünelim. OCR genelde yatay çalıştığı için o dikey bölgeleri kaçırabiliyor. Yine bunun yerine bir Vision Language model kullanarak her bir sayfayı VLM’e gönderip “buradaki metinleri bana çıkart ve tam olarak ver” şeklindeki küçük promptlarla birlikte oradaki tablo verilerini ya da taranmış verileri çok daha kaliteli şekilde almamız mümkün oluyor.

Verilerimizi düzgün format ile elde ettik. Sırada chunklama stratejimiz var. Burası gerçekten çok kritik aslında. Oluşturduğumuz bu düz metni neye göre böleceğimizi belirlediğimiz yer. Burası gerçekten belki üstüne en fazla durmamız gereken yerlerden birisi. En fazla test yapmamız gereken yerlerden birisi. Çünkü artık güzel bir düz metnimiz olduğunu düşünelim. Kullanabileceğimiz çok çeşitli chunk stratejileri var. Bunların başında en basit olarak karakter bazlı chunklama gelebilir. Ben şunu söyleyebilirim “benim her bir chunkım bin karakter uzunluğunda maksimum olmalı, benim düz metnimi al, biner karakterli şekilde böl” diyebiliriz. Fakat burada büyük dezavantajlar var. Bunların en büyüğü chunklar arasında kopukluklar meydana gelebilir.

Mesela biz üstteki chunkı çağırırken asıl vermemiz gereken bilgi ya da cümlenin geri kalanı bir sonraki chunklarda kalmış olabilir. O yüzden bu daha çok demo yazılımlarında kullandığımız bir yöntem. Bunun yerine mesela paragraf bazlı bölme chunking stratejisi uygulayabiliriz. Her bir paragraf, bir chunk olsun. Kullanıcı bir soru sorduğu zaman o paragrafın içinde var mı yok mu diye bakalım varsa o paragrafı direkt getirelim şeklinde düşünebiliriz. Fakat bunun da bir dezavantajı var. Özellikle bazı metinler çok uzun paragraflar içerebiliyor ve paragraf uzadıkça semantik olarak aradığımız bilgiye yakınlaşmamız da bir o jadar zorlaşmış olabiliyor. Bunlardan daha iyi iyi bir yöntem mesela Smart Chunking adını verdiğimiz bir yöntem. Ne yapıyoruz aslında? Oluşturduğumuz o düz metni bir LLM’e veriyoruz ve diyoruz ki “burada şu şu şu kurallara uyarak bana mantıklı anlamsal çıkarımlar yap ve şu kadar chunk oluştur” diyoruz. Bir LLM bizim yerimize anlamsal olarak o verdiğimiz düz metni düzgün bir şekilde bölüp bize verebiliyor. Tabi bunun da dezavantajı maliyet ve zaman oluyor, oldukça uzun sürebiliyor. Benim burada dinleyicilerimize özel olarak tavsiyem bir strateji daha var: Semantik Chunk Stratejisi oldukça başarılı bir strateji. Semantik chunk nedir? Burada aslında şunu yapıyoruz: metni cümlelere bölüyoruz ilk başta, noktalama işaretleriyle olarak düşünebiliriz. Daha sonra aldığımız her bir cümle ile sonraki cümle arasında bir anlamsal yakınlık var mı yok mu diye semantik search yöntemine benzer şekilde bir cosine similarity hesaplıyoruz.

Bu iki cümle arasında anlamsal olarak bir yakınlık varsa o iki cümleyi diyoruz ki “Tamam, seni birleştiriyorum, sen artık tek bir chunk olabilirsin” diyoruz ve bu adımı bir sonraki cümleye geçiriyoruz. Bir sonraki cümleyle yine anlamsal olarak yakınlık var mı yok mu ona bakıyoruz. Varsa birleştiriyoruz, yoksa bir sonraki cümleyi yeni bir chunk olarak oluşturuyoruz gibi düşünebilirsiniz.

Bu yöntemlere benzer birçok farklı strateji de mevcut fakat bence şimdilik bunlardan bahsetmek yeterli diye düşünüyorum. İsterseniz burada ikinci evre olarak RAG adımıyla devam edebiliriz. RAG adımında kendi dokümanlarımıza uygun parser metodlarımızı yazdık. Uygun chunk stratejiimizi seçtiğimizi düşünelim. Şimdi sırada kullanıcının sorusuna benzer en yakın içerikleri bulmaya geliyor. Normal bir RAG sisteminde kullanıcının sorusunu embeddinge çevirip semantik search ile arama yapıp belirlediğimiz sayıda konteksi alıp LLM’e veriyoruz.

Burada biraz işler değişiyor. Çünkü bazen konteks eğer belirsiz olursa ya da çok fazla sayıda olursa LLM’in çıktısının kalitesi bir o kadar düşebiliyor.

Bu yüzden bizim doğru konteksi seçmemiz çok önemli. Semantik search bazen eksik kalabiliyor bu noktada. Onun yerine biz genellikle hibrit search yöntemini tavsiye ediyoruz.

Hibrit search dediğimiz aslında semantik search'ün anlamsal yakınlık uzaklığıyla birlikte ki semantik search, aslında burada şunu sağlıyor: Kullanıcı örneğin “şifremi unuttum” yazdığı zaman benim database’imin içinde “parolamı hatırlamıyorum”la ilgili bir bilgi varsa “şifremi unuttum” ve “parolamı hatırlamıyorum” benzer anlamlar ifade edeceği için parolamı hatırlamıyorumla alakalı bilgiyi bize getirmesini sağlıyorken BM25 benzeri bir sözcük tabanlı arama algoritması ise – full-text search gibi düşünebiliriz- direkt kelime bazlı arama sağlayabiliyor. Bu iki yöntemi birleştirerek hem anlamsal olarak yakınları tararken hem de birebir geçen terimlerin veya semantik search'ün zorlandığı kısa cümlelerin bulunmasını kolaylaştırabiliyoruz. Bu sayede konteks başarımız ciddi şekilde artabiliyor. Bir diğer tekniğimiz Query rewriting yöntemi. Kullanıcılar genelde konuşma dilinde sorular sorarlar.  Biz ise içeriye daha böyle yazısal ifadeler koyarız. Örneğin kullanıcı “Kart şifremi nereden öğrenebilirim” şeklinde yazmaz. Genelde genelde “Şifrem ne” şeklinde yazar. Bizim bu durumlarda doğru soruları ve doğru cevapları eşleştirmemiz bir hayli zor olabiliyor. Bu durumda bunun önüne geçebilmek için adı üstünde Query rewriting yapabiliriz. Aslında ne yapıyoruz burada? küçük bir LLM yardımıyla kullanıcının sorduğu soruyu daha yazısal ifadelere çevirip daha böyle kapsamlı düzgün Türkçeye çevirip o soruyla birlikte RAG yapmaya da Query rewriting yöntemi diyoruz. Bununla birlikte yine Multiquery Search de kullanabiliriz. Multiquery Search de yine bir agent ya da bir basit LLM yardımıyla birlikte kullanıcının sorusunu beş farklı on farklı varyasyonuna çevirtip onlarla birlikte RAG yapıp daha zengin içerikler elde edebiliriz.

Son olarak bir teknik daha var burada. Özellikle LLM’e çok fazla konteks vermek süre ve token maliyeti açısından çok dezavantajlı olabiliyor. Bir de çok çeşitli konteks vermek halüsinasyon riskini de ciddi şekilde arttırabiliyor. Bu durumu engellemek için bir reranker kullanabiliriz.

Reranker nedir? RAG yapıp getirdiğimiz kontekslerin kullanıcı sorusu ile ilişkisinin durumunu ölçen bir algoritma olarak, bir model olarak düşünebiliriz. Aslında Cross Encoder tabanlı bir model rerankerlar. Biz gittik Query rewriting yaptık, multi search yaptık. Daha sonra yirmi tane chunk aldık kendi vektör databaseimizden. Daha sonra bu yirmi chunkı bu embedding modeline sokarak, reranker modeline sokarak bir sıralama yapabiliriz ve bu en yüksek skorlu beş tanesini LLM’e verip daha sağlıklı cevap üretmesini sağlayabiliriz.

Son olarak bu üçüncü evre olan Post-RAG evresi. Burada ise LLM’den aldığımız cevapları kontrol etme adımı olarak düşünebiliriz. Peki neden biz LLM’in çıktılarını kontrol ediyoruz? Konuşmamızın başında da bahsettiğim gibi doğru cevap vermekten daha önemli bir sorunumuz var: yanlış cevap vermemek. Cevap anlamsız olabilir, cevap sorunun cevabı olmayabilir veya hiç cevap verilmemiş direkt fallback mesajı verilmiş olabilir. Bunlar bizim için küçük problemlerken yanlış cevap verilmesi veya yasaklı kriterlerden birini içeren cevaplar bizim için oldukça risklidir. Örneğin bir bankacılık chatbotu asla yatırım tavsiyesi vermemeli, bir ürünü direkt övmemeli diye düşünebiliriz.

Eğer bizim cevabımız da direkt yatırım tavsiyesi varsa, bu bizim için ciddi bir risk. Bu durumların önüne geçmek için LLM’in çıktısını kullanıcıya vermeden önce aslında kontrol etmemiz gerekiyor.

Burada kullanabileceğimiz iki yöntem var yine. Birincisi RAG için aldığımız bu konteksleri LLM’in çıktısı ile yine semantik olarak karşılaştırmak. Yani örneğin “eğer bağlam ile cevap arasında yüzde elli'lik bir benzerlik varsa bu cevabı verme, bu cevap yerine Fallback mesajı ver” diyebiliriz. Yine benzer şekilde daha önceden oluşturduğumuz trigger sentenceları alıp LLM’in ürettiği çıktıda bu trigger sentencelardan yani bu yasaklı yapılardan birisi var mı yok mu şeklinde manuel kontroller yapabiliriz. İkincisi biraz daha kapsamlı ve bence gerekli bir adım. DeepEval adında bir ürün var. Buna benzer yapılar DeepEval olduğu için burada özellikle bahsediyorum, kendimiz de yapabiliriz. Basit yapılar bunlar. Çeşitli parametrelerle LLM’in çıktılarını daha farkl bir ekspert LLM ile birlikte aslında değerlendirmemizi sağlıyor. Yani bizim LLM’imiz bir çıktı üretiyor, biz de diyoruz ki “ya bu çıktıyı üretirken bu LLM bak şu sistem promptu kullandı. Şuradaki konteksi yani bağlamı kullandı. Sence şu kriterlere uyuyor mu bu çıktı” diye bir expert LLM’e bu soruyu sorabiliriz ve onun verdiği puanlama ile birlikte biz o çıktıyı kullanıcıya verebiliriz. Ya da “ya bu çıktı riskli bir bölgede, biz bunun yerine Fallback mesajı verip devam edelim” diye düşünebiliriz. Özellikle DeepEval’ı kullanacak olanlar varsa rubrik yöntemi ile kullanmalarını da tavsiye ederim. Çok daha tutarlı olduğunu görecekler. Göreceğiniz gibi bir chatbot veya agent mimarisi için kurumsal olarak içerideki life cycle bu şekilde oluyor. Tabi çok çeşitli RAG yapıları var. Yani mesela craft RAG, agentic RAG gibi. Fakat bu RAG yapıları her mimari için mükemmel çözümler üretmiyor. Her birinin artı ve eksisi oluyor. Ben burada advance seviyede bir sistemden bahsetmek istedim. Bu bahsettiğim teknikler onlarca farklı tekniklerin, çok uzun süreler test edilip en mantıklı kombinasyonlarıyla seçilerek oluşturuldu ve sadece bunları değil, bunların yanında birçok farklı tekniği de kullanıyoruz. Umarım dinleyiciler için de faydalı olmuştur.

Ahmet Hoşgör:

Evet çok böyle. Şey. Bence teknik açıdan merak edenlerin de faydalanabileceği, kaliteli bir cevap oldu,uzun ve kaliteli bir cevap oldu. Hani şey vaktimizi de iyi yönetmek adına bazı soruları yine de sormak isterim Alperen. Burada kütüphane metaforu yapmıştık orada aslında şöyle sorabilirim yani her sorulan soruya da bazen cevap vermemeli belki yani kütüphaneciye belki kasanın anahtarları nerede diye her soran kişiye belki kütüphaneci cevap vermemeli. Burada kimin hangi bilgiye erişeceği konusu var. Bunu nasıl yönetiyorsunuz?

Alperen Çelik:

Burada özellikle şöyle bir yapımız mevcut DeepEval ile birlikte şöyle bir yapıyı kullanıyoruz. Diyelim ki kullanıcı kendi bilgilerini bizim içeriye verdi. Burada aslında yapmamamız gereken bir gard mekanizması diye düşünebiliriz. Kendi IBAN bilgisini verdi, TC bilgisini verdi ya da bizim içeride bulunan sistem prompt'umuzu istedi injection yapmaya çalıştı gibi düşünebiliriz. Bu tarz durumlarda bizim bir gard mekanizmamız var. Aslında bu da üçe ayrılıyor. Birincisi basit şekilde kullanıcının sorduğu soruyu önce bir analiz ediyoruz. Yani bu soruda hakaret var mı, bir aşağılama var mı, bir yanlış bir ifade var mı ya da bir injection yapmaya çalışıyor mu gibi bir kontrolden geçiriyoruz. Değilse sonraki adıma geçiyor. Sonraki adım da kişisel bilgi var mı yok mu adımına geçiyor. Eğer kullanıcı kendi kişisel bilgisini vesaire verdiyse bize, bizim onları kesinlikle maskelememiz gerekiyor. Her ne kadar kullanıcının sorduğu soru anlık olarak bir yere gönderilmiyor ya da tutulmuyor olsa da kullanıcı verisi bizim için çok mahrem.

Bundan dolayı onların maskelenip içeriye öyle alınması gerekiyor. Bu yapıyı kullanırken de bir gard mekanizmasıyla aslında bir LLM ile birlikte, ki kullandığımız modellerden birisi de GPT'nin Safegard yapısı yüz yirmi milyar parametreli çok büyük bir modeli var ve bu model gerçekten çok iyi çalışıyor. Verilen kurallara çok çok iyi uyduğunu gözlemledik.

Hatta başarım oranının doksan dokuz'ların üstünde olduğunu kendi tarafımızda on binlerce test sonucunda gözlemledik. Bu yapılar sayesinde aslında kullanıcı yasaklı bir bilgi içeriğe genelde veremiyor. Vermeye çalıştığı zaman fallback mesajıyla onu engelliyor ya da “bu konuda talebin cevabı bende yok, istersen müşteri temsilcisiyle konuşabilirsin” şeklinde yönlendirici mesajı verip devam ediyoruz gibi düşünebilirsin.

Ahmet Hoşgör:

Süper. Aslında bu bahsettiğin şey mekanizma nerede çalışıyor? Yani Slack’ten Teams’ten de ulaşılabiliyor mu? Yoksa bir bot gibi mi? Dinleyenlerin daha kafasında, biraz daha canlanması adına soruyorum.

Alperen Çelik:

Biz burada çok çeşitli altyapılar kurguladık. Aslında şu an hem backend tarafımız hem frontend tarafımız hem UI tarafımız mevcut.

Örneğin bir iş birimi “ya ben bunu kendi dokümanlarım üstünde kullanmak istiyorum. Benim ekibimin bak şöyle bir ekranı var, buraya bir chatbot koyabilir miyiz” dediği takdirde UI’na kadar biz her şeyi direkt oraya entegre edebiliyoruz. Örneğin kendi içeride kullandığı içsel ekranlarda buna erişebiliyor. Yine bahsettiğiniz gibi Teams vs. üzerinden de buna erişmek mümkün fakat burada kullanıcı verisinden dolayı buna çok erişime izin vermiyoruz. Onun yerine daha çok web sitelerimizin üzerinde konumlandırmayı tercih ediyoruz. Yakın zamanda mobil uygulamalarımızda da aktif bir şekilde kullanılabilecek. Veri konusunda ise bütün veriler aslında lokale store ediliyor. Aynı zamanda kullandığımız LLM modelleri de kendi bankamızın bünyesinde bulunan GPU makinelerinden serve ediliyor ve bu sayede kullanıcı verisini yurtdışına çıkartmadan güzel bir şekilde cevaplar üretebiliyoruz diyebilirim.

Ahmet Hoşgör:

Burada feedback loopu nasıl? Yani kendiniz de test ediyorsunuzdur tabi, burada düzeltilen cevaplar oluyor mu, doğru yanlış cevaplara nasıl davranıyorsunuz? Bir de bunu böyle pilot ekiplere açıp yavaş yavaş mı gidiyor, scale etme sürecindeki şeyler, düzeltme davranışları nasıl? Onu merak ettim.

Alperen Çelik:

Harika bir soru. Bir CMS ekranımızdan bahsetmiştim. Chatbot suit adında. Aslında bu ekranda bir raporlama tabı da mevcut. Raporlama tabı bize şunu sağlıyor kullanıcının sorduğu ve aldığı cevapları çok detaylı bir şekilde analiz edebileceğimiz bir raporlama ekranı olarak düşünebilirsiniz. Takım arkadaşlarımızdan bazıları direkt olarak bu görevi üstlenmiş durumda. Günlük olarak, haftalık olarak bu raporları inceleyerek, sorunlu bulabildikleri yapıları direkt bize bildirerek veya çözüm önerileri ile birlikte geliyorlar ve biz de varsa bir çözümümüz çözüm üretiyoruz, yoksa onu daha geliştirebilmek adına geliştirme talebi olarak açıyoruz gibi düşünebiliriz.

Bir de şöyle bir yapımız var. Kullanıcılarımızın sorduğu her bir soruyu biz yine lokalimizde bulunan bir LLM sayesinde değerlendirmeye alıyoruz. Ya burada kullanıcımız acaba bizden bir şikayette mi bulundu? Eğer bir şikayette bulunduysa onu şikayet sınıfına koymuş oluyoruz ve daha sonra şikayetleri üst birimimize iletmiş oluyoruz. Ya burada kullanıcımız bizden güzel mi bahsetti, bize övgüyle mi bahsediyor gibi farklı farklı klasife ettiğimiz sınıflarımız mevcut. Bu sınıfların havuzları toplandıktan sonra üst birimimize rapor olarak sunuyoruz ve gelen aksiyonla birlikte biz de devam ediyoruz diye düşünebiliriz.

Ahmet Hoşgör:

Burada asla kapatmadan biraz daha böyle, biraz da hayal kurulan, o gelecek, yani vizyon ve gelecek kısmına geçip sonra da aslında kapanış kısmına geçmek isterim. Tabii çok hızlı gelişiyor her şey. Biz eskiden böyle önümüzdeki beş yılı nasıl görüyorsun falan diyorduk. Şimdi öyle şeyler demek mümkün değil tabii ki. Bir sonraki adımı hep konuşuyoruz. O adım da çok hızlı geliyor. Hem GenAI’ın bir sonraki adımı hem şimdi agentic arayüzlerler de konuşulmaya başlandı bunların bir sonraki adımları olara. Hem belki kişisel olarak hem şirket bakış açısıyla önümüzdeki dönemi nasıl görüyorsun?

Alperen Çelik:

Harika. Şu anda şirketler yatırım yapmaktan bile çekinir durumda “ya bir ay sonra daha iyisi gelir” düşüncesiyle. Gerçekten kritik bir dönemden geçiyoruz. Bizim şirket olarak vizyonumuz şu şekilde: Öncelikle tüm çalışanlarımız yapay zekayı bir karar destek sistemi olarak görmeli. Kendi yerini alacak biri olarak değil de bir destekleyici bir Senior yeri geliyor bir JR olarak görmeli hedefindeyiz. Bunun için banka içinde çok fazla sayıda yapay zeka eğitimleri veriyoruz ya da dışarıdan alıyoruz gibi düşünebilirsiniz. Hem kullandığımız toolları geliştiriyor hem de onların domainleriyle birlikte diğer ekiplerdeki arkadaşların domainleri ile birlikte yeni projeler yapmayı hedefliyoruz.

Bir diğer konuysa agentic taraf tabii ki. Agentic AI gümbür gümbür geliyor. Herkes işimizi elimizden mi alacak düşüncesinde. Biz de bu tarafta yoğunlaşmış durumdayız. İş elinden almaktan ziyade, şunu bir yazılımcı olarak çok iyi görebiliyorum ki, yani benim yazacağım o kodları birine yazdırıyor olmam aslında benim yerime iş yapıyor olduğu anlamına gelmiyor. Yine mimariyi ben kurguluyorum, yine ürünü ben yönetiyorum burada. Yalnızca düşünmeye daha fazla zamanım oluyor. Daha kritik noktaları, edge caseleri de düşünebiliyorum gibi görüyorum kendimde. Agentic tarafta da geliştikçe bence daha özgün ürünler çıkacak. Daha özgün projeler yapabileceğiz. Daha kendi kararlarımızla farklı farklı şeyler deneyebileceğimizi düşünüyorum. Çok muazzam bir dönemden geçtiğimizi açıkçası düşünüyorum. Ben umutluyum. Umarım herkes de umutludur diyebilirim.

Ahmet Hoşgör:

Evet evet gerçekten öyle, şey. Bazen AI’ın da buzul çağı olduğu dönemleri anlatırlar eskiden. Hani daha duraklama dönemleri olabiliyor, bazen de çok hızlanan dönemler oluyor. Belki işte internetin bulunması da öyleydi. Ya da işte mobil tarafın gelmesi. Şu anda da öyle bir dönemdeyiz. Belki de daha fazlasındayız. Peki kapatırken yani aslında Alperen bunu junior/mid/senior farklı seviyede insanlar dinlemiş olabilir. Ben junior olarak da, senin yanında da, böyle yeni mezun olsam çalışmak isterim. Bir çalışma arkadaşı olarak da yanında da isterim. Belki tönetici olarak da isterim. Çünkü çok dolu dolu anlattın. Hakikaten otuz dakika değil yani üç yüz dakika olsa burada konuşurduk hissiyatı verdin. Ben teşekkür ederim tekrar konuk olduğun için. Peki ne önerirsin hani başvuracaklara? Nerelerden ulaşabilirler, kimleri arıyorsunuz? Ya da ne tarz profiller var böyle biraz da aslında “gelin biz birlikte geliştirelim” diyorsan o kişilere neler demek istersin? Sözü bir en son sana vereyim.

Alperen Çelik:

Kesinlikle diyoruz. Aynen öyle. Ve karamsarlık kesinlikle burada olmamalı. Onun yerine kendi işimize odaklanmamız lazım. Biz de çok yüksek sayıda stajyer ve junior pozisyonlarında özellikle alımlar yapıyoruz. Daha geçtiğimiz haftalarda çok büyük bir başvuru tufanına tutulduk diyebilirim. Önümüzdeki dönemde yine stajyer alımlarımız devam edecek ve ekiplerini sadece yapay zeka ekibi olarak düşünmeyelim. Çok fazla ekibimiz var içeride. Her ekip için bazen onlarca farklı stajyer alma gibi durumumuz olabiliyor. Bundan dolayı LinkedIn hesaplarımızı takip etmek gerçekten çok kritik, özellikle Burgan Bank'ı. Bana da spesifik olarak soruları olursa dinleyicilerimizin, direkt LinkedIn üzerinden ulaşırlarsa seve seve ben de sorularına cevap veririm.

Ahmet Hoşgör:

Süper. Çok teşekkürler konuk olduğun için. Aslında ben böyle bir şey de düşünüyordum. Sadece AI üzerine bir podcast serisi mi yapsak, o düşüncemi güçlendirdi bugün bu konuşma. Öyle bir şey yaparsak da ilk bölüme seni tekrar davet etmek isteriz. Çok teşekkürler vallahi konuk olduğun için. Çok keyifli, kaliteli bir sohbet oldu bence. Umarım yüzyüze de görüşme fırsatımız olur bir gün. Görüşmek üzere.

Alperen Çelik:

Çok teşekkür ederim kıymetli sözlerin için. Görüşmek üzere.