Membangun mesin pencari web dari nol dengan 300 juta embedding neural hanya dalam 2 bulan

 (blog.wilsonl.in)
1 poin oleh GN⁺ 2025-08-13 | Belum ada komentar. | Bagikan ke WhatsApp
  • Dengan latar penurunan kualitas mesin pencari dan kemajuan model embedding berbasis Transformer, penulis membahas pengalaman mengembangkan mesin pencari web berbasis 300 juta embedding selama 2 bulan
  • Dengan total 200 klaster GPU, crawler terdistribusi skala besar, RocksDB, HNSW, dan infrastruktur serta algoritme berkinerja tinggi lainnya, sistem ini mewujudkan pencarian pemahaman bahasa alami secara real-time
  • Dengan tujuan tanya jawab berbasis niat alih-alih pencocokan kata kunci, berbagai teknik NLP/ML seperti normalisasi, chunking, dan pengaitan kalimat diterapkan untuk parsing dokumen dan pelestarian konteks
  • Diperkenalkan pula desain sistem terdistribusi skala besar serta cara mengoptimalkan bottleneck/biaya di tiap lapisan seperti pipeline, storage, service mesh, dan vector index
  • Pada akhirnya dijelaskan lahirnya mesin pencari personal yang berlatensi sangat rendah, terdistribusi besar, dan berakurasi tinggi

Gambaran umum dan motivasi

  • Penulis memutuskan membangun mesin pencari dari nol setelah melihat masalah penurunan kualitas mesin pencari, spam SEO, meningkatnya konten yang tidak relevan, serta meningkatnya kemampuan pemahaman bahasa alami dari model embedding berbasis Transformer
  • Keterbatasan mesin pencari yang ada berasal dari kurangnya kemampuan memahami pertanyaan setingkat manusia dan pencocokan sederhana berbasis kata kunci
  • Tujuannya adalah membuat konten berkualitas selalu tampil di posisi atas, sambil menerapkan ranking berbasis niat yang juga menelusuri hasil-hasil panjang di bagian ekor secara merata
  • Proses membangun mesin pencari web mencakup berbagai bidang seperti ilmu komputer, linguistik, ontologi, NLP, ML, sistem terdistribusi, dan rekayasa performa
  • Proyek ini merupakan tantangan untuk memulai sendiri sepenuhnya tanpa infrastruktur maupun pengalaman sebelumnya selama 2 bulan, lalu mewujudkan mesin pencari yang benar-benar baru

Susunan sistem secara keseluruhan

  • Menghasilkan 300 juta embedding teks berbasis SBERT di 200 klaster GPU
  • Ratusan crawler paralel mengumpulkan 50.000 halaman per detik dan membangun total 280 juta indeks
  • RocksDB dan HNSW disimpan serta diindeks dengan sharding pada 200 core CPU, 4TB RAM, dan 82TB SSD
  • Total latensi respons kueri ditetapkan di kisaran 500ms
  • Struktur dan alur keseluruhan dipisahkan menjadi crawler, pipeline, storage, indeks vektor embedding, service mesh, serta area front-end/back-end

Eksperimen dan peningkatan pencarian berbasis embedding

Neural Embedding Playground

  • Melalui eksperimen, pencarian dengan model embedding seperti SBERT terbukti memiliki pemahaman kueri yang lebih alami dan akurasi lebih tinggi dibanding pencarian tradisional berbasis kata kunci
  • Sistem mampu memahami niat kueri masukan pada level konteks dan kalimat, lalu mengekstrak jawaban yang benar-benar relevan

Contoh pencarian tradisional vs. pencarian neural

  • Pencarian tradisional: hasil cenderung acak, berfokus pada kecocokan kata kunci
  • Pencarian embedding: memahami konteks dan niat pertanyaan, lalu memberikan hasil yang berpusat pada kalimat inti atau konsep yang tepat
  • Untuk gabungan konsep yang kompleks, pertanyaan implisit/majemuk, dan kueri yang memuat sinyal kualitas, sistem dapat menemukan jawaban berbasis makna

Parsing dan normalisasi halaman web

  • Tujuan normalisasi adalah mengekstrak hanya elemen teks yang bermakna dari HTML sambil menghapus noise seperti elemen layout dan kontrol

  • Mengikuti standar seperti WHATWG dan MDN, struktur tabel untuk p, table, pre, blockquote, ul, ol, dl, dan lainnya dipertahankan

  • Elemen chrome seperti menu, navigasi, komentar, dan antarmuka dihapus sepenuhnya

  • Aturan khusus per situs (misalnya en.wikipedia.org) diterapkan untuk mengatasi masalah ekstraksi yang berlebihan atau kurang

  • Data terstruktur berbasis makna (meta, OpenGraph, schema.org, dan lain-lain) juga dapat dimanfaatkan untuk membangun graf pengetahuan dan meningkatkan ranking

Chunking dan pelestarian konteks

Chunking tingkat kalimat

  • Untuk mengatasi keterbatasan model embedding, digunakan chunking berbasis kalimat alih-alih seluruh halaman
  • Saat melakukan chunking, berbagai kasus seperti batas kalimat alami, tata bahasa, singkatan, URL, dan ekspresi informal dibedakan secara akurat menggunakan spaCy sentencizer

Pelestarian dan pengaitan konteks

  • Hubungan antarkalimat, heading, paragraf, tabel, dan sebagainya dipahami lalu dibundel bersama informasi konteksnya saat dibuat embedding
  • Misalnya, struktur tabel juga dimasukkan dengan mengaitkan heading/klausul tingkat atas secara berantai agar makna tiap baris tidak hilang

Rantai pernyataan (Statement Chaining)

  • Dengan classifier DistilBERT, satu kalimat dan kalimat sebelumnya dianalisis bersama untuk mengotomatisasi pemeriksaan ketergantungan konteks dan ekstraksi rantai
  • Saat embedding dibuat, semua kalimat dependen tingkat atas ikut disertakan untuk meningkatkan kemampuan mempertahankan konteks

Hasil penggunaan prototipe

  • Melalui berbagai eksperimen kueri dunia nyata di lingkungan sandbox, terbukti sistem mampu memberikan tanya jawab yang jauh lebih akurat (sesuai konteks) dibanding metode sebelumnya
  • Bahkan ketika ada ketidakcocokan kata kunci, elipsis/metafora/pertanyaan majemuk, aplikasi tetap mengenali niat dan mencocokkan kalimat konteks yang benar—serta efektif menggali pengetahuan dan relasi tersembunyi

Crawler web skala besar (berbasis node)

  • Berbagai aspek stabilitas dan efisiensi diperhitungkan, seperti work stealing untuk distribusi pekerjaan, kontrol konkurensi/lalu lintas per domain, serta validasi DNS/URL/header
  • Crawler menerapkan Promise berbasis asynchronous I/O, mekanisme yang tangguh terhadap DDoS, manajemen sumber daya (memori, delay, backoff), dan deteksi domain noise
  • Normalisasi URL, pembatasan protokol serta port/informasi pengguna, dan canonicalization digunakan untuk memperkuat filter URL duplikat/tidak normal

Pipeline (distributed task queue)

  • Status setiap halaman dikelola di PostgreSQL, dan pada tahap awal polling/transaksi digunakan secara langsung
  • Dalam lingkungan terdistribusi besar (ribuan crawler), muncul masalah skalabilitas dan bottleneck antrean/lock → status queue lalu dikelola dengan koordinator in-memory berbasis Rust
  • Struktur task mencakup indeks berbasis hash map, binary heap, grup domain, random poll, swap_remove, dan berbagai bentuk pengindeksan lainnya
  • Memori per task sekitar 100B, sehingga 1 miliar task pun bisa ditangani di server 128GB
  • Setelah itu, dikembangkan queue open source berbasis RocksDB sebagai pengganti SQS, dengan dukungan 300 ribu ops/detik pada 1 node

Desain storage (Oracle → PostgreSQL → RocksDB)

  • Awalnya digunakan Oracle Cloud (egress/storage berbiaya rendah), lalu PostgreSQL (TOAST), tetapi akhirnya menemui batas skalabilitas tulis/performa
  • Karena karakteristik PostgreSQL seperti MVCC, write amplification, dan WAL, bottleneck muncul pada INSERT paralel skala besar, sehingga akhirnya beralih ke RocksDB sebagai KV store
  • Dengan penyimpanan blob terpisah (BlobDB), file SST, multi-threading, dan hash indexing, RocksDB memanfaatkan performa maksimum NVMe SSD
  • Sistem diskalakan ke 64 shard RocksDB—setiap shard dirutekan berdasarkan xxHash(key) dan menggunakan serialisasi Serde+MessagePack
  • Pada akhirnya, ribuan klien (crawler/parser/vectorizer) mampu memproses 200 ribu ops/detik, dengan metadata dan blob dipisah serta disimpan dalam bentuk terkompresi

Service mesh dan jaringan

  • Saat infrastruktur diperluas, desain berbasis mTLS+HTTP2 dipilih untuk penemuan instance layanan otomatis dan keamanan komunikasi
  • Setiap node menerapkan sertifikat berbasis root CA, memakai serialisasi MessagePack secara langsung, serta mengembangkan DNS internal, CoreDNS, dan client SDK kustom
  • Penulis punya pengalaman menggunakan VPN yang sudah ada (ZeroTier, Tailscale), tetapi memilih HTTP+mTLS buatan sendiri karena masalah jaringan, performa, dan operasional
  • Kontrol layanan sistem (systemd + cgroup + journald) digunakan untuk menyatukan pengelolaan, sekaligus mewujudkan sistem yang lebih ringan dan terstandar

Pipeline pembuatan embedding GPU skala besar

  • Awalnya memanfaatkan OpenAI API, lalu berpindah ke lingkungan GPU berkinerja tinggi seperti Runpod karena masalah biaya
  • Pipeline memisahkan tiap stage secara asynchronous, mencapai efisiensi GPU di atas 90%, dan pada 250 GPU menghasilkan 100 ribu embeddings per detik
  • Pipeline Rust, inferensi Python → IPC melalui named pipe, serta backpressure terstruktur digunakan untuk penyetelan sumber daya otomatis

Pengindeksan vektor (HNSW/sharding)

  • Menggunakan algoritme HNSW untuk pencarian vektor berbasis memori, dengan ANN (Approximate Nearest Neighbor) untuk latensi sangat rendah
  • Saat batas RAM tercapai, diterapkan sharding merata per node (64 node), dan tiap shard dicari secara paralel sebagai indeks HNSW terpisah
  • Karena karakteristik HNSW memerlukan RAM besar dan memiliki keterbatasan pembaruan langsung, sistem akhirnya berpindah ke vector DB open source berbasis disk bernama CoreNN
  • CoreNN dapat melakukan kueri akurat terhadap 3 miliar embedding bahkan pada satu node dengan 128GB RAM

UX mesin pencari dan optimasi latensi

  • Dalam UX mesin pencari, kuncinya adalah respons instan (tanpa loading indicator, SSR tradisional)
  • Dengan Cloudflare Argo dan sejenisnya, sistem didekatkan ke edge PoP, dan HTTP/3 diadopsi untuk meminimalkan latensi transmisi
  • Semua data disiapkan di tingkat app server, round-trip API individual diminimalkan, dan halaman yang telah diminify serta dikompresi dikirimkan segera

Ringkasan ini menjelaskan secara konkret bagaimana mesin pencari web skala besar yang menerapkan teknologi NLP·ML modern dapat dibangun end-to-end hanya dalam 2 bulan, sekaligus memandu keputusan desain dan optimasi utama di seluruh sistem, algoritme, dan infrastruktur.

Bacaan terkait

Belum ada komentar.

Belum ada komentar.