Jak postavit interní AI vyhledávač s Elasticsearch: praktický návod pro firemní dokumenty, know-how a podporu

Firmy mají často víc znalostí, než dokážou reálně používat. Leží v PDF dokumentech, složkách na serveru, SharePointu, smlouvách, technických manuálech, zápisech ze schůzek, e-mailech, interních směrnicích a starých projektových adresářích. Problém není v tom, že informace neexistují. Problém je v tom, že se k nim lidé nedostanou dost rychle, nedokážou odlišit aktuální zdroj od staré verze a při rozhodování ztrácejí čas ručním dohledáváním.

Interní AI vyhledávač kombinující Elasticsearch a generativní AI je praktický způsob, jak tento problém řešit. Elasticsearch umí silné fulltextové vyhledávání, filtrování, relevance scoring a práci s metadaty. AI k tomu přidává sémantické porozumění, práci s přirozeným jazykem, shrnutí nalezených pasáží a schopnost odpovědět uživateli s odkazy na zdroje. Důležité ale je, aby se z toho nestal jen „chat nad dokumenty“. Správný návrh kombinuje klasické hledání, vektorové hledání, oprávnění, citace a měření kvality.

Nejlepší start není indexovat celou firmu najednou. První verze by měla řešit jeden konkrétní problém: technická podpora hledá manuály, obchod připravuje briefingy, HR odpovídá na interní dotazy, právní tým dohledává smluvní ustanovení nebo servis hledá podobné incidenty. Jakmile je jasný use case, dá se navrhnout datový tok, index, retrieval strategie a pravidla odpovědnosti. Právě tento článek je návod, jak takový systém navrhnout rozumně.

Jak se AI vyhledávání liší od běžného fulltextu

Klasický fulltext funguje dobře, když uživatel zná správná slova. Pokud hledá přesný název produktu, číslo smlouvy, zkratku normy nebo chybovou hlášku, Elasticsearch s BM25 scoringem často najde správné dokumenty velmi dobře. Problém nastává ve chvíli, kdy uživatel nezná terminologii, ptá se obecně nebo hledá význam, ne přesné slovo. Dotaz „jak řešíme reklamace u partnerů“ nemusí obsahovat stejná slova jako dokument „postup pro B2B vratky a servisní eskalace“.

Právě tady pomáhá sémantické neboli vektorové vyhledávání. Dokumenty a dotazy se převádějí na embeddingy, tedy číselné reprezentace významu. Díky tomu systém najde podobný obsah i tehdy, když se slova neshodují přesně. To je užitečné u interních znalostních bází, technické dokumentace, smluv, servisních poznámek a onboarding materiálů. Samotná vektorová vrstva ale není všelék. U přesných kódů, čísel, názvů produktů, paragrafů a zkratek často stále vyhrává fulltext.

Proto dává pro firemní vyhledávač největší smysl hybridní přístup. Elasticsearch může kombinovat klasické fulltextové hledání, vektorové hledání a techniky jako reciprocal rank fusion, které spojí různé typy výsledků do jednoho pořadí. Prakticky to znamená, že uživatel nemusí přemýšlet, jestli se ptá „fulltextově“ nebo „sémanticky“. Systém zkusí obě cesty, vybere kandidáty a teprve potom nad nimi AI připraví odpověď.

Důležité je rozlišovat dvě věci: vyhledání a odpověď. Elasticsearch by měl nejdřív najít relevantní části dokumentů. LLM by až potom mělo z nalezeného kontextu vytvořit odpověď, ideálně s odkazy na zdroje. Pokud se tento krok přeskočí a model odpovídá bez pevného kontextu, roste riziko halucinací. Interní AI vyhledávač má být konzervativní: raději říct „nenašel jsem dostatečný zdroj“ než sebevědomě vytvořit nepodloženou odpověď.

Doporučená architektura: Elasticsearch, embeddingy a LLM

První vrstvou jsou připravená data. Systém se napojí na souborový server, síťové úložiště, SharePoint, Google Drive, systém pro správu dokumentů, databázi nebo na výstupy z různých aplikací.

Druhou vrstvou je zpracování a čištění dokumentů. Soubory ve formátech PDF, DOCX, HTML, e-maily a tabulky je potřeba převést do textové podoby, rozdělit na smysluplné části a zároveň zachovat důležité doplňující údaje, například název dokumentu, autora, datum, verzi nebo umístění souboru.

Třetí vrstvou je uložení do vyhledávacího systému Elasticsearch. Každá část dokumentu by měla obsahovat samotný text, číselnou reprezentaci významu textu, název dokumentu, odkaz nebo cestu k souboru, autora, datum, verzi, typ dokumentu, oddělení a pravidla přístupu.

Čtvrtou vrstvou je vyhledání relevantních částí dokumentů. Dotaz uživatele se vyhodnotí dvěma způsoby: klasickým fulltextovým hledáním a významovým hledáním podle obsahu. Výsledky se následně spojí, případně se ještě seřadí podle relevance. U technických, právních nebo jinak citlivých dokumentů se často vyplatí použít také filtry podle doplňujících údajů, například podle oddělení, jazyka, typu dokumentu, data platnosti, produktové řady nebo zákaznického segmentu. Tím se výrazně zvyšuje přesnost odpovědí a snižuje množství nerelevantních výsledků.

Pátou vrstvou je vytvoření odpovědi. Jazykový model nedostane celý firemní archiv, ale pouze několik vybraných pasáží, které byly nalezeny jako nejvhodnější. Úkolem modelu není domýšlet si chybějící informace, ale srozumitelně vysvětlit nalezený obsah, porovnat zdroje, shrnout hlavní body a upozornit na případnou nejistotu. Výstup by měl obsahovat odkazy na původní dokumenty, ideálně i na konkrétní použité pasáže. U citlivých procesů je vhodné nastavit režim, ve kterém umělá inteligence pouze připraví návrh odpovědi a člověk ho před odesláním schválí.

Číselné reprezentace významu textu lze vytvářet různými způsoby. Elasticsearch má vlastní možnosti pro významové vyhledávání a napojení na modely pro zpracování textu, zároveň je možné použít i externí modely. Pro firemní rozhodnutí však není nejdůležitější konkrétní značka modelu. Podstatnější je, zda celé řešení zvládne vícejazyčné dokumenty, průběžné aktualizace, uživatelská oprávnění, sledování nákladů a pravidelné testování kvality výsledků.

Use case: kde interní AI vyhledávač pomůže nejrychleji

Prvním silným příkladem využití je interní podpora pro zaměstnance. Zaměstnanec se může zeptat, jak založit požadavek, jak funguje konkrétní benefit, kde najde šablonu smlouvy nebo jak postupovat při reklamaci. Vyhledávač s umělou inteligencí dohledá příslušné interní směrnice, návody a často kladené otázky a připraví odpověď včetně odkazu na zdroj. Personální, IT nebo provozní tým tak může výrazně snížit počet opakovaných dotazů a noví zaměstnanci se rychleji zorientují.

Druhým příkladem je obchod a péče o zákazníky. Před schůzkou se zákazníkem může systém projít nabídky, zápisy z jednání, servisní historii, dodatky ke smlouvám a projektové soubory a připravit stručný přehled. Obchodník se nemusí ptát „najdi dokument X“, ale může položit otázku „co bych měl vědět před schůzkou s tímto zákazníkem“. Přínos je v tom, že systém propojí informace z více míst a zároveň jasně ukáže, z jakých dokumentů vychází.

Třetím příkladem je technická podpora a servis. Uživatel zadá příznak problému, chybovou hlášku nebo obecný popis závady. Elasticsearch najde přesné výskyty chybových kódů a příslušných manuálů, významové vyhledávání dohledá podobné případy a umělá inteligence připraví návrh dalšího postupu. Technik má stále poslední slovo, ale nemusí ručně procházet desítky souborů PDF, starých poznámek a servisních záznamů. Právě zde lze často nejrychleji proměnit archiv dokumentace ve skutečnou provozní výhodu.

Čtvrtým příkladem je právní práce a kontrola souladu s pravidly. Vyhledávač s umělou inteligencí může pomoci najít podobná smluvní ustanovení, porovnat různé verze smluv, upozornit na rizikové formulace nebo ověřit, zda dokument odpovídá interní šabloně. V této oblasti je ale nutná opatrnost. Umělá inteligence by neměla dělat konečné právní rozhodnutí. Může však výrazně urychlit první orientaci v dokumentech a připravit kvalitní podklady pro člověka, který rozhodne.

Bezpečnost, oprávnění a kvalita odpovědí

Interní AI vyhledávač musí od začátku respektovat oprávnění. Pokud uživatel nemá přístup ke složce nebo dokumentu, nesmí se k obsahu dostat ani přes AI odpověď. To znamená promítnout access control do indexu i do dotazování. U některých systémů stačí dokument filtrovat podle rolí, u jiných je potřeba použít detailnější oprávnění podle uživatele, týmu nebo dokumentové klasifikace.

Druhé bezpečnostní pravidlo je práce se zdroji. Každá odpověď by měla ukázat, z čeho vychází: název dokumentu, datum, typ zdroje a ideálně konkrétní pasáž. Pokud AI nedokáže zdroj ukázat, neměla by se odpověď používat pro důležitá rozhodnutí. To platí zvlášť u právních, finančních, personálních a zákaznicky citlivých témat.

Třetí pravidlo je testování kvality. Nestačí nasadit vyhledávač a spoléhat, že se výsledky „nějak“ zlepší. Firma by měla mít sadu reálných dotazů a očekávaných dokumentů. U každého dotazu se vyhodnocuje, zda systém našel správné zdroje, zda odpověď odpovídá dokumentům a zda nevynechal důležitou výjimku. Tato evaluační sada je pro interní AI vyhledávání stejně důležitá jako testy pro software.

Čtvrté pravidlo je řízení aktualizací. Interní dokumenty se mění. Systém musí umět reindexovat změněné soubory, odstraňovat neplatné verze a hlídat, kdy zdroj zestárl. Mnoho projektů selže ne proto, že by AI byla slabá, ale proto, že odpovídá ze starých nebo nekvalitních dat.

Postup první implementace

První krok je vybrat jeden use case. Ne „vyhledávání ve všech dokumentech“, ale například „servisní technik najde správný postup do dvou minut“ nebo „obchodník dostane briefing k zákazníkovi před schůzkou“. Druhý krok je vybrat omezený datový rozsah: jen finální manuály, platné směrnice, aktuální smluvní šablony nebo ověřené znalostní články.

Třetí krok je navrhnout index. Každý dokument nebo chunk musí nést metadata: zdroj, vlastník, datum, verze, typ dokumentu, oddělení, jazyk, citlivost a přístupová pravidla. Čtvrtý krok je zprovoznit hybridní retrieval: BM25, vektorové hledání, metadata filtry a spojení výsledků. Pátý krok je přidat LLM odpověď, ale jen nad nalezeným kontextem a se zdroji.

Šestý krok je evaluace. Připravte 30 až 100 reálných dotazů, které lidé skutečně kladou. U každého ověřte, zda systém našel správné zdroje a zda odpověď pomohla. Sedmý krok je provoz: logování dotazů, sběr feedbacku, pravidelné reindexace a úprava relevance. Teprve potom má smysl rozšiřovat systém na další oddělení.

FAQ