Sıfırdan 2 Ayda 300 Milyon Nöral Gömme ile Bir Web Arama Motoru Kurmak

• Arama motoru kalitesindeki düşüş ve Transformer tabanlı gömme modellerindeki ilerlemelerden hareketle, 2 ay boyunca 300 milyon gömme tabanlı bir web arama motoru geliştirme deneyimi ele alınıyor
• Toplam 200 GPU kümesi, büyük ölçekli dağıtık crawler, RocksDB, HNSW gibi yüksek performanslı altyapı ve algoritmalarla gerçek zamanlı doğal dil anlayışlı arama hayata geçiriliyor
• Anahtar kelime eşleşmesi yerine niyet odaklı soru-cevap hedeflenerek, belge ayrıştırma ve bağlam koruma için normalizasyon, chunking, ifade zincirleme gibi çeşitli NLP/ML teknikleri uygulanıyor
• Pipeline, depolama, service mesh, vektör indeksi gibi her katmanda büyük ölçekli dağıtık sistem tasarımı ile darboğaz ve maliyet optimizasyonu yöntemleri tanıtılıyor
• Sonuçta ultra düşük gecikmeli, büyük ölçekli dağıtık, yüksek doğruluklu kişiselleştirilmiş bir arama motorunun ortaya çıktığı anlatılıyor

---

Genel Bakış ve Motivasyon

• Yazar, son dönemde arama motoru kalitesindeki düşüş, SEO spam'i ve alakasız içeriklerin artmasıyla ilgili farkındalığı ve Transformer tabanlı gömme modellerinin doğal dili anlama kapasitesinin yükseldiği ortamı birleştirerek bir arama motorunu sıfırdan kurmaya karar veriyor
• Mevcut arama motorlarının sınırları, insan seviyesinde soru anlama yeteneğinin eksikliği ve anahtar kelime tabanlı basit eşleştirmeden kaynaklanıyor
• Amaç, kaliteli içeriğin her zaman üst sıralarda görünmesini sağlamak ve uzun kuyrukta kalan sonuçları da dengeli biçimde keşfeden niyet odaklı sıralama kurmak
• Web arama motoru inşa etme süreci; bilgisayar bilimi, dilbilim, ontoloji, NLP, ML, dağıtık sistemler ve performans mühendisliği gibi pek çok alanı kapsıyor
• Bu proje, 2 ay boyunca altyapı ya da önceden edinilmiş deneyim olmadan tamamen tek başına başlayıp tamamen yeni bir arama motoru gerçekleştirme meydan okuması olarak sunuluyor

Genel Sistem Yapısı

• 200 GPU kümesinde SBERT tabanlı 300 milyon metin gömmesi üretiliyor
• Aynı anda çalışan yüzlerce crawler saniyede 50.000 sayfa topluyor ve toplam 280 milyon indeks oluşturuyor
• RocksDB ve HNSW, 200 çekirdek, 4 TB RAM ve 82 TB SSD üzerinde sharding ile depolanıp indeksleniyor
• Sorgu yanıtı için toplam gecikme yaklaşık 500 ms seviyesinde hedefleniyor
• Genel yapı ve akış; crawler, pipeline, depolama, gömme vektör indeksi, service mesh ve front-end/back-end alanlarına ayrılıyor

Gömme Tabanlı Arama Deneyleri ve İyileştirmeler

Neural Embedding Playground

• SBERT gibi gömme modelleriyle yapılan aramanın, geleneksel anahtar kelime odaklı aramaya göre daha doğal sorgu anlama ve daha yüksek doğruluk sağladığı deneylerle doğrulanıyor
• Girdi sorgusunun niyetini bağlam ve cümle düzeyinde anlayarak gerçekten ilgili doğru yanıtları çıkarmanın mümkün olduğu gösteriliyor

Geleneksel Arama vs. Nöral Arama Örnekleri

• Geleneksel arama: rastlantısal sonuçlar, ağırlıkla anahtar kelime eşleşmesi
• Gömme araması: sorunun bağlamını ve niyetini kavrayıp, doğru çekirdek cümle veya kavram odaklı sonuçlar sunma
• Karmaşık kavram birleşimleri, örtük/bileşik sorular ve kalite sinyali içeren sorgularda anlam tabanlı doğru yanıt araması mümkün oluyor

Web Sayfası Ayrıştırma ve Normalizasyon

• HTML içinden yalnızca anlamsal metin öğelerini çıkarıp düzen/kontrol öğeleri gibi gürültüleri temizlemeyi amaçlayan normalizasyon hedefleniyor

• WHATWG, MDN gibi standartlara uygun biçimde p, table, pre, blockquote, ul, ol, dl gibi yapıların korunması sağlanıyor

• Menü, gezinme, yorumlar, arayüz gibi chrome öğeleri tamamen kaldırılıyor

• Siteye özel (ör. en.wikipedia.org) kurallar uygulanarak aşırı/eksik çıkarım sorunları çözülüyor

• Anlam tabanlı yapılandırılmış veriler (meta, OpenGraph, schema.org vb.) kullanılarak bilgi grafiği kurma ve sıralamayı iyileştirme de mümkün oluyor

Chunking ve Bağlam Koruma

Cümle Düzeyinde Chunking

• Gömme modellerinin sınırlarını aşmak için tüm sayfa yerine cümle tabanlı chunking uygulanıyor
• Chunking sırasında doğal cümle sınırları, dilbilgisi, kısaltmalar, URL'ler ve gayriresmî ifadeler gibi çok sayıda durum spaCy sentencizer ile doğru biçimde ayrıştırılıyor

Bağlam Koruma ve Bağlantılama

• Cümleler arasındaki bağımlılıklar, başlıklar, paragraflar, tablolar vb. tespit edilerek bağlam bilgisi de birlikte paketlenip gömmeye dahil ediliyor
• Örneğin tablo yapıları da her satırın anlamını kaybetmemesi için üst başlıklar/maddeler zincirleme biçimde bağlanarak ekleniyor

İfade Zincirleme (Statement Chaining)

• DistilBERT sınıflandırıcısı, bir cümleyi önceki cümleyle birlikte analiz ederek bağlama bağımlılığı doğrulama ve zincir çıkarımını otomatikleştiriyor
• Gömme sırasında üst bağımlı cümlelerin tamamı birlikte dahil edilerek bağlamı koruma gücü artırılıyor

Prototip Kullanım Sonuçları

• Sandbox ortamında çeşitli gerçek sorgularla yapılan deneylerde, mevcut yöntemlere kıyasla çok daha doğru (bağlama uyumlu) soru-cevap sonuçları doğrulanıyor
• Anahtar kelime uyumsuzluğu, eksiltme/mecaz/bileşik sorular gibi durumlarda da uygulama niyeti tanıyıp doğru bağlam cümlelerini eşleştiriyor; gizli bilgi ve ilişkileri de etkili biçimde ortaya çıkarıyor

Büyük Ölçekli Web Crawler'ı (Node Tabanlı)

• İş yükü dağıtımı için work stealing, alan adına göre eşzamanlılık/trafik kontrolü, DNS/URL/header doğrulaması gibi çeşitli kararlılık ve verimlilik unsurları dikkate alınıyor
• Crawler; asenkron I/O tabanlı Promise yapıları, DDoS'a dayanıklı mekanizmalar, kaynak yönetimi (bellek, gecikme, backoff) ve gürültülü domain tespiti gibi özelliklerle tasarlanıyor
• URL normalizasyonu, protokol ile port/kullanıcı bilgisi kısıtlamaları ve canonicalization ile yinelenen/anormal URL filtreleme güçlendiriliyor

Pipeline (Dağıtık Görev Kuyruğu)

• Her sayfanın durumu başlangıçta PostgreSQL üzerinde yönetiliyor; ilk aşamada doğrudan polling ve transaction kullanılıyor
• Büyük ölçekli dağıtık ortamda (binlerce crawler) ölçeklenme sorunu ile kuyruk/kilit darboğazları ortaya çıkınca, kuyruk durumunu yönetmek için Rust tabanlı bellek içi coordinator geliştiriliyor
• Görev yapısı; hash map tabanlı indeksler, binary heap, domain grupları, rastgele polling, yer değiştirme (swap_remove) gibi çeşitli indeksleme tekniklerini içeriyor
• Görev başına bellek kullanımı yaklaşık 100B düzeyinde ve 128GB sunucuda 1B görev bile işlenebiliyor
• Daha sonra SQS yerine geçecek, RocksDB tabanlı açık kaynak bir kuyruk da geliştirilerek tek düğümde saniyede 300 bin işlem destekleniyor

Depolama Tasarımı (Oracle → PostgreSQL → RocksDB)

• Başlangıçta Oracle Cloud (düşük maliyetli egress/depolama), ardından PostgreSQL (TOAST) kullanılsa da, sonunda yazma ölçeklenmesi ve performans sınırlarıyla karşılaşılıyor
• PostgreSQL'in MVCC, Write Amplification ve WAL gibi özellikleri nedeniyle büyük ölçekli paralel INSERT işlemlerinde darboğaz oluşuyor; sonuçta KV store olan RocksDB'ye geçiliyor
• RocksDB'nin ayrı blob depolaması (BlobDB), SST dosyaları, çoklu thread ve hash indexing özellikleriyle NVMe SSD'nin azami performansı kullanılıyor
• Sistem 64 RocksDB shard'ına genişletiliyor; her shard xxHash(key) tabanlı yönlendirme kullanıyor ve Serde + MessagePack serileştirmesi uygulanıyor
• Son durumda binlerce istemciden (crawler/parser/vectorizer) saniyede 200 bin işlem işleniyor; metadata ve blob'lar ayrıştırılıp sıkıştırılarak saklanıyor

Service Mesh ve Ağ Yapısı

• Altyapı büyüdükçe servis örneklerini otomatik keşfetmek ve iletişimi güvenceye almak için mTLS + HTTP2 tabanlı bir tasarım kuruluyor
• Her Node üzerinde root CA tabanlı sertifikalar uygulanıyor; MessagePack serileştirmesi doğrudan kullanılıyor, iç DNS ve CoreDNS ile özel istemci SDK'ları geliştiriliyor
• Daha önce VPN (ZeroTier, Tailscale) deneyimi bulunsa da ağ, performans ve operasyon sorunları nedeniyle doğrudan HTTP + mTLS tercih ediliyor
• Sistem servis denetimi (systemd + cgroup + journald) ile yönetim tekilleştirilip hafifletme ve standardizasyon sağlanıyor

Büyük Ölçekli GPU Gömme Üretim Pipeline'ı

• İlk aşamada OpenAI API kullanılıyor, ancak maliyet nedeniyle daha sonra Runpod gibi yüksek performanslı GPU ortamlarına geçiliyor
• Pipeline'da her aşama asenkron olarak ayrılıyor, GPU verimliliği %90'ın üstüne çıkarılıyor ve 250 GPU ile saniyede 100 bin embedding üretiliyor
• Rust pipeline, Python inference ve named pipe üzerinden IPC kullanılıyor; yapısal backpressure ile kaynaklar otomatik ayarlanıyor

Vektör İndeksleme (HNSW/Sharding)

• HNSW algoritması kullanılarak bellek tabanlı vektör araması yapılıyor; ANN (Approximate Nearest Neighbor) ile ultra düşük gecikme elde ediliyor
• RAM sınırına ulaşıldığında düğümler arasında dengeli sharding (64 düğüm) uygulanıyor ve her shard ayrı HNSW indeksiyle paralel aranıyor
• HNSW'nin doğası gereği yüksek RAM gereksinimi ve canlı güncelleme sınırları bulunuyor; sonunda CoreNN adlı disk tabanlı açık kaynak vektör veritabanına geçiliyor
• CoreNN, 128GB RAM ile tek düğümde bile 3B embedding üzerinde yüksek doğruluklu sorgulama yapabiliyor

Arama Motoru UX'i ve Gecikme Optimizasyonu

• Arama motoru UX'inde ana unsur anında yanıt vermek; bu yüzden yükleme göstergesi yok ve geleneksel SSR kullanılıyor
• Cloudflare Argo vb. ile edge PoP'lara yakınlaştırma yapılıyor, HTTP/3 benimsenerek iletim gecikmesi en aza indiriliyor
• Tüm veriler uygulama sunucusu seviyesinde hazır tutuluyor, tek tek API roundtrip'leri en aza indiriliyor ve minify edilmiş, sıkıştırılmış sayfalar anında döndürülüyor

---

Bu özet, modern doğal dil işleme ve ML teknolojileri kullanan büyük ölçekli bir web arama motorunun nasıl yalnızca 2 ayda uçtan uca kurulabildiğini; sistem, algoritma ve altyapı genelindeki başlıca tasarım ve optimizasyon kararlarıyla birlikte somut biçimde açıklıyor.

[GN⁺]

Hacker News görüşleri

• OpenAI’nin en yeni embedding modelinde batch inference için 1 milyon token başına $0.0001 gibi son derece düşük bir maliyet sunması şaşırtıcı; 1 milyar sayfayı sayfa başına 1.000 token ile embed etseniz bile toplamda yalnızca $100 tutuyor. Bunu kendi başına Runpod spot GPU’larla çalıştırmak bunun en az 100 katına mal oluyor. Diğer API maliyetleri bir yana, OpenAI’nin alan-özel kaynak verileri toplamak için bir tür honeypot stratejisi izleyip izlemediğini merak ediyorum.

  • Bildiğim kadarıyla OpenAI, özel bir istisna olmadığı sürece API üzerinden işlenen verilerin çoğuyla yeniden eğitim yapmıyor.

• Yazının sonunda Common Crawl verisini eklemeyi düşündüğünden bahsediyor. Ekibimizin web graph tabanlı sıralama bilgisinin hangi sayfaların crawl edileceğini seçmede çok yardımcı olabileceğini düşünüyorum. Büyük ölçekli bir örneği doğrudan görmek ilginçti; vector database’lerin beklenmedik ölçüde maliyet etkin olmasına şaşırdım.

• İçtenlikle hayranlık duyuyorum; yazı da inanılmaz derecede iyi toparlanmış. Arama motorlarının özünün temizlenmiş ve filtrelenmiş veri olduğuna katılıyorum (çöp girerse çöp çıkar). LLM eğitimi için de sonuçta az miktarda yüksek kaliteli verinin daha önemli olduğunu yeniden hissettim. Tüm içeriği LLM’lerin değerlendirip bir arama motoru oluşturması halinde nasıl bir performans çıkacağını merak ediyorum.

  • Şu anda bir arkadaşımın küçük işletme web sitesinin SEO’sunu bizzat yönetiyorum. Teknik tarafta düzenlemeler yaptım ve yerel odaklı elle hazırlanmış içerikler de epey yazdım. İki ay geçmesine rağmen Bing sitenin favicon’unu bile çekmedi; Google da bir ay sürdü. Hâlâ tamamen alakasız ulusal ölçekli lead toplama siteleri, Yelp blog spam’i ve bölgeyle hiç ilgisi olmayan başka şirket sayfaları üst sıralarda çıkıyor. PageRank ve crawl sisteminin bir şeyleri düzgün çalıştırmadığı açıkça görülüyor.

• Gerçekten saygı uyandırıyor; bu kadar çok teknolojiyi bir araya getirip tek sistem gibi çalıştırmak büyük iş. Bir arama motorunun belirleyici değerinin asıl sıralama algoritmasında olduğunu düşünüyorum. Bu projede LLM’nin sıralamada nasıl kullanıldığını tam anlayamadım. Eski sıralama tekniklerinden biri gerçek kullanıcıların arama→tıklama verisini toplamaktı. Bu tam olarak insanların arama sorgusu→tıkladığı bağlantı eğitim verisi demek. Birkaç tıklama bile sıralamayı belirgin biçimde iyileştiriyor. Bu veriyi neural net’e verirseniz işi bir sınıflandırma problemine çevirip sıralamayı geliştirebilirsiniz; daha çok kişi tıkladıkça ağırlığı da artar.

• Gerçekten söyleyecek tek şey bunun inanılmaz olduğu; pratikte de epey iyi çalışıyor. Eğer 10 bin kişi ayda $5 abonelikle maliyeti karşılayabiliyorsa, topluluk destekli bir arama motoru da o kadar hayal ürünü görünmüyor.

  • Encoder-only LLM’leri bilen herkes için Google’ın fiilen sona yaklaştığı açık. Google’ın hâlâ ayakta kalmasının nedeni tüm dünya web’ini tarayıp indeksini sürekli güncel tutmanın zaman alması. Common Crawl gibi açık kurumlar ya da ücretli servisler gerçek zamanlı web crawling sorununu çözerse, Google’ın 25 yıllık savunma hattı çöker ve arama giderek eşitlenir.

  • Dahası, büyük kurumsal BT’nin tüm fonksiyonel ikamelerinin gerçek zamanlı olarak ortaya çıkışını izliyoruz. Modeller sayesinde şirketlerin teknik barriers’ı artık ciddi biçimde düşüyor.

• Tek bir kişinin bunu bu noktaya kadar getirmiş olması daha önce hayal bile edilemezdi. Ticari arama motorlarından o kadar da uzak görünmüyor; belki Google’ın takip edebileceği kadar bile yakın. Yıllık $50 bin gibi bir maliyetten söz edilmesi inanılmaz derecede ucuz; neredeyse hemen seed money göndermek isteyecek kadar.

• Gerçekten harika bir proje. Büyük arama motorlarında iyi sonuç vermeyen bir sorguyla bunu da denedim: yüksek çözünürlüklü ultrawide monitör önerileri. Burada da hâlâ sadece büyük sıralamalarda uzmanlaşmış meta sayfaların, gerçekten uzman bilgi içeren sayfaların önüne geçtiğini gördüm. Sıralamaya fazla takıntılı görünüyor. Ben cevabı kendim arıyor olsam birkaç donanım forumu ve blog seçip özellikleri, artıları ve eksileri dikkatle karşılaştırırdım. Gerçek sitelerin bu analizi yapıp yapmadığını doğrulamak zor olduğu için, böyle özel durumlarda somut veri alıntılayan siteleri daha üstte değerlendirmek daha mantıklı olurdu. Kullanıcı olarak ben analizde kullanılan birincil kaynakları görmek isterim. Ama gerçek arama motorları genelde kaynak dayanaklarını alttan üste bu şekilde sunmuyor.

  • Bu baştan itibaren bir arama problemi olmayabilir; tam olarak “tek bir doğru cevabı” olan bir sayfa değil, farklı kaynakların birleşimini ve “akıl yürütmeyi” gerektiren bir soru.

• Bence gerçekten çok harika. Her şeyi bununla değiştirmeyi düşündüm; biraz zaman kaybı da olabilir ama yine de çeşitli aramalar yapıp izlenimlerimi bırakacağım. Genel olarak beni çoğu zaman neredeyse doğru yere götürdü ama %100 değildi. Örneğin fediverse’i lemmy üzerinden bulmaya çalıştığımda sonuç olarak bir liberapay sayfası çıktı. Common Crawl entegrasyonu sözünü mutlaka tutmasını, hatta archive.org gibi başka sitelere de bakmasını isterim. Yapay zeka sektörüne milyarlar akıyor; böylesi deneylerin topluluk fonlaması ya da iş paylaşımıyla gerçekten yürümesi ve başarılı olması çok güzel olurdu. Açıkçası insanlar mevcut arama motoru düzenindeki neredeyse tekel durumundan yorulmuş durumda. Ecosia’nın da kendi arama motorunu hazırladığını biliyorum; keşke bu projeyle iş birliği yapsa ya da ondan destek alsa. Ben içtenlikle merkeziyetsiz bir arama motoru istiyorum. Sürdürülebilirlik nedeniyle açık kaynak konusunda tereddüt yaşanmasını anlıyorum. Ama bu kadar çok paranın pek anlamlı olmayan yerlere harcanması sinir bozucu ve bu projenin potansiyeli çok büyük; lütfen açık kaynak yapılsın isterim. Sonunda topluluğun kitlesel fonlama gibi yollarla sürdürülebilir bir çözüm bulacağına inanıyorum. Yazının tamamını henüz okumamıştım ama o kadar heyecanlandım ki önce gidip kullandım. Yazının kendisi çok derinlikli ve bu yaklaşımın başkaları için de fazlasıyla yararlı bir referans olacağını düşünüyorum. Dürüst olmak gerekirse büyü gibi ve uzun zamandır ilk kez bir projede baştan sona heyecan hissettim. Açık kaynak yapmanın zor olduğunu, ayrıca üçüncü dünya ülkesi arka planını da anlıyorum ama gerçekten cebimden $50 bile bağışlamaya hazırım. Hayatında bir kez bile çevrimiçi ödeme yapmamış biri olarak bu kadar istekli destek vermek istiyorum. O yüzden lütfen Common Crawl gibi kaynakları kullanıp toplulukla birlikte ilerlesin. Bu projeyi ve kariyerini içtenlikle destekliyorum.

• Son zamanlarda okuduğum en içgörülü yazılardan biriydi. Maliyeti azaltmak için hangi unsurların seçildiğini ve tasarrufun gerçekte nereden geldiğini ayrıntılı biçimde anlatması özellikle hoşuma gitti. Neural search’e odaklanmış ama BM-25 + embedding birleştiren hibrit aramayı da deneyip denemediğini merak ediyorum. Ayrıca hangi reranking modellerinin en kullanışlı ve verimli olduğunu da sormak isterim.

• Gerçekten çok ilginç bir deneyim paylaşımıydı. Ben de iş araması için benzer bir şey geliştiriyorum ve benzer zorluklarla sık sık karşılaşıyorum. Birçok kişi crawling/processing/indexing işinin kolay olduğunu sanıyor ama bunu büyük ölçekte ve maliyet etkin şekilde yapmak bambaşka bir mesele. wilsonzlin’i tebrik ediyorum; bunun hakkında konuşmak isterim. Böyle bir sistemi uçtan uca gerçekten inşa eden insan sayısı çok az.