Postgres, Luxir und SlopShape: Der Suchstack wird neu gebaut, während der Traffic der Verlage fällt
PlanetScale hat am 27. September eine ausführliche technische Erklärung zur Volltextsuche in Postgres veröffentlicht. Sie ist der jüngste Beitrag einer Woche voller Suchinfrastruktur-Veröffentlichungen, während Verlage starke Rückgänge bei Suchverweisen melden.

Die jüngste Entwicklung im Suchstack kam diese Woche nicht von einer Suchmaschine. Am 27. September veröffentlichte PlanetScale "Anatomy of a (Postgres) Search Engine". Die technische Erklärung beschreibt, wie invertierte Indizes in Postgres arbeiten und wie sie sich von den b-trees unterscheiden, zu denen die meisten Entwickler zuerst greifen.
Der Beitrag von PlanetScale erinnert daran, dass Suche inzwischen eine Datenbankfunktion ist, nicht nur eine Produktkategorie. "A b-tree is useless for matching content in the middle of a string", schreibt das Unternehmen. Dann zeigt es das Muster, das Entwickler nicht mehr verwenden sollen: eine Abfrage, die jede Zeile einer Tabelle mit einem führenden Wildcard-LIKE prüft. Die Alternative ist ein invertierter Index, der auf jedes einzelne Wort eines Feldes verweist. Laut dem Beitrag finden "essentially all full-text search engines" damit ihre Dokumente. Ein kleiner architektonischer Punkt mit großen Folgen dafür, wie schnell eine Datenbank eine Frage beantworten kann.
Die Erklärung bleibt bei der Mechanik ungewöhnlich konkret. Ein invertierter Index hat ein Termwörterbuch und Postings-Listen und kann zusätzlich Positions- und Häufigkeitsdaten führen. Postings-Listen sind sortiert und werden dann komprimiert: PlanetScale nennt das Beispiel eines Index mit 300.000 Dokumenten, von denen 100.000 das Wort "who" enthalten. Jede ID wörtlich zu speichern würde 19 Bit pro Posting kosten, doch der durchschnittliche Abstand zwischen aufeinanderfolgenden IDs beträgt drei, was in zwei Bit passt. Dichte Listen können weiter gehen und eine Bitmap speichern, was optimal wird, sobald etwa die Hälfte aller Dokumente einen Term enthält. Das ist ein Komprimierungsdetail, aber es erklärt, warum Suche über große Korpora überhaupt bezahlbar ist und warum die Abfrage-Engine die Vereinigung oder Schnittmenge zweier Postings-Listen in einem einzigen O(n)-Durchlauf bilden kann. PlanetScale merkt außerdem an, dass Vektorbefehle auf neueren CPUs 128, 256 oder sogar 512 Bit in einer einzigen Instruktion mit OR oder AND verknüpfen können, wenn Listen als Bitmaps gespeichert sind.
Luxir bewirbt Vollspektrum-Suche als eine Engine
Fünf Tage früher, am 22. September, veröffentlichte ein separates Projekt namens Luxir seine eigene Anpreisung: eine Open-Source-Engine, die Volltext-, Vektor- und Facettensuche mit Analytik in einer Anfrage verbindet. Die Seite von Luxir argumentiert mit Kosten statt mit Funktionen und sagt, die Engine sei "designed for the most search per core, per gigabyte, and per dollar", und Cloud-Kunden "pay for inefficiency forever".
Die Architekturangaben sind konkret. Ein Work-Stealing-Scheduler verteilt Indexierung, Merging und Abfrageausführung über Kerne, Netzwerk-IO läuft asynchron, damit ein langsamer Client keinen Kern belegt, und Segmente sind unveränderlich und speichergemappt, sodass sie aus dem Page-Cache gelesen werden. Postings-Dekodierung, Scoring und Vektorabstand laufen auf SIMD-Pfaden, mit Block-Max-Pruning für Top-k-Anfragen. Luxir bezieht auch zu Zählungen Position, was für jeden wichtig ist, der eine Suchoberfläche baut. Facettenzählungen sind "always exact by default", so das Projekt, und Gesamttrefferzahlen sind exakt, wenn die Anfrage sie verlangt, und werden beschnitten, wenn nicht. Abfragen, Facetten und Metriken laufen im selben Durchlauf über dieselbe Indexansicht, sodass eine Runde Dokumente, Seitenleistenzahlen und Kopfzahlen zusammen zurückbringt.
Beide Beiträge beschreiben Technik, die die meisten Nutzer nie sehen. Aber sie ist die Ebene, auf der die Ökonomie der Suche entschieden wird, und diese Ökonomie verändert sich schnell.
Ein Detektor, der Struktur liest, nicht Vokabular
Am selben Tag wie der Start von Luxir nahm ein Paper auf arXiv den Inhalt ins Visier, der diese Indizes füllt. "SlopShape: Identifying AI-Generated Commercial Web Content", eingereicht am 14. September und überarbeitet am 17. September, fragt, ob sich KI-generierter Text an strukturellen Signaturen erkennen lässt, also daran, wie Informationen präsentiert werden, in welcher Reihenfolge, mit welchen Belegen und in welcher Stimme. Der Autor, Jochen Madler von Sitefire, replizierte die Arbeit StoryScope von Russell et al. an kommerziellem Content: 2.250 vor ChatGPT entstandene menschliche Blogbeiträge von 268 Unternehmensdomains gegen 11.250 KI-Spiegelungen aus fünf Frontier-Modellen. Ein Instrument mit 214 Merkmalen, angewendet von einem LLM und validiert in einer menschlichen Gold-Annotationssitzung mit einem Mensch-Mensch-Kappa von 0,928 und einem Mensch-Modell-Kappa von 0,946, erkannte KI-Beiträge allein anhand seiner 187 strukturellen Merkmale mit 98,0 Macro-F1 bei zurückgehaltenen Unternehmen. Wurde jeder KI-Beitrag mit seinem eigenen Modell umformuliert, blieb der Wert mit 98,1 unverändert.
Das Paper beansprucht außerdem Zuordnung. KI-Beiträge teilen "a tidy, self-announcing shape", 79,3 Prozent werden dem richtigen Quellmodell zugeordnet, bei einer Zufallsrate von 16,7 Prozent, und menschliche Beiträge besetzen seltene strukturelle Konfigurationen. Pipeline, Instrument, Prompts und Code sind veröffentlicht.
Das Ergebnis ist für die Suche wichtig, weil Struktur genau das ist, was Ranking-Systeme und KI-Antwortmaschinen verarbeiten. Wenn kommerzieller Web-Content eine erkennbare Form hat, dann wird das Korpus, das Suchmaschinen indexieren, gleichzeitig einheitlicher, während die Werkzeuge zum Indexieren schneller und billiger werden.
Bezahlen müssen es die Verlage
Die umliegenden Schlagzeilen im Dossier zeigen in die andere Richtung. Die jüngste im Dossier zitierte Berichterstattung enthält einen Bericht, dass der Rückgang der Google-Suche für Verlage auf 40 Prozent im Jahresvergleich zunahm, datiert auf den 24. September, und einen separaten Beitrag, wonach Google Search Profile Badges die Traffic-Krise der Verlage offenlegen, datiert auf den 16. September. Ältere Beiträge beschreiben, dass Suchmaschinen-Traffic im ganzen Web zurückgeht, wobei einige kleine Websites einen Rückgang von 60 Prozent sehen, und dass die Google-KI-Suche kleine Verlage bedroht, weil konversationelle KI den Website-Traffic senkt. Einige dieser Daten liegen außerhalb der letzten Woche, sie sind also Hintergrund statt Nachricht. Aber sie setzen den Rahmen für die technischen Veröffentlichungen oben: Die Kosten für den Aufbau eines Suchindex fallen weiter, und der Traffic, den dieser Index an Verlage zurückschickt, fällt mit.
Zwei weitere Dossier-Einträge zeigen, wie weit das Feld geworden ist. Am 26. September öffnete CleanTechnica Einreichungen für seinen eigenen Buchverlag und bietet Autoren einen Weg zur Veröffentlichung für eine Vorabgebühr von 3.000 bis 5.000 Dollar plus einen Prozentsatz pro verkauftem Buch, mit einem für den 30. September angesetzten Google Hangout. Am 24. September veröffentlichte der Engineering-Content-Hub von Wiley ein Whitepaper, gesponsert von Hendrix by Marmon Utility, über den Bau von Schaltanlagenausgängen. Es argumentiert, dass Zuverlässigkeit bei den ersten Spannen aus einer Station heraus ungewöhnlich schwer wiegt, weil ein einzelner kontaktbedingter Fehler dort viele Stromkreise gleichzeitig unterbrechen kann.
Keines von beiden ist auf den ersten Blick eine Suchgeschichte. Aber beide sind kommerzieller Content für ein bestimmtes Publikum, produziert unter dem Namen eines Sponsors oder der Marke eines Verlags, also dieselbe Kategorie, die das SlopShape-Paper zu klassifizieren versucht. Die Behauptung des Papers ist, dass solcher Content eine Form hat: eine bestimmte Reihenfolge, eine bestimmte Art von Belegen, eine bestimmte Stimme. Wenn das stimmt, muss die nächste Generation von Suchmaschinen entscheiden, was sie damit macht.
Vorerst bewegt sich die Infrastrukturseite schneller als die Politikseite. PlanetScale liefert TIN aus, seinen Volltext-Suchindex für Postgres, und kündigt einen tieferen Artikel zu Funktionen, Leistung und Implementierung an. Luxir ist herunterladbar, mit einer HTTP/JSON-API auf Port 9400 und einem Datenverzeichnis für die Persistenz. Das arXiv-Paper ist öffentlich, mit Code und Artefakten.
Was keines von ihnen klärt, ist, wohin die Leser gehen. Suchmaschinen werden besser darin, Dokumente zu finden, und Verlage melden, dass weniger Menschen bei ihnen ankommen. Diese Lücke ist die Geschichte, die die Werkzeuge noch nicht beantwortet haben.
Quellen
5- 01Anatomy of a (Postgres) Search EngineEN
- 02Luxir: Open-source hybrid search engineEN
- 03SlopShape: Identifying AI-Generated Commercial Web ContentEN
- 04Publish Your Book Through CleanTechnica PressEN
- 05Engineering the Substation Exit for Reliability, Capacity, and ExpansionEN
Alle Zahlen und Zitate in diesem Text stammen aus den unten genannten Quellen.
Die Materialien wurden vom Redaktionsteam mit Unterstützung von KI erstellt.
Kommentare
0- Noch keine Kommentare — seien Sie der Erste.