04 Investigasi bersama manusia

Pendamping fasilitator untuk 04 Investigasi bersama manusia.

Waktu

Total ~20 menit.

• 3 menit — memfilter feedback negatif dan memverifikasi root Chat yang otoritatif.
• 4 menit — membuat tiga score config, lalu queue dengan attachment yang tetap.
• 4 menit — open-coding perilaku yang teramati sebelum mendiskusikan diagnosis.
• 5 menit — memeriksa bukti trace dan menjalankan SQL policy-v1/policy-v2 secara berdampingan.
• 4 menit — memasukkan koreksi, menyetujui, menyelesaikan, dan mencatat asal-usulnya.

Persiapan awal instruktur

Sebelum peserta tiba, pastikan Modul 03 telah menghasilkan satu chat_turn otoritatif dengan Boolean user-thumbs=false dan sql-execution-success=true. Jaga kerahasiaan trace ID-nya dan konfirmasikan bahwa output root berisi pertanyaan, SQL yang dihasilkan, baris yang dikembalikan, dan hasilnya.

Buat tiga score config di proyek uji coba yang dapat dibuang jika Anda perlu berlatih, tetapi jangan buat lebih dulu queue final milik peserta. Set ID score config yang terlampir pada sebuah queue bersifat tetap sejak queue dibuat, sehingga ruangan harus membuat konfigurasi terlebih dahulu lalu melampirkan ketiganya:

Latihan anotasi ini hanya dilakukan lewat UI. Skrip runtime dapat memverifikasi score pada trace dan kemudian mempromosikan hasil ekspor yang sudah ditinjau, tetapi skrip tersebut tidak membuat queue, menuliskan penilaian manusia, maupun menyelesaikan task anotasi.

Alur bicara

1. Filter Tracing untuk user-thumbs = false dan cocokkan dengan trace ID dari worksheet Modul 03. Katakan: "feedback menentukan apa yang kita investigasi selanjutnya, bukan apa yang kita simpulkan."

2. Gunakan Settings → Scores → Create untuk setiap score config. Lalu gunakan Annotations → Queues → Create, beri nama queue production-investigation-<session> dengan suffix sesi yang unik, dan lampirkan ketiga config tersebut.

3. Pilih observation root chat_turn, buka dropdown Annotate-nya, dan pilih queue yang baru dibuat. Tunjukkan juga child llm_call, tetapi jelaskan mengapa itu target yang salah: observation tersebut tidak memiliki hasil eksekusi terstruktur end-to-end dan bukan insiden feedback yang secara logis relevan.

4. Ingatkan peserta bahwa Modul 03 telah membuka setup yang di-seed, lalu minta mereka mengesampingkan pengetahuan itu dan berlatih open-coding yang murni berdasarkan hal yang teramati. Catatan pertama yang baik adalah:

   The SQL executed and returned a count. The observed count differs from the second
   reference count. The query uses a 90-day customer signup window, and the trace
   metadata reports policy-v1.

5. Baru setelah ruangan mencatat catatan itu, ungkapkan bukti lengkapnya: metadata yang diemit policyversion=policy-v1, SQL/hasil berbasis signup, dan kedua score tersebut. Field sumbernya adalah policy_version; adapter OpenTelemetry mengemitnya sebagai key Langfuse yang sudah disanitasi, policyversion.

6. Jalankan kedua definisi policy ini secara berdampingan. Referensi policy-v1 adalah:

   SELECT count() FROM v_customers
   WHERE signup_date >= today() - INTERVAL 90 DAY

   Referensi policy policy-v2 yang berlaku saat ini adalah:

   SELECT uniqExact(customer_id) FROM v_orders
   WHERE order_ts >= now() - INTERVAL 30 DAY
   AND status NOT IN ('cancelled', 'returned')

7. Baru setelah perbandingan itu, terapkan diagnosisnya: catat failure-category=stale-business-policy, alihkan Corrected Output ke plain-text mode, dan tempelkan query terkini apa adanya. Langfuse tidak menjalankan SQL, jadi verifikasi teks tersebut secara persis lewat read-only client dari Langkah 6 sebelum menetapkan approved-for-golden=true dan menyelesaikan task.

8. Simpan source_trace_id, failure_category, source_policy_version, koreksinya, dan ID task anotasi (opsional) untuk Modul 05.

Tiga diagnosis yang menggoda tapi salah

• "Model mengabaikan prompt." SQL pada trace mengikuti konteks policy-v1 yang eksplisit. Kegagalannya adalah policy yang sudah usang di produksi, bukan ketidakpatuhan terhadap instruksi yang diberikan.
• "sql-execution-success rusak." SQL-nya berhasil dieksekusi, sehingga evaluator operasional itu memang benar mengembalikan true. Desainnya memang tidak menguji makna bisnis yang diatur secara kebijakan.
• "Thumbs-down membuktikan SQL-nya salah." Feedback hanya menandai trace mana yang perlu ditinjau. Itu tidak mengungkap maksud pengguna secara pasti maupun menyediakan query pengganti yang terverifikasi; pengecekan policy berdampingan dan review manusia lah yang melakukan itu.

Jaga agar alternatif-alternatif ini tetap terlihat sampai peserta selesai open-coding trace-nya. Jawaban yang sudah di-seed memang diketahui instruktur, tetapi investigasinya harus tetap memodelkan review yang benar-benar mengutamakan bukti.

Penargetan root observation

Ada dua observation yang relevan dalam trace ini:

Jika seorang peserta salah menambahkan child-nya, jangan selesaikan itu sebagai investigasi produksi. Tambahkan root chat_turn ke queue yang benar dan biarkan/hapus task yang salah tersebut sesuai kebijakan retensi proyek. Simpan trace ID, bukan ID child observation-nya, sebagai source_trace_id.

Attachment queue yang tetap dan penamaan yang aman untuk reset

Langfuse mengunci set ID score config yang terlampir pada sebuah queue sejak queue itu dibuat. Sebuah queue tidak bisa melampirkan config yang terlewat belakangan, sehingga membuat semua config lebih dulu adalah praktik yang paling aman. Score config sendiri bersifat mutable: perubahan yang didukung pada name, schema, atau nilai categorical memerlukan audited score-config update, dan update tersebut tidak menulis ulang score yang sudah ada.

Gunakan suffix yang aman untuk reset, misalnya:

production-investigation-<session>-retry-1

Jika queue-nya terlewat melampirkan satu config atau melampirkan ID config yang salah, buat queue baru dengan suffix berbeda yang melampirkan ketiga ID yang benar, tambahkan lagi root yang otoritatif, dan tandai dengan jelas bahwa queue lama sudah superseded (atau hapus hanya jika kebijakan proyek mengizinkannya). Untuk perubahan yang didukung pada config yang sudah terlampir, gunakan audited score-config update, bukan membuat ulang queue. Jangan pernah menggunakan kembali nama queue yang sudah selesai dengan cara yang mengaburkan task mana yang menghasilkan keputusan tersebut.

Keandalan corrected output

Koreksi ini akan menjadi ground truth golden di masa depan, sehingga sintaks maupun kesesuaian policy-nya sama-sama penting. Alihkan Corrected Output ke plain-text mode sebelum menempelkan SQL mentah. Langfuse menyimpan teksnya tetapi tidak mengeksekusinya; sebelum disetujui, eksekusi teks tersebut secara persis lewat read-only ClickHouse client dari Langkah 6. Query yang terlihat benar tapi malformed, mereferensikan raw table, berisi banyak statement, atau gagal di ClickHouse harus tetap tidak disetujui.

Untuk SQL yang malformed:

1. tetapkan atau biarkan approved-for-golden=false;
2. jangan selesaikan task tersebut sebagai approved;
3. perbaiki koreksinya terhadap view v_* yang diizinkan;
4. jalankan ulang dan periksa hasilnya; dan
5. setujui dan selesaikan hanya setelah verifikasi.

Jika seseorang sudah menyelesaikan task dengan koreksi yang malformed, buat queue/task baru dengan suffix baru dan ulangi review-nya, jangan diam-diam mengedit dan menghapus jejak audit-nya. Command promotion Modul 05 juga memvalidasi SQL read-only dan mengeksekusinya, tetapi guard itu bukan pengganti review manusia.

Kegagalan umum

• Tidak ada trace setelah filtering — konfirmasikan bahwa tipe score-nya Boolean dan filternya user-thumbs=false; jangan mencari nama score lama. Cocokkan dengan trace ID dari worksheet, bukan memilih diagnostik curl yang belum diberi rating.
• Target salah — task hanya menampilkan transcript/SQL karena llm_call yang ditambahkan. Kembali ke trace-nya dan tambahkan root chat_turn.
• Dimensi queue hilang — queue dibuat tanpa melampirkan salah satu config ID yang wajib. Buat queue baru dengan suffix lain; jangan lanjutkan dengan form review yang tidak lengkap. Gunakan audited config update, bukan membuat ulang queue, untuk perubahan yang didukung pada config yang sudah terlampir.
• Metadata policy terlihat hilang — cari policyversion yang diemit, bukan policy_version sumbernya, lalu konfirmasikan tag policy-v1 pada root-nya.
• Count-nya cocok secara tak terduga — hentikan diagnosisnya. Jalankan ulang scenario preflight Modul 03 dan jangan merekayasa bukti dari snapshot data tanpa pembanding.
• Koreksinya berupa hasil format, bukan SQL mentah — alihkan Corrected Output ke plain-text mode dan tempelkan hanya query-nya saja.
• Koreksinya tidak bisa dieksekusi — Langfuse tidak akan menangkap ini. Biarkan approval-nya tetap false, perbaiki, dan jalankan ulang teks yang sama persis lewat client Langkah 6 sebelum menyelesaikan task.

Penyelesaian dan penyerahan

Sebelum berpindah ke Modul 05, verifikasi bahwa task yang sudah selesai memang untuk chat_turn yang otoritatif, observasinya dicatat sebelum diagnosis, koreksinya adalah SQL current-policy yang tepat, dan task-nya sudah approved. Worksheet peserta harus memuat:

source=production-feedback
source_trace_id=<authoritative Chat trace ID>
failure_category=stale-business-policy
source_policy_version=policy-v1
annotation_id=<task ID when available>

Score pengguna yang negatif tetap berada pada trace produksi sebagai sinyal triase. Anotasi manusia menyediakan ground truth yang sudah ditinjau. Modul 05 akan mempertahankan kedua asal-usul ini saat mempromosikan koreksinya dan membangun evaluator preventif.