Anatomia silnika Postgres w dobie odbudowy ruchu po-search

Wpis pojawił się 27 września o 01:39 UTC. Blog inżynieryjny PlanetScale opublikował „Anatomia (Postgres) Search Engine”, omawiając, jak inwersyjne indeksy, słowniki terminów i listy pozycji zastępują skanowanie wiersz po wierszu, które sprawia, że zapytania LIKE '%postgres%' są kosztowne. Czas publikacji nie jest przypadkowy dla branży medialnej, nawet jeśli wpis nie wspomina o wydawnictwach.

Ruch z wyszukiwarek to to, co wydawcy próbują zastąpić lub odbudować, a rozmowa o infrastrukturze przesunęła się niżej. Tekst PlanetScale przypomina, że mechanizmy za wyszukiwarką nie są magią. Indeks b-tree sortuje wartości kolumny w porządku całkowitym i może znaleźć dokładną wartość, zakres lub prefiks. Nie potrafi jednak dopasować treści w środku ciągu. To zadanie należy do inwersyjnego indeksu, który mapuje każde pojedyncze słowo w polu tekstowym do dokumentów je zawierających.

Wpis jest wystarczająco szczegółowy, by przydać się inżynierom, i na tyle konkretny, by dało się go zweryfikować. PlanetScale opisuje słownik terminów, który mapuje każdy termin we wszystkich dokumentach do list pozycji. Słownik jest przechowywany na dysku jako b-tree lub inna struktura posortowana leksykograficznie. Zapytania z gwiazdką i rozmyte mogą skanować część lub cały ten słownik: g* wyszukuje zarówno gonna, jak i give, podczas gdy u~2 wyszukuje każdy termin w odległości dwóch edycji znaków, co w przykładzie z wpisu oznacza you i up.

Dlaczego rurociąg ma znaczenie dla wydawców

Listy pozycji są prawie zawsze sortowane i skompresowane. PlanetScale podaje przykład obliczeniowy: indeks z 300 000 dokumentów, z których 100 000 zawiera słowo „who”, zajmowałby 19 bitów na pozycję, gdyby każdy identyfikator był przechowywany dosłownie. Średnia luka między kolejnymi posortowanymi identyfikatorami wynosi trzy, co mieści się w dwóch bitach. Gęste listy mogą być przechowywane jako mapy bitowe, jeden bit na dokument. Suma i przecięcie posortowanych list wykonują się w jednym przejściu O(n), a operacje na mapach bitowych mogą używać instrukcji wektorowych, aby OR-ować lub AND-ować 128, 256 lub nawet 512 bitów naraz.

To ten sam typ problemu, z którym wydawcy mierzą się teraz po stronie konsumpcji. 28 września Digiday opublikowało podsumowanie swojego Publishing Summit, opisujące, jak wydawcy odbudowują się na erę post-search. Tego samego ranka cxotoday.com zamieściło artykuł argumentujący, że media niezależne są duszone przez Google i inne giganty AI. Żadne z tych mediów nie jest wymienione we wpisie PlanetScale, a blog techniczny w ogóle nie porusza kwestii ruchu odsyłającego. Związek jest strukturalny: wyszukiwanie jest przebudowywane po obu stronach zapytania.

Liczby krążące w prasie branżowej nie są łagodne. Niedawne nagłówki śledzone w dossier obejmują 40% spadek rok do roku odsyłania z Google Search dla wydawców, datowany na 24 września, oraz osobny raport o spadku ruchu z wyszukiwarek w całym internecie, z czymś w rodzaju 60% spadku dla niektórych małych stron. Te dane pochodzą z agregacji nagłówków, a nie z pierwotnych źródeł, więc traktuj je jako kierunkowe. Kierunek jest spójny.

Otwartoźródłowe alternatywy też się ruszają

Luxir, otwartoźródłowy hybrydowy silnik wyszukiwania opublikowany 22 września, opiera się na tych samych ekonomicznych założeniach. Jego strona twierdzi, że oferuje wyszukiwanie pełnotekstowe, wektorowe i fasetowane z analityką z jednego silnika. Wyróżnia się harmonogramerem kradnącego pracę, który dzieli indeksowanie, scalanie i wykonanie zapytań między wszystkie rdzenie, asynchronicznym IO sieciowym oraz ścieżkami SIMD dla dekodowania pozycji, punktacji i odległości wektorowej. Liczby faset są dokładne domyślnie, według projektu, a żądania top-k przycinają z ograniczeniami block-max, gdy wywołujący nie prosi o wyczerpującą sumę.

Strona Luxir to strona produktowa, a nie papier z benchmarkami, a jej twierdzenia o wydajności są samodeklarowane. To samo dotyczy wpisu PlanetScale, opublikowanego przez firmę sprzedającą bazę danych zgodną z Postgres. Oba są przydatne jako opisy architektury i oświadczenia o intencjach. Żadnego nie należy czytać jako niezależnego pomiaru.

W innym miejscu dossier, 22 września pojawił się na arXiv artykuł Jochena Madlera ze Sitefire, „SlopShape: Identifying AI-Generated Commercial Web Content”, oferujący strukturalny detektor marketingowych treści pisanych przez AI. Artykuł raportuje 2 250 ludzkich wpisów blogowych sprzed ChatGPT z 268 domen firmowych w porównaniu z 11 250 lustrzanymi odbiciami AI z pięciu modeli frontierowych. Wykrywanie osiąga 98.0 macro-F1 na trzymanych z boku firmach, wyłącznie z 187 cech strukturalnych. Przypisanie do poprawnego modelu źródłowego wynosi 79.3% przy szansowym poziomie 16.7%. Kappa człowiek-człowiek wyniosło 0.928, a człowiek-model 0.946. Artykuł to wersja v2, zrewidowana 17 września.

To ma znaczenie z tego samego powodu, co infrastruktura wyszukiwania. Jeśli duża część komercyjnych treści webowych jest generowana maszynowo w porządku, samookreślającym kształcie, to korpus, który indeksują wyszukiwarki, zmienia się w tym samym czasie, co same silniki. Wydawcy odbudowujący się na erę post-search nie rywalizują tylko o pozycję na stronie wyników. Rywalizują o pozycję w korpusie, który coraz częściej pisze z powrotem.

Dwa mniejsze elementy w dossier wskazują w tym samym kierunku. ParkourNote, przestrzeń badawcza zbudowana przez soloprzypuszczalnie, opublikowana 28 września, importuje artykuły, książki, strony web i filmy, transkrybuje i tłumaczy je, a bibliotekę udostępnia Claude, ChatGPT lub Codex przez serwer MCP. GPU-font, również opublikowany 28 września, uruchamia małą sieć neuronową w przeglądarce przez WebGPU, aby dopasować fonty z obrazu. Obie to projekty indywidualne, nie przesunięcia platformowe. Są też przykładami tego samego wzorca: więcej możliwości, mniej serwera, mniej pośredników.

Dla wydawców praktyczne pytanie się nie zmienia. Odsyłanie z wyszukiwarek spada, techniczny koszt budowy produktu wyszukiwania spada wraz z nim, a wolumen syntetycznych treści rywalizujących o te same sloty indeksu rośnie. Wpis PlanetScale wyjaśnia, jak indeks znajduje słowo. Nie wyjaśnia, kto zostaje znaleziony.