Co zrobić, gdy wyszukiwarka katalogu nie rozpoznaje odmiany nazwy miasta

Problem zwykle wygląda niewinnie: użytkownik wpisuje „firmy w Białymstoku”, ale katalog przechowuje lokalizację jako „Białystok” i nie pokazuje żadnych wyników. Podobnie dzieje się przy zapytaniach „z Rzeszowa”, „w Toruniu”, „pod Wrocławiem” albo „dla mieszkańców Łodzi”. Rekordy istnieją, lecz wyszukiwarka porównuje słowa zbyt dosłownie.

To nie jest błąd danych adresowych, tylko najczęściej brak normalizacji zapytania, niewłaściwa konfiguracja indeksu albo próba wyszukiwania odmienionej nazwy w polu, które zawiera wyłącznie formę podstawową. W praktyce trzeba rozdzielić dwie rzeczy: nazwę miasta przechowywaną w bazie oraz sposób, w jaki użytkownik może ją wpisać.

Najpierw ustal, na którym etapie znika wynik

Nie należy zaczynać od dopisywania wszystkich odmian miast do bazy. To szybka poprawka, ale po kilku miesiącach tworzy bałagan: jeden rekord ma „Kraków”, drugi „w Krakowie”, trzeci „Krakowie”, a filtry i raporty przestają być spójne.

Najpierw trzeba wykonać prosty test diagnostyczny. Dla jednego miasta sprawdź kolejno:

• wyszukiwanie formy podstawowej, np. „Poznań”;
• wyszukiwanie formy odmienionej, np. „w Poznaniu”;
• wyszukiwanie samego rdzenia, np. „Poznan” bez polskiego znaku;
• wyszukiwanie z dodatkową frazą, np. „hydraulik w Poznaniu”;
• filtrowanie miasta z listy zamiast wpisywania go ręcznie.

Jeżeli „Poznań” zwraca wyniki, a „Poznaniu” już nie, dane najprawdopodobniej są poprawne. Problem znajduje się w analizie tekstu zapytania. Jeżeli nie działa również forma podstawowa, trzeba sprawdzić indeksowanie, nazwę pola, typ dopasowania oraz to, czy rekord w ogóle został dodany do indeksu.

W katalogach opartych na Elasticsearch lub OpenSearch warto skontrolować analyzer przypisany do pola miejscowości. Przy PostgreSQL znaczenie ma sposób użycia LIKE, ILIKE, rozszerzenia pg_trgm lub wyszukiwania pełnotekstowego. W prostych wdrożeniach opartych na MySQL problem często wynika z porównania pełnej frazy do pojedynczej wartości zapisanej w kolumnie city.

Najbardziej miarodajny test to podgląd zapytania wysyłanego przez formularz. Interfejs może wyświetlać tekst „w Gdańsku”, ale do API przekazywać całą frazę jako jeden ciąg, bez rozpoznania, że „Gdańsku” oznacza „Gdańsk”. Wtedy zmiana tekstu przycisku lub etykiety niczego nie naprawi.

Trzeba też sprawdzić mniej oczywiste przyczyny:

• spacje na początku lub końcu wartości;
• nierozróżniane przez użytkownika łączniki, np. „Bielsko Biała” i „Bielsko-Biała”;
• polskie znaki, np. „Lodz” zamiast „Łódź”;
• dzielnice wpisywane zamiast miasta, np. „Mokotów” zamiast „Warszawa”;
• nazwy historyczne, skrócone i potoczne;
• rekordy zapisane jako gmina, powiat albo miejscowość pocztowa zamiast faktycznego miasta.

Priorytetem jest ustalenie, czy wyszukiwarka nie rozpoznaje odmiany, czy w ogóle nie przeszukuje właściwego pola. Te dwa problemy wyglądają podobnie dla użytkownika, ale wymagają zupełnie innych poprawek.

Normalizacja, słownik odmian czy wyszukiwanie przybliżone

Najbezpieczniejszy model polega na przechowywaniu w bazie jednej, urzędowej formy nazwy, na przykład „Zielona Góra”, oraz przekształcaniu zapytania użytkownika przed rozpoczęciem wyszukiwania. Wartość wyświetlana i indeksowana pozostaje dzięki temu spójna.

Dla polskich nazw miejscowości można zastosować trzy mechanizmy.

1. Słownik aliasów i odmian

To rozwiązanie daje największą kontrolę. Dla miasta można zapisać zestaw wariantów:

• Kraków;
• Krakowie;
• Krakowa;
• Krakowem;
• krakowski;
• Cracow.

Po wpisaniu dowolnego wariantu system sprowadza zapytanie do jednej wartości kanonicznej: „Kraków”.

Słownik dobrze działa w katalogach obejmujących określony obszar, na przykład wszystkie miasta powiatowe, stolice województw lub miejscowości, w których faktycznie działają dodane firmy. Nie trzeba od razu opracowywać pełnej listy ponad 100 tys. polskich nazw miejscowych. Rozsądniej zacząć od miejscowości występujących w bazie oraz od 100–300 najczęściej wyszukiwanych lokalizacji.

Niedogodność jest konkretna: słownik trzeba utrzymywać. Nowe miasta, dzielnice i błędne warianty pojawiają się wraz z ruchem użytkowników. Bez analizy zapytań lista szybko przestaje odpowiadać rzeczywistym problemom.

2. Analiza morfologiczna

Lematyzator próbuje sprowadzić wyraz odmieniony do formy podstawowej. Dzięki temu „Warszawie”, „Warszawy” i „Warszawą” mogą zostać powiązane z hasłem „Warszawa”.

To rozwiązanie jest wygodne przy dużych zbiorach, ale nie powinno samodzielnie decydować o lokalizacji. Polskie nazwy własne bywają niejednoznaczne. „Tychy”, „Police”, „Koło” czy „Piła” mogą zostać błędnie potraktowane jak wyrazy pospolite. Mechanizm językowy powinien więc działać razem ze słownikiem miejscowości, najlepiej opartym na identyfikatorach TERYT lub innej kontrolowanej bazie lokalizacji.

3. Wyszukiwanie przybliżone

Fuzzy search pomaga przy literówkach takich jak „Wrocaw”, „Rzeszuw” czy „Bialystok”. Nie jest jednak właściwym narzędziem do obsługi odmiany gramatycznej. Zbyt wysoka tolerancja potrafi połączyć różne miejscowości o podobnych nazwach, zwłaszcza przy krótkich hasłach.

Praktyczna granica to zwykle tolerowanie jednej literówki w krótszych nazwach i maksymalnie dwóch w dłuższych, ale dokładne ustawienie zależy od użytego silnika oraz liczby miejscowości w indeksie. Dla nazw takich jak „Koło”, „Hel” czy „Łeba” dopasowanie rozmyte powinno być mocno ograniczone. Przy czterech literach jedna zmiana stanowi już 25% całej nazwy.

Najlepszy porządek działania jest następujący:

1. usunięcie przyimków, takich jak „w”, „we”, „z”, „ze”, „pod”;
2. normalizacja wielkości liter, spacji i łączników;
3. rozpoznanie pełnego aliasu lub odmiany w słowniku;
4. sprawdzenie formy podstawowej w bazie miejscowości;
5. dopiero na końcu uruchomienie wyszukiwania przybliżonego.

Nie należy automatycznie usuwać polskich znaków z wartości wyświetlanej ani zastępować nimi danych źródłowych. Można utworzyć dodatkowe pole techniczne, dzięki któremu zapytanie „Lodz” znajdzie „Łódź”, ale użytkownik powinien nadal widzieć poprawną nazwę.

Jak wdrożyć poprawkę bez psucia filtrów i adresów

Poprawka powinna działać w warstwie wyszukiwania, a nie zmieniać treść rekordów firm. Adres „ul. Piotrkowska 120, 90-006 Łódź” musi pozostać adresem, a nie zestawem wariantów przygotowanych pod wyszukiwarkę.

W praktyce rekord warto oprzeć na kilku osobnych polach:

• city_name — oficjalna nazwa wyświetlana użytkownikowi;
• city_id — stały identyfikator miejscowości;
• city_normalized — wersja techniczna używana w wyszukiwaniu;
• city_aliases — odmiany, formy potoczne i alternatywne;
• district — dzielnica;
• postal_code — kod pocztowy;
• voivodeship — województwo.

Stały identyfikator jest ważniejszy niż sama nazwa. W Polsce istnieją miejscowości o identycznych lub bardzo podobnych nazwach. Sam tekst „Nowa Wieś” nie wystarcza, by jednoznacznie ustalić lokalizację. Do rozróżnienia potrzebna jest przynajmniej gmina, powiat albo identyfikator z rejestru.

Po rozpoznaniu miasta zapytanie powinno zostać zamienione na filtr po city_id, nie na kolejne porównanie tekstowe. Dzięki temu wpisanie „firmy z Bielska-Białej” może prowadzić do dokładnie tego samego zbioru rekordów co wybór „Bielsko-Biała” z listy.

Trzeba przy tym zachować kolejność wyników. Rekordy z dokładnie rozpoznanego miasta powinny pojawić się przed firmami z okolicy. Promień 20–30 km bywa przydatny dla usług mobilnych, lecz nie powinien włączać się bez informacji dla użytkownika. Kto szuka notariusza w Opolu, może uznać wynik z Brzegu za błąd, mimo że odległość drogowa jest stosunkowo niewielka.

Dobrze skonfigurowany katalog powinien jasno rozróżniać:

• wynik w wybranym mieście;
• wynik w dzielnicy tego miasta;
• wynik w pobliżu;
• firmę obsługującą dany obszar bez lokalnego adresu.

To istotne również z punktu widzenia jakości danych NAP, czyli zgodności nazwy firmy, adresu i numeru telefonu. Analizując sposób prezentacji lokalizacji oraz strukturę wpisów, można porównać rozwiązania stosowane przez katalog NAP – https://poadresie.pl.

Przed publikacją poprawki trzeba przygotować zestaw testów. Minimum to około 30–50 zapytań obejmujących:

• wszystkie przypadki gramatyczne kilku miast;
• nazwy ze znakami diakrytycznymi i bez nich;
• miasta z łącznikiem;
• nazwy wieloczłonowe;
• dzielnice;
• literówki;
• miejscowości o podobnych nazwach;
• frazy z branżą, np. „mechanik z Katowic”;
• zapytania bez miasta;
• zapytania zawierające kilka lokalizacji.

Test „Warszawa działa” nie wystarcza. Trzeba sprawdzić także „Warszawie”, „Warszawy”, „Warszawą”, „W-wa”, „Warszawa Mokotów” oraz błędny wariant „Warszwa”. Każdy przypadek powinien mieć z góry określony oczekiwany wynik. Inaczej zespół będzie oceniał wyszukiwarkę na oko.

Najbardziej irytujący błąd po wdrożeniu normalizacji polega na zbyt agresywnym poprawianiu użytkownika. System rozpoznaje podobne słowo jako nazwę miasta i usuwa je z frazy branżowej. Dlatego mechanizm powinien zmieniać zapytanie dopiero wtedy, gdy rozpoznana lokalizacja znajduje się w kontrolowanym słowniku i osiąga odpowiednio wysoki poziom zgodności.

FAQ

Czy trzeba zapisywać każdą odmianę miasta w rekordzie firmy?
Nie. Rekord powinien zawierać jedną oficjalną nazwę i stały identyfikator miejscowości. Odmiany należy obsługiwać w słowniku aliasów lub w indeksie wyszukiwania.

Czy usunięcie polskich znaków rozwiąże problem?
Rozwiąże wyłącznie część przypadków, na przykład „Lodz” zamiast „Łódź”. Nie połączy automatycznie „Łodzi” z „Łódź” ani „Wrocławiu” z „Wrocław”.

Czy wystarczy włączyć fuzzy search?
Nie. Wyszukiwanie przybliżone pomaga przy literówkach, ale może zwracać błędne miasta. Powinno działać dopiero po sprawdzeniu aliasów, odmian i dokładnych nazw.

Co zrobić z dzielnicami, takimi jak Mokotów lub Wrzeszcz?
Dzielnica powinna mieć własny identyfikator i relację z miastem. Po wpisaniu „Mokotów” system powinien rozpoznać dzielnicę Warszawy, a nie tworzyć osobne miasto.

Czy można automatycznie rozszerzać wyniki na okoliczne miejscowości?
Tak, ale tylko z jasnym oznaczeniem „wyniki w pobliżu”. Rozszerzenie promienia nie powinno udawać dokładnego dopasowania do miasta wskazanego przez użytkownika.

Jak sprawdzić, czy poprawka rzeczywiście działa?
Należy porównać odsetek zapytań bez wyników przed i po wdrożeniu, liczbę ręcznych zmian lokalizacji oraz kliknięcia w wyniki. Trzeba osobno analizować zapytania zakończone zerowym wynikiem, bo to one najszybciej ujawniają brakujące odmiany i aliasy.

Pierwszy krok jest jednoznaczny: sprawdź, czy forma podstawowa miasta zwraca prawidłowe rekordy. Jeżeli tak, nie zmieniaj danych firm. Najpierw dodaj normalizację zapytania i mapowanie odmiany na stały identyfikator miejscowości. Fuzzy search oraz rozszerzanie wyników na okolice zostaw na później — uruchomione zbyt wcześnie zamaskują właściwy błąd i obniżą precyzję wyszukiwarki.