Harness Engineering: Dağılmayan Yapay Zeka Ajanları İnşa Etmek İçin Kapsamlı Rehber

Çoğu insan, AI ajanlarını yanlış katmanda iyileştirmeye çalışıyor.

Bir ajan başarısız olduğunda, prompt'u yeniden yazıyorlar.

Tekrar başarısız olduğunda, daha fazla talimat ekliyorlar.

Başlamadan önce:

En yeni AI alfa bilgileri, ajan iş akışları ve adım adım kılavuzlar için Substack'imi takip edin (X'te yayınlamadan önce): [https://substack.com/@lunarresearcher

Sonra model değiştiriyorlar, daha fazla araç ekliyorlar, bağlam penceresini büyütüyorlar ve bir sonraki çalıştırmanın farklı davranmasını umuyorlar.

Ancak birçok ajan başarısızlığı, akıl yürütme başarısızlığı değildir.

Bunlar ortam başarısızlıklarıdır.

Ajan, hangi dosyaların önemli olduğunu bilmiyordu.

Doğru aracı yanlış yerde kullandı.

Önceki oturumda alınan kararları kaybetti.

Kontrolleri çalıştırmadan başarılı olduğunu iddia etti.

Kısmi bir başarısızlıktan sonra bir eylemi tekrarladı.

Onay gerektirmesi gereken bir şeyi yapma izni vardı.

Model mutlaka sorun değildi. Modelin etrafındaki sistem eksikti.

Bu sistem, koşum takımıdır (harness).

Ve onu tasarlamak, kendi başına bir mühendislik disiplini haline geliyor.

Koşum Takımı Mühendisliği (Harness Engineering), model zekasını güvenilir işe dönüştüren ortamı inşa etme pratiğidir.

Bir prompt, tek bir denemeyi değiştirir.

Bir koşum takımı, her denemeyi değiştirir.

Bu kılavuz, nasıl bir tane inşa edileceğini açıklar.

1. Model, Ajan Değildir

Bir model akıl yürütebilir, üretebilir, karşılaştırabilir ve seçebilir.

Ancak bir ajanın aynı zamanda gerçek bir ortamla etkileşime girmesi gerekir.

Şunları yapabilmelidir:

• görevi anlamak
• ilgili bağlamı bulmak
• araçları seçmek ve kullanmak
• durumu korumak
• izinlere saygı duymak
• sonucu incelemek
• başarısızlıktan kurtulmak
• işin tamamlandığını kanıtlamak

Model, bu sistemin içindeki akıl yürütme motorudur.

Koşum takımı ise akıl yürütmeyi işlevsel kılan her şeydir.

1kullanıcı isteği
2     |
3     v
4+-----------------------------+
5|         KOŞUM TAKIMI        |
6| sözleşme | bağlam | politika|
7| araçlar  | durum  | kontroller|
8| izler    | kurtarma          |
9+-----------------------------+
10     |
11     v
12    model
13     |
14     v
15gerçek ortam

Zayıf bir koşum takımı içindeki güçlü bir model, hala zayıf bir ajandır.

Etkileyici bireysel yanıtlar üretebilir, ancak uzun görevler, değişen ortamlar ve kısmi başarısızlıklar karşısında tutarsız davranacaktır.

Koşum takımı mühendisliğinin amacı, modeldeki belirsizliği ortadan kaldırmak değildir.

Bu belirsizliği, gözlemleyebilen, doğrulayabilen ve kurtarabilen bir sistemin içinde tutmaktır.

2. Bir Görev Sözleşmesiyle Başlayın

Çoğu ajan görevi, belirsiz bir niyet olarak başlar:

Kayıt akışını iyileştir.

Bu cümle bir konuşma için yeterli olabilir.

Otonom yürütme için yeterli değildir.

Ajan harekete geçmeden önce, koşum takımı isteği bir görev sözleşmesine dönüştürmelidir.

Yararlı bir sözleşme beş soruyu yanıtlar:

1. Hangi sonuç mevcut olmalı?
2. Kapsamın içinde ne var?
3. Ne değişmemeli?
4. Hangi kanıt tamamlandığını kanıtlar?
5. Hangi eylemler insan onayı gerektirir?

1hedef: kayıt sırasındaki kaybı azaltmak
2
3kapsam:
4  - kayıt akışı
5  - kayıt analitiği
6
7kısıtlamalar:
8  - kimlik doğrulamayı değiştirme
9  - mevcut mobil davranışı koru
10
11kabul:
12  - testler geçiyor
13  - analitik olayı tetikleniyor
14  - ekran görüntüleri masaüstü ve mobil kapsıyor
15
16onay_gerekli:
17  - canlıya alma
18  - veritabanı geçişi

Bu, ajanın sorusunu şuradan değiştirir:

Şimdi ne yapmalıyım?

şuna:

Hangi eylem, ortamı sözleşmeli sonuca doğru hareket ettirir?

Bir sözleşme olmadan, ajan makul görünen aktivite için optimize eder.

Bir sözleşmeyle, doğrulanmış tamamlama için optimize edebilir.

3. Ajana Bir Kılavuz Değil, Bir Harita Verin

Tüm depoyu, dokümantasyon setini ve konuşma geçmişini bağlama dökmek iyi bir bağlam mühendisliği değildir.

Bu bağlam selidir.

Koşum takımı önce küçük bir harita sağlamalı, ardından ajanın ayrıntıları ilgili hale geldiğinde almasına izin vermelidir.

1PROJE HARİTASI
2
3ürün kuralları     -> docs/product/
4mimari             -> docs/architecture.md
5ön yüz             -> apps/web/
6arka yüz           -> services/api/
7testler            -> tests/
8komutlar           -> docs/commands.md
9yayın kuralları    -> docs/release.md

Bu, aşamalı ifşadır (progressive disclosure):

1görev
2  -> proje haritası
3      -> ilgili alt sistem
4          -> tam dosyalar
5              -> yerel talimatlar

Bağlam, bilgi var olduğu için değil, görev gerektirdiği için genişlemelidir.

İyi bir bağlam derleyicisi şunlara karar verir:

• her zaman neye ihtiyaç var
• daha sonra ne alınabilir
• neyin bayatladığı
• neyin özetlenebileceği
• neyin kelimesi kelimesine kalması gerektiği

Amaç maksimum bağlam değildir.

Token başına maksimum sinyaldir.

4. Bir Araç Yığını Değil, Bir Araç Geçidi Oluşturun

Bir ajana yirmi araç vermek onu yetenekli yapmaz.

Ajana hata yapması için yirmi yol verir.

Her aracın net bir sözleşmesi olmalıdır:

1ARAÇ: dosya_düzenle
2
3girdiler:
4  yol
5  yama
6
7ön koşullar:
8  yol mevcut
9  yol izin verilen çalışma alanı içinde
10
11başarı kanıtı:
12  yama uygulandı
13  sonuçtaki fark döndürüldü
14
15başarısızlık davranışı:
16  kısmi üzerine yazma yok
17  yapılandırılmış hata döndürüldü
18
19risk sınıfı:
20  geri alınabilir

Koşum takımı, araçların nasıl sunulduğunu ve kullanıldığını kontrol etmelidir.

Şunları yapabilir:

• ilgisiz araçları gizlemek
• argümanları doğrulamak
• yolları ve alan adlarını kısıtlamak
• zaman aşımları eklemek
• yeniden denemeleri tekdüzen (idempotent) hale getirmek
• çıktıları normalleştirmek
• riskli eylemler için onay istemek
• sadece "başarılı" değil, kanıt döndürmek

Bu, önemli bir ayrım yaratır:

1model niyete karar verir
2geçit eylemi doğrular
3araç ortamı değiştirir
4sensör sonucu gözlemler

Model bir eylem önerebilir.

Araç geçidi, bu eylemin yürütülecek kadar geçerli olup olmadığına karar verir.

5. Beyni, Elleri ve Geçmişi Ayırın

Birçok kırılgan ajan, her şeyi büyüyen bir metin kaydında birleştirir.

Akıl yürütme, araç çağrıları, dosyalar, kararlar, hatalar ve eski gözlemlerin tümü aynı bağlam penceresi için rekabet eder.

Daha güçlü bir sistem, üç sorumluluğu ayırır:

1BEYİN
2planlar, akıl yürütür, seçer
3
4ELLER
5kontrollü bir ortamda araçları yürütür
6
7GEÇMİŞ
8kalıcı gerçekleri, kararları ve çalışma durumunu saklar

Modelin, aktif bağlamda her ham olaya ihtiyacı yoktur.

Doğru güncel duruma ihtiyacı vardır.

Sandbox'ın tüm hedefi anlaması gerekmez.

Sınırlı bir eylemi güvenle yürütmesi gerekir.

Oturum günlüğünün akıl yürütmesi gerekmez.

Geçerli bağlam kaybolduktan sonra ne olduğunu koruması gerekir.

Bu ayrım, uzun süreli ajanların devam ettirilmesini, incelenmesini ve onarılmasını kolaylaştırır.

Ayrıca, tüm sistemi yeniden inşa etmeden bir parçayı değiştirmenize olanak tanır.

6. Bellek, Kalıcı Durum Haline Gelmelidir

Konuşma geçmişi güvenilir bellek değildir.

Bu bir olay akışıdır.

Yararlı bellek, açık duruma dönüştürülmelidir.

En azından dört kategoriyi koruyun:

1GERÇEKLER
2ortam hakkında keşfedilen istikrarlı bilgiler
3
4KARARLAR
5alınan seçimler ve arkasındaki neden
6
7İLERLEME
8tamamlanan, aktif, engellenen ve kalan işler
9
10DERSLER
11gelecekteki davranışı değiştirmesi gereken başarısızlıklar

Örneğin:

1gerçekler:
2  - ödeme doğrulaması services/orders içinde yaşıyor
3
4kararlar:
5  - mevcut doğrulama hattını yeniden kullan
6  - neden: ikinci bir doğruluk kaynağından kaçınır
7
8ilerleme:
9  tamamlanan:
10    - sunucu tarafı kuralı eklendi
11  kalan:
12    - entegrasyon testini güncelle
13
14dersler:
15  - yerel test komutu TEST_DB_URL gerektiriyor

Bu, elli sayfalık metin kaydını yeniden oynatmaktan ve modelin önemli satırı fark etmesini ummaktan çok daha kullanışlıdır.

Denetlenebilirlik için ham geçmişi saklayın.

Yürütme için kalıcı durumu derleyin.

7. Tamamlama, Kanıt Gerektirir

Bir ajanın "bitti" demesi, görevin bittiğinin kanıtı değildir.

Bu sadece başka bir model çıktısıdır.

Tamamlama, ortamdaki gözlemlenebilir değişikliklerle belirlenmelidir.

1iddia                         kanıt
2--------------------------------------------------
3"hata düzeltildi"             başarısız test şimdi geçiyor
4"sayfa çalışıyor"             tarayıcı akışı tamamlandı
5"geçiş güvenli"               kuru çalıştırma ve geri alma geçiyor
6"rapor doğru"                 değerler kaynak veriyle eşleşiyor
7"görev tamamlandı"            her kabul kontrolü geçiyor

Koşum takımı önce en ucuz deterministik kontrolleri çalıştırmalıdır.

1sözdizimi
2  -> türler
3      -> odaklı testler
4          -> entegrasyon testleri
5              -> görsel veya anlamsal inceleme
6                  -> insan onayı

Soruyu bir derleyici, şema, sağlama toplamı, sorgu veya test cevaplayabiliyorsa, başka bir model kullanmayın.

Belirsizlik için modelleri kullanın.

Tesisat işleri için kodu kullanın.

Bir model, görevin tamamlandığını önerebilir.

Bunu yalnızca ortam kanıtlayabilir.

8. Doğrulama, Sonuca Saldırmalıdır

Çalışanlar ve değerlendiriciler aynı hedefi paylaşmamalıdır.

Çalışan, en güçlü çözümü oluşturmaya çalışır.

Değerlendirici, reddedilme nedenini bulmaya çalışır.

1çalışan
2  -> aday üretir
3
4doğrulayıcı
5  -> sözleşmeyi kontrol eder
6  -> eksik durumları arar
7  -> desteklenmeyen iddiaları test eder
8  -> sonucu kırmaya çalışır
9
10hayatta kalırsa
11  -> kabul et
12
13başarısız olursa
14  -> hedeflenmiş kanıt döndür

Bu asimetri önemlidir.

Aynı ajana, aynı bağlamda, "işini iki kez kontrol etmesini" isterseniz, genellikle hatayı yaratan varsayımları korur.

Yararlı bir doğrulama aşaması şunlara sahip olmalıdır:

• açık bir ret kriteri
• üretilen esere erişim
• kabul sözleşmesine erişim
• gerektiğinde bağımsız araçlar veya yeni bağlam
• onarmadan reddetme izni

Doğrulama ikinci bir görüş değildir.

Bu, girişilmiş bir çürütmedir.

9. Model Önerir, Politika Yetkilendirir

Bazı kurallar asla modelin onları hatırlayıp hatırlamamasına bağlı olmamalıdır.

1onay olmadan asla yayınlama
2asla bir sırrı ifşa etme
3asla çalışma alanının dışına yazma
4asla harcama limitini aşma
5asla çalışmadıkları sürece testleri geçmiş olarak işaretleme

Bunlar prompt önerileri değildir.

Bunlar politikadır.

En güvenli tasarım, politikayı akıl yürütme döngüsünün dışında tutar.

1DÜŞÜK RİSK
2dosyaları oku, ara, incele
3-> otomatik
4
5GERİ ALINABİLİR DEĞİŞİKLİK
6çalışma alanını düzenle, testleri çalıştır
7-> izle birlikte otomatik
8
9DIŞ ETKİ
10mesaj gönder, canlıya al, satın alma yap
11-> açık onay
12
13GERİ ALINAMAZ VEYA HASSAS
14verileri sil, kimlik bilgilerini döndür, küresel olarak yayınla
15-> sıkı geçit veya yasak

Sonuç ne kadar güçlüyse, geçit de o kadar sıkıdır.

Özerklik, kontrolün yokluğu değildir.

Açıkça uygulanan bir sınır içinde özgürce çalışabilme yeteneğidir.

10. Kurtarma, Başarısızlık Sınıfını Hedeflemelidir

En yaygın kurtarma stratejisi şudur:

Bir şey başarısız oldu. Tekrar dene.

Bu kurtarma değildir.

Bu tekrardır.

Koşum takımı, bir sonraki eylemi seçmeden önce başarısızlığı sınıflandırmalıdır.

1araç zaman aşımı
2-> geri çekilme ile yeniden dene
3
4geçersiz argümanlar
5-> araç çağrısını onar
6
7eksik bağlam
8-> belirli kaynağı al
9
10başarısız test
11-> başarısız davranışı incele
12
13izin reddedildi
14-> onay iste veya güvenli yolu seç
15
16çelişkili gereksinimler
17-> insana yükselt
18
19değişmeyen tekrarlanan başarısızlık
20-> döngüyü durdur

Bir yeniden deneme, en az bir ilgili koşulu değiştirmelidir.

Aksi takdirde sistem, aynı başarısızlığı yeniden üretmek için ödeme yapıyordur.

Sınırlı bir ajan döngüsü şöyle görünür:

1gözlemle
2  -> karar ver
3      -> harekete geç
4          -> ölç
5              -> kabul et
6              -> onar
7              -> yükselt
8              -> durdur

Her döngünün bir bütçeye ihtiyacı vardır:

• maksimum deneme
• maksimum süre
• maksimum harcama
• maksimum yıkıcı kapsam
• yükseltme koşulu

Güvenilir ajanlar nasıl devam edeceklerini bilirler.

Ayrıca devam etmenin artık mantıklı olmadığı zamanı da bilirler.

11. Talimatlar Altyapı Haline Gelmelidir

Ajan talimatları, yerel gerçekliği açıkladıklarında kullanışlıdır.

Ancak tek başına talimatlar zayıf bir uygulamadır.

Bir kural tekrar tekrar önemliyse, onu yığında aşağı taşıyın.

1"biçimlendiriciyi kullan"
2-> biçimlendiriciyi otomatik olarak çalıştır
3
4"katmanlar arasında içe aktarma yapma"
5-> mimari testi ekle
6
7"bir geçiş geri alma dahil et"
8-> CI'da geri alma dosyası gerektir
9
10"oluşturulan dosyaları değiştirme"
11-> oluşturulan yollara yazmaları engelle
12
13"her harici iddiayı alıntıla"
14-> alıntı kapsamını doğrula

Bu bir talimat merdiveni oluşturur:

1açıklama
2  -> kontrol listesi
3      -> şablon
4          -> otomatik kontrol
5              -> uygulanan politika

Önemli bilgiyi bu merdivende mümkün olduğunca aşağı taşıyın.

Prompt, muhakemeyi açıklamalıdır.

Koşum takımı, değişmezleri (invariants) uygulamalıdır.

12. Sadece Nihai Cevabı Değil, Çalıştırmayı da Gözlemleyin

Temiz bir nihai eser, korkunç bir süreci gizleyebilir.

Ajan şunları yapmış olabilir:

• yanlış verilere erişmiş
• başarısız bir komutu görmezden gelmiş
• harici bir eylemi iki kez tekrarlamış
• beklenen bütçenin on katını tüketmiş
• yanlış nedenle doğru cevaba ulaşmış

Çalıştırmayı yeniden yapılandırılabilir kılan izlere ihtiyacınız var.

109:14  sözleşme oluşturuldu
209:15  bağlam kaynağı yüklendi: architecture.md
309:17  dosya düzenlendi: checkout.ts
409:18  odaklı test başarısız oldu: mükerrer kupon
509:21  uygulama onarıldı
609:22  odaklı test geçti
709:24  entegrasyon testi geçti
809:25  harici dağıtım engellendi: onay gerekli

Yararlı bir iz şunları kaydeder:

• durum geçişleri
• bağlam kaynakları
• araç girdileri ve çıktıları
• ortam değişiklikleri
• doğrulama sonuçları
• yeniden deneme nedenleri
• onay kararları
• maliyet ve gecikme

Amaç gözetim değildir.

Amaç yerel onarımdır.

Bir çalıştırma 18. adımda başarısız olduğunda, tüm görevi yeniden oynatmak yerine güvenilir bir kontrol noktasından yeniden başlatabilmelisiniz.

13. Her Çalıştırmanın Bir Değişiklik Makbuzuna İhtiyacı Vardır

Uzun ajan metin kayıtlarını incelemek zordur.

Bir çalıştırmanın sonunda, koşum takımı küçük bir değişiklik makbuzu derlemelidir.

1HEDEF
2Ödeme sırasında mükerrer kupon uygulamasını düzelt.
3
4DEĞİŞENLER
5- ödeme doğrulama mantığı
6- odaklı regresyon testi
7
8DOĞRULANAN
9- lint geçti
10- birim testleri geçti
11- ödeme entegrasyon testi geçti
12
13DOĞRULANMAYAN
14- canlı ödeme sağlayıcısı
15
16KARARLAR
17- mevcut kupon öncelik sırası korundu
18
19RİSKLER
20- eski mobil istemci yerel olarak mevcut değildi
21
22ONAY GEREKLİ
23- staging'e dağıt

Makbuz, modelin söylediklerinin bir özeti değildir.

Sistemin kanıtlayabildiklerinin bir özetidir.

Bu, insanlara kompakt bir inceleme yüzeyi ve sonraki ajan oturumuna güvenilir bir başlangıç noktası verir.

En iyi devir teslim "işte konuşma" değildir.

"İşte durum, kanıt ve çözülmemiş risk"tir.

14. Her Başarısızlık Koşum Takımını Yükseltmelidir

En zayıf ekipler başarısız çıktıyı düzeltir.

En güçlü ekipler ayrıca buna izin veren sistemi de düzeltir.

Bir başarısızlıktan sonra şunu sorun:

1Görev sözleşmesi belirsiz miydi?
2Önemli bağlam görünmez miydi?
3Yanlış araç mı sunuldu?
4Bir ön koşul eksik miydi?
5Sonuç doğrulanamaz mıydı?
6Politika prompt'un içinde mi bırakıldı?
7Kurtarma çok mu genişti?
8İz yetersiz miydi?

Ardından dersi yeniden kullanılabilir bir iyileştirmeye dönüştürün.

1başarısızlık
2  -> teşhis
3      -> yeni sensör, kural, harita, test veya araç sözleşmesi
4          -> gelecekteki çalıştırmalar otomatik olarak iyileşir

Bu, koşum takımı volanıdır (harness flywheel).

Sistem daha güvenilir hale gelir çünkü başarısızlıklar arkalarında altyapı bırakır.

Düzeltilmiş bir cevap, bir çalıştırmaya yardımcı olur.

Düzeltilmiş bir koşum takımı, gelecekteki her çalıştırmaya yardımcı olur.

15. Koşum Takımları da Bozulur

Daha fazla koşum takımı her zaman daha iyi değildir.

Modeller gelişir. Araçlar gelişir. Görevler değişir. Eski güvenlik önlemleri gereksiz sürtüşme haline gelebilir.

Dünün modeli için oluşturulan bir geçici çözüm, bugünün modelinin daha iyi bir strateji kullanmasını engelleyebilir.

Bu, koşum takımı bozulmasına (harness decay) yol açar:

1eski model sınırlaması
2  -> koşum takımı geçici çözümü
3      -> model iyileşir
4          -> geçici çözüm kalır
5              -> sistem yavaşlar veya daha az yetenekli hale gelir

Koşum takımı bileşenlerine üretim kodu gibi davranın.

Hala fayda sağlayıp sağlamadıklarını ölçün.

Her yönlendirici, değerlendirici, bellek katmanı ve yeniden deneme kuralı için şunu sorun:

• Bu hangi başarısızlığı önlüyor?
• Bu başarısızlık ne sıklıkla hala oluyor?
• Bu ne kadar gecikme ve karmaşıklık ekliyor?
• Aynı sonuca şimdi daha basit bir şekilde ulaşılabilir mi?
• Onu kaldırırsak ne olur?

En iyi koşum takımı en büyüğü değildir.

Niyet ile kanıt arasındaki boşluğu güvenilir bir şekilde kapatan en küçük sistemdir.

Silmek için inşa edin.

16. Minimum Uygulanabilir Koşum Takımı

Başlamak için bir orkestrasyon platformuna ihtiyacınız yok.

Koşum takımını katmanlar halinde inşa edin.

Seviye 1: Sınırlı bir görev

• hedef
• kapsam
• kısıtlamalar
• kabul kontrolleri

Seviye 2: Okunabilir bir ortam

• proje haritası
• komutlar
• yerel talimatlar
• bilinen bağımlılıklar

Seviye 3: Kontrollü eylemler

• yazılı araçlar
• argüman doğrulama
• yol ve izin sınırları
• yapılandırılmış sonuçlar

Seviye 4: Dayanıklı yürütme

• açık çalışma durumu
• kontrol noktaları
• kararlar
• dersler

Seviye 5: Kanıt

• deterministik kontroller
• çekişmeli doğrulama
• değişiklik makbuzu

Seviye 6: Kurtarma ve öğrenme

• başarısızlık sınıflandırması
• sınırlı yeniden denemeler
• yükseltme
• tekrarlanan başarısızlıklardan koşum takımı güncellemeleri

Gerçekten sahip olduğunuz başarısızlığı ortadan kaldıran en küçük katmanı oluşturun.

Tek bir prompt'un ara sıra açıklığa kavuşturulması gerektiği için çok ajanlı bir mimariyle başlamayın.

Karmaşıklık, gözlemlenen başarısızlıkla kazanılmalıdır.

17. Yeniden Kullanılabilir Bir Koşum Takımı Şartnamesi

Bir ajana anlamlı özerklik vermeden önce, bunu tanımlayın:

1AJAN KOŞUM TAKIMI ŞARTNAMESİ
2
31. SÖZLEŞME
4   hedef:
5   kapsam:
6   kısıtlamalar:
7   kabul kanıtı:
8
92. BAĞLAM
10   her zaman yüklenen harita:
11   alma kaynakları:
12   yerel talimatlar:
13   tazelik kuralları:
14
153. ARAÇLAR
16   izin verilen araçlar:
17   ön koşullar:
18   yan etkiler:
19   başarı kanıtı:
20   zaman aşımı ve yeniden deneme politikası:
21
224. DURUM
23   gerçekler:
24   kararlar:
25   ilerleme:
26   dersler:
27   kontrol noktası formatı:
28
295. POLİTİKA
30   otomatik eylemler:
31   onay gerektiren eylemler:
32   yasaklanan eylemler:
33   bütçe limitleri:
34
356. DOĞRULAMA
36   deterministik kontroller:
37   çekişmeli kontroller:
38   kabul kuralı:
39
407. KURTARMA
41   başarısızlık sınıfları:
42   yeniden deneme limitleri:
43   yükseltme koşulları:
44   güvenli geri alma:
45
468. GÖZLEMLENEBİLİRLİK
47   iz olayları:
48   metrikler:
49   nihai değişiklik makbuzu:

Bu alanlar tanımlanmamışsa, ajan özerk değildir.

Doğaçlama yapıyordur.

18. Sistemi Doğru Seviyede Ölçün

Token sayısı nihai metrik değildir.

Denenen görev sayısı da değildir.

Yararlı birim, kabul edilen iştir.

Pratik bir metrik şudur:

1kabul edilen çıktılar
2------------------------------
3insan inceleme dakikası + çalıştırma maliyeti

Ayrıca şunları da takip edin:

• ilk geçiş kabul oranı
• araç başarısızlığından sonra kurtarma oranı
• tekrarlanan başarısızlık oranı
• görev başına insan müdahalesi
• desteklenmeyen tamamlama iddiaları
• istekten doğrulanmış sonuca kadar geçen süre
• bileşene göre koşum takımı yükü

Bu, yaygın bir yanılsamayı önler:

Bir ajan, pahalı inceleme işi yaratırken oldukça üretken görünebilir.

Amaç daha fazla ajan aktivitesi değildir.

İnsan dikkati birimi başına daha fazla güvenilir sonuçtur.

19. Ağır Bir Koşum Takımına İhtiyacınız Olmadığında

Her model çağrısının bir işletim sistemine ihtiyacı yoktur.

Şu durumlarda basit bir prompt kullanın:

• görev kısa
• çıktıyı incelemek kolay
• başarısızlık ucuz
• harici bir yan etki oluşmaz
• kullanıcı döngüde kalır

Şu durumlarda bir koşum takımı ekleyin:

• iş birden çok araç veya oturumu kapsıyor
• ortam değişebilir
• eylemlerin gerçek sonuçları var
• tamamlamayı manuel olarak yargılamak zor
• aynı başarısızlık tekrar tekrar ortaya çıkıyor
• insan incelemesi darboğaz haline geliyor

Bir koşum takımının amacı, bir demoyu karmaşık göstermek değildir.

Gerçek işi güvenilir kılmaktır.

Gerçek Değişim

AI ürünlerinin ilk nesli, prompt'lar etrafında inşa edildi.

Bir sonraki nesil, ortamlar etrafında inşa ediliyor.

Soru artık sadece:

Modelin cevabını nasıl daha iyi hale getiririz?

Şudur:

İyi eylemlerin kolay, tehlikeli eylemlerin kontrollü, başarısızlıkların görünür ve tamamlamanın kanıtlanabilir olduğu bir sistemi nasıl inşa ederiz?

Prompt mühendisliğinden koşum takımı mühendisliğine geçiş budur.

Model zekayı sağlar.

Koşum takımı yapıyı sağlar.

Birlikte güvenilir yürütme üretirler.

Ajanınız parçalanmaya devam ediyorsa, prompt'a sıfat eklemeyi bırakın.

Başarılı olması için ihtiyaç duyduğu ortamı inşa edin.

Buraya Kadar Okuduysanız

Bu kılavuzu yer imlerine ekleyin.

X'te @LunarResearcher'ı Takip Edin

Substack'ime Abone Olun

Bu makaleyi, her ajan başarısızlığını daha uzun bir promptla düzeltmeye çalışan birine gönderin.