Üretim ortamında büyük bir dil modelini çalıştırmak artık yalnızca modeli eğitmek, test etmek, dağıtmak ve gösterge tablolarını izlemekten ibaret değil. Modern bir sistem; istemleri, vektör veritabanlarını ve bilgi kaynaklarını birbirine bağlayabilir, ardından doğruluğun yanı sıra ton, güvenlik ve güvenilirlik açısından değerlendirilen açık uçlu metinler üretebilir. Daniel Bryant, CNCF blogunda yayımlanan bir yazısında buradan hareketle pratik bir soru soruyor: Yapay zekâ işlem hattının sahibi kim olmalı?
Yazar, yanıtın LLMOps’a ayrı bir krallık vermekte değil, gerekli yetenekleri geliştirme ekiplerinin iş yüklerinin geri kalanında kullandığı arayüzlerin aynısı üzerinden sunan, iyi yapılandırılmış bir mühendislik platformuna entegre etmekte olduğunu düşünüyor.
LLMOps nedir?
LLMOps, büyük dil modellerini geliştirmek, dağıtmak ve üretim yaşam döngüleri boyunca yönetmek için gereken uygulamalar, araçlar ve iş akışları kümesini ifade eder. Bu döngü; veri yönetimi, istem mühendisliği, ince ayar, dağıtım ve çıkarım hizmeti, izleme ve değerlendirme ile güvenlik ve yönetişimi kapsar.
Analize göre LLMOps, MLOps’un yalnızca yeniden adlandırılması değildir. Büyük dil modellerinin ince ayar ve hizmet maliyetleri daha yüksektir; ayrıca çıktılarını değerlendirmek, performansı açık bir doğruluk sayısına indirgemekten daha zordur. Modelin doğru olması yeterli değildir; aynı zamanda güvenli ve güvenilir olması gerekir ve bu özellikleri ölçmek daha karmaşıktır.
Modelin işletilmesi ilk dağıtımda sona ermez. Modeller önceki davranışlarından sapabilir, maliyetler artabilir, istemler alışıldığı şekilde çalışmayı bırakabilir ve müşteri ilişkileri yönetimi sistemleriyle veya kurum içi bilgi tabanlarıyla entegrasyonların sürekli izlenmesi gerekebilir.
Platform mühendisliğiyle kesişen yaşam döngüsü
LLMOps yaşam döngüsü, istemlerin geçici metinler yerine sürümlenebilir öğeler olarak ele alınmasıyla veri hazırlama ve istem mühendisliğinden, Hugging Face Transformers gibi kütüphaneler kullanılarak açık temel modellerin ince ayarına kadar uzanır. Ayrıca modellerin ve istemlerin sürümlenmesini ve soy bilgilerinin izlenmesini, grafik işlem birimleriyle desteklenen uç noktalar üzerinden çıkarım sunulmasını ve sapmayı ve maliyeti izlemek için insan geri bildirimlerine dayalı izlemeyi de kapsar.
Bu döngünün her bölümü altyapıya, erişim kontrollerine ve bir çalışma ortamına ihtiyaç duyar; bunlar da zaten platform mühendisliğinin kapsamına giren alanlardır. Ancak yazar iki alanın doğası arasında ayrım yapar: Platform mühendisliği altyapıya, MLOps ise modellere odaklanır. Bu nedenle faydalı sorunun “İşlem hattının sahibi kim?” değil, “Her katmanın sahibi kim ve bunları gerçekten koordine eden bir taraf var mı?” olduğunu düşünür.
Paralel bir yığın oluşturma riski
Analiz, yazılım teslimi ortamını dağıtım talepleri altında ezilebilen DevOps ekiplerine, self servis için standart yollar oluşturan platform mühendisliği ekiplerine ve DevOps araçları veri sürümlerini yönetmek veya sapmayı izlemek üzere tasarlanmadığı için paralel yığınlar oluşturan MLOps ekiplerine ayırıyor. LLMOps’un eklenmesiyle, yönetişimden sorumlu taraftan uzakta, istemler, vektör veritabanları ve RAG işlem hatları için bağımsız üçüncü bir yığın ortaya çıkabilir.
Yazar bu olasılığı “gizli yapay zekâ operasyonları” sorunuyla ilişkilendiriyor. Ekiplerden biri, denetlenmemiş bir vektör veritabanına bağlı kendi RAG işlem hattını oluşturabilir ve sorumlu tarafın gerçekte neyin çalıştığı konusunda net bir görüşü olmayabilir. Analize göre en büyük operasyonel risk yalnızca halüsinasyon üreten bir sohbet robotu değildir; bu yeteneklerin platformun dışına yayılması ve ardından görünürlük ve kontrol kapsamının dışında kalmasıdır.
Yazar bunu önlemek için ekipleri yavaşlatmayı değil, platformu talepleri yönetişimi kullanım yolunun içine yerleştirerek hızla karşılayabilecek hâle getirmeyi öneriyor. Hazır bir yolun bulunmaması ekipleri yeteneklerini platform dışında oluşturmaya itebilirken, standart bir yolun sunulması bu yeteneklerin yönetilebilir bir ortama geri alınmasına yardımcı olur.
Platform katmanları içinde LLMOps
Bryant, CNCF’nin TAG App Delivery grubuna bağlı Platforms Working Group tarafından yayımlanan platformlar beyaz kitabının tasarımından yararlanıyor. Bu tasarım ortamı üç katmana ayırıyor: üstte ürünler, ortada makul ölçüde en ince entegrasyon katmanı olarak platformlar ve altta yetenek sağlayıcıları.
Bu tasarıma göre ince ayar görevleri, vektör veritabanları, istem günlükleri ve çıkarım uç noktaları gibi işlevler başka bir platform yeteneği olarak ele alınabilir. Bunlar da diğerleri gibi API’lere, sürümlere ve açık sahipliğe ihtiyaç duyar. Yazar, CNCF ekosistemindeki araçların bu modeli destekleyebileceğine işaret ediyor: Backstage ürün katmanında standart yolları sunarken Crossplane altyapıyı alt katmana yerleştiriyor; Kratix, KusionStack ve KubeVela gibi çerçeveler ise ortada çalışarak LLM işlem hattını diğer hizmetlerdekine benzer bir self servis arayüz üzerinden kullanılabilir hâle getiriyor.
İşlem hattı yönetişimi için pratik kontroller
Analiz, platform ekiplerinin bir dizi pratik kontrolü benimsemesini öneriyor:
- Gayriresmî betikler yerine yönetilen API’ler: İnce ayar görevleri, istem dağıtımları ve çıkarım uç noktaları, geliştiricilerin diğer ihtiyaçları için kullandığı self servis arayüz üzerinden talep edilmelidir.
- Talep sırasında politika uygulama: Maliyet sınırları, veri yerleşimi kuralları ve model erişim kontrolleri, bulut hizmetleri faturası ortaya çıktıktan sonra değil, görev başlamadan önce denetlenmelidir.
- Etkinin boyutuyla orantılı insan onayı: Her istemin önceden onaylanması gerekmez; ancak müşterilerin kişisel verileriyle ilgilenen veya bağımsız kararlar alan bir model bunu gerektirebilir.
- Açık bir denetim günlüğü: Günlük; değişikliğin modelle, istemle veya verilerle ilgili olup olmadığı fark etmeksizin neyin ve neden değiştiği, değişikliği kimin onayladığı veya neyin onaylandığı gibi soruları yanıtlamalıdır.
Yazar, LLM işlem hattının platform yeteneklerinin başka bir otomatik tüketicisi olduğu ve insan geliştirici veya bağımsız aracıya sağlanan güvencelerin aynısına ihtiyaç duyduğu sonucuna varıyor. Bu modelde başarılı olan ekipler DevOps, platform ve MLOps arasındaki anlaşmazlıkta taraf seçmek yerine, işlem hattının tamamını sürekli geri bildirim döngüleriyle sürümlenebilir, izlenebilir ve maliyetin gözetildiği bir ürün olarak ele alıyor.
Bu anlamda Bryant, LLMOps’un sahiplik sorununu ortadan kaldırdığını veya yeniden icat ettiğini düşünmüyor; bunun yerine modellerin boyutu, yüksek maliyetleri ve değerlendirme zorluğu nedeniyle mevcut platformları daha büyük bir baskı altına soktuğunu belirtiyor. Ona göre çözüm, standart yolu bir kez oluşturmak ve ardından bunu geliştiriciye, veri bilimciye ve akıllı aracıya ortak bir API veya kullanıcı arayüzü üzerinden yönetilen bir yetenek olarak sunmaktır. Bu tartışmanın CNCF içinde, özellikle TAG App Delivery’ye bağlı Platforms Working Group’ta sürdüğünü ve katkıda bulunmak isteyen herkese açık olduğunu belirtiyor.