Gerçek uygulamalar için istemler oluştururken önemli bir denge unsuru ortaya çıkar: Kısa ve öz olma ile etkili olma arasındaki denge. Tüm faktörler eşit olduğunda kısa bir istem, daha uzun bir isteme göre daha hızlı, daha ucuz ve daha kolay korunur. 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 gereken bağlam, talimat veya örneklerden yoksun olabilir.
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 gönderiler, iç içe yerleştirilmiş yapı ve çok sayıda kod snippet'i) hakkında düşünün.
Temel çizgiyi başlatma
İlk isteminizi yazın. Sıfır görevli ile başlayabilir ve şunları ekleyebilirsiniz:
- Net talimat
- Çıkış biçimi
- Giriş değişkeni için yer tutucu
Değerlendirme ve optimizasyon yaparken karmaşıklığı artırır, diğer bileşenlerle ve gelişmiş istem teknikleriyle çalışırsınız. İlk olarak, optimizasyon çalışmalarını doğru yöne yönlendirmek için bir değerlendirme sistemi oluşturmamı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. Ö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 zamanınızın büyük bir kısmını netlik, fayda, üslup veya yaratıcılık gibi öznel ya da nitel metrikleri belirlemeye ve iyileştirmeye ayırmanız gerekir. Geniş kapsamlı hedeflerle başlayabilirsiniz ancak kısa süre içinde daha ayrıntılı sorunlarla karşılaşabilirsiniz.
Örneğin, başlık oluşturucunuzun belirli ifadeleri veya kalıpları aşırı kullandığını ve bu nedenle tekrarlayan, robotik 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ımlarsınız. Zaman içinde temel metrikleriniz dengelenecek ve iyileşmeleri takip edebileceksiniz.
Bu süreçte, uygulamanızın alanında iyi olanın neye benzediğini bilen 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.
- Ton, netlik veya fayda gibi daha öznel nitelikleri değerlendirmek için insan geri bildirimi şarttır. Ö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. Yüksek kaliteli ve bağlam açısından zengin değerlendirme, ölçekten daha ö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ştirmeyi üretime bağlayan operasyonel bir altyapıya ihtiyacınız vardır. Bu, 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:
- Sürüm oluşturma: Mağaza istemlerini, değerlendirme metriklerini ve test girişlerini sürüm kontrolünde saklayın. Tekrarlanabilirlik ve net değişiklik geçmişi 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, LLM-as-judge 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) toplama ve yinelenen sorunları yeni test senaryolarına dönüştürme.
- 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 iyileştirme 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 isteyebilirsiniz. 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 bu durum, süreci hızlandırabilir. Sisteminiz kullanıcı girişini işleyip günlüğe kaydediyorsa bu bilgiler 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 aşağıdaki kaynakları incelemenizi öneririz:
- LLM'nin özetleme özelliğini karşılaştırın.
- Hamel Husain'in LLM'yi yargıç olarak kullanma 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 kullanılır?
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?