AI Ajanlarının 5 Seviyesi: Prompt'tan Üretime

Şu sıralar herkesin agent'lar hakkında dilinden düşmeyen beş kavram var: Context engineering, loop engineering, Jev engineering, harness engineering ve eval engineering.

Kulağa birbiriyle yarışan beş farklı yaklaşım gibi geliyorlar. Ama değiller. Aslında tek bir sistemin beş katmanı bunlar ve her biri tek bir soruya cevap veriyor.

Bunları anlamanın en kolay yolu, yeni bir çalışan işe aldığınızı hayal etmek:

• Context - ona bir şey sorduğunuzda masasında ne olduğu
• Loop - sizin kontrol listenize mi uyduğu yoksa bir sonraki adımı kendi mi bulduğu
• Jev - postaları ayıklayan resepsiyon; böylece sadece önemli olanları görür
• Harness - ofisi. Araçları, anahtarları ve işini kimin kontrol ettiği
• Evals - gerçekten gelişip gelişmediğini bilmeniz için her ay uygulanan aynı test

Bir AI agent tam da bu çalışandır. Model kişinin kendisi, bu beş katman ise onun etrafındaki her şeydir. Bu beş katmanı doğru kurduğunuzda, küçük bir ekip eskiden yeni işe alım gerektiren işlerin altından kalkabilir. Tekrar eden işler production ortamında ayakta kalabilen bir agent'a devredilir, kararlar ise insanlarınızda kalır. Kadro büyütmek yerine ölçeklenmek pratikte tam olarak böyle görünür.

Her katman için bunun ne olduğunu, nasıl çalıştığını, nerede kullanılacağını ve nasıl kurulacağını adım adım anlatacağım.

Ayrıca her katman için bir de kısayol hazırladım. Sıfırdan inşa etmeden aynı sonuca ulaşmanın daha basit, yeni başlayanlara yönelik yolu. Bu kısayolları bir araya getirmemde Viktor'daki arkadaşlarım bana yardımcı oldu.

Viktor, Slack veya Microsoft Teams'inizde yaşayan bir AI çalışan. Herkesle aynı kanallarda duruyor ve bir takım arkadaşı gibi çalışıyor; yeni bir pozisyon açmadan ekibe kattığınız biri gibi.

Onunla çalışmak, gerçek bir insanla çalışmaya benziyor:

• Bir kanalda veya konu başlığında (thread) ondan bahsedip görevi tarif ediyorsunuz.
• O adımları çözüyor, araçlarınız arasında işi hallediyor ve sonucu aynı thread'e yazıyor.

Kurulum çok basit. Viktor'u çalışma alanınıza ekleyin, o da tıpkı ekibinizdeki diğer üyeler gibi katılımcılar listesinde görünsün. Okurken denemek isterseniz YARCHI100 kodunu kullanabilirsiniz.

Görsel 1. Bir agent'ın beş katmanı

1. Context engineering

Tanım

Çalışanınıza her soru sormadan önce masasına bazı evraklar koyarsınız. Doğru üç sayfayı koyarsanız saniyeler içinde cevap verir. Üç yüz sayfa koyarsanız cevap kağıt yığınının ortasında kaybolur. Ve onu kaçırır.

Model bu çalışandır. Masa ise context window'dur: modelin cevap vermeden önce gördüğü her şey. Talimatlarınız, o ana kadarki sohbet, veritabanından çekilen belgeler, çalıştırdığı her aracın çıktısı.

Context engineering, masaya neyin ve nereye konulacağına karar vermektir.

Nasıl çalışır?

Daha fazla context, daha iyi cevaplar demek değildir. Belirli bir noktadan sonra daha kötü cevaplar demektir.

Stanford bunu doğrudan test etti. Bir modele 20 ila 30 belge verdiğinizde, ortadaki belgeler için doğruluk oranı yüzde 50-57 civarına düşüyor. Hiç belge verilmediğinde ise aynı model yüzde 56 başarı gösterdi. Cevap aslında pencerenin içindeydi ama model, hiçbir şey verilmemiş halinden bile daha kötü performans sergiledi.

Bunun iki temel nedeni var:

• Modeller pencerenin başına ve sonuna en çok, ortasına ise en az dikkat eder.
• İşe yarasa da yaramasa da her token para ve zaman maliyetidir.

Bilmeniz gereken tek mekanik prompt caching'dir. Sağlayıcı, prompt'unuzun başlangıcını saklar ve bir sonraki çağrıda yeniden kullanır; önbelleğe alınmış bir token, yenisinden yaklaşık on kat daha ucuza mal olur.

İşin püf noktası şu: Önbellek yalnızca o başlangıç bayt bayt aynıysa işe yarar. En üstteki tek bir karakteri değiştirirseniz, ondan sonraki her şey tam fiyat üzerinden faturalandırılır. Bu yüzden sıra her zaman şöyledir: değişmeyenler önce, değişenler en sonda.

Nasıl kurulur?

Her bir context parçası şu dört yerden birine gider:

1. System prompt. Yalnızca her çağrıda geçerli olan şeyler: rol, kısıtlamalar, çıktı formatı. Bayt bayt aynı tutun. Başa zaman damgası koymayın, JSON anahtarlarını rastgele sıralamayın.
2. Tools. Sohbetin ortasında araç eklemeyin veya çıkarmayın. Bu hem önbelleği bozar hem de modelin artık var olmayan araçları çağırmasına yol açar. Bir aracı belirli bir adımda kısıtlamak istiyorsanız çağrıyı engelleyin ama tanımı bırakın.
3. Disk. Büyük veya uzun ömürlü her şey bir dosyaya gider, pencerede yalnızca dosya yolu kalır. Web sayfaları için de aynı kural geçerli: URL'yi tutun, içeriği atın. İçeriği çıkarın, onu geri getirecek anahtarı tutun.
4. Tail (Kuyruk). Her birkaç adımda bir, mevcut hedefi context'in sonlarına doğru yeniden ifade edin. Ortayı düzeltemezsiniz, o yüzden önemli olanları oradan uzak tutun.

Araçların da bir sınırı vardır. Anthropic, kullanıcı daha tek bir kelime yazmadan 58 araç tanımının yaklaşık 55.000 token tükettiğini ölçtü. Tüm araçları yüklemek yerine modelin bunları aramasına izin vermek, Opus 4'ün kendi benchmark'larındaki başarısını yüzde 49'dan yüzde 74'e çıkardı.

20'nin altında aracınız varsa hepsini yüklü tutun. Üstüne çıkıyorsanız arama yöntemine geçin.

Büyük işler için bir hile daha: bir sub-agent gönderin. Kendi penceresinde 50 dosyayı okur ve size tek sayfalık bir özet döner. Ana context'iniz yalnızca bu özeti görür.

Görsel 2. Tek bir model çağrısına neler girer?

Kısayol

Viktor bunların çoğunu sizin yerinize halleder çünkü onun context'i şirket seviyesinde yaşar.

• Hafıza. Tüm ekip genelinde işinizle ilgili kalıcı bir hafızası vardır. Geçen hafta kurucu ortağınızdan öğrendiği bir şeyi bugün isteğinize tekrar yapıştırmanıza gerek kalmaz.
• Bağlı kaynaklar. Notion, Google Drive veya HubSpot bağlandığında dosyaları sohbete yapıştırmayı bırakırsınız. Belgenin veya kaydın adını söylersiniz, o kaynağı okur. Disk kuralı sizin yerinize uygulanmış olur.
• Yetenekler (Skills). Bir görevi yaparken ekranınızı bir kez kaydedersiniz. O bu kaydı yazılı bir prosedüre dönüştürür, siz düzeltir ve onaylarsınız. O andan itibaren bu talimat sabitlenmiş ve gözden geçirilmiş olur, tıpkı iyi bir system prompt gibi.

Sizin tarafınızda kalanlar:

• Şirketinizi anlatan kısa bir brifingi bir kez yazın: ne satıyorsunuz, kim alıyor, hangi rakamlar önemli, asla ne yapmamalı.
• Her thread'de tek bir görev olsun ve ilk mesajda "tamamlanmış" ne demek, onu tanımlayın.
• Yanlış bir şey öğrenirse, her thread'de onu düzeltmek yerine ayarlardan hafızasını temizleyin.

2. Loop engineering

Tanım

Çalışana bir kontrol listesi verebilirsiniz: dosyayı aç, 12. satırı değiştir, kaydet. Ya da bir hedef verebilirsiniz: testi geç.

Hedef verildiğinde bir şey dener, ne olduğunu gözlemler ve bir sonraki adıma karar verir. Kontrol listesi bir workflow'dur (iş akışı). Hedef ise bir loop'tur (döngü).

Nasıl çalışır?

Bir loop, tekrarlanan dört hamledir: düşün, hareket et, gözlemle, karar ver. Bir hatayı düzeltmek şöyle görünür:

1. Testleri çalıştır. Üçü başarısız oluyor.
2. İlk hatayı oku. Eksik bir import var.
3. Import'u ekle, tekrar çalıştır.
4. Bir test hala başarısız. O hatayı oku, düzelt, tekrar çalıştır.
5. Her şey geçti. Dur.

Bu adımları önceden kimse yazmadı. Model her birini, bir önceki sonucu gördükten sonra seçti.

Tüm fark budur. Sizin yazdığınız yüz adım hala bir workflow'dur. Modelin seçtiği üç adım ise bir loop'tur.

Loop'u yalnızca adımları önceden yazamayacağınız durumlarda kullanın. Yazabiliyorsanız, yazın. Workflow daha ucuzdur, paralel çalışır ve dördüncü adım başarısız olduğunda her şeyi değil, sadece dördüncü adımı yeniden çalıştırırsınız.

Loop'lar ayrıca pahalıdır. Bir agent, tek bir çağrının kabaca dört katı token harcar. Çoklu agent yapılarında bu oran on beş kata çıkar.

Nasıl kurulur?

Bir loop'un dört parçaya ihtiyacı vardır. Herhangi birini çıkarırsanız çalışmayı durdurur:

1. Net bir "bitti" tanımı olan hedef. "Hatayı düzelt" değil. Bunun yerine: "auth_test.py dosyasındaki başarısız test geçecek ve başka hiçbir şey bozulmayacak."
2. Bir kontrolcü (checker). Modelin dışında olup geçti veya kaldı diyen bir şey: bir test paketi, derleyici, linter. Öz-düzeltme (self-correction) üzerine yapılan araştırmalar bu konuda tutarlı sonuçlar veriyor. Gerçek dış geri bildirimle işe yarıyor, model sadece kendini değerlendirdiğinde ise başarısız oluyor. Kontrolcü yoksa loop da yoktur, sadece ucu açık bir harcama olur.
3. Bir durma kuralı. Kontrolcü onay verir, tur limitine ulaşırsınız veya son iki deneme aynı çıktıyı üretir.
4. Bir bütçe. Hem tur sayısı hem de dolar cinsinden.

Kodda tüm bu yapı birkaç satıra sığar:

1for turn in range(MAX_TURNS):
2    action = model.next_step(goal, history)
3    result = run(action)
4    history.append(result)
5
6    if checker(result):       break   # tamamlandı
7    if repeated(history, 2):  break   # takıldı
8    if spent() > BUDGET:      break   # çok pahalı
9else:
10    fallback_workflow(goal)

Yayınlanmış en iyi production kurulumu hibrit bir yapıdır. Atlan önce deterministik bir filtre çalıştırıyor ve gelen uyarıların yalnızca yüzde 14 kadarı agent'a ulaşıyor.

Ardından loop'a en fazla üç döngü hakkı tanınıyor. Üç döngüden sonra güven skoru hala yüzde 50'nin altındaysa, sabit bir Python workflow'u devreye giriyor.

Önce filtrele, kısaca döngüye sok, olmazsa yedeğe geç.

Görsel 3. Workflow ile loop arasında nasıl karar verilir?

Kısayol

Viktor'a bir thread'de verdiğiniz her görev bir loop'tur. Siz hedefi yazarsınız, o adımları seçer, araçlarınız arasında çalışır ve sonuçla birlikte thread'e geri döner.

Dört parça şu şekilde eşleşir:

• Hedef. Eksik brifinglere itiraz eder ve tahmin yürütmek yerine sorar. Yine de "bitti" durumunu net yazın. "Raporu hazırla" demek yerine "Geçen haftanın gelir raporu, toplamlar Stripe ile eşleşmeli, Pazartesi sabah 9'a kadar #finance kanalına atılmalı" demek çok daha iyidir.
• Kontrolcü. Paylaşmadan önce mantıksız görünen rakamları işaretler. Karşılaştırma yapılacak kaynağı belirterek bunu güçlendirebilirsiniz: Stripe toplamı, satır sayısı, test paketi.
• Durma kuralı. Hassas işlemlerde insan onayı için duraksar ve sonuç her zaman size döner.
• Bütçe. Kredi sistemi. Reasoning (akıl yürütme) katmanı her adımın fiyatını belirler ve tekrarlayan işlerde sıklık önemlidir. Saatlik bir rapor, haftalık bir rapordan çok daha pahalıya patlar.

Atlan'ın hibrit modeli kod olmadan da çalışır. Tekrarlayan işler planlanmış bir göreve dönüşür: o teklifi sunar ve siz onaylayana kadar beklemede kalır. İşte bu sizin workflow'unuzdur.

Ucu açık olan her şey bir thread'e gider ve bu da sizin loop'unuzdur. Yedek plan (fallback) sizsiniz.

3. Jev engineering

Tanım

Ofisteki uzman her zarfı açıp okumaz. Resepsiyondaki biri postaları ayıklar: faturalar bir yığına, spamlar çöpe, sözleşmeler avukata gider.

Agent'ınız iki tür iş yapar: bir şey yazmak ve bir şeye karar vermek. Şu anda tek bir büyük model ikisini birden yapıyor, yani postaları ayıklaması için avukata para ödüyorsunuz.

Jev resepsiyondur. Asla yazmaz. Sadece seçer.

Nasıl çalışır?

Jev'e bir soru ve olası cevapları önceden verirsiniz. O da bir güven skoruyla birlikte şu üç şeyden birini döndürür:

• evet veya hayır
• bir kümeden tek bir seçenek
• bir ölçekte bir sayı

Sadece seçim yaptığı için hızlı ve ucuzdur. İddia edilen rakamlar 3-329 saniyeye karşı 70-500 milisaniye ve çıktı ücretsizken milyon input token başına 0,042 dolar.

Şimdi işin dürüst kısmı. Jev henüz iki haftalık ve bağımsız testler yeni yeni gelmeye başlıyor.

• E-posta sınıflandırmada, basit lojistik regresyon yüzde 98,9 başarı sağlarken Jev yüzde 98,6'da kaldı.
• Phishing tespitinde Jev yüzde 62,6 alırken Claude Haiku 4.5 yüzde 81,3 aldı.
• "Sıfır halüsinasyon" iddiası, yazarların kendi dipnotuyla geliyor: bu ampirik değil, sadece çıktının her zaman şemayla eşleştiği anlamına geliyor.

Güven skoru da kutudan çıktığı haliyle gerçek bir olasılık değeri değil. Onu bir sıralama olarak ele alın ve kendi etiketli verileriniz üzerinde eşik değerler belirleyin.

Nasıl kurulur?

Mantıklı kurulum, pahalı modelin önüne bir kapı koymaktır:

1. Her şey içeri girer.
2. Jev her öğe hakkında dar kapsamlı tek bir soruyu yanıtlar.
3. Güvenilir ve rutin olanlar: ucuza halledilir. Etiketlenir, yönlendirilir veya atılır.
4. Emin olunamayan veya alışılmadık olanlar: ana modele gider.

1d = jev.choose(item, options=["spam", "order_status", "refund", "other"])
2
3if d.confidence >= 0.7 and d.option != "other":
4    handle_cheap(d.option, item)
5else:
6    main_model(item)   # fail closed: emin olunamayanlar pahalı yola gider

Bunlardan herhangi birine girişmeden önce, işe yarayabilecek en basit şeyi deneyin. Birkaç yüz gerçek örneği etiketleyin, temel bir sınıflandırıcı eğitin ve ancak bu yeterli olmazsa bir üst modele geçin.

Bu otuz dakikalık bir iştir ve herhangi bir satıcı iddiasının geçmesi gereken temel çizgidir.

Görsel 4. Jev'in yanıtladığı üç soru türü

Kısayol

Jev, Viktor'un yayınlanmış mimarisinin bir parçası değil, ancak fikir sizin kontrolünüzdeki iki yerde işe yarıyor:

• Reasoning katmanı. Üç modda çalışır: Claude Opus üzerinde Smart, yaklaşık yarı maliyetle Claude Sonnet üzerinde Balanced ve yaklaşık iki katı maliyetle Claude Fable üzerinde Ultra. İstekleri sıralamak veya tek bir rakam çekmek için en üst katmana ihtiyacınız yok.
• Onun önündeki kapı. Destek e-postaları veya uyarılar gibi bir akışı yönetmesini istiyorsanız, tüm akışı ona teslim etmeyin. Önce bir sınıflandırıcı veya Jev çağrısı koyun ki yalnızca değerlendirme gerektiren öğeler onun için göreve dönüşsün.

Viktor'u kullansanız bile kendi mühendisliğinizin hâlâ önemli olduğu iki katmandan biri budur.

4. Harness engineering

Tanım

Aynı çalışan, iki farklı ofis. Birincisinde doğru araçları, duvarda bir kullanım kılavuzu, işini kontrol eden bir meslektaşı var ve kasanın anahtarı onda değil. İkincisinde ise bir dizüstü bilgisayar ve sizin admin şifreniz var.

Aynı yetenekler, çok farklı sonuçlar. Çalışan modeldir. Ofis ise harness'tır.

Agent = model + harness.

Nasıl çalışır?

Harness, model olmayan her şeydir: araçlar, izinler, sandbox, projeyi açıklayan dosyalar, çıktı üzerindeki kontroller.

2026'da kendi başına bir disiplin haline geldi çünkü insanlar ölçmeye başladı ve modelin beklenenden daha az şey açıkladığı ortaya çıktı:

• Anthropic yalnızca container kaynaklarını değiştirerek bir benchmark skorunu 6 puan artırdı.
• LangChain modeli sabit tuttu ve yalnızca harness'ı değiştirerek aynı benchmark'ta 13,7 puanlık bir artış sağladı.
• Ardından harness'ı on kat daha ucuz bir açık model etrafında öyle bir ayarladılar ki, Opus 4.8'in 0,87'lik skoruna karşı 0,86 elde ettiler.

Artık sadece bir model satın almıyorsunuz. Bir model ve bir harness'ı birlikte satın alıyorsunuz.

Agent gerçek bir şeye dokunduğu an buna ihtiyacınız var: bir repo, bir gelen kutusu, bir ödeme, bir production veritabanı.

Nasıl kurulur?

Dıştan içe doğru inşa edin:

1. Sınırlama (Containment). Agent'ın fiziksel olarak erişemeyeceği şeyler. Bir container, ayrı bir branch, salt okunur bir veritabanı kullanıcısı, allowlist dışında ağ erişimi olmaması. Bunu ilk prompt'tan önce yapın.
2. Rehberler (Guides). Harekete geçmeden önce onu yönlendiren şeyler. Repodaki AGENTS.md gibi bir dosya, modelin doğru olanı seçebilmesi için yeterince net araç açıklamaları, birkaç iyi çıktı örneği.
3. Sensörler (Sensors). Hareket ettikten sonra onu kontrol eden şeyler. Linter, tip kontrolcüsü, test paketi: hızlı ve deterministiktirler, bu yüzden her şeyde çalıştırın. Diff'i inceleyen ikinci bir model gibi daha yavaş kontrolleri yalnızca kritik olanlarda kullanın.
4. İzinler (Permissions). Agent'lar onay istediğinde, insanlar yüzde 93 oranında onay veriyor. Yani onay istemi neredeyse hiçbir şeyi korumuyor. Gerçek koruma, hiç sunulmayan eylemlerdir. Onayı yalnızca gerçekten geri alınamaz olan birkaç şey için saklayın.

Bir rehber dosyasının uzun olması gerekmez. Dört satır bile davranışı değiştirir:

1# AGENTS.md
2- Monorepo: /api (FastAPI), /web (Next.js), /jobs (cron)
3- Testleri `make test` ile çalıştır. Commit öncesi mutlaka geçmeliler
4- /migrations klasörünü asla elle düzenleme, `make migration` kullan
5- DB erişimi salt okunurdur. Herhangi bir şema değişikliği öncesi sor

Hook'lar aynı fikrin zorunlu kılınmış versiyonudur. Claude Code'da hook, bir araç çağrısından önce çalışan ve onu engelleyebilen küçük bir script'tir. "Asla main'e push yapma" kuralı prompt'ta bir satır olarak değil, bir hook olarak çalışır.

Bir uyarı. Harness'ınızın her bir parçası, modelin bir şeyi yapamayacağına dair bir bahistir ve bu bahislerin süresi dolar. Anthropic, bir model güncellemesi sonrası gereksiz hale gelen bütün bir scaffolding bileşenini sildi.

Harness'ınızı birkaç ayda bir yeniden okuyun ve modelin artık ihtiyaç duymadığı kısımları silin.

Görsel 5. Bir harness'ın dört halkası

Kısayol

Eğer agent = model + harness ise, Viktor ile elde ettiğiniz şeyin çoğu harness'tır. Altındaki model Claude'dur. Modelin etrafındaki her şey hazır gelir:

• Araçlar. 3.200'den fazla entegrasyon: GitHub, Linear, HubSpot, Stripe, Notion, Google Drive ve daha fazlası. Hazır bağlantısı olmayan bir araç için bağlantıyı kendisi kurabilir.
• Rehberler. Yetenekler (Skills). AGENTS.md dosyasını kendiniz yazmak yerine ekranınızı kaydedersiniz, o prosedürü taslak olarak oluşturur, siz düzenlersiniz.
• Sensörler. Mantığa uymayan verileri işaretler ve eksik parçaları olan brifingleri sorgular. Ayrıca attığı her adım, ekibinizin okuyabileceği bir Slack thread'ine düşer.
• İzinler. Müşteri e-postaları ve finansal değişiklikler onay için duraksar. Yeni planlanmış otomasyonlar, biri açana kadar beklemede kalır.

Hiçbir ürünün sizin yerinize kuramayacağı tek parça sınırlamadır (containment), çünkü bu tamamen sizin teslim ettiğiniz kimlik bilgilerine bağlıdır. Yüzde 93'lük onay oranını unutmayın ve onu işin gerektirdiği en düşük erişimle bağlayın:

• salt okunur bir veritabanı kullanıcısı
• kısıtlanmış bir Stripe anahtarı
• kişisel kutunuz değil, paylaşımlı bir destek kutusu
• belirli repolarla sınırlandırılmış bir GitHub token'ı

Erişemediği şeyi bozamaz.

Görsel 6. Viktor'un harness'ı

5. Evals engineering

Tanım

Yeni işe aldığınız birinin geliştiğini nasıl anlarsınız? Geçen ay yaptığınız testin aynısını uygular ve karşılaştırırsınız.

Aynı test olmadan, yaptığınız her değişiklik bir tahminden ibarettir. Eval'lar, agent'ınız için o testtir: doğru cevabı zaten bildiğiniz ve bir şeyi her değiştirdiğinizde çalıştırdığınız görevler bütünü.

Nasıl çalışır?

İki tür kontrol vardır:

• Uçtan uca (End to end). Nihai cevap doğru çıktı mı? Skorun değiştiğini söyler, nedenini değil.
• Davranışsal (Behavioral). Belirli bir şey gerçekleşti mi? Cevaplamadan önce arama yaptı mı? İstek belirsizken netleştirici bir soru sordu mu? "Bitti" demeden önce doğrulama yaptı mı?

Davranışsal kontroller yalnızca nihai cevapta değil, trace üzerinde yani agent'ın yaptığı her şeyin kaydında çalışır. Google'ın kuralı, bu test paketinin beş saniyenin altında bitmesi gerektiğidir; böylece her değişiklikte çalıştırılabilir.

Notlandırmayı bir model yapıyorsa buna judge (hakem) denir ve hakemin de kontrol edilmesi gerekir. Airbnb, model tarafından üretilen referans cevaplarının yaklaşık dörtte üçünün, aynı girdinin tekrarlanan çalıştırmalarında farklı çıktığını keşfetti. Yani eval'ları kendi gürültüsünü ölçüyordu.

Nasıl kurulur?

1. Gerçek hatalardan başlayın. Gerçek çalışmaları inceleyin, neyin yanlış gittiğini bulun ve her birini bir test senaryosuna dönüştürün. Airbnb'nin altın setleri 50 ila 100 örnek içerir ve başarısızlıklar şarttır.
2. Her senaryo için tek bir davranışsal kontrol yazın. Bir senaryo, doğrulanacak tek bir şey.
3. Hakeminizi test edin. Ona güvenmeden önce bir örneği elle notlandırın ve modelle ne sıklıkta aynı fikirde olduğunuzu görün.
4. Production'dan örnekleyin. Airbnb her gün canlı trafiğin yüzde 5'ini çeker. Gerçek kullanım ondan uzaklaştıkça eval setiniz eskir.

Tek bir senaryo şu kadar küçük olabilir:

1input: "#1042 numaralı siparişin iadesi, müşteri kırık geldiğini söylüyor"
2expect:
3  - yanıt vermeden önce siparişi sorgular
4  - iadeyi yapmadan önce onay ister
5check:
6  - trace'de send_reply'den önce get_order var
7  - trace'de refund'tan önce approval_request var

Genel geçme oranına odaklanmayın. Belirli bir davranış sessizce bozulurken bu oran artmaya devam edebilir. Bireysel kontrollere bakın.

Görsel 7. İyi eval senaryoları nereden gelir?

Kısayol

Hiçbir ürün bu katmanı sizin yerinize kuramaz, çünkü işiniz için doğru cevabın neye benzediğini yalnızca siz biliyorsunuz. Ancak yöntem birebir uygulanabilir:

• İki hafta sonra, doğru cevabı bildiğiniz 20 thread'ini seçin. Onu düzeltmek zorunda kaldığınız her birini dahil edin.
• Her senaryo için tek bir basit kontrol yazın. Her rakam için bir kaynak bağladı mı, brifing belirsizken sordu mu, şirketten bir şey çıkmadan önce duraksadı mı?
• Her değişiklikten sonra seti yeniden çalıştırın: yeni bir yetenek, düzenlenmiş bir brifing, farklı bir katman. Smart'tan Balanced'a geçmek kredilerin yaklaşık yarısını tasarruf ettirir, bu yüzden kalıcı olarak geçmeden önce test edin.
• Haftada bir kez, rastgele beş thread'i elle notlandırın.

Hepsini bir araya getirmek

Beş katman, beş soru. Context onun ne gördüğüdür. Loop kimin karar verdiğidir. Jev ucuz kararları halleder. Harness onun neye erişebildiği ve onu kimin kontrol ettiğidir. Eval'lar ise bunu nasıl bildiğinizdir.

Viktor ile bunların üçü büyük ölçüde hazır gelir: context, loop ve harness. Jev, eval'lar ve teslim ettiğiniz kimlik bilgileri sizin mühendisliğiniz olarak kalır.

Bugün başlıyorsanız, her biri için en ucuz ve faydalı hamle şudur:

• Context: Değişmeyen talimatlarınızı system prompt'a taşıyın ve onları değiştirmeyi bırakın.
• Loop: Çalışmaya bırakmadan önce bir tur limiti ve bir dolar limiti koyun.
• Jev: Agent'ınızın en sık karar verdiği konu neyse, onunla ilgili 200 örneği etiketleyin.
• Harness: Agent'ınızı hiçbir şeyi silemeyecek bir kullanıcı olarak çalıştırın.
• Evals: Son beş başarısızlığınızı test senaryosu olarak yazın.

Viktor'da aynı gün şöyle görünür:

• Context: Şirket brifingini yazın ve ilk yeteneğinizi kaydedin.
• Loop: Her göreve bir "tamamlanma" tanımı koyun ve katmanı bilinçli seçin.
• Jev: Herhangi bir akışı, onun için görevlere dönüşmeden önce filtreleyin.
• Harness: Onu salt okunur, sınırlandırılmış kimlik bilgileriyle bağlayın.
• Evals: İlk test setiniz olarak 20 gerçek thread'i kaydedin.

Bu bir günlük iştir ve beşini de kapsar.

Benim görüşüm: Artık zor olan kısım model değil. Etrafındaki beş katman. Bunları doğru kurduğunuzda kadro artırmadan kapasite artırırsınız. Çoğu ekip ilk üçünü hazır almalı ve kendi zamanını kaliteyi belirleyen iki şeye, yani ucuz kararlara ve eval'lara harcamalı.

Bu makaleye sponsor olduğu için Viktor'a teşekkürler.

@viktor_com adresinden ücretsiz deneyin. 100 dolar kredi, kart gerekmez. Tam link ilk yanıtımda.

Kaydolurken YARCHI100 kodunu kullanın.

Ücretli İş Birliği