Ekibinizin kod tabanına dağılmış istemleri var. Bazıları yapılandırma dosyalarındadır. Bazıları sabit kodlanmış dizelerdir. Birkaç kritik belge, bir kişinin sakladığı bir Google Dokümanı'nda bulunur. Sistemin özetleme özelliği isteminde neden "yardımsever bir İngiliz kütüphaneci gibi yanıt verin" dediğini kimse hatırlamıyor. Ancak bu ifadenin kaldırılması çıktının daha da kötüleşmesine neden olacağından sonuç aynı kalır.
Bu, çoğu ekibin istemleri yönetme şeklidir ve kabaca 2005'te sürüm kontrolü olmadan kod yazmaya eşdeğerdir. Çalışmayana kadar çalışır ve çalışmayı bıraktığında neyin değiştiği veya nasıl düzeltileceği hakkında hiçbir fikriniz olmaz.
Hızlı mühendislik retrospektifleri, mühendislik retrospektiflerinin yazılım geliştirmeye getirdiği LLM etkileşimlerine aynı disiplini getirir: sistematik inceleme, paylaşılan öğrenme ve artımlı iyileştirme. Bunu nasıl yapacağınızı burada bulabilirsiniz.
Geçici İstemde Bulunma Sorunu
Çoğu ekip şuna benzer bir döngü aracılığıyla bilgi istemleri geliştirir: Birisi bir bilgi istemi yazar, onu birkaç örnekle test eder, gönderir ve devam eder. Çıktı kalitesi düştüğünde veya yeni bir arıza modu ortaya çıktığında, birisi spesifik arıza durumuna göre istemde ince ayar yapar, belki süreçteki diğer üç durumu da bozar ve döngü tekrarlanır.
Bu yaklaşımla ilgili sorunlar şunlardan oluşmaktadır:
Geçmiş yok. Bir istemi değiştirdiğinizde eski sürüm kaybolur. Yeni sürüm daha kötüyse kolayca geri dönemezsiniz. Birisi "istemde neden bunu söylüyor?" diye sorarsa kimse bilmiyor.
Paylaşılan öğrenme yok. Akıl yürütme istemine "adım adım düşün" seçeneğini eklemenin doğruluğu gözle görülür bir farkla artırdığını anlayan kişi bu görüşü paylaşmıyor. Bir sonraki istemi yazan kişi aynı dersi sıfırdan öğrenir.
Sistematik test yok. İstemler, genellikle kolay durumlar olan, akla gelen örneklere göre test edilir. Uç vakalar, rakip girdiler ve dağıtım değişiklikleri, üretimde başarısız olana kadar test edilmez.
Ölçüm yok. "Çıktı daha iyi görünüyor" en yaygın değerlendirme yöntemidir. Nasıl daha iyi? Neye kıyasla? Kim tarafından ölçüldü? Tutarlı bir değerlendirme olmadan değişikliklerin gerçekten iyileştirme olup olmadığını anlayamazsınız.
Düzenli bir geriye dönük bilgi istemi, bu sorunların dördünü de ele alır.
Hızlı Geriye Dönük İncelemede Neler İncelenmeli?
Kanıtlarınızı Toplayın
Geriye dönük sergiden önce şunları toplayın:
Üretim hataları. LLM destekli bir özelliğin, kullanıcının fark ettiği kötü bir çıktı ürettiği herhangi bir örnek. Girişi, istemi ve çıkışı yakalayın. Kullanıcı geri bildiriminiz varsa (beğenmemeler, şikayetler, düzeltmeler) bunu ekleyin.
Son retrodan bu yana bilgi istemi değişiklikleri. Hangi istemler değişti, bu değişikliğin ardındaki amaç neydi ve sonrasında ne oldu? İstemlerinizin sürümünü kontrol ediyorsanız (olmalısınız), bu bir fark incelemesidir. Değilseniz bu retronuzdaki ilk aksiyon öğesidir.
Kalite metriği trendleri. Otomatik değerlendirmeler çalıştırıyorsanız (bununla ilgili daha fazla bilgiyi aşağıda bulabilirsiniz) trendleri getirin. İşler iyileşiyor mu? Kötüleşiyor mu? Düz mü?
Maliyet ve gecikme verileri. İstemler her ikisini de doğrudan etkiler. Kaliteyi küçük bir farkla artıran ancak jeton kullanımınızı iki katına çıkaran ayrıntılı bir sistem istemi, açıkça tartışılmaya değer bir ödündür.
Sohbet
İyi bir hızlı geçmişe dönük inceleme üç soruyu kapsar:
1. İstemlerimiz nerede başarısız oluyor ve neden?
Başarısızlıklarınızı sınıflandırın. Ortak kategoriler:
- Aşağıdaki talimat: Model, istemin istediğini yapmadı. Genellikle talimatın belirsiz olduğu veya istemin başka bir bölümüyle çeliştiği anlamına gelir.
- Biçim ihlalleri: Düz metin istediğinizde model JSON'u döndürüyordu veya tam tersi. Genellikle daha net biçim özellikleri ve örneklerle düzeltilebilir.
- Halüsinasyon: Model, sağlanan bağlam tarafından desteklenmeyen bilgiler üretti. Bu acil bir sorun (zayıf topraklama talimatları) veya model sınırlaması olabilir.
- Ton/tarz kayması: Çıktı, amaçlanandan farklı geliyor. Genellikle istemler uzun olduğunda ve stil talimatları gizlendiğinde meydana gelir.
- Edge case arızaları: İstem, tipik girişler için çalışır ancak olağandışı girişlerde kesintiye uğrar. Sistematik test eksikliğinin en çok acı verdiği nokta burasıdır.
Her hata kategorisi için şunu sorun: Bu anlık bir sorun mu, bir model sorunu mu, yoksa bir girdi sorunu mu? Düzeltme her biri için farklıdır.
2. Bu modeli harekete geçirme konusunda ne öğrendik?
Her modelin tuhaflıkları vardır. GPT-4, aynı istemlere Claude'dan farklı yanıt verir ve her ikisi de güncellemelerle davranışı değiştirir. Ekibiniz günlük çalışmalar yoluyla bu tuhaflıklar hakkında bilgi toplar; geriye dönük çalışma ise bu bilgilerin paylaşıldığı ve belgelendiği yerdir.
Yakalanacak faydalı şeyler:
- Çıktıyı güvenilir bir şekilde artıran teknikler (ve hangi tür görevler için)
- İşe yaraması gerektiği gibi görünen ancak işe yaramayan yaklaşımlar
- Sağlayıcı güncellemelerinden sonra model davranışı değişiklikleri
- Özel kullanım durumlarınız için iyi sonuç veren yönlendirme kalıpları
Bu, herkesin aynı dersleri yeniden keşfetmesini önleyen bir ekip bilgi tabanı oluşturur.
3. Bundan sonra neyi değiştirmeli veya test etmeliyiz?
Başarısızlıklara ve öğrenilenlere dayanarak belirli deneyleri tanımlayın. İyi denemeler şunlardır:
- Kapsamın daraltılması (tek seferde tek bir şeyin değiştirilmesi)
- Ölçülebilir (test etmeden önce "daha iyi"nin ne anlama geldiğini tanımlayın)
- Zaman sınırlamalı (belirli bir süre veya sayıda değerlendirme için çalıştırılır)
Örnek: "Müşteri hizmetleri istemine istenen çıktı biçiminin iki örneğini eklemenin, 200 üretim sorgusu üzerinden ölçülen biçim ihlallerini %12'den %5'in altına düşürüp düşürmediğini test edeceğiz."
Hızlı Yönetim Uygulaması Oluşturma
Temel bilgi istemi yönetimi uygulandığında geriye dönük incelemeler daha etkili olur. Başlamak için süslü aletlere ihtiyacınız yok; yalnızca birkaç pratik yeterli.
İstemlerinizin Sürüm Kontrolü
İstemlere kod gibi davranın. Bunları deponuzda saklayın, PR'lerdeki değişiklikleri inceleyin ve sürümleri etiketleyin. Bu size geçmiş, geri alma yeteneği ve inceleme gözetimi sağlar. Hızlı bir değişiklik kaliteyi düşürürse tam olarak neyin değiştiğini görebilir ve onu geri alabilirsiniz.
Çok sayıda istemi olan ekipler için özel bir dizin yapısı düşünün:
istemler/
özetleme/
sistem.txt
birkaç atış örneği.json
müşteri hizmetleri/
sistem.txt
yükseltme kuralları.txt
sınıflandırma/
sistem.txt
label-definitions.json
Bir Değerlendirme Seti Oluşturun
Her ana bilgi istemi için bir dizi test senaryosu bulundurun: iyi çıktının neye benzediğini bildiğiniz girdi-çıktı çiftleri. Bunun çok büyük olmasına gerek yok; tipik kullanımı, uç durumları ve bilinen hata modlarını kapsayan istem başına 20-50 vaka.
Bir istemi değiştirdiğinizde değerlendirme kümenizi çalıştırın. Bu, gerilemeleri üretime ulaşmadan yakalar. Başlangıçta oluşturulması zaman alır, ancak üretim hatalarında hata ayıklamaya göre çok daha fazla zaman tasarrufu sağlar.
Kararlarınızı Belgeleyin
Ani bir değişiklik yaptığınızda kısa bir not yazın: Sorun neydi, neyi değiştirdiniz ve bunun neden yardımcı olmasını bekliyordunuz? Bu, üç ay sonra bir komut istemine baktığınızda ve bunun neden görünüşte rastgele bir talimat içerdiğini merak ettiğinizde ve bunun kritik olduğu ortaya çıkana kadar ek yük gibi görünebilir.
İşe Yarayan Hızlı Geçmişe Dönük Formatlar
Her retronun aynı olması gerekmez. Farklı kadanslarda iyi çalışan iki formatı burada bulabilirsiniz:
Hızlı İnceleme (30 dakika, iki haftada bir)
Hızlı yinelenen ekipler için. Son oturumdan bu yana yaşanan üretim hatalarını gözden geçirin, yapılan acil değişiklikleri tartışın, her biri için birer teşvik edici öngörü paylaşın ve önümüzdeki iki hafta için en yüksek öncelikli deneyi seçin. Sıkı ve eylem odaklı tutun.
Derin İnceleme (90 dakika, aylık)
Geriye çekilip büyük resme bakmanız gerektiğinde. Tüm istemlerdeki kalite ölçümlerini ve eğilimleri inceleyin. En kötü performansı gösteren istemi seçin ve kapsamlı bir analiz yapın: başarısızlıkların üzerinden geçin, temel nedeni tartışın, yaklaşımlar için beyin fırtınası yapın ve uygun bir deney tasarlayın. Ayrıca istem kitaplığınızı ve belgelerinizi eski olup olmadığına dair inceleyin; istemlerden herhangi biri eski veya kullanılmamış mı?
Olay İncelemesi (geçici)
Anlık bir arıza, kullanıcıların karşılaştığı gerçek bir olaya neden olduğunda, birkaç gün içinde odaklanmış bir inceleme yapın. Ne oldu, istem neden başarısız oldu, testimiz neden onu yakalayamadı ve bu tür hataları önlemek için değerlendirme setimize ne ekleyeceğiz?
Genel Tuzaklar
Aşırı mühendislik istemleri. Daha uzun istemler her zaman daha iyi değildir. Eklediğiniz her talimat diğer talimatlarla öngörülemeyen şekillerde etkileşime girebilir. İsteminiz 500 kelimeden fazlaysa tek bir istemde çok fazla şey yapmaya çalışıp çalışmadığınızı ve bunu bir zincire ayırmanız gerekip gerekmediğini düşünün.
Yanlış metrik için optimizasyon. Otomatik metriklerde iyi puan alan ancak kullanıcıların yararsız bulduğu çıktılar üreten bir istem, iyi bir istem değildir. Yalnızca otomatik puanlamayı değil, insan değerlendirmesini de sürecinize dahil edin.
Maliyeti göz ardı etmek. Jeton kullanımınızı iki katına çıkaracak hızlı iyileştirmeler, kalite kazanımına değmeyebilir. Kalitenin yanı sıra sorgu başına maliyeti de izleyin ve açık bir şekilde ödün verin.
Sebepler yerine belirtilerin düzeltilmesi. Aynı istemi yeni hata modları için yamalamaya devam ederseniz, istemin muhtemelen başka bir yara bandı yerine yeniden tasarlanması gerekir. Geriye dönük verileriniz bu modeli gösterecektir; birden fazla retrosunda hata listelerinde görünen bir istem, daha temel bir dikkat gerektirir.
Rakip girdilerle test yapmamak. Kullanıcılarınız beklemediğiniz şeyler yapacaktır. Geriye dönük değerlendirmeniz, istem olağandışı, düşmanca veya kapsam dışı girdiler aldığında ne olacağına ilişkin periyodik bir incelemeyi içermelidir. İsteminizde korkuluk olmadığını keşfetmek için bir üretim olayının gerçekleşmesini beklemeyin.
Başlarken
Başlamak için her şeyi çözmenize gerek yok. İşte minimal bir ilk adım:
- LLM destekli en önemli özelliğinizi seçin.
- Son 10 hatayı toplayın (kötü çıktılar, kullanıcı şikayetleri, ideal olmayan her şey).
- Ekibinizle her birinin neden başarısız olduğunu sınıflandırarak 30 dakika geçirin.
- En yaygın başarısızlık modelini belirleyin ve buna yönelik bir deneme tasarlayın.
- Denemeyi çalıştırın ve sonuçları iki hafta içinde inceleyin.
Bu, geriye dönük ilk isteminiz. Tekrar tekrar yapın, kas geliştireceksiniz. En iyi yapay zeka çıktı kalitesine sahip ekipler, en akıllıca yönlendirmelere sahip olanlar değil; başarısızlıklarından sistematik olarak ders çıkaran ve aynı hatayı asla iki kez yapmayan ekiplerdir.
NextRetro'yi ücretsiz deneyin — İstem hatalarını kategoriler halinde sınıflandırın, önceliklere oy verin ve sprintler genelinde iyileştirme denemelerini izleyin.
Son Güncelleme: Şubat 2026
Okuma Süresi: 7 dakika
