Cara Kami Memilih AI yang Tepat untuk Tiap Fungsi
Ketika merancang fitur berbasis kecerdasan buatan, pertanyaan "model mana yang kupakai" tampak seperti harus dijawab sekali saja, di awal. Dalam praktik NovLore ternyata tidak begitu: seiring waktu kami sadar bahwa tugas-tugas berbeda dari produk punya kebutuhan yang begitu berbeda satu sama lain sehingga satu penyedia saja, sebagus apa pun, tak bisa melayani semuanya dengan baik. Artikel ini menceritakan kenapa, dan bagaimana sistem yang lahir darinya bekerja hari ini.
Masalah yang mendorong pilihan ini
Awalnya Scintilla — asisten menulis NovLore — menggabungkan dua tugas berbeda dalam satu jalur: percakapan dengan pengguna dan generasi cruscotto karya (tokoh, tempat, plot) dari percakapan itu. Keduanya tampak terkait, tapi punya kebutuhan yang berlawanan: percakapan butuh merespons cepat, sementara menghasilkan data terstruktur yang koheren butuh waktu untuk berpikir. Satu penyedia saja, yang dioptimalkan untuk salah satu kebutuhan, secara sistematis merugikan yang lain.
Solusinya bukan mencari penyedia yang bagus di kedua hal itu sekaligus. Solusinya adalah berhenti memperlakukan keduanya sebagai tugas yang sama.
Enam ranah, bukan satu
Hari ini setiap fungsi AI NovLore mendeklarasikan ranahnya sendiri — koreksi, penulisan ulang, chat, struktur, bab, transkripsi — dan setiap ranah bisa punya penyedia berbeda sebagai pilihan pertama. Chat Scintilla, misalnya, memakai model yang dipilih karena kecepatan responsnya; generasi satu bab penuh, yang dijalankan pengguna dengan sadar harus menunggu, justru memakai model yang dipilih karena kualitas prosa pada tugas panjang.
| Ranah | Melakukan apa | Yang paling penting |
|---|---|---|
| Chat | percakapan dengan asisten | kecepatan respons |
| Koreksi | typo dan konsistensi tata bahasa | presisi, biaya rendah |
| Penulisan ulang | mengubah teks yang dipilih | kualitas gaya |
| Struktur | data terstruktur tentang tokoh/plot | keandalan format |
| Bab | generasi satu bab penuh | kualitas pada teks panjang |
| Transkripsi | sudah disiapkan, belum aktif | — |
Tak satu pun dari pilihan ini final: panel admin memungkinkan mengganti penyedia dan cadangan untuk setiap ranah tanpa menyentuh kode, karena biaya dan kualitas relatif model berubah seiring waktu jauh lebih cepat dari perubahan perangkat lunak.
Kenapa tujuh penyedia, bukan satu yang "cukup bagus"
Dengan satu penyedia saja, setiap gangguan layanannya — dan itu terjadi pada semua orang, bahkan yang terbaik sekalipun — jadi gangguan bagi seluruh produk. Solusi paling umum adalah punya cadangan; yang kurang jelas, tapi lebih kokoh, adalah bahwa cadangan tak boleh lewat jalur yang sama dengan pilihan pertama. Kalau pilihan pertama dan cadangan adalah dua rute berbeda menuju penyedia yang sama di belakangnya, ketidaktersediaan penyedia itu akan menjatuhkan keduanya sekaligus.
Karena itu, ketika pilihan pertama untuk sebuah ranah adalah agregator yang memberi akses ke banyak model dengan satu kunci saja, cadangannya sengaja diarahkan ke penyedia langsung yang independen. Ini redundansi sungguhan, bukan cuma di atas kertas.
Apa yang dilihat pengguna saat cadangan aktif
Tak ada apa-apa, kalau sistem bekerja sebagaimana mestinya. Kalau penyedia pilihan pertama untuk sebuah ranah tak merespons, perpindahan ke cadangan berlangsung transparan: permintaan tetap berhasil, dan hanya satu data teknis internal yang mencatat bahwa yang merespons adalah pilihan kedua. Pada streaming — respons yang muncul kata demi kata, seperti pada chat — cadangan hanya bisa aktif sebelum potongan teks pertama tiba: begitu respons dimulai, mengganti penyedia di tengah jalan akan menghasilkan teks yang dijahit dari dua gaya berbeda, lebih buruk daripada menunggu beberapa detik lebih lama.
Transparansi cadangan bukan detail teknis untuk penggemar infrastruktur: ini beda antara pengguna yang menyadari perlambatan sesekali dan pengguna yang melihat error saat sedang menulis novelnya.
Router sebagai satu-satunya titik lintas
Agar sistem ini bertahan seiring waktu, setiap fungsi AI produk — termasuk yang berupa output terstruktur dan yang berupa streaming — lewat satu router internal tunggal, tak pernah langsung ke penyedia. Ini pilihan yang menuntut disiplin (tak ada jalan pintas, bahkan untuk fungsi "sementara") tapi terbayar dengan cara yang tepat: ketika sebuah penyedia mengubah syaratnya, atau ada penyedia baru yang layak ditambahkan, perubahan dilakukan di satu tempat saja, bukan di sepuluh endpoint berbeda yang ditulis di waktu berbeda.
Pertanyaan yang Sering Diajukan
Kenapa tidak selalu pakai model paling kuat yang tersedia?
Karena "paling kuat" bukan hal yang sama dengan "paling cocok untuk tugasnya". Model yang unggul pada teks panjang dan kreatif bisa lambat dan mahal untuk chat yang harus merespons dalam satu detik; memakainya di mana-mana akan membuat bagian produk yang seharusnya instan terasa lambat juga.
Bisakah pengguna memilih AI mana yang dipakai?
Tidak langsung per pesan: pilihannya per ranah dan dikelola oleh yang mengurus produk, berdasarkan kualitas dan keandalan yang diamati seiring waktu. Ini pilihan yang disengaja — menyerahkannya ke pengguna akan memindahkan keputusan teknis yang butuh pemantauan terus-menerus terhadap tujuh penyedia berbeda ke pundak mereka.
Apa yang terjadi kalau cadangan juga tak merespons?
Operasi gagal dengan error eksplisit, dan untuk aksi berbayar kredit, pembebanan dibatalkan otomatis dari lot yang sama tempat ia diambil: pengguna tak membayar untuk permintaan yang tak mendapat respons.
Apakah sistem ini memperlambat pengembangan fitur AI baru?
Dalam jangka pendek ya, sedikit: menambah fungsi butuh lewat router alih-alih memanggil API langsung. Dalam jangka menengah justru sebaliknya, karena setiap fungsi baru mewarisi gratis penanganan error, cadangan, dan pelacakan biaya yang sudah dibangun sekali untuk semuanya.