Praktik terbaik integrasi AI di dunia nyata untuk menjalankannya tanpa pemborosan biaya

• Untuk menjalankan LLM dan platform AI secara stabil di lingkungan produksi, diperlukan pendekatan desain yang berpusat pada arsitektur yang mampu beradaptasi terhadap perubahan
• Untuk mengantisipasi perubahan model dan API, pisahkan semua panggilan AI menjadi layanan terpisah dan terapkan pola migrasi berbasis eksekusi ganda
• Dengan memanfaatkan Flex service tier dari OpenAI, biaya dapat dipangkas 50% dengan kualitas model dan data yang sama
• Letakkan data yang berulang di bagian awal prompt untuk memaksimalkan efisiensi penggunaan cache token, sehingga hanya membayar 10% dari biaya token biasa
• Untuk mencegah lonjakan biaya berlebihan, Rate Limiting dan Circuit Breaker wajib dibangun di backend

---

Strategi integrasi AI yang siap menghadapi perubahan

• Model dan API AI terus berubah, dan cara yang saat ini bekerja bisa gagal kapan saja
• Daripada terus mengejar alat atau model tertentu, yang terpenting adalah merancang sistem yang bisa beradaptasi terhadap perubahan
• Tujuan penggunaan AI bukan sekadar mengikuti teknologi terbaru, melainkan operasi yang stabil dan kontrol biaya

Pola migrasi (The Migration Pattern)

• Ekstrak semua panggilan API AI menjadi layanan terpisah yang menangani koneksi, penyusunan prompt, dan prompt tertentu secara internal
• Layanan-layanan ini dioperasikan dalam kondisi permanent migratability sehingga selalu bisa menggunakan versi dan model terbaru maupun versi lama yang sebelumnya dipakai
• Ada pengalaman masalah saat bermigrasi dari GPT 4.1 ke GPT-5
  • Prompt yang dibuat sempurna untuk GPT 4.1 mengalami penurunan keandalan di GPT-5, misalnya ada JSON key yang hilang
  • GPT-5 cenderung menggunakan structured JSON schemas alih-alih format JSON sederhana
  • Perlu menjelaskan cara mendefinisikan key dan nilai yang mungkin, lalu mengisinya di dalam prompt
• Implementasi strategi migrasi
  • Untuk periode tertentu atau di lingkungan test/staging, jalankan secara bersamaan prompt dan model lama serta prompt dan model baru
  • Bahkan struktur data dan panggilan API yang sepenuhnya berbeda pun dimungkinkan (OpenAI merekomendasikan peralihan dari chat-style API ke response-style API)
  • Catat hasil dari kedua sisi, lalu jika ada perbedaan penting sistem akan memberi tahu dan menampilkan diff
  • Server eksekusi ganda memang menimbulkan biaya 2x, tetapi memungkinkan pemahaman atas dampak perbedaan model lama dan baru serta perbedaan prompt terhadap kualitas, prediktabilitas, dan keandalan
• Sangat berguna terutama untuk analisis latar belakang, pemrosesan data, dan analisis semantik yang bukan percakapan murni
• Jika hasil baru tidak memenuhi harapan, kapan saja bisa rollback ke versi legacy
• Karena sistem API pada akhirnya akan deprecated, kesiapan migrasi adalah keharusan
• Melihat diff pada data JSON membantu saat menyusun ulang prompt
  • Claude Code atau OpenAI Codex dapat digunakan untuk menyesuaikan prompt sampai kedua hasil menjadi serupa
• Pola ini berlaku untuk semua layanan yang berkomunikasi dengan model ML eksternal
• Jika layanan baru tiba-tiba menunjukkan penurunan performa, cukup alihkan switch ke versi lama agar kembali memperoleh data yang andal seperti sebelumnya

Rahasia service tier (The Service Tier Secret)

• Layanan cloud menyediakan service tier dengan harga berbeda tergantung tingkat pentingnya panggilan API
• Untuk OpenAI
  • default tier: harga yang ditampilkan di situs web
  • batched requests: jauh lebih murah, tetapi tidak cocok untuk pekerjaan semi-sinkron karena tidak jelas kapan batch akan terisi dan diproses
  • Flex tier: setengah harga dari default tier
    • Bisa 50% lebih lambat dan pada waktu tertentu mungkin tidak tersedia, tetapi memberikan model dan kualitas data yang sama
• Contoh penggunaan Flex tier
  • Diterapkan pada pekerjaan backend seperti ekstraksi tamu, analisis isi ucapan, dan peringkasan
  • Dengan fitur auto-retries di OpenAI SDK, logika tambahan tidak diperlukan
  • Implementasikan fallback saat terjadi error 429: coba beberapa kali dengan Flex, lalu jika gagal beralih ke standard tier dan coba lagi
• Hasil penerapan skala besar
  • Berhasil mencapai penghematan biaya 50% secara langsung karena Flex tier tersedia hampir sepanjang waktu
  • Saat input token besar dan output token kecil (transkrip podcast dalam jumlah besar → data ringkasan JSON yang sedikit), cache token juga setengah harga
  • Beban kerja ekstraksi dan inferensi dapat ditingkatkan 2x, yang berujung pada kualitas platform yang lebih baik dan kenaikan conversion rate
• Hal yang perlu diperiksa per platform
  • Harga Batch sama dengan biaya pemrosesan Flex
  • Harga Flex tersedia untuk model GPT-5, 5.1, o3, dan o4
  • Codex, Pro, GPT-4o, alat audio real-time, dan lainnya mungkin tidak mudah mendapatkan harga Flex
• Jika service tier semacam ini tersedia tetapi tidak digunakan, itu adalah financial negligence
• Jika tetap membutuhkan hasil cepat saat trafik padat, bisa mengatur Priority tier (harga 2x, hasil lebih cepat)
  • Priority juga mungkin tidak tersedia untuk model tertentu
• Karena model dan pola pemakaian sangat beragam, implementasi dan optimasi perlu fleksibel

Front-loading untuk efisiensi cache (Front-Loading for Cache Efficiency)

• Saat ada banyak data untuk dianalisis, letakkan bagian yang berulang di depan
• Taruh system prompt di depan, dan jika data yang sama akan dianalisis berkali-kali, mulailah prompt dengan data tersebut
• Urutan prompt
  1. System prompt (penjelasan peran)
  2. Instruksi sistem yang selalu sama ("ekstrak data dalam format ini")
  3. Data yang bisa berulang di antara beberapa prompt
  4. Instruksi khusus untuk masing-masing prompt
• Data yang ditempatkan di depan akan diproses sebagai cache token, sehingga hanya membayar 10% dari biaya token lainnya
• Contoh penerapan nyata
  • Masukkan seluruh transkrip lebih dulu, lalu tambahkan instruksi tugas spesifik di akhir transkrip (mencari tamu tertentu, mencari sponsor, menangani pertanyaan pelanggan, dll.)
• Verifikasi optimasi beberapa prompt
  • Masukkan prompt-prompt tersebut sebagai data ke dalam percakapan Claude Code atau ChatGPT, lalu minta analisis optimasi
  • Jangan menerima hasil AI mentah-mentah; gunakan sebagai referensi saja (AI hanyalah prediksi token, dan hanya karena AI mengatakan sesuatu lebih berguna bukan berarti itu benar)
  • Dengan menganalisis beberapa prompt sekaligus, Anda bisa memperoleh insight yang bermakna

Rate Limiting dan Circuit Breakers

• Saat menggunakan platform eksternal yang menimbulkan biaya berbasis token, Rate Limiting adalah keharusan
• Target penerapan Rate Limit
  • Aksi yang berhadapan langsung dengan pelanggan dan memicu interaksi AI
  • Interaksi AI yang bisa dikirim dari server backend
• Perlu mencegah situasi ketika race condition membuat proses yang sama terus restart dan memicu panggilan yang sama berulang kali (meski memakai cache token tetap menimbulkan biaya)
• Deteksi gejala anomali
  • Jika penggunaan token AI pada jam tertentu mencapai 10x dari normal, harus ada fungsi notifikasi dan penghentian
• Implementasi Circuit Breaker
  • Circuit breaker menyeluruh untuk semua fitur AI di aplikasi atau untuk bagian tertentu saja
  • Feature toggle yang bisa diaktifkan/dinonaktifkan dari perintah Laravel atau antarmuka admin
  • Bahkan fitur self-onboarding seperti tombol "buat pengaturan keren" juga harus bisa dinyalakan/dimatikan
  • Jika seseorang mengotomatisasi fitur dan menimbulkan biaya ratusan dolar per jam, segera blokir lewat toggle
• Feature toggle harus diimplementasikan di backend, bukan frontend agar kontrol terjadi di titik nyata saat kejadian
• Pemanfaatan AI scan
  • Gunakan alat agentic coding untuk memindai kode dan menemukan titik yang berpotensi menyalahgunakan panggilan AI serta lokasi untuk menambahkan feature toggle
• Semua penggunaan AI wajib melewati sistem backend
  • Jangan biarkan client side langsung memanggil platform AI memakai token (itu memang praktik yang buruk)
  • Hanya lewat backend Anda bisa menyalakan/mematikan fitur dan menerima notifikasi penggunaan tinggi
• Lapisan keamanan yang diterapkan
  • Rate limits di semua fitur
  • Rate limits untuk pengguna frontend
  • Rate limits backend
  • Feature toggle
  • Notifikasi penyalahgunaan fitur (per akun, per tipe pelanggan, per IP)
• Ke depan, hal ini mungkin akan menjadi fitur bawaan di tool dan framework, tetapi saat ini masih perlu diimplementasikan sendiri

Pelajaran utama: bangun sistem yang siap menghadapi perubahan

• Lingkungan AI terus berubah (model, API, harga), sehingga mustahil mengejar semuanya
• Inti dari operasi AI bukan model terbaru, melainkan merancang sistem yang mampu beradaptasi ketika perubahan terjadi
• Komponen wajib:
  • Pola migrasi
  • Optimasi service tier
  • Prompt caching
  • Rate limiting
  • Circuit breakers
• Ini bukan sekadar nice-to-have, melainkan fondasi untuk mencegah kerugian saat menjalankan AI di produksi
• Begitu AI digunakan di produksi, biaya dan stabilitas bukan lagi sekadar masalah teknis, melainkan masalah arsitektur

"Build for Change" bangun fondasi untuk menghadapi perubahan