Představte si, že vaše firma vlastní 500 GB dokumentů a vy potřebujete AI asistenta, který na jejich základě bude přesně odpovídat. Běžné chatovací aplikace mají limitovanou paměť a klasické vyhledávání podle klíčových slov je neefektivní. Řešením je technologie RAG.
Definice RAG (Retrieval-Augmented Generation)
RAG (Generování rozšířené o vyhledávání) je metoda, která spojuje sílu velkých jazykových modelů (LLM) s vašimi externími, soukromými daty. Místo toho, aby se AI spoléhala jen na to, co se naučila při tréninku (což může být zastaralé), RAG jí umožňuje „nahlédnout do učebnice“ – vaší databáze – v reálném čase.
Jak RAG funguje ve 3 krocích
Celý proces transformuje statické dokumenty na dynamické znalosti:
- Retrieval (Získávání): Uživatelský dotaz (např. „Detaily smlouvy s CodeCloud“) se převede na čísla (vektory). Systém následně provede sémantické vyhledávání ve vektorové databázi a najde pasáže, které významově odpovídají dotazu, nikoliv jen podle klíčových slov.
- Augmentation (Rozšíření): Nalezené relevantní části dokumentů se vloží přímo do promptu pro AI. Tím modelu poskytneme kontext a aktuální fakta, která původně neznal.
- Generation (Generování): AI asistent vygeneruje odpověď. Díky předchozím krokům si nevymýšlí (nehalucinuje), ale syntetizuje odpověď přímo z předložených firemních dat.
Využití vektorové databáze je v této architektuře naprosto klíčové, protože přináší schopnost sémantického vyhledávání. Na rozdíl od tradičních databází, které hledají přesnou shodu slov, vektorová databáze „chápe“ význam textu díky jeho matematické reprezentaci. To znamená, že pokud se uživatel zeptá „Jaké jsou benefity pro zaměstnance?“, systém dokáže najít relevantní pasáže v dokumentech, i když obsahují jiná slova jako „zaměstnanecké výhody“, „prémie“ nebo „dovolená navíc“. Tím se dramaticky zvyšuje šance, že AI dostane ten správný kontext a odpoví přesně, i když uživatel nepoužil ta „správná“ klíčová slova.
Architektura RAG (Retrieval Augmented Generation) s vektorovou databází
Infografika vysvětluje, jak funguje architektura RAG (Retrieval Augmented Generation), konkrétně model obohaceného generování s využitím vektorového vyhledávání podle přístupu společnosti amberSearch. Cílem této metody je umožnit umělé inteligenci (AI) využívat pro své odpovědi vaše vlastní, interní firemní data.
Schéma je vodorovnou přerušovanou čárou rozděleno na dvě hlavní části: spodní Přípravnou fázi a horní Proces dotazování v reálném čase.
1. Přípravná fáze (Indexování dat)
Tato část se nachází ve spodní polovině diagramu a probíhá „na pozadí“ před samotným kladením dotazů. Jejím účelem je připravit data pro vyhledávání.
- Firemní data a znalosti (In-house Information): Vlevo dole jsou zobrazeny ikony reprezentující různé zdroje vašich dat, jako jsou PDF dokumenty, soubory DOCX, e-maily, databáze a firemní Wiki.
- Proces indexování a vektorizace: Šipka směřující doprava naznačuje proces, kterým tato data procházejí. Texty se rozdělí na menší části a převedou se na tzv. „embeddingy“ – matematické vektory, které zachycují jejich sémantický význam.
- Vektorový index / Databáze: Výsledek tohoto procesu se ukládá do speciální databáze, znázorněné ikonou krychle uprostřed dole.
Poznámka: Jak uvádí text pod touto částí, klíčovou vlastností Vektorového indexu je, že umožňuje vyhledávat informace podle jejich skutečného významu, nikoliv pouze na základě shody klíčových slov.
2. Proces dotazování (V reálném čase)
Horní polovina diagramu ukazuje, co se děje, když uživatel položí otázku. Celý tento proces řídí centrální prvek zvaný Firemní Vyhledávání (Orchestrator), znázorněný ikonou mikročipu. Kroky jsou očíslovány od 1 do 6:
- Dotaz: Uživatel (ikona vlevo) položí otázku přirozeným jazykem.
- Sémantické vyhledávání: Orchestrator pošle tento dotaz „dolů“ do Vektorového indexu, kde se hledají informace významově nejpodobnější položené otázce.
- Relevantní kontext: Z indexu se vrátí ty nejdůležitější nalezené kousky informací. To je tzv. Relevantní kontext.
- Obohacený prompt (Dotaz + Kontext): Orchestrator spojí původní dotaz uživatele s nalezeným kontextem a vytvoří vylepšené zadání („obohacený prompt“). Tento prompt pošle do AI modelu – Generativního LLM (velký jazykový model, ikona mozku vpravo).
- Vygenerovaná odpověď: LLM zpracuje dodaný kontext a na jeho základě vytvoří přesnou a srozumitelnou odpověď, kterou pošle zpět Orchestratoru.
- Finální odpověď: Orchestrator předá hotovou odpověď zpět uživateli.
Shrnutí: Díky této architektuře AI neodpovídá pouze na základě svých obecných znalostí z tréninku, ale aktivně využívá vaše aktuální firemní data jako spolehlivý zdroj informací pro vytvoření přesné odpovědi.
Praktická implementace
V praxi vývoj takového řešení zahrnuje nastavení prostředí (např. v Pythonu), inicializaci vektorové databáze a vytvoření pipeline, která dokumenty rozčlení a uloží. Výsledkem je webové rozhraní (např. přes Flask), kde se manažer může ptát na interní směrnice a dostávat okamžité, ozdrojované odpovědi.
Výsledek? Bezpečný, rychlý a na datech založený AI systém, který eliminuje halucinace a pracuje s vaším unikátním know-how.
Co je klíč k úspěchu? Kalibrace dat
RAG není jen o zapojení „černé skříňky“. Pro kvalitní výsledky je nutné správně nastavit zpracování dat:
- Chunking strategie (Dělení textu): Rozdělení dokumentů na menší části. Právní dokumenty vyžadují jiné dělení než chaty zákaznické podpory, aby se neztratil kontext.
- Embedding (Vkládání): Výběr modelu, který převádí text na vektory (např. all-MiniLM-L6-v2).
- Vektorová databáze: Úložiště pro vaše data (např. ChromaDB), které umožňuje rychlé sémantické hledání.
Zdroje:
Přepis videa:
(00:00) Vaše společnost má 500 gigabajtů dokumentů na svém serveru a dostanete za úkol připojit AI asistenta, podobného ChatGPT, který bude odpovídat na otázky o těchto dokumentech. Říkáte si: „Jak to mám sakra zvládnout?“ Ze své zkušenosti víte, že typické chatovací aplikace neumí přijmout více než tucet souborů.
Musíte tedy použít jinou metodu, která umožní AI prohledávat, číst a rozumět všem souborům. Ale jak? Možná vás napadne vytvořit chytrý algoritmus, který bude prohledávat názvy dokumentů a jejich obsah a seřadí je podle relevance. Brzy si však uvědomíte, že to znamená, že při každém vyhledávání uživatele by bylo nutné prohledat celých 500 GB dokumentů.
(00:37) A to je velmi neefektivní způsob, jak to udělat. Možná se tedy pokusíte o něco jiného – provedete předběžné zpracování, kdy preventivně shrnete všechny dokumenty do prohledávatelných částí. Ale také si uvědomíte, že v tomto případě to pravděpodobně nebude přesný způsob, jak to udělat. Zkusme jinou metodu.
Spojení Dvou Světů
(00:54) Proč nezkusíme spojit tyto dva nápady dohromady a získat to nejlepší z obou světů? Začněme velkým jazykovým modelem (LLM). Víme, že základní myšlenka toho, jak LLM skutečně přijímají vstup, je word embedding neboli vkládání slov. To znamená, že lidský jazyk je převeden na numerickou reprezentaci, protože počítače neumí myslet ve slovech, ale v číslech.
(01:11) Je tedy možné, že místo prohledávání celých 500 GB dokumentů v podstatě uložíme tyto dokumenty tak, že zachováme jejich sémantiku – tedy význam těchto slov – do vektorového vložení a uložíme je do databáze jako vektory? A pokud to dokážeme, možná je dokážeme načíst rychleji tím, že rozdělíme kontext na části ve vektorové databázi, aby je AI asistent mohl vejít do svého kontextového okna a generovat z toho výstup.
Co Je RAG?
(01:35) Tato metoda se nazývá RAG neboli Retrieval Augmented Generation (generování rozšířené o získávání). Řekněme, že jeden z případů použití AI asistenta ve společnosti je pokládat otázky typu: „Můžeš mi říct něco o loňské servisní smlouvě s CodeCloud?“
Abychom porozuměli tomu, jak RAG funguje, musíme ho rozdělit na tři různé kroky: Retrieval (získávání), Augmented (rozšíření) a Generation (generování).
Krok 1: Retrieval (Získávání)
(01:52) Stejně jako jsme převedli dokumenty na vektorová vložení, abychom je uložili do databáze, provedeme přesně stejný krok pro otázku, která zní: „Můžeš mi říct něco o loňské servisní smlouvě s CodeCloud?“
(02:13) Jakmile je vygenerováno vložení slov pro otázku, je vložení otázky porovnáno s vložením dokumentů. Tento typ vyhledávání se nazývá sémantické vyhledávání, kde místo vyhledávání podle statických klíčových slov se k nalezení relevantního obsahu používá význam a kontext dotazu, který je porovnáván s existujícími dokumenty.
Krok 2: Augmentation (Rozšíření)
(02:31) Rozšíření v RAG se týká procesu, kdy jsou získaná data vložena do promptu za běhu. Možná si říkáte, proč je to tak výjimečné? Typicky se AI asistenti spoléhají na to, co se naučili během předběžného tréninku, což jsou statické znalosti, které mohou velmi rychle zastarat.
Místo toho je naším cílem, aby se AI asistent spoléhal na aktuální informace ve vektorové databázi. Za běhu tedy musíme být schopni poskytnout AI asistentovi důležité detaily, které by mohly pomoci odpovědět na výše uvedenou otázku.
(02:56) V případě RAG jsou výsledky sémantického vyhledávání připojeny k promptu, což v podstatě slouží jako rozšířené znalosti. Takže pro vaši společnost je AI asistentovi poskytnuta informace o dokumentech vaší společnosti, které jsou skutečné, aktuální a soukromé datové sady. To vše se může dít bez nutnosti dolaďovat AI model a upravovat velký jazykový model.
Krok 3: Generation (Generování)
(03:14) Posledním krokem RAG je generování. V tomto kroku AI asistent generuje odpověď na základě sémanticky relevantních dat získaných z vektorové databáze.
Původní prompt, který říká: „Můžeš mi říct něco o loňské servisní smlouvě s CodeCloud?“, AI asistent nyní prokáže své porozumění znalostní bázi vaší společnosti pomocí dokumentů, které se vztahují k servisním smlouvám v CodeCloud. A protože počáteční prompt specifikuje kritérium „loňský rok“, krok generování použije vlastní uvažování k práci s poskytnutými daty, aby získal nejlepší odpověď na otázku.
Síla RAG a Nutnost Kalibrace
(03:43) RAG je velmi mocný systém, který může okamžitě zlepšit hloubku znalostí nad rámec jeho tréninkových dat. Ale stejně jako u jakéhokoli jiného systému je naučit se, jak kalibrovat, získaná dovednost, kterou je třeba se naučit, abyste dosáhli lepších výsledků.
(04:00) Například vědět, jak rozdělit vaše data do částí před jejich uložením do vektorové databáze, je kritické rozhodnutí, které určí účinnost RAG. Abyste nastavili systém RAG, musíte použít různé strategie:
- Chunking strategie – kde určíte velikost a překrytí každé části
- Embedding strategie – rozhodnout, který embedding model použít k převodu vašich dokumentů na vektorová vložení
- Retrieval strategie – kde kontrolujete práh toho, jak podobná slova musí být, stejně jako další filtry, které byste mohli chtít přidat do datové sady
Různé Přístupy Pro Různá Data
(04:39) Nastavení systému RAG bude vypadat odlišně od jednoho systému k druhému, protože to silně závisí na datové sadě, kterou se snažíte uložit. Například právní dokumenty budou vyžadovat jinou chunking strategii než například přepis zákaznické podpory.
(04:56) Je to proto, že právní dokumenty často mají dlouhé strukturované odstavce, které je třeba zachovat, zatímco konverzační přepis může být v pořádku s rozdělením na úrovni vět s vysokým překrytím pro zachování kontextu.
Praktická Ukázka
(05:13) Nyní, když jsme pokryli koncepční prvky RAG, podívejme se, jak to vypadá na praktické úrovni. Abychom tomu lépe porozuměli, můžeme se podívat na tuto laboratoř speciálně zaměřenou na to, jak používat RAG.
Když otevřu laboratoř, jsem rovnou vržen do skutečné mise: 500 GB firemních dokumentů musí být přeměněno v okamžité, přesné odpovědi pomocí systému RAG.
Nastavení Vývojového Prostředí
(05:30) V první úloze jsme požádáni o nastavení vývojového prostředí. Vytvořil jsem Python virtuální prostředí, aktivoval ho, nainstaloval UV a poté stáhl ChromaDB, Sentence Transformers, OpenAI a Flask. Malý značkovač s nápisem „ready“ potvrzuje, že jsem připraven. Testy kontrolují, že VENV existuje, UV je k dispozici a všechny čtyři balíčky jsou nainstalovány – hezky a čistě.
Prohlížení Dokumentů
(05:52) V další otázce jsme požádáni, abychom si prohlédli trezor dokumentů TechCorp. Prošel jsem simulovaným repozitářem Markdown dokumentů – příručky pro zaměstnance, specifikace produktů, poznámky ze schůzek a často kladené otázky. Klíčovým poznatkem je, že s nimi budeme zacházet jako se skutečným podnikovým korpusem a zpřístupníme je prohledávání podle významu, nejen podle klíčových slov.
Inicializace Vektorové Databáze
(06:10) V následující otázce jsme požádáni, abychom inicializovali naši vektorovou databázi. Spustil jsem ChromaDB lokálně pomocí perzistentního klienta a vytvořil kolekci nazvanou „techcorp_docs“. Test ověřuje, že existuje adresář ChromaDB a inicializační skript je přítomen. Toto je naše úložiště AI mozku.
Chunking Strategie
(06:32) V další otázce jsme požádáni, abychom se naučili chunking strategii. Napsal jsem malý skript, který rozděluje text s velikostí 500 a překrytím 100. To zachovává kontext napříč hranicemi a zlepšuje kvalitu získávání. Vytiskne statistiky částí a zapíše ověřovací soubor s počtem částí. Test kontroluje, že skript existuje a výstupní soubor je platný. Chunking je kritický pro přesnost.
Porozumění Embeddingu
(06:50) V další otázce jsme požádáni, abychom porozuměli embeddingu. Načetl jsem „all-MiniLM-L6-v2“ z Sentence Transformers, zakódoval několik krátkých vět a vypočítal podobnosti. Test kontroluje, že soubor s výsledky existuje a obsahuje hodnoty podobnosti.
(07:10) Velkou myšlenkou je, že otázky i dokumenty se stávají vektory, taktakže můžeme měřit význam, nejen slova. Takže „dogs allowed“ (psi povoleni) a „pets permitted“ (domácí mazlíčci povoleni) mají vysokou podobnost. Nicméně „remote work“ (vzdálená práce) nemá podobnost.
Napájení AI Mozku
(07:35) V další otázce jsme požádáni, abychom nakrmili AI mozek. Tady to všechno dohromady zapadá. Procházím dokumenty TechCorp, rozděluju soubory s velikostí 500 a krokem 400, vložím každou část pomocí „all-MiniLM-L6-v2“ a ukládám vektory plus metadata do kolekce „techcorp_docs“. Zaznamenává pokrok na soubor a zapíše shrnutí – celkem zpracovaných dokumentů a částí. Test potvrzuje, že skript pro načítání existuje, soubor dokončení je vytvořen a formát je platný. Toto je náš pipeline pro načítání znalostí.
Aktivace Sémantického Vyhledávání
(07:59) V další otázce jsme požádáni o aktivaci sémantického vyhledávání. Sestavil jsem malý skript vyhledávacího enginu, načetl kolekci, vložil tři dotazy ve stylu CEO a načetl nejlepší výsledky podle sémantické podobnosti. Zapíše výsledky do souboru, vytiskne strukturovaný výstup. Test zajišťuje, že skript existuje, soubory s výsledky existují a všechny tři dotazy proběhly.
Spuštění Webového Rozhraní
(08:22) V následující otázce jsme požádáni o spuštění jednoduchého webového rozhraní. Vytvořil jsem Flask aplikaci na portu 5000 a pak spustil běžící značkovač.
Testování Jako CEO
Jsme požádáni, abychom testovali jako CEO. Otevřu aplikaci a zkusím otázky typu „Jaké jsou pravidla pro domácí mazlíčky?“ Sleduji tok RAG – získávání, rozšíření, generování se zdroji. Pak označím test jako otestovaný. Tady září hodnota dema – odpovědi založené na našich soukromých dokumentech.
(09:09) S načítáním, rozšířením a generováním na místě jsme připraveni na uživatelské rozhraní pro kladení otázek. Máme kompletní systém RAG, který je rychlý, založený na datech a rozšiřitelný.
Klíčové Body, Na Které Dávat Pozor
Několik věcí, kterým jsem věnoval zvláštní pozornost na této cestě:
- Model: all-MiniLM-L6-v2, který je kompaktní a efektivní
- Chunking: velikost 500 s překrytím 400 pro test, krok 400 při načítání – obojí zachovává kontext pro lepší výsledky
- Úložiště: ChromaDB perzistentní klient s kolekcí „techcorp_docs“
- Web: jednoduchá Flask aplikace na portu 5000 pro rychlé hodnocení
- Bezpečnost: práh podobnosti udržuje nekvalitní shody venku, čímž snižuje halucinace
RAG je komplexnější technika, která zahrnuje:
- Vektorové vyhledávání relevantních dokumentů
- Dynamické skládání kontextu
- Kombinaci retrieval systému s generativním modelem
- Často i chunking dokumentů, embeddings atd.
-
R – Retrieval (Vyhledávání): Systém nejprve prohledá důvěryhodnou databázi a najde relevantní podklady k dotazu.
-
A – Augmented (Rozšíření): Původní uživatelský dotaz je „rozšířen“ o nalezená fakta.
-
G – Generation (Generování): AI model vygeneruje finální odpověď na základě těchto faktů, nikoliv jen ze své paměti.
