Nieraz stawałem po stronie pgvectora jako sensownego wyboru domyślnego do wyszukiwania wektorowego. Po jakimś czasie utrzymywania go na produkcji zebrałem to, o czym wprowadzające poradniki milczą: wybór indeksu i jego kompromisy, dostrajanie relacji recall–szybkość, utrzymywanie embeddingów w zgodzie ze źródłem i pułapki operacyjne, które ujawniają się dopiero przy skali.
Gdy wyszukiwanie semantyczne przerośnie testowy zbiór danych, pojawia się pytanie: zostać przy pgvector w Postgresie, czy przejść na dedykowaną bazę wektorową, taką jak Pinecone, Qdrant czy Weaviate? Szczegółowo o tym, co naprawdę zmienia się w dużej skali, z czego rezygnujesz, opuszczając Postgres, i jak podjąć decyzję bez przeinżynierowania.
Wyszukiwanie słów kluczowych dopasowuje słowa; wyszukiwanie semantyczne dopasowuje znaczenie. Deep-dive o embeddingach i podobieństwie wektorowym oraz o tym, jak pgvector pozwala robić wyszukiwanie semantyczne w Postgresie, który już uruchamiasz — bez osobnej bazy wektorowej.
Otrzymanie wyników wyszukiwania jest łatwe; otrzymanie właściwych produktów we właściwej kolejności to prawdziwa praca. Deep-dive o strojeniu trafności dla sklepu — boostowanie sygnałami biznesowymi, synonimy, obsługa literówek, zero wyników i mierzenie, czy twoje zmiany naprawdę pomagają.
Gdy sklep potrzebuje wyszukiwania, odruchem jest Elasticsearch — ale wyszukiwanie pełnotekstowe Postgresa dorosło. Pojedynek dla przypadku e-commerce: szeregowanie, fasety, tolerancja literówek i koszt operacyjny, który to rozstrzyga.
SQL LIKE to nie wyszukiwanie. Deep-dive o dodaniu prawdziwego wyszukiwania pełnotekstowego do aplikacji Rails z Elasticsearch — analizatory, mapowania, trafność, trzymanie indeksu w synchronizacji — i uczciwe spojrzenie na to, kiedy zamiast tego wystarczy Postgres.
Użytkownicy robią literówki, a dopasowanie dokładne po cichu ich zawodzi. Praktyczny deep-dive w rozmyte dopasowanie oparte na trigramach w Ruby — jak działa, jak je przyspieszyć i kiedy zamiast tego wepchnąć je do Postgresa.