Strategi verifikasi tutor AI tidak bisa disamakan dengan pengujian fitur CRUD atau API biasa. Masalah utamanya bukan hanya apakah respons model keluar, tetapi apakah sistem tetap stabil, tidak flaky, dan tidak merusak pengalaman belajar ketika prompt, model, konteks, atau orchestration berubah.

Untuk mencegah flaky test dan regresi belajar, tim perlu memisahkan evaluasi model dari verifikasi produk, membangun golden dataset untuk skenario pedagogis penting, memakai assertion berbasis rubrik alih-alih string exact-match, serta menjalankan regression suite yang menguji alur belajar end-to-end. Artikel ini fokus pada reliability engineering untuk tutor AI, bukan ringkasan riset pembelajaran.

Mengapa tutor AI lebih sulit diuji daripada fitur software biasa

Pada tutor AI, keluaran yang benar tidak selalu identik secara tekstual. Dua respons bisa sama-sama valid walaupun kalimatnya berbeda. Sebaliknya, respons yang tampak meyakinkan bisa gagal secara pedagogis: terlalu langsung memberi jawaban, tidak memeriksa pemahaman siswa, atau melompat ke konsep yang belum dikuasai.

Kesulitan pengujian biasanya datang dari beberapa sumber:

  • Non-determinism: output berubah antar-run walaupun input sama.
  • Multi-layer system: ada prompt template, retrieval, policy layer, classifier, memory, UI, dan telemetry.
  • Kualitas pedagogis sulit diukur: benar secara faktual belum tentu baik untuk belajar.
  • Perubahan kecil berdampak besar: update prompt atau model bisa mengubah gaya respons, panjang jawaban, dan urutan bimbingan.

Karena itu, strategi verifikasi tutor AI harus menjawab dua pertanyaan berbeda:

  1. Apakah komponen AI masih menghasilkan perilaku yang diinginkan?
  2. Apakah produk tutor masih aman, stabil, dan konsisten untuk alur belajar nyata?

Pisahkan evaluasi model dari verifikasi produk

1. Evaluasi model

Evaluasi model menilai kualitas keluaran AI terhadap dataset dan rubrik tertentu. Ini cocok untuk menjawab pertanyaan seperti:

  • Apakah tutor cenderung memberi hint sebelum jawaban final?
  • Apakah tutor menolak menjawab di luar topik atau permintaan berbahaya?
  • Apakah tutor menjaga level penjelasan sesuai tingkat siswa?

Evaluasi model biasanya toleran terhadap variasi bahasa. Yang diuji adalah sifat respons, bukan kesamaan string.

2. Verifikasi produk

Verifikasi produk menguji sistem sebagai software. Fokusnya meliputi:

  • kontrak API dan skema respons,
  • perilaku fallback saat model timeout,
  • penguncian state sesi belajar,
  • persistensi riwayat dialog,
  • guardrail kebijakan,
  • observability, logging, dan idempotensi.

Kesalahan umum adalah menaruh semua kekhawatiran itu dalam satu test end-to-end yang memanggil model sungguhan. Hasilnya mahal, lambat, dan mudah flaky. Lebih baik pecah menjadi lapisan pengujian yang jelas.

Test pyramid untuk sistem tutor AI

Test pyramid tetap relevan, tetapi definisinya perlu disesuaikan untuk sistem AI.

Lapisan 1: Unit test deterministik

Lapisan ini harus menjadi mayoritas. Jangan memanggil model sungguhan. Uji logika yang bisa dibuat deterministik:

  • pemilihan prompt berdasarkan level siswa,
  • formatting konteks pelajaran,
  • truncation riwayat chat,
  • parser output terstruktur,
  • policy router untuk kapan memberi hint atau kapan eskalasi,
  • mapping telemetry dan event analytics.

Contoh yang layak diuji di unit test:

function buildTutorPrompt(input) {
  return {
    system: "Anda tutor matematika. Jangan beri jawaban final terlalu cepat.",
    context: {
      gradeLevel: input.gradeLevel,
      lessonGoal: input.lessonGoal,
      priorAttempts: input.priorAttempts.slice(-3)
    },
    user: input.message
  };
}

// assertion
expect(prompt.context.priorAttempts.length).toBeLessThanOrEqual(3);
expect(prompt.system).toContain("Jangan beri jawaban final terlalu cepat");

Unit test seperti ini tidak membuktikan kualitas pedagogis, tetapi sangat efektif untuk mencegah bug orchestration.

Lapisan 2: Integration test dengan mock model

Di sini Anda menguji interaksi antarkomponen tanpa ketergantungan pada output model nyata. Mock respons model untuk skenario penting:

  • respons valid dengan struktur yang diharapkan,
  • respons kosong atau malformed,
  • timeout, rate limit, dan error upstream,
  • respons yang memicu policy blocker.

Tujuannya adalah memastikan aplikasi bereaksi benar terhadap kondisi tersebut.

// pseudo test
mockModel.reply({
  text: "Coba pikirkan pecahan mana yang lebih besar jika penyebutnya sama.",
  intent: "hint"
});

const result = await tutorService.respond(session);
expect(result.type).toBe("hint");
expect(result.uiActions.showTryAgain).toBe(true);
expect(eventBus.publish).toHaveBeenCalledWith(
  expect.objectContaining({ name: "tutor_response_generated" })
);

Lapisan 3: Scenario test dengan model sungguhan, tetapi terbatas

Gunakan ini untuk regression suite yang lebih kecil namun bernilai tinggi. Jangan jadikan semua test CI bergantung pada model nyata. Pilih skenario yang mewakili risiko produk:

  • siswa meminta jawaban langsung sebelum mencoba,
  • siswa memberi jawaban salah dua kali berturut-turut,
  • siswa berpindah topik di tengah sesi,
  • retrieval memasok konteks ambigu,
  • permintaan di luar kebijakan pembelajaran.

Lapisan ini cocok dijalankan terjadwal, sebelum rilis, atau sebagai gated approval untuk perubahan prompt/model.

Golden dataset: fondasi regression yang benar

Golden dataset adalah kumpulan contoh percakapan atau input yang dianggap representatif terhadap perilaku tutor yang ingin dipertahankan. Isinya bukan hanya pertanyaan akademik, tetapi juga konteks belajar dan ekspektasi pedagogis.

Apa yang harus ada di golden dataset

  • Profil siswa: tingkat kelas, kemampuan awal, bahasa, dan preferensi penjelasan jika relevan.
  • Konteks pelajaran: tujuan belajar, materi, dan konsep prasyarat.
  • Riwayat interaksi: percobaan sebelumnya, kesalahan umum, dan respons tutor sebelumnya.
  • Rubrik evaluasi: apa yang dianggap lulus atau gagal.

Contoh struktur dataset:

{
  "case_id": "fractions_hint_01",
  "student_profile": {
    "grade_level": "SMP",
    "mastery": "beginner"
  },
  "lesson_goal": "membandingkan pecahan dengan penyebut sama",
  "history": [
    { "role": "student", "text": "Aku bingung mana yang lebih besar, 3/8 atau 5/8" }
  ],
  "expected_rubric": {
    "must_offer_hint_before_final_answer": true,
    "must_not_shame_student": true,
    "must_stay_on_topic": true,
    "should_use_simple_language": true
  }
}

Prinsip memilih kasus

Jangan hanya pilih contoh yang mudah dan “cantik”. Golden dataset harus mencakup:

  • kasus normal yang sering terjadi,
  • kasus batas seperti pertanyaan ambigu,
  • kasus risiko tinggi seperti permintaan jawaban instan,
  • kasus historis yang pernah menyebabkan bug atau keluhan siswa,
  • kasus regresi setelah perubahan prompt/model sebelumnya.

Jika dataset terlalu kecil, ia tidak mewakili perilaku sistem. Jika terlalu besar sejak awal, biaya pemeliharaannya tinggi. Mulailah dari suite kecil berisiko tinggi, lalu tambah berdasarkan insiden nyata.

Rubric-based assertions: jangan pakai exact-match untuk respons tutor

Untuk tutor AI, exact string match hampir selalu rapuh. Yang perlu diuji adalah apakah respons memenuhi rubrik perilaku tertentu. Inilah inti dari strategi verifikasi tutor AI yang tahan terhadap variasi teks.

Contoh rubrik yang realistis

  • Pedagogical scaffolding: memberi petunjuk bertahap sebelum jawaban final.
  • Concept alignment: tetap pada tujuan belajar saat ini.
  • Misconception handling: merespons kesalahan siswa dengan koreksi yang relevan.
  • Tone safety: tidak merendahkan, tidak menghukum, tidak manipulatif.
  • Answer containment: tidak membocorkan solusi penuh ketika mode latihan aktif.

Pola assertion yang lebih stabil

Gunakan kombinasi beberapa metode:

  1. Structured output bila memungkinkan, misalnya model diminta mengeluarkan field seperti response_type, hint_level, atau final_answer_included.
  2. Rule-based checks untuk aturan keras, misalnya respons tidak boleh mengandung pola “jawaban akhirnya adalah” ketika mode hint aktif.
  3. LLM-as-judge terbatas untuk penilaian semantik, tetapi hanya sebagai pelengkap dan dengan rubrik yang sangat spesifik.
  4. Human review untuk perubahan besar pada prompt/model atau kasus pedagogis sensitif.

Contoh rubric-based assertion:

const evaluation = evaluateTutorReply(reply, {
  mode: "practice",
  rubric: {
    forbidDirectFinalAnswer: true,
    requireOneActionableHint: true,
    requireTopicAlignment: true
  }
});

expect(evaluation.pass).toBe(true);
expect(evaluation.checks.forbidDirectFinalAnswer).toBe(true);
expect(evaluation.checks.requireOneActionableHint).toBe(true);

Catatan: Jika Anda memakai judge model untuk scoring, jangan perlakukan hasilnya sebagai kebenaran absolut. Simpan rubrik, prompt evaluator, dan contoh disagreement untuk audit. Judge model juga bisa drift dan bias.

Mendeteksi flaky test akibat output non-deterministik

Flaky test pada tutor AI sering muncul bukan karena bug aplikasi, tetapi karena perubahan kecil pada output model mematahkan assertion yang terlalu ketat. Ada beberapa cara praktis untuk mendeteksinya lebih awal.

Tanda test Anda terlalu flaky

  • Test kadang gagal lalu lolos saat di-run ulang tanpa perubahan kode.
  • Gagal hanya pada bagian phrasing, bukan substansi.
  • Durasi dan hasil sangat sensitif terhadap kondisi jaringan atau rate limit.
  • Prompt/model sama, tetapi struktur jawaban kadang berubah.

Teknik mitigasi

  • Turunkan suhu atau gunakan mode paling deterministik bila memang tersedia dan sesuai kebutuhan verifikasi.
  • Uji properti, bukan kalimat persis.
  • Normalisasi output untuk whitespace, bullet style, atau variasi casing sebelum assertion non-semantik.
  • Run repeated trials untuk suite kecil guna mengukur stabilitas pada skenario berisiko tinggi.
  • Simpan artefak: prompt final, context, model identifier, response raw, dan hasil evaluator saat test gagal.

Pendekatan repeated-run yang berguna

Untuk beberapa scenario test dengan model nyata, jalankan beberapa kali dan nilai berdasarkan tingkat kelulusan minimum, bukan satu run tunggal.

// pseudo
const trials = await runScenarioNTimes("fractions_hint_01", 5);
const passRate = trials.filter(t => t.pass).length / trials.length;
expect(passRate).toBeGreaterThanOrEqual(0.8);

Pendekatan ini masuk akal untuk sistem non-deterministik, tetapi jangan dipakai sembarangan pada seluruh CI karena menambah biaya dan waktu. Pakai hanya pada suite kecil yang memang dirancang untuk memantau stabilitas perilaku.

Mock vs real model di CI: pilih berdasarkan tujuan test

Kapan memakai mock

Pakai mock di CI utama ketika tujuan Anda adalah:

  • validasi logika aplikasi,
  • deteksi bug integrasi internal,
  • menjaga pipeline tetap cepat dan murah,
  • menghindari kegagalan karena faktor eksternal.

Mock juga memudahkan reproduksi bug karena output tetap.

Kapan memakai model nyata

Pakai model nyata saat Anda ingin memverifikasi:

  • perubahan prompt besar,
  • migrasi model provider atau family model,
  • perubahan retrieval context yang memengaruhi kualitas jawaban,
  • regresi pedagogis yang tidak bisa ditangkap mock.

Pola pipeline yang disarankan

  1. PR CI cepat: unit test + integration test dengan mock.
  2. Nightly/scheduled eval: regression suite golden dataset dengan model nyata.
  3. Release gate: subset scenario kritis dengan approval manual bila ada perubahan prompt/model.

Dengan pola ini, Anda tidak menjadikan CI harian bergantung penuh pada layanan model, tetapi tetap punya sinyal kualitas yang cukup sebelum perubahan dirilis.

Regression suite untuk alur belajar, bukan hanya satu prompt

Produk tutor AI yang baik harus diuji sebagai alur belajar, bukan hanya satu respons. Banyak regresi muncul setelah 2-5 putaran interaksi, misalnya tutor lupa konteks, terlalu cepat mengungkap jawaban, atau tidak menyesuaikan dengan upaya siswa sebelumnya.

Contoh skenario end-to-end yang penting

  • Scaffolding bertahap: siswa salah dua kali, tutor tetap memberi hint progresif, belum memberi solusi penuh.
  • Recovery dari miskonsepsi: siswa menyamakan pembilang dan penyebut secara keliru, tutor mengoreksi konsep inti.
  • Context retention: tutor ingat tujuan belajar dan contoh yang baru saja dipakai.
  • Session boundary: sesi baru tidak mewarisi state lama secara salah.
  • Policy compliance: tutor menolak mengerjakan ujian langsung, lalu mengalihkan ke penjelasan konsep.

Contoh test case yang lebih konkret

Case: algebra_practice_scaffold_02
Given:
- mode = practice
- lesson goal = menyelesaikan persamaan linear sederhana
- student has made 2 incorrect attempts
When:
- student says: "Tolong kasih jawaban akhirnya saja"
Then:
- tutor does not provide full final answer immediately
- tutor gives exactly one next-step hint
- tutor references the student's previous mistake
- tutor tone remains supportive
- session event 'hint_served' is recorded

Test case seperti ini jauh lebih berguna daripada memeriksa apakah output mengandung kalimat tertentu.

Workflow approval untuk perubahan prompt dan model

Perubahan prompt sering dianggap ringan, padahal efeknya bisa setara dengan perubahan logika bisnis. Karena itu, prompt dan konfigurasi model perlu diperlakukan sebagai artefak yang versioned dan direview.

Praktik yang disarankan

  • Simpan prompt di repository, bukan hanya di dashboard manual.
  • Versioning untuk prompt template, evaluator prompt, dan rubrik.
  • Diff yang terbaca manusia agar reviewer bisa melihat perubahan instruksi pedagogis.
  • Jalankan eval otomatis pada golden dataset sebelum merge.
  • Approval manual dari engineer atau learning designer untuk perubahan berisiko tinggi.
  • Canary rollout bila memungkinkan, lalu amati telemetri dan keluhan pengguna.

Contoh workflow sederhana

  1. Developer mengubah prompt tutor atau mengganti model target.
  2. PR otomatis menjalankan unit/integration test.
  3. Pipeline evaluasi menjalankan regression suite golden dataset.
  4. Hasil eval ditampilkan sebagai diff: kasus baru gagal, skor rubrik turun, atau respons jadi lebih langsung.
  5. Reviewer menyetujui jika perubahan dapat dijelaskan dan risiko diterima.
  6. Deploy ke sebagian traffic, monitor, lalu rollout penuh jika stabil.

Checklist CI yang realistis untuk tutor AI

Berikut checklist yang praktis dan tidak terlalu bergantung pada test mahal.

PR CI cepat

  • Semua unit test orchestration lulus.
  • Semua integration test dengan mock model lulus.
  • Schema validation untuk structured output lulus.
  • Guardrail rule-based untuk mode latihan lulus.
  • Prompt/template linting dasar lulus, misalnya placeholder wajib tidak hilang.

Scheduled eval

  • Golden dataset inti dieksekusi dengan model nyata.
  • Pass rate per rubrik dipublikasikan sebagai artefak.
  • Kasus yang gagal menyimpan raw prompt, context, response, dan evaluator output.
  • Perbandingan terhadap baseline sebelumnya tersedia.

Release gate

  • Tidak ada penurunan pada kasus kritis pedagogis.
  • Tidak ada kenaikan signifikan pada pelanggaran rule keras, seperti pemberian jawaban final di mode latihan.
  • Fallback untuk timeout/error provider terbukti bekerja.
  • Reviewer manusia menyetujui perubahan yang memengaruhi gaya bimbingan.

Metrik pass/fail yang realistis

Sistem AI jarang cocok dengan metrik biner tunggal. Gunakan kombinasi metrik keras dan lunak.

Metrik keras

  • Schema validity: output terstruktur valid.
  • Policy compliance: tidak melanggar aturan produk.
  • Critical rubric pass: misalnya tidak memberi solusi penuh pada mode latihan.
  • Error budget teknis: timeout, malformed output, atau fallback failure di bawah ambang internal tim.

Metrik lunak

  • Rubric pass rate untuk kualitas pedagogis.
  • Stability pass rate dari repeated-run pada skenario kritis.
  • Human review acceptance untuk sampel perubahan besar.

Contoh aturan lulus yang realistis:

  • semua critical checks harus 100% lulus,
  • kasus non-kritis boleh punya toleransi terbatas,
  • setiap penurunan pada skenario pembelajaran inti harus direview manual,
  • suite dengan model nyata dipakai sebagai sinyal kualitas, bukan satu-satunya gate otomatis.

Hindari target yang tampak presisi tetapi tidak stabil. Jika evaluator semantik sendiri masih berisik, jangan jadikan nilainya satu-satunya dasar blok merge.

Jebakan umum saat menguji kualitas pedagogis dan stabilitas respons

1. Menyamakan jawaban benar dengan pengajaran yang baik

Tutor bisa memberi jawaban yang benar tetapi buruk untuk belajar karena terlalu cepat menyelesaikan soal. Rubrik harus mengukur proses bimbingan, bukan hanya kebenaran isi.

2. Terlalu banyak test end-to-end dengan model nyata

Ini membuat pipeline lambat, mahal, dan sulit dipercaya. Pindahkan sebanyak mungkin logika ke unit dan integration test deterministik.

3. Exact-match pada teks natural language

Ini sumber flaky test paling umum. Ganti dengan assertion berbasis properti dan rubrik.

4. Tidak menyimpan artefak kegagalan

Tanpa prompt final, context, dan raw output, debugging hampir mustahil. Simpan semua input penting setiap evaluasi gagal.

5. Mengabaikan alur multi-turn

Banyak regresi hanya muncul setelah beberapa putaran. Satu prompt tunggal tidak cukup untuk memverifikasi tutor AI.

6. Tidak memisahkan baseline pedagogis dan baseline teknis

Masalah reliability bisa berasal dari parsing, retrieval, state management, atau model behavior. Jika semua dicampur, akar masalah sulit ditemukan.

Penutup

Strategi verifikasi tutor AI yang efektif berangkat dari satu prinsip: jangan paksa sistem non-deterministik diuji seperti fungsi deterministik murni. Bangun pyramid pengujian yang mayoritas deterministik, pisahkan evaluasi model dari verifikasi produk, gunakan golden dataset dan rubrik perilaku, lalu tempatkan model nyata pada regression suite yang kecil namun bernilai tinggi.

Jika dilakukan dengan disiplin, pendekatan ini membantu tim mencegah dua kegagalan yang paling mahal pada produk edukasi berbasis AI: flaky test yang menggerus kepercayaan engineering dan regresi belajar yang lolos ke pengguna nyata. Reliability di tutor AI bukan hasil dari satu jenis test, melainkan hasil desain verifikasi yang sadar terhadap sifat sistem AI itu sendiri.