Ketika sebuah perusahaan atau tim pengembang pertama kali membangun asisten kecerdasan buatan (AI), hasilnya sering kali tampak luar biasa. Model bahasa besar (Large Language Models atau LLM) seperti GPT-5, Claude, atau Gemini mampu menjawab pertanyaan dengan anggun, terdengar percaya diri, serta memberikan rekomendasi yang masuk akal. Namun, situasi berubah drastis ketika sistem tersebut benar-benar diluncurkan ke hadapan pengguna nyata di lingkungan produksi.
Dalam minggu pertama peluncuran, masalah mulai bermunculan: asisten AI dengan percaya diri menyebutkan fitur produk yang sebenarnya sudah didepresiasi delapan bulan lalu, biaya API per permintaan melonjak hingga tiga kali lipat dari proyeksi karena model dipanggil terus-menerus untuk tugas yang tidak memerlukan kecerdasan buatan, dan jawaban yang diberikan tidak konsisten untuk pertanyaan serupa dari pelanggan yang berbeda.
Menariknya, akar masalah dari kegagalan ini bukanlah karena model AI-nya yang kurang canggih. Model frontier saat ini sudah sangat mumpuni. Masalah utamanya terletak pada kesalahan arsitektur (architectural failure), di mana pengembang meminta satu komponen tunggal (LLM) untuk melakukan segalanya sekaligus: bernalar, mengingat, memvalidasi, memutuskan, dan merespons. Pendekatan inilah yang disebut sebagai arsitektur LLM-centric.
Memahami Jebakan Arsitektur LLM-Centric
Pendekatan LLM-centric mengandalkan model bahasa sebagai pusat dari seluruh sistem. Segala bentuk masukan pengguna (user input) dilemparkan langsung ke dalam model dalam satu langkah besar, berharap model dapat menyelesaikan seluruh alur kerja.
Meskipun terlihat praktis pada tahap purwarupa (prototype), pendekatan ini memiliki batasan yang sangat rapuh ketika dihadapkan pada data nyata, kendala bisnis, dan risiko operasional. Berikut adalah alasan utama mengapa sistem yang berpusat pada LLM sering kali runtuh di tingkat produksi:
1. Masalah Memori (The Memory Problem)
Model bahasa besar secara inheren tidak memiliki memori permanen di antara pemanggilan API (API calls). Setiap permintaan baru diperlakukan sebagai lembar kosong (blank slate). Meskipun dalam satu sesi percakapan riwayat teks disertakan dalam prompt, model tidak tahu apa yang ia katakan kepada pelanggan lima menit lalu, atau apakah pengguna tersebut sudah menghubungi dukungan tiga kali dalam minggu ini. Memaksa model mengingat segalanya melalui penumpukan konteks membuat biaya melonjak dan konsistensi hancur.
2. Masalah Halusinasi Kontekstual
Halusinasi bukan sekadar istilah acak. Dalam sistem produksi, kegagalan ini dapat berupa intrinsic hallucination (model bertentangan dengan konteks dokumen), extrinsic hallucination (informasi tidak terverifikasi), outdated knowledge (pengetahuan usang akibat batas pelatihan), hingga sycophantic hallucination (model mengiyakan koreksi keliru dari pengguna). Bentuk paling berbahaya adalah ketika model mengarang jawaban secara percaya diri mengenai kebijakan internal produk atau riwayat akun pelanggan karena tidak adanya lapisan retrieval yang terhubung ke data tepercaya.
3. Ketidakkonsistenan Penalaran (Reasoning Inconsistency)
Model bahasa adalah sistem probabilistik, bukan mesin penalaran deterministik. Pertanyaan serupa dengan sedikit perbedaan redaksi dari dua pelanggan yang berbeda dapat menghasilkan keputusan penanganan yang berbeda pula (misalnya, satu pelanggan diabaiakn, sementara yang lain dieskalasi). Mengandalkan aturan bisnis yang disimpan di dalam prompt alih-alih kode program menciptakan ketidakpastian yang tidak boleh ada dalam operasional bisnis.
Tantangan Operasional: Biaya, Latensi, dan Kegagalan Senyap
Selain masalah kognitif di atas, sistem LLM-centric juga memicu tantangan operasional yang berat ketika volume trafik meningkat:
- Struktur Biaya yang Tidak Viabel: Sebagian besar penyedia AI mengenakan biaya per token (masukan dan keluaran). Jika setiap permintaan memicu pemanggilan model berulang kali untuk tugas deterministik sederhana (seperti validasi kolom atau pengecekan status akun), biaya infrastruktur akan membengkak secara eksponensial.
- Latensi Pengguna: Pemanggilan model membutuhkan waktu antara 1 hingga 10 detik. Rangkaian pemanggilan model secara berurutan (sequential calls) membuat waktu tunggu menumpuk, menjadikan antarmuka terasa lambat dan rusak.
- Kegagalan Senyap (Silent Failures): Perangkat lunak tradisional biasanya gagal secara berisik (fail loudly) dengan memunculkan stack trace atau eksepsi. Sebaliknya, sistem berbasis LLM sering kali gagal secara senyap (fail silently)—model menghasilkan jawaban salah, tidak lengkap, tetapi melaporkan status sukses tanpa ada eksepsi yang tercatat.
Solusi: Beralih ke Arsitektur Modular
Perbedaan mendasar antara tim yang terus-menerus melakukan debugging prompt dan tim yang sukses menjalankan sistem AI di produksi terletak pada pemahaman mengenai di mana kecerdasan seharusnya berada.
Alih-alih menyerahkan segalanya kepada model, arsitektur modular memisahkan tugas secara tegas:
- Tugas Bahasa: Diserahkan kepada model (seperti memahami bahasa alami, ekstraksi maksud, klasifikasi teks, dan perumusan draf respons yang empatik).
- Tugas Logika dan Status: Dijalankan oleh kode deterministik berbasis bahasa pemrograman seperti Python (seperti pemeriksaan status akun, penegakan aturan bisnis, perutean antrean, dan manajemen status sesi).
Dengan memisahkan lapisan bahasa dari lapisan operasional, sistem menjadi lebih terukur, hemat biaya, dapat diuji (testable), serta memiliki jejak audit (audit trail) yang jelas untuk setiap keputusan yang diambil.
Kesimpulan
Pendekatan LLM-centric sangat menarik untuk tahap demonstrasi karena kecepatannya dalam membangun purwarupa. Namun, mengandalkan satu model untuk merangkap seluruh fungsi sistem akan berujung pada kerentanan biaya, halusinasi kebijakan, dan ketidakpastian aturan bisnis. Masa depan rekayasa AI di tingkat produksi bukan tentang mencari model yang lebih besar untuk menyelesaikan segalanya, melainkan tentang merancang sistem modular yang menempatkan model LLM pada fungsi aslinya yang paling optimal: sebagai lapisan pemahaman bahasa di atas fondasi kode yang kokoh.
