İçeriğe geç

Kılavuzlar

Başka bir aracın puanlarına ikinci bir görüş

Değerlendirme puanınız yükseldi. Bu gerçek mi? Peki onu ölçen hakeme güvenebilir misiniz? Zaten başka bir araçla değerlendirme yapıyorsanız, bir değişiklikten önce ve sonra o aracın vaka başına sonuçlarını dışa aktarın; Oloproof hiçbir şeyi yeniden çalıştırmadan bu sonuçlar üzerinde iki soruyu da yanıtlar.

Ne okur

Sistem sürümü başına bir dosya, CSV ya da JSON Lines, vaka ve ölçüt başına bir satırla:

SütunNe içerir
case_idVakanın kimliği. İki dosya yalnızca ikisinin de içerdiği bir kimlik üzerinde eşleşir
criterionMetriğin adı; bir kuralın adını verdiği metrik bu olur
scoreMetriğin ölçeğinde bir sayı ya da araç o vakayı puanlamadıysa boş
passedPuan yerine true ya da false, ya da boş
score_min, score_maxPuanın üzerinde yer aldığı ölçek (çoğu araçta 0 ve 1); bir puan için zorunludur
judge, judge_versionHakemliği bir model yaptıysa, hakemlik yapan model. İsteğe bağlı

Başka hiçbir şey okunmaz ve başka herhangi bir sütun içeren bir dosya reddedilir: bir dosya vaka kimliklerini ve puanları içerir, asla bir soru, bir yanıt ya da başka herhangi bir içerik içermez. Aşağıdaki tarifler her aracın sonuçlarını bu dosyaya dönüştürür.

Çalıştırın

oloproof init --example second-opinion second-opinion
cd second-opinion

Örnek, bir destek asistanının 150 soru üzerindeki sadakatinin (faithfulness) iki dışa aktarımını, bir prompt değişikliğinden önce ve sonra, başka bir aracın hakeminin puanladığı haliyle içerir: 0 ile 1 arasında bir puan ve 0.7 eşiğindeki geçti ya da kaldı kararı. make_exports.py bunları yazan simülasyondur. Ortalama puan yaklaşık 0.02 yükseldi.

oloproof scores import before.csv after.csv --policy release.yaml
faithfulness: +0.023 [-0.024, +0.068] · 150 paired · 0 missing · 0 excluded
faithfulness_passed: +5.3 points [-6.9, +18.0] · 150 paired · 0 missing · 0 excluded
Decisions
  score-went-up  faithfulness  superiority  INSUFFICIENT_EVIDENCE  evaluator_not_validated
  more-answers-pass  faithfulness_passed  superiority  INSUFFICIENT_EVIDENCE  evaluator_not_validated
Gate: BLOCK (exit 3)
score-went-up, more-answers-pass: the judge (or model or custom evaluator) behind these rules has not been measured against people yet, so it may not decide.

Her dosya bir çalıştırma oldu ve iki çalıştırma vaka vaka karşılaştırıldı. Yanıtın iki yarısı var.

  • Gerçek mi? Henüz değil. Puan 0.023 yükseldi, ancak aralık 0.024 aşağıdan 0.068 yukarıya uzanıyor: 150 soruyla bu kadar küçük bir değişiklik gürültüden ayırt edilemez. Hakemin geçirdiği yanıtların payı 5.3 puan yükseldi; aralığı 6.9 puan aşağıdan 18.0 yukarıya uzanıyor.
  • Hakeme güvenebilir misiniz? Kimse onu denetlemedi. release.yaml, bir hakemin bir sürüme ancak insanların etiketleri onu ölçtükten sonra karar vermesine izin verir (require_validated_evaluators: true); bu yüzden iki kural da aralığa ulaşmadan evaluator_not_validated noktasında durur.

İlk yarıyı tek başına, hakem denetlenmiş gibi görmek için:

oloproof scores import before.csv after.csv --policy statistics-only.yaml
  score-went-up  faithfulness  superiority  INSUFFICIENT_EVIDENCE  interval_overlaps_zero
  more-answers-pass  faithfulness_passed  superiority  INSUFFICIENT_EVIDENCE  interval_overlaps_zero

CI'da --summary markdown >> "$GITHUB_STEP_SUMMARY" ekleyin: pull request bu durumda "Is it real?" ve kural başına bir satırla açılır; her satır "not established" der ve nedenini söyler, çıkış kodu da aynı kalır. İçe aktarmanın kendi satırları standart hataya gider, böylece özet yalnızca yanıtı alır (CI).

--policy olmadan komut karşılaştırmayı bildirir ve hiçbir şeye karar vermez. Tek bir dosyayla o çalıştırmayı bildirir ve --policy onu politikanın çalıştırma kurallarına göre kapı denetiminden geçirir.

Hakemi denetlemek

İnsanlar, içe aktarılmış bir çalıştırmanın vakalarından rastgele bir örneklemi hakemin kararını görmeden etiketler ve Oloproof hakemi bu etiketlere karşı ölçer:

oloproof labels export RUN_ID --criterion faithfulness_passed --sample 60 --out sample.csv
oloproof labels import sample.csv
oloproof evaluators validate EVALUATOR_ID --by NAME

Örneklem her vakanın kimliğini gösterir, hakemin kararından ise hiçbir şey göstermez. Etiketleyen kişi vakayı, onu tutan araçta kimliğiyle okur ve passed alanına pass ya da fail yazar. oloproof evaluators list değerlendiricinin kimliğini verir. Hakem doğrulandıktan sonra, onu okuyan kurallar yalnızca kanıta dayanarak karar verir.

Etiketler geçti ya da kaldı biçimindedir, dolayısıyla bir hakemin puanını değil, geçti ya da kaldı kararını denetler. Kararı puanın yanında içe aktarın, tıpkı örneğin faithfulness_passed ile yaptığı gibi: insanların doğrulayabileceği ölçüt budur.

Kendi aracınızdan

Örneğin recipes/ klasörü her araç için kısa bir betik içerir. Her biri o aracın sonuçlarını okur ve yalnızca kimlikleri ve puanları tutarak dosyayı yazar. Her sürüm için birini çalıştırın, ardından iki dosyayı içe aktarın.

AraçTarifİki çalıştırma arasında bir vakayı ne tanımlarNotlar
DeepEvaldeepeval_results.py RESULTS_JSON OUTTest vakasının name alanıSonuçları DisplayConfig(results_folder=...) ile kaydedin ve her LLMTestCase için bir ad verin. Her metrik, puanını ve geçti ya da kaldı kararını hakem modeliyle birlikte <metric>_passed olarak verir
Braintrustbraintrust_experiment.py PROJECT EXPERIMENT OUTDeneyin üzerinde çalıştığı veri kümesi kaydı (origin.id)0 ile 1 arasında puanlar; hepsini tek bir model puanladıysa --judge o modelin adını verir
LangSmithlangsmith_experiment.py EXPERIMENT OUT --scale LOW HIGHVeri kümesi örneği (reference_example_id)true ya da false bir puan geçti ya da kaldı olur; bir sayı kendi ölçeğini gerektirir
Langfuselangfuse_experiment.py EXPERIMENT SINCE OUTVeri kümesi öğesi (experiment_item_id)Langfuse 5 deneyleri; puan yapılandırmalarının aralığındaki sayısal puanlar ya da --scale

Tarifler her aracın SDK'sını 16 Ekim 2026'da yayımlandığı haliyle izler (DeepEval 4.3.1, braintrust 0.46.1, langsmith 0.14.11, langfuse 5.0.2) ve canlı bir hesaba karşı değil, bu biçimdeki sonuçlar üzerinde test edilmiştir. Bir alanın adını değiştiren bir araç içe aktarmayı değil, kendi tarifini bozar: sözleşme, tarifin yazdığı dosyadır.

Bir dosyanın doğru yapması gerekenler

  • Yalnızca bir dosyada bulunan bir vaka diğer tarafta eksiktir, sayılır ve en kötü değerinde sınırlanır; asla başka bir vakayla eşleştirilmez.
  • Aynı vaka ve ölçüt için ikinci bir satır, score_min ile score_max dışında kalan bir puan, hem puan hem de geçti ya da kaldı içeren bir satır ve bir dosyada puan, diğerinde geçti ya da kaldı olan bir ölçüt, satır belirtilerek reddedilir.
  • Karşılaştırılan dosyalar her ölçütün ölçeği ve hakemi üzerinde uyuşmalıdır: iki hakemden gelen puanlar iki ayrı ölçüm aracıdır ve aralarındaki fark kısmen bu araçların farkı olur.
  • Her dosya, içeriğiyle tanımlanan bir sistem sürümüdür. Aynı dosyayı yeniden içe aktarmak saklanmış olanı yeniden kullanır; hiçbir şey asla yürütülmez, dolayısıyla hiçbir yeniden çalıştırma içe aktarılmış bir puanı yeniden üretemez ya da değiştiremez.
  • --tool puanların nereden geldiğini kaydeder, --name ise her dosyanın sistemine ad verir; ikisi de çalıştırmayla birlikte saklanır.

Neler yapılmadı

  • Bir aracın kendi dışa aktarma biçimini doğrudan okumak: bir tarif onu yukarıdaki dosyaya dönüştürür.
  • Dosyaları hiçbir şey kurmadan barındırılan siteye yüklemek.
  • Bir hakemin geçti ya da kaldı kararlarından ayrı olarak puanlarını doğrulamak.

Sonra nereye