Artificial Intelligence

Mengapa Mocking Database Vektor di CI Berbahaya dan Solusi 200ms

Ringkasan

  • Tim pengembang aplikasi RAG di pipeline CI kerap gagal saat produksi karena praktik mocking database vektor menutupi kesalahan semantik, padahal solusi server 200ms sudah hadir.

Membangun aplikasi berbasis Retrieval-Augmented Generation (RAG) kini terbilang mudah. Namun, transisi dari prototipe di Jupyter Notebook menuju pipeline CI/CD tingkat produksi kerap menjadi batu sandungan bagi para insinyur perangkat lunak. Salah satu titik rawan ada pada pengujian pencarian vektor yang membebani server jika tidak dikelola dengan arsitektur yang tepat.

Kendala ini muncul saat tim mencoba menjalankan pytest untuk aplikasi yang bergantung pada ChromaDB atau Qdrant di dalam runner GitHub Actions. Praktik umum yang sering ditempuh justru berujung pada dua jebakan fatal yang mengorbankan kualitas atau efisiensi sistem.

Jebakan pertama adalah ilusi mocking. Banyak tim memutuskan untuk memalsukan klien database menggunakan unittest.mock. Pengujian hanya memastikan bahwa fungsi collection.query() dipanggil dengan parameter yang benar. Padahal, inti dari pipeline RAG adalah pencarian semantik, ambang batas cosine similarity, dimensi embedding, serta pengambilan chunk teks. Tanpa menguji mekanisme asli, tim seolah terbang dalam kegelapan dan baru menyadari metrik jarak mereka salah saat aplikasi sudah rilis.

Di sisi lain, terdapat jebakan kedua berupa penggunaan Testcontainers untuk memutar instance ChromaDB asli di dalam workflow CI. Pendekatan Docker-in-Docker (DinD) ini terbukti sangat lambat ketika dijalankan di runner GitHub yang hanya menyediakan memori 7GB. Mengunduh image database vektor berukuran gigabita dan menyalakan daemon memakan memori masif. Akibatnya, pipeline yang biasanya rampung dalam 45 detik bisa melorot menjadi 10 menit, atau malah berhenti tiba-tiba akibat error OOMKilled.

Akar masalah dari kedua jebakan tersebut bukanlah database itu sendiri, melainkan lokasi eksekusinya. Selama ini, runner CI dipaksa untuk merangkap sebagai penyedia infrastruktur. Padahal, arsitektur pengujian yang ideal mengharuskan pemisahan antara komputasi dan penyimpanan state.

Bagi ekosistem teknologi di Indonesia, isu ini sangat relevan mengingat maraknya startup lokal dan talenta AI yang sedang giat membangun produk berbasis large language model (LLM). Komunitas developer Tanah Air sering kali mengandalkan layanan CI gratisan dengan resource terbatas. Ketergantungan pada mocking yang salah sasaran berisiko meloloskan bug pada sistem rekomendasi atau chatbot perusahaan, sementara penggunaan Testcontainers bisa membuat biaya komputasi cloud membengkak.

Pemisahan komputasi dari state menjadi kunci strategis. Runner CI seharusnya hanya bertugas mengeksekusi kode pengujian, sedangkan database berada di server jarak jauh yang terisolasi, menyala instan, dan dimusnahkan seketika setelah tes selesai. Pendekatan ini menjamin tidak ada tabrakan data saat menjalankan banyak tugas secara paralel.

Sayangnya, infrastruktur semacam ini belum banyak tersedia sebagai layanan turnkey di regional Asia Tenggara. Developer Indonesia kerap harus merakit sendiri skrip bash teardown yang kompleks atau berlangganan instance cloud berbiaya mahal hanya untuk keperluan testing sesaat. Ketiadaan solusi lokal yang setara membuat ketergantungan pada tool global menjadi tidak terhindarkan.

Sebagai respons atas kebutuhan tersebut, seorang pengembang merilis TrashDB, sebuah API orkestrasi yang dibangun menggunakan .NET 10 di atas bare-metal server. Alat ini dirancang spesifik untuk memutar database dalam 200 milidetik dan langsung mematikanannya. "Kita harus berhenti memaksa runner CI kita untuk menjadi penyedia infrastruktur," demikian prinsip di balik peluncuran SDK Python native agar bisa diintegrasikan langsung ke dalam pytest fixtures tanpa skrip penghancuran manual.

Melalui fitur seperti pengaturan time-to-live (TTL) lima menit untuk kontainer ChromaDB, TrashDB menawarkan cara baru menghindari penumpukan resource. Pengguna cukup memanggil client.create_container dengan parameter engine dan TTL, lalu membiarkan sistem membersihkan server secara otomatis.

Ke depan, tren isolasi database efemeral akan menjadi standar wajib dalam pengujian aplikasi AI tingkat produksi. Solusi berbasis API orkestrasi seperti ini berpotensi menggeser dominasi Testcontainers yang membebani mesin lokal. Developer di Indonesia perlu mulai mengadopsi pola pikir pemisahan infrastruktur ini agar pipeline RAG mereka tetap gesit dan andal.

TrashDB sendiri saat ini berada dalam tahap Alpha gratis dan terus dikembangkan secara terbuka. Kehadirannya membuka peluang bagi komunitas lokal untuk bereksperimen dengan pengujian semantik otentik tanpa takut menghabiskan kuota memori CI, sekaligus mendorong lahirnya inovasi serupa dari penyedia cloud domestik.

Mengapa Ini Penting

Ketiadaan layanan orkestrasi database efemeral di Indonesia memaksa startup lokal menghadapi dilema antara stabilitas pengujian dan efisiensi biaya komputasi cloud. Jika tren isolasi infrastruktur ini tidak diadopsi, ekosistem AI domestik berisiko tertinggal dalam hal kecepatan iterasi produk berbasis LLM. Di samping itu, ketergantungan pada tool asing seperti TrashDB dapat menjadi celah keamanan data jika pengujian melibatkan dokumen sensitif perusahaan. Masa depan pengujian CI/CD di Tanah Air membutuhkan kolaborasi antara komunitas open-source dan penyedia cloud lokal untuk menghadirkan solusi serupa yang terjamin privasinya.

Sumber Asli
Dev.to
Tanggal
14 Juli 2026
Waktu Baca
4 menit