Jak rozběhnout interního AI asistenta nad firemními daty

• Kdy má interní AI asistent skutečně smysl
• RAG stručně: jak dostat firemní data do odpovědí AI
• Data rozhodují víc než samotný model
• API model, nebo lokální AI? U bezpečnosti sledujte tok dat
• Jaký výkon firma reálně potřebuje
• Jak vybrat vektorový index bez zbytečné složitosti
• Pilot v šesti krocích
• Nejčastější chyby při zavádění firemního AI asistenta
• Závěr

Kdy má interní AI asistent skutečně smysl

Největší přínos vzniká tam, kde lidé opakovaně hledají odpovědi ve velkém množství firemních materiálů a potřebují vědět, odkud odpověď pochází. Typicky jde o produktové know-how, zákaznickou podporu, interní procesy, technickou dokumentaci, obchodní argumentaci nebo rozsáhlý archiv článků a materiálů.

Dobrý začátek vypadá jednoduše. Firma vybere jeden korpus, jednu skupinu uživatelů a jeden měřitelný problém. Technická podpora může rychleji najít správný postup, obchodní tým dohledat aktuální produktové argumenty a obsahový tým ověřit, co už o daném tématu ve firmě existuje. Úzký pilot pomáhá rychleji ověřit přínos, snížit bezpečnostní rizika a získat jasnější odpověď na otázku, zda má projekt reálnou hodnotu.

Interní AI asistent má největší přínos ve chvíli, kdy se umí opřít o konkrétní firemní zdroje a ukázat, z čeho odpověď vychází. Právě zde přichází na řadu RAG.

RAG stručně: jak dostat firemní data do odpovědí AI

RAG, tedy Retrieval-Augmented Generation, propojuje chytré vyhledávání s jazykovým modelem. Systém nejprve najde relevantní části firemních dokumentů a teprve potom je předá modelu jako kontext pro odpověď. Díky tomu se asistent opírá o konkrétní interní data, uvádí dohledatelné zdroje a dokáže pracovat i s informacemi, které běžný jazykový model nemá ve své obecné znalosti.

Prakticky to funguje tak, že se dokumenty rozdělí na menší části, převedou se na embeddingy a uloží do vektorového indexu. Embedding si lze představit jako číselné vyjádření významu textu. Když se uživatel zeptá na konkrétní věc, systém převede i jeho dotaz na embedding a najde textové úseky s nejbližším významem. Jazykový model potom dostane otázku, nalezené pasáže a instrukci, aby odpověděl pouze z dostupných zdrojů.

Dobře navržená RAG vrstva vytváří nad dokumenty znalostní systém. Umí vyhledat podobné pasáže, upozornit na duplicity a dodat modelu přesný kontext pro odpověď. Z běžné složky dokumentů se tak stává prostředí, se kterým lze pracovat přirozeným jazykem.

Data rozhodují víc než samotný model

U interního asistenta bývá lákavé řešit hlavně výběr jazykového modelu, v praxi však často rozhoduje příprava dat. Pokud má firma v dokumentech duplicity, staré verze, nekonzistentní názvy a nejasná oprávnění, AI tyto problémy nevyřeší – naopak je zviditelní. Model může být výkonný, jenže špatně rozdělené nebo zastaralé podklady povedou k nepřesným odpovědím.

Chunking by měl respektovat přirozenou strukturu dokumentů. U návodů dávají smysl kapitoly, u produktové dokumentace tematické bloky, u znalostní báze otázky a odpovědi, u tabulek vztah mezi hlavičkou a konkrétním řádkem. Příliš dlouhé bloky přinášejí modelu moc šumu, příliš krátké části zase rozbíjejí kontext. Cílem je, aby systém při dotazu našel přesně tu část dokumentu, která nese odpověď.

Stejně důležitá jsou metadata. Ke každému úseku se vyplatí ukládat název dokumentu, datum aktualizace, vlastníka, typ obsahu, jazyk, interní URL, stav platnosti a oprávnění. Metadata pomáhají filtrovat výsledky, vyřadit staré dokumenty, dohledat zdroj odpovědi a zabránit tomu, aby se uživateli zobrazily informace, ke kterým nemá mít přístup.

Kontrolní otázky před spuštěním pilotu

• Máme jasně vybraný korpus dokumentů?
• Víme, kdo za tato data odpovídá?
• Jsou dokumenty aktuální, nebo obsahují staré verze?
• Máme u zdrojů základní metadata a oprávnění?
• Víme, která data mohou odejít do externího API a která musí zůstat lokálně?
• Máme připravené reálné testovací dotazy?
• Víme, jak se bude index aktualizovat po změně dokumentů?
• Máme určené metriky, podle kterých poznáme úspěch pilotu?

První verze nemusí být složitá. Měla by být čistá, dohledatelná a bezpečně ohraničená. Jeden dobře připravený korpus s rozumnými metadaty má pro pilot větší hodnotu než velká hromada dokumentů bez jasného původu a pravidel.

API model, nebo lokální AI? U bezpečnosti sledujte tok dat

Generativní část asistenta může běžet přes externí API, nebo na lokálním modelu ve vlastní infrastruktuře. API model obvykle nabídne velmi dobrou kvalitu odpovědí, rychlejší start a menší provozní starosti. Firma nemusí řešit GPU pro inferenci, aktualizace modelů ani jejich optimalizaci. Tento přístup se hodí pro piloty, méně citlivá data a scénáře, kde je důležitá rychlost nasazení.

Lokální model přináší větší kontrolu nad daty a vyžaduje pečlivější technický návrh. Je potřeba počítat s výkonnou grafickou kartou [PROLINK: grafické karty vhodné pro AI výpočty], dostatečnou VRAM, rychlým úložištěm, správou modelů a monitoringem výkonu. Lokální inference dává smysl hlavně u citlivých dokumentů, obchodního tajemství, neveřejného technického know-how, smluv nebo regulovaných agend.

Klíčový bezpečnostní rozdíl spočívá v tom, co přesně chrání vlastní infrastruktura. Server ve firmě, firewall, autentizace, šifrování a síťová pravidla řeší perimetr – tedy ochranu systému před útočníkem zvenčí a kontrolu nad prostředím, kde aplikace běží. Tato vrstva je nutná pro každý seriózní firemní systém. Tok dat do generativního modelu je samostatné rozhodnutí.

Pokud asistent používá externí LLM přes API, mohou k poskytovateli odejít dotazy uživatelů i dohledané pasáže z interních dokumentů. Vlastní server tuto část nezmění, protože data v takovém scénáři opouštějí firmu až ve chvíli, kdy se posílají do modelu. U citlivých dat proto nestačí konstatovat, že systém běží „u nás". Bezpečnostní návrh musí říct, které scénáře smějí používat externí API a které mají běžet na lokálním LLM.

V praxi často vychází nejlépe hybridní přístup. Embedding a vektorový index běží lokálně, takže firemní korpus kvůli vyhledávání neopouští organizaci. Generování odpovědí se následně rozdělí podle citlivosti. Méně rizikové scénáře mohou využít API, důvěrná nebo regulovaná data zůstávají u lokálního modelu.

Jaký výkon firma reálně potřebuje

Hardwarové požadavky závisí na velikosti korpusu, frekvenci aktualizací a tom, zda firma chce provozovat lokální model. Menší pilot nad stovkami nebo nižšími tisíci dokumentů zvládne i výkonnější běžná pracovní stanice [PROLINK: pracovní stanice pro AI / výkonné workstation]. S desetitisíci dokumentů, častými aktualizacemi nebo lokální inferencí začíná hrát roli GPU, kapacita RAM, rychlost úložiště a provozní rezerva.

Praktické rozdělení lze chápat ve třech velikostních třídách. Malé nasazení znamená stovky až jednotky tisíc dokumentů, kde často stačí CPU, rychlé NVMe úložiště [PROLINK: NVMe SSD a firemní úložiště] a jednoduchý lokální index. Střední třída už pracuje s desetitisíci dokumentů, takže se vyplatí GPU pro rychlejší embedding a promyšlenější práce s indexem. Velká nasazení se statisíci dokumentů obvykle potřebují dedikovanou vektorovou databázi, inkrementální reindexaci, více paměti, monitoring a provozní disciplínu podobnou jiným firemním systémům.

Z interní praxe nad středně velkým korpusem víme, že rozdíl mezi CPU a GPU už není akademický detail. Reálný korpus s 25 106 dokumenty, vícejazyčným embedding modelem multilingual-e5-base a FAISS HNSW indexem vytvoří index o velikosti ve stovkách MB. Příprava takového indexu může na běžném CPU trvat hodiny, zatímco s výkonnou grafickou kartou typu RTX 4080 [PROLINK: grafické karty vhodné pro AI výpočty] se může zkrátit na desítky minut. To je rozdíl mezi jednorázovým experimentem a systémem, který lze pohodlně ladit, obnovovat a rozšiřovat.

GPU se nejvíce projeví při tvorbě embeddingů a u lokálních modelů. Převod dokumentů na embeddingy lze udělat i na CPU, u většího korpusu se tím však zpomalí každé přepočítání indexu. Výkonná grafická karta umožní rychleji testovat různé strategie chunkingu, embedding modely i obnovu indexu. U lokálního LLM je klíčová VRAM – tedy paměť grafické karty – protože velikost modelu a délka kontextu přímo ovlivňují, jak pohodlně lze systém provozovat.

Rychlé NVMe úložiště [PROLINK: NVMe SSD a firemní úložiště] je pro RAG praktická nutnost, zejména pokud má systém růst. Vektorový index, metadata, cache, dokumenty, logy a zálohy potřebují prostor i rychlý přístup. U větších nasazení je vhodné počítat s rezervou pro nové dokumenty, další verze a zpětnou vazbu od uživatelů.

U prvního pilotu není nutné kupovat maximální možný výkon. Smysluplnější je začít konfigurací, která zvládne lokální embedding, práci s indexem a testování modelů. Pokud se pilot osvědčí, firma už bude mít reálná data o velikosti korpusu, době indexace, počtu dotazů a požadavcích uživatelů. Teprve podle nich se dá dobře rozhodnout, zda zůstat u pracovní stanice, přejít na server [PROLINK: servery pro firmy] nebo budovat širší platformu.

Jak vybrat vektorový index bez zbytečné složitosti

Vektorový index nebo vektorová databáze zajišťuje, že systém rychle najde textové části podobné dotazu uživatele. Pro piloty a menší nasazení často stačí FAISS, který běží přímo v aplikaci a nevyžaduje samostatnou databázovou vrstvu. Je rychlý, praktický a vhodný pro ověření, zda RAG nad daným korpusem funguje.

Pokud firma už používá PostgreSQL a chce jednodušší produkční správu, dává smysl pgvector. Umožňuje ukládat embeddingy přímo do známého databázového prostředí a kombinovat významové vyhledávání s běžnými filtry nad metadaty. To je užitečné hlavně u oprávnění, typů dokumentů, data aktualizace nebo týmových filtrů.

Specializované vektorové databáze, například Qdrant, Milvus nebo Weaviate, se hodí ve chvíli, kdy systém roste. Přinášejí lepší škálování, správu kolekcí, provozní funkce a pohodlnější práci s většími objemy dat. Pro první pilot bývají často zbytečně robustní, pro širší firemní provoz už mohou být správnou volbou.

Výběr technologie by měl následovat po use-casu. Pro ověření hodnoty interního asistenta stačí jednodušší řešení. Pro systém obsluhující více týmů, různé zdroje dat a detailní oprávnění se vyplatí robustnější databázová vrstva.

Pilot v šesti krocích

První verze interního AI asistenta by měla být malá, měřitelná a bezpečně ohraničená. Ambiciózní celofiremní platforma se lépe obhajuje ve chvíli, kdy už existuje pilot s doloženou úsporou času nebo lepší dostupností znalostí. Pilot má ukázat, co systém skutečně zlepšuje, kde naráží na kvalitu dat a jaké nároky bude mít produkční provoz.

1. Vyberte konkrétní use-case a tým, který systém otestuje.
2. Připravte jeden dobře ohraničený korpus dokumentů.
3. Doplňte metadata, oprávnění a informaci o aktuálnosti dokumentů.
4. Nastavte chunking, embedding a vektorový index.
5. Otestujte odpovědi na reálných dotazech, včetně situací, kdy odpověď v datech není.
6. Vyhodnoťte přínos podle času, relevance zdrojů, počtu vyřešených dotazů a zpětné vazby uživatelů.

Dobrá testovací sada obsahuje otázky, na které firma zná správnou odpověď. Hodnotí se nejen finální text, ale hlavně to, zda systém našel správné zdroje. Plynulá odpověď bez relevantního podkladu má v interním prostředí nízkou hodnotu. Ověřitelná odpověď s jasným zdrojem je pro firemní použití podstatně cennější.

Měřit lze několik praktických ukazatelů. Kolik času uživatelé ušetřili při hledání odpovědi? Kolikrát systém našel správný dokument? Kolik odpovědí bylo nepodložených nebo neúplných? Jak často musel uživatel stejně kontaktovat specialistu? Tady se rozhoduje o dalším rozšíření projektu.

Nejčastější chyby při zavádění firemního AI asistenta

Při zavádění interního asistenta se nejčastěji chybuje tam, kde se technický projekt tváří jednodušeji, než ve skutečnosti je. Chatovací rozhraní lze postavit rychle, spolehlivý systém nad firemními daty však vyžaduje datovou disciplínu, bezpečnostní pravidla a průběžné vyhodnocování.

Největší rizika vypadají takto:

• Firma nahraje příliš mnoho dokumentů bez vyčištění, metadat a jasného původu.
• Pilot je moc široký, takže se nedá dobře vyhodnotit.
• Retrieval neřeší oprávnění uživatele už při vyhledávání.
• Externí API se používá i pro data, která by měla zůstat lokálně.
• Systém neumí říct, že odpověď v dostupných datech nenašel.
• Hodnotí se jen kvalita formulace, ne relevance nalezených zdrojů.
• Hardware se pořídí bez znalosti reálné zátěže a velikosti korpusu.
• Index se neaktualizuje po změnách dokumentů, takže odpovědi rychle stárnou.

Interní asistent nad firemními daty funguje nejlépe tam, kde firma ví, s jakými daty pracuje, kdo za ně odpovídá a kdo je smí používat. Pokud tyto odpovědi chybí, projekt potřebuje nejprve lepší přípravu dat a pravidel.

Závěr

Interní AI asistent nad firemními daty má největší hodnotu ve chvíli, kdy lidem pomáhá rychleji najít správnou informaci a zároveň ukáže, z jakého zdroje vychází. Základem je dobře vybraný pilot, čistý korpus, rozumný chunking, kvalitní embedding, vektorový index a jasné rozhodnutí, která data mohou do externího modelu a která musí zůstat lokálně. Hardware se vyplatí dimenzovat podle reálného scénáře: menšímu týmu může stačit výkonná pracovní stanice [PROLINK: pracovní stanice pro AI / výkonné workstation], citlivější a náročnější provoz už bude potřebovat GPU, rychlé úložiště a postupně i serverovou infrastrukturu [PROLINK: servery pro firmy]. Takový přístup umožní začít prakticky, změřit přínos a rozšiřovat řešení až ve chvíli, kdy má interní AI asistent pro firmu prokazatelnou hodnotu.

Peter Vnuk

Technologie jsou pro mě práce i zábava – nejvíc se věnuji smartphonům, notebookům, audiotechnice, umělé inteligenci a všemu hi-tech. Rád recenzuji novinky, sleduji futuristické trendy a odhaduji další vývoj technologií. Fascinuje mě sci-fi a vize budoucího světa, které často inspirují i reálný technologický pokrok. Profesionálně se věnuji také videohrám a hernímu průmyslu. Když zrovna nepracuji, rád si odpočinu u dobré hry, kvalitního piva nebo tvorbou technologických memes na Facebooku.