Hataları Siz Görmeden Yakalayan Kendi Kendini Düzelten Bir AI Döngüsü Nasıl Oluşturulur?

Kendi kendini düzelten bir döngü oluşturmak için eksiksiz bir rehber.

Yapay zekayı sıradan bir kullanıcı gibi kullanan biriyle, onu gerçek bir sistem olarak işleten birini ayıran belirli bir an vardır.

Bu an, hatayı yakalayan kişi olmaktan çıktıkları andır.

Şu anda çoğu insan için döngü şöyle işler: Claude'dan bir şey iste. Çıktıyı oku. Bir sorun olduğunu fark et. Ona belirt. Düzeltilmiş bir versiyon al. Onu oku. Başka bir şey fark et. Tekrar belirt. Her seferinde, her görev için, manuel olarak doğrulama katmanı sizsiniz.

Kendi kendini düzelten bir döngü sizi bu konumdan tamamen çıkarır. Sistem üretir, kendi çalışmasını gerçek bir standarda göre kontrol eder, yanlış yaptıklarını yakalar, düzeltir ve size sonucu ancak o zaman gösterir. Çıktıyı gördüğünüzde, bariz hatalar çoktan yakalanmış ve halledilmiş olur. Size kalan şey, gerçekten bir insana ihtiyaç duyan şeyler hakkında karar vermektir, bir makinenin ilk taslağını düzeltmek değil.

Bu, eksiksiz bir yapıdır. Sonunda, buna önemli bir şey emanet etmeden önce test etmeniz gereken tam mimariye, tam promptlara ve tam hata modlarına sahip olacaksınız.

Bu Neden Sadece İki Kere Sormakla Aynı Şey Değil

Akla gelen ilk içgüdü, modelden aynı konuşmada kendi çalışmasını kontrol etmesini istemektir. "Az önce yazdıklarını gözden geçir ve hataları düzelt." Bu biraz yardımcı olur. Ancak gerçek bir kendi kendini düzelten döngü oluşturmaz ve bunun nedenini anlamak, bundan sonraki her şeyin temelidir.

Bir modelin, kendi çıktısını, hatayı ilk etapta üreten aynı bağlamda ve aynı akıl yürütmeyle gözden geçirmesi, genellikle çıktısını gerçekten incelemektense savunma eğiliminde olur. Bu, belirli bir modele özgü bir kusur değildir. Yapısal bir sorundur. Makul görünen ama yanlış bir cevap üreten aynı geçiş, bunun yanlış olduğunu fark edecek konumda değildir, çünkü içeriden bakıldığında cevap hâlâ makul görünür. "Emin misin?" diye sormak, gerçek bir yeniden incelemeden çok daha sık güvence üretir.

Çözüm daha iyi sormak değil, mimaridir. Gerçek bir kendi kendini düzelten döngü, bir cevap üretme işini onu yargılama işinden ayırır; farklı bir geçiş, farklı bir prompt ve ideal olarak tamamen farklı bir referans çerçevesi kullanır, böylece yargı, hatayı yaratan aynı kör noktalar tarafından kirletilmez.

Her Kendi Kendini Düzelten Döngünün İhtiyaç Duyduğu Üç Rol

Belirli görev ne olursa olsun, çalışan her kendi kendini düzelten sistem üç farklı role indirgenebilir. Bu rolleri net bir şekilde anlamak, aşağıdaki herhangi bir spesifik prompt'tan daha önemlidir, çünkü onları gördüğünüzde, ayrıntıları doldurarak hemen hemen her görev için bir döngü oluşturabilirsiniz.

Oluşturucu. Gerçek çıktıyı üretir. Kodu yazar, içeriği taslak haline getirir, araştırmayı yapar, görevi yürütür. Bu role en yaratıcı serbestlik ve en az kısıtlama verilmelidir, çünkü işi mükemmel bir tane değil, ilk bir deneme üretmektir.

Değerlendirici. Hiçbir şey üretmez. Tek işi, Oluşturucu'nun çıktısını, belirsiz bir kalite hissine değil, belirli, yazılı bir standarda göre değerlendirmektir. Kod testlerini geçiyor mu? Taslak, brife uyuyor mu? Araştırma, sorulan soruyu gerçekten cevaplıyor mu? Değerlendirici, ideal olarak Oluşturucu'nun sahip olmadığı bir şeye erişebilmelidir: orijinal kaynak materyal, test paketi, gerçek gereksinim belgesi. Böylece, aynı çıktıyı yeniden okuyup yeni bir fikir oluşturmak yerine, kontrol edebileceği bağımsız bir temel gerçekliğe (ground truth) sahip olur.

Yönetici. Değerlendirici'nin kararını okur ve sonra ne olacağına karar verir. Belirli geri bildirimlerle Oluşturucu'ya geri gönder. Bir insana havale et. Görevi tamamlandı olarak işaretle. Durdurma koşulunuz da burada yaşar; bir şey otomatik olarak düzeltilemediğinde döngünün sonsuza kadar çalışmasını engelleyen kuraldır.

Her üç rolde de kritik tasarım ilkesi şudur: doğrulama, Oluşturucu'nun kendi akıl yürütmesinin dışındaki bir şeye referans vermelidir. Bir test paketi. Orijinal bir kaynak belge. Yazılı bir kontrol listesi. Gerçekten farklı bir çerçevelemeye sahip ikinci bir yapay zeka çağrısı. Kısacası, "aynı modele, aynı nefeste, tekrar sormak" olmayan herhangi bir şey.

Devir Teslimleri Oluşturmak

Kendi kendini düzelten bir döngüdeki asıl mühendislik işi, her rol için zekice promptlar değildir. Aralarında geçen şeyin yapısıdır ve bu, ilk döngülerini kuran çoğu insanın tamamen atladığı ve ardından sistemin neden tahmin edilemez davrandığını merak ettiği kısımdır.

Bir devir teslimin güvenilir bir şekilde çalışması için üç özelliğe ihtiyacı vardır. Tanımlı bir format, böylece alıcı rol, gevşek bir düzyazıyı ayrıştırıp neyin önemli olduğunu tahmin etmek zorunda kalmaz. Tanımlı bir tetikleyici, böylece Oluşturucu işin ne zaman bittiğine kendisi karar vermez. Ve tanımlı bir hata yolu, böylece bir şey sorunsuz gitmediğinde, sistem sessizce bozulmak veya sonsuza kadar döngü yapmak yerine belirtilmiş bir sonraki adım olur.

Pratikte bu, Oluşturucu'nun sadece sohbet metni değil, yapılandırılmış bir şey çıktılaması gerektiği anlamına gelir: Net bir teslimat artı emin olmadığı şeylerin açık bir beyanı. Değerlendirici daha sonra bu yapılandırılmış çıktıyı yazılı bir standarda göre değerlendirir ve kendi yapılandırılmış kararını döndürür; ihtiyatlı bir düzyazı paragrafı değil, net bir geçti, kaldı veya revizyon gerekli, ekte belirli bir nedenle. Yönetici, ham içeriği değil, bu yapılandırılmış kararı okur ve anlık bir yargı doğaçlaması yapmak yerine önceden belirlenmiş kurallara dayanarak bir sonraki eyleme karar verir.

İşte, ister yazma, ister kod veya araştırma olsun, çoğu görevde işe yarayan bir şablon yapısı:

1OLUŞTURUCU ÇIKTI FORMATI
2Teslimat: [gerçek çıktı]
3Güven: [yüksek / orta / düşük]
4Bilinen belirsizlikler: [emin olmadığınız herhangi bir şey, açıkça belirtilmiş]
5Yapılan varsayımlar: [söylenmeden varsaydığınız herhangi bir şey]
6
7DEĞERLENDİRİCİ KARAR FORMATI
8Karar: [GEÇTİ / KALDI / REVİZYON GEREKLİ]
9Şuna göre kontrol edildi: [kullanılan belirli standart, örn. orijinal brif, test paketi, kaynak belge]
10Bulunan belirli sorunlar: [kesin sorunlar, genel bir izlenim değil]
11Bu karardaki güven: [yüksek / orta / düşük]
12
13YÖNETİCİ EYLEMİ
14Eğer GEÇTİ: tamamlandı olarak işaretle, kullanıcıya teslim et.
15Eğer KALDI veya REVİZYON GEREKLİ: Değerlendirici'nin belirli sorunları eklenmiş olarak Oluşturucu'ya geri gönder. Revizyon sayacını artır.
16Eğer revizyon sayacı [N]'i aşarsa: döngüyü durdur, neyin denendiği ve neden başarısız olduğunun tam geçmişiyle birlikte insana havale et.

Bu, sıradan bir ileri geri sohbetten daha fazla yapı gibi görünüyor ve öyle de. Bu peşin maliyet, size ilk çalıştırmada olduğu gibi yüzüncü çalıştırmada da aynı şekilde davranan, bağlam biriktikçe tahmin edilemez bir şekilde sürüklenmeyen bir sistem kazandırır.

Değerlendiricinin Sadece Bir Fikre Değil, Temel Gerçekliğe İhtiyacı Var

Bu, tüm sistemdeki en önemli ilkedir ve kendi bölümünü hak eder, çünkü yanlış anlaşılması diğer her şeyi sessizce baltalar.

Yalnızca Oluşturucu'nun çıktısını gören, kontrol edecek bağımsız bir referansı olmayan bir Değerlendirici, yalnızca iç tutarlılığı değerlendirebilir: çıktının tutarlı ve iyi biçimlendirilmiş görünüp görünmediğini. Doğruluğu değerlendiremez: çıktının gerçekten istenenle eşleşip eşleşmediğini veya gerçek sorunu çözüp çözmediğini. Kendinden emin bir şekilde yanlış, iyi biçimlendirilmiş ve dahili olarak tutarlı bir cevap, temel gerçekliği olmayan bir Değerlendirici'den her seferinde sıyrılıp gidecektir.

Kodlama görevleri için temel gerçeklik, test paketidir, kodu çalıştırmanın gerçek çıktısıdır, lint sonuçlarıdır, derleme durumudur. "Bu kod doğru görünüyor mu?" değil, "Çalıştırıldığında gerçekten geçti mi?"dir.

İçerik görevleri için temel gerçeklik, orijinal kaynak materyal ve orijinal brifingdir, taslakla yan yana. "Bu iyi okunuyor mu?" değil, "Bu taslaktaki her belirli iddia, kaynakta gerçekten olan bir şeye dayanıyor mu ve parça, brifingdeki her gereksinimi gerçekten karşılıyor mu?"dur.

Araştırma görevleri için temel gerçeklik, araştırmanın dayanması gereken gerçek arama sonuçları ve kaynak belgelerdir. "Bu özet otoriter mi görünüyor?" değil, "Her iddia belirli bir kaynağa kadar izlenebilir mi ve aranan kaynaklar gerçekten ilgili olanlar mıydı?"

Belirli göreviniz için Değerlendirici'nin temel gerçekliğinin ne olduğunu ifade edemiyorsanız, henüz kendi kendini düzelten bir döngünüz yok demektir. Bir yeniden ifade döngünüz var; burada Oluşturucu'nun kendinden emin hatası, gerçekten yakalanmak yerine Değerlendirici tarafından kendinden emin bir şekilde yeniden ifade edilir.

Durdurma Koşulu İsteğe Bağlı Değildir

Kendi kendini düzelten bir döngünün pahalı, kontrolden çıkmış bir karmaşaya dönüşmesinin en yaygın yolu, açık ve kesin bir durdurma koşulunun olmamasıdır. Bir tane olmadan, bir Oluşturucu ve Değerlendirici süresiz olarak döngü yapabilir, her revizyon başka bir değerlendirmeyi tetikler, her değerlendirme başka bir revizyonu tetikler, maliyet yükselir ve fatura gelene kadar kimse fark etmez.

Gerçek bir durdurma koşulunun üç bileşeni olmalıdır ve bunların üçü de modelin anlık yargısına bırakılmak yerine açık mantık olarak uygulanmalıdır.

Maksimum yineleme sayısı. Revizyon döngüleri için, sonrasında Yönetici'nin Değerlendirici memnun olsun ya da olmasın bir insana havale etmek zorunda olduğu kat bir tavan.

Gerçekten ölçülebilir bir kalite eşiği, istek odaklı değil. Bir promptun içindeki bir talimat olarak "yeterince iyi" bir durdurma koşulu değildir, çünkü modelin doğru baskı altında görmezden gelebileceği ve sonunda görmezden geleceği bir öneridir. Belirli, kontrol edilebilir bir çıta, on bir test senaryosunun tamamı geçti veya taslak, belirtilen beş brif gereksiniminin tümünü karşılıyor, bir durdurma koşuludur, çünkü her seferinde öznel olarak yargılanmak yerine mekanik olarak doğrulanabilir.

Bir maliyet veya zaman tavanı. Bu eşiğe ulaşıldığında, görevin hangi durumda olursa olsun aşamayacağı mutlak bir bütçe. Bu, sizi özellikle en kötü senaryoya karşı koruyan korkuluktur: birisi faturanın farkına varana kadar döngü yapan gerçekten çözülemez bir görev.

DURDURMA KOŞULLARI

Maksimum revizyon: 3. 3. başarısız kararda, dur ve tam revizyon geçmişiyle birlikte bir insana havale et, 4. döngüyü otomatik olarak deneme.

Kalite eşiği: Değerlendirici'nin kontrol listesindeki tüm öğeler GEÇTİ göstermelidir, "çoğunlukla geçiyor" veya "yeterince yakın" değil.

Bütçe tavanı: bu görev [X] token veya [Y] dakikadan fazla tükettiyse, mevcut durum ne olursa olsun hemen dur ve neyin tamamlandığına karşı neyin kaldığına dair rapor ver.

Bunları Yönetici'nin gerçek mantığına yazın, modelin baskı altında kendini vazgeçirebileceği daha uzun bir promptun içindeki yumuşak bir talimat olarak değil.

Çalışılmış Bir Örnek: Kendi Kendini Düzelten İçerik Üretimi

Bunu somutlaştırmak için, üç rolün ve durdurma koşulunun, bir kaynak belgeyi bitmiş bir içerik parçasına dönüştürmek gibi yaygın bir görev için tam olarak nasıl bir araya geldiğini görelim; bir insanın her taslağı manuel olarak düzeltmesine gerek kalmadan.

Oluşturucu, kaynak materyali ve brifi alır ve bir taslak üretir. Çıktısı, taslağın kendisini, artı açık bir güven beyanını ve yazarken emin olmadığı herhangi bir şeyin listesini içerir: kaynakta olduğundan tam olarak emin olmadığı belirli bir sayı, doğrudan belirtilmiş olarak bulmaktansa çıkardığı bir iddia.

Değerlendirici, taslağı ve orijinal kaynağı yan yana alır, asla taslağı tek başına almaz. Her biri kendi geçti/kaldı notuna sahip üç belirli şeyi kontrol eder. Taslaktaki her olgusal iddia, kaynakta gerçekten bulunan bir şeye dayanıyor mu? Taslak, brifingdeki her belirli gereksinimi karşılıyor mu (uzunluk, ton, gerekli bölümler)? Temel argüman veya 'hook' gerçekten mevcut mu ve doldurma maddelerle seyreltilmemiş mi? Değerlendirici, üç kontrolün her biri için ayrı ayrı geçti veya kaldı içeren yapılandırılmış bir karar döndürür; çünkü bunu tek bir genel puana indirgemek, tam olarak hangi boyutun başarısız olduğunu gizler.

Yönetici bu yapılandırılmış kararı okur. Üçünde de temiz bir geçiş, taslağı son çıktı kuyruğuna gönderir. Gerçek kontrolü boyutunda bir başarısızlık, onu, doğrulanmamış iddia doğrudan işaretlenmiş olarak Oluşturucu'ya geri gönderir; "doğruluğu iki kez kontrol et" gibi belirsiz bir talimat değil. Brif uyumluluğundaki bir başarısızlık, onu, belirtilen eksik gereksinim adıyla birlikte geri gönderir. Aynı belirli kontrolde üç başarısız döngüden sonra, Yönetici döngüyü tamamen durdurur ve sistemin kendi başına çözemeyeceğini zaten gösterdiği bir sorunu yeniden denemeye devam etmek yerine, neyin denendiğine dair tüm geçmişle birlikte bir insana havale eder.

Bu küçük bir sistemdir. Üç rol, bir yapılandırılmış devir teslim formatı, bir açık durdurma koşulu. Aynı zamanda, gerçekten gözetimsiz çalıştırabileceğiniz ve çıktısına güvenebileceğiniz bir sistemdir, çünkü her hata modunun tanımsız bir yol yerine tanımlı bir yolu vardır.

Döngüyü Güvenmeden Önce Test Etmek

Kendi kendini düzelten herhangi bir sisteme gerçekten önemli bir şey için güvenmeden önce, onu kasıtlı olarak bu belirli stres testlerinden geçirin. Gerçek kullanımda başarısız olan döngülerin çoğu, eğer birileri önce kontrol etme zahmetine girseydi, bu testlerden birinde hemen başarısız olurdu.

Çözülemez görev testi. Oluşturucu'ya, Değerlendirici'nin standardına göre tamamlayamayacağı bir görevi kasten verin. Yönetici, yineleme tavanına doğru bir şekilde ulaşıp bir insana havale mi ediyor, yoksa asla başarılı olamayacak bir görevde maliyet yakarak sonsuza kadar mı dönüyor?

Kendinden emin yanlış testi. Değerlendirici'ye, ince bir şekilde yanlış olduğunu bildiğiniz bir çıktı verin; iyi okunan ancak belirli bir olgusal veya mantıksal hata içeren bir şey. Değerlendirici, temel gerçeklik referansıyla bunu doğru bir şekilde yakalıyor mu? Değerlendirici, bozuk olduğunu bildiğiniz bir şeyi geçiriyorsa, temel gerçeklik referansınız gerçekten kontrol edilmiyor demektir veya kontrol çok yüzeyseldir.

Aynı model kör nokta testi. Oluşturucu ve Değerlendiriciniz aynı temel model üzerinde çalışıyorsa, bunu doğrudan kontrol etmeye değer. Değerlendirici'ye, o modelin karakteristik olarak yapma eğiliminde olduğu türden bir hatayı tam olarak içeren bir çıktı verin. Değerlendirici bunu geçiriyorsa, kör noktalarını roller arasında paylaşan bir döngü inşa etmişsiniz demektir ki bu, onları ayırmanın tüm amacını boşa çıkarır. Özellikle Değerlendirici rolü için gerçekten farklı bir model veya en azından anlamlı derecede farklı bir prompt çerçevesi kullanmayı düşünün.

Maliyet kaçağı testi. Sisteminizdeki en kötü durum yolunu hesaplayın: maksimum revizyonlar, en pahalı model çağrıları, en uzun makul içerik uzunluğu ve bunun gerçek dolarlar ve gerçek zaman olarak ne kadara mal olduğunu hesaplayın. Bu rakam, gerçek bir faturada göründüğünde sizi telaşlandıracaksa, durdurma koşullarınız henüz yeterince sıkı değil demektir.

Kendi kendini düzelten bir döngüye gerçek bir şey emanet etmeden önce bu dört testi çalıştırmak, aksi takdirde ilk kez bir müşterinin, patronun veya kendi banka hesap özetinizin önünde ortaya çıkacak olan başarısızlıkların ezici çoğunluğunu yakalar.

Aksi Halde İyi Bir Tasarımı Sessizce Bozan Yaygın Hatalar

Doğru üç-rol mimarisine sahip olsanız bile, tamamen farklı alanlarda tekrar tekrar ortaya çıkan bir avuç belirli uygulama hatası vardır ve bunları önceden bilmek, her birini zor yoldan yeniden keşfetmekten sizi kurtarır.

Değerlendirici'nin yalnızca Oluşturucu'nun çıktısını görmesine izin vermek, bağımsız bir referans olmadan. Bu, en yaygın hatadır ve sisteminizi sessizce bir doğruluk kontrolünden bir tutarlılık kontrolüne dönüştürür. Karşılaştıracak hiçbir şeyi olmayan bir Değerlendirici, size yalnızca çıktının dahili olarak tutarlı göründüğünü söyleyebilir, asla gerçekten doğru olup olmadığını söyleyemez.

Her role, üzerine ince bir talimat farkı katmanlanmış aynı modeli vermek. Değerlendirici, Oluşturucu ile tamamen aynı temel modeli çalıştırıyorsa, sadece ona "eleştirel ol" diyen farklı bir promptla, genellikle Oluşturucu'nun sahip olduğu tamamen aynı kör noktaları miras alır, çünkü temelde farklı bir şapka takan aynı akıl yürütme sürecidir. Bütçenin izin verdiği yerlerde, Değerlendirici rolü için gerçekten farklı bir model, teatral bağımsızlık yerine gerçek bağımsızlık üretir.

Yönetici'ye, önceki denemelerin gerçek bir hafızasını vermek yerine basit bir geçiş noktası gibi davranmak. Bu belirli görevde daha önce neyin denendiğine dair hiçbir görünürlüğü olmayan bir Yönetici, aynı başarısız geri bildirimi Oluşturucu'ya ikinci ve üçüncü kez memnuniyetle gönderecek ve her seferinde aynı başarısız sonucu üretecektir, çünkü sistemde bu yaklaşımın daha önce başarısız olduğunu hatırlayan hiçbir şey yoktur.

Herkesin yakından izlediği tek demo çalışmasında sistem iyi çalıştığı için dört stres testini atlamak. Siz onu yakından izlerken doğru davranan bir sistem ile gözetimsiz çalışırken doğru davranan bir sistem farklı iddialardır. Sadece ikincisi, başlangıçta kendi kendini düzelten bir döngü oluşturmanın asıl amacıdır. Hata modlarını kasıtlı olarak test etmediyseniz, sisteminiz için hangi iddianın doğru olduğunu gerçekten bilmiyorsunuz demektir.

Durdurma koşulunu katı mantık yerine yumuşak bir talimat olarak yazmak. Bir promptun içindeki "yeterince iyi olduğunda dur" bir durdurma koşulu değildir; modelin doğru baskı altında kendini aşabileceği ve sonunda aşacağı bir öneridir. Yönetici'nin başka bir döngüye izin vermeden önce mekanik olarak kontrol ettiği katı bir yineleme sayacı bir durdurma koşuludur. Bu ikisi arasındaki fark, bir görevin gerçekten çözülemez olduğu ortaya çıktığında çok önemlidir.

İkinci Çalışılmış Örnek: Kendi Kendini Düzelten Kod

Aynı iskelet, görev içerik yerine kod olduğunda farklı görünür ancak aynı mantığı izler ve her ikisini yan yana incelemek, alanlar arasında ne kadar az şeyin değiştiğini açıkça ortaya koyar.

Buradaki Oluşturucu, tanımlanmış bir görev (bir hata düzeltmesi, bir özellik, bir yeniden düzenleme) üzerinde çalışan bir kodlama ajanıdır. Yapılandırılmış çıktısı yalnızca kod farkı (diff) değil, aynı zamanda onu çalıştırma girişiminden elde edilen gerçek komut çıktısı, test sonuçları, lint çıktısı, derleme durumudur; bunların hepsi devir teslimine dahil edilir. Kod üreten ancak onu asla gerçekten çalıştırmayan bir Oluşturucu, Oluşturucu rolünü doğru bir şekilde doldurmuyordur, çünkü sözdizimsel olarak makul olan ancak kendi test paketinde başarısız olan kod, hiç koddan daha kötüdür, çünkü bitmiş gibi görünürken bitmemiştir.

Değerlendirici, doğrulanabilir üç belirli şeyi kontrol eder. Değişiklik, testlerin kendileri değiştirilmeden mevcut test paketini geçti mi? (Bir Oluşturucu'nun bir testi geçirmek için sessizce düzenlemesi, doğrudan kontrol edilmeye değer, belirli ve şaşırtıcı derecede yaygın bir başarısızlıktır.) Statik analiz ve linting temiz mi geldi? Diff, gerçekten atanan görevi ele alıyor mu, yoksa Oluşturucu'nun yol boyunca çözmeye daha ilginç bulduğu, ilgili ancak farklı bir problemi mi ele alıyor? Bunların her biri, yapılandırılmış kararda kendi açık geçti/kaldı notunu alır.

Yönetici, hangi belirli kontrolün başarısız olduğuna göre yönlendirme yapar. Başarısız bir test paketi, eklenmiş tam başarısız test çıktısıyla birlikte Oluşturucu'ya geri gider; "testleri düzelt" gibi genel bir talimat değil. Bir kapsam uyumsuzluğu (diff'in atanandan farklı bir problemi çözdüğü durum), döngüye girmek yerine hemen bir insana havale edilir, çünkü bu, görevin gerçekte ne olduğu hakkında bir yargı hatasıdır, Oluşturucu'nun kendi başına üstesinden gelebileceği mekanik bir kusur değildir.

Buradaki temel iskeletin (Oluşturucu kanıtlarla birlikte üretir ve gönderir, Değerlendirici belirli adlandırılmış kriterlere karşı kontrol başına kararla kontrol eder, Yönetici tam olarak hangi kontrolün başarısız olduğuna göre yönlendirme yapar) yukarıdaki içerik üretimi örneğiyle aynı olduğuna dikkat edin. Bu, iki farklı alanı yan yana görmekten çıkarılacak asıl derstir. İskeleti doğru bir şekilde elde ettiğinizde, onu yeni bir görev türüne uygulamak, çoğunlukla Değerlendirici için yeni, belirli bir kontrol listesi yazmak meselesidir; her seferinde ilk prensiplerden tüm mimariyi yeniden tasarlamak değil.

Birden Çok Eşzamanlı Döngüye Ölçeklendirme

Tek bir kendi kendini düzelten döngü gerçekten güvenilir hale geldiğinde, bir sonraki gerçek soru, sistemin yönetilemez hale gelmeden aynı anda birkaçını nasıl çalıştıracağınızdır; çünkü çoğu insanın bunu ölçeklendirmeye yönelik ikinci girişimi tam olarak burada yanlış gider.

İlki çalışır çalışmaz, mimari teknik olarak desteklediği için aynı anda birçok döngü başlatma ve beş farklı görevi paralel olarak ele alma cazibesi vardır. Gerekenden daha uzun süre buna direnin. Eklenen her eşzamanlı döngü, bir durdurma koşulunun sessizce başarısız olabileceği, maliyetin fark edilmeden kaçabileceği, bir Değerlendirici'nin temel gerçeklik referansının, yalnızca tek bir test çalıştırmasında değil, gerçek hacim altında kendini gösterecek şekilde ince bir şekilde yanlış olabileceği başka bir yerdir.

Daha güvenli ölçeklendirme yolu, her adımda gerçek bir güven eşiği ile sıralı genişlemedir. Bir döngüyü, çıktısını yakından kontrol etmeyi bıraktığınız noktaya kadar güvenilir bir şekilde çalıştırın; yani, tek bir başarılı demo çalıştırmasında değil, gerçek bir zaman dilimi boyunca kendi manuel nokta kontrollerinizi tutarlı bir şekilde geçiyor olsun. Ancak o zaman farklı bir görev için ikinci bir döngü ekleyin. Her döngünün gerçek başarısızlık oranını zaman içinde takip edin, yalnızca gözlemlediğiniz çalıştırmalarda işe yarayıp yaramadığını değil.

Birden çok döngüyü aynı anda çalıştırdığınızda, izole başına döngü takibi yerine, tüm döngüler arasında paylaşılan bir maliyet panosuna ciddi şekilde yatırım yapın. Makul bir görev başına bütçeye sahip tek bir döngü, izole olarak tamamen iyi görünür. Her biri kendi bütçesi dahilinde olan on döngü, yine de kimsenin fark etmediği, gerçekten endişe verici bir toplama ulaşabilir; ta ki toplu fatura gelene kadar, çünkü her bir döngünün takibi kendi başına iyi görünüyordu.

Ölçeklendirme sorunlarını ortaya çıkmadan önce engelleyen tek alışkanlık: yalnızca başarılı tamamlamaları değil, her döngüdeki her durdurma koşulu tetikleyicisini günlüğe kaydedin. Maksimum yineleme tavanına ulaşan ve bir insana havale eden bir döngü, tam olarak yapması gerekeni yapıyordur, ancak belirli bir döngü bu tavana sürekli olarak ulaşırken diğerleri nadiren ulaşıyorsa, bu, o belirli görev için Değerlendirici'nin standardının yanlış ayarlandığının, asla geçemeyecek kadar katı olduğunun veya tamamen yanlış temel gerçekliğe karşı kontrol ettiğinin bir işaretidir. Bu model, yalnızca başarıları takip ediyor ve her havaleyi, o belirli döngünün tasarımı hakkında bir veri noktası olarak değil, izole, kayda değer olmayan bir olay olarak ele alıyorsanız görünmezdir.

Bu Hafta Nereden Başlamalı

İlk denemenizde tamamen genel bir kendi kendini düzelten sistem kurmaya çalışmayın. Halihazırda düzenli olarak yaptığınız, net bir standardı olan (sorulsa yazabileceğiniz) belirli, dar, iyi tanımlanmış bir görev seçin ve üç-rol döngüsünü önce bu tek görev etrafında oluşturun.

Değerlendirici'nin kontrol listesini, Oluşturucu'nun promptunun tek bir satırını yazmadan önce açıkça yazın. Kontrol ettiğiniz standart, Oluşturucu'dan ne üretmesini istediğinizi şekillendirmelidir, tersi değil. Kontrol listesini henüz yazamıyorsanız, bu görev için "doğru"nun ne anlama geldiğini, kontrolü otomatikleştirecek kadar iyi bilmiyorsunuz demektir ve bunu bir şey inşa etmeden önce keşfetmeye değer.

Yukarıdaki dört stres testini, bir şey birinin önünde ters gitmeden önce, döngüye gerçekten önemli bir şey emanet etmeden önce uygulayın. Durdurma koşulunu, bir kez kontrolden çıkan bir döngü tarafından canınız yandıktan sonra sonradan akla gelen bir şey olarak değil, en başından itibaren gerçek, katı mantık olarak ekleyin.

Bir döngü gerçekten güvenilir hale geldiğinde, gözetimsiz çalıştığında, gerçek hataları yakaladığında, gerektiğinde temiz bir şekilde durduğunda, ikincisi çok daha hızlı gider. Promptlar doğrudan aktarıldığı için değil (genellikle yeni görev için yeniden yazılmaları gerekir), ancak sorunun gerçek şeklini zaten anladığınız için. İnşa etmeyi yargılamaktan ayırın. Yargılamaya kontrol edecek gerçek bir şey verin. Durdurma koşulunu umut olarak değil, mantık olarak yazın.

Bu şekil, tüm disiplindir. Geriye kalan her şey, onu önünüzdeki göreve uygulamaktır.

Bu makaledeki her şeyin arkasındaki tam döngü şablonları ve Oluşturucu-Değerlendirici-Yönetici kurulumları için @cyrilXBT adresini takip edin.