Einen Websuchmaschine von Grund auf in 2 Monaten mit 300 Millionen neuronalen Embeddings aufbauen

• Vor dem Hintergrund der Qualitätsverschlechterung von Suchmaschinen und der Fortschritte bei Transformer-basierten Embedding-Modellen wird die Erfahrung beschrieben, in zwei Monaten eine Websuchmaschine auf Basis von 300 Millionen Embeddings entwickelt zu haben
• Mit insgesamt 200 GPU-Clustern, einem groß angelegten verteilten Crawler, RocksDB, HNSW und weiterer Hochleistungsinfrastruktur sowie Algorithmen wurde eine Suche mit Echtzeit-Natural-Language-Understanding umgesetzt
• Statt Keyword-Matching war das Ziel ein intentionszentriertes Frage-Antwort-System; dafür kamen verschiedene NLP/ML-Techniken wie Normalisierung, Chunking und Statement-Chaining zur Dokumentenverarbeitung und Kontexterhaltung zum Einsatz
• Vorgestellt werden Entwurf großer verteilter Systeme für jede Schicht – Pipeline, Storage, Service Mesh, Vektorindex usw. – sowie Ansätze zur Engpass- und Kostenoptimierung
• Abschließend wird geschildert, wie eine personalisierte Suchmaschine mit extrem niedriger Latenz, großer Verteilung und hoher Genauigkeit entstand

---

Überblick und Motivation

• Der Autor entschied sich, vor dem Hintergrund sinkender Suchmaschinenqualität, SEO-Spam und der Zunahme irrelevanter Inhalte sowie angesichts der gewachsenen Sprachverständnisfähigkeiten Transformer-basierter Embedding-Modelle dazu, eine Suchmaschine von Grund auf neu zu bauen
• Die Grenzen bestehender Suchmaschinen ergeben sich aus mangelndem Frageverständnis auf menschlichem Niveau und einfachem keywordbasiertem Matching
• Ziel ist ein intentionsbasiertes Ranking, bei dem hochwertige Inhalte zuverlässig weit oben erscheinen und auch der lange Tail gleichmäßig erschlossen wird
• Der Aufbau einer Websuchmaschine umfasst viele Bereiche wie Informatik, Linguistik, Ontologien, NLP, ML, verteilte Systeme und Performance Engineering
• Dieses Projekt ist die Herausforderung, innerhalb von zwei Monaten ohne Infrastruktur oder Vorerfahrung allein eine vollständig neue Suchmaschine zu realisieren

Gesamtsystemaufbau

• Auf 200 GPU-Clustern wurden 300 Millionen SBERT-basierte Text-Embeddings erzeugt
• Hunderte Crawler sammelten parallel 50.000 Seiten pro Sekunde und bauten insgesamt einen Index mit 280 Millionen Einträgen auf
• RocksDB und HNSW wurden über Sharding auf 200 CPU-Kerne, 4 TB RAM und 82 TB SSD für Speicherung und Indexierung verteilt
• Die gesamte Query-Latenz wurde auf etwa 500 ms ausgelegt
• Die Gesamtarchitektur und der Datenfluss sind in Crawler, Pipeline, Storage, Embedding-Vektorindex, Service Mesh sowie Frontend-/Backend-Bereiche gegliedert

Experimente und Verbesserungen bei Embedding-basierter Suche

Neural Embedding Playground

• Experimente bestätigten, dass Suche mit Embedding-Modellen wie SBERT gegenüber klassischer keywordzentrierter Suche ein natürlicheres Query-Verständnis und höhere Genauigkeit bietet
• Es ist möglich, die Absicht einer Eingabe-Query auf Kontext- und Satzebene zu erfassen und tatsächlich stark relevante Antworten zu extrahieren

Beispiele: traditionelle Suche vs. neuronale Suche

• Klassische Suche: zufällige Ergebnisse, Fokus auf Keyword-Übereinstimmung
• Embedding-Suche: Erkennen von Kontext und Intention der Frage, Bereitstellung präziser Ergebnisse rund um Kernsätze oder Konzepte
• Auch bei komplexen Konzeptkombinationen, impliziten/zusammengesetzten Fragen und Queries mit Qualitätssignalen ist eine bedeutungsbasierte Suche nach den richtigen Antworten möglich

Parsen und Normalisieren von Webseiten

• Ziel der Normalisierung ist es, aus HTML nur semantisch relevante Textelemente zu extrahieren und Rauschen wie Layout- oder Steuerelemente zu entfernen

• In Anlehnung an Standards wie WHATWG und MDN bleiben Tabellenstrukturen für p, table, pre, blockquote, ul, ol, dl usw. erhalten

• Chrome-Elemente wie Menüs, Navigation, Kommentare und Interface-Bestandteile werden vollständig entfernt

• Es werden spezielle Regeln pro Website angewandt, etwa für en.wikipedia.org, um Probleme mit Über- oder Unterextraktion zu beheben

• Auch semantisch strukturierte Daten wie meta, OpenGraph und schema.org lassen sich nutzen, um Knowledge Graphs aufzubauen und das Ranking zu verbessern

Chunking und Kontexterhaltung

Chunking auf Satzebene

• Um die Grenzen von Embedding-Modellen zu überwinden, wird nicht die gesamte Seite, sondern satzbasiertes Chunking verwendet
• Beim Chunking werden natürliche Satzgrenzen, Grammatik, Abkürzungen, URLs und informelle Ausdrücke mit dem spaCy-Sentencizer präzise unterschieden

Kontexterhaltung und Verknüpfung

• Durch die Erkennung von Abhängigkeiten zwischen Sätzen, Überschriften, Absätzen, Tabellen usw. werden auch Kontextinformationen gemeinsam in die Embeddings eingebunden
• So werden etwa Tabellenstrukturen zusammen mit übergeordneten Überschriften oder Klauseln verkettet eingefügt, damit die Bedeutung jeder Zeile erhalten bleibt

Statement Chaining

• Mit einem DistilBERT-Klassifikator werden ein Satz und der vorherige Satz gemeinsam analysiert, um Kontextabhängigkeit zu prüfen und Chains zu extrahieren
• Beim Embedding werden alle übergeordneten abhängigen Sätze gemeinsam einbezogen, um die Kontexterhaltung zu verbessern

Ergebnisse des Prototypen

• In einer Sandbox-Umgebung zeigten vielfältige praxisnahe Queries im Vergleich zu bestehenden Ansätzen deutlich präzisere, kontextangepasste Frage-Antwort-Ergebnisse
• Auch bei Keyword-Mismatch, Auslassungen, Metaphern oder zusammengesetzten Fragen erkennt die App die Intention und findet die richtigen Kontextsätze – verborgene Wissensbestände und Beziehungen werden effektiv aufgedeckt

Großer Webcrawler auf Node-Basis

• Berücksichtigt wurden verschiedene Stabilitäts- und Effizienzaspekte wie Work Stealing zur Lastverteilung, domänenspezifische Parallelitäts-/Traffic-Kontrolle sowie DNS-/URL-/Header-Validierung
• Der Crawler nutzt asynchrones I/O auf Promise-Basis, DDoS-resistente Mechanismen, Ressourcenmanagement (Speicher, Delay, Backoff) und Erkennung verrauschter Domains
• Durch URL-Normalisierung, Einschränkungen bei Protokollen, Ports und Benutzerinformationen sowie Canonicalization wurde die Filterung doppelter oder fehlerhafter URLs verstärkt

Pipeline (verteilte Task-Queue)

• Der Status jeder Seite wurde in PostgreSQL verwaltet; anfangs kamen direkt Polling und Transaktionen zum Einsatz
• In einer großen verteilten Umgebung mit Tausenden Crawlern traten Skalierungsprobleme sowie Queue-/Lock-Engpässe auf → Verwaltung des Queue-Zustands mit einem In-Memory-Koordinator auf Rust-Basis
• Task-Struktur: HashMap-basierte Indizes, Binary Heap, Domain-Gruppen, zufälliges Polling, swap_remove und weitere Indexierungsverfahren
• Der Speicherbedarf pro Task liegt bei etwa 100 B; auf einem 128-GB-Server lassen sich auch 1B Tasks verarbeiten
• Später wurde als Ersatz für SQS eine Open-Source-Queue auf RocksDB-Basis entwickelt, die auf einem einzelnen Node 300.000 Ops/s unterstützt

Storage-Design (Oracle → PostgreSQL → RocksDB)

• Zunächst wurden Oracle Cloud (günstiger Egress/Storage) und später PostgreSQL (TOAST) genutzt, stießen aber an Grenzen bei Write-Scaling und Performance
• Aufgrund von Eigenschaften wie MVCC, Write Amplification und WAL wurde PostgreSQL bei massiv parallelen INSERTs zum Engpass; schließlich erfolgte der Wechsel zum KV-Store RocksDB
• Mit separater Blob-Speicherung (BlobDB), SST-Dateien, Multithreading und Hash-Indizierung nutzt RocksDB die maximale Leistung von NVMe-SSDs aus
• Skalierung auf 64 RocksDB-Shards – jedes Shard wird per xxHash(key)-basiertem Routing angesprochen, mit Serde+MessagePack-Serialisierung
• Am Ende wurden 200.000 Ops/s aus Tausenden Clients (Crawler/Parser/Vectorizer) verarbeitet; Metadaten und Blobs werden getrennt und komprimiert gespeichert

Service Mesh und Networking

• Für automatische Service-Discovery und abgesicherte Kommunikation beim Ausbau der Infrastruktur wurde ein Design auf Basis von mTLS+HTTP2 gewählt
• Auf jedem Node kommen Zertifikate mit Root-CA-Basis zum Einsatz; zusätzlich wurden direkte MessagePack-Serialisierung, internes DNS und CoreDNS sowie ein eigenes Client-SDK entwickelt
• Zwar gab es Erfahrungen mit bestehenden VPNs (ZeroTier, Tailscale), wegen Problemen bei Netzwerk, Performance und Betrieb fiel die Wahl aber auf eigenes HTTP+mTLS
• Mit System-Service-Steuerung (systemd + cgroup + journald) wurde das Management vereinheitlicht sowie eine schlanke und standardisierte Betriebsumgebung erreicht

Pipeline zur Erzeugung von Embeddings im großen GPU-Maßstab

• Anfangs wurde die OpenAI API verwendet, wegen der Kosten erfolgte später der Wechsel in Hochleistungs-GPU-Umgebungen wie Runpod
• Die Pipeline trennt die einzelnen Stufen asynchron, erreicht über 90 % GPU-Auslastung und erzeugt auf 250 GPUs 100.000 embeddings pro Sekunde
• Rust-Pipeline, Python-Inference → IPC über named pipe, automatische Ressourcentuning durch strukturierten Backpressure

Vektorindizierung (HNSW/Sharding)

• Mit dem HNSW-Algorithmus wird eine speicherbasierte Vektorsuche als ANN (Approximate Nearest Neighbor) für extrem niedrige Latenzen realisiert
• Bei Erreichen der RAM-Grenzen wurde gleichmäßiges Sharding über Nodes hinweg (64 Nodes) eingesetzt; jedes Shard wird mit einem eigenen HNSW-Index parallel durchsucht
• Aufgrund der hohen RAM-Anforderungen und begrenzter Live-Update-Fähigkeiten von HNSW erfolgte schließlich der Wechsel zu CoreNN, einer diskbasierten Open-Source-Vektor-DB
• CoreNN ermöglicht auch auf einem einzelnen Node mit 128 GB RAM hochpräzise Abfragen über 3B Embeddings

Suchmaschinen-UX und Latenzoptimierung

• Für die UX einer Suchmaschine ist Unmittelbarkeit der Antwort entscheidend (kein Ladeindikator, traditionelles SSR)
• Mit Cloudflare Argo u. a. wird die Nähe zu Edge-PoPs erhöht; durch HTTP/3 wird die Übertragungslatenz minimiert
• Auf Ebene des App-Servers werden alle Daten vollständig vorbereitet, einzelne API-Roundtrips minimiert und minifizierte sowie komprimierte Seiten sofort ausgeliefert

---

Diese Zusammenfassung zeigt konkret die wichtigsten Entwurfs- und Optimierungspunkte über System, Algorithmen und Infrastruktur hinweg, wie eine groß angelegte Websuchmaschine mit aktueller Natural-Language-Processing- und ML-Technologie in nur zwei Monaten end-to-end aufgebaut werden kann.

[GN⁺]

Hacker-News-Kommentare

• Es ist erstaunlich, dass OpenAIs neuestes Embedding-Modell bei Batch-Inferenz extrem niedrige Kosten von $0.0001 pro 1 Million Token bietet; selbst wenn man 1 Milliarde Seiten mit jeweils 1.000 Token einbettet, kostet das insgesamt nur $100. Wenn man die Inferenz selbst auf Runpod-Spot-GPUs laufen lässt, wird es etwa 100-mal teurer. Andere API-Kosten einmal außen vor. Ich frage mich, ob das nicht eine Art Honeypot-Strategie von OpenAI ist, um sich domänenspezifische Quelldaten zu sichern.

  • OpenAI trainiert meines Wissens im Allgemeinen nicht erneut mit Daten, die über die meisten APIs verarbeitet werden; abgesehen von besonderen Ausnahmen sollte das nicht passieren.

• Am Ende des Artikels wird erwähnt, dass man darüber nachdenkt, Common-Crawl-Daten hinzuzufügen. Die Ranking-Informationen unseres Teams auf Basis des Webgraphen wären vermutlich sehr hilfreich bei der Auswahl, welche Seiten gecrawlt werden sollen. Es war spannend, ein konkretes Beispiel in großem Maßstab zu sehen, und überraschend, wie kosteneffizient Vektor-Datenbanken offenbar sind.

• Ich bin wirklich beeindruckt, und der Artikel ist auch bemerkenswert gut aufbereitet. Ich stimme zu, dass der Kern einer Suchmaschine in bereinigten und gefilterten Daten liegt (garbage in, garbage out). Auch beim Training von LLMs merkt man wieder, dass eine kleine Menge hochwertiger Daten am Ende wichtiger ist. Ich frage mich, welche Leistung eine Suchmaschine hätte, wenn ein LLM alle Inhalte prüfen würde.

  • Ich betreue gerade selbst das SEO für die Website des kleinen Unternehmens eines Freundes. Ich habe sie technisch optimiert und auch einiges an lokal zugeschnittenem, manuell geschriebenem Content erstellt. Nach zwei Monaten hat Bing nicht einmal das Favicon eingesammelt, und Google hat dafür auch einen Monat gebraucht. Noch immer ranken völlig irrelevante landesweite Lead-Sammelseiten, Yelp-Blogspam und Seiten anderer Anbieter ohne jeden lokalen Bezug ganz oben. Es sieht ziemlich eindeutig so aus, als würden PageRank und das Crawling-System nicht richtig funktionieren.

• Ich habe wirklich großen Respekt davor. So viele Technologien zusammenzubringen und als ein System zum Laufen zu bringen, ist eine enorme Leistung. Ich denke, der entscheidende Wert einer Suchmaschine liegt im eigentlichen Ranking-Algorithmus. Mir ist nicht ganz klar, wie das LLM in diesem Projekt fürs Ranking eingesetzt wird. Unter den älteren Ranking-Methoden gibt es das Sammeln echter Such-und-Klick-Daten von Nutzern. Das sind im Grunde menschliche Suchbegriff→angeklickter-Link-Trainingsdaten. Schon wenige Klicks verbessern das Ranking deutlich. Gibt man diese Daten in ein neuronales Netz, lässt sich das als Klassifikationsproblem formulieren und das Ranking verbessern. Je mehr Leute klicken, desto höher wird die Gewichtung.

• Mehr als dass es wirklich erstaunlich ist, kann ich kaum sagen. Es funktioniert in der Praxis ziemlich gut. Wenn 10.000 Menschen monatlich $5 abonnieren und damit die Kosten gedeckt wären, dann klingt eine von der Community unterstützte Suchmaschine gar nicht mehr so unrealistisch.

  • Für Leute, die Encoder-only-LLMs kennen, ist klar, dass Google im Grunde schon erledigt ist. Dass Google sich noch hält, liegt nur daran, dass das Crawlen des weltweiten Webs und das permanente Aktualisieren des Indexes lange dauert. Wenn offene Organisationen wie Common Crawl oder kostenpflichtige Dienste das Problem des Echtzeit-Webcrawlings lösen, bricht Googles 25-jähriger Schutzwall zusammen, und Suche selbst wird zu einer Commodity.

  • Darüber hinaus beobachten wir gerade in Echtzeit, wie für jede Funktion im Enterprise-IT-Bereich Ersatz entsteht. Durch Modelle sind die technischen Barrieren von Unternehmen inzwischen stark gesunken.

• Dass eine einzelne Person so weit gekommen ist, hätte ich mir nie vorstellen können. Es scheint gar nicht so weit von einer kommerziellen Suchmaschine entfernt zu sein, vielleicht sogar in Reichweite von Google. Dass das für $50.000 im Jahr möglich sein soll, ist absurd günstig; ich hätte fast Lust, sofort Seed-Geld zu schicken.

• Wirklich ein tolles Projekt. Ich habe hier auch Fragen ausprobiert, die bei bekannten Suchmaschinen oft nicht gut beantwortet werden, etwa Empfehlungen für hochauflösende Ultrawide-Monitore. Aber noch immer taucht das Problem auf, dass Meta-Seiten, die nur auf großes Ranking spezialisiert sind, vor Seiten mit tatsächlicher Fachinformation erscheinen. Es wirkt, als sei die Fixierung auf Ranking zu stark. Wenn ich selbst eine Antwort suchen würde, würde ich einige Hardware-Foren und Blogs auswählen und Spezifikationen sowie Vor- und Nachteile sorgfältig vergleichen. Da man schwer überprüfen kann, ob eine Website eine solche Analyse wirklich gemacht hat, wäre es in Sonderfällen sinnvoller, Seiten höher zu bewerten, die konkrete Daten zitieren. Als Nutzer möchte ich die Primärquellen sehen, auf denen die Analyse basiert. Aber echte Suchmaschinen heben solche Quellen nicht von unten nach oben hervor.

  • Vielleicht ist das von vornherein gar kein klassisches Suchproblem. Es gibt nicht eine einzelne Seite mit einer klaren, „festgelegten Antwort“, sondern es ist eine Frage, die eine Kombination mehrerer Quellen und „Schlussfolgerung“ erfordert.

• Ich finde das wirklich großartig. Ich wollte schon versuchen, alles damit zu ersetzen. Das wäre vielleicht ein wenig Zeitverschwendung, aber ich werde auf jeden Fall verschiedene Suchen ausprobieren und Eindrücke hinterlassen. Meistens führt es einen fast an die richtige Stelle, aber eben nicht zu 100 %. Als ich zum Beispiel mit lemmy nach dem Fediverse suchen wollte, bekam ich eine Liberapay-Seite als Ergebnis. Ich hoffe wirklich, dass das Versprechen eingehalten wird, Common Crawl einzubinden, und dass auch andere Seiten wie archive.org berücksichtigt werden. In die AI-Branche fließen Milliarden, und ich hoffe, dass genau solche Experimente erfolgreich laufen können, sei es über Community-Finanzierung oder geteilte Arbeit. Ehrlich gesagt sind viele Menschen von der fast monopolartigen Lage der heutigen Suchmaschinen erschöpft. Soweit ich weiß, arbeitet Ecosia ebenfalls an einer eigenen Suchmaschine; ich hoffe sehr, dass es mit diesem Projekt zusammenarbeitet oder davon Hilfe bekommt. Ich wünsche mir aufrichtig eine dezentrale Suchmaschine. Ich verstehe, dass man wegen der Nachhaltigkeit beim Open Source noch zögert. Aber es ist frustrierend, wie viel Geld ohne großen Sinn verbrannt wird, während dieses Projekt enormes Potenzial hat; ich hoffe wirklich, dass es Open Source wird. Ich glaube, die Community würde letztlich Wege zur Nachhaltigkeit finden, etwa per Crowdfunding. Ich habe den Beitrag noch nicht einmal ganz gelesen, sondern ihn vor lauter Begeisterung sofort ausprobiert. Der Artikel selbst ist sehr tiefgehend, und ich denke, dieser Ansatz kann auch für andere sehr hilfreich sein. Ehrlich gesagt wirkt es magisch, und zum ersten Mal seit Langem hat mich ein Projekt von Anfang bis Ende begeistert. Ich verstehe, dass Open Source schwierig ist und dass es einen Hintergrund in einem Drittland gibt, aber ich wäre wirklich bereit, sogar $50 meines eigenen Geldes zu spenden. Ich habe noch nie in meinem Leben online bezahlt, und trotzdem würde ich dieses Projekt so gern unterstützen. Deshalb hoffe ich sehr, dass es mit Dingen wie Common Crawl gemeinsam mit der Community weitergeht. Ich wünsche diesem Projekt und der Karriere dahinter von Herzen alles Gute.

• Das war einer der aufschlussreichsten Beiträge, die ich in letzter Zeit gelesen habe. Besonders gut fand ich, dass die ausgewählten Maßnahmen zur Kostensenkung und die tatsächlichen Einsparungspunkte detailliert erklärt wurden. Der Fokus lag auf Neural Search, aber ich frage mich, ob auch hybride Suche mit BM-25 + Embeddings ausprobiert wurde. Und ich würde gern wissen, welche Reranking-Modelle am nützlichsten und effizientesten waren.

• Das war ein wirklich interessanter Erfahrungsbericht. Ich entwickle selbst etwas Ähnliches für die Business-Suche und stoße auf viele ähnliche Herausforderungen. Viele Leute denken, Crawling, Verarbeitung und Indexierung seien einfach, aber das in großem Maßstab kosteneffizient zu tun, ist ein völlig anderes Problem. Applaus für wilsonzlin; ich würde mich gern einmal dazu austauschen. Es gibt wirklich nur sehr wenige Menschen, die so etwas end-to-end selbst bauen.