Jak przygotować wyszukiwarkę katalogu firm odporną na literówki

Użytkownik wpisuje „hydraulik Wrocaw”, „stomatolok Kraków” albo nazwę firmy bez polskich znaków. Jeżeli katalog odpowiada komunikatem „brak wyników”, problem nie leży po stronie użytkownika. Źle przygotowano wyszukiwarkę.

Odporność na literówki nie polega jednak na włączeniu jednego parametru fuzziness. W katalogu firm wyszukiwanie obejmuje jednocześnie nazwy przedsiębiorstw, branże, miejscowości, ulice, kody pocztowe i potoczne określenia usług. Każde z tych pól wymaga innych zasad. Zbyt restrykcyjne dopasowanie pomija poprawne rekordy, a zbyt luźne potrafi pokazać zakład pogrzebowy po wpisaniu „zakład fryzjerski”. Dobra konfiguracja musi znaleźć kompromis między czułością wyszukiwania a trafnością wyników.

Najpierw uporządkuj dane, dopiero potem włącz tolerancję literówek

Algorytm nie naprawi bałaganu w bazie. Jeżeli ta sama miejscowość występuje jako „Warszawa”, „W-wa”, „warszawa ” i „M. St. Warszawa”, wyszukiwarka będzie próbowała porównywać warianty, które powinny zostać ujednolicone już podczas importu danych.

Przed indeksowaniem warto utworzyć osobne pola dla:

• nazwy firmy,
• nazwy handlowej,
• branży i kategorii działalności,
• opisu usług,
• miejscowości, dzielnicy i województwa,
• ulicy i numeru budynku,
• kodu pocztowego,
• numerów identyfikacyjnych, takich jak NIP, REGON czy KRS.

Nie należy wrzucać całego rekordu do jednego pola tekstowego. Zapytanie „dentysta Mokotów” powinno być rozpoznane jako połączenie kategorii z lokalizacją, a nie jako przypadkowy fragment długiego opisu przedsiębiorstwa.

Podstawowa normalizacja powinna obejmować:

• zamianę wielkich liter na małe,
• usunięcie zbędnych spacji,
• ujednolicenie łączników i znaków interpunkcyjnych,
• przygotowanie wersji tekstu bez polskich znaków,
• rozwinięcie najczęstszych skrótów adresowych,
• rozdzielenie formy prawnej od właściwej nazwy firmy.

Dla wyszukiwarki „Łódź” i „Lodz” powinny prowadzić do tego samego zbioru wyników. Nie oznacza to jednak, że należy usuwać polskie znaki z danych źródłowych. Najbezpieczniej przechowywać oryginalną wartość do wyświetlania oraz dodatkową, znormalizowaną wersję używaną do wyszukiwania.

Podobnie trzeba traktować formy prawne. Użytkownik szukający „Alfa Transport” nie powinien być zmuszony do wpisania pełnej nazwy „Alfa Transport spółka z ograniczoną odpowiedzialnością sp.k.”. Elementy takie jak „sp. z o.o.”, „S.A.”, „sp.k.” czy „JDG” mogą mieć niższą wagę niż właściwa nazwa.

Inaczej wygląda sytuacja z numerami. NIP, REGON, kod pocztowy i numer budynku nie powinny korzystać z klasycznego dopasowania rozmytego. Literówka w nazwie firmy jest prawdopodobna, ale zmiana jednej cyfry w NIP-ie może wskazać zupełnie inny podmiot. Dla takich pól lepsze jest dopasowanie dokładne, ewentualnie po wcześniejszym usunięciu spacji i myślników.

Przed uruchomieniem mechanizmów fuzzy należy też przygotować słownik branżowy. W polskich katalogach szczególnie często pojawiają się różne określenia tej samej usługi:

• „mechanik”, „warsztat samochodowy” i „serwis aut”,
• „dentysta”, „stomatolog” i „gabinet stomatologiczny”,
• „księgowa”, „biuro rachunkowe” i „usługi księgowe”,
• „przeprowadzki”, „transport mebli” i „firma przeprowadzkowa”.

To nie są literówki, lecz synonimy. Próba obsłużenia ich samym dystansem edycyjnym da słabe wyniki.

Tolerancję literówek ustawiaj zależnie od długości i rodzaju zapytania

Najczęściej stosowane silniki wyszukiwania mierzą podobieństwo za pomocą dystansu Damerau-Levenshteina. Uwzględnia on dodanie, usunięcie lub zamianę znaku, a także przestawienie dwóch sąsiednich liter. Dzięki temu „stomatolgo” może zostać dopasowane do „stomatolog”.

W Elasticsearch i OpenSearch ustawienie fuzziness: AUTO stosuje prostą zasadę:

• słowa o długości 0–2 znaków muszą pasować dokładnie,
• słowa o długości 3–5 znaków dopuszczają jedną zmianę,
• słowa dłuższe niż 5 znaków dopuszczają dwie zmiany.

To rozsądny punkt startowy, ale nie gotowa konfiguracja katalogu. Dwie zmiany w krótkiej nazwie mogą rozszerzyć wyniki zbyt mocno. Nazwy takie jak „Dom”, „Max”, „Lux” czy „Med” występują w tysiącach firm i powinny być traktowane ostrożniej niż długie określenia branżowe.

W praktyce dobrze działa hierarchia zapytań:

1. Dokładna nazwa firmy otrzymuje najwyższą punktację.
2. Dokładne dopasowanie po normalizacji, na przykład bez polskich znaków, trafia niżej.
3. Dopasowanie prefiksowe obsługuje niedokończone słowo.
4. Dopasowanie rozmyte uruchamia się jako warstwa ratunkowa.
5. Opis działalności ma niższą wagę niż nazwa, kategoria i lokalizacja.

Przykładowo zapytanie „Auto-Mat” powinno najpierw pokazać firmę o dokładnie takiej nazwie, a dopiero dalej przedsiębiorstwa zawierające słowa „auto” lub „mat”. Fuzzy nie może wyprzedzać dopasowania dokładnego, ponieważ wtedy popularna firma o podobnej nazwie potrafi zepchnąć właściwy rekord poza pierwszy ekran.

W wyszukiwaniu wielopolowym warto nadać polom różne wagi. Praktyczny punkt wyjścia może wyglądać następująco:

• nazwa firmy: waga 5,
• nazwa handlowa: waga 4,
• główna kategoria: waga 3,
• miejscowość i dzielnica: waga 2–3,
• opis działalności: waga 1.

Nie są to wartości uniwersalne. Trzeba je sprawdzić na danych z konkretnego katalogu. Jeżeli wiele firm ma generyczne nazwy, takie jak „Expert”, „Partner” lub „Premium”, kategoria i lokalizacja powinny mieć większy wpływ na kolejność wyników.

Szczególnej kontroli wymaga parametr określający liczbę rozwijanych wariantów słowa. Każda dodatkowa literówka zwiększa liczbę możliwych kombinacji. Przy popularnym zapytaniu oraz dużym indeksie zbyt wysoki limit ekspansji podnosi zużycie procesora i wydłuża czas odpowiedzi. Nie warto więc uruchamiać dwóch błędów dla każdego tokenu bez ograniczeń.

Dla wyszukiwarki katalogowej rozsądnym celem operacyjnym jest czas odpowiedzi p95 poniżej 200–300 ms, liczony po stronie serwera wyszukiwania. Autouzupełnianie powinno reagować szybciej, najlepiej w granicach 100–150 ms, ponieważ każde opóźnienie jest widoczne podczas pisania. Są to cele projektowe, nie gwarantowane parametry silnika — wynik zależy od liczby dokumentów, długości pól, sprzętu, obciążenia i konfiguracji indeksu.

Autouzupełniania nie należy budować przez dodanie symbolu wieloznacznego do każdego zapytania. Przy większej bazie jest to kosztowne i trudne do kontrolowania. Lepszym rozwiązaniem są prefiksy albo edge n-gramy, czyli tokeny tworzone od początku słowa. Dla wyrazu „hydraulik” indeks może zawierać formy „hyd”, „hydr”, „hydra” i kolejne. Minimalna długość prefiksu na poziomie 2 znaków często generuje zbyt dużo przypadkowych trafień; w katalogach firm bezpieczniej rozpocząć podpowiedzi po wpisaniu 3 znaków.

Jakość sprawdzaj na prawdziwych zapytaniach, nie na kilku ręcznych przykładach

Najdroższy błąd powstaje wtedy, gdy zespół ocenia wyszukiwarkę na podstawie pięciu poprawnie wpisanych nazw. Literówki ujawniają się dopiero w logach: użytkownicy pomijają polskie znaki, łączą wyrazy, wpisują nazwę dzielnicy zamiast miasta, mylą kolejność liter albo szukają usługi potocznym określeniem.

Do testów należy przygotować co najmniej cztery grupy zapytań:

• poprawne nazwy firm,
• nazwy zawierające jedną i dwie literówki,
• zapytania branżowo-lokalizacyjne, na przykład „elektryk Ursynów”,
• zapytania trudne: skróty, nazwy bez polskich znaków, błędne spacje i potoczne synonimy.

Dla katalogu mającego kilkadziesiąt tysięcy rekordów sensowny pierwszy zestaw testowy powinien zawierać minimum 200–300 rzeczywistych zapytań. Przy większym ruchu lepiej zebrać 1000 lub więcej fraz z logów, ręcznie oznaczyć oczekiwane wyniki i używać tego zestawu przy każdej zmianie konfiguracji.

Nie wystarczy mierzyć, czy właściwa firma „gdzieś się znalazła”. Trzeba sprawdzać:

• czy oczekiwany rekord znalazł się w pierwszej trójce,
• czy pierwsze dziesięć wyników dotyczy właściwej branży,
• jaki odsetek zapytań kończy się pustą listą,
• po jakich frazach użytkownicy natychmiast zmieniają zapytanie,
• czy kliknięcie następuje w pierwszy wynik, czy dopiero w kolejne,
• ile zapytań generuje bardzo dużą liczbę słabo powiązanych rekordów.

Przydatnym wskaźnikiem jest zero-results rate, czyli udział zapytań bez wyników. Sam spadek tego parametru nie oznacza jeszcze sukcesu. Można łatwo zejść niemal do zera, ustawiając bardzo luźne dopasowanie, ale użytkownicy dostaną wtedy przypadkowe firmy. Dlatego wskaźnik trzeba analizować razem z kliknięciami i pozycją wybranego wyniku.

W katalogu lokalnym ważna jest również kolejność geograficzna. Firma z właściwej branży oddalona o 300 km nie powinna automatycznie wygrywać z nieco słabiej dopasowanym przedsiębiorstwem z tej samej dzielnicy. Lokalizacja może działać jako filtr albo składnik rankingu. Filtr jest bezpieczniejszy, gdy użytkownik jawnie wybrał miasto. Ranking odległościowy lepiej sprawdza się przy wyszukiwaniu „w pobliżu”.

Trzeba też zdecydować, co zrobić po wpisaniu miejscowości, której nie ma w katalogu. Pokazanie pustej strony jest najprostszym, ale zwykle najgorszym rozwiązaniem. Lepszy komunikat powinien wyjaśnić, że w wybranej lokalizacji nie znaleziono firm, i zaproponować wyniki z sąsiednich miejscowości — wyraźnie oznaczone, a nie wymieszane z lokalnymi.

Przy mniejszym katalogu mechanizm można zbudować bez osobnego klastra wyszukiwarki. PostgreSQL z rozszerzeniem pg_trgm obsługuje podobieństwo trigramowe oraz indeksy GIN i GiST. To rozsądna opcja, gdy baza liczy od kilku do kilkuset tysięcy stosunkowo krótkich rekordów, ruch nie jest ekstremalny, a zespół chce ograniczyć liczbę utrzymywanych usług. Minusem jest większa ilość własnej pracy przy rankingu, synonimach, analizie językowej i autouzupełnianiu.

Elasticsearch lub OpenSearch daje większą kontrolę nad analizatorami, wagami pól, fuzzy matchingiem i n-gramami, ale oznacza dodatkową infrastrukturę, reindeksację oraz pilnowanie synchronizacji z główną bazą. Najbardziej irytujący problem pojawia się po zmianie mapowania: wielu ustawień analizatora nie da się bezpiecznie zmienić w istniejącym polu, więc trzeba utworzyć nowy indeks, przepisać dane i przełączyć alias.

Silniki takie jak Meilisearch mają tolerancję literówek włączoną domyślnie i pozwalają określić minimalną długość słowa dla jednego oraz dwóch błędów. Aktualne ustawienia domyślne rozpoczynają dopuszczanie jednego błędu od 5 znaków, a dwóch od 9 znaków. To przyspiesza uruchomienie projektu, lecz również wymaga strojenia — zwłaszcza dla krótkich nazw marek, akronimów, kodów i nazw miejscowości.

Niezależnie od technologii trzeba prowadzić listę słów, dla których literówki są wyłączone. Powinny się na niej znaleźć przede wszystkim:

• krótkie marki i akronimy,
• NIP, REGON i KRS,
• kody pocztowe,
• oznaczenia modeli,
• nazwy składające się z dwóch lub trzech znaków,
• wyrażenia, których rozmycie regularnie daje mylące wyniki.

Nie da się zagwarantować, że fuzzy matching zawsze odgadnie intencję człowieka. Można natomiast ograniczyć liczbę pustych ekranów i przypadkowych odpowiedzi, jeżeli każda zmiana będzie oceniana na stałym zestawie testowym.

Więcej informacji na: poadresie.pl

FAQ

Czy wyszukiwarka powinna tolerować dwie literówki w każdym słowie?
Nie. Dwie zmiany mają sens głównie dla dłuższych wyrazów. W krótkich nazwach firm i miejscowości mogą prowadzić do zupełnie innych rekordów.

Czy usuwanie polskich znaków wystarczy do obsługi błędnych zapytań?
Nie. Normalizacja „Łódź” do „lodz” rozwiązuje tylko problem znaków diakrytycznych. Nie obsłuży przestawionych liter, brakującego znaku, synonimów ani błędnego podziału wyrazów.

Czy PostgreSQL wystarczy do wyszukiwarki katalogu firm?
Tak, szczególnie na początku projektu. pg_trgm pozwala wdrożyć wyszukiwanie podobnych nazw bez osobnego silnika. Przy rozbudowanym autouzupełnianiu, wielu polach, synonimach i skomplikowanym rankingu Elasticsearch, OpenSearch lub Meilisearch zwykle daje większą kontrolę.

Czy fuzzy matching należy stosować do adresów?
Do nazw ulic i miejscowości — tak, ale z ograniczeniami. Do numerów budynków, kodów pocztowych i identyfikatorów firm lepsze jest dopasowanie dokładne po normalizacji formatu.

Od ilu znaków uruchamiać podpowiedzi?
Najczęściej od trzech. Podpowiedzi po jednym lub dwóch znakach generują dużo przypadkowych wyników i niepotrzebnie obciążają silnik, szczególnie przy dużym katalogu.

Jak często aktualizować indeks?
Zmiany danych firmy powinny trafiać do indeksu w ciągu kilku minut. Pełna reindeksacja jest potrzebna po zmianie analizatora, sposobu tokenizacji albo struktury pól. Warto wykonywać ją do nowego indeksu i przełączać alias dopiero po kontroli liczby dokumentów oraz testach zapytań.

Pierwszy krok jest jednoznaczny: wyciągnij z logów 200 najczęstszych zapytań i sprawdź, które z nich nie zwracają właściwej firmy w pierwszej trójce wyników. Dopiero na tej podstawie zmieniaj fuzziness, wagi pól i synonimy. Włączanie coraz luźniejszego dopasowania bez takiego zestawu testowego to błąd, który należy usunąć w pierwszej kolejności.