Blog
Modeli değiştirmek zorunda kalırsanız elinizde ne kalır
Kısaca: Kurumlarda yapay zeka işleri tek bir modele yapışık halde büyüyor. O model sürüm değiştirdiğinde, fiyatı arttığında ya da koşulları değiştiğinde geriye taşınabilir hiçbir şey kalmıyor. Taşınabilirlik pahalı bir mimari yatırımı değil, birkaç saatlik yazı işi: neye bağlı olduğunuzu, neyi doğru saydığınızı ve ne kadar ödediğinizi yazılı hale getirmek. Aşağıda bunu bu hafta yapmanızı sağlayan beş prompt var.
Kurumlarda yapay zeka kurulumları hep aynı şekilde büyüyor. Bir ekip bir modelle iyi sonuç alır. O modelin adı promptlara, kodlara, sunumlara, bir süre sonra da sözleşmeye yazılır. Altı ay sonra elinizde o modele yapışık on beş iş vardır ve hiçbiri bu şekilde tasarlanmamıştır; öylece olmuştur.
Sonra bir şey değişir. Sürüm emekliye ayrılır, fiyat listesi güncellenir, kurumsal anlaşmanın bir maddesi değişir, ya da işinize açıkça daha uygun bir alternatif çıkar. O an masada tek bir soru vardır: bunu değiştirirsek ne bozulur?
Çoğu kurumda bu sorunun cevabı yoktur. Cevabın olmaması tek başına bir risktir, çünkü cevabı olmayan kurum modeli değiştiremez. Değiştiremeyen kurum ise fiyatı, koşulu ve hizmet seviyesini tartışamaz. Pazarlık gücü tam olarak burada kaybedilir.
Model değişimi arıza değil, takvim işidir
Sağlayıcılar sürümlerini düzenli aralıklarla yeniliyor ve eskilerini bir süre sonra kapatıyor. Bu bir kaza değil, bu işin normal işleyişi. Yani doğru soru "değişir mi" değil, "ne zaman değişir ve o gün ne yaparız".
Bunu kabul ettiğiniz anda yaptığınız iş de değişir. Amaç en iyi modeli seçmek olmaktan çıkar, seçtiğiniz model değiştiğinde ayakta kalmak olur. İki hedef birbirine benziyor ama farklı işler yaptırır: birincisi karşılaştırma tablosu hazırlatır, ikincisi belge yazdırır.
İyi haber, taşınabilirliğin sandığınız kadar pahalı olmaması. Gereken şeylerin çoğu altyapı değil, yazı işi. Bugün kimsenin yazmadığı üç dört belge, bir modelden diğerine geçişi haftalar süren bir projeden yarım günlük bir tatbikata indiriyor.
Önce neye bağlı olduğunuzu yazın
Bağımlılık genellikle sanıldığı yerde değildir. İnsanlar "model adını değiştiririz olur biter" der; asıl bağ, sadece o sağlayıcıda bulunan bir özellikte, ona özel bir arayüzde ya da veri saklama koşulunda gizlidir.
Asagida kurumumuzda yapay zeka kullanan bir isin tanimi
ve varsa teknik notlari var.
Bu isin tek bir model saglayicisina nerelerden bagli
oldugunu cikar. Su basliklari ayri ayri doldur:
- model adi veya surumu dogrudan yazili olan yerler,
- sadece o saglayicida bulunan ozellikler,
- o saglayiciya ozel arayuz, kutuphane veya SDK,
- veri saklama ve gizlilik kosullari,
- sozlesme veya kurumsal anlasma bagi.
Her maddeye "degistirmesi kolay / orta / zor" etiketi koy
ve zor olanlarin altina neden zor oldugunu tek cumleyle yaz.
Verdigim metinde olmayan hicbir sey ekleme; eksik bilgi
varsa "bilinmiyor" yaz ve bunlari sonda ayri bir liste
olarak tekrarla.
Is tanimi: [isin ne yaptigini, hangi arayuzu kullandigini
ve varsa kod veya yapilandirma notlarini yapistirin]Bu promptun asıl çıktısı "zor" etiketli maddeler ve "bilinmiyor" listesidir. Zor maddeler önümüzdeki çeyreğin iş listesidir. Bilinmiyor listesi ise kimin neyi kurduğunu kimsenin hatırlamadığı yerleri gösterir; genellikle en riskli kısım orasıdır.
Doğruluğu modele değil, kabul setine bağlayın
"Bu model bizim işimizde daha iyi" cümlesi, karşısında bir ölçüt olmadığı sürece bir fikirdir. Model değiştirme kararını fikirle veremezsiniz; çünkü değişimden sonra bir şey bozulduğunda geri dönecek bir referansınız olmaz.
Kabul seti, işinizin doğru cevabının ne olduğunu modelden bağımsız tanımlayan küçük bir örnek listesidir. Yüzlerce örnek gerekmez; otuz iyi seçilmiş örnek, çoğu kurumsal işi kapsar.
Asagida bu isin gercek girdi ve ciktilarindan ornekler var.
Bunlardan bir kabul seti olustur. Her satirda su alanlar
olsun:
- girdi ozeti,
- kabul edilebilir ciktinin tasimasi gereken sartlar,
- kesinlikle olmamasi gereken seyler,
- bu ornegi kim dogruladi.
Sartlari "iyi", "dogru", "kaliteli" gibi kelimelerle degil,
bir insanin bakip evet-hayir diyebilecegi ifadelerle yaz.
En az bes zor ornek sec: sinirda olan, eksik bilgili,
birden fazla anlama gelen veya hatali girdi iceren durumlar.
Ciktiyi tablo olarak ver.
Ornekler: [gercek girdi-cikti ciftlerini yapistirin]Kabul setini bir kez yazdığınızda iki işe birden yarar. Model değiştirirken karşılaştırma ölçütü olur; değiştirmeseniz bile sağlayıcı sessizce sürüm güncellediğinde bozulmayı fark etmenizi sağlar. Setin sahibi teknik ekip değil, işi yapan birim olmalı.
Promptu modele değil, işe yazın
Promptlar zamanla belirli bir modelin alışkanlıklarına göre şekilleniyor: onun sevdiği etiketler, onun beklediği örnek sayısı, onun tuhaflıklarını kapatmak için eklenmiş cümleler. Bunların hiçbiri işin tarifi değil; hepsi o modele özel bandaj.
Asagidaki prompt belirli bir modele gore sekillenmis olabilir.
Onu tasinabilir hale getir. Su islemleri yap ve her
degisikligi ayri satirda gerekcesiyle listele:
- modele ozgu bicim, etiket ve komut kaliplarini ayikla,
- belirli bir modelin davranisini duzeltmek icin eklenmis
cumleleri isaretle,
- beklenen cikti bicimini acikca tarif et,
- yeterli bilgi yoksa ne yazilacagini belirt.
Sonunda iki sey ver: sadelestirilmis prompt ve degisiklik
listesi.
Promptun ne yaptigini degistirme, sadece bagimliligini azalt.
Prompt: [mevcut promptu yapistirin]Değişiklik listesini okumak, promptu okumaktan daha öğreticidir. Bandajların çoğu bir zamanlar gerçek bir sorunu çözmüştür ama o sorunun hala var olup olmadığını kimse kontrol etmemiştir.
Maliyeti ve gecikmeyi modelden bağımsız ölçün
Model değiştirme kararı çoğu zaman fiyat üzerinden konuşulur, ama listedeki birim fiyat karşılaştırılabilir bir sayı değildir. Sizin için anlamlı olan şey görev başına toplam maliyet ve görevin ne kadar sürdüğüdür.
Asagida bir isin aylik kullanim verileri var.
Model degistirmeden onceki ve sonraki hali karsilastirmak
icin bos bir olcum tablosu hazirla.
Satirlar su olcumler olsun:
- gorev basina ortalama maliyet,
- gorev basina ortalama sure,
- kabul setinden gecen ornek sayisi,
- insan mudahalesi gereken oran,
- aylik toplam maliyet.
Sutunlar: mevcut model, aday model, fark, kabul esigi.
Kabul esigi sutununu benim doldurmam icin bos birak ve
tablonun altina her olcum icin "bu esik nasil belirlenmeli"
diye tek cumlelik rehber yaz.
Sayi uydurma; sadece verdiklerimi tabloya yerlestir,
eksikleri "veri yok" olarak isaretle.
Kullanim verileri: [aylik hacim, maliyet ve sure
verilerinizi yapistirin]Eşik sütununu önceden doldurmak önemli. Aday modelin sonuçlarını gördükten sonra eşik belirlerseniz, eşiği sonuca göre ayarlarsınız ve ölçüm anlamını kaybeder.
Yarım günlük bir değiştirme provası yapın
Buraya kadarki dört belge hazırlıktır. Hazırlığın işe yarayıp yaramadığını ancak bir kez deneyerek öğrenirsiniz, ve bunu gerçek bir zorunluluk çıkmadan önce denemek gerekir.
Asagidaki is icin yarim gunluk bir model degistirme
provasi plani yaz. Plan su bolumlerden olussun:
- prova oncesi hazir olmasi gerekenler,
- saat bazli adim adim akis,
- her adimda kimin ne yapacagi,
- durdurma kosullari (provayi iptal ettirecek durumlar),
- geri donus adimlari,
- prova sonunda doldurulacak tek sayfalik rapor basliklari.
Prova gercek musteri trafigine ve gercek kisisel veriye
dokunmasin; bunu plana acikca yaz.
Bilmedigin kurumsal detaylari uydurma, "[doldurulacak]" birak.
Is: [isin adi, kullandigi model ve devreye girdigi yer]Provanın amacı aday modele geçmek değil. Amaç, geçişin kaç saat sürdüğünü ve nerede takıldığını öğrenmek. O sayı elinizde olduğunda, sağlayıcınızla yapacağınız her konuşma farklı geçer.
Nerede durmak gerekir
Bu promptlar bağımlılığı görünür kılar, ortadan kaldırmaz. Model envanter çıkarırken "bu özellik sadece şu sağlayıcıda var" gibi cümleler uydurabilir; bunları sağlayıcının kendi belgelerinden teyit etmeden karar girdisi yapmayın.
Karşılaştırmayı gerçek müşteri verisiyle yapmayın. Kabul setini maskelenmiş ya da temsili örneklerle kurun; sözleşmeniz aday sağlayıcıyla henüz imzalanmamışken oraya giden her veri ayrı bir konudur.
Provayı kimin ne kadar hızlı yaptığını ölçmek için kullanmayın. Ölçtüğünüz şey sistemin taşınabilirliği; kişi bazlı bir izleme aracına dönüştüğü anda bir daha dürüst bir prova yapamazsınız.
Son olarak, taşınabilirlik bedava değildir. Her soyutlama katmanı bakım gerektirir ve her belge güncel tutulmak ister. Küçük, tek seferlik işlerde bu yatırım gereksizdir; kararın içine giren, günlük operasyona bağlanmış işlerde ise ertelenmesi pahalıya patlar.
Bir modeli değiştirememek teknik bir kısıt değildir; pazarlık gücünüzün bittiği yerin adıdır.