Layanan:

Pencarian Produk yang Paham Maksud Pembeli: Semantic Search Laravel dengan MariaDB Vector

Pencarian Produk yang Paham Maksud Pembeli: Semantic Search Laravel dengan MariaDB Vector

Pencarian kata kunci sering gagal saat pembeli mengetik kebutuhan, bukan SKU. Contohnya perlengkapan hangat untuk trekking musim dingin tanpa nama produk spesifik. Semantic search Laravel mengubah teks produk dan query menjadi embedding vektor, lalu mencari tetangga terdekat dalam ruang makna. Tim Bagisto mempublikasikan uji coba pada katalog 25.000 produk dengan MariaDB Vector tanpa database vektor terpisah.

Artikel ini menekankan studi Bagisto/MariaDB.org, batas benchmark, dan perbedaan onsite search versus SEO Google. Untuk sudut Laravel 13 generik, lihat artikel terkait di situs ini tentang MariaDB Vector tanpa DB kedua.

Fakta uji Bagisto (guest post MariaDB.org)

Pencarian Produk yang Paham Maksud Pembeli

  • Stack: MariaDB 11.8.9, Bagisto 2.4.10, Laravel 12.62, PHP 8.3, 25.000 produk generated, vektor 1536 dimensi, cosine distance.
  • Indexing ~2,5 menit (~171 dokumen/detik); median query ~27 ms default, ~10 ms setelah cache HNSW di-tune.
  • Container DB dibatasi 4 CPU / 2 GB RAM; binary log off; hardware Intel i5-8400, SSD.
  • Embedding dibuat di layer aplikasi/model, bukan “AI bawaan” MariaDB.
  • Hasil spesifik setup; bukan SLA production universal.

Semantic Search Laravel: Dari Keyword ke Embedding

Pipeline konseptual dimulai dari teks produk. Model embedding menulis vektor ke kolom VECTOR plus indeks HNSW di MariaDB. Query pengguna melalui embedding di layer aplikasi, lalu nearest-neighbor, ranking, dan filter bisnis (stok, kategori, harga).

MariaDB Vector (GA di 11.8 LTS menurut proyek MariaDB Vector) menyimpan dan mencari vektor native. Arsitektur ini bisa jalan tanpa Pinecone/Qdrant terpisah. Namun dedicated vector DB tetap relevan pada skala atau fitur tertentu.

Detail implementasi dan angka benchmark ada di guest post tim Bagisto di MariaDB.org. Sumber ini berasal dari tim produk yang menjalankan uji; baca sebagai evidence scoped, bukan benchmark netral pihak ketiga.

Konfigurasi Default vs Tuned

Setup default uji memakai innodb_buffer_pool_size 128 MB, mhnsw_max_cache_size 16 MB, mhnsw_ef_search 20, mhnsw_default_m 6.

Setelah tuning (buffer pool 1 GB, cache HNSW 512 MB, dan penyesuaian parameter pencarian), latensi median turun dan recall membaik. Pada dataset uji, HNSW M=16 menurut laporan Bagisto meningkatkan recall@10 dari ~59% ke ~94,5% tanpa penalti latensi yang disebutkan.

Jadi pelajaran operasionalnya jelas: konfigurasi DB materiil mengubah latency dan recall. Jangan salin angka QPS (~1.900 dengan 8 klien concurrent pada mesin uji) sebagai jaminan di VPS production dengan traffic campuran dan filter metadata.

Filter Metadata dan Pencarian Hybrid

Toko nyata jarang pure vector similarity. Sumber Bagisto mengeksplor filter (warna, kategori) bersama vector search. Filtered query cenderung lebih lambat dan trade-off recall/latency muncul.

Virtual column dan pre-filter exact search tercatat sebagai eksperimen indexing JSON metadata. Meski begitu, ini onsite product discovery, bukan ranking Google Search.

Vector search tidak menggantikan SEO on-page. Manfaat tidak langsung mungkin lewat UX dan conversion bila analytics mendukung.

Memahami intent pembeli di SERP tetap topic terpisah; baca search intent Google dan SERP. Kemudian untuk konteks stack PHP, MariaDB Vector Laravel 13 melengkapi sudut framework tanpa fokus katalog Bagisto.

Kapan Native MariaDB Cukup dan Kapan Evaluasi Lain

Native vector di MariaDB menarik bila aplikasi sudah MariaDB, katalog moderat, tim ingin sedikit komponen, dan filter relasional plus vektor tinggal satu engine.

Evaluasi sistem vector terpisah bila skala embedding sangat besar, kebutuhan distributed ANN, isolasi multi-tenant ketat, atau fitur cloud vendor jadi syarat.

Embedding model, biaya inferensi, refresh indeks saat katalog berubah, dan monitoring drift kualitas pencarian tetap tanggung jawab tim aplikasi. MariaDB tidak menggantikan strategi merchandising atau sinonym manual sepenuhnya.

Toko custom di Laravel/WooCommerce perlu desain search dari ukuran katalog, pola query, SLA latency, dan kemampuan ops DB. Implementasi multibahasa menambah kompleksitas tokenisasi dan embedding locale.

Tuning HNSW dan Pipeline Indeks Laravel

Indeks HNSW di MariaDB Vector memiliki parameter seperti M (konektivitas graf) dan ef_search (usaha pencarian) yang memengaruhi recall versus latency.

Studi Bagisto menunjukkan tuning M dan ukuran cache HNSW dapat mengubah recall@10 drastis pada dataset uji. Angka tersebut tidak otomatis jadi nilai magic untuk katalog Anda.

Pipeline operasional: batch job Laravel (queue) menghasilkan embedding saat produk baru atau deskripsi berubah. Tim menulis ke kolom VECTOR(1536) (dimensi mengikuti model embedding yang dipilih), lalu rebuild atau update indeks sesuai dokumentasi MariaDB 11.8.

Model embedding (OpenAI, open source lokal, dll.) menambah biaya compute dan kebutuhan GPU/CPU terpisah dari lisensi database.

Hybrid search sering lebih robust: keyword BM25 untuk SKU exact match plus vector untuk query conversational, dengan reranking di aplikasi. Tetap pertahankan keyword search bila pelanggan masih mengetik kode produk pendek.

Monitor di production: distribusi latency P95, zero-result rate, click-through dari hasil search, dan drift kualitas saat katalog musiman berubah. Benchmark guest post tidak menggantikan observability toko live.

Untuk merchant Bagisto, integrasi semantic search memanfaatkan stack PHP/Laravel yang sudah familiar. Sebelum fitur vector di production, rencanakan upgrade DB ke MariaDB 11.8 LTS, backup, dan regression test checkout bila migrasi dari MySQL lama.

Akhirnya, anggap semantic layer sebagai modul discovery di atas katalog yang tetap butuh faceted navigation klasik.

Artikel Terkait

Artikel & Informasi Seputar Bisnis & Website

→
baca semua artikel

Copyright © 2026 CodeF Web Developer. All rights reserved colaborated with Pajuda.com