Jak sestavit testovací sadu pro AI a odhalit zhoršení po změně modelu

Po výměně modelu začne asistent zákaznické podpory psát srozumitelnější odpovědi. U dvou objednávek ale slíbí termín dodání, který ve vstupních datech chybí. Kdybyste hodnotili jen první ukázku a její styl, změnu schválíte. Dobrá testovací sada podobnou chybu zachytí dřív, než se návrh dostane k zákazníkovi. Obsahuje běžné úlohy, obtížné výjimky a předem napsaná pravidla pro rozhodnutí, co projde.

Takové sadě se často říká eval. Na začátku stačí tabulka a dva lidé, kteří rozumějí úloze. Níže najdete postup od výběru případů přes modelovou bodovací tabulku až po rozhodnutí, kdy změnu nasadit. Princip funguje i při úpravě zadání, vyhledávání v dokumentech nebo připojených nástrojů.

Vyberte výsledek, který opravdu používáte

„Chceme lepší AI“ není dost přesné zadání pro test. „Chceme, aby asistent z údajů o objednávce vytvořil použitelný návrh e-mailu“ už je dobrý začátek. U takového návrhu můžete ověřit, zda obsahuje správné číslo objednávky, zachovává stav doručení a navrhuje další krok, který pravidla podpory dovolují.

Vedle běžné cesty napište hranici. Příklad z podpory může znít takto. Asistent smí připravit návrh, pracovník rozhoduje o odeslání a změnu objednávky provádí jen oprávněný člověk. Tato hranice se může promítnout do hodnocení. Když návrh tvrdí, že adresa už byla změněna, a záznam žádnou změnu neobsahuje, máte konkrétní důvod k zastavení. Odpověď může být perfektně napsaná a přesto nesplnit účel.

Při prvním testu se držte jedné opakované činnosti. Velké srovnání možností AI modelů může pomoci vybrat nástroje do užšího výběru. Interní sada pak řeší užší otázku, zda jedna změna zlepšuje váš konkrétní postup. Výsledky pro zákaznické e-maily se nedají automaticky přenést na souhrny smluv ani na generování kódu.

Připravte případy podle práce, kterou skutečně dostáváte

Pro první pracovní kolo může menšímu týmu stačit například dvacet případů. Počet v tomto návodu slouží k plánování práce, neposkytuje statistickou záruku. Důležitější než samotná velikost je pokrytí situací, které mají různý dopad. Pokud všech dvacet e-mailů řeší sledování zásilky a ve všech je vyplněno datum, sada vám o práci s chybějícím datem nic neřekne.

Vyjděte z nejčastějších požadavků z několika běžných dnů. Přiberte pracovníka, který řeší reklamace nebo provozní výjimky. Možná vám ukáže případ, kdy zákazník napsal dvakrát ze dvou adres, objednávka obsahuje dvě zásilky a běžná šablona odpovědi vede k nesprávnému závěru. Zjednodušte ho na situaci, kterou můžete bezpečně reprodukovat.

• Běžná práce zahrnuje například jednoduchý dotaz na jednu zásilku s úplnými údaji. Ověříte, že změna nekazí to, co dosud fungovalo.
• Neúplný vstup ponechá prázdný údaj s dopadem na odpověď. Asistent má požádat o doplnění nebo případ předat podle pravidel.
• Rozpor v podkladech může postavit proti sobě dvě data z různých evidencí. Člověk, který připravuje test, určí, zda má jeden zdroj přednost nebo se má rozpor označit.
• Záměna podobných případů prověří objednávky se stejným příjmením nebo dvě téměř shodná čísla. Do očekávání napište, podle kterého identifikátoru se má rozhodovat.
• Hranice oprávnění v příkladu požádá o akci, kterou asistent smí pouze navrhnout. Hodnotíte i stav zkušebního systému, pokud asistent umí volat nástroje.

Při práci s citlivými údaji si vytvořte modelové případy se stejnou strukturou. Pouhá výměna jména za iniciály může nechat identitu rozpoznatelnou z kombinace adresy, čísel a časů. U testu na konflikt dvou dat potřebujete zachovat konflikt a pořadí, nikoli původní datum narození zákazníka nebo obsah jeho přílohy. Jaká data smějí do konkrétní služby, určete před sestavením sady.

U každého případu zapište, co se dá rozhodnout

Testovací řádek potřebuje identifikátor, vstup, očekávání a krátkou poznámku k dopadu chyby. Vstup zahrnuje přesné zadání, podklady a případný stav systému. Když pro zkoušku použijete interní směrnici, uložte její verzi. Jinak může změna směrnice vypadat jako zhoršení modelu, i když asistent správně pracuje s novými pravidly.

U volného textu většinou existuje několik stejně dobrých odpovědí. Doslovná shoda s jednou vzorovou větou proto často měří formulaci místo užitečnosti. K případu si raději zapište „má upozornit, že datum dodání chybí“, „nesmí odhadnout termín“ a „má požádat o ověření stavu zásilky“. Pokud potřebujete zachovat konkrétní číslo, ověřte ho přesně. Styl nechte posoudit člověka podle krátkých kritérií.

Modelová kritéria pro návrh odpovědi zákazníkovi Na mobilu lze tabulku posouvat do stran.

Zásadní porušení si označte samostatně. Dobré skóre za čitelnost by nemělo převážit skutečnost, že text připisuje údaje jiné objednávce. Blokující chyby mají jiný následek než delší odstavec nebo méně obratné oslovení. Tým si jejich definici sepíše před vyhodnocením a stejnou definici použije pro obě varianty.

U nejasného výsledku pomáhá zapsat větu, na které záleží. „Odpověď je divná“ vám při pozdějším rozboru nepomůže. „Ve druhém odstavci slibuje úterní dodání, dopravce uvádí jen převzetí zásilky“ už umožňuje reprodukovat chybu a ověřit opravu. Rozlišení tvrzení podle dopadu podrobněji rozebírá náš postup ověřování jednotlivých odpovědí AI.

Spusťte obě varianty za srovnatelných podmínek

Pokud chcete zjistit, co udělala výměna modelu, ponechte ostatní části postupu co nejvíce stejné. Při změně modelu a zadání najednou změříte výsledný rozdíl, ale hůř vysvětlíte jeho příčinu. Když se současně změnila i dokumentace nebo dostupnost vyhledávání, označte výsledek jako porovnání dvou konfigurací celého systému.

1. Uložte výchozí nastavení. Zapište model nebo viditelný název režimu, verzi zadání, dostupné nástroje a podklady. U hotové chatovací aplikace uveďte i nastavení paměti, pokud je pro danou práci podstatné.
2. Spusťte oba postupy nad stejnými vstupy. Každý případ začněte ve stejném počátečním stavu. Nový chat a půlhodinový rozhovor s předchozími opravami představují různé podmínky.
3. Označte výstupy neutrálně a při ručním posuzování promíchejte jejich pořadí. Když hodnotitel neví, který návrh je nový, má méně důvodů očekávat jeho zlepšení.
4. Zapište splnění kritérií, kritické chyby, dobu ruční kontroly a opravy. Uchovejte informaci o tom, zda některý běh zastavila služba nebo jestli chyběl vstup.
5. Zopakujte důležité hraniční případy. Opakované pokusy označte samostatně a uveďte, kolik jich bylo. Jeden povedený běh po dvou chybách pořád znamená, že selhání nastalo.

Z běžného chatu někdy nezískáte přesnou identifikaci modelu na pozadí. Zaznamenejte, co rozhraní skutečně ukazuje, včetně data a názvu zvoleného režimu. Stejné výsledky v jiný den tím nezaručíte. Při rozhodování o pracovním nasazení může být právě tato omezená kontrola nad konfigurací důležitější než několik sekund rozdílu v rychlosti.

Použijte výsledky k rozhodnutí o změně

Představme si dva návrhy zpracované nad stejnými dvaceti modelovými případy. Původní postup vytvořil šestnáct použitelných návrhů a nový osmnáct. Nový postup navíc u běžných dotazů zkrátil průměrnou úpravu. V jedné odpovědi však zaměnil dva zákazníky. Pokud jste si zaměnění údajů označili za blokující chybu, výsledek je důvodem k opravě, přestože celkové skóre vzrostlo z osmdesáti na devadesát procent.

Prohlédněte si páry případů. Obě varianty mohly uspět v patnácti stejných situacích, nová mohla opravit tři staré chyby a přitom způsobit jednu novou. Poslední případ by v tomto modelu zůstal nevyřešený u obou. Jen ze součtu úspěchů tento rozdíl nepoznáte. Rozdělte případy na úspěch v obou variantách, zlepšení, zhoršení a selhání v obou. Právě skupina zhoršení vám řekne, zda se při zdánlivě výhodném přechodu objevil nový problém.

Za použitelný čas počítejte celý postup. U modelového týmu může první varianta vyžadovat minutu na vytvoření a dvě na kontrolu, druhá půl minuty na vytvoření a čtyři na kontrolu. Celkem jde o tři minuty oproti čtyřem a půl. Sledujete-li jen dobu generování, vyjde pořadí obráceně. Rozbor nákladů na kontrolu objemných výstupů AI ukazuje podobný problém z pohledu kolegů, kteří výstup přebírají.

Ukažte i počet případů. Změna o deset procentních bodů při dvaceti úlohách znamená dva návrhy v této sadě. Nevydávejte ji za přesný odhad toho, co se stane u všech zákazníků. Pokud se obě varianty střídají v úspěchu a rozdíl dělá jediný případ, může být pro rozhodnutí cennější přidat další podobné situace a zkontrolovat, zda je hodnotitelé posuzují stejně.

Rozlište chybu asistenta od poruchy prostředí

Při spuštění sady si všímejte, jestli měl asistent vůbec možnost úkol splnit. Uvažujte dva případy. V prvním má nástroj v podkladech dva stavy a vybere nesprávný. Ve druhém databáze zkušebního prostředí vůbec neodpoví. Pro uživatele oba pokusy končí bez použitelného výsledku, opravují se však jinak. K prvnímu se vraťte s očekáváním, jak vybrat správný zdroj. U druhého prověřte dostupnost služby a to, zda asistent chybějící data čestně přiznal.

Když z deseti pokusů dva zastaví technický výpadek a sedm z osmi dokončených odpovědí projde, můžete evidovat sedm úspěchů z deseti startů i sedm z osmi dokončených odpovědí. Každý údaj odpovídá na jinou otázku. První přibližuje zkušenost uživatele v dané sérii pokusů, druhý kvalitu dokončených odpovědí. Rozepište jejich jmenovatele. Pokud dva přerušené případy prostě vyřadíte a výsledek označíte za úspěšnost služby, zamlčíte část zkušenosti.

Při krátkém výpadku zopakujte stejný případ v obnoveném prostředí. Nový výsledek zapište jako další pokus a původní si ponechte s vysvětlením. U akcí s následkem kontrolujte i skutečný stav po doběhnutí. Text „případ jsem uzavřel“ nepotvrzuje změnu evidence. Naopak časový limit v aplikaci může přijít až poté, co se změna zapsala. K ověření potřebujete záznam z nezávislé evidence nebo přímou kontrolu zkušební objednávky.

Před prověrkou si vyberte jednu ukázku, která má projít, a jednu, která má být odmítnuta. Tím otestujete i samotná pravidla hodnocení. Jestli projde návrh se záměrně změněným číslem objednávky, chyba může být v hodnoticím postupu. Zkontrolujte, zda se správná hodnota bere ze vstupu a zda se opravdu porovnává číslo daného případu, nikoli libovolný podobný identifikátor v odpovědi.

Udržujte oddělené příklady pro opravy a prověrku

Když ladíte zadání podle jedné sady, časem si pracovní postup zvykne právě na její příklady. Zadání může výslovně opravovat konkrétní kombinaci dat a přitom selhat u jinak formulovaného, obsahově stejného dotazu. Část případů proto vyhraďte pro závěrečnou prověrku a neberte je do každého kola ladění. U malé sady může jít o několik případů. Pokud se jeden z nich použije k opravě zadání, připravte pro prověrku nový případ se stejným druhem problému.

Do pravidelně opakované sady přidávejte skutečně nové typy selhání. Jeden incident obvykle nepotřebuje deset kopií se změněným jménem. Potřebuje příklad původního problému a podle povahy chyby variantu, která pomůže ověřit, zda úprava funguje i v blízké situaci. U vrácených objednávek to může být částečné vrácení, u dat s rozdílným významem zase záměna data odeslání za předpokládané doručení.

Test má vlastníka. Někdo musí udržovat verze příloh, rozhodovat o změnách očekávání a zajistit, aby se výsledek dostal k člověku, který změnu schvaluje. Praktické je mít k nasazení krátký zápis s verzí sady, důvodem rozhodnutí, zbývajícími slabinami a způsobem návratu. Pokud se po nasazení ukáže problém mimo testované případy, budete mít z čeho vyjít a budete vědět, které chování přezkoušet jako první.

Kdy stačí tabulka a kdy se vyplatí automatizace

Ruční prověrka dává smysl, když sada ještě vzniká a tým se teprve shoduje, co považuje za dobrý výstup. Můžete rychle přidat sloupec pro novou podmínku nebo rozdělit příliš širokou známku. U pravidelných změn stojí za automatizaci především kontroly s jednoznačnou odpovědí. Ověření, že výstup obsahuje existující číslo a že zkušební objednávka zůstala nedotčená, nemusí posuzovat hodnotitel pokaždé ručně.

U zdvořilosti, přiměřené stručnosti nebo kvalitní práce s nejednoznačným dotazem potřebujete jasné příklady hodnocení. Pokud využijete jiný model jako pomocného hodnotitele, porovnejte jeho úsudek na části sady s lidmi znalými dané práce. Automatické hodnocení může přehlédnout přesvědčivě napsanou chybu nebo dát přednost podobnému stylu. U sporných a závažných výsledků ponechte rozhodnutí člověku, který má k dispozici zdrojová data.

Časté otázky

Jak poznám, že mám dost případů?

Začněte hlavními druhy práce a případy s vážnými následky. Pokud vás další vzorky stále pravidelně překvapují novými typy chyb, pokrytí není dostatečné pro široké nasazení. Počet přizpůsobte také tomu, kolik výstupů můžete opravdu spolehlivě posoudit.

Má se testovat model, nebo celá aplikace?

Pro rozhodnutí o nasazení nejčastěji celé pracovní řešení. Jeho výsledek ovlivňují připojené podklady, zadání, nástroje a pravidla předávání. Samostatný test modelu pomáhá při hledání příčiny rozdílu, když ostatní podmínky udržíte shodné.

Co udělat, když se hodnotitelé neshodnou?

Nejdřív porovnejte důvody. Pokud jeden hodnotil tón a druhý správnost údajů, rozdělte kritérium. Jestli oba odlišně pochopili pravidlo, přidejte příklad hraniční odpovědi a zpětně stejným způsobem znovu posuďte dotčené výstupy.

Můžu zkoušet pouze nejrizikovější případy?

Taková sada je užitečná pro kontrolu určitých hranic. Na běžnou použitelnost potřebujete i typické úlohy s úplnými vstupy. Výsledky těchto dvou skupin je často vhodné vykázat zvlášť.

Co když se test při každém spuštění trochu liší?

Uložte všechny relevantní pokusy a jejich podmínky. U několika klíčových případů opakujte běh podle předem stanoveného plánu. Rozdíl mezi dvěma odpověďmi ve formulaci má jinou váhu než rozdíl v tom, kterému zákazníkovi je údaj přiřazen.

Musím celou sadu spouštět po každé drobné změně?

Podle dopadu změny můžete nejdřív použít kratší kontrolu zaměřenou na dotčené situace. Před širším nasazením změny modelu, pravidel nebo přístupů má smysl ověřit i běžné úlohy a všechny známé blokující chyby.