Case Study

Studi Kasus Atmo: Kurangi Waktu Onboarding Modul 47 Persen Pakai Vector Database 2026

Vito Atmo
Vito Atmo·23 Mei 2026·0 kali dibaca·4 min baca
Studi Kasus Atmo: Kurangi Waktu Onboarding Modul 47 Persen Pakai Vector Database 2026

TL;DR: Atmo, platform LMS in-house Vito Atmo, mengimplementasikan pgvector di Supabase untuk membangun "cari modul mirip" berbasis semantik. Hasilnya: waktu rata-rata user menemukan modul relevan turun 47 persen dalam 60 hari, dengan biaya infrastruktur tambahan di bawah 200 ribu per bulan.

Awal 2026, kami mengamati pola yang konsisten di Atmo: user sering bolak-balik membuka 5-7 modul sebelum menemukan yang relevan dengan kebutuhan mereka. Pencarian keyword bawaan tidak cukup karena istilah marketing Indonesia banyak yang tumpang tindih ("funnel" vs "alur konversi" vs "tahapan pelanggan"). Solusinya bukan menambah filter, melainkan mengubah cara mesin memahami kueri.

Tulisan ini merangkum proses, angka aktual, dan pelajaran dari implementasi vector database di Atmo selama 60 hari.

Konteks Awal

Atmo punya sekitar 80 modul mini berbahasa Indonesia tentang marketing dan pengembangan web. Setiap modul punya judul, ringkasan 200 kata, dan 3-5 tag manual. Pencarian sebelumnya pakai full-text search PostgreSQL biasa. Metrik yang kami tracking:

  • Waktu rata-rata dari buka platform sampai mulai modul: 4,2 menit
  • Jumlah modul yang dibuka sebelum memilih: 5,3 modul
  • Bounce rate di halaman cari: 38 persen

Target setelah implementasi: turunkan ketiga metrik minimal 20 persen.

Pilihan Stack

Kami memilih pgvector karena tiga alasan praktis. Pertama, Atmo sudah pakai Supabase untuk auth dan database utama, jadi tidak perlu vendor tambahan. Kedua, pgvector cukup performa untuk skala 80-500 modul. Ketiga, biaya nol karena sudah include di paket Supabase Pro yang kami pakai.

KomponenPilihanAlasan
Vector DBpgvector di SupabaseSatu stack, gratis
Embedding modelOpenAI text-embedding-3-smallMurah, kualitas cukup untuk Bahasa Indonesia
ChunkingPer modul (judul + ringkasan)Skala kecil, tidak perlu chunking halus
Dimensi1.536Default text-embedding-3-small

Implementasi 4 Minggu

Minggu 1: Setup pgvector extension, buat tabel module_embeddings dengan kolom id, module_id, embedding vector(1536), created_at. Tulis script Python untuk generate embedding semua 80 modul. Total biaya generasi awal: 7 ribu rupiah (sekitar 250 ribu token via OpenAI).

Minggu 2: Bangun endpoint cari semantik di Next.js API route. Query user diubah jadi embedding, lalu cari 10 modul dengan jarak kosinus terdekat. Pakai indeks IVFFlat untuk performa.

Minggu 3: A/B testing di 30 persen user. Bandingkan pencarian keyword lama vs pencarian semantik baru di tab terpisah.

Minggu 4: Roll out 100 persen, monitoring metrik, dokumentasi internal.

Hasil Setelah 60 Hari

  • Waktu rata-rata buka sampai mulai modul: 4,2 menit jadi 2,2 menit (turun 47 persen)
  • Jumlah modul dibuka sebelum memilih: 5,3 jadi 2,8 (turun 47 persen)
  • Bounce rate halaman cari: 38 persen jadi 22 persen (turun 42 persen)
  • Biaya infrastruktur tambahan: 180 ribu per bulan (embedding ulang saat modul baru + storage)

Catatan: sample size hanya 1.200 user aktif bulanan. Hasil mungkin berbeda untuk platform dengan skala lebih besar atau konten lebih kompleks. Angka ini berlaku untuk konteks LMS niche dengan modul berbahasa Indonesia.

Pelajaran Penting

1. Embedding Model Mempengaruhi Bahasa Indonesia

Kami sempat coba model open-source gratis (sentence-transformers all-MiniLM), tapi kualitasnya kurang untuk Bahasa Indonesia. OpenAI text-embedding-3-small jauh lebih baik karena dilatih di korpus multilingual yang lebih besar. Lihat dokumentasi embedding OpenAI untuk benchmark.

2. Re-Embedding Saat Modul Berubah

Setiap kali isi modul diupdate substantif, embedding harus regenerasi. Kami pakai trigger Postgres yang antri ulang ke worker setiap 2 jam. Tanpa ini, hasil cari bisa stale dalam hitungan minggu.

3. Pencarian Hybrid Lebih Kuat

Solusi optimal kami pakai 70 persen vector + 30 persen keyword. Murni vector kadang melewatkan match eksak (nama tool, brand). Hybrid search seperti dijelaskan di panduan Weaviate menutup celah ini.

Pertanyaan Umum

Apakah harus pakai pgvector atau Pinecone?

Untuk skala di bawah 1 juta vektor dan stack PostgreSQL/Supabase, pgvector cukup dan lebih murah. Untuk skala produksi besar dengan latency ketat, layanan managed seperti Pinecone atau Weaviate Cloud lebih siap.

Berapa biaya embedding untuk 1.000 artikel?

Pakai text-embedding-3-small, sekitar 30-50 ribu rupiah sekali generasi untuk 1.000 artikel medium-length. Biaya kueri jauh lebih kecil karena hanya embedding kueri user (puluhan token per kueri).

Apakah ini relevan untuk personal brand atau hanya untuk platform besar?

Relevan untuk siapa pun yang punya konten >50 artikel dan ingin pengalaman cari yang lebih relevan. Untuk personal brand dengan 10-20 artikel, manfaatnya belum sebanding effort. Mulai pertimbangkan saat konten Anda menembus 50+ pieces.

Yang Akan Kami Coba Berikutnya

Eksperimen berikutnya adalah menambah personalisasi: re-rank hasil pencarian berdasarkan modul yang sudah dibuka user. Ini akan menggeser logika dari "modul mirip kueri" jadi "modul mirip kueri DAN sesuai progress user". Akan kami publikasikan hasilnya di studi kasus lanjutan dalam 90 hari.

Bagikan

Artikel Terkait

#vector-database#atmo#pgvector#supabase#semantic-search

Butuh website yang benar-benar bekerja?

Hubungi Vito untuk konsultasi gratis 15 menit.

WhatsApp Sekarang