Vyhľadávanie vo firemnej aplikácii: full-text, filtre a relevancia výsledkov

Vyhľadávacie pole je v zadaní takmer vždy jedna veta: „a nech sa dá aj vyhľadávať". V realite je to jedna z častí aplikácie, kde sa najviac líši to, čo si zadávateľ predstavuje, od toho, čo sa dá reálne postaviť za rozumný čas — a kde sa najčastejšie podceňuje, že samotné vyhľadávanie je len polovica úlohy. Tá druhá je vedieť, či fungovalo dobre.

Nie každá aplikácia potrebuje špeciálny vyhľadávací nástroj. Ak má tabuľka stovky až nízke tisícky záznamov a hľadá sa podľa presného alebo takmer presného textu — meno zákazníka, číslo objednávky, kód produktu — obyčajný databázový dopyt (SQL LIKE alebo ekvivalent) stačí a je najjednoduchšie riešenie na údržbu.

Problém nastáva pri troch veciach naraz, a stačí, aby platila čo aj len jedna:

• objem — desaťtisíce až milióny záznamov, kde LIKE prestáva byť rýchly,
• preklepy a tvary slov — používateľ napíše „reklamacia" bez diakritiky alebo v inom páde a očakáva, že sa nájde „reklamácie",
• relevancia — pri viacerých zhodách treba vedieť, ktorá je najdôležitejšia, nie len že sa zhoduje.

Full-textové vyhľadávanie (napríklad Postgres tsvector, Elasticsearch, Meilisearch, Algolia) rozdeľuje text na slová, ignoruje bežné spojky, pozná tvary slov a vie povedať, ktorý dokument sa zhoduje najviac. Toto je presne to, čo LIKE nedokáže — hľadá doslovný reťazec, nie význam.

Rozdiel je citeľný pri prvom preklepe alebo pri hľadaní vo voľnom texte, ako je popis produktu alebo obsah dokumentu. Pri štruktúrovaných poliach ako dátum, stav alebo kategória plný text nič nerieši — tam patrí filter, nie hľadanie.

Častá chyba v návrhu je snažiť sa vyriešiť oboje jedným poľom. Filter zužuje presne — „objednávky za posledný mesiac v stave vybavené" má jednoznačnú odpoveď a používateľ vie, čo dostane. Vyhľadávanie odpovedá na neisté a nepresné zadanie — používateľ si nie je istý presným znením, len tuší, čo hľadá.

Dobrý dizajn kombinuje oboje: filtre ako samostatné, jasne popísané ovládacie prvky a vyhľadávacie pole na voľný text vedľa nich, nie namiesto nich. Keď sa filter skryje do vyhľadávacieho poľa („stav:vybavené dátum:2026"), používateľ musí poznať syntax, ktorú mu nikto nevysvetlil.

Relevancia sa nedá odhadnúť pri návrhu, dá sa len merať po nasadení. Tri signály, ktoré sa oplatí sledovať:

1. Dopyty bez výsledku. Ak sa opakovane hľadá niečo, čo systém nenájde, buď dáta chýbajú, alebo hľadanie nerozumie bežnému spôsobu, akým to ľudia píšu.
2. Opakované hľadanie s iným výrazom. Ak používateľ hľadá „faktúra", nenájde, čo chce, a hneď skúša „invoice" alebo „faktúry", je to signál, že prvý pokus zlyhal — aj keď formálne vrátil výsledky.
3. Na čo sa kliká. Ak sa takmer vždy klikne na tretí alebo štvrtý výsledok, nie na prvý, poradie podľa relevancie je nastavené zle.

Bez tohto merania sa vyhľadávanie ladí podľa dojmu, a dojem tvorcu sa systematicky líši od skúsenosti bežného používateľa — tvorca vie, čo má hľadať, a píše to inak.

Sémantické vyhľadávanie a RAG (retrieval-augmented generation) riešia inú otázku než klasický full-text — nie „nájdi presne tento reťazec", ale „nájdi obsahovo podobné veci, aj keď použili iné slová". To je užitočné pri hľadaní v dokumentácii alebo pri otázke typu „aké zmluvy máme s podobnými podmienkami ako táto", kde presná zhoda textu nič nerieši.

Ale nie je to náhrada bežného vyhľadávania — je to doplnok pre inú kategóriu dopytov. Systém, ktorý potrebuje presne nájsť objednávku číslo 48213, nepotrebuje sémantické hľadanie, potrebuje index na stĺpci. Princíp aj limity sémantického vyhľadávania nad firemnými dátami sme rozobrali v článku o RAG a firemnej dokumentácii.

• Aký objem dát sa bude prehľadávať a ako rýchlo rastie.
• Aké typy dopytov sa reálne očakávajú — presné ID, voľný text, alebo oboje.
• Ktoré polia patria do filtra a ktoré do voľného hľadania.
• Ako sa bude merať, či vyhľadávanie funguje — bez toho sa ladenie nedá overiť.
• Ako často sa dáta menia, lebo full-textový index treba pri zmenách priebežne aktualizovať, nie len raz vybudovať.

Vyhľadávanie vo firemnej aplikácii nie je jedna funkcia, ale rozhodnutie medzi troma nástrojmi — databázovým dopytom, full-textovým vyhľadávaním a filtrami — podľa toho, aký typ otázky používateľ kladie. Kvalita sa nedá odhadnúť pri návrhu, len merať po nasadení, cez prázdne výsledky a opakované hľadania.

Voľba konkrétneho nástroja závisí od objemu dát, typu dopytov a rozpočtu na údržbu. Ak riešite vyhľadávanie vo vlastnej aplikácii, prejdeme si konkrétnu situáciu na nezáväznej konzultácii alebo si pozrite naše riešenia v oblasti vývoja.