API Python

Semua yang dilakukan CLI juga dapat dilakukan oleh library-nya. Gunakan library ini ketika evaluasi seharusnya berada di dalam skrip, notebook, atau suite pengujian, bukan di samping file konfigurasi.

from oloproof import evaluate, system, current_case
from oloproof.evaluators import ExactMatch, Contains, JsonSchema, Regex, RubricJudge, evaluator

Semua yang berada di bawah oloproof_core adalah bagian internal mesin dan bukan bagian dari antarmuka ini.

Sistem menerima input kasus, bukan kasusnya

Inilah satu hal yang perlu dibuat benar sejak awal, karena kesalahannya gagal secara diam-diam.

@system(name="support-bot", version="1")
def answer(case):
    return {"label": "refund" if "refund" in case["question"].lower() else "other"}

Satu baris dataset terlihat seperti ini:

{"id":"refund_00","input":{"question":"Can I get a refund? #0"},"expected":{"label":"refund"}}

Fungsi tersebut menerima objek input, sehingga case["question"] adalah pertanyaannya dan tidak ada case["expected"]. Apa yang dikembalikannya adalah output yang dibaca evaluator, sehingga ExactMatch(field="label") membandingkan label yang dikembalikan dengan label yang diharapkan kasus tersebut.

Menjalankannya

result = evaluate(
    system=answer,
    dataset="data/example.jsonl",
    evaluators=[ExactMatch(criterion="exact_label", field="label")],
)

for metric in result.metrics:
    print(metric.metric, metric.estimate, metric.interval, metric.n_observed, metric.n_missing)

exact_label 1.0 lower=0.8842966917779722 upper=1.0 30 0

Tiga puluh kasus, semuanya benar, dan intervalnya masih menjangkau turun sampai 88,4%. Tiga puluh kasus tidak dapat menetapkan lebih dari itu, apa pun yang dikatakan estimasinya.

Membaca kasus yang gagal

Jika sistem memunculkan exception, kasus itu menjadi hilang, bukan salah, dan metrik melaporkannya:

exact_label None lower=0.0 upper=1.0 0 30

Estimasi None dengan interval yang mencakup seluruh rentang berarti tidak ada yang teramati. Periksa n_missing sebelum memercayai sebuah estimasi: sistem yang setiap kasusnya memunculkan exception menghasilkan objek hasil yang secara struktur baik-baik saja, dan hitungan itulah yang memberi tahu Anda bahwa hasilnya kosong.

Itu adalah kontrak penyebut yang menjalankan tugasnya, bukan kegagalannya — kasus yang mengalami error dibatasi, bukan dibuang — tetapi tidak ada yang memunculkan exception atas nama Anda, jadi pemeriksaan itu menjadi tanggung jawab Anda.

Menulis evaluator Anda sendiri

@evaluator mengubah sebuah fungsi menjadi evaluator. Fungsi itu menerima satu argumen, yaitu kasusnya, dan membaca apa yang diperlukannya dari kasus tersebut: case.output adalah apa yang dikembalikan sistem dan case.expected adalah objek expected dari baris tersebut.

from oloproof.evaluators import evaluator

@evaluator(criterion="known_label", reads=("output",))
def known_label(case):
    return case.output["label"] in {"refund", "other"}

result = evaluate(system=answer, dataset="data/example.jsonl", evaluators=[known_label])

known_label 1.0 lower=0.8842966917779722 upper=1.0 30 0

reads mendeklarasikan bagian kasus mana yang dibacanya, untuk keperluan provenans; bawaannya adalah ("output", "expected"). Evaluator ini mengembalikan True atau False, atau sebuah skor jika mendeklarasikan value_type="score" dan score_range tempat skornya berada. Versinya mencakup digest dari file yang mendefinisikannya, sehingga menyuntingnya membatalkan penilaian yang tersimpan di cache.

Fungsi yang ditulis sebagai def f(output, expected) ditolak saat dideklarasikan, disertai bentuk yang berfungsi, alih-alih gagal pada setiap kasus.

Menerapkan kebijakan

evaluate menerima sebuah kebijakan dan memutuskan eksekusi tersebut, dengan aturan yang sama yang dibaca CLI dari release.yaml:

result = evaluate(
    system=answer,
    dataset="data/example.jsonl",
    evaluators=[ExactMatch(criterion="exact_label", field="label")],
    policy="release.yaml",
)
print(result.gate)

Tanpa kebijakan, result.gate bernilai None: tidak ada aturan yang bisa tidak terpenuhi, sehingga tidak ada yang perlu diputuskan.

Langkah selanjutnya

• Menulis suite membahas evaluator yang sama sebagai konfigurasi.
• Merekam apa yang dilakukan sistem membahas current_case() dan cara membaca

artefak di dalam evaluator.

• Membandingkan kandidat dengan baseline membahas alur kerja yang menjadi alasan

keberadaan interval.