Gerçek uygulamalar için istemler oluştururken önemli bir denge unsuru ortaya çıkar: Kısa ve öz olma ile etkili olma arasında denge kurmak. Tüm faktörler eşit olduğunda kısa bir istem, daha uzun bir isteme kıyasla daha hızlı, daha ucuz ve bakımı daha kolaydır. Bu durum, özellikle gecikme ve jeton sınırlarının önemli olduğu web ortamlarında geçerlidir. Ancak isteminiz çok kısa olursa model, yüksek kaliteli sonuçlar üretmek için gerekli bağlam, talimat veya örneklerden yoksun kalabilir.
Değerlendirmeye dayalı geliştirme (EDD), bu dengeyi sistematik olarak izlemenize ve optimize etmenize olanak tanır. Çıktıları küçük ve güvenli adımlarla iyileştirmek, gerilemeleri yakalamak ve model davranışını zaman içinde kullanıcı ve ürün beklentileriyle uyumlu hale getirmek için tekrarlanabilir ve test edilebilir bir süreç sunar.
Bunu, test odaklı geliştirme (TDD) olarak düşünebilirsiniz. Bu yöntem, yapay zekanın belirsizliğine uyarlanmıştır. Belirleyici birim testlerinin aksine, hem iyi biçimlendirilmiş hem de başarısız olan çıkışlar beklenmedik şekiller alabileceğinden yapay zeka değerlendirmeleri sabit kodlanamaz.
EDD, keşif çalışmalarınızı da destekler. Test yazmak bir özelliğin davranışını netleştirmeye yardımcı olduğu gibi, değerlendirme ölçütlerini tanımlamak ve model çıkışlarını incelemek de netlik eksikliğiyle yüzleşmenizi sağlar. Ayrıca, açık uçlu veya bilinmeyen görevlere yavaş yavaş daha fazla ayrıntı ve yapı eklemenizi sağlar.
Sorunu tanımlama
Giriş türü, çıkış biçimi ve ek kısıtlamalar da dahil olmak üzere sorununuzu bir API sözleşmesi gibi çerçeveleyebilirsiniz. Örneğin:
- Giriş türü: Blog yayını taslağı
- Çıkış biçimi: 3 gönderi başlığı içeren JSON dizisi
- Kısıtlamalar: 128 karakterden kısa olmalı ve samimi bir üslup kullanılmalıdır.
Ardından örnek girişleri toplayın. Veri çeşitliliğini sağlamak için hem ideal örnekler hem de gerçek, karmaşık girişler ekleyin. Varyasyonları ve uç durumları (ör. emoji içeren yayınlar, iç içe yerleştirilmiş yapı ve çok sayıda kod snippet'i) göz önünde bulundurun.
Temel çizgiyi başlatma
İlk isteminizi yazın. Sıfır görevli ile başlayın ve net talimatlar, çıkış biçimi ve giriş içeriği için bir değişken yer tutucu ekleyin.
Sisteminizi daha karmaşık hale getirir ve yapay zeka sisteminizi optimize etmek için ek bileşenler veya istem teknikleri kullanırsınız. Zamanımızı verimli bir şekilde kullanmak ve doğru bileşenleri optimize etmek için bir değerlendirme sistemi oluşturmanız gerekir.
Değerlendirme sisteminizi oluşturma
TDD'de, gereksinimleri öğrendikten sonra test yazmaya başlarsınız. Üretken yapay zekada, test edilecek kesin çıkışlar olmadığından değerlendirme döngünüzü oluşturmak için daha fazla çaba göstermeniz gerekir.
Etkili bir değerlendirme için birden fazla ölçüm aracı kullanmanız gerekebilir.
Değerlendirme metriklerinizi tanımlayın
Değerlendirme metrikleri deterministik olabilir. Yani bilinen ve doğru bir yanıt vardır. Örneğin, modelin geçerli JSON döndürüp döndürmediğini veya doğru sayıda öğe çıkışı verip vermediğini kontrol edebilirsiniz.
Ancak yapay zeka ile zamanınızın çoğunu öznel ve niteliksel ölçümleri belirlemeye ve iyileştirmeye ayıracaksınız. Çıkış kalitesi, fayda, üslup ve yaratıcılık buna dahildir. Çıkışın beklentilerinizi nasıl karşılaması gerektiğiyle ilgili daha geniş kapsamlı başarı hedefleriyle başlayabilirsiniz. Sonunda, hedeflerinizi daha iyi tanımlamanıza yardımcı olacak belirli ve ayrıntılı sorunlarla karşılaşacaksınız.
Örneğin, başlık oluşturucunuzun belirli ifadeleri veya kalıpları aşırı kullandığını ve bu nedenle tekrarlayan, mekanik sonuçlar verdiğini varsayalım. Bu durumda, varyasyonu teşvik etmek ve aşırı kullanılan yapıları veya anahtar kelimeleri engellemek için yeni metrikler tanımlamanız gerekir. Zaman içinde temel metrikleriniz dengelenecek ve iyileşmeleri takip edebileceksiniz.
Bu süreçte, uygulamanızın alanında iyi olanın nasıl göründüğünü anlayan ve ince hata modlarını tespit edebilen uzmanlardan yararlanılabilir. Örneğin, bir yazma asistanı geliştiriyorsanız değerlendirmenizin içerik üreticinin veya editörün dünya görüşüyle uyumlu olduğundan emin olmak için bir içerik üretici ya da editörle birlikte çalışın.
Hakemlerinizi seçin
Farklı değerlendirme ölçütleri için farklı değerlendiriciler gerekir:
- Koda dayalı kontroller, deterministik veya kurala dayalı çıktılar için iyi sonuç verir. Örneğin, başlıklarda kaçınmak istediğiniz kelimeleri tarayabilir, karakter sayılarını kontrol edebilir veya JSON yapısını doğrulayabilirsiniz. Bunlar hızlı, tekrarlanabilir ve düğmeler veya form alanları gibi sabit çıkışlı kullanıcı arayüzü öğeleri için mükemmeldir.
- Üslup, netlik veya fayda gibi daha öznel nitelikleri değerlendirmek için insan geri bildirimi çok önemlidir. Özellikle başlangıçta model çıkışlarını kendiniz (veya alan uzmanlarıyla) incelemek hızlı yinelemeye olanak tanır. Ancak bu yaklaşım iyi ölçeklenmez. Uygulamanızı başlattıktan sonra yıldız derecelendirmesi gibi uygulama içi sinyaller de toplayabilirsiniz ancak bunlar genellikle gürültülüdür ve hassas optimizasyon için gereken ayrıntıdan yoksundur.
- LLM-as-judge, çıktıları puanlamak veya eleştirmek için başka bir yapay zeka modeli kullanarak öznel ölçütleri değerlendirmenin ölçeklenebilir bir yolunu sunar. Uzman incelemesinden daha hızlı olsa da bu yöntemin de dezavantajları vardır: Basit bir uygulamada, modelin önyargılarını ve bilgi eksikliklerini devam ettirebilir, hatta güçlendirebilir.
Kaliteye nicelikten daha fazla önem verin. Klasik makine öğrenimi ve tahmine dayalı yapay zekada, veri ek açıklaması için kitle kaynaklarından yararlanmak yaygın bir uygulamadır. Üretken yapay zeka için kitle kaynaklı açıklama ekleyenler genellikle alan bağlamına sahip değildir. Ölçekten daha çok, yüksek kaliteli ve bağlam açısından zengin değerlendirme önemlidir.
Değerlendirme ve optimizasyon
İstemlerinizi ne kadar hızlı test edip iyileştirebilirseniz kullanıcı beklentileriyle uyumlu bir sonuç elde etmeniz de o kadar hızlı olur. Sürekli optimizasyon alışkanlığı kazanmanız gerekir. İyileştirme yapmayı, değerlendirmeyi ve başka bir şey denemeyi deneyin.
Üretime geçtikten sonra kullanıcılarınızın ve yapay zeka sisteminizin davranışını gözlemlemeye ve değerlendirmeye devam edin. Ardından bu verileri analiz edin ve optimizasyon adımlarına dönüştürün.
Değerlendirme ardışık düzeninizi otomatikleştirme
Optimizasyon çalışmalarınızdaki zorlukları azaltmak için değerlendirmeyi otomatikleştiren, değişiklikleri izleyen ve geliştirme ile üretimi birbirine bağlayan bir operasyonel altyapıya ihtiyacınız vardır. Bu durum genellikle LLMOps olarak adlandırılır. Otomasyon konusunda yardımcı olabilecek platformlar olsa da üçüncü taraf bir çözümü kullanmaya başlamadan önce ideal iş akışınızı tasarlamanız gerekir.
Göz önünde bulundurmanız gereken bazı önemli bileşenler şunlardır:
- Sürüm oluşturma: Mağaza istemlerini, değerlendirme metriklerini ve test girişlerini sürüm kontrolünde saklayın. Tekrarlanabilirliği ve net değişiklik geçmişini sağlamak için bunları kod olarak değerlendirin.
- Otomatik toplu değerlendirmeler: Her istem güncellemesinde değerlendirme çalıştırmak ve karşılaştırma raporları oluşturmak için iş akışlarını (ör. GitHub Actions) kullanın.
- İstemler için CI/CD: Dağıtımları, deterministik testler, büyük dil modeli (LLM) puanları veya koruma duvarları gibi otomatik kontrollerle sınırlayın ve kalite gerilediğinde birleştirmeleri engelleyin.
- Üretim günlük kaydı ve gözlemlenebilirlik: Girişleri, çıkışları, hataları, gecikmeyi ve jeton kullanımını yakalayın. Sapma, beklenmedik kalıplar veya hatalarda ani artış olup olmadığını izleyin.
- Geri bildirim alımı: Kullanıcı sinyallerini (beğenme, yeniden yazma, bırakma) toplayın ve tekrarlanan sorunları yeni test senaryolarına dönüştürün.
- Deneme izleme: İstem sürümlerini, model yapılandırmalarını ve değerlendirme sonuçlarını izleyin.
Küçük ve hedeflenmiş değişikliklerle yineleme yapın
İstem ayrıntılandırma genellikle isteminizin dilini iyileştirmekle başlar. Talimatları daha spesifik hale getirmek, amacı netleştirmek veya belirsizlikleri ortadan kaldırmak bu kapsamda değerlendirilebilir.
Aşırı uyumdan kaçınmaya dikkat edin. Model sorunlarını düzeltmek için çok dar kurallar eklemek sık karşılaşılan bir hatadır. Örneğin, başlık oluşturucunuz sürekli olarak The Definitive Guide (Kesin Kılavuz) ile başlayan başlıklar üretiyorsa bu ifadeyi açıkça yasaklamak cazip gelebilir. Bunun yerine, sorunu soyutlayın ve üst düzeydeki talimatı ayarlayın. Bu, özgünlüğe, çeşitliliğe veya belirli bir editoryal tarza vurgu yaptığınız anlamına gelebilir. Böylece model, tek bir istisna yerine temel tercihi öğrenir.
Başka bir yol da daha fazla istem tekniği denemek ve bu çabaları birleştirmektir. Bir teknik seçerken kendinize şu soruyu sorun: Bu görev en iyi şekilde analoji (az görevli), adım adım muhakeme (düşünce zinciri) veya yinelemeli iyileştirme (öz yansıtma) ile mi çözülür?
Sisteminiz üretime geçtiğinde EDD çarkınız yavaşlamamalıdır. Hatta hızlanması gerekir. Sisteminiz kullanıcı girişini işleyip günlüğe kaydediyorsa bu girişler en değerli analiz kaynağınız olmalıdır. Değerlendirme paketinize yinelenen kalıplar ekleyin ve sürekli olarak bir sonraki en iyi optimizasyon adımlarını belirleyip uygulayın.
Önemli noktalar
Değerlendirmeye dayalı istem geliştirme, yapay zekanın belirsizliğinde yolunuzu bulmak için yapılandırılmış bir yöntem sunar. Sorununuzu net bir şekilde tanımlayarak, özel bir değerlendirme sistemi oluşturarak ve küçük, hedeflenmiş iyileştirmelerle yineleme yaparak model çıkışlarını sürekli olarak iyileştiren bir geri bildirim döngüsü oluşturursunuz.
Kaynaklar
LLM-as-judge'i uygulamak istiyorsanız önerilen bazı okuma materyallerini aşağıda bulabilirsiniz:
- LLM'nin özetleme özelliğini karşılaştırma
- Hamel Husain'in LLM-as-a-Judge (Yargıç olarak LLM) kullanım kılavuzunu okuyun.
- A Survey on LLM-as-a-Judge (LLM'nin Yargıç Olarak Kullanılmasıyla İlgili Bir Anket) başlıklı makaleyi okuyun.
İstemlerinizi daha da iyileştirmek istiyorsanız bağlama duyarlı geliştirme hakkında daha fazla bilgi edinin. Bu işlem en iyi şekilde bir makine öğrenimi mühendisi tarafından yapılabilir.
Anlayıp anlamadığınızı kontrol etme
Değerlendirmeye dayalı geliştirmenin birincil hedefi nedir?
İstemci tarafı bir sistemi değerlendirmek için neden daha büyük modeller kullanmalısınız?
Değerlendirme için LLM'yi hakem olarak kullanmanın olası dezavantajı nedir?
Hangi bileşen, önerilen otomatik değerlendirme işlem hattının bir parçasıdır?
Değerlendirme sisteminiz için hakem seçerken insan geri bildirimi kullanmanın temel sınırlaması nedir?