05 Tutup siklusnya

Pendamping fasilitator untuk 05 Tutup siklusnya.

Waktu

~25 menit total.

• 5 menit — membuat dan mempromosikan tiga catatan turunan produksi.
• 5 menit — menjalankan eksperimen berpasangan policy-v1 dan policy-v2.
• 5 menit — membandingkan correctness dan mengkalibrasi business-policy-adherence.
• 5 menit — mengaktifkan aturan observasi yang terjaga dan memutar ulang empat jenis metrik.
• 5 menit — memeriksa bukti, mendiskusikan rollback, biaya, dan siklus umpan balik berikutnya.

Kedua eksperimen dan evaluator asinkron mungkin berjalan lebih lama daripada blok fasilitasi ini. Mulai proses secepatnya, gunakan waktu tunggu untuk sesi diskusi konseptual, dan latih latensi penyedia sehari sebelumnya.

Pemeriksaan awal instruktur

Jalankan pemeriksaan perintah non-mutasi ini dari root lab dan pastikan konfigurasi yang dipilih sudah ada sebelum sesi:

cd ClickHouse_Demos/workshops/agent_arena
.venv/bin/python -m scripts.promote_to_golden --help
.venv/bin/python -m scripts.provision_online_evaluators --help
.venv/bin/python -m eval.harness --help
.venv/bin/python -m scripts.verify_online_scores --help

Kemudian pastikan:

• Modul 03 memiliki satu chat_turn root otoritatif dengan sql-execution-success=true dan Boolean user-thumbs=false;
• tugas production-investigation-<session> khusus UI dari Modul 04 sudah diselesaikan, SQL yang telah dikoreksi sudah dieksekusi, trace ID aslinya tersedia secara privat, dan ID tugas anotasinya tercatat saat Langfuse menampilkannya;
• reviewed.json akan dibuat dari tinjauan asli tersebut, bukan dari fixture sintetis yang sudah dilacak;
• WINNER_MODEL, WINNER_PROMPT, dan WINNER_CONFIG_ID semuanya menggambarkan pemenang room yang sama;
• koneksi LLM Langfuse agent-arena-openrouter dapat menjangkau model judge yang dikonfigurasi dan memiliki kredensial yang valid;
• keluaran kategoris terstruktur dari judge hanya menerima persis PASS, FAIL, dan NOT_APPLICABLE, beserta alasannya; dan
• dispatcher evaluator dalam kondisi sehat dan room dapat menerima skor asinkron.

Untuk setiap latihan, buat satu suffix unik dan simpan pasangan baseline/ candidate secara bersamaan:

export LOOP_RUN_SUFFIX="$(date +%Y%m%d-%H%M%S)"
export BASELINE_RUN_ID="online-loop-baseline-${LOOP_RUN_SUFFIX}"
export CANDIDATE_RUN_ID="online-loop-candidate-${LOOP_RUN_SUFFIX}"

Jangan gunakan kembali run ID dari sesi sebelumnya. Harness menambahkan versi kebijakan dan konfigurasi, dan ID dasar yang unik mencegah peserta membandingkan bukti yang tidak terkait atau bukti yang sebagian tertimpa.

Batas anotasi manual

Anotasi manusia pada Modul 04 memang disengaja untuk tidak diotomatisasi. Skrip runtime tidak membuat queue, mengisi penilaian manusia, memasukkan output yang dikoreksi, menyetujui item, atau menyelesaikan tugas. Fixture sintetis yang dilacak berguna untuk latihan instruktur ketika tinjauan asli belum ada, tetapi fixture itu tetap berstatus source=synthetic-reviewed-fixture dan tidak membuktikan bahwa siklus anotasi manusia telah selesai.

Untuk jalur peserta, gunakan reviewed.json asli yang diabaikan git. Kalimat aslinya adalah satu pertanyaan umpan balik pengguna yang nyata. Dua input lain adalah parafrase yang ditulis oleh reviewer, diturunkan dari insiden yang ditinjau tersebut:

How many active customers do we have?
What is our active customer count right now?
How many customers qualify as active under our business definition?

Ketiganya tetap mengacu pada trace sumber asli dan provenance anotasi yang sama. Sampaikan hal ini secara eksplisit agar peserta tidak salah mengira satu insiden produksi sebagai tiga trace umpan balik yang independen.

Keandalan dan provenance promosi

Sebelum room menjalankan promosi, periksa reviewed.json tanpa memproyeksikannya. Berkas ini harus memuat SQL read-only yang telah dikoreksi secara persis, provenance produksi yang diperlukan, dan tiga ID aman yang unik. Promosi pertama-tama memvalidasi seluruh batch lokal, lalu melakukan pembacaan metadata yang terautentikasi sebelum eksekusi ClickHouse atau upsert dataset. Promosi gagal secara fail-closed ketika metadata tidak dapat dibaca, dan menolak ID yang bertabrakan dengan provenance produksi asli yang berbeda.

Promosi asli yang identik bersifat idempoten. Fixture sintetis memerlukan flag --synthetic-fixture secara eksplisit; flag ini tidak dapat diberikan sebagai path langsung atau dikombinasikan dengan reviewed.json. Jangan pernah menjalankannya setelah promosi asli. Jika terjadi collision, pertahankan kedua sumber, selidiki item dataset yang sudah ada, dan pilih ID baru yang teraudit hanya jika item-item tersebut memang benar-benar mewakili kasus tinjauan yang berbeda.

Aturan eksperimen versus aturan observasi

Jaga agar kedua konteks ini tetap terlihat di slide atau whiteboard:

Provisioner memasang satu evaluator umum berbasis katalog, bukan evaluator yang hanya khusus untuk jumlah pelanggan. Katalog policy-v2-nya mencakup active customers, revenue, view-to-purchase conversion, dan gross margin; pertanyaan yang tidak relevan seharusnya menghasilkan NOT_APPLICABLE.

Fase --business-policy-experiments harus melaporkan online rule enabled=False. Periksa UI rule Langfuse sebagai pengaman kedua. Perintah enable yang dijalankan belakangan hanya membuktikan bahwa setidaknya ada satu skor business-policy-adherence yang terlampir pada dataset, tetapi itu tidak dapat menggantikan tinjauan kalibrasi lengkap dari instruktur.

Gerbang kalibrasi

Bandingkan baseline dan candidate pada item ID, model, dan prompt yang sama. Repo berisi 20 pertanyaan YAML, tetapi q019 dan q020 adalah holdout few-shot, sehingga project bersih dimulai dengan 18 item Experiment dan mencapai 21 setelah tiga promosi. Project bersama terverifikasi yang digunakan ulang memiliki 22 item hanya karena satu item lama yang tidak terkait dan sudah disetujui masih tersimpan; run berpasangan terbarunya bergerak dari 16/22 menjadi 19/22. Perlakukan ini sebagai bukti verifikasi berkualifikasi, bukan jumlah item wajib bagi peserta atau jaminan bahwa provider stokastik akan mereproduksi setiap agregat secara persis sama.

Jangan aktifkan kecuali semua gerbang berikut lolos:

• ketiga kasus prod-active-* berpindah dari FAIL dan salah di bawah policy-v1 menjadi PASS dan benar di bawah policy-v2;
• revenue (q005) dan conversion (q018) pada candidate adalah PASS;
• plain count (q001) adalah NOT_APPLICABLE;
• correctness setiap item yang sudah ada sebelumnya dibandingkan per item dan tidak ada regresi 1→0;
• correctness agregat tidak mengalami regresi; dan
• setiap item Experiment memiliki correctness, agent-arena-llm-judge, dan skor business-policy-adherence yang persis dengan structured output yang valid.

Judge yang memberi label PASS pada setiap count telah gagal dalam kalibrasi, meskipun candidate-nya terlihat baik. Gunakan probe NOT_APPLICABLE untuk menunjukkan bahwa penentuan keberlakuan kebijakan adalah langkah klasifikasi yang nyata.

Penskoran asinkron dan pemecahan masalah skor yang tidak muncul

Baik evaluasi experiment maupun observasi bersifat asinkron. Harness menunggu skor experiment yang diperlukan, sementara scripts.verify_online_scores melakukan polling terhadap skor trace live selama 180 detik secara default. Jangan melakukan refresh berulang kali, membuat ulang rule, atau melakukan enable lebih awal hanya karena skornya masih pending.

Jika skor tidak muncul:

1. Pastikan nama yang persis sesuai harapan. Experiment menggunakan business-policy-adherence; observasi serving menggunakan agent-arena-business-policy-online.
2. Pastikan dispatcher/execution worker evaluator dalam kondisi sehat.
3. Periksa koneksi agent-arena-openrouter dan ketersediaan model judge. Keterlambatan penyedia, rate limit, atau pembatasan routing dapat membuat evaluasi tetap pending atau gagal walaupun respons agen berhasil.
4. Pastikan rule experiment menargetkan dataset arena-golden dan rule observasi menargetkan observasi chat_turn root. Mapping harus mengekspos $.question dan $.sql.
5. Periksa structured output. Kategori yang hilang, kategori di luar tiga nilai yang diizinkan, atau alasan yang tidak ada merupakan kegagalan kalibrasi.
6. Jika provisioning melaporkan nama rule yang ambigu, hentikan dan selesaikan duplikasi nama rule yang persis di Langfuse sebelum mencoba lagi; jangan menebak duplikat mana yang telah diperbarui.

Simpan trace yang gagal dan bukti evaluator. Jangan mengubah outage penyedia menjadi PASS yang dipalsukan, dan jangan melewati gerbang skor yang hilang.

Panduan replay

Setelah enablement, restart serving secara eksplisit dengan policy-v2 dan gunakan empat pertanyaan persis milik peserta:

How many active customers do we have?
What was revenue in the last 30 days?
What is our view-to-purchase conversion rate for the last 7 days?
How many products are there?

Wajibkan keberhasilan operasional untuk setiap trace. Active customers, revenue, dan conversion harus memiliki agent-arena-business-policy-online=PASS; product count harus NOT_APPLICABLE.

Permintaan conversion memiliki batas stokastik yang telah terverifikasi. Izinkan paling banyak satu retry dengan konfigurasi yang sama, simpan kedua trace ID beserta hasilnya, dan hentikan jika tidak ada satu pun percobaan yang lolos. Kegagalan yang berulang adalah bukti produksi baru yang perlu diselidiki, bukan alasan untuk mengulang sampai hijau.

Sampling, biaya, dan keandalan

Aturan workshop menggunakan sampling 1 sehingga setiap trace yang memenuhi syarat menghasilkan bukti yang terlihat. Pada volume produksi, judge LLM pada setiap request menambah biaya penyedia, mengonsumsi rate limit, dan dapat menghasilkan skor setelah respons pengguna terkirim. Pilih sampling berdasarkan traffic, risiko insiden, biaya/latensi evaluator, dan cakupan yang dibutuhkan. Pertahankan pemeriksaan operasional deterministik secara luas; cadangkan penilaian semantik yang mahal untuk traffic dan metrik yang memang sepadan dengan biayanya.

Evaluator berfungsi sebagai monitoring, bukan otorisasi jalur request. Judge yang tertunda tidak boleh diam-diam memblokir respons serving. Arahkan skor yang hilang, penyimpangan kategori, dan ketidaksesuaian sinyal ke alert operasional atau backlog tinjauan, sesuai dengan service-level objective sistem.

Rollback dan reset

Jika judge observasi menghasilkan false pass, false fail, output yang cacat, atau biaya/latensi yang tidak dapat diterima setelah enablement:

1. Buka Evaluations di Langfuse, temukan rule observasi yang persis, agent-arena-business-policy-online, dan alihkan ke disabled.
2. Pastikan observasi chat_turn baru tidak lagi menerima skor dari rule online tersebut.
3. Tetap jalankan policy-v2, sql-execution-success, dan 👍/👎 kecuali ada bukti tersendiri yang menyatakan sebaliknya; menonaktifkan judge yang bermasalah seharusnya tidak memunculkan kembali kebijakan lama yang sudah diketahui usang.
4. Tambahkan trace yang terdampak ke queue anotasi manusia dengan suffix, perbaiki katalog/prompt evaluator dan golden data, lalu ulangi kalibrasi eksperimen berpasangan sebelum mengaktifkan kembali.

Untuk menghentikan layanan lokal tanpa menghapus bukti remote:

scripts/arena.sh stop

scripts/arena.sh down juga menghapus database ClickHouse workshop dan user read-only-nya, tetapi tidak menghapus dataset Langfuse, run Experiment, queue anotasi, atau skor. Jangan gunakan ini sebagai rollback evaluator.

Alur penjelasan: siklus tetap terbuka

• Evaluator awal lolos karena kontraknya hanya "SQL berhasil dieksekusi". 👎 dari pengguna mengungkap kegagalan nilai di luar kontrak tersebut.
• Tinjauan manusia mengubah sinyal yang tidak pasti menjadi diagnosis dan koreksi yang teruji.
• Provenance produksi membuat insiden ini dapat diaudit ketika masuk ke golden set; parafrase meningkatkan cakupan variasi kalimat tanpa menciptakan trace pengguna tambahan.
• Eksperimen berpasangan memisahkan perubahan kebijakan dari perubahan model/prompt, dan menguji judge umum sebelum masuk produksi.
• PASS online tidak membuat umpan balik pengguna menjadi usang. Kondisi di masa depan berupa agent-arena-business-policy-online=PASS bersamaan dengan user-thumbs=false justru merupakan jenis ketidaksesuaian yang harus memulai kembali investigasi.

Gerbang penyelesaian

Jangan tutup modul ini sampai room dapat menunjukkan keenam artefak berikut:

1. trace produksi dengan pass operasional dan sinyal negatif dari pengguna;
2. anotasi manusia yang telah diselesaikan dan SQL yang telah dikoreksi dan diverifikasi;
3. tiga golden item dengan provenance produksi yang asli;
4. bukti baseline/candidate pada dataset yang sama tanpa adanya regresi correctness yang sudah ada;
5. bukti Experiment FAIL, PASS, dan NOT_APPLICABLE yang telah dikalibrasi; dan
6. skor live yang telah diaktifkan di seluruh active customers, revenue, conversion, dan plain count, sementara 👍/👎 yang berkelanjutan tetap tersedia untuk siklus berikutnya.