Způsoby implementace AI ve firmách, funkce AI nad firemním know-how a s tím související aspekty zabezpečení firemních dat

Shrnutí: Implementace AI do firmy přináší nový pohled na zabezpečení firemních dat. Stávající firemní bezpečnostní pravidla pravděpodobně nebudou pokrývat situaci po implementaci AI. Jakými způsoby lze AI do firmy implementovat, jak takto implementované AI funguje, na co se zaměřit, aby firemní know-how bylo chráněno dostatečně, implementace AI byla efektivní a dávala smysl, to vše je předmětem tohoto článku.

Executive summary

Implementace umělé inteligence (AI) na bázi velkých jazykových modelů (LLM) představuje zásadní příležitost, jak zvýšit produktivitu zaměstnanců, zefektivnit práci s informacemi a lépe využít firemní know-how. Zároveň přináší nová rizika v oblasti zabezpečení dat, kvality výstupů a řízení přístupových práv. Tento článek přibližuje čtenáři, jak vlastně AI na bázi LLM funguje, popisuje tři základní metody, jak AI ve firmě implementovat a v závěru uvádí ukázku konkrétní implementace AI.

Mezi 3 základní metody implementace AI nad firemním know-how patří:

1. Využívání veřejných AI nástrojů, např. ChatGPT, Copilot

Rychlé a levné řešení bez nutnosti implementace. Není však napojeno na interní know-how firmy, což omezuje jeho využitelnost. Při práci s interními daty vzniká riziko jejich úniku mimo firmu.

2. Trénink vlastního AI modelu nad firemními daty

Technicky komplexní a finančně náročný přístup. Přináší vysokou míru kontroly nad daty, ale má zásadní nevýhody, zejména obtížnou aktualizaci znalostí, riziko nepřesností a nemožnost efektivně řídit přístupová práva k informacím uvnitř firmy.

3. RAG (Retrieval-Augmented Generation) architektura – doporučený přístup

Moderní a v současnosti nejrozšířenější metoda. Kombinuje výhody obou předchozích přístupů:

• AI pracuje s aktuálním firemním know-how bez nutnosti tréninku modelu
• odpovědi jsou podloženy konkrétními zdroji
• lze efektivně řídit přístupová práva k informacím
• minimalizuje riziko halucinací a nepřesností

Z pohledu většiny organizací představuje RAG architektura nejlepší poměr mezi náklady, bezpečností a kvalitou výstupů, viz porovnání níže.

Klíčové faktory úspěchu implementace

• rámcové pochopení fungování AI na bázi LLM, podrobně v první kapitole
• porozumění výhodám i nevýhodám metod implementací, podrobně v druhé kapitole
• kvalitně strukturované a spravované firemní know-how
• správně nastavené řízení přístupových práv a zabezpečení dat interně i vůči externím službám
• zapojení zaměstnanců a řízení změny, tzv. change management

Doporučení

Pro většinu firem, které chtějí efektivně využívat AI nad vlastním know-how, je nejvhodnější přístup:

• implementace AI na bázi RAG architektury
• využití již hotové platformy, která minimalizuje náklady na vývoj a provoz. Praktická ukázka takové implementace na bázi platformy iTutor je v poslední kapitole.

Tento přístup umožňuje dosáhnout rychlých výsledků při zachování vysoké úrovně bezpečnosti a kvality výstupů.

Fungování AI na bázi LLM nad firemním know-how

V článku se zabýváme implementacemi, kdy AI pracuje s firemním know-how a pomocí Chatbotů, Agentů a dalších prostředků pomáhá zaměstnancům plnit efektivněji jejich pracovní úkoly, či dokonce AI část těchto úkolů přejímá a vykonává je sama.

Pro určení, jakou metodu takovéto implementace AI zvolit a jaká přijmout nová pravidla zabezpečení dat, je dobré porozumět konkrétním metodám implementace AI a rámcově pochopit fungování AI nad firemním know-how.

V této první kapitole si velmi zjednodušeně vysvětlíme fungování AI nad firemním know-how, které je uložené ve formě textů, či v podkladech převoditelných na texty, jako je např. zvuk, video, či obrázky. Takovéto texty tvořící firemní know-how jsou obvykle uloženy na mnoha místech, např. ve firemním systému pro správu dokumentů, na discích, v intranetu firmy i na jejích internetových stránkách, ve firemních databázích, diskusních fórech, mailech, CRM či ERP systémelech apod.

Pokud víte, co to je LLM, na jakém principu pracuje, jak se učí, jak odpovídá na prompt, co to je embedding, jak se liší embeddingy pro RAG od embeddingů uvnitř LLM, či jak s embeddingy pracuje vektorová databáze, může zbytek této kapitoly přeskočit a pokračovat v druhé kapitole Metody implementace AI a jejich vliv na zabezpečení dat.

Na koho bude působit tato první kapitola příliš technicky a podrobně, může ji také přeskočit a pokračovat v druhé kapitole. Odtud se sem případě může vracet ke konkrétním pojmům, když mu nějaký použitý termín v druhé kapitole nebude jasný a rád by se o něm něco dozvěděl blíže.

LLM

„Mozkem“ AI pro práci nad firemním know-how je tzv. LLM, Large Language Model, česky Velký Jazykový Model. Lze si jej představit jako „někoho“, kdo si přečetl „všechny informace na světě“ (veřejně dostupné texty na internetu), a na základě toho odpovídá na dotazy uživatelů či řeší jejich požadavky vznesené v přirozeném jazyce. Odpovědi LLM jsou opět v přirozeném jazyce.

Tento „mozek“ nepřemýšlí zcela stejně jako lidský mozek, na to víme ještě příliš málo, jak lidský mozek přemýšlí, abychom to dokázali simulovat počítačově. LLM je vybudován nad architekturou zvanou počítačová neuronová síť. Ta je inspirována činností neuronů v mozku. Počítačová neuronová síť se skládá se z ohromného množství počítačově reprezentovaných neuronů, každý neuron je simulován jedním reálným číslem. Počítačové neurony jsou umístěných ve vrstvách, každý neuron ve vrstvě je propojený se všemi neurony předchozí vrstvy tak, že se do něj přenáší pomocí vah hodnota z každého propojeného neuronu předchozí vrstvy. Zvážené hodnoty vstupních neuronů se agregují do výsledného čísla, ke kterému se přičte konstanta (bias), a na výsledek se aplikuje aktivační funkce (např. ReLU, Sigmoid nebo Tanh), která do systému vnese nelinearitu. Tak vznikne hodnota (číslo) výstupního neuronu. Znalosti největších LLM jsou tedy reprezentovány architekturou propojení neuronů ve vrstvách a hodnotami stovek miliard až bilionů vah a biasů (biasů je méně než vah, na jeden bias je obvykle tisíc i více vah), kde hodnoty vah a biasů se nastaví při tréninku (učení).

Zjednodušeně, naučené neuronové síti vložíte na vstup reprezentovaný vstupní vrstvou neuronů nějaká čísla, tolik čísel, kolik má vstupní vrstva neuronů. Tato čísla se pomocí nastavených vah a biasů postupně přenáší do neuronů v dalších vrstvách, až se objeví jako nějaká jiná čísla v neuronech na výstupní vrstvě sítě. Výstup neuronové sítě je opět tolik čísel, kolik má výstupní vrstva neuronů.

Když se neuronová síť učí, dávají se jí na vstup vzorky vstupních čísel, a ukazují se jí vždy pro každý takový vstupní vzorek, jaký vzorek výstupních čísel je očekáván na výstupu. Neuronová sít si ve fázi učení upravuje své váhy a bias pomocí procesu, který se nazývá backpropagation tak, aby se pro zadané vstupní vzorky její výstupní vzorky co nejvíce podobaly očekávaným výstupním vzorkům.

LLM nepracuje s čísly, ale s texty, výše popsaný princip je nicméně podobný:

• Ve fázi učení se vezmou „všechny dostupné texty z internetu“. Což samo o sobě je složitý proces, zahrnující vyfiltrování těchto dat, tzv. kuraci, kde místo pouhého „předhození“ veškerého dostupného textu na vstup LLM se data pečlivě filtrují, aby se předešlo zkreslení, šíření nepravdivých informací, a úniku citlivých údajů, hlídá se použití licencovaných informací. Každý takto očištěný souvislý text u internetu, např. jedna internetová stránka, jeden stažený dokument, se po částech posílá na vstup LLM. Ke každé poslané vstupní části textu se jako výstup LLM ukáže, jaké další slovo je očekávané na výstupu. Nad staženým textem z internetu vlastně popojíždíme oknem, které mění šířku od jednoho slova až po maximálně podporovaný počet slovu na vstupu LLM, čemuž se říká velikost kontextového okna LLM. Např. u textu „Kočka leze dírou, pes oknem“ se na vstup LLM pošle v prvním okně „Kočka“ a ukáže se, že na výstupu je očekávané slovo „leze“. Pak se na vstup LLM pošle rozšířené okno „Kočka leze“ a ukáže se, že na výstupu očekáváme slovo „dírou“, atd., až se na konec pošle „Kočka leze dírou, pes“ a ukáže se očekávané „oknem“. Kdyby velikost kontextového okna LLM byla jen 3 slova, reálně je o mnoho větší a obvykle pojme 150 až 300 stran textu, po dosažení 3 slov na vstupu („Kočka leze dírou“) by se jako další vstup LLM poslalo posunuté okno „leze dírou, pes“ a takto by se s oknem o velikosti 3 slova projelo celým vstupním textem. LLM si ve fázi učení pomocí backpropagation nastaví ze všech poslaných textů na vstup až biliony svých vah, a tak se v jeho váhách zafixují nejen syntaktická pravidla přirozeného jazyka, ale i znalosti ukryté v zaslaných textech.
• Natrénované LLM poté řeší požadavky či dotazy uživatelů, nebo agentů AI tak, že textově zformulované požadavky či dotazy, které svou délkou nepřekročí velikost kontextového okna LLM, se předají na vstup LLM. Takto naformulovaný text předávaný LLM jako vstup se nazývá prompt. LLM ze vstupního promptu „vypočte“ výše popsaným průchodem všemi vrstvami neuronů s nastavenými vahami z doby učení první slovo výstupu, které bude v jeho odpovědi. Toto vypočtené slovo LLM přidá na konec textu vstupního promptu, a takto upravený prompt pošle opět sám na sebe jako vstup. Tak LLM vypočte druhé slovo své odpovědi. To by se mohlo opakovat do nekonečna, proto se LLM dokáže v určité chvíli „rozhodnout, že to už stačí“ a jím takto vygenerovanou odpověď s konečným počtem slov předá tazateli.

Takto velmi zjednodušeně vysvětlená funkce LLM stačí pro pochopení 2 ze tří základních metod implementace AI ve firmě nad firemním know-how, popisovaných v druhé kapitole. Existuje ještě třetí, nejpoužívanější metoda implementace AI, využívající technologii RAG. Kvůli ní si ještě zjednodušeně řekneme něco o převodu textů na čísla.

Embeddingy

LLM je neuronová síť, ta pracuje s čísly, ne s texty. Je dobré rámcově chápat, jak se vstupní texty posílané do LLM v promptu převedou na čísla, a jak se z číselného výstupu neuronové sítě LLM zpětně udělá slovo. Pro technologii RAG je převod textů na čísla zásadní i z jiného důvodu, kvůli vyhledávání podkladů pro odpověď LLM.

Metoda převodu textu na čísla je postavena na něčem, čemu se říká embedding. Embedding, do češtiny obvykle nepřekládaný výraz, je číselné vyjádření kontextového významu slova. Každé slovo jde převést na embedding, 2 slova sobě kontextově významově blízá mají i sobě blízké embeddingy. Takováto číselná reprezentace významu slova nejde vyjádřit jedním číslem, např. že by stůl měl číslo (embedding) 4 a židle 6. To jsou si sice docela blízká čísla, protože i stůl a židle jsou si něčím významově blízké, ale při takovémto způsobu číslování slov bychom brzy skončili, že už nejde vyjádřit významová blízkost a vzdálenost různých slov, aniž by se to vzájemně číselně nevylučovalo. Embedding proto není jedno číslo, ale vektor čísel, bývá to někdy až více tisíců čísel v jednom embeddingu. V takovémto mnoha-číselném vektorovém prostoru lze matematicky např. pomocí Kosinové podobnosti či Eukleidovské vzdálenosti určovat blízkost/vzdálenost jednotlivých embeddingů, vlastně bodů v tomto prostoru, reprezentujíc kontextový význam jednotlivých slov. Zároveň do takovéto vektorové reprezentace kontextového významu slova již lze „zakódovat“ význam všech slov tak, aby jejich blízkost vycházela „správně“.

Embeddingy lze vytvářet nejen ze slov, ale i z celých textů, embedding takového textu má v sobě zakódovaný význam celého textu.

Něco navíc

Pro ty, kteří mají pocit, že zde zjednodušujeme příliš, a že zde chybí vysvětlení řady věcí, pár stručných poznámek na závěr.

• Embeddingy se ve skutečnosti nedělají ze slov, ale z tzv. tokenů. Token může být i jen část slova. LLM si pak dokáže poradit i se slovy, které nikdy neviděl, může lépe zvládnout gramatiku složitějších jazyků jako je např. čeština, a lze vytvářet relativně malé slovníky tokenů, kolem 100 000 tokenů, kterými lze pokrýt všechna slova přirozeného jazyka. Těch je samozřejmě mnohem více, např. v češtině je slov kolem 250 000, a to jen v jejich základní podobě, díky skloňování, časování, odborným a slangovým výrazům to jde do milionů. Metody, jak dělat tokeny jsou různé, např. slovo „nejobhospodařovanější“ by se mohlo rozpadnout na tokeny „nej“, „ob“, „hospoda“, „řov“, „an“ a „ější“. Jak je vidět, z těchto tokenů a dalších jim podobných půjde složit mnoho jiných českých slov, aniž tato slova musí být ve slovníku.
• Embedding z tokenu se vypočítává pomocí neuronové sítě. LLM v sobě má slovník, technicky je to první vrstva jeho neuronové sítě. Má-li tento slovník např 100 000 tokenů a embedding obsahuje 16 384 dimenzí (čísel), jedná se o matici 100 000 x 16 384 čísel, kde každý řádek reprezentuje embedding konkrétního tokenu ze slovníku. Na začátku učení je tato matice naplněna náhodnými čísly, během fáze učení se zpřesňují pomocí backpropagation nejen váhy neuronové sítě LLM, ale i tato čísla, reprezentující hodnoty tokenů.
• Vstupem do neuronové sítě LLM není řada čísel, jak bylo vysvětleno pro obecnou neuronovou síť výše, ale matice, kde na každé řádce je embedding jednoho tokenu ze vstupního textu. Navíc je zde přidáno poziční kódování, aby neuronová síť mohla pochopit, že to není jen „hromada“ slov (tokenů), ale že ty tokeny mají své pořadí a vztah k okolním tokenům.
• Embeddingy nejde snadno převádět zpětně na slova. U LLM se to zjednodušeně dělá, tak, že na výstupní vrstvě neuronové sítě je tolik neuronů, kolik je slov (tokenů) ve slovníku. Hodnota každého takového neuronu se přepočte na pravděpodobnost, s jakou se má slovo ze slovníku reprezentované tímto neuronem objevit v textovém výstupu LLM. Jako finální slovo se zvolí buď slovo s nejvyšší pravděpodobností. Při této volbě se ale LLM chová trochu jako robot, odpovědi jsou stabilní ale málo kreativní. Nebo se podle tzv. „teploty“ a náhodného výběru zavede do odpovědí neurčitost, což může vést ke kreativnějším odpovědím, ale také k „blábolení“ či nesmyslům (halucinacím) v odpovědích.
• Pro technologii RAG, která bude vysvětlena ve druhé kapitole, se používají trochu jiné embeddingy. Tyto embeddingy mají obvykle menší rozměr než embeddingy uvnitř LLM, např. 1 536 čísel v jednom embeddingu. Je to proto, že se musí ukládat do vektorové databáze a pak v ní rychle vyhledávat embeddingy dle blízkosti. Vektorová databáze je specializovaný typ databáze pro ukládání a správu dat ve formě číselných polí, tzv. vektorů. Na rozdíl od tradičních databází, které hledají přesnou shodu (např. jméno nebo ID), vektorová databáze umí vyhledávat podle podobnosti významu (blízkosti embeddingů). Embeddingy pro RAG se vytváří obvykle pomocí specializované neuronové sítě. Pro RAG se vyrábí embeddingy z ucelých odstavců textu, ne jen z jednotlivých slov (tokenů). Tato specializovaná neuronová síť interně vyrobí embeddingy se všech slov (tokenů) v textu, a ve výsledku je shlukne (tzv. pooling) do jediného embeddingu, který obsahuje význam celého textu.

Metody implementace AI a jejich vliv na zabezpečení dat

Existuje více metod, jak implementovat AI zpracovávající firemní know-how s pomocí LLM. Zde popíšeme 3 základní způsoby těchto implementací.

Metody jsou zde popisovány z technického a bezpečnostního pohledu. Alespoň v úvodu je potřeba zmínit lidský faktor, který se nesmí zanedbat při jakékoliv implementaci AI. Implementace AI přináší často změnu firemních procesů, kultury, je třeba překonat strach zaměstnanců z nahrazení, což je při implementaci AI často větší překážka než technologie samotná. Je nutné správně aplikovat change management, vysvětlit důvody zavedení, spojit implementaci se vzdělávacím procesem, připravit pilotní projekt, vybrat AI ambasadory a udělat řadu dalších souvisejících věcí. Toto není předmětem článku, popis jak pracovat s lidským faktorem při implementaci AI by vydal na celý článek podobného rozsahu jako je tento technický článek. V případě zájmu čtenářů zařadíme článek o lidském faktoru a odpovídajících postupech při implementaci AI do Kontis Insights v budoucnu.

3 základní metody implementace AI zpracovávající firemní know-how s pomocí LLM:

Využívání hotových nástrojů AI bez napojení na firemní know-how

Jedná se o nástroje jako je jako je ChatGPT, Microsoft Copilot, Google Gemini, Claude, Perplexity AI, a další obdobné nástroje na bázi LLM.

Využívání hotových nástrojů AI přináší nulové náklady na vývoj, téměř okamžitý start řešení či nízké náklady na provoz.

Tyto nástroje nejsou samy o sobě propojeny s firemním know-how, použité LLM o firemním know-how „neví nic“. Ve fázi učení se možná odpovídající LLM naučil něco o firmě ze zdrojů na internetu, např. byl trénován i na firemních internetových stránkách či jiných veřejných zdrojích o firmě. Tyto načtené vědomosti byly sloučeny ve vahách LLM s miliardami ostatních vědomostí načtených z internetu, což nutně vede ke generalizaci. LLM na základě požadavku uživatele v promptu může také dospět k tomu, že si nějaké informace o firmě na internetu vyhledá dodatečně a přidá je si je jako další vstup do promptu. K těmto firemním informacím se LLM dokáže dostat pomocí služeb nějakého internetového vyhledávače, takže texty, které dokáže dohledat, jsou podobné jako texty na vstupu v době učení, jen např. aktuálnější. Z interního firemního know-how v nich mnoho nebude.

Takto používané LLM může skvěle pomoci při řešení pracovních úkolů, ke kterým zaměstnanci nepotřebují firemní know-how. Před používáním je dobré proškolit zaměstnance, aby rámcově chápali, jak LLM funguje a jak správně sestavovat prompt pro LLM, aby dostali co nejlepší odpovědi. Viz první kapitola vysvětlující funkci LLM, pokud uživatel nezadá dostatečně obsáhlý prompt dobře vysvětlující požadavek, LLM nemůže poskytnut kvalitní odpověď.

Problém nastává, chce-li zaměstnanec řešit v AI dotazy či požadavky související s firemním know-how. LLM nemá odpověď „zakódovanou“ ve svých vahách, protože nebyl učen nad firemním know-how. Pravděpodobně neodpoví že neví, spíše si začne vymýšlet, tzv. halucinovat. Jste-li např. výrobní firma vyrábějící na výrobních linkách, a zeptáte se takovéhoto LLM „Jak se na lince pro výrobu produktu X upíná produkt do mechanismu linky“, LLM neřekne, že neví, ale sestaví poměrně věrohodnou odpověď na základě toho, co se naučil ve fázi učení z internetu o různých výrobních linkách či upínání výrobků. Konkrétně pro vaší firmu a vaše postupy může odpovědět sice věrohodně, ale zcela nesprávně.

To vede zaměstnance k vkládání dokumentů s firemním know-how do promptu LLM, na základě nichž má LLM odpovědět. Např. v uvedeném příkladu výrobní firmy uživatel do promptu vloží dotaz a firemní dokument s pracovními instrukcemi pro danou výrobní linku, LLM instruuje, aby odpověděl jen na základě informací v přiloženém dokumentu. Obdobně např. manažer přiloží do promptu smlouvu se zákazníkem a zeptá se, zda něco neporušuje konkrétně jím popsanou činností v promptu a pokud ano, jaké z toho plynou sankce.

Problémy s využíváním LLM bez napojení na firemní know-how

Pokud v takovéto implementaci chtějí uživatelé řešit dotazy či požadavky související s firemním know-how:

• Uživatel musí umět nalézt dokumenty se souvisejícím firemním know-how, které přiloží do promptu. Nalézt všechny takové dokumenty a další zdroje informací, které mohou být v e-mailech, chatech, bug-listech, firemním ERP a podobně není snadné. Uživatel často nenalezne vše z firemního know-how s dotazem související.
• I když uživatel nalezne všechny potřebné podklady pro kvalitní odpověď LLM, nemusí se tyto podklady do promptu vejít, viz velikost kontextového okna LLM vysvětlená v první kapitole.
• I když se podklady do kontextového okna vejdou, pokud jsou velké, LLM v nich hůře hledá relevantní části pro odpověď a ztrácí detail z dlouhého textu.

Zabezpečení dat této metody

Při výše popsaném vkládání podkladů k promptu putují mimo firmu celé firemní dokumenty. I když je komunikace s LLM po cestě zabezpečena a dodavatel LLM zaručuje, že nebude na základě těchto dat učit své LLM, či je využívat k čemukoliv jinému než vygenerování odpovědi LLM, v řadě firem toto v odděleních odpovídajících za zabezpečení firemních dat schváleno nebude. Zejména putují-li promptem ven např. smlouvy se zákazníky, viz předchozí příklad, či dokumenty obsahující citlivá data z pohledu GDPR, může to být problematické. Alespoň se zde musí přijmout další opatření pro zabezpečení dat, jako např.

• Proškolení uživatelů, jaké dokumenty mohou vkládat do promptu. S tím je obvykle spojeno zavedení systému klasifikace firemních dokumentů a přiřazení konkrétní klasifikace ke každému dokumentu, aby byli uživatelé schopni rozpoznat. Které dokumenty a za jakých podmínek mohou do promptu vkládat.
• Zavedení systémů DLP (Data Loss Prevention), kontrolující odesílaná data z firmy.
• Implementování AI Gateway, která filtruje prompty, anonymizuje data, audituje použití.

Taková opatření nesou další náklady, a 100% zabezpečení úniku firemního know-how mimo firmu zaručit nedokážou. Pokud je toto cílem, je potřeba LLM „uzavřít“ v intranetu firmy, viz další 2 metody. Vlastní obecně naučené LLM lze i v případě této metody uzavřít uvnitř firmy, avšak nedává to ekonomicky ani funkčně velký smysl bez současné implementace RAG architektury. Jaké vlastní obecně naučené LLM lze uzavírat uvnitř firmy a s jakými je to spojeno požadavky je proto blíže popsáno až v odstavci Zabezpečení dat vně firmy u metody RAG architektura.

Trénink a implementace interního LLM

Na opačném spektru nákladovosti, doby zavedení, ale i zabezpečení proti úniku firemních dat mimo firmu je metoda vyžadující natrénování vlastního modelu LLM nad firemním know-how. Takovéto LLM poté může pracovat zcela uzavřené ve firemním intranetu.

Existují 2 způsoby tréninku LLM nad firemním know-how:

Full training

Při Full training se začíná od nuly, LLM nezná ani jedno slovo, nejsou nastaveny jeho váhy. Je potřeba v tréninku použít „celý internet“, nad jehož daty byla provedena v první kapitole popsaná kurace a navíc do vstupních tréninkových dat zařadit firemní data, opět očištěná. Z popisu tréninku LLM v první kapitole je zřejmé, že s tím je spojena vysoká náročnost na technické odborníky, složité vyčištění dat, velmi vysoké náklady na počítačový výkon, pro představu Full trainig obvykle vyžaduje tisíce GPU hodin, a fáze tréninku trvá dlouho. Na celý proces tréninku je potřeba vyhradit obvykle několik měsíců. Z těchto důvodů je Full training vlastního LLM pro 99 % firem ekonomicky nesmyslný a nedosažitelný. Zásadní problém při tréninku na firemní data je v tom, že firemní know-how není statická věc, naopak se v čase velmi rychle mění. Každá taková změna firemních dat by vyžadovala nové přetrénování LLM, či jeho dotrénování metodou Fine tuning.

Fine tuning

Při Fine tunig se začíná s již nastaveným, tzn. s obecně natrénovaným veřejně dostupným LLM jako je např. Llama či Mistral. Obecně natrénované LLM se poté dotrénuje na firemních datech. To je ekonomicky i časově přijatelnější než Full training, ale i s touto metodou je spojena delší doba implementace, náročnost na technické odborníky a vyčištění vstupních firemních dat, či nutnost neustálého dotrénovávání LLM souvisejícího se změnou firemního know-how.

Problémy s tréninkem LLM nad firemním know-how

Full training i Fine tuning s sebou při tréninku nad firemním know-how nesou kritické nevýhody, mezi něž např. patří:

• LLM nedokáže v odpovědích uvádět firemní dokumenty, na základě kterých vygeneroval odpověď. Nejde si tedy ověřit správnost odpovědi LLM, což vzhledem k možnému halucinování LLM popsaném výše je vážný problém.
• Při dotrénování hrozí riziko, že při úpravě vah LLM zapomene některé již naučené věci, to se nazývá „katastrofické zapomínání“. Pokud LLM dotrénováváme jen na firemních datech, i když při každém takovém dotrénování vždy použijeme celou množinu aktuálních firemních dat, hrozí že LLM „zapomene“ něco z úvodního Full traingu nad celým internetem, LLM se stane expertem na firemní know-how, ale přestane zvládat obecné dotazy nebo logické uvažování. Jsou různé metody jak toto korigovat, nicméně poměrně komplikované a náročné.
• Při dotrénování jsou obvykle firemní data v porovnáním s daty z Full tréninku velmi „malá“, hrozí že LLM se trénovací příklady naučí "nazpaměť". Výsledkem je, že LLM skvěle odpovídá na data z trénovací sady, ale selhává v reálném provozu při mírně odlišných dotazech.

Zabezpečení dat této metody

Z hlediska zabezpečení firemního know-how, pokud je natrénované LLM uzavřeno uvnitř firmy v jejím intranetu, je plně zabezpečeno, že firemní know-how se nedostává mimo firmu.

Avšak během tréninku LLM nad firemními daty se firemní know-how stalo součástí vnitřních vah LLM, viz první kapitola o fungování LLM. Takto natrénované LLM v odpovědích nedokáže rozlišit, který uživatel měl jaká práva na konkrétní firemní data, na základě kterých LLM odpoví. Pokud model zná odpověď, odpoví každému, kdo se správně zeptá. Tím se metoda trénování vlastního LLM stává pro většinu firem nepoužitelná, z vně je firemní know-how zabezpečeno dokonale, ale uvnitř firmy nijak, jakýkoliv zaměstnanec s přístupem k promptu LLM se automaticky dostane k jakýmkoliv informacím z celého firemního know-how.

Viz výše uvedený příklad manažera, který se táže na něco ke konkrétní smlouvě, naučené LLM nad firemním know-how manažerovi nejspíše odpoví správně. Ale pokud se na něco o této smlouvě a zákazníkovi zeptá jakýkoliv jiný zaměstnanec s přístupem k promptu LLM, i jemu LLM podá všechny informace které zná, aniž tento zaměstnanec měl právo do smluv firmy se zákazníky vidět.

RAG architektura

Implementace AI nad firemními daty, založená na RAG architektuře, je v současnosti nejpoužívanější metoda, jak AI na bázi LLM naučit pracovat s firemním know-how.

U výše popsaných metod implementací AI jsou stručně nastíněny problémy, které jsou s nimi spojené. Využití RAG architektury téměř všechny tyto problémy řeší.

Pod zkratkou RAG se skrývá:

• Retrieval, tzn. vyhledání informací, na základě kterých má LLM odpovědět na dotaz či požadavek v promptu.
• Augmentation, neboli rozšíření, vyhledané informace se připojí do promptu s uživatelským dotazem/požadavkem včetně instrukcí, jak má LLM odpovídat jen na základě těchto připojených informací.
• Generation, tzn. generování, to už je klasické LLM generování odpovědi na základě promptu, rozšířeného o související informace z firemního know-how.

Vyhledávání v know-how firmy

Podstatné u RAG je to Retrieval, vyhledání informací ve firemním know-how. V RAG architektuře je toto hledání založené na embedding, jejichž podstata je vysvětlena v první kapitole v sekci Embeddingy.

Příprava embeddingů

Nejprve se ze všech textů představující firemní know-how nařežou menší části textu, tzv. chunky. Cílem je rozdělit firemní textové know-how na takové části, která půjde co nejlépe poskládat jako kontext dotazu uživatele v promptu LLM. Pokud by byl chunk příliš malý, např. jedno slovo, nebyl by v něm dostatečně obsažen význam. Pokud by byl chunk příliš velký, např. celá kapitola, byl by příliš rozsáhlý, s více tématy, špatně by se vyhledával dle významu a LLM by ho méně efektivně zpracovávalo. Jsou různé metody, jak text rozdělit na chunky, např.:

• prosté rozdělení na části textů s fixní délkou znaků
• pokročilejší dělení dle odstavců či podkapitol
• sofistikované metody, kde se konce a začátky témat v textu určují opět pomocí AI
• někdy se z chunků dělá hierarchická struktura, do LLM se posílá širší okolí chunku apod.

Obvykle se délka jednoho chunku pohybuje kolem 256 až 512 tokenů, které opět vysvětlujeme v první kapitole. Používají různá vylepšení jako je mírné překryvy textu, každý chunk obsahuje na začátku 10-20% konce předchozího chunku, aby se neztratila souvislost. Nebo na začátek každého chunku se přiřazuje kontext celého dokumentu z kterého pochází, něco jako např. „Tento odstavec pochází z pracovních instrukcí pro výrobní linku X“ či „Tento odstavec pochází ze smlouvy o X se zákazníkem Y“.

Z tako vytvořených chunků se vypočtou embeddingy pro RAG, popsané v první kapitole. Tyto embeddingy se uloží do vektorové databáze včetně originálních textů, ze kterých vznikly.

Vyhledání kontextu k promptu uživatele

Uživatel zadá v promptu svůj požadavek/dotaz. Z něj se buď udělá embedding, nebo se před tím zadaný prompt ještě zpracuje. Od jednoduchých metod, jako je vyčištění promptu od zbytečných slov, či generování embeddingu z každého slova, až po sofistikované metody s využitím AI, jako je generování variant formulací dotazu, extrakce témat z promptu uživatele, či generování fiktivních odpovědí, z kterých se teprve vytváří embeddingy.

Jako výsledek zpracování promptu je jeden či několik embeddingů ze zadaného promptu uživatele. K tomuto výslednému jednomu či několika embeddingům se ve vektorové databázi s uloženými embeddingy z fáze přípravy vyhledají jim nejbližší embeddingy ve vektorovém prostoru. Ty nejspíše obsahují informace z firemního know-how, související s dotazem či požadavkem uživatele. U těchto vyhledaných embeddingů jsou ve vektorové databázi uloženy i originální texty, z kterých vznikly. Tyto originální texty se přidají do promptu jako kontext požadavku s instrukcemi, že LLM má odpovídat jen na jejich základě.

RAG architektura tedy udělá něco podobného, jako když uživatel při Využívání již hotových nástrojů AI bez napojení na firemní know-how do promptu připojí firemní dokumenty, dle kterých má LLM odpovědět. RAG to udělá sofistikovaněji a efektivněji. Když vezmeme výše vypsané Problémy s využíváním LLM bez napojení na firemní know-how, zde ve stejném pořadí platí:

• Na rozdíl od uživatele nejspíše RAG nalezne mnohem více sémanticky (významově) blízkých informací z firemního know-how, které souvisí s dotazem uživatele v promptu. LLM má tedy v promptu více souvisejících informací, na základě kterých může vygenerovat odpověď.
• Vyhledanými podklady RAG nejsou celé firemní dokumenty, ale jen jejich s dotazem související fragmenty. Takže se nejspíše všechny tyto testy vejdou do kontextového okna LLM.
• Protože texty obsahují jen z dokumentů vyřezané informace skutečně související s dotazem, LLM z nich může efektivně vytvořit odpověď, aniž se ztratí v detailu dlouhého textu z velké části nesouvisejícího s dotazem, viz funkce LLM.

Doplnění odpovědí o odkazy na zdroje

RAG architektura odstraňuje kritický nedostatek Tréninku a implementace interního LLM, kde LLM nedokáže v odpovědích uvádět odkazy na firemní dokumenty, z kterých čerpal informace pro odpověď. K embeddingům uložených ve vektorové databázi, lze jako metadata připojovat odkazy na zdrojové dokumenty, či dokonce jejich konkrétní části, z kterých byl ve fázi přípravy embedding vyroben. RAG dokáže tyto odkazy připojovat k odpovědím LLM, tazatel si může ověřit v originálním zdroji odpovědi, zda LLM nehalucinuje.

Zabezpečení firemního know-how u RAG architektury bude probráno v samostatné podkapitole, RAG dokáže odstranit téměř všechny nevýhody v zabezpečení dat, jmenované u předchozích dvou metod implementace AI.

Použijeme-li dříve uvedený příklad, kde uživatel do svého promptu „Jak se na lince pro výrobu produktu X upíná produkt do mechanismu linky“ vloží firemní dokument s pracovními instrukcemi pro danou výrobní linku, RAG architektura toto udělá za uživatele sofistikovaněji. Popis „upínání“ bývá v dokumentaci často rozprostřen mezi textové návody více pracovních instrukcí, technické výkresy s popisky, kusovníky, mohou s ním souviset i informace v dokumentech o bezpečnosti práce apod. RAG při správně položeném dotazu vyhledá nejspíše většinu těchto textů, očištěných o informace s dotazem nesouvisející. Odpověď LLM na prompt obohacený o tyto texty bude přesnější a výstižnější. Díky od RAG připojených odkazů k odpovědi LLM na zdrojové texty může tazatel odpověď ověřit v odkazovaných dokumentech.

Podobně, když se manažer v promptu zeptá, zda u konkrétního zákazníka něco neporušuje jím popsanou činnosti, a pokud ano, jaké z toho plynou sankce, na rozdíl od tazatele, který k promptu přiložil celou smlouvu, RAG vyhledá nejen tuto smlouvu se zákazníkem a v ní jen pasáže související s dotazem, ale obdobné texty RAG možná najde, pokud existují, např. v přílohách smlouvy, v uložené komunikaci se zákazníkem o předmětu smlouvy, ve směrnicích specifikující obecná pravidla firmy pro práci se zákazníky apod. Odpověď LLM na dotaz bude opět výrazně lepší než jen s přiloženou smlouvou k promptu, s možností ověření v dotčených dokumentech, že to tak skutečně je.

Zabezpečení dat této metody

Uvnitř firmy

Při výrobě embeddingů z nařezaných textů know-how, popsané ve fázi jejich přípravy, lze k embeddingům ukládat různá metadata, např. již zmíněné odkazy na zdrojové texty. Tato metadata lze využívat i k uložení a následnému určení práv tazatele na konkrétní texty, související s vyrobeným embeddingem. Existuje více metod, jak to dělat, např.:

• Filtrování dle metadat. Do metadat embeddingu se uloží informace, dle kterých budou ve vektorové databázi při hledání blízkých embeddingů k dotazu uživatele filtrovány jen embeddingy, na které má uživatel právo. Takovéto filtrování enginem vektorové databáze umožňuje efektivní a rychlé vyhledání blízkých embeddingů k embeddingu dotazu. Avšak neumožňuje komplexní řízení práv. K embeddingu se jako metadata ukládá např. seznam povolených uživatelů, skupina či role, kam musí uživatel patřit, a pod. Z toho je vidět, že takto nejde vybudovat komplexní, v čase se ve firmě měnící systém řízení práv.
• Řízení přístupů na základě vztahů. K embeddingu se uloží id objektu, z kterého byl embedding vygenerován. Při hledání blízkých embeddingů k dotazu uživatele vektorová databáze vrátí např. 50 nejbližších výsledků bez ohledu na práva. RAG architektura se zeptá externí služby, poskytující komplexní řízení práv ve firmě, které z těchto 50 konkrétních objektů má právo tazatel vidět. Do promptu LLM se přidají jen texty z embeddingů, na jejichž zdrojové objekty má uživatel právo. Pokud je takových embeddingů ve vyhledaných 50-ti málo, iteračně RAG vyhledává ve vektorové databázi jiné embeddingy např. s výběrem jiné metriky či prahové hodnoty, které možná nejsou dotazu uživatele tak „blízké“ jako předchozích 50 vyhledaných, ale uživatel má právo vidět objety s testy spojenými.

Tímto způsobem lze z hlediska zabezpečení dat zaručit, že na rozdíl od natrénovaného LLM nad firemním know-how, LLM vrátí uživateli na jeho dotaz či požadavek pouze informace, na které má uživatel v rámci firemního know-how právo je vidět.

Vně firmy

RAG architekturu lze v případě potřeby obdobně jako u zabezpečení natrénované LLM nad firemním know-how plně uzavřít v intranetu firmy a tak firemní know-how plně ochránit před jakýmkoliv únikem vně firmu.

Pro tento případ je potřeba na firemních serverech vedle firemní platformy, v které je uloženo firemní know-how, provozovat také:

• Vektorovou databázi pro uložení embeddingů. Zde jsou k dispozici na trhu velká škálovatelná řešení s pokročilými funkcemi pro vyhledávání, např. vektorové DB Qdrant či Milvus, i řešení jednodušší na nastavení a provoz, vhodná pro menší až střední projekty, jako např. ChromaDB.
• Model pro výrobu embeddingů. Na trhu jsou špičkové modely jako např. BGE-M3, který je multilinguální a tudíž vhodný i pro češtinu, nebo modely od MixedBread.ai, TEI od Hugging Face či Nomic Embedd.
• Vlastní obecně naučené LLM. Na trhu jsou LLM se špičkovým výkonem jako třeba Llama 3.1 nebo novější modely řady Qwen3.5, které však vyžadují výkonný hardware, více GPU s vysokou VRAM. Či jsou k dispozici modely méně náročné na hardware jako Mistral Large 2, Ollama či vLLM. Takovýto obecně naučený LLM lze v tomto případě použití navíc pomocí Fine tunig dotrénovat např. na firemní styl komunikace, což je poměrně zajímavé rozšíření obecné funkce LLM.

Je třeba zvážit náklady takového řešení, u špičkových řešení půjde pořízení HW do milionů, nezanedbatelné částky půjdou i na provoz, kromě elektřiny a chlazení to budou zejména náklady na experty, kteří budou jmenované systémy udržovat a aktualizovat. Náklady na experty jsou často vyšší než samotný hardware a jeho provoz.

Z toho důvodu k uzavření vektorové databáze, modelu pro výrobu embeddingů a LLM, do intranetu firmy se tedy obvykle přistupuje pouze v případech, kdy ochrana soukromí je naprosto kritickým požadavkem, či se počítá s masivním provozem AI, kde budou objemy nad 10 miliard tokenů měsíčně, v tomto případě to někdy dává i ekonomický smysl.

Většina firem si vystačí s provozem, kde k vektorové DB, modelu pro výrobu embeddingů a LLM přistupuje přes API k již hotovým řešením SaaS. Na trhu jsou vysoce kvalitní řešení od OpenAI, Azure OpenAI Service, Anthropic, DeepSeek (tady bude z hlediska zabezpečení v některých regionech, např. v EU problém, že servery jsou v Číně), Groq či Mistral AI.

Existují univerzální adaptéry, jako např. LiteLLM., pomocí nichž se lze přepínat mezi jednotlivými řešeními a případně měnit SaaS dodavatele dle měnících se požadavků na zabezpečení, výkon a kvalitu, aniž musí firma měnit celý firemní systém.

Dodavatelé SaaS řešení obvykle zaručují, že na posílaných datech přes API nebudou trénovat své LLM ani je jakkoliv jinak využívat, někteří dodavatelé zaručují provoz v datacentrech v EU, např. Azure OpenAI Service či Mistral AI.

Náklady SaaS řešení se obvykle počítají z množství tokenů, které projdou přes API. Pokud nebude firma posílat přes API miliardy tokenů měsíčně, vyjde SaaS řešení mnohem ekonomičtěji než provozovat vše na svých serverech.

Jednoduchá srovnávací tabulka metod implementace

Kritérium	Bez integrace s know-how	Trénink interního LLM	RAG architektura
Náklady	nízké	vysoké	střední
Bezpečnost	nízká	vysoká	vysoká
Přesnost	nízká	střední	vysoká

Ukázka implementace AI s RAG v platformě iTutor

Implementace RAG AI nad firemním know-how v iTutor

iTutor je platforma, která mimo jiné:

• shromažďuje a organizuje firemní know-how
• řídí, které části know-how jsou přístupné kterým zaměstnancům s využitím kompetenčních či kvalifikačních matic, map vzdělávání a komplexního systému řízení práv
• poskytuje zaměstnancům informace, vzdělávání a podporu pro efektivní používání jimi sdíleného firemního know-how ve své každodenní práci
• umožňuje ověřovat pomocí automatického testování, 360-zpětné vazby, měření plnění cílů a dalších technik, že firemní know-how je správně uloženo, předáváno a účinně pomáhá v pracovním procesu každému zaměstnanci.

Platforma iTutor toho umí mnohem více, viz popis platformy iTutor, z hlediska v článku diskutované implementace AI nad firemním know-how takto stručný popis iTutor stačí.

Firemní know-how je v iTutor:

• centralizováno ve výkonném systému pro správu dokumentů (DMS) iTutor Documents, ve formě textových, obrazových, audio a video dokumentů. iTutor Documents je unikátní pro správu firemního know-how pro všechny typy firem od malých firem až po nadnárodní koncerny s multi-jazyčným prostředí, protože:
  • má pokročilé work-flow schvalování a připomínkování vznikajících verzí dokumentů s komplexní správou přístupových práv k verzím dokumentů
  • umožňuje vytvářet jazykové sub-verze dokumentů s vlastním schvalovacím work-flow pro překladatele a schvalovatele jazykových mutací, podporuje obsahové odchylky a varianty verzí dokumentů, odpovídající konkrétnímu národnímu prostředí, zvykům a legislativě
  • má vestavěné business-pluginy pro specifické způsoby ukládání know-how, např. editor pracovních instrukcí, v kterém lze graficky vytvářet modulární interaktivní pracovní instrukce pro práci zaměstnanců na výrobních linkách či v jiných pracovních procesech
• část firemního know-how je uloženo v iTutor LMS/LXP ve formě e-learningových kurzů. To se týká zejména znalostí a dovedností, které je potřeba didakticky na vysoké úrovni předat zaměstnancům a on-line si ověřovat zpětnou vazbou pochopení obsahu. V iTutor je integrovaný nástroj třídy LCMS iTutor Publisher pro vývoj pokročilých e-kurzů a následné zpracování jejich obsahu pro AI. Obsah e-kurzů je obvykle „zabalen“ v různých interaktivních výukových strategiích a není snadno přístupný pro AI. Text know-how, je v e-kurzech „ukryt“ v různých JS funkcionalitách, simulacích a interaktivních prvcích, k takovému obsahu se lze dostat jen sofistikovanou interakcí studenta s e-kurzem. iTutor Publisher dokáže z takovýchto interaktivních multimediálních e-kurzů vytvářet jejich textové obrazy, s převedením i skrytého obsahu do textově srozumitelné formy pro AI.

Koho blíže zajímá, jak se v integrovaných systémech DMS/LMS/LCMS/LXP spravuje firemní know-how, může si přečíst podrobnější článek zde.

Nad firemním know-how spravovaným v platformě iTutor pracuje modul iTutor AI, který implementuje AI s RAG architekturou:

• Každý z dokumentů i e-kurzů v iTutor lze označit jako nepřístupný pro AI. Tím lze zabránit úniku extrémně citlivých dat např. z pohledu GDPR.
• Na pozadí iTutor pracuje iTutor know-how change agent. Ten detekuje veškeré změny v know-how spravovaném v iTutor. Byla-li vydána např. nová verze dokumentu v iTutor Documents, tento agent změnu zachytí a předá o ní informaci dalšími agentovi, iTutor RAG Creatoru.
• iTutor RAG creator je agent také běžící na pozadí iTutor. Dokáže z každého know-how uloženého v iTutor vytvořit embeddingy pro RAG s použitím pokročilých metod popsaných v sekci Příprava. Vytvořené embeddingy ukládá do vektorové databáze Qdrant, která je součástí iTutor. iTutor RAG creator ukládá do vektorové databáze ke každému embeddingu odkaz na objekt, ze kterého byl vytvořen. To umožňuje komplexně řídit práva na základě vztahů, jak je popsáno v zabezpečení dat Uvnitř firmy.
• Obvykle se firmě nepodaří soustředit veškeré své know-how v jediném systému, zde iTutor. Know-how firmy je často kromě systému s AI funkcionalitou rozprostřeno v řadě dalších systémů, jako jsou relační databáze, např. MS SQL Server, systémy pro správu projektů, např. Jira, kolaborační platformy, např. MS SharePoint, CRM systémy, např. SalesForce, komunikační kanály, např. Slack, systémy zákaznické podpory, např. Zendesk, či ERP systémy, např. SAP.
  iTutor RAG creator má vlastní API konektor, pomocí kterého ho lze snadno propojit s téměř jakýmkoliv externím systémem, v kterém je uložena nějaká část know-how firmy. Tak lze do RAG vektorové databáze v iTutor zrcadlit firemní know-how ve formě embeddingů vytvořených iTutor RAG creatorem z libovolného jiného firemního zdroje.
• Když uživatel v iTutor AI zadá požadavek či dotaz, který chce zpracovat pomocí AI, zpracování proběhne dle principů podrobně popsaných výše v metodě RAG architektura:
  • Z dotazu uživatele iTutor AI vyrobí embeding pomocí extrakce témat z dotazu.
  • Ve vektorové databázi jsou vyhledány embeddingy blízké vyrobenému embedingu z dotazu, nalezené embedingy obsahují tudíž know-how související s dotazem.
  • Na základě aplikace pokročilého řízení přístupů na základě vztahů jsou vybrány jen ty nalezené embeddingy, na které má tazatel právo.
  • Prompt LLM používaného v iTutor AI je finálně tvořen textem dotazu uživatele, který je obohacen texty vyhledaných embedingů obsahující know-how související s dotazem, a do promptu jsou přidány instrukce, jak s těmito texty má LLM pracovat. Zjednodušeně, že LLM má odpovídat na základě nalezených textů z embedingů a ne na základě svých obecných znalostí.
  • V nastavení iTutor AI lze určit, jaký model LLM je používán, či jak se určuje blízkost embeddingů ve vektorové databázi.
  • Uživatel dostane odpověď od iTutor AI, což je odpověď použitého LLM, doplněná technologií RAG o odkazy na použité dokumenty, e-kurzy v iTutor, nebo objekty z externích systémů, v kterých si může ověřit správnost odpovědi AI.
• V iTutor AI je implementováno monitorovací systém, pomocí kterého mohou administrátoři analyzovat odpovědi AI a hodnocení těchto odpovědí od tazatelů. Na základě toho lze funkčnost iTutor AI i uložené podklady know-how optimalizovat.
• iTutor AI umožňuje svoji funkčnost „vytáhnout“ vně platformy iTutor. Zákazníci si mohou vytvářet na bázi Tutor AI své vlastní AI chatboty, určovat pro každého takového AI chatbota, na jaká data firemního know-how má právo a upravovat jeho design. Takovýto zákazníkem vytvořený AI chatbot mohou zákazníci umísťovat do svého intranetu či na své internetové stránky. Na firemních stránkách Kontis si můžete prohlédnout jednoho takového AI chatbota, vytvořeného v iTutor AI, pracujícího nad informacemi určenými v iTutor AI pro potenciální zákazníky Kontis.
  Platforma iTutor podporuje řadu technologií pro single-sign-on, jako je Microsoft Entra ID, AD FS, integrované ověření v AD. Má-li zákazník implementováno single-sign-on, může chatbot vytvořený v iTutor AI umístěný v intranetu zákazníka odpovídat zaměstnanci na základě jeho oprávnění k přístupu ke konkrétnímu know-how firmy.
• Existuje i samostatný produkt iTutor Chatbot odvozený z iTutor AI, v kterém si může kdokoliv snadno během pár minut vytvořit vlastního AI chatbota, metodou drag & drop do něj vhodit soubory a webové stránky, na základě kterých chatbot odpovídá. Takového chatbota pak lze provozovat na svých webových stránkách. iTutor Chatbota si můžete zkusit udělat na webu ai.itutor.eu, nejen si zde vyzkoušíte, jak LLM s RAG architekturou dokáže odpovídat na vaše dotazy na základě zpřístupněného know-how, ale případně můžete vytvořeného chatbota komerčně používat na svých stránkách k jakémukoliv účelu.

Schématický diagram fungování RAG v iTutor

Příklady využití

Na závěr se vrátíme k výše citovaným příkladům využití AI u zákazníka:

• Řada výrobních firem spravuje své know-how v iTutor, příklady z automotive si můžete prohlédnout zde. Know-how takové firmy bývá uloženo v iTutor Documents, kde jsou spravovány např. dokumenty s výrobními postupy, pracovní instrukce, směrnice, smlouvy. V kurzech iTutor LMS mohou být související informace obsažené např. v kurzech o Bezpečnosti práce. V externích systémech, jako je např. SAP, bývají spravovány kusovníky výrobků s jejich popisy, definice výrobních linek s pracovními místy apod.

  Pokud se uživatel s takto organizovaným know-how v iTutor AI zeptá „Jak se na lince pro výrobu produktu X upíná produkt do mechanismu linky“, iTutor AI nejspíše nalezne většinu souvisejících textů ze všech jmenovaných zdrojů, zejména pokud je SAP napojen pomocí iTutor AI API konektoru. Odpověď iTutor AI na prompt bude proto s vysokou pravděpodobností dostatečně přesná a výstižná. Díky připojeným odkazům v odpovědi iTutor AI na zdrojové objekty si může uživatel odpověď LLM ověřit přímo v odkazovaných objektech.

• Pokud se manažer v promptu iTutor AI zeptá, zda u konkrétního zákazníka něco neporušuje jím popsanou činnosti, a pokud ano, jaké z toho plynou sankce, iTutor AI nejspíše vyhledá nejen smlouvu se zákazníkem a v ní pasáže související s dotazem, ale najde, pokud existují, i související texty např. v přílohách smlouvy. To vše může být uloženo v iTutor Documents, nebo v nějakém externím systému napojeném přes iTutor AI API konektor. Dále iTutor AI může vyhledat komunikaci se zákazníkem o předmětu smlouvy, pokud tuto komunikaci má firma uloženou např. v MS Exchange a bylo realizováno propojení Microsoft Graph API s iTutor AI API konektorem. iTutor AI ověří, zda tazatel má na nalezené informace týkající se smluv a komunikace se zákazníkem právo. Pokud ano, dá tazateli pravděpodobně velmi podrobnou a konkrétní odpověď. Pokud tazatel na takovéto informace právo nemá, pokusí se iTutor AI vyhledat nějaké vzdáleněji související informace s dotazem. Např. nalezne ve směrnicích uložených v iTutor Documets obecná pravidla firmy pro práci a komunikaci se zákazníky. Poté opoví alespoň dle těchto informací. Tazatel si může ověřit v použitých zdrojích, které iTutor AI přidá na konec odpovědi, že LLM nehalucinuje.
• Viz výše popsaná možnost vytvářet a „vytahovat“ AI chatboty vně platformy iTutor, pokud má zákazník v iTutor implementované single-sign-on, může si např. vytvořit AI chatbota reprezentujícího pracovníka HR a tohoto chatbota umístit do intranetu firmy. Tento HR AI chatbot bude schopen odpovídat zaměstnancům jejich dotazy na HR oddělení firmy na základě informací, na které má konkrétní zaměstnanec právo plus na základě všem zaměstnancům přístupného know-how firmy o HR. Zeptá-li se např. zaměstnanec tohoto HR AI Chatbota na něco související s jeho pracovní smlouvou, chatbot mu bude nejspíše schopen přesně odpovědět, protože tento zaměstnanec má oprávnění ke čtení své pracovní smlouvy, a tudíž i HR AI chatbot, kterého se zaměstnanec ptá, bude mít přístup k informacím k jeho pracovní smlouvě. Obdobně bude HR AI Chatbot odpovídat jeho manažerovi s přístupem ke smlouvám podřízených. Zeptá-li se jiný zaměstnanec na pracovní smlouvu kolegy, žádné konkrétní informace od HR AI Chatbota nedostane.

Stručně shrnuto, iTutor je v oblasti AI platforma, která má plně implementovanou RAG architekturu a je schopna spravovat a AI zpracovávat veškeré firemní know-how. Navíc je schopna zpracovat svým AI know-how uložené v řadě dalších systému zákazníka. S poměrně nízkými náklady tak lze pomocí platformy iTutor implementovat používání AI nad veškerým know-how firmy. Řešení iTutor pro AI zpracování firemního know-how lze buď spustit ihned, nebo se pouze musí implementovat jednoduché API konektory na další firemní zdroje, kde je uloženo know-how, pokud není vše uloženo v iTutor Documents a e-kurzech v iTutor LMS. Náklady na experty při implementaci AI ve firmě jsou často vyšší než na HW a provoz technického řešení. Hotová platforma iTutor tyto náklady minimalizuje.