ivralo nasıl ölçülür

Eval nedir

Eval vakası, evals/cases/ altındaki bir YAML dosyasıdır: bir insanın yazacağı gibi yazılmış bir istek, çalışma alanının başlangıçtaki dosyaları ve iş bittikten sonra nelerin doğru olması gerektiği. Beklentiler modelin kullandığı ifadelere göre değil, çalışma alanına ve kaydedilen run'a göre kontrol edilir:

• run'ın hangi preset'leri açtığı (opened, never_opened);
• hangi dosyaların bulunması, hangilerinin bulunmaması ve hangilerinin değişmemesi gerektiği;
• üretilen bir dosya üzerinde bir kontrol; örneğin bir çalışma kitabındaki sütun toplamı ya da bir PDF'in sayfa sayısı;
• projenin kendi komutlarının geçmesi (command_passes); bir kod değişikliği bu şekilde kanıtlanır;
• araç çağrıları, hatalar ve süre için bütçeler, bir de cevabın dili.

Her run yeni bir oturumla ve çalışma alanının geçici bir kopyasıyla başlar; uzun süreli hafıza kapalıdır. Bir vaka, run'larının çoğunluğu geçerse geçmiş sayılır; varsayılan olarak üç run yapılır. Her vakanın bir seviyesi vardır (easy, medium ya da hard); zor vakalarda ilk akla gelen cevabı yanlış çıkaran tuzak açıkça belirtilir.

Neye ihtiyaç duyar

Eval suite yalnızca repo'nun bir checkout'unda bulunur. evals/ wheel'in içinde değildir ve ivralo eval vakaları ana dizinden okur; checkout'ta ana dizin checkout'un kendisidir. Checkout kurulumu Checkout'tan kurulum sayfasında anlatılıyor.

Checkout dışında normal bir run neye ihtiyaç duyuyorsa ona ihtiyaç duyar: veritabanı ve bir model. Herhangi bir model referansı olur. Sonra fixture'ları bir kez kurun; fixture'lar repo'da tutulan builder'larla üretilir ve hiçbir zaman elle düzenlenmez:

uv run python evals/fixtures/build.py

Seçilen bir vakanın ihtiyaç duyduğu fixture eksikse ya da eski builder'larla kurulmuşsa ivralo eval tek satırlık bir mesajla başlamayı reddeder.

Çalıştırmak

uv run ivralo eval --list                     # vakalar ve seviyeleri; hiçbir şey çalıştırmaz
uv run ivralo eval                            # frozen olmayan her vaka
uv run ivralo eval coder-adds-a-shout-flag --runs 1
uv run ivralo eval --level hard --jobs 4

Her run bittiği anda bir satır yazdırır. Sonuçlar git'in yok saydığı evals/results/ altına kaydedilir. Bir baseline ile karşılaştırırken yalnızca geçme oranı karşılaştırılır; diğer sütunlar ölçüm amaçlıdır.

Split'ler

Her vaka bir split'e aittir:

Frozen vakalar, anahtarları ve incelemeleriyle birlikte ayrı bir yerde, evals/frozen/ altında durur. Onları yalnızca tek başına çalıştırılan ivralo eval --split frozen okur. Düz bir çalıştırma onları dışarıda bırakır; --explain, --tune ve ivralo eval merge ise onları adıyla reddeder. Tuning tarafında hiçbir şey bu vakaları görmez; böylece verdikleri sonuç dürüst kalır.

Pull request'te ne zaman gerekir

skills/, agents/building/team.py ya da agents/roster/roster.py'de değişiklik yaptıysanız, değişikliği modelin sınaması gerekir: eval'leri çalıştırın ve tabloyu pull request'e yapıştırın. Bu iş dakikalarla saatler arasında sürer ve modeli devreye sokar; bu yüzden test katmanlarının bir parçası olarak değil, bilerek çalıştırın.

Yanlış bir cevap vakaya dönüşür

Bir run ters gittiğinde, ne yapması gerektiğini anlatan bir notla kaydedin. Oturumda:

/bad ilk 100 satırı değil, bütün sayfayı okumalıydı

Komut satırında:

ivralo feedback --last --note "bütün sayfayı okumalıydı"

İkisi de git'in yok saydığı evals/cases/drafts/ altına bir taslak vaka yazar; yani siz taşımadığınız sürece taslak makineden çıkmaz. Cevabın doğru olduğunu söyleyecek her alan, sizin doldurmanız için FILL ME olarak bırakılır; kaydedilen bir vaka yanlış bir cevabı hiçbir zaman doğru diye kabul etmez.

uv run ivralo eval drafts                     # taslakları listeler: dolu ya da doldurulacak
uv run ivralo eval --drafts                   # dolu olanları çalıştırır
git mv evals/cases/drafts/<name>.yaml evals/cases/

ivralo eval record --last, kaydedilmiş herhangi bir run için, notlu ya da notsuz, aynı işi yapar.

Bir skill nasıl değişir

Uzmanlık skill'lerde birikir ve skill'ler eval üzerinden, bir insanın açtığı bir pull request'le değişir.

Önce vakanın neden başarısız olduğunu okuyun. --explain, başarısız her run'ı kaydedilmiş run'la eşleştirir; çağrıları, okunan skill'leri ve hangi kuralın başarısız olduğunu, hiçbir modele sormadan yazdırır:

uv run ivralo eval --explain coder-adds-a-shout-flag

Ardından --tune ile, ivralo ile gelen bir skill'in tek bir bölümü için bir modelden tek bir yeniden yazım önerisi alırsınız:

uv run ivralo eval --tune coding

1. Run'larında bu skill'in okunduğu tuning vakalarını bulur, ayarlamanın maliyetini söyler ve başlamadan önce onay ister.
2. Tuner'a başarısız run'ları verir; bir vakanın beklentilerini ve held-out vakaları hiçbir zaman vermez. Tek bir bölümün yeniden yazılmasını ister.
3. Bölümünün dışına taşan, fazla uzayan, skill'in lint'ini bozan ya da bir vakanın ayrıntısını skill'e kopyalayan yeniden yazımları kod reddeder.
4. Bir yeniden yazım ancak başarısız vakaların açık çoğunluğu iyileşirse ve hiçbir vaka gerilemezse tutulur.
5. En iyisi bir kez held-out split'inde sınanır. Tuning'de kazanıp held-out'ta kaybeden bir yeniden yazım önerilmez, yalnızca raporlanır.

skills/'e hiçbir zaman yazılmaz. Sonuç, evals/results/tuning/<stamp>-<skill>/ altında bir patch ve bir pull request açıklamasıdır; pull request'i siz açarsınız:

git switch -c fix/tune-coding
git apply evals/results/tuning/<stamp>-coding/skill.patch
gh pr create --body-file evals/results/tuning/<stamp>-coding/pull-request.md

Prompt'lar, team.py ve roster bu döngünün dışındadır: orada yapılan bir değişiklik bütün vakaları aynı anda etkiler ve diff'ine bakarak hangi başarısızlığa çözüm olduğunu anlamak mümkün değildir.