Nejdřív zjistěte, kde znalost skutečně žije
První krok není volba modelu, ale inventář dokumentů, wiki, tiketů a databází, na které se lidé dnes ptají. U každého zdroje zapište vlastníka, formát, jazyk, způsob změny a přístupová práva. Odlišujte schválený pracovní postup od staré poznámky, kterou už nikdo neudržuje. Pokud se tyto materiály smíchají bez označení, vyhledávač může nabídnout velmi přesvědčivý, ale neplatný návod. Zeptejte se pracovníků, jak poznávají správnou verzi dnes a kdy raději zavolají kolegovi.
Stanovte také hranici projektu. Může pokrývat veřejné produktové manuály, interní provozní postupy nebo jen jednu konkrétní agendu. Každá další kategorie přidává nové vlastníky a pravidla. Pro pilot vyberte menší množinu důležitých, udržovaných dokumentů. U chybějících informací nevytvářejte umělý obsah, který bude vypadat autoritativně. Raději zaznamenejte mezeru a určete člověka, který ji může doplnit. Vyhledávání nedokáže napravit chybějící rozhodnutí o vlastnictví znalostí.
Fulltext, hybridní hledání a RAG řeší různé potřeby
Přesný název produktu, číslo tiketu nebo kód předpisu často nejlépe najde klasické klíčové hledání. Dotaz popisující problém jinými slovy může těžit ze sémantického vektorového hledání. Microsoft popisuje hybridní dotaz jako kombinaci klíčové a vektorové části v jednom vyhodnocení. Nevybírejte technologii podle dojmu z několika ukázek; porovnejte výsledky na skutečných dotazech, včetně krátkých, neúplných a vícejazyčných formulací. Důležité je také umět vysvětlit, proč se dokument objevil nahoře.
RAG přidává k vyhledaným pasážím generovanou odpověď. To může ušetřit čas, pokud čtenář potřebuje syntézu více zdrojů, ale zároveň vzniká další místo pro chybu. U jednoduchého navigačního dotazu může být lepší nabídnout tři relevantní dokumenty než generovat odstavec. U složitého dotazu musí systém odlišit fakta z dokumentů od vlastního shrnutí. V pilotu měřte samostatně kvalitu nalezení pasáží a kvalitu odpovědi; jedna dobrá výsledná věta nezakryje, že správný zdroj nebyl nalezen.
Připravte zdroje pro dohledatelné výsledky
Dokumenty rozdělte na úseky, které mají srozumitelný kontext a stabilní odkaz na originál. Příliš krátký úsek ztratí podmínky a výjimky, příliš dlouhý překryje přesnou odpověď. U každého úseku uchovejte název, verzi, datum změny, vlastníka a oprávnění. Tabulky, přílohy a obrázky mohou obsahovat klíčovou informaci, kterou prosté získání textu vynechá; rozhodněte, zda je umíte zpracovat věrně. Pokud ne, zobrazte odkaz na originální dokument a omezení indexu.
Citace má být pro uživatele použitelná. Odkaz na úvodní stránku rozsáhlého manuálu často nestačí; vhodnější je konkrétní sekce nebo identifikátor pasáže. U citlivých procesů zobrazte i datum účinnosti a stav dokumentu. Když zdroj zmizí nebo je nahrazen, musí se aktualizovat index a případná cache. V odpovědi nemá zůstat odkaz na neexistující nebo nepovolený podklad. Správu indexu proto propojte s běžným životním cyklem dokumentu, nikoli s občasným ručním importem.
Oprávnění musí platit před vyhledáním i po něm
Interní index často spojuje dokumenty s různými právy. Uživateli nesmí uniknout ani název, úryvek nebo vektorový soused dokumentu, ke kterému nemá přístup. Microsoft popisuje přístupové filtry i další modely dokumentových oprávnění v Azure AI Search. Konkrétní technologie se může lišit, ale princip je stejný: identita a členství ve skupinách se ověří při dotazu, oprávnění z originálu se synchronizují do indexu a výsledek se filtruje před předáním modelu či obrazovce.
Testujte změny rolí a odchod zaměstnance. Pokud se dokument přesune do přísnější kategorie, stale index může po určitou dobu vracet starý výsledek. Určete přijatelnou dobu synchronizace a pro kritické zdroje zvažte ověření přístupu při čtení. Cache odpovědí musí respektovat kontext uživatele, ne pouze text dotazu. Auditujte přístup k citlivým zdrojům a minimalizujte uložení osobních údajů ve vyhledávacích logách. Oprávnění nejsou volitelný filtr nad hotovým RAG systémem.
Evaluace potřebuje otázky i očekávané zdroje
Připravte sadu reálných dotazů od lidí, kteří dokumenty používají. U každého určete, které zdroje mají být nalezeny, zda existuje jednoznačná odpověď a kdy je správné říct, že podklad chybí. Amazon Bedrock v dokumentaci evaluace znalostních bází pracuje s očekávanými texty a odpověďmi jako referenčními daty. I bez této služby lze stejný princip použít lokálně. Vzorek musí obsahovat známé názvy, parafráze, podobné dokumenty, staré verze a dotazy mimo rozsah.
Měřte nalezení relevantní pasáže, pořadí výsledků, věrnost odpovědi citovanému textu, správnost odmítnutí a čas potřebný k ověření. Nespoléhejte pouze na průměrné skóre. Jedna chyba, která uživateli zpřístupní cizí dokument nebo doporučí zrušený postup, může být důležitější než desítky drobných stylistických nedostatků. Při změně indexace, chunkingu, modelu nebo oprávnění spusťte stejnou sadu znovu. Uživatelům umožněte označit chybný zdroj a předat opravu vlastníkovi znalosti.
Pilot ukáže, zda stačí vyhledávání
Začněte jednou agendou a malou skupinou lidí. Zaznamenejte dnešní čas hledání, počet dotazů končících otázkou na kolegu a nejčastější chybějící dokumenty. Pilot porovná fulltext, hybridní hledání a případně RAG na stejné sadě dotazů. U odpovědí sledujte, zda člověk skutečně otevře citaci, zda jí rozumí a zda výsledku důvěřuje přiměřeně. Samotný počet položených dotazů není důkazem hodnoty; může znamenat i to, že systém odpovídá nejasně.
Před rozšířením určete, kdo aktualizuje zdroje, kdo řeší chybné výsledky a jak se vypne generování, pokud není bezpečné. EXCOIN zde netvrdí konkrétní proprietární vyhledávací produkt ani měřený výsledek klientské instalace. Užitečný výstup úvodní práce je mapa zdrojů a práv, testovací sada, srovnání variant a plán údržby. Pokud spolehlivý fulltext vyřeší hlavní problém, není důvod přidávat model jen proto, že v demonstraci působí působivě.
Do pilotu zařaďte také úmyslně zavádějící otázky. Uživatel může předpokládat, že konkrétní pravidlo platí, i když bylo zrušeno nebo nikdy nebylo schváleno. Správný systém má najít odpovídající důkaz, případně přiznat, že jej nemá. Otestujte rozdíly mezi dvěma podobnými verzemi postupu a mezi dokumenty s různými oprávněními. Vyhodnoťte, zda se odpověď mění správně po aktualizaci zdroje, a změřte dobu, než se změna projeví v indexu. Pracovníci podpory musí mít cestu, jak označit chybu bez přepisování originálního dokumentu. Vlastník obsahu pak rozhodne, zda je problém v dokumentu, v indexaci nebo v generování. Takové rozdělení odpovědnosti zkracuje čas nápravy a brání tomu, aby se jedna technická oprava pokusila zakrýt nejasné obchodní pravidlo. Při předání zaznamenejte i způsob zálohování a obnovy indexu; jeho opětovné sestavení může trvat déle než samotné spuštění aplikace. Ověřte rovněž, že po obnově zůstávají správně spárované verze dokumentů, oprávnění a odkazy v dříve vytvořených odpovědích.