Bulan lalu saya merilis perubahan pipeline yang benar-benar saya banggakan. Sebuah penulisan ulang prompt. Sebuah langkah review dengan konteks penuh. Sebuah rubrik terperinci untuk mendeteksi pengulangan dan menegakkan variasi struktural di seluruh segmen.
Saya deploy. Saya amati selama enam minggu. Saya bilang ke diri sendiri bahwa ini berfungsi.
Lalu saya membangun framework evaluasi. Menjalankannya di 40 episode produksi nyata dalam 7 bahasa. Dan menemukan bahwa langkah review — yang saya rancang dengan sangat hati-hati — membuat skrip secara terukur lebih buruk.
Bukan netral. Lebih buruk.
Dialog per segmen mendapat skor 3,34 dari 5. Outline mendapat 3,01. Dan skrip final, setelah review? 2,91.
Langkah yang dirancang untuk meningkatkan skrip malah menurunkan kualitas lebih dari 12%.
Pergeseran ini — dari "saya pikir ini berfungsi" menjadi "saya tahu ini tidak" — dimulai beberapa minggu lalu. Saya menonton kursus Agentic AI Andrew Ng di DeepLearning.AI, di mana dia menekankan sesuatu yang terdengar jelas tapi sebenarnya tidak: eval dan trace adalah fondasi dari sistem agentik mana pun. Tanpa itu, Anda men-debug dalam kegelapan. Dengan itu, Anda tahu persis tautan mana dalam rantai yang putus.
Saya telah menjalankan pemeriksaan kualitas skrip ad-hoc selama berbulan-bulan — metrik struktural seperti rasio panjang giliran dan keseimbangan pembicara, ditambah judge LLM yang membandingkan varian prompt A/B. Mereka mendeteksi regresi yang jelas. Tapi tidak komprehensif. Mereka mencakup satu tahap (dialog), satu bahasa dalam satu waktu, dan dirancang untuk pengujian A/B prompt, bukan audit kualitas di seluruh pipeline.
Poin Andrew tentang trace benar-benar menghantam. Pipeline saya memiliki lima panggilan LLM utama per episode — riset, outline, dialog per segmen, intro/outro, dan review — plus satu pass TTS ElevenLabs. Saya punya metrik kualitas untuk satu di antaranya. Empat lainnya hanya dipercaya berdasarkan insting.
Jadi saya membangun sistem evaluasi nyata. Lengkap. Multi-dimensi. Dapat dijalankan ulang. Inilah yang ditemukannya, enam perbaikan yang saya rilis dalam satu hari, dan apa yang benar-benar membaik.
Baseline: Tiga Angka yang Mengubah Segalanya
Saya mengevaluasi 40 episode lengkap dari database produksi saya — mencakup semua 7 bahasa (en, vi, ja, ko, es, zh, fr) dan 10 gaya podcast — terhadap tiga rubrik dengan lima dimensi masing-masing. Seorang judge LLM (GPT-5.6-terra) menilai setiap tahap.
| Stage | Score | Worst Dimension |
|---|---|---|
| Dialogue (per-segment) | 3.34 | Factual Grounding: 2.17 |
| Outline (research + structure) | 3.01 | Citation Credibility: 1.28 |
| Final Script (post-review) | 2.91 | Publishability: 1.95 |
Tiga hal langsung mencolok:
1. Pass review menurunkan skrip sebesar 0,43. Dialog mendapat 3,34. Setelah review? 2,91. Langkah yang dirancang untuk meningkatkan kualitas malah menghilangkannya.
2. Semua URL kutipan adalah redirect buram. Setiap "URL sumber" di setiap outline menunjuk ke vertexaisearch.cloud.google.com/grounding-api-redirect/AUZIYQ.... Ini berfungsi untuk manusia yang mengkliknya, tapi tampak sepenuhnya palsu bagi peninjau otomatis. 344 fakta memiliki URL sumber. Nol memiliki resolved_url — sebuah field yang bahkan belum ada saat itu.
3. Publishability adalah dimensi terendah di seluruh pipeline (1,95). Podcaster sungguhan, menurut judge evaluasi, tidak akan mempublikasikan skrip ini dengan nama mereka sendiri. Pola AI yang terdeteksi: pembuka segmen yang identik, transisi generik, tidak ada kepribadian host.
Evaluasi memberi saya daftar berperingkat tentang apa yang harus diperbaiki. Saya menghabiskan sisa hari untuk memperbaikinya.
Enam Perbaikan (Dan Dampak Terukurnya)
Perbaikan 1: URL Kutipan — 0% ke 100% Resolusi
Sebelum: 0 dari 344 fakta riset memiliki resolved_url. Setiap URL tampak palsu.
Perbaikan: Sebuah URL resolver 60 baris yang berjalan selama pembuatan outline, mengikuti redirect Vertex AI ke sumber sebenarnya, dan menyimpan kedua URL (asli untuk kepatuhan ToS Google, resolved untuk semua hal lainnya).
def resolve_grounding_url(url: str) -> str:
if "grounding-api-redirect" not in url:
return url
response = requests.head(url, allow_redirects=True, timeout=5)
return response.url if response.url != url else url
Setelah: 23 dari 23 fakta riset di episode baru hari ini memiliki resolved_url terisi — URL nyata seperti simonwillison.net, axios.com, thinkingmachines.ai. Resolusi 100%.
Perbaikan 2: Mengganti Model Review (Gemini → DeepSeek)
Sebelum: Gemini 3.5 Flash menjalankan pass review. Ia membuat editan ringan dan konservatif: mengubah "Exactly!" menjadi "No question about it!" tapi sebagian besar mempertahankan teks asli. Ia menambahkan filler yang mendatarkan dialog. Kepadatan tag audio menurun. Rasio type-token menurun. Jumlah giliran membengkak.
Perbaikan: Mengganti pass review ke DeepSeek v4-pro (384K output maks, dibatasi 96K). Membuat provider dapat dikonfigurasi:
provider = get_provider("review") # reads REVIEW_PROVIDER env var
response = provider.generate(
prompt=prompt, temperature=0.0,
max_output_tokens=96000,
)
Verifikasi: Deploy ke production. Sebuah episode berita teknologi Vietnam berjalan melalui pipeline penuh dengan review DeepSeek — 10,3K → 11,6K token, selesai dalam 121 detik, 0 pass pengetatan diperlukan. Episode kedua (bahasa Inggris) memproses 7,9K → 17K token dalam 203 detik. Kunci API DeepSeek disimpan di Google Cloud Secret Manager, diinjeksi otomatis saat deploy melalui service.yaml.
Perbaikan 3: Kritik Mandiri Outline (Peningkatan +0,50)
Sebelum: Outline langsung dari Gemini ke pengguna tanpa pemeriksaan kualitas internal. Skor rata-rata: 3,01.
Perbaikan: Menambahkan langkah kritik otomatis. DeepSeek v4-pro mengevaluasi outline terhadap rubrik 6 dimensi (5 dimensi outline plus jumlah segmen), mengembalikan skor + umpan balik spesifik, dan menyimpan kritik di metadata podcast.
Lalu saya menjalankan eksperimen terkontrol: ambil 6 episode yang outlinenya mendapat skor di bawah 3,0, jalankan kritik DeepSeek, berikan umpan balik ke Gemini sebagai instruksi regenerasi, dan skor ulang.
Setelah: Peningkatan keseluruhan +0,50 di 6 episode.
| Dimension | Before | After | Delta |
|---|---|---|---|
| Content Boundaries | 3.33 | 4.17 | +0.83 |
| Research Depth | 2.67 | 3.17 | +0.50 |
| Citation Credibility | 1.00 | 1.50 | +0.50 |
| Structural Logic | 3.67 | 4.17 | +0.50 |
| Audience Fit | 2.17 | 2.33 | +0.17 |
Episode terburuk naik dari 1,80 ke 3,20 (+1,40). Hanya 1 dari 6 yang memburuk. Kritik sekarang diaktifkan secara default di production — setiap outline baru mendapat pemeriksaan kualitas ini sebelum pengguna melihatnya.
Perbaikan 4: Outline Satu Segmen Sekarang Gagal Keras
Sebelum: Evaluasi menunjukkan episode dengan segmen tunggal dan nol fakta riset mendapat skor serendah 2,07. Ini adalah kasus kegagalan yang tidak diperlakukan pipeline sebagai kegagalan.
Perbaikan: Jika generator outline menghasilkan kurang dari 3 segmen valid setelah upaya pemulihan, podcast ditandai FAILED. Tidak ada lagi outline satu segmen yang sampai ke pengguna. Pada upaya pembuatan berikutnya, kredit pengguna dibebaskan untuk mencoba ulang.
Perbaikan 5: Aturan Lokalisasi Bahasa Mandarin
Sebelum: Episode bahasa Mandarin mendapat skor 2,88 — yang terendah di antara 7 bahasa. Artefak terjemahan (idiom bahasa Inggris diterjemahkan harfiah), pembuka segmen identik, nama host default bahasa Inggris (Alex/Maya) alih-alih nama Mandarin (明辉/晓雯).
Perbaikan: Menulis aturan dialog spesifik Mandarin: pola percakapan asli (konstruksi 不是...而是...), partikel akhir kalimat yang tepat (吧/啊/呢), pedoman anti-terjemahan (jangan pernah menerjemahkan "medical miracle" secara harfiah), metafora sepak bola Mandarin untuk episode Piala Dunia, dan profil host spesifik locale dengan kepribadian yang berbeda.
Template dialog Mandarin berubah dari menggunakan ulang default bahasa Inggris menjadi memiliki panduan 80 barisnya sendiri yang mencakup pola percakapan, frasa ketidaksetujuan, dan pembingkaian spesifik audiens untuk setiap gaya podcast.
Perbaikan 6: Nama Host Default untuk Non-Bahasa Inggris
Sebelum: Beberapa episode non-Inggris memiliki host bernama Alex dan Maya. Profil host spesifik locale sudah ada tetapi jalur fallback di generator outline di-hardcode ke default bahasa Inggris.
Perbaikan: Melacak perbaikan melalui pipeline resolusi profil yang sadar locale. Episode produksi terbaru sekarang menggunakan 翔太/健一 (ja), Mạnh/Nga (vi), Hugo/Camille (fr), 明辉/晓雯 (zh). Commit Juli sudah memperbaiki edge function dan alur pembuatan — fallback yang tersisa ada di generator outline itu sendiri.
Framework Evaluasi (Dapat Digunakan Kembali)
Framework yang menemukan semua ini sekitar ~500 baris Python, tiga file rubrik (masing-masing 5 dimensi), judge GPT-5.6-terra bersama, dan sebuah orkestrator:
docs/pipeline/evals/
├── run.py # Orchestrator: extract → judge → report
├── judge.py # Shared LLM judge (rate with rubric)
├── rubric_outline.py # Stage 1: 5 dimensions, 1-5 scale
├── rubric_dialogue.py # Stage 2: 5 dimensions, 1-5 scale
├── rubric_final_script.py # Stage 3: 5 dimensions, 1-5 scale
├── dataset_40.json # Extracted production data
├── scores.json # Machine-readable scores
└── report.md # Auto-generated report
Saya juga membangun lapisan eksperimen untuk perbandingan A/B:
docs/pipeline/evals/experiments/
├── review_ab.py # Compare two review models
├── outline_critique_ab.py # Critique → regenerate → compare
├── shared.py # Score comparator, report generator
└── results/ # Archived by date
Jalankan python docs/pipeline/evals/run.py --full setelah setiap perubahan pipeline dan dapatkan laporan dalam ~8 menit. Jalankan experiments/review_ab.py --episodes 10 untuk membandingkan model. Hasil diarsipkan berdasarkan tanggal untuk pelacakan tren — ingin tahu apakah kualitas membaik bulan ini vs bulan lalu? Diff skornya.
Evaluasi 40 episode penuh memakan biaya sekitar $1-2 dalam panggilan API. Eksperimen lebih murah lagi. Untuk sinyal yang Anda dapatkan kembali — daftar berperingkat tentang tahap dan dimensi pipeline mana yang perlu perhatian — ini adalah alat debugging termurah yang pernah saya bangun.
Yang Masih Rusak
Eksperimen A/B review DeepSeek perlu prompt produksi penuh. Skrip eksperimen menggunakan prompt sederhana 15 baris. Review produksi menggunakan prompt 80 baris dengan aturan anti-pengulangan, kuota frasa khas, pagar editorial, dan kebijakan durasi. Dengan prompt sederhana, DeepSeek menunjukkan hasil yang pada dasarnya netral (-0,04). Dengan prompt penuh di production, pipeline berhasil menyelesaikan dalam bahasa Inggris dan Vietnam. Saya perlu memperbarui eksperimen untuk mencerminkan production dan menjalankan ulang.
Lokalisasi bahasa Mandarin perlu validasi. Aturannya terlihat benar di atas kertas, profil host sudah ditulis, panduan dialog sudah ada. Tapi saya belum menjalankan evaluasi pada episode Mandarin baru untuk mengonfirmasi skornya naik dari 2,88. Itu prioritas minggu ini.
Saya perlu menjalankan ulang evaluasi 40 episode penuh pada episode baru. Keenam perbaikan sudah di-deploy. Langkah berikutnya adalah mengekstrak 40 episode yang dihasilkan setelah perubahan ini, menjalankannya melalui evaluasi yang sama, dan membandingkan dengan baseline historis. Jika skor skrip final naik dari 2,91 ke atas 3,0, dan kredibilitas kutipan naik dari 1,28 ke sesuatu yang masuk akal, saya tahu perubahan itu berhasil dari ujung ke ujung.
Audit Pipeline Tiga Pertanyaan
Setelah pengalaman ini, saya sekarang mengaudit setiap perubahan pipeline dengan tiga pertanyaan:
1. Apakah ada quality gate di antara setiap langkah? Outline saya langsung dari Gemini ke pengguna. Menambahkan langkah kritik menangkap outline terburuk sebelum ada yang melihatnya. Setiap langkah pipeline perlu pemeriksaan kualitas — evaluasi LLM otomatis terhadap kriteria eksplisit.
2. Apakah setiap langkah benar-benar meningkatkan kualitas saat diukur? Menjalankannya dan berasumsi itu membantu tidaklah cukup. Anda perlu skor sebelum/sesudah literal pada konten yang sama. Langkah review saya menurunkan skrip selama enam minggu sebelum saya mengukurnya. Ukur dulu, jangan berasumsi apa pun.
3. Bisakah saya tahu dimensi mana yang rusak? "Kualitas buruk" tidak dapat ditindaklanjuti. "Kredibilitas kutipan 1,28 karena 100% URL adalah redirect buram" bisa ditindaklanjuti. Rubrik multi-dimensi per tahap memberi tahu Anda persis ke mana harus melihat. Saya menghabiskan berjam-jam menyelidiki langkah review saya sebelum evaluasi. Dengan evaluasi, saya menghabiskan hitungan detik — angkanya langsung menunjuk ke publishability dan model review.
Pertanyaan yang Sering Diajukan
Bukankah menjalankan evaluasi LLM jadi mahal?
Evaluasi 40 episode penuh memakan biaya sekitar $1-2 dalam panggilan API (GPT-5.6-terra, ~420K total token). Eksperimen A/B lebih murah lagi. Untuk sinyal yang Anda dapatkan — daftar berperingkat tentang tahap pipeline mana yang perlu perhatian — ini alat debugging termurah yang saya bangun, dan lebih murah daripada kredit yang akan terbuang oleh pengguna pada episode yang rusak.
Kenapa 5 dimensi per tahap? Kenapa tidak "kualitas keseluruhan" saja?
"Kualitas keseluruhan" memberi tahu Anda ada yang salah. Tidak memberi tahu apa. Ketika saya melihat Kredibilitas Kutipan di 1,28, saya langsung tahu URL-nya rusak. Ketika saya melihat Publishability di 1,95, saya tahu ciri-ciri AI terdeteksi. Lima dimensi memberi Anda diagnosis diferensial. Satu dimensi memberi Anda termometer demam.
Bagaimana Anda menjaga judge LLM tetap konsisten?
Model yang sama (GPT-5.6-terra), suhu yang sama (0,0), upaya penalaran yang sama (medium), prompt rubrik yang sama setiap kali. Skor diarsipkan dengan stempel waktu sehingga Anda bisa membandingkan antar tanggal. Mengganti judge mengubah baseline — pilih satu dan tetap gunakan.
Apa yang terjadi ketika judgenya sendiri salah?
Rubrik mencakup justifikasi wajib untuk setiap skor — judge harus mengutip bukti spesifik dari konten. Saya juga melakukan tinjauan kualitatif manual terhadap 10 episode di semua 7 bahasa untuk mengkalibrasi judge. Skor LLM cocok dengan penilaian manusia saya. Untuk dimensi kritis di mana LLM mungkin tidak dapat diandalkan (seperti "publishability," yang memerlukan penilaian kultural), pemeriksaan sampel manusia sangat penting.
Saya membangun DIALOGUE, sebuah platform podcast AI, sendirian, di malam dan akhir pekan saya. Saya menulis tentang apa yang saya pelajari sepanjang perjalanan.
Jika Anda telah membangun sistem evaluasi untuk pipeline LLM Anda sendiri, saya penasaran: bagaimana Anda mengukur kualitas, dan apa yang Anda temukan yang mengejutkan Anda?
Sekian dari saya.
Salam hangat, Chandler