Nejdřív zdroj, potom model
Podnikové znalosti bývají rozdělené mezi dokumenty, wiki, smlouvy, databáze a lidi. RAG má smysl, když zaměstnanec potřebuje odpověď z těchto materiálů a samotné vyhledání několika souborů nestačí. Jazykový model umí nalezené podklady shrnout a zasadit do otázky. Nezaručí však, že podklad je správný, aktuální nebo dostupný správné osobě. Projekt proto začíná inventářem zdrojů a odpovědností, ne výběrem modelu podle výsledku veřejné demonstrace.
U každé sbírky určete vlastníka, frekvenci změn, pravidla přístupu a význam archivovaných verzí. Návrh právního postupu může mít jinou váhu než stará poznámka z chatu. Pokud se tyto dokumenty bez rozlišení sloučí do jediného indexu, systém může podat plynulou, ale věcně chybnou odpověď. Kvalita katalogu dokumentů je tedy součástí kvality výsledku. Někdy se vyplatí nejdříve vyčistit obsah a sjednotit názvy, protože žádný způsob vyhledávání neuspořádané znalosti sám nenapraví.
Jak funguje cesta od otázky k odpovědi
Typický tok přijme otázku, vyhledá relevantní úryvky, předá je modelu s pokynem odpovídat z doložených zdrojů a zobrazí výsledek s odkazy. Každý krok může selhat jinak. Dotaz nemusí odpovídat slovníku dokumentu, hledání může vybrat starou verzi, úryvek může ztratit důležitý kontext a model může spojit dvě neslučitelné věty. Microsoft popisuje RAG jako kombinaci retrieval vrstvy, sestavení kontextu a generování; zároveň zdůrazňuje omezený kontext modelu a potřebu vracet jen relevantní materiál.
Návrh ukázkového toku musí říci, které části otázky se použijí pro hledání, jak se filtrují oprávnění a jaké informace se zobrazí člověku. Odpověď může obsahovat klikatelné zdroje, datum platnosti a upozornění na chybějící důkaz. U složitější otázky může být poctivější ukázat několik protichůdných podkladů než vygenerovat jediný závěr. Důležité je odlišit tvrzení obsažené v dokumentu od doporučení, které z něho model odvozuje. To zlepší kontrolu i důvěru uživatelů.
Indexace a vyhledávání nejsou jednorázový import
Dokument je třeba načíst, rozdělit na užitečné celky, připojit metadata a vytvořit vyhledávací reprezentaci. Velké kusy textu mohou do odpovědi přinést šum, příliš malé ztratí souvislost. Tabulky, přílohy a skeny vyžadují jiný postup než čistý text. U každého úryvku zachovejte vazbu na původní soubor, verzi, lokaci a přístupové oprávnění. Bez této vazby nelze dodat spolehlivou citaci ani bezpečně odstranit obsah po změně práv.
Porovnejte klasické fulltextové hledání, sémantické vektory a jejich kombinaci na skutečných otázkách. Dotaz na přesné číslo smlouvy často těží z textového hledání, dotaz formulovaný jinými slovy může pomoci sémantické podobnosti. Přerankování kandidátů může zlepšit pořadí, ale prodlouží odezvu a zvýší cenu. Volba velikosti úryvků a počtu výsledků má vycházet z měření, ne z univerzálního návodu. Uchovávejte verzi indexačního postupu, aby šlo při poklesu kvality zjistit, co se změnilo.
Oprávnění musí platit i po indexaci
Člověk nesmí dostat odpověď z dokumentu, který by nemohl otevřít přímo. To platí i pro nepřímé prozrazení v souhrnu. Bezpečný systém uplatní přístupová pravidla už při hledání nebo před předáním vybraného textu modelu; pouhé skrytí odkazu ve výsledku nestačí. Při změně role zaměstnance se musí promítnout nové oprávnění do hledání bez nebezpečného zpoždění. Stejně důležité je odstranění či omezení dokumentu, jehož obsah už nemá být dostupný.
Microsoft dokumentuje filtrování na úrovni dokumentů pro RAG scénáře, ale konkrétní mechanismus závisí na použitém produktu a zdroji identit. Vlastní implementace potřebuje testy s několika rolemi a skutečně odlišným přístupem. Ověřte také cache, sdílené konverzace, analytické logy a export odpovědí. Pravidlo přístupu ztrácí smysl, pokud správná kontrola funguje jen při prvním dotazu, ale citlivý úryvek zůstane v historii dostupné jiné skupině.
Vyhodnocujte hledání zvlášť od generování
Dobrý model nemůže podložit odpověď, pokud vyhledávání nevrátilo potřebný dokument. Sestavte sadu reprezentativních otázek a ke každé označte očekávané zdroje, přípustnou odpověď a situace, kdy je správné odmítnout závěr. Měřte, zda se správný zdroj dostal mezi výsledky, zda nebyl překryt starou verzí a zda v něm byl potřebný odstavec. Microsoft Foundry rozlišuje evaluaci retrieval části a výsledné odpovědi, což pomáhá určit, kde změna skutečně pomůže.
V druhém kroku hodnoťte věcnou správnost, úplnost, citace, míru nepodložených tvrzení a srozumitelnost. Automatická skóre mohou usnadnit srovnání verzí, ale u důležitých procesů je doplňte lidskou revizí. Testujte běžné, nejednoznačné i nepřátelské dotazy a všechny jazyky, které budou používané. Nezlepšujte systém pouze na stejné sadě, na níž pak hlásíte úspěch. Část příkladů ponechte stranou jako nezávislou kontrolu po změně modelu, indexu nebo instrukcí.
Citace, nejistota a hranice použití
Citace má vést na skutečný úryvek, z něhož tvrzení vyplývá. Odkaz na dokument jako celek nestačí, pokud obsahuje desítky stran nebo více protichůdných verzí. Uživatel musí umět zdroj otevřít a poznat datum jeho platnosti. Pokud nalezené texty neodpovídají, systém by měl říci, že odpověď nemá oporu, a nabídnout vyhledané podklady nebo cestu k člověku. Sebejistý tón bez důkazu zvyšuje riziko použití chybného výsledku.
RAG je pomůcka pro práci se znalostmi, ne automatické schválení rozhodnutí. U právních, finančních, bezpečnostních nebo personálních závěrů stanovte, co může systém pouze navrhnout a co musí potvrdit oprávněná osoba. Při prezentaci mějte viditelnou hranici: odpověď může shrnout schválený interní postup, ale nemusí zaručit jeho správnost pro každý nový případ. Výstup doplňte možností nahlásit chybný zdroj a při opakovaných problémech dočasně stáhnout konkrétní sbírku.
Chraňte systém před instrukcemi v dokumentech
Vyhledaný dokument je datový podklad, nikoli správce aplikace. Může obsahovat text, který se snaží změnit instrukce modelu, požádat o další údaje nebo vyvolat nechtěnou akci. OWASP upozorňuje, že samotný RAG prompt injection neodstraňuje. Aplikační vrstva proto odděluje obsah zdroje od pravidel systému, omezuje dostupné nástroje a každou citlivou akci kontroluje mimo model. Nestačí přidat do promptu větu „ignoruj škodlivý text“.
Při pilotu vložte do testovacích dokumentů záměrně podezřelé instrukce a ověřte, že se nepřenesou do oprávnění ani do výsledné akce. Sledujte také možnost otrávení zdroje: kdo smí dokument vytvořit, změnit a označit jako schválený? Zálohy, index a historie musí umožnit dohledat změnu, která kvalitu náhle zhoršila. Bezpečnostní kontrola souvisí s redakčním procesem dokumentů stejně jako s konfigurací modelu. Oddělené role jsou zde důležitější než složitý chatbot.
Pilot a dlouhodobý provoz
První pilot omezte na jednu užitečnou sbírku a skupinu lidí, kteří znají správné odpovědi. Změřte čas k nalezení informace, přesnost zdrojů, podíl odpovědí bez dostatečného důkazu, odezvu a cenu jedné skutečně vyřešené otázky. Evidujte chyby podle příčiny: neaktuální dokument, špatné vyhledání, nesprávná syntéza nebo chybějící oprávnění. Takový rozpad ukáže, zda investovat do obsahu, indexu, modelu či uživatelského rozhraní.
Po spuštění plánujte reindexaci, mazání, aktualizaci oprávnění, přehled selhání a pravidelný test na stálé sadě otázek. Uživatelé potřebují vědět, kam hlásit chybu a kdy se opraví zdroj. Pro některé úlohy může být levnější a přesnější dobré fulltextové vyhledávání s jasnou navigací. To není neúspěch AI projektu, ale správný výsledek srovnání. EXCOIN může navrhnout a ověřit vhodný přístup podle skutečných dokumentů a provozních hranic; zde neuplatňujeme nedoložené sliby přesnosti ani návratnosti.