Vyhledávací pole je v zadání téměř vždy jedna věta: „a ať se dá i vyhledávat". V realitě je to jedna z částí aplikace, kde se nejvíc liší to, co si zadavatel představuje, od toho, co se dá reálně postavit za rozumný čas — a kde se nejčastěji podceňuje, že samotné vyhledávání je jen polovina úkolu. Ta druhá je vědět, jestli fungovalo dobře.
Kdy stačí obyčejný dotaz
Ne každá aplikace potřebuje speciální vyhledávací nástroj. Pokud má tabulka stovky až nízké tisíce záznamů a hledá se podle přesného nebo téměř přesného textu — jméno zákazníka, číslo objednávky, kód produktu — obyčejný databázový dotaz (SQL LIKE nebo ekvivalent) stačí a je nejjednodušší řešení na údržbu.
Problém nastává u tří věcí naráz, a stačí, aby platila byť jen jedna:
- objem — desetitisíce až miliony záznamů, kde
LIKEpřestává být rychlý, - překlepy a tvary slov — uživatel napíše „reklamace" bez diakritiky nebo v jiném pádu a očekává, že se najde „reklamací",
- relevance — u více shod je třeba vědět, která je nejdůležitější, ne jen že se shoduje.
Full-text vyhledávání: co doopravdy řeší
Full-textové vyhledávání (například Postgres tsvector, Elasticsearch, Meilisearch, Algolia) rozděluje text na slova, ignoruje běžné spojky, zná tvary slov a umí říct, který dokument se shoduje nejvíc. To je přesně to, co LIKE nedokáže — hledá doslovný řetězec, ne význam.
Rozdíl je citelný při prvním překlepu nebo při hledání ve volném textu, jako je popis produktu nebo obsah dokumentu. U strukturovaných polí jako datum, stav nebo kategorie plný text nic neřeší — tam patří filtr, ne hledání.
| Situace | Vhodný nástroj |
|---|---|
| Přesné ID, kód, číslo objednávky | databázový dotaz |
| Jméno, název s překlepy nebo skloňováním | full-text vyhledávání |
| Datum, stav, kategorie, rozsah cen | filtr |
| Volný text v popisech nebo dokumentech | full-text vyhledávání |
| „Najdi mi smlouvy podobné této" | sémantické vyhledávání (embeddings) |
Filtr a hledání řeší jiný úkol
Častá chyba v návrhu je snažit se vyřešit obojí jedním polem. Filtr zužuje přesně — „objednávky za poslední měsíc ve stavu vyřízeno" má jednoznačnou odpověď a uživatel ví, co dostane. Vyhledávání odpovídá na nejisté a nepřesné zadání — uživatel si není jistý přesným zněním, jen tuší, co hledá.
Dobrý design kombinuje obojí: filtry jako samostatné, jasně popsané ovládací prvky a vyhledávací pole na volný text vedle nich, ne místo nich. Když se filtr skryje do vyhledávacího pole („stav:vyřízeno datum:2026"), uživatel musí znát syntaxi, kterou mu nikdo nevysvětlil.
Jak se pozná, že vyhledávání funguje dobře
Relevance se nedá odhadnout při návrhu, dá se jen měřit po nasazení. Tři signály, které se vyplatí sledovat:
- Dotazy bez výsledku. Pokud se opakovaně hledá něco, co systém nenajde, buď data chybí, nebo hledání nerozumí běžnému způsobu, jakým to lidé píšou.
- Opakované hledání s jiným výrazem. Pokud uživatel hledá „faktura", nenajde, co chce, a hned zkouší „invoice" nebo „faktury", je to signál, že první pokus selhal — i když formálně vrátil výsledky.
- Na co se kliká. Pokud se téměř vždy klikne na třetí nebo čtvrtý výsledek, ne na první, pořadí podle relevance je nastavené špatně.
Bez tohoto měření se vyhledávání ladí podle dojmu, a dojem tvůrce se systematicky liší od zkušenosti běžného uživatele — tvůrce ví, co má hledat, a píše to jinak.
Kde do toho vstupuje AI
Sémantické vyhledávání a RAG (retrieval-augmented generation) řeší jinou otázku než klasický full-text — ne „najdi přesně tento řetězec", ale „najdi obsahově podobné věci, i když použily jiná slova". To je užitečné při hledání v dokumentaci nebo u otázky typu „jaké máme smlouvy s podobnými podmínkami jako tato", kde přesná shoda textu nic neřeší.
Ale není to náhrada běžného vyhledávání — je to doplněk pro jinou kategorii dotazů. Systém, který potřebuje přesně najít objednávku číslo 48213, nepotřebuje sémantické hledání, potřebuje index na sloupci. Princip i limity sémantického vyhledávání nad firemními daty jsme rozebrali v článku o RAG a firemní dokumentaci.
Co si ujasnit před návrhem
- Jaký objem dat se bude prohledávat a jak rychle roste.
- Jaké typy dotazů se reálně očekávají — přesné ID, volný text, nebo obojí.
- Která pole patří do filtru a která do volného hledání.
- Jak se bude měřit, jestli vyhledávání funguje — bez toho se ladění nedá ověřit.
- Jak často se data mění, protože full-textový index je třeba při změnách průběžně aktualizovat, ne jen jednou vybudovat.
Shrnutí
Vyhledávání ve firemní aplikaci není jedna funkce, ale rozhodnutí mezi třemi nástroji — databázovým dotazem, full-textovým vyhledáváním a filtry — podle toho, jaký typ otázky uživatel klade. Kvalita se nedá odhadnout při návrhu, jen měřit po nasazení, přes prázdné výsledky a opakovaná hledání.
Volba konkrétního nástroje závisí na objemu dat, typu dotazů a rozpočtu na údržbu. Pokud řešíte vyhledávání ve vlastní aplikaci, projdeme si konkrétní situaci na nezávazné konzultaci nebo si prohlédněte naše řešení v oblasti vývoje.