# Použití RAG jako druhého mozku: Neexistuje nejlepší řešení, pouze nejvhodnější scénář V posledních dvou letech se téměř všechny týmy pracující na velkých jazykových modelech (LLM) snažily o totéž: přidat ke svému modelu RAG. Důvod je přímý. Velké jazykové modely mají dva zásadní vrozené nedostatky – znalosti mají datum expirace a mají sklon si vymýšlet. Od RAG se očekávalo, že vyřeší oba problémy současně: poskytne mu nejnovější externí materiály a nechá ho odpovídat na základě těchto materiálů. To vedlo k rozšířené mylné představě: **RAG je technologie. Když vyberete tu správnou, vyhráli jste.** Realita je ale taková: RAG není jedna technologie. **RAG je souhrnné označení pro třídu architektur.** Různé scénáře vyžadují zcela odlišné architektonické volby. Stejně jako mají velké jazykové modely různá využití – 4B lehký model není k ničemu, je praktičtější pro inferenci na zařízení, nízkou latenci a nízkonákladové scénáře než model s biliony parametrů. Bilionový model má silnou inferenci, ale podniky si ho nemohou dovolit nasadit. Každý má své místo. Mezi RAG řešeními existují stejné rozdíly. Žádné řešení není absolutně nejlepší. Existuje pouze to, které je nejvhodnější pro daný scénář. **Tento článek chce říci: v konkrétním scénáři „poznámky + dokumenty + RAG“ – tedy vytvoření druhého mozku pomocí AI – jaké řešení je optimální. A proč.** --- ## I. Co je na RAG v roce 2025 skutečně těžké Demo RAG zvládnete za odpoledne. Ale problémy, které se objeví v produkčním prostředí, se soustředí do tří dimenzí: ### Indexování není jednorázová práce, je to dlouhodobá zátěž „Vložit všechny dokumenty do vektorové databáze“ zní jednoduše. Ale v praxi: při upgradu modelu je třeba znovu zpracovat 10 milionů dokumentů, což představuje přibližně 50 miliard tokenů, jen náklady na API činí 300–650 USD. Při mazání dokumentů mohou ve vektorové databázi zůstat nevyčištěné zastaralé položky po mnoho dní. Při změně oprávnění, pokud se index dokumentů odcházejícího zaměstnance včas neaktualizuje, existuje několikahodinové bezpečnostní okno. Při omezeních platformy nástroje jako Slack, Notion již omezují hromadné stahování dat třetími stranami. ### Latence je víceúrovňový řetězec Každý dotaz prochází: porozumění problému → vektorové vyhledávání → řazení výsledků → skládání kontextu → generování odpovědi AI. Pokud se zpomalí kterákoli úroveň, zpomalí se celek. Inference LLM zabírá 60–80 % času od konce do konce. ### Náklady rostou s objemem dat Čím více dokumentů, tím více zpracování. Všechny tři články se nafukují. **Společný kořen: Nejprve musíte z dokumentů vytvořit index, abyste mohli začít dotazovat.** Toto je RAG „centralizovaný na vyhledávání“. --- ## II. Dva hlavní typy řešení ### Řešení 1: Vektorová databáze + statický index Dokumenty jsou nejprve rozřezány, převedeny a uloženy do vektorové databáze. Při dotazu se z databáze vyhledá nejpodobnější obsah. **Vhodné pro:** Obrovské množství dokumentů, pevný obsah. **Nevhodné pro:** Často se měnící obsah, každá úprava vyžaduje přestavbu indexu. ### Řešení 2: Reálný datový proud + událostmi řízený Změna dat spouští aktualizaci, index se synchronizuje v reálném čase. **Vhodné pro:** Čerstvost v řádu sekund. **Nevhodné pro:** Složitá infrastruktura, vyžaduje cache vrstvu, mechanismus událostí, dvojí úložiště. ### Existuje jeden typ scénáře, který obě cesty neobslouží Advokát sepisuje shrnutí případu. 200 poznámek k případu, 50 právních dokumentů. Píše a zároveň vyhledává – „Jak se argumentovalo v dřívějším případě o zákazu konkurence?“ Po napsání odstavce obsah změní a za pár sekund vyhledá znovu. Nový obsah by již měl být ve výsledcích vyhledávání. Charakteristiky tohoto scénáře: **Obsah se často mění** (není to statická knihovna), **dotazování a tvorba se prolínají** (píše a zároveň vyhledává), **uživatel je běžný člověk** (nepíše kód, nerozumí vektorovým databázím), **data a soukromí jsou červenou linií**. **Toto není požadavek na „vyšší technickou složitost“. Je to požadavek na to, že „technické řešení by nemělo být tak těžké“.** --- ## III. Od Search-centric k Memory-centric Hlavní proud řešení předpokládá, že **znalostní báze je statická**. Dotaz je jednorázové vyhledávání. Toto paradigma se nazývá **Search-centric RAG**. Model: znalostní báze = sbírka dokumentů, RAG = inteligentní vyhledávání. Ale vytvoření druhého mozku vyžaduje jiné paradigma. Každý den píšete poznámky, upravujete je, mažete je, importujete nové dokumenty. Znalosti neustále rostou a vyvíjejí se. Chcete, aby AI nejen „vyhledávala“, ale **neustále „pamatovala“ vaše znalosti a přirozeně je používala, když je potřebujete.** Toto je **Memory-centric RAG**. Model: znalostní báze = neustále se vyv��jející paměť, RAG = přirozený přístup. | | Search-centric RAG | Memory-centric RAG | | --- | --- | --- | | Chápání znalostí | Statická sbírka dokumentů | Neustále rostoucí paměť | | Čerstvost dat | Závisí na frekvenci aktualizace indexu | Reálný čas, zapamatováno ihned po napsání | | Způsob dotazování | Aktivní vyhledávání | Přirozená konverzace | | Vztah k tvorbě | Vyhledávání a tvorba jsou oddělené | Prolínání – úprava je aktualizace paměti | | Typický scénář | Podnikové vyhledávání, FAQ k politikám | Osobní správa znalostí, druhý mozek | **Tato dvě paradigmata se navzájem nenahrazují. Slouží zcela odlišným scénářům.** Jako vyhledávač a osobní asistent. --- ## IV. Jakou architekturu Memory-centric RAG vyžaduje? Čtyři požadavky na architekturu: **1. Nezávislost na předběžném indexování.** Každá úprava by vyžadovala přestavbu indexu, o reálném čase nemůže být řeč. Vyhledávací systém musí sdílet data s editorem – obsah se změní, další dotaz to odrazí. **2. Minimální využití kontextu.** Poznámky jsou soukromá data, nelze nahrávat vše. Ale AI potřebuje vidět informace, aby mohla odpovědět. Rovnováha: přenést pouze nejrelevantnější věty, komprimovat fragmenty, po přenosu smazat. **3. Generační schopnosti pomocí nejlepšího cloudového modelu.** Uživatel se neobtěžuje, server vidí pouze minimální kontext. **4. Úprava je aktualizace paměti.** Změna se okamžitě projeví v paměti, příští dotaz ji již odráží. --- ## V. Praxe Memory-centric RAG v NoteRich ### Poznámky jsou vždy lokálně, plná data se nenahrávají Poznámky jsou uloženy lokálně v prohlížeči. Není to povoleno (náklady by explodovaly) ani by to nemělo být (soukromí uživatele). ### Při dotazu se přenáší pouze minimální nezbytný kontext Přenášejí se pouze nejrelevantnější nalezené věty, komprimované fragmenty. Po zpracování na serveru jsou smazány – neukládají se, nezaznamenávají, netrénuje se na nich. **Malé množství nahrávání je nevyhnutelné, plnému nahrávání se lze zcela vyhnout.** ### Žádné předběžné indexování, úprava je paměť Nebuduje se předem vektorová databáze. Při psaní poznámek je vyhledávací systém již online. Změny obsahu se projeví v reálném čase. ### Vícekriteriální hodnocení + přesnost na věty + bezstavový server Nespoléhá se pouze na sémantickou podobnost. Vrací přesné věty, deduplikuje a slučuje. Backend neukládá, nezaznamenává, netrénuje. --- ## VI. Čtyři úrovně druhého mozku **První úroveň: Paměť.** AI si „pamatuje“ všechny napsané poznámky. **Druhá úroveň: Asistence při tvorbě.** Generování nového obsahu na základě starých poznámek. **Třetí úroveň: Zpětná vazba v reálném čase.** Po napsání odstavce to AI okamžitě vnímá. **Čtvrtá úroveň: Úprava je paměť.** Úprava obsahu vygenerovaného AI se okamžitě dostane do paměti. Uzavřená smyčka znalostního prostředí. --- ## VII. Přiznat si hranice a pak je překročit ### Hranice 1: Výpočetní kapacita prohlížeče Online verze běží zcela v prohlížeči. Testováno s desítkami tisíc textů a desítkami milionů znaků, velmi plynulé. **Do několika set tisíc dokumentů bez problémů, nad tento objem výkon klesá.** Toto je fyzická hranice prohlížeče. Ale osobní uživatelé se k této hranici téměř nikdy nedostanou. Pokud ano – máte podnikové požadavky. V offline nasazení běží stejná architektura na serveru a škáluje se podle potřeby. ### Hranice 2: Multimodální podpora Aktuálně se zaměřuje na text. OCR obrázků, přepis zvuku, analýza videa – online verze je omezena výpočetním výkonem prohlížeče. Podnikové offline nasazení může integrovat vlastní řešení na serveru. **Textová paměť je základ, multimodální paměť je upgrade.** ### Hranice 3: Složité uvažování napříč dokumenty Vícekrokové uvažování je úkolem fáze generování, nikoli fáze vyhledávání. Vyhledávání pouze „hledá“, ne „odvozuje“. NoteRich umožňuje spotřebitelským modelům dosahovat praktických výsledků díky vysoce kvalitnímu kontextu. ### Hranice 4: Úplně offline Špičkové velké jazykové modely nelze spouštět na běžných počítačích – to je fyzikální zákon. Offline nasazení může připojit lokální modely nasazené podnikem. --- ## VIII. Offline řešení Advokátní kanceláře, nemocnice, finanční instituce – data se nesmí dostat mimo interní síť. Offline nasazení zabalí architekturu Memory-centric jako jedinou komponentu backendu, nasazení jedním kliknutím, celý proces neopustí podnikovou síť. --- ## IX. Konečná vize **Search-centric RAG řeší problém „najít“.** Memory-centric RAG řeší problém „pamatovat si“. Tyto dva přístupy si nekonkurují. NoteRich pouze na cestě Memory-centric RAG učinil několik přímočařejších rozhodnutí. **Rychlé, levné, vysoce kvalitní.** Umožňuje běžným lidem začít spravovat znalosti pomocí AI do 30 sekund a zároveň podnikům plně důvěřovat v rámci firewallu. **[Vyzkoušet NoteRich →](https://noterich.com/app/)** *Open-source koncept projektu [github.com/Lisanoterich/memory-centric-rag](https://github.com/Lisanoterich/memory-centric-rag)*