Vyberte otázky, které mají doložitelnou odpověď
Začněte konkrétní skupinou uživatelů a otázek: například postup při servisní výjimce nebo vysvětlení interního pravidla. U každé otázky určete, v jakém dokumentu by správná odpověď měla být a kdo za něj odpovídá. Pokud se znalost nachází jen v hlavách lidí nebo se pravidla navzájem vylučují, model problém neodstraní. Nejprve opravte zdroj. RAG podle původní výzkumné práce kombinuje vyhledání relevantních podkladů s generováním odpovědi; výběr podkladů proto přímo ovlivňuje věrohodnost výsledku. Ne každá úloha potřebuje generování, některé stačí dobře vyhledat.
Vymezte riziko chybné odpovědi. Interní přehled pro orientaci může připustit nižší jistotu, zatímco instrukce pro úkon s penězi nebo osobními údaji vyžaduje přesné podklady a lidskou kontrolu. Stanovte, kdy systém řekne, že odpověď nenašel, a kam člověka pošle. Zapište, zda se má vracet citace, odkaz na celý dokument nebo i číslo verze. Cílem není, aby model odpověděl na všechno, ale aby uživatel rychle našel správný a aktuální podklad. Měřte také případy, kdy je lepší nepodat žádnou odpověď.
Nejdřív spravte dokumenty a jejich vlastníky
Zmapujte úložiště, typy souborů, jazykové varianty a strukturu oprávnění. U každého zdroje určete vlastníka, datum platnosti, verzi a pravidlo vyřazení. Starý dokument s vyšším skóre vyhledávání může být horší než krátká aktuální instrukce. Ověřte, zda jsou texty strojově čitelné a zda tabulky či přílohy neztratí při převodu smysl. Pro výběr korpusu není cílem nasát všechno; vyberte soubor, jehož správnost lze udržovat. Dokument bez odpovědného správce bude časem rizikem i při perfektním modelu.
Připravte postup pro konflikt mezi zdroji. Když dvě směrnice uvádějí různé hodnoty, nesmí generátor tiše vytvořit kompromis. Lepší je zobrazit neshodu a předat ji vlastníkům. U každého dokumentu zachovejte identifikátor, původní umístění a metadata důležitá pro filtr. Při mazání či změně oprávnění se musí změna promítnout do indexu v předvídatelném čase. Zvažte, zda historické verze vůbec mají být pro běžného uživatele vyhledatelné. Rozhodnutí o jejich uchování patří datovému vlastníkovi, nikoli pouze správci vyhledávače.
Indexace a dělení textu jsou produktová rozhodnutí
Dlouhý dokument se obvykle dělí na menší části, které lze vyhledat a předat modelu. Příliš krátké úseky ztratí kontext; příliš dlouhé zhorší výběr a zvýší cenu. Dělení respektujte nadpisy, tabulky a hranice pravidel. Ke každému úseku uchovejte odkaz na celý zdroj a jeho platnost. Otestujte, zda otázka mířená na výjimku nevrací jen obecný úvod. Volbu délky neodvozujte z univerzálního čísla, ale ze vzorku vlastních dokumentů a dotazů. Stejně tak ověřte, jestli je důležité vyhledávat přesnými slovy, významově, nebo kombinací.
Vektorové vyhledávání může najít podobný význam, ale nemusí být nejlepší pro číslo smlouvy, zkratku nebo přesný název produktu. Klasické hledání může takové dotazy zvládnout lépe. Zvažte kombinovaný postup a případné přeuspořádání výsledků. Filtry podle týmu, jazyka, stavu dokumentu a data platnosti aplikujte před předáním úseků modelu. Zaznamenejte, které úseky se pro odpověď skutečně použily. Bez této evidence těžko rozlišíte chybu v indexaci od halucinace modelu. Každá změna strategie vyhledávání vyžaduje kontrolu, zda se nezhoršily jiné typy dotazů.
Oprávnění vynucujte před generováním
Uživatel smí vyhledat jen dokumenty, ke kterým má právo. Filtrování až po vygenerování odpovědi je pozdě, protože model už mohl citlivý obsah použít. Přeneste relevantní pravidla přístupu ze zdrojového úložiště nebo vytvořte spolehlivou mapu oprávnění a testujte její aktualizaci. Ověřte přímé otázky na cizí projekt, podobné názvy dokumentů a odebrání přístupu uprostřed práce. Zvláštní pozornost patří sdíleným týmovým dokumentům a tomu, zda metadata sama neprozrazují citlivou informaci. Model nemá právo oprávnění rozšiřovat.
Načtený text může obsahovat škodlivé instrukce, například pokyn ignorovat pravidla nebo odeslat obsah jinam. OWASP popisuje prompt injection jako samostatné riziko. Zdrojový dokument je data, nikoli důvěryhodná instrukce pro aplikaci. Omezte nástroje dostupné modelu, oddělte systémová pravidla a výsledky vyhledávání a nedávejte mu přístup k akcím, které nepotřebuje. Testujte útoky vložené do dokumentů a komentářů. Ani dobré promptové pokyny nenahradí serverové kontroly přístupu a schvalování citlivých operací člověkem.
Citace musí umožnit skutečné ověření
Odpověď by měla odkazovat na konkrétní použitý úsek a otevřít jeho původní dokument, nikoli pouze zobrazit titul souboru. Uveďte verzi nebo datum, pokud se pravidla mění. Když zdroj odpověď nepodporuje, citace ji nezachrání. Testujte, zda každé důležité tvrzení lze ze zdroje ověřit a zda je odkaz přístupný právě tomuto uživateli. U výpočtů a rozhodnutí s dopadem na zákazníka může být vhodnější ukázat podklad a nechat člověka odpověď sestavit. Rozhraní má jasně rozlišit doslovnou citaci, shrnutí a závěr modelu.
Pokud se najde několik možných zdrojů, ukažte rozdíly a časovou platnost. Nenuťte model volit jeden jen proto, že má kratší text. Při chybějícím dokladu má otevřeně přiznat nejistotu a nabídnout další postup. Uživatelé musí mít jednoduchou možnost nahlásit chybnou odpověď nebo neaktuální dokument. Zpětná vazba se má propojit s dotazem, vybranými úseky a verzí indexu bez zbytečného ukládání citlivých dat. Tak lze opravit příčinu a později ověřit, zda se problém nevrací.
Evaluační sada musí oddělit hledání od odpovědi
Sestavte otázky z reálné práce s očekávanými dokumenty a výsledky. Zahrňte běžné případy, přesné názvy, podobná pravidla, staré verze, otázky bez odpovědi a dotazy přes hranici oprávnění. Měřte, zda se správný úsek dostal mezi nalezené, zda výsledná odpověď stojí na zdroji, zda je úplná a zda správně cituje. Microsoft v dokumentaci RAG evaluátorů rozlišuje kvalitu retrieval a groundedness výsledku; podobné oddělení je užitečné i bez jejich konkrétních nástrojů. Při problému pak víte, zda upravit data, index, prompt nebo model.
Část sady nechte stranou pro nezávislou kontrolu, jinak se postup naučí jen testové otázky. Výsledky vyhodnocujte podle oddělení, jazyka a typu dokumentu; průměr může skrýt vážnou chybu v jednom procesu. U kritických odpovědí používejte lidskou kontrolu a jasnou rubriku. Vedle kvality sledujte čas odpovědi, náklad a počet dotazů, které končí předáním člověku. Určete minimální přijatelný výsledek před pilotem. Po vydání doplňujte nově zjištěné chyby, ale zachovejte stabilní základ pro porovnání verzí.
Aktualizace a provoz musí být součást návrhu
Změna dokumentu se má v indexu projevit ve známé době; smazání či odebrání oprávnění může vyžadovat rychlejší reakci. Sledujte úspěšnost importu, počet vyřazených souborů, stáří indexu a chyby převodu tabulek. Po aktualizaci ověřte několik klíčových dotazů. Při selhání importu nesmí systém tiše nabízet staré pravidlo jako aktuální. Vlastník dokumentu má vědět, jak zjistí, že se změna propsala. Provozní návod popíše obnovu indexu, návrat předchozí konfigurace a kontakt pro spor o správnost obsahu.
Verzujte způsob dělení, vyhledávání, prompt, model i index. Když se kvalita zhorší, potřebujete zjistit, co se změnilo a jaký postup vytvořil konkrétní odpověď. Monitorujte dostupnost a zatížení, ale chraňte obsah dotazů v logách. Stanovte dobu uchování, role a postup pro odstranění zaznamenaného osobního údaje podle skutečných pravidel. Výpadek generování by neměl odříznout člověka od původních dokumentů. RAG má zrychlit přístup ke znalosti, nikoli se stát jediným způsobem, jak ji firma může získat.
Poznejte, kdy RAG není správná volba
Pokud se odpověď mění podle aktuálního stavu transakce, dokumentové vyhledávání nemusí stačit. Potřebujete autorizované volání systému, který stav vlastní. Pokud je korpus malý a dobře uspořádaný, klasické hledání nebo navigace může být jednodušší a spolehlivější. Pokud musí být výsledek deterministický, například výpočet částky podle schváleného pravidla, generování může přidat zbytečné riziko. U nesourodých zdrojů nejprve sjednoťte odpovědnost za obsah. RAG není náhrada za datovou správu ani za rozhodování odborníka.
První pilot omezte na jeden spravovaný korpus a několik reprezentativních otázek. Předem stanovte kvalitu hledání, oporu odpovědi, správnost citací, latenci a podmínky zastavení. Porovnejte jej s obyčejným vyhledáváním a dnešním postupem uživatelů. EXCOIN může navrhnout a implementovat řešení, ale skutečný přínos nelze slíbit bez posouzení vašich dokumentů a oprávnění. Úspěch poznáte podle toho, že uživatel bezpečně najde aktuální podklad, dokáže jej otevřít a ví, kdy má odpověď ověřit s člověkem.
Před rozšířením ověřte náklady a lidskou práci
Při pilotu sledujte, kolik času zabere příprava dokumentů, opravování zdrojů a kontrola odpovědí. Náklad na dotaz není jen cena modelu a vyhledávače. Pokud zaměstnanec musí každou odpověď znovu ověřit v několika souborech, přínos může být malý i při pěkně vypadajícím rozhraní. Měřte dobu k nalezení spolehlivého podkladu oproti dnešnímu postupu. Zohledněte také čas vlastníků dokumentů, kteří budou udržovat platnost a řešit sporný obsah. Udržovaná znalostní báze má vlastní cenu, ale může být užitečná i bez generativní vrstvy.
Rozšíření na další oddělení schvalujte až po vyhodnocení rozdílů v oprávněních, jazycích a kvalitě zdrojů. Úspěch v jednom dobře spravovaném korpusu není důkazem, že systém bezpečně zvládne všechny firemní soubory. Každá nová skupina dokumentů potřebuje vlastníka, způsob aktualizace a testové otázky. Když se změní politika přístupu, prověřte, zda se starý úsek nevyskytuje v cache nebo uložené konverzaci. Zaznamenejte podmínky, za nichž se pilot zastaví nebo vrátí k obyčejnému vyhledávání. Tak zůstane přínos doložitelný a riziko omezené.