Azure OpenAI Service ile Kurumsal Uygulama Nasıl Geliştirilir?

Azure OpenAI Service nedir, neden kurumsal ortamlarda tercih edilir?

Azure OpenAI Service, OpenAI'ın dil modellerine Microsoft Azure altyapısı üzerinden erişim sağlayan bir bulut hizmetidir. Modelleri bir uygulamanın içinden REST arayüzü ya da yazılım geliştirme kitleriyle çağırırsınız; hizmet ise Azure'un kimlik, ağ ve uyumluluk altyapısı içinde çalışır.

Kurumsal ekiplerin bu yolu seçmesinin pratik nedenleri vardır: mevcut Azure aboneliği ve fatura yapısı içinde kalmak, kuruluşun kimlik yönetimiyle bütünleşmek, özel ağ üzerinden erişim kurabilmek ve veri işleme taahhütleri hakkında kurumsal sözleşme zemininde ilerlemek. Hangi modellerin hangi bölgelerde sunulduğu ve hizmet koşulları Microsoft tarafından zaman içinde değiştiğinden, kesin ayrıntılar için resmî Azure dokümantasyonuna bakılmalıdır.

Hizmetin ve çevresindeki platformun adları da değişiyor. Microsoft'un güncel dokümantasyonunda platform Microsoft Foundry adıyla, modeller ise Azure OpenAI in Microsoft Foundry Models başlığıyla anılıyor; eski belgelerde, adreslerde ve örnek kodlarda platformun önceki adına hâlâ rastlanabilir. Portal ve menü adlarını izlerken güncel Microsoft Learn sayfalarını esas alın; bu sayfadaki mimari ve güvenlik ilkeleri ad değişikliğinden etkilenmez.

Bir uygulama hangi mimari parçalardan oluşur?

Tipik bir kurumsal uygulama dört katmandan oluşur:

• Model katmanı: Azure üzerinde bir kaynak oluşturulur, kullanılacak model bu kaynağa bir dağıtım (deployment) olarak eklenir. Uygulama modeli bu dağıtımın adıyla çağırır.
• Uygulama katmanı: İş mantığını taşıyan servis; istekleri düzenler, istem (prompt) şablonlarını yönetir, yanıtı işler.
• Veri katmanı: Modelin kuruma özgü bilgiyle cevap verebilmesi için kullanılan belge deposu, veritabanı ya da arama hizmeti.
• Platform katmanı: Kimlik, gizli bilgi yönetimi, ağ kuralları, günlük kayıtları ve izleme.

Bu ayrım, modeli değiştirmek ya da güncellemek gerektiğinde uygulamanın geri kalanına dokunmadan hareket etmeyi kolaylaştırır.

RAG kullanan uygulamalarda veri katmanının kalitesi çıktıyı doğrudan belirler: belgelerin güncel tutulması, parçalara anlamlı bölünmesi ve erişim yetkisine göre filtrelenmesi gerekir. Kullanıcının göremeyeceği bir belge parçası modele bağlam olarak verilirse, yanıt üzerinden yetkisiz bilgi sızabilir; bu nedenle yetki denetimi arama aşamasında uygulanmalıdır.

Adım adım uygulama geliştirme

Geliştirme genellikle şu sırayla ilerler:

• Kullanım senaryosunu daraltmak: Belge özetleme, müşteri sorusu yanıtlama, iç bilgi arama gibi tek bir somut iş seçilir.
• Kaynağı ve dağıtımı kurmak: Uygun bölgede kaynak açılır, ihtiyaca uygun model dağıtılır.
• İlk istem tasarımı: Sistem mesajı ile modelin rolü, tonu ve sınırları tanımlanır.
• Kuruma özgü veriyi bağlamak: Yanıtların şirket belgelerine dayanması için arama destekli üretim (RAG) yaklaşımı kullanılır; ilgili parçalar önce bulunur, sonra modele bağlam olarak verilir.
• Değerlendirmek: Gerçek soru örnekleriyle yanıt kalitesi, doğruluk ve tutarlılık test edilir.

Örneğin bir insan kaynakları ekibi, çalışan politikalarını yanıtlayan bir asistan kurmak istesin. Politika belgeleri aranabilir hale getirilir, çalışan sorusuna en uygun bölümler bulunur ve model yalnızca bu bölümlere dayanarak cevap üretir. Kaynak göstermesi istenirse çalışan yanıtı doğrulayabilir.

Değerlendirme adımını somutlaştırmak için bir test seti hazırlayın: gerçek kullanıcı sorularından derlenmiş örnekler, her biri için beklenen yanıtın özeti ve yanıtın dayanması gereken kaynak belge. Her istem ya da model değişikliğinden sonra aynı set yeniden çalıştırılır; yanıtlar beklenen özetten saptığında değişiklik geri alınır. Bu alışkanlık, özellikle model sürümü güncellendiğinde sessiz kalite kaybını yakalar.

Güvenlik nasıl sağlanır?

Güvenlik, uygulamayı çalıştırmadan önce tasarlanmalıdır. Başlıca kontroller şunlardır:

• Kimlik tabanlı erişim: Sabit anahtarları kod içinde tutmak yerine kurumsal kimlik yönetimiyle yetkilendirme ve gizli bilgilerin güvenli bir kasada saklanması.
• Ağ sınırları: Hizmete yalnızca özel ağ üzerinden erişim, gerekmeyen genel erişimin kapatılması.
• İçerik denetimi: Zararlı ya da uygunsuz girdi ve çıktıyı sınırlayan filtreleme ayarları.
• Veri sınıflandırması: Hangi verinin modele gönderilebileceği, hangi verinin maskelenmesi gerektiği kararı.
• Erişim kayıtları: Kim, ne zaman, hangi isteği gönderdi bilgisinin denetim için tutulması.

Unutulmaması gereken nokta, zafiyetlerin yalnızca modelde değil, çevresindeki uygulamada da oluşabilmesidir: aşırı geniş yetkiler, istemlere gömülü hassas bilgi ve kullanıcı girdisinin denetlenmemesi gibi.

İzleme ve maliyet nasıl yönetilir?

Kullanım bedeli ve kota kuralları Microsoft'un güncel sayfalarında yayımlanır. Maliyeti öngörülebilir kılmak için birkaç alışkanlık işe yarar.

Bunların ilki kullanımı ölçmektir: hangi uygulama, hangi ekip ve hangi özellik ne kadar kullanıyor. Etiketleme ve ayrı kaynak kullanımı bu ayrımı kolaylaştırır. İkincisi istemleri kısa ve amaca yönelik tutmak, gereksiz bağlamı modele göndermemektir. Üçüncüsü bütçe uyarıları ve kullanım sınırı koymaktır; böylece hatalı bir döngü ya da beklenmedik yoğunluk faturayı sürpriz hale getirmez.

İzleme tarafında yanıt süresi, hata oranı ve kullanıcı geri bildirimi birlikte takip edilir. Model davranışının zamanla değişebileceği düşünülürse, düzenli aralıklarla aynı test sorularını yeniden çalıştırmak kaliteyi korumanın basit bir yoludur.

Sık yapılan hatalar

• Prototipi güvenlik ve maliyet kontrolleri olmadan doğrudan canlıya çıkarmak.
• Modelin kuruma özgü bilgiyi "bildiğini" varsaymak; kaynak göstermeyen yanıtlara güvenmek.
• Tek bir istem denemesine bakıp uygulamayı onaylamak, gerçek kullanıcı sorularıyla test etmemek.
• Hassas veriyi sınıflandırmadan modele göndermek.
• Değerlendirme ve izleme yapısı kurmadan model sürümünü değiştirmek.

Öğrenme yolu çoğu zaman şöyle ilerler: önce hizmeti ve temel çağrıları tanımak, sonra istem tasarımı ve RAG'ı denemek, ardından güvenlik, izleme ve maliyet yönetimini ekleyerek kurumsal bir senaryoya taşımak.

Bir başka hata, hata durumlarını düşünmemektir. Hizmet yoğun olduğunda ya da kota aşıldığında uygulamanın nasıl davranacağı (yeniden deneme, bekleme, kullanıcıya anlaşılır mesaj) önceden tasarlanmalıdır; aksi halde kullanıcı boş ekranla karşılaşır.

Bu beceriyi Mindset programlarında nerede çalışırsınız?

"Azure OpenAI Service ile Uygulama" programının modül başlıkları şunlardır: Azure OpenAI Service mimarisi, Azure yapay zeka ekosistemi entegrasyonu, Azure üzerinde uygulama geliştirme, güvenlik, izleme ve maliyet yönetimi ile kurumsal senaryo atölyesi. Yukarıdaki mimari, güvenlik ve maliyet başlıkları bu modüllerle aynı sırayı izler.