Hodnoťte celou cestu od otázky k odpovědi
RAG propojuje vyhledávání v dokumentech s generováním odpovědi. Působivá ukázka na několika otázkách však nic neříká o tom, jak si poradí se zastaralou směrnicí, dvěma rozpornými verzemi, přístupovým omezením nebo otázkou bez odpovědi. Měřit pouze plynulost textu proto nestačí. Microsoft v dokumentaci hodnotitelů rozlišuje kvalitu nalezeného kontextu, ukotvení odpovědi v kontextu a relevanci výsledku. To je užitečný rámec, ale konkrétní kritéria musí odpovídat rozhodnutí, která budou zaměstnanci s odpověďmi dělat.
Nejdřív popište účel služby. Jinak se hodnotí pomocník, který ukazuje interní pravidla, a jinak návrh právně významného stanoviska. Určete, co smí systém doporučit, kdy musí nabídnout zdrojový dokument a kdy má uživatele odkázat na člověka. Zaznamenejte vlastníka každé třídy dokumentů a odpovědnost za jejich aktuálnost. Hodnocení bez tohoto kontextu umí vyrobit čísla, ale neumí říct, zda je výsledek bezpečný pro zamýšlené použití.
Testovací sada musí reprezentovat skutečnou práci
Sestavte otázky z reálných informačních potřeb, nikoli jen z názvů dokumentů. Vložte jednoduché faktické dotazy, kombinace více dokumentů, synonyma, překlepy, nejednoznačné názvy a dotazy v jazycích, které lidé používají. U každé otázky určete očekávaný typ odpovědi, přípustné zdroje a případně fakt, že odpověď v korpusu chybí. Zvláštní skupinu tvoří časové varianty: stará a nová verze postupu, dokument po datu účinnosti nebo zrušené pravidlo. Bez nich systém snadno vypadá přesně, přestože cituje neplatný obsah.
Testovací sada musí obsahovat i hranice oprávnění. Stejný dotaz položte za uživatele s různou rolí a ověřte, že žádný dokument nepřekročí hranici přístupu v nalezeném kontextu, citaci ani odpovědi. Přidejte otázky mimo téma, úmyslně zavádějící formulace a dokumenty obsahující instrukce pro model. Citovaný obsah je data, nikoli pokyn k řízení asistenta. OWASP tuto oblast popisuje jako prompt injection; v interním RAG má zvláštní význam, protože útočný text může vstoupit přes běžný dokument.
Oddělte hodnocení vyhledávání od generování
Pro každý test ukládejte dotaz, identitu uživatele nebo testovací roli, verzi indexu, nalezené dokumenty, jejich pořadí a verze. Přezkoumejte, zda se správný dokument objevil ve výsledcích a zda byly výsledky relevantní. Je-li odpověď chybná, nejdřív zjistěte, zda potřebný důkaz vůbec dorazil do kontextu. Bez této hranice bude tým měnit prompt, když je skutečná chyba v indexaci, dělení textu, filtrech nebo oprávněních.
U vyhledávání se hodí ukazatele jako úspěšnost nalezení relevantního dokumentu v prvních výsledcích, podíl zavádějících výsledků a pokrytí typů dotazů. Absolutní číslo bez rozdělení podle jazyka, oddělení a tématu je slabé. Sledujte například, zda firemní slang nebo názvy produktů nezhoršují výkon jen pro určité uživatele. Testujte i dokumenty s tabulkami, přílohami a skeny: pokud se z nich ztratí struktura, vyhledávač nemá z čeho vycházet. Chybu pak opravujte v příjmu dokumentů, ne v generátoru.
Odpověď musí být doložitelná po jednotlivých tvrzeních
Když správný kontext dorazí, hodnotí se, zda je odpověď věcně podložená, úplná vzhledem k otázce a srozumitelná. Zkontrolujte klíčová tvrzení jednotlivě proti citovaným pasážím. Citace na dokument jako celek nestačí, jestliže konkrétní věta z něj nevyplývá. Rozlišujte přímý fakt, shrnutí a odvození. U odvození má asistent jasně uvést, že jde o interpretaci, a nabídnout podklady. RAGAS popisuje automatizované hodnocení vztahu mezi otázkou, kontextem a odpovědí; taková metrika pomáhá třídit velký počet případů, ale nenahrazuje lidský posudek citlivých tvrzení.
Předem si určete, jak se hodnotí odpověď při rozporu zdrojů. Správný výsledek může být upozornění na konflikt, datum účinnosti a odkazy na obě verze, nikoli jediné sebejisté doporučení. Důležitá je také kalibrace nejistoty. Pokud korpus odpověď nemá, je přiznání mezery lepší než doplnění pravděpodobného, ale nedoloženého vysvětlení. Sledujte podíl oprávněných odmítnutí a současně falešná odmítnutí, která zbytečně blokují použitelnou informaci.
Práva a soukromí ověřujte jako samostatnou podmínku
Přístupová práva se musí uplatnit před předáním kontextu modelu. Nestačí skrýt citaci v rozhraní, pokud text už prošel modelem nebo logem. V testech kombinujte role, skupiny, sdílené složky a změny oprávnění po vytvoření indexu. Ověřte, že odebrání přístupu se promítne do výsledků v přijatelném čase. Oddělte oprávnění ke čtení dokumentu od práva vidět jeho název nebo metadata. Některé organizace považují i název projektu za citlivý údaj.
Zmapujte také záznamy dotazů, odpovědí a zpětné vazby. Mohou obsahovat osobní, smluvní nebo obchodní údaje. Stanovte dobu uchování, kdo smí záznamy číst a jak se smažou. Pokud k automatickému hodnocení používáte externí model, musíte vědět, jaká data do něj odchází a na základě jaké smlouvy. Menší ručně označená sada může být pro citlivý korpus vhodnější než levně vypadající masové hodnocení, které přenáší obsah mimo povolené prostředí.
Automatické skóre není samo o sobě rozhodnutí
Modelový hodnotitel může rychle upozornit na pravděpodobně nepodložené tvrzení, ale také se mýlit. Kalibrujte jej na sadě případů, které posoudili lidé, a sledujte shodu v jednotlivých kategoriích. U měření nepoužívejte stejný model a stejný prompt jako jedinou autoritu nad vlastním výstupem. Hodnotitel by měl dostat jasnou rubriku: například zda je každé podstatné tvrzení podloženo, zda odpověď nepřidává nepovolený závěr a zda uživateli přiznává omezení. Při změně hodnotitele verzujte pravidla, jinak nelze srovnávat trend.
Výsledky rozdělte na kritické chyby a zlepšení kvality. Jediné vyzrazení nepřístupného dokumentu může zastavit vydání, i kdyby průměrná relevance byla vysoká. Stejně může kritický proces vyžadovat nulovou toleranci k doporučení podle neplatné směrnice. Pro běžné interní hledání lze použít prahové hodnoty pro pokrytí, relevanci a rychlost, ale stanovte je podle pilotu a nákladů chyby. Metriky bez prahů a odpovědnosti bývají pouze dekorací dashboardu.
Regrese musí kopírovat změny v korpusu i aplikaci
Spouštějte stejnou sadu po změně modelu, promptu, indexace, dělení dokumentů, embeddingu a pravidel oprávnění. Uchovávejte verzi korpusu nebo alespoň identifikátory a kontrolní součty dokumentů, aby bylo jasné, co se změnilo. Průběžně přidávejte případy z provozu: otázky bez výsledku, sporné odpovědi a citace, které uživatele zavedly na neplatný dokument. Každou opravu ověřte i proti dříve fungujícím scénářům. Zlepšení jedné otázky se může projevit zhoršením jiné skupiny.
Při hodnocení rychlosti oddělte čas vyhledávání a generování. Pomalá odpověď může být problémem velkých kontextů, přetíženého indexu nebo čekání na model. Sledujte i náklady na dotaz, ale kvalitu neobětujte bez výslovného rozhodnutí. U častých dotazů lze zvážit schválené předpřipravené odpovědi, pokud se kontroluje jejich aktuálnost a oprávnění. Vyhodnocení jedné otázky musí být opakovatelné s konkrétní verzí vstupů; jinak regresní graf smíchá změny systému s proměnou dokumentů.
Uvolnění do provozu má mít jasný postup
Před pilotem požádejte vlastníky dokumentů o potvrzení nejdůležitějších případů a bezpečnostní tým o kontrolu přístupových hranic. Pilot provozujte na vymezené skupině a řekněte uživatelům, kdy mají otevřít zdroj nebo oslovit člověka. V rozhraní umožněte označit chybnou odpověď, ale zpětnou vazbu nepovažujte automaticky za pravdu: může chybět kontext nebo oprávnění hodnotitele. Při kritickém incidentu musí existovat možnost zastavit určitou kolekci, vyhledávání nebo celý generátor a přejít na přímé dokumenty.
Po vydání sledujte nejen skóre, ale i typy chyb a jejich dopad. Pravidelně znovu označujte vzorek odpovědí lidmi a porovnávejte jej s automatickým hodnocením. EXCOIN může pomoci navrhnout testovací sadu, měření a provozní pravidla, ale kvalita závisí na skutečném korpusu, přístupových právech a přijatelné míře rizika konkrétní organizace. Dobrý RAG není ten, který vždy odpoví; je to ten, u něhož lze ověřit, proč odpověděl právě tak a kdy odpovědět neměl.
Při předání provozu určete také vlastníka testovací sady. Jeho úkolem není pouze spouštět skript, ale rozhodovat, které nové otázky jsou reprezentativní a jaké chyby vyžadují okamžitou reakci. Výsledky se mají pravidelně projednávat s lidmi, kteří dokumenty spravují a odpovědi používají. Jestliže se změní firemní proces, aktualizujte očekávanou odpověď i zdroj; starý test by jinak mohl penalizovat správné nové chování. Zaznamenejte důvod každé změny, aby dlouhodobé výsledky zůstaly srozumitelné.