Bir ajan kurulumunda talimatlar zamanla birikiyor. Her sorun için bir kural ekleniyor, her hata için bir korkuluk yazılıyor ve bir yıl sonra elinizde kimsenin baştan sona okumadığı bir metin yığını kalıyor.
OpenAI'dan Eric Provencher, yeni modeller için yayımladığı geliştirici notunda bu yığının artık bir maliyet kalemi olduğunu söylüyor. Eski modeller için yazılmış ayrıntılı talimatlar, daha yetenekli bir modelin önüne geçiyor.
Bu rehber o notu dört yerleşik hata üzerinden açıyor ve her biri için ne yapılması gerektiğini anlatıyor. Temel fikir tek cümlede özetlenebiliyor: daha yetenekli model daha az el tutma istiyor. Tavsiyeler OpenAI'ın kendi modeli için verilmiş olsa da sorunun kendisi sağlayıcıdan bağımsız; aynı birikme her ajan kurulumunda yaşanıyor ve çözümü de aynı yerden geçiyor.
Neden eski talimatlar zarar veriyor
Bir talimat metni yazıldığı modelin zayıflıklarına göre şekilleniyor. Model bir şeyi atlıyorsa, o şeyi zorunlu kılan bir kural ekliyorsunuz; yanlış yorumluyorsa, adım adım bir sıra yazıyorsunuz.
Model değiştiğinde bu kurallar ortadan kalkmıyor ama gerekçeleri kalkıyor. Geriye, yeni modelin zaten yapabildiği şeyi kısıtlayan bir metin kalıyor.
- Kurallar birikiyor, hiçbiri silinmiyor.
- Her kural bağlam penceresinde yer kaplıyor.
- Kısıtlayıcı kurallar modelin daha iyi bir yolu seçmesini engelliyor.
- Sorunun kaynağı görünmez, çünkü her kural tek tek makul duruyor.
Bağlam bir bütçe
Sadeleştirme tartışmasının altında ölçülebilir bir kısıt var: bağlam penceresi sonsuz değil ve içine koyduğunuz her satır bir başkasının yerini alıyor.
Talimatlar büyüdükçe asıl işe, yani göreve ve koda ayrılan yer daralıyor. Model daha az kod görüyor, daha çok kural okuyor ve sonuç tam tersine dönüyor: kuralların amacı işi iyileştirmekken, kendisi işin önündeki engel oluyor.
- Her zorunlu okuma kuralı, okunan belgenin tamamını bağlama taşıyor.
- Uzun beceri listeleri her çağrıda yeniden yükleniyor.
- Kullanılmayan kurallar da aynı maliyeti ödetiyor; ölü kural diye bir şey yok.
- Bağlam dolduğunda ilk kaybedilen şey çoğu zaman görevin kendisi oluyor.
Hata bir: uzun beceri açıklamaları
Provencher'in ilk uyarısı beceri tanımlarına dair. Biriken talimatlar bağlamı tüketiyor ve aşırı uzun açıklamalar modelin doğru beceriyi seçmesini zorlaştırıyor.
Sorun yalnızca yer kaplaması değil. Uzun açıklamalar kırpılabiliyor ve kırpılmış bir açıklama modelin yanlış beceriyi seçmesine yol açıyor.
Önerilen yaklaşım açık: beceri adları ve açıklamaları, o becerinin ne zaman geçerli olduğunu net biçimde göstermeli. Ne yaptığını anlatan uzun bir paragraf değil, ne zaman kullanılacağını söyleyen kısa bir cümle.
Pratik bir ölçüt var: bir beceri açıklamasını okuyan kişi, o becerinin hangi durumda çağrılacağını tek okumada anlayabiliyor mu? Anlayamıyorsa model de anlayamıyor ve seçim rastgeleye yaklaşıyor.
Hata iki: her değişiklikte zorunlu okuma
Ekipler sık sık ajana bir kural koyuyor: herhangi bir değişiklik yapmadan önce mimari, veritabanı ve dağıtım belgelerini oku.
Kural iyi niyetli ama basit düzeltmelerde gereksiz. Bir yazım hatasını düzeltmek için mimari belgesini okumak, hem bağlam hem zaman hem para harcıyor.
| Belge | Ne zaman okunmalı |
|---|---|
| Mimari notu | Servis sınırlarına dokunulduğunda |
| Veritabanı belgeleri | Şema değişikliği yapıldığında |
| Dağıtım belgeleri | Yayına çıkış akışı değiştiğinde |
| Hiçbiri | Küçük bir hata düzeltmesinde |
Yani belgeleri yasaklamıyorsunuz, koşula bağlıyorsunuz. Kuralın "her zaman oku" hâli yerine "şunu değiştiriyorsan şunu oku" hâli.
Tablo aynı zamanda bir sınır çiziyor: belge okumak bir maliyet kalemi, bir güvenlik önlemi değil. Belgeyi okutmak yapılan değişikliği doğru yapmıyor; yalnızca modelin bağlamına bilgi ekliyor. O bilginin gerekli olup olmadığı da değişikliğin türüne bağlı.
Hata üç: katı onay kuralları
Eski kurulumlarda ajanın her riskli adımdan önce onay istemesi mantıklıydı; modelin yargısına güvenilmiyordu. Aynı kurallar daha yetenekli bir modelde ters etki yapıyor.
Provencher'e göre katı korkuluklar Astra'nın işi erkenden bırakmasına yol açabiliyor. Model, önündeki kuralı aşamadığı için tamamlanmamış bir işi tamamlanmış sayıyor.
Çözüm, güvenli işlemler için açık izin vermek: geçici testler, tek kullanımlık dosyalar ve hata düzeltmeleri için tekrar tekrar onay istenmesin. İzin listesi daraldıkça ajan takılıyor, genişledikçe iş akıyor.
Buradaki denge noktası da net değil ve ekipten ekibe değişiyor. Üretim veritabanına dokunan bir işlemde onay istemek hâlâ doğru; geçici bir dosya oluşturup silmek için onay istemek ise yalnızca gecikme üretiyor. Ayrımı yapan şey işlemin geri alınabilir olup olmaması.
Hata dört: bitiş koşulunu söylememek
Dördüncü madde belki en kullanışlısı. Ara onay noktaları koymak yerine, işin ne zaman bittiğini baştan tanımlamak gerekiyor.
Gerekli adımların tamamını önceden yazın: uygula, test et, doğrula, hata varsa düzelt. Ajan bu listeyi bir bitiş koşulu olarak okuyor ve listeyi tamamlamadan durmuyor.
- Ara onay noktaları erken durma noktası yaratıyor.
- Bitiş koşulu yazılmadığında model kendi eşiğini belirliyor.
- Adımları listelemek, adımları sıralamaktan farklı: biri ne yapılacağını, diğeri nasıl yapılacağını söylüyor.
- Doğrulama adımını listeye koymak, tek başına en çok işe yarayan madde.
Listedeki maddelerin sırası da önemli. Doğrulama adımı listenin sonunda değil ortasında durmalı ki, hata bulunduğunda düzeltme adımı hâlâ listenin içinde kalsın.
Somut bir örnek
Dört maddeyi tek bir örnekte görmek kolaylaştırıyor. Bir kod ajanına verilen tipik bir talimatı önce eski hâliyle düşünün: "Herhangi bir değişiklikten önce mimari, veritabanı ve dağıtım belgelerini oku. Her dosya değişikliğinden önce onay iste. Testleri çalıştırmadan önce onay iste. Değişiklik bittiğinde bildir."
Bu metinde dört ayrı sorun var ve dördü de tek tek makul görünüyor. Sadeleştirilmiş hâli ise şöyle kuruluyor: "Servis sınırlarına dokunuyorsan mimari notunu, şema değiştiriyorsan veritabanı belgesini oku. Geçici test dosyaları oluşturabilir ve silebilirsin. İş şu adımlar tamamlandığında bitmiş sayılır: uygula, test et, doğrula, hata varsa düzelt."
- Zorunlu okuma koşula bağlandı, tamamen kaldırılmadı.
- Güvenli işlemler için açık izin verildi.
- Ara onay noktaları kaldırıldı.
- Bitiş koşulu tek cümlede tanımlandı.
İkinci metin birincisinden kısa ama daha belirleyici. Fark, kuralların sayısında değil, hangi soruya cevap verdiklerinde: birincisi "nasıl çalış" diyor, ikincisi "ne zaman bitti" diyor.
Adım adım anlatmanın maliyeti
Notun altında yatan fikir şu: ayrıntılı adım adım sıralamalar, modelin nüans ve belirsizlik karşısındaki muhakemesini gereksiz yere kısıtlıyor.
Bu, talimat yazmayı bırakın demek değil. Ne yapılacağını söylemek gerekiyor; nasıl yapılacağını adım adım yazmak ise modelin daha iyi bir yol bulmasını engelliyor.
Ne zaman sadeleştirme yapılmalı
Bu işin doğal anı model değişikliği. Yeni bir modele geçtiğinizde elinizdeki talimat metni, artık var olmayan bir modelin zayıflıklarına göre yazılmış durumda oluyor.
Buna karşılık her model yükseltmesinde metni baştan yazmak da gerçekçi değil. Pratik yol, talimatları hangi soruna karşı eklendiğini not ederek tutmak; o sorun ortadan kalktığında kuralı kaldırmak kolaylaşıyor.
Kaydı tutulmayan kurallar en tehlikelisi. Kimse neden eklendiğini hatırlamadığı için kimse silmeye cesaret edemiyor ve metin yıllarca büyümeye devam ediyor.
Kendi kurulumunuzu sadeleştirme sırası
Elinizdeki metni bir oturuşta yeniden yazmak yerine ölçerek ilerlemek daha güvenli.
- Önce beceri adlarını ve açıklamalarını kısaltın; en görünür kazanç burada.
- Zorunlu okuma kurallarını koşullu hâle getirin, silmeyin.
- Onay listesini gözden geçirin ve güvenli işlemleri açıkça serbest bırakın.
- Her göreve bir bitiş koşulu ekleyin, ara onayları kaldırın.
Her adımdan sonra aynı görevleri tekrar çalıştırıp sonucu kaydedin. Sadeleştirmenin işe yarayıp yaramadığını ancak sabit bir görev kümesiyle ölçebilirsiniz.
Ölçmeden değiştirmeyin
Sadeleştirmenin en sinsi yanı, iyileşmenin de kötüleşmenin de hemen görünmemesi. Bir korkuluğu kaldırdığınızda ajan çoğu görevi daha hızlı bitiriyor; sorun ancak belirli bir uç durumda ortaya çıkıyor.
Bu yüzden sabit bir görev kümesi tutmak gerekiyor. On beş görevlik küçük bir liste bile yeterli; önemli olan listenin değişmemesi ve her sadeleştirmeden sonra aynı listenin tekrar çalıştırılması.
- Başarı oranı: kaç görev insan müdahalesi olmadan bitti.
- Erken durma: kaç görevde ajan işi yarım bırakıp onay istedi.
- Bağlam kullanımı: görev başına harcanan jeton.
- Yanlış beceri seçimi: kaç görevde alakasız bir beceri çağrıldı.
Dördüncü madde beceri açıklamalarını kısaltmanın işe yarayıp yaramadığını doğrudan gösteriyor. Diğer üçü ise kaldırdığınız korkulukların bedelini ölçüyor.
Nerede durmalı
Bu tavsiyelerin tamamı bir varsayıma dayanıyor: kullandığınız modelin yargısı, yazdığınız kuraldan iyi. Bu her model için doğru değil.
Küçük ve hızlı bir modelle çalışıyorsanız, kaldırdığınız korkuluk gerçekten gerekli olabilir. Sadeleştirmeyi model değiştirdiğinizde yapın ve her seferinde ölçün; genel bir kural değil, modele bağlı bir ayar bu. Aynı metnin iki farklı modelde farklı sonuç vermesi, talimatın kötü yazıldığı anlamına gelmiyor; yalnızca kime yazıldığının önemli olduğunu gösteriyor.