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

• 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.

[GN⁺]

Komentar Hacker News

• Cukup mengejutkan bahwa model embedding terbaru OpenAI menawarkan biaya sangat rendah untuk inferensi batch, yaitu $0.0001 per 1 juta token; saya menyadari bahwa bahkan jika 1 miliar halaman masing-masing di-embedding dengan 1.000 token, totalnya hanya sekitar $100. Jika menjalankan inferensi sendiri dengan GPU spot Runpod, biayanya bisa 100 kali lebih mahal. Biaya API lain di luar itu. Saya jadi bertanya-tanya apakah ini semacam strategi honeypot OpenAI untuk memperoleh data sumber yang terspesialisasi per domain.

  • Sepengetahuan saya, OpenAI umumnya tidak melatih ulang menggunakan sebagian besar data yang diproses lewat API, kecuali dalam kasus khusus tertentu.

• Di akhir tulisan disebutkan rencana untuk menambahkan data Common Crawl. Saya rasa informasi peringkat berbasis web graph dari tim kami bisa sangat membantu dalam menentukan halaman mana yang perlu di-crawl. Menarik melihat contoh berskala besar seperti ini secara langsung, dan saya terkejut bahwa database vektor ternyata cukup efisien dari sisi biaya.

• Saya benar-benar kagum. Tulisan ini juga tersusun sangat baik. Saya setuju bahwa inti search engine adalah data yang sudah dibersihkan dan difilter dengan baik (garbage in, garbage out). Ini kembali menegaskan bahwa dalam pelatihan LLM pun, sejumlah kecil data berkualitas tinggi pada akhirnya lebih penting. Saya jadi penasaran seperti apa performanya jika semua konten ditinjau oleh LLM untuk membangun search engine.

  • Saat ini saya mengelola sendiri SEO situs web bisnis kecil milik teman. Saya sudah memperbaikinya secara teknis dan juga menulis cukup banyak konten manual yang disesuaikan dengan lokalitas. Setelah 2 bulan, Bing bahkan belum mengambil favicon-nya, dan Google juga butuh 1 bulan. Sampai sekarang, yang muncul di atas masih situs pengumpul lead skala nasional yang sama sekali tidak relevan, spam blog Yelp, dan halaman bisnis lain yang tidak ada hubungannya dengan wilayah setempat. Jelas terlihat ada sesuatu yang tidak berjalan semestinya pada sistem pagerank dan crawling.

• Saya sangat respek. Menggabungkan begitu banyak teknologi hingga semuanya bekerja sebagai satu kesatuan adalah hal yang luar biasa. Menurut saya, nilai penentu dari search engine ada pada algoritme ranking yang sesungguhnya. Saya kurang paham bagaimana LLM digunakan untuk ranking di proyek ini. Salah satu teknik ranking lama adalah mengumpulkan data pencarian hingga klik dari pengguna nyata. Itu pada dasarnya adalah data latih manusia berupa kueri pencarian → tautan yang diklik. Hanya dengan beberapa klik saja, ranking bisa meningkat cukup jelas. Jika data ini dimasukkan ke neural network, masalahnya bisa diubah menjadi masalah klasifikasi untuk meningkatkan ranking. Semakin banyak orang mengklik, semakin besar bobotnya.

• Saya benar-benar hanya bisa bilang ini luar biasa. Nyatanya sistem ini berjalan cukup baik. Jika biaya bisa ditutup dengan 10.000 orang berlangganan $5 per bulan, maka search engine yang didukung komunitas tampaknya bukan ide yang mustahil.

  • Bagi orang yang paham encoder-only LLM, sudah jelas bahwa Google pada dasarnya sudah selesai. Google masih bertahan hanya karena butuh waktu lama untuk merayapi seluruh web dunia dan menjaga indeksnya tetap mutakhir. Jika organisasi terbuka seperti Common Crawl atau layanan berbayar memecahkan masalah crawling web secara real-time, maka benteng pertahanan Google selama 25 tahun akan runtuh dan search akan menjadi semakin setara.

  • Lebih jauh lagi, kita sedang menyaksikan penggantian secara real-time untuk setiap fungsi di big tech, dan lewat model, hambatan teknis perusahaan kini juga jauh menurun.

• Bahwa satu orang bisa membuat sampai sejauh ini adalah sesuatu yang tak pernah saya bayangkan sebelumnya. Rasanya hasilnya tidak terlalu jauh dari search engine komersial, bahkan mungkin sudah cukup dekat untuk menyaingi Google. Fakta bahwa ini bisa dilakukan hanya dengan $50 ribu per tahun terasa sangat murah sampai saya ingin langsung mengirim seed money.

• Proyek yang sangat keren. Saya mencoba di sini pertanyaan yang biasanya tidak dijawab dengan baik oleh search engine terkenal, yaitu opsi rekomendasi monitor ultrawide resolusi tinggi, tetapi di sini pun masih ada kecenderungan halaman meta besar yang hanya ahli soal ranking muncul lebih dulu daripada halaman dengan informasi yang benar-benar mendalam. Obsesi terhadap ranking terlihat terlalu kuat. Kalau saya sendiri yang mencari jawabannya, saya akan memilih beberapa forum hardware dan blog lalu membandingkan spesifikasi serta kelebihan-kekurangannya dengan teliti. Karena sulit memverifikasi apakah sebuah situs benar-benar melakukan analisis seperti itu, dalam kasus khusus seperti ini rasanya lebih masuk akal untuk memberi nilai lebih tinggi pada situs yang mengutip data konkret. Sebagai pengguna, saya ingin melihat sumber asli yang dipakai dalam analisis. Namun search engine nyata biasanya tidak mengangkat dasar sumber seperti itu dari bawah ke atas.

  • Mungkin ini sejak awal bukan masalah search query sama sekali. Ini bukan satu halaman dengan “jawaban pasti” yang sudah ada, melainkan pertanyaan yang membutuhkan kombinasi beberapa sumber dan ‘penalaran’.

• Saya rasa ini sangat keren. Saya sempat berpikir untuk mengganti semuanya dengan ini. Mungkin akan sedikit membuang waktu, tapi saya tetap ingin mencoba banyak pencarian dan meninggalkan kesan saya. Secara umum hasilnya memang mengarahkan ke tempat yang hampir benar, meski belum 100%. Misalnya, ketika saya mencoba mencari fediverse lewat lemmy, hasilnya justru halaman liberapay. Saya harap janji integrasi Common Crawl benar-benar dipenuhi dan juga mempertimbangkan situs lain seperti archive.org. Miliaran dolar mengalir ke industri AI, jadi saya sungguh berharap eksperimen seperti ini bisa berhasil lewat pendanaan komunitas atau pembagian kerja. Sejujurnya banyak orang sudah lelah dengan kondisi search engine saat ini yang nyaris monopolistik. Setahu saya Ecosia juga sedang menyiapkan search engine mereka sendiri, jadi saya berharap mereka bisa berkolaborasi dengan proyek ini atau setidaknya belajar darinya. Saya benar-benar menginginkan search engine yang terdesentralisasi. Saya paham masih ada keraguan untuk open source karena alasan keberlanjutan. Tapi frustrasi sekali melihat begitu banyak uang dibuang tanpa makna, sementara proyek ini punya potensi yang sangat besar, jadi saya sangat berharap ini bisa di-open-source-kan. Saya percaya komunitas pada akhirnya bisa menemukan cara keberlanjutan, misalnya lewat crowdfunding. Saya bahkan belum selesai membaca seluruh postingan, tetapi sudah terlalu antusias sampai langsung mencobanya duluan. Tulisannya sendiri sangat mendalam dan saya rasa pendekatan seperti ini bisa menjadi referensi yang sangat berguna bagi orang lain juga. Jujur saja ini terasa seperti sihir, dan sudah lama saya tidak merasakan antusiasme dari awal sampai akhir terhadap sebuah proyek seperti ini. Saya paham open source itu sulit, dan saya juga tahu latar belakang negara ketiga yang disebutkan, tapi saya sungguh rela menyumbang bahkan hanya $50 dari uang saya sendiri. Saya yang hampir tidak pernah melakukan pembayaran online pun sampai merasa ingin mendukung sejauh ini. Jadi saya benar-benar berharap proyek ini memanfaatkan Common Crawl dan berkembang bersama komunitas. Saya tulus mendukung proyek ini dan juga karier pembuatnya.

• Ini salah satu tulisan paling berwawasan yang saya baca belakangan ini. Saya sangat suka karena penulis menjelaskan secara rinci elemen-elemen yang dipilih untuk menekan biaya dan titik penghematan yang benar-benar berdampak. Meski fokusnya pada neural search, saya penasaran apakah pernah mencoba hybrid search yang menggabungkan BM-25 + embedding. Saya juga ingin tahu model reranking mana yang paling berguna dan efisien.

• Ini pengalaman yang sangat menarik. Saya juga sedang membangun sesuatu yang mirip untuk pencarian bisnis, dan menghadapi banyak tantangan serupa. Banyak orang mengira crawling/pemrosesan/indexing itu mudah, tetapi melakukannya secara hemat biaya dalam skala besar adalah masalah yang sama sekali berbeda. Salut untuk wilsonzlin. Saya ingin sekali berbincang soal ini; sangat sedikit orang yang benar-benar membangun hal seperti ini secara e2e.