Generative AI (Üretken Yapay Zeka) ve büyük dil modelleri (Large Language Models – LLM), ChatGPT gibi teknolojilerin kullanıma açılmasıyla son zamanlarda önemli bir popülarite kazandı. Bunun bir sonucu olarak araştırma raporlarında, organizasyonlara ve yöneticilere, hem müşteriler hem de yatırımcılar tarafından Generative AI teknolojilerini kullanmak konusunda baskının arttığını görmeye başladık. Örneğin IBM tarafından hazırlanan bu rapora göre, araştırmaya katılan CEO’ların %75’i Generative AI kullanmanın rekabet avantajı yaratacağına inandığını söylerken, %66’sı yatırımcılardan kurumun AI adaptasyonunun hızlanması için baskı aldığını söylemekte.
Ancak Generative AI teknolojilerini, iş süreçlerinin günlük bir parçası haline getirmek ve kurumu bu teknolojiden fayda sağlar konuma getirmek kolay değil. Bu yazıda MLOps prensiplerinin “foundational model” denilen temel dil modelleri için nasıl uygulanabileceğini (FMOps – Foundational Model Operations) inceleyeceğiz. Bu kapsamda en yaygın kullanılan generative AI teknolojilerinden olan LLM’ler için operasyon süreçlerinin (LLMOps) nasıl farklılaşabileceğine yakından bakacağız.
MLOps ve Prensipleri
Machine Learning Operations ya da kısaca MLOps için, makine öğrenimi modellerinin kurumsal IT operasyonlarına entegrasyonu için oluşturulan bir grup teknik ve metot diyebiliriz. MLOps kullanımı ile (DevOps süreçlerine benzer şekilde) makine öğrenimi modellerinin geliştirilmesi, test ve canlı ortamlar arası taşınması (deployment), test ve bakım ihtiyaçlarının karşılanması gibi adımları otomatize etmeyi düşünebiliriz.
MLOps süreçlerindeki personaları aşağıdaki şekilde ifade edebiliriz.
- Analitik Ekip: Verinin farklı kaynaklardan toplanması, ETL akışlarının tasarlanması, verinin kataloglanması ve ML modelleri tarafından kullanıma hazır hale getirilmesinden sorumlu veri mühendisleri ekibi.
- Veri Bilimi Ekibi: Jupyter notebook gibi ortamlarda, toplanan veri üzerinden en etkili ML modelinin tasarlanması için çalışan ekip. Tasarlanan modelin hedeflenen KPI’lara ulaşmasını sağlamak da bu ekibin sorumluluğundadır.
- İş Ekipleri: İş ihtiyacı için iş gereksinimlerini ve modelin performansını değerlendirmekte kullanılacak KPI’ları tasarlayan ürün yöneticisi ya da ürün sahipleridir. Tasarlanacak olan ML modelinin kullanıcısı olan ve iş-karar mekanizmalarına dahil eden ekip de yine iş ekipleri olacaktır.
- Platform Ekibi: Modelin geliştirildiği ortamların mimarisi, erişilebilirliği, entegrasyonları gibi başlıklardan sorumlu ekiptir. Veri ve bilgi güvenliği kriterlerini takip eden güvenlik ekipleri de platform ekibinde sayılabilir. CI/CD süreçlerinin standardizasyonu, kullanıcı ve servis hesapları için rollerin belirlenmesi, container yaratılması, geliştirilen modelin canlı ortama alınması ve oradan kullanılabilir olması gibi başlıkları bu ekip sorumluluğunda sayabiliriz.
- Risk ve Uyumluluk Ekipleri: Bütün süreçlerin veri gizliliği gibi hukuki düzenlemelere uyumluluğunu, verinin, kodun ve süreçte oluşturulan bileşenlerin denetimini (audit) sağlayan ekiptir.
Tabi ki kurumlarda işin ve ihtiyacın büyüklüğüne göre bu personalar, aynı kişiler tarafından temsil ediliyor olabilir.
MLOps için farklı sağlayıcılarıların referans mimarisi diyagramlarına bir göz gezdirmenizi öneririm:
Microsoft 👇
Google 👇
Generative AI Dünyası ve MLOps’tan Farkları
Generative AI teknolojileri kullanıldığında, işin doğası gereği yukarıdaki süreçlerde, kişilerde ve tanımlarda bazen ufak değişiklikler yapmak, bazen tamamen yenilerini tasarlamak gerekebilmektedir.
Öncelikle “temel modeller” olarak çevirebileceğimiz “Foundational Model” tanımını kısaca ele alalım. Foundational modeller; kullanarak farklı özelleşmiş ML modelleri elde edebileceğimiz makina öğrenmesi modelleridir. Bu sayede çok farklı kullanım senaryolarında altta yatan makine öğrenimi modelleri olarak yer alabilirler.
Temel modeller, terabytelarca veri ve milyarlarca parametre ile eğitilerek geliştirilirler. Tasarımında kullanılan üretken dönüştürücü (generative transformer) mimarisiyle bir akış içerisinde bir sonraki en iyi üretimi (metin, ses, görüntü) tespit etmeyi gerektiren modellerde kullanılabilir. Bu da temel modelleri, aşağıdaki kullanım senaryolarında ideal bir araç yapar:
Metinden Metine: Temel model, etiketlenmemiş metin (free text) verisiyle eğitilir. Bu sayede, bir grup kelime verildiğinde bir sonraki en uygun kelimeyi tespit edebilir. Chatbot, özet çıkarımı, metin tabanlı sınıflandırma gibi kullanım senaryolarında yer alır.
Metinden Resime: Temel model, <metin-resim> ikilileriyle eğitildiğinde, girilen metne karşılık en iyi piksel kombinasyonunu üretebilir. Kampanya, reklam görselleri oluşturmakta, kıyafet, oda, bina gibi tasarımlar yaratmada kullanılabilir.
Metinden Sese ya da Video’ya: Temel model etiketli ve etiketsiz (labeled, unlabeled) veri ile eğitildiğinde ses ve video akışı oluşturabilir. Müzik ve animasyon üretiminde kullanılabilir.
Geleneksel makine öğrenimi modelleri ile temel model ve dil modeli kavramlarına bir baktığımıza göre, bu modellerin operasyonel süreçlerini konuşabiliriz. Özetle hem temel modeller, hem dil modelleri, MLOps prensiplerinden bazı noktaları miras alabilir, ancak bazı noktaları güncellemek gerekecektir.
FMOps: Geniş kullanım senaryoları için uyarlanarak kullanılabilecek temel model süreçlerinin tasarlanması ve otomatize akışlara dönüştürülmesi diyebiliriz.
LLMOps: FMOps’un bir alt başlığı gibi düşünebiliriz. Temel modellerin, dil modelleri olarak özelleşmiş versiyonlarının süreçlerinin tasarlanması ve otomatize akışlara dönüştürülmesi diyebiliriz.
Bu üç kavramı (MLOps, FMOps ve LLMOps) ve ilişkilerini görselleştirmek gerekirse:
Bir operasyonel süreci tasarlarken, olası rolleri ve personaları ortaya koyarak başlamak kullanışlı olacaktır. FMOps için süreçleri şu kişilerin ve rollerin gözünden konuşarak başlayabiliriz.
- Geliştirici Roller: Temel modelleri sıfırdan geliştiren kullanıcıları geliştirici roller altında düşünebiliriz. Bu kapsamda geliştirici ekiplerde ML ve NLP gibi teknolojilere hakimiyet, veri bilimcileri ve editörler bulunmalıdır. Çünkü büyük verinin doğru etiketlenmesi doğru çıktı üretmek adına oldukça önemlidir. Geliştirme sürecinin çıktısını, tekrar kullanılabilir bir temel model olarak düşünebiliriz.
- Uyarlarıyıcı Roller: Geliştirilen temel modeli gereksinimlere uygun çıktılar vermek üzere ayarlayan, daha üst katmanlar ekleyerek tekrar eğiten kullanıcıları uyarlayıcı roller altında düşünebiliriz. Temel modellerin parametrelerinin istenen başarıda çıktıyı alana kadar tekrar tekrar değiştirilmesi ve doğru parametre değerlerinin tespit edilmesi de bu rollerin sorumluluğundadır. Yine ML teknolojisine aşinalık ve veri bilimcileri bu ekip için de gerekmektedir. Ancak bununla beraber, çıktının belirli bir iş görevini yerine getirmeye yetkin olabilmesi için, ilgili iş alanında uzmanlık da bulunmalıdır. Son zamanlarda duyulmaya başlayan prompt engineer’lar (yönerge mühendisleri) bu ekip altında düşünülebilir.
- Tüketici Roller: Geliştirilen ve belirli bir iş konusunda bir görevi yerine getirmek üzere uyarlanan makine öğrenimi modelini beki bir arayüz aracılığıyla kullanan ve işi yerine getiren kullanıcıları ve sistemleri bu kapsamda ele alabiliriz. Yukarıda konuştuğumuz rollerden farklı olarak, uyarlanmış modeli kullanırken, ML teknolojilerinde uzmanlık gerekmez. Ancak doğru sonuçları elde etmek için prompt engineer’lık yapabilirler.
Geliştirici Roller Açısından Süreçler
Geliştirici roller, temel modeli tasarlayan, derin öğrenme gibi metotlar ile modeli eğiten kişilerin rolüdür. Bu rolün işlevini yerine getirebilmesi için, teknoloji altyapısına (sunucular, network, vb) ihtiyacı olacaktır. Aynı zamanda tarihsel veri yanında modeli test edebileceği veriye ulaşabilmeli, izleme (monitoring) altyapısına erişebilmelidir.
Geleneksel ML modelleri için, “baz alınabilecek ve doğru (ground truth)” kabul edilen verinin, çalışma ortamına taşınması genelde ETL süreçlerinin tasarlanması ile elde edilir. Örneğin, bir kullanım senaryosu olarak, müşterinin ayrılma olasılığını tahminleyecek bir modeli ele alalım. Elimizde, bir veritabanında müşterinin durumunu (churn, not churn) ilişkili veriler ile görebileceğimiz bir veritabanı bulunması gerekmektedir. Bir temel modelin bu veri ile eğitilebilmesi için de, verinin milyarlarca satır seviyesinde olması gerekir.
Metinden resime kullanım senaryoları için ise, benzer şekilde etiketlenmiş milyarlarca <metin, resim> ikililerine ihtiyaç olacaktır. Bu tarz bir verinin hazırlanması, CLIP gibi modeller ile bir parça otomatize edilebilse de genelde oldukça zaman alan ve maliyetli bir iştir.
Tarihsel veri hazırlanabildiğinde, modelin eğitilmesi ve kullanılabilir bir ürün haline getirilmesi yine bu rolün sorumluluğundadır. Oluşturulan modeller, birazdan “Tüketici Roller Açısından Süreçler” başlığında “Modelin Testi” bölümünde konuşacağımız gibi test edilmeli, değerlendirilmeli ve sürekli iyileştirilmelidir.
Uyarlayıcı Roller Açısından Süreçler
Temel modeller ve özelleşmiş versiyonu büyük dil modelleri, geliştirme aşamasında amaca uygun hâle getirilmek üzere tasarlansa bile, doğası gereği daha derin bir özelleştirme adımına ihtiyaç duymaktadır. Zira bir temel model, bir haber sitesindeki haberin özetlenmesi açısından istenen çıktıyı verebilse de, hukuki bir metnin sınıflandırılması gibi bir senaryo için uygun olmayabilir. Bu nedenle, bir uyarlama yaklaşımı tasarlanmalı, model tekrar tekrar etiketli veriler ile eğitilmeli, ayarlarıyla istenen sonucu alana kadar oynanmalıdır.
Modelin parametre değerlerinin farklılaştırılması ile istenen sonuca yaklaştırılması için de kullanılabilecek farklı mekanizmalardan bahsedebiliriz:
- Ayarlarla Oynamak: Etiketli verinin modelin parametreleri değiştirilerek tekrar tekrar girdiye dahil edilmesi, modelin kullandığı ağrılıkların ve katmanlar arası eğilimlerin tekrar hesaplanması ve tüm çıktının oluşturulup gözlenmesi olarak özetleyebiliriz. Hesaplamalar tekrar tekrar yapılacağı için yüksek işlemci gücü harcanmasına neden olabilir. Ancak sürecin sonunda modelin doğruluğunu önemli ölçüde artırır.
- Parametre Verimli İyileştirme: “Parameter efficient fine tuning” terimi, makine öğrenimi ve derin öğrenme modellerinin performansını artırmak için kullanılan bir yöntemi ifade eder. Bu yöntem, genellikle büyük ve karmaşık modellerin daha az hesaplama gücü ve veri kullanarak daha iyi sonuçlar elde etmesini amaçlar. Parametre verimli iyileştirme, mevcut bir modelin veya ağırlıkların (parametrelerin) daha küçük bir alt kümesini, hedef bir görevde daha iyi performans gösterecek şekilde ayarlamayı içerir. Özellikle büyük veri setleri veya hesaplama kaynakları sınırlı olduğunda kullanışlıdır, ancak buna karşılık daha düşük bir doğruluk üretir.
Tüketici Roller Açısından Süreçler
Yukarıda da belirtildiği gibi prompt ya da yönerge dediğimiz girdileri modele veren, çıktısını test eden, buna göre amaca uygunluğunu değerlendiren ve doğru modeli belirleyen kullanıcılar, modelin tüketicileridir. Tüketiciler iş birimleri ve iş kullanıcıları olabileceği gibi son kullanıcılar (end-user) yani müşteriler de olabilmektedir.
Modelin tüketicileri, modeli geliştirme ve uyarlama süreçlerinden bağımsız, kullanımlarına sunulan bir ürün olarak değerlendirmelidir. Geliştirme ve uyarlama sürecinde verilen tasarım kararları ya da istisnai uygulamalar varsa, model tüketicisi bunları görmezden gelebilir. Ancak modelin ürettiği çıktılara değerlendirme ve geri bildirim vermek, model tüketicisinin de en doğal hakkı olacaktır.
Burada önemli bir nokta da, son kullanıcıların geri bildirimler ile modeli amacından saptırmasının önüne geçmek olacaktır.
Model Seçimi
Tüketici kullanıcıların, model seçim sürecinde dikkat etmesi gereken bir çok başlık bulunmaktadır. Bunlar özetle,
- Özel ve Açık Kaynak Lisanslama: Özel lisanslı modellerin genelde bir maliyeti olur ancak daha iyi performans verebilirler. Bununla beraber açık kaynak lisanslı olarak da esnek ve özelleştirilebilir modeller bulunmaktadır.
- Lisansın Ticari Kullanımı: Bazı modeller, açık kaynak dahi olsa ticari kullanımı kısıtlanmış bir lisansla dağıtılıyor olabilir.
- Parametre Kullanımı: Bazı modeller sayıca çok parametre ile çalışacak şekilde tasarlanırken, bazıları az parametre ile daha pratik kullanıma uygundur. Genelde çok parametreli modeller ile daha karmaşık senaryolara uyarlama geliştirmek mümkün olabilir.
- Hız: Büyük modeller için yanıt üretimi zaman alabilirken, küçük modeller daha hızlı olabilmektedir. Bu nedenle modelden istenilen doğruluğu, istenilen hızda elde etmek için bir denge gözetmek gerekebilmektedir.
- Eğitiminde Kullanılan Veri Seti: Temel modelin hangi veri seti ile eğitildiğini bilmek oldukça önemlidir. Bazı modeller, internete açık veriler ve GitHub, StackOverflow gibi mecralarda erişilebilen kodlar ile eğitilirken, bazıları insan müdahelesi ile tasarlanmaktadır. Bu durum, modelin uyarlanacağı kullanım senaryosu için uygunluğunu etkilemektedir.
- Kalite: Modellerin kalitesi, beklenen amaca uygunluğuna göre değişebilmektedir. Bir kullanım senaryosu için elde edilen kalite, diğer bir senaryoda farklı olabilir.
- Uyarlanabilirlik: Seçilen modelin, hedeflenen kullanıma uygun hale getirilebilmesi için ağırlıkları ve katmanları ile oynayabilmek gerekebilir. Her model için bu yapılabilir olmayabilir. Genelde açık kaynak modeller, kullanıcılar tarafından özelleştirilebilmeye daha elverişlidir.
Modelin Testi
Bir model seçildikten sonra, modelin üreteceği çıktıların doğruluğunu ölçmek, kullanım senaryosuna uygunluğunu değerlendirmek açısından önemlidir. Elde hazır bir veri seti olup olmamasına göre farklı test metotları takip edilebilir:
Örneğin elimizde etiketli bir veri seti varsa, modele bir girdi vermek ve çıktısını etiketler ile kıyaslamak bir yöntem olabilir. Ancak serbest metinler gibi veriler ile test edilecek ise, farklı metotlar takip edilebilir.
- Doğruluk Metrikleri – Kullanım senaryosuna göre farklı metrikler kullanılabilir. Örneğin Duygu Analizi (sentiment analysis) gibi bir model için, precision, recall ve F1 puanı gibi metrikler olabilir.
- Benzerlik Metrikleri – Metin özetleme gibi, çıktısı serbest metinler olan kullanım senaryoları için ROUGE ve Cosine benzerliği gibi metotlar önerilebilir.
Ancak bazı durumlarda, tek bir doğru cevap olmayabilir. Örneğin, “Dijital Dönüşüm konulu sitemiz için slogan öner” gibi bir soru için, bir çok farklı yanıt oluşturulabilir. Bu gibi durumları test edebilmek için etiketli bir veri bulunamayacağı için şu metotlar önerilebilir:
- İnsan müdahelesi (Human-in-the-loop HIL) – Bu yöntemde, modelin yanıtları yönerge test ekipleri (prompt testers) tarafından gözden geçirilir. Uygun bulunan ve uygun olmayan yanıtlar işaretlenir. Modelin kritikliğine göre, bazen bir grup çıktı, bazen ise çıktıların tamamının gözden geçirilmesi gerekebilir.
- Dil modeli ile değerlendirme: Bu senaryoda yönerge test ekibi yerine, bir dil modeli yer alır. Bu aşamada tercih edilen dil modeli, haliyle daha gelişmiş bir model olmalıdır. Örneğin, kurum içi kullanım amaçlı hazırlanacak bir modelin çıktılarının, ChatGPT API’si aracılığıyla bir tur değerlendirilmesi, bir başlangıç maliyeti çıkaracak olsa da, işin sonunda kurumda tekrar kullanılabilir ve maliyet oluşturmayacak bir model kalacaktır.
Sonuç Olarak
Geleneksel makine öğrenimi modelleri için tasarlanan süreçler, iş üretken yapay zeka (generative AI) uygulamalarına geldiğinde yeni roller, tanımlar ve teknolojiler gerektirebilmektedir. Bu yazıda FMOps ve LLMOps için temel bir konsept tasarlamak, MLOps ile aralarındaki olası insan, süreç ve teknoloji farklarına değinmek, belirli bir kullanım senaryosu için bir temel modelin seçimi ve değerlendirilmesi adımlarını tartışmak istedim.
Umarım devam yazısı olarak farklı iş alanları için farklı temel model ve büyük dil modeli çözümlerinin nasıl teslim edilebileceğini, temel modellerin “halüsinasyon” ve “eğilim” gibi problemler oluşturma ihtimaline karşı nasıl izlemeye alınabileceğini, dil modellerinin özel veriler ile entegrasyonunda kullanılabilecek mimari yaklaşımları (örneğin Retrieval Augmented Generation) da ele alacağım.