Langsung ke konten
Dokumentasi
Log perubahanHargaBuka konsol

Panduan

Dari nol hingga putusan atas aplikasi Anda sendiri

Anda punya fungsi Python yang menjawab pertanyaan, dan ingin tahu apakah fungsi itu cukup baik untuk dirilis. Tiga perintah membawa Anda dari fungsi itu ke keputusan rilis, tanpa YAML yang ditulis tangan: oloproof init --system menulis proyek di sekitar fungsi Anda, oloproof check memberi tahu apakah proyek itu akan berjalan sebelum ada yang dibelanjakan, dan oloproof run memutuskan. Semuanya berjalan di mesin Anda, tanpa akun dan tanpa panggilan model.

Setiap keluaran di bawah berasal dari menjalankan perintah-perintah ini pada fungsi yang ditampilkan.

1Fungsi Anda

Fungsi apa pun yang menerima satu kasus dan mengembalikan jawaban. Yang ini adalah bot.py, dengan modul pembantu yang diimpornya:

from prompts import GREETING


def answer(question):
    text = question.lower()
    if "refund" in text:
        reply = "Refunds are available within 30 days of purchase."
    elif "ship" in text:
        reply = "We ship to the US and Canada."
    else:
        reply = "A support agent will follow up within one business day."
    return {"reply": f"{GREETING} {reply}", "topic": "support"}

2Tulis proyek di sekitarnya

Dari direktori yang berisi bot.py:

oloproof init --system bot:answer
Initialized Oloproof project in . around bot:answer
  Each case's input is a string, read from the function's first parameter.

Fill in before a run means anything:
  data/cases.jsonl  3 placeholder cases: give each a real input and, as its expected
                    phrase, words a right answer contains. Add more: see below.
  oloproof.yaml     the check reads the whole answer; if your function returns an
                    object, add `field:` naming the key that holds the text.
  release.yaml      a placeholder bar of 0.80; set the one your release needs.

What this suite can decide, if every case is measured:
  mentions-floor (mentions_expected at least 0.8, 3 cases):
    1 or more pass: INSUFFICIENT_EVIDENCE (not established yet); 0: FAIL
    (ruled out). With 50 cases, PASS from 46; with 100, from 89.

Next: oloproof check, then oloproof run

Referensinya diimpor terlebih dahulu, dan tidak ada yang ditulis kecuali referensi itu mengarah ke sebuah fungsi; galat dalam modul Anda berhenti di sini dengan nama file dan barisnya. Fungsinya tidak dipanggil. Tiga file muncul: oloproof.yaml (fungsi Anda dan satu pemeriksaan), data/cases.jsonl (tiga kasus pengganti) dan release.yaml (ambang batasnya). Masukan kasus berupa string karena parameter pertama bernama question; parameter bernama case, inputs, row atau yang dianotasi sebagai dict justru menerima objek.

Pemeriksaannya adalah contains: sebuah kasus lulus ketika jawabannya memuat frasa yang diharapkan dari kasus itu. Ini pemeriksaan deterministik, jadi tidak perlu diukur terhadap manusia sebelum boleh memutuskan. Panduan suite mencantumkan setiap pemeriksaan dan juri lainnya.

3Isi kasusnya

Ganti kasus pengganti dengan pertanyaan nyata dan kata-kata yang dimuat jawaban yang benar, satu kasus per baris:

{"id": "refund_01", "input": "Can I get a refund?", "expected": {"phrase": "30 days"}}
{"id": "ship_01", "input": "Do you ship to Canada?", "expected": {"phrase": "US and Canada"}}
{"id": "other_01", "input": "My order is late", "expected": {"phrase": "follow up"}}

Tiga kasus tidak dapat melewati ambang 0,80, seperti kata tabel di atas: dengan tiga, jawaban terbaik adalah INSUFFICIENT_EVIDENCE. Eksekusi di bawah memakai 30 kasus seperti ini, sepuluh per topik, dan di sana 29 yang lulus sudah cukup.

4Periksa sebelum menjalankan

oloproof check

Sebelum field diatur, keluarannya:

ok   System: callable bot:answer imports.
ok   Called on case refund_01: it answered {"reply": "Thanks for writing in. Refunds are available within 30 days of purchase.", "topic": "support"}

Evaluators on that answer (one case, not a result):
ok   mentions_expected (contains) can read the answer; it passed this case.
note   It reads the whole answer object; `field:` can name one of reply, topic.

Jadi tambahkan field: reply di bawah pemeriksaan dalam oloproof.yaml, lalu periksa lagi:

ok   System: callable bot:answer imports.
ok   Called on case refund_01: it answered {"reply": "Thanks for writing in. Refunds are available within 30 days of purchase.", "topic": "support"}

Evaluators on that answer (one case, not a result):
ok   mentions_expected (contains) can read the answer; it passed this case.

Code: the system's version hashes bot.py, prompts.py. Edit one and the next run calls the system again.

What this suite can decide, if every case is measured:
  mentions-floor (mentions_expected at least 0.8, 30 cases):
    29 or 30 pass: PASS (established); 19 to 28: INSUFFICIENT_EVIDENCE (not
    established yet); 18 or fewer: FAIL (ruled out). With 50 cases, PASS from
    46; with 100, from 89.

CI: no model key is needed for the evaluators. Keys your own function reads are not checked here.

Ready. Next: oloproof run

Arti setiap bagian:

  • Impor dan jawaban: Sistem dibangun persis seperti oloproof run membangunnya, dan dipanggil pada kasus pertama (--case ID memilih kasus lain, --no-call melewati panggilan). Jika memunculkan eksepsi, baris itu menyebut galatnya serta file dan baris dalam kode Anda.
  • Evaluator: Setiap pemeriksaan yang tidak memerlukan model dijalankan pada satu jawaban itu. Field yang tidak dapat ditemukannya disebutkan bersama field yang dimiliki jawaban. Lulus atau gagal di sini adalah satu kasus, bukan hasil. Juri berbasis model tidak pernah dipanggil oleh check; ia mengatakannya, dan eksekusi yang memanggilnya.
  • Kode: File-file yang isinya menjadi versi sistem: modulnya dan modul proyek yang diimpornya, ditambah system.code_paths jika ada. File proyek yang dimuat saat mengimpor atau memanggil sistem tetapi tidak termasuk di antaranya (misalnya modul yang diimpor berdasarkan nama saat eksekusi) dicantumkan sebagai tidak di-hash: tambahkan ke code_paths, atau perubahan padanya memakai ulang jawaban yang usang.
  • Apa yang dapat diputuskan: Tabel yang sama dengan oloproof plan. Tanpa release.yaml, ia mengatakan bahwa eksekusi menjawab dengan kata-kata sederhana dan tidak memutuskan apa pun.
  • CI: Setiap model yang dipanggil proyek dan rahasia yang dibutuhkan job CI untuknya, ANTHROPIC_API_KEY atau OPENAI_API_KEY kecuali api_key_env menyebut yang lain, dan tidak ada untuk server di mesin ini.

check tidak menyimpan apa pun. Ia keluar dengan 2 bila ada yang harus diperbaiki dan 0 bila tidak, dan oloproof check --json mencetak temuan yang sama sebagai satu dokumen.

5Jalankan

oloproof run
Gate: ALLOW (exit 0)
mentions-floor:
  100.0%, range 88.4% to 100.0% (exact binomial interval); 30 of 30 cases

Laporan eksekusinya lebih panjang; ini putusan dan baris aturannya. Ke-30 kasus lulus, dan rentang tempat tingkatnya berada dimulai dari 88,4%, di atas ambang 0,80, sehingga aturannya menyatakan PASS dan gerbang mengizinkan rilis. oloproof inspect latest membacanya lagi.

Selanjutnya

  • Tambahkan gerbang ke pull request: oloproof init --ci github menulis workflow di samping proyek ini (panduan CI).
  • Ganti pemeriksaan dengan juri ketika sebuah frasa tidak dapat menyatakan apa jawaban yang benar (panduan juri); oloproof check lalu menyebut kunci yang dibutuhkan CI.
  • Sudah punya jawaban dalam file, bukan fungsi? oloproof eval answers.jsonl memeriksanya tanpa proyek sama sekali.