Evaly: od experimentů s AI k jistému nasazení do produkce

• Přestože se základní modely zlepšily, skutečný posun umožňující jejich sebejisté nasazení do produkce přinášejí důsledné postupy hodnocení.

• Dobře navržená hodnocení pomáhají produktovým manažerům, vedoucím pracovníkům pro správu AI a technickým ředitelům bezpečně a ve velkém nasazovat AI agenty, takže se z izolované hračky stává konkurenční výhoda.

• Tato jistota vychází z hodnocení chování AI agentů na základě skutečných dotazů uživatelů, okrajových případů a scénářů specifických pro danou oblast, které odpovídají vašemu podnikatelskému prostředí, nikoli z veřejného benchmarku tvrdícího, že „tento model je nejlepší“.

• Cílem je tuto jistotu podložit měřitelnými výsledky. Úspěch znamená konkrétně a měřitelně vymezit, co je "dobré", v souladu s potřebami firmy a její ochotou podstupovat rizika – ať už jde o faktickou přesnost, vhodný tón, rychlost, nebo nákladovou efektivitu.

• Začleněním hodnocení do celého systému (instrumentace, protokolování, A/B testování a ochranná opatření) a vyvážením důslednosti s efektivitou mohou týmy nasazovat rychleji a dosáhnout vyšší odolnosti.

Většině firem nevadí, když si jejich zaměstnanci zkoušejí ChatGPT nebo Gemini. Nasazení LLM do pracovních postupů či prostředí s vysokými riziky je však mnohem méně běžné.

Důvody bývaly často oprávněné: kvalita byla nevyrovnaná a riziko halucinací či nežádoucího chování převažovalo nad možnými přínosy technologie.

Poměr rizik a přínosů se však za poslední rok výrazně změnil. Částečně za to může lepší výkon základních modelů, z velké části však také stále důslednější hodnocení (neboli „evaly“). Evaly nám i našim klientům dávají jistotu, že během několika týdnů můžeme ve velkém nasadit agenty určené pro klienty.

Tato příručka vysvětluje základní prvky evalů a popisuje, jak je navrhovat, implementovat a provozovat v produkčním prostředí.

Cílem hodnocení není najít dokonalý model, ale získat podloženou jistotu, že se váš model chová v souladu s potřebami firmy, očekáváním uživatelů a ochotou organizace podstupovat rizika.

Základem každé strategie hodnocení je jednoduchá otázka: Jak vypadá „dobrý“ výsledek? Odpověď by měla být konkrétní. Pro jednu organizaci může „dobrý“ výsledek znamenat faktickou přesnost v přísně stanovených mezích, zatímco jiná může upřednostňovat rychlost, nákladovou efektivitu nebo osobitý tón komunikace. Tuto definici ovlivňují všechna omezení, která musíte dodržovat – od použitelných dat až po příslušné regulatorní povinnosti.

Je zásadní, aby se 'dobrý' výsledek skládal z prvků, které lze skutečně měřit. Pokud úspěch znamená poskytovat užitečné finanční poradenství, je třeba užitečnost vyjádřit pomocí vlastností, jako jsou faktická správnost, vhodná upozornění, personalizované uvažování a bezpečně nastavené hranice. Jakmile měřitelně vymezíte „dobrý“ výsledek, musíte určit, jak budete výsledky analyzovat a interpretovat. Teprve využití těchto výsledků mění hodnocení v systematickou metodu namísto pouhých subjektivních úsudků.

Každý proces hodnocení stojí na třech vzájemně propojených pilířích:

1. Vstupy/benchmarky: Reprezentativní příklady z reálného prostředí pro obecný výkon a pečlivě sestavené interní datové sady k ověření použitelnosti v dané oblasti.

2. Chování modelu: Způsob volání modelu (generování rozšířené o vyhledávání, sumarizace, vyhledávání strukturovaných informací, používání nástrojů).

3. Metriky: Jak měříte a interpretujete výkon.

Vstupy musí odpovídat prostředí, se kterým se váš systém setká. Nejcennější poznatky přinášejí skutečné příklady: dotazy vašich zákazníků, finanční scénáře nebo případy specifické pro dané odvětví. Pouze testováním na těchto příkladech zjistíte, zda model skutečně chápe nuance požadované uživateli a naplňuje potřeby firmy.

Stejně jako samotný model záleží i na jeho chování – například na znění promptu, koordinaci vyhledávání či používání nástrojů a způsobu předávání kontextu. Dva totožné modely se mohou chovat velmi odlišně podle způsobu nasazení. Proto je nutné tuto vrstvu zahrnout do návrhu hodnocení.

Posledním pilířem jsou metriky. Samotná čísla málokdy vystihnou celý obraz, ale vhodně zvolené metriky umožňují chování systému interpretovat. Latence, přesnost, bezpečnost, soudržnost, zkreslení, náklady a spokojenost uživatelů společně vytvářejí vícerozměrný obraz systému v produkčním provozu. Klíčem je zvolit metriky, které odpovídají KPI projektu či firmy a objasňují vlastnosti nejdůležitější pro vaše uživatele. Jednodušší metriky bývají přesnější a levnější, zatímco nevhodná volba může týmy zavést na scestí. Při výběru metrik postupujte takto:

Příklady vhodně zvolených metrik:

• Chatbot zákaznické podpory: míra vyřešení při prvním kontaktu (vyřešil se problém uživatele bez eskalace?), průměrná doba vyřízení, skóre spokojenosti uživatelů, míra eskalace na lidské pracovníky

• Nástroj pro finanční výzkum: přesnost citací (% řádně ozdrojovaných tvrzení), faktická přesnost ověřená podle referenčních údajů, relevance vyhledávání (našel správné dokumenty?), soudržnost uvažování hodnocená oborovými odborníky

• Asistent pro generování kódu: syntaktická správnost, míra úspěšnosti testů, počet bezpečnostních zranitelností, doba potřebná k vytvoření funkčního řešení

Příklady nevhodně zvolených metrik:

• Používání samotné délky odpovědi jako ukazatele kvality (delší ≠ lepší)

• Měření rychlosti bez zohlednění kompromisů v přesnosti

• Sledování skóre jistoty modelu bez ověření vůči skutečné správnosti

• Spoléhání výhradně na interní perplexitu modelu bez ověření z pohledu uživatelů

Častá úskalí metrik, kterým je třeba se vyhnout:

• Protikladné metriky: Souběžná optimalizace rychlosti a úplnosti bez zohlednění jejich vzájemného kompromisu

• Přeučení na benchmarky: Dosažení 95 % na testovací sadě, ale selhání v produkci, protože skuteční uživatelé se chovají jinak

Pro jednoho klienta z přísně regulovaného odvětví finančních služeb byla přesnost řešení pro hloubkový výzkum naprosto zásadní. Vytvořili jsme datové sady otázek a odpovědí sestavené odborníky i datové sady generované nástroji. Mohli jsme tak posoudit přesnost, schopnost systému vybírat správné nástroje a vyhledávat správné informace a získat vyvážený pohled na přesnost i kvalitu uvažování. Klíčové bylo měřit více rozměrů: faktickou přesnost (ověření odborníky), kvalitu vyhledávání (přesnost a úplnost relevantních dokumentů) a soudržnost uvažování (strukturované hodnocení logického postupu).

Kdy pro hodnocení jemných rozdílů v kvalitě použít LLM jako hodnotitele

Přístup LLM jako hodnotitel využívá k hodnocení druhý model AI a nahrazuje lidskou kontrolu škálovatelným automatizovaným bodováním kvality. Přístup LLM jako hodnotitel se často nadužívá i tam, kde požadovanou přesnost zajistí jednodušší metriky. Může být užitečný tam, kde deterministické kontroly nedokážou kvalitu zachytit, například když je metrika sémantická (užitečnost, ukotvení ve zdrojích, kvalita uvažování, tón či výklad zásad) a deterministické bodování není možné. Můžete potřebovat škálovatelnou zpětnou vazbu pro mnoho variant promptů a modelů a také jasná hodnoticí kritéria a schéma strukturovaného výstupu. Aby tento přístup fungoval, postupujte následovně:

• Výslovně definujte rozměry hodnoticích kritérií: správnost, ukotvení ve zdrojích, soulad se zásadami, praktickou využitelnost a tón.

• Pro odpovědi hodnotitele používejte strukturované výstupy (schéma JSON).

• Pro analýzu selhání zaznamenávejte jak binární výsledky kontrolních bran, tak diagnostický text.

• V každém cyklu vydání kalibrujte výstupy hodnotitele podle vzorků označených lidmi.

• V oblastech s vysokými riziky používejte dva hodnotitele nebo pravidelně ověřujte shodu.

• Průběžně sledujte odchylování hodnotitele a míru neshody.

Datová sada benchmarku je pevně daný, pečlivě sestavený soubor testovacích příkladů se známými odpověďmi, který slouží ke konzistentnímu hodnocení modelů a spravedlivému porovnávání výsledků mezi verzemi. Obvykle obsahuje vstupy (například uživatelské dotazy), očekávané výstupy nebo referenční hodnocení a hodnoticí kritéria či štítky pro bodování. Veřejné benchmarkové testy slouží k porovnávání výkonu nejmodernějších modelů. Při návrhu systému mohou posloužit jako úvodní vodítko, který model by mohl být vhodným kandidátem.

U vlastního systému se však na tyto benchmarky nelze spoléhat jako na ukazatel výkonu v prostředí vaší firmy, protože mají známé nedostatky:

• Kontaminace: Modely mohly být trénovány na datech benchmarku. Hodnotit je na stejné datové sadě pak připomíná testování s tahákem.

• Nasycení: Všechny špičkové modely již dosahují téměř maximálního skóre. Zlepšení či zhoršení výkonu se proto omezuje na několik procentních bodů a často spadá do přirozené variability výsledků testů.

• Úzký záběr: Data benchmarků neodpovídají vašim skutečným úlohám, protože jsou důkladně vybírána a čištěna. Některá jsou dokonce generována LLM, a proto neodrážejí složitost a okrajové případy ve vašich datech (překlepy, neobvyklé formulace či nekvalitní obrázky).

Student požádá aplikaci o pomoc s řešením slovních úloh.

Příklad použitelného veřejného benchmarku: GSM8K (matematické uvažování na úrovni základní školy)

• Volitelná obtížnější sada: MATH.

Proč je tento benchmark užitečný:

• Umožňuje rychle porovnat, který model lépe zvládá obecné matematické uvažování.

• Je vhodným prvním filtrem před investicí do úplných produktových evalů.

Proč přesto potřebujete vlastní datovou sadu:

Vaše aplikace má požadavky, které GSM8K netestuje:

• Formulace a pořadí témat ve vašich osnovách,

• styl vysvětlování vhodný pro danou věkovou skupinu,

• zpracování nejednoznačných studentských dotazů či dotazů s mnoha překlepy,

• pravidla zásad (například kdy poskytnout nápovědu a kdy úplnou odpověď).

Účinné ověřování závisí na vytvoření hodnoticích benchmarků specifických pro vaši aplikaci. Tyto datové sady by měly vycházet ze skutečných interakcí, typických okrajových případů a pravděpodobných způsobů selhání. Při zavádění nového produktu nebo procesu může jít o náročný úkol. Ve většině případů však lze data získat ze stávajícího produktu nebo je začít shromažďovat co nejdříve, třeba už během počáteční fáze testování. Po vytvoření aplikace by se tyto benchmarky měly vyvíjet společně s produktem a postupně být bohatší a reprezentativnější.

Propojení benchmarku specifického pro vaši aplikaci s výběrem modelu je zásadní. Benchmark neukáže jen to, zda řešení funguje, ale také která kombinace velikosti modelu a technik následného trénování poskytne požadovaný výkon nejhospodárněji. Nejvýraznější zlepšení předtrénovaných modelů („PT“ v názvu ChatGPT) nepřináší nové trénování, ale metody "následného trénování".

Tyto metody určují, k jakým informacím má model přístup, jak jsou uspořádány a jak je model při inferenci veden a koordinován. Mezi techniky následného trénování patří:

• Promptování s myšlenkovým řetězcem a dynamické přidělování výpočetního výkonu (více přemýšlení nad obtížnějšími problémy)

• Sebekonzistence, kdy se vygeneruje více výstupů a vybere se nejlepší

• Tvorba a koordinace kontextu, například generování rozšířené o vyhledávání (RAG), příklady na několika příkladech a agentní pracovní postupy

• Používání nástrojů a přístup k externím znalostem, díky nimž může model jednat nad rámec svých interních parametrů

• Strategie reprezentace a ukládání znalostí navržené pro efektivní vyhledávání a uvažování nad strukturovanými i nestrukturovanými daty

Přestože tyto techniky následného trénování mohou výrazně zvýšit výkon systému, přinášejí také určité kompromisy. Každá další vrstva koordinace, vyhledávání či uvažování zvyšuje složitost systému, dobu inference a provozní náklady. Promyšleně zvolená kombinace technik následného trénování však často umožní použít menší, rychlejší a levnější modely a zároveň splnit výkonnostní požadavky. Výkonu se tak dosahuje lepším návrhem systému namísto zvětšování modelu.

Nalezení této rovnováhy je ze své podstaty specifické pro každou aplikaci. Optimální kombinaci technik proto určujte pomocí evalů určených pro vaši aplikaci. Ty vám umožní určit bod, od něhož další koordinace nepřináší významné zlepšení, takže týmy mohou zvolit nejnižší úroveň složitosti následného trénování potřebnou k dosažení cílového výkonu.

Řešení AI je třeba chápat jako celý systém: databáze, API, uživatelská rozhraní, orchestrační vrstvy, monitorovací infrastrukturu a další součásti. Hodnocení proto musí pokrývat celý technologický stack. Klíčové části systému je nutné monitorovat, abyste měli přehled o možných problémech a mohli zodpovědně zrychlovat vývoj.

Monitorování klíčových částí systému zahrnuje:

• Instrumentaci procesů pro získávání měřitelných výsledků.

• Protokolování experimentů, abyste viděli dopad každé úpravy.

• Používání jednoduchých A/B porovnání před nasazením významných změn k odhalení možných regresí.

Iterace založená na datech zkracuje cestu od prototypu k produkci bez slepých míst. Protokolování a monitorování jsou důležité také pro pochopení skutečného způsobu používání aplikace. Příklad zajištění pozorovatelnosti:

• Krok 1: Uživatelský požadavek vstoupí do systému s údaji request_id, user_segment a intent.

• Krok 2: Trasování zaznamená verzi modelu, verzi promptu, vyhledané dokumenty a volání nástrojů.

• Krok 3: Hodnotitel LLM oboduje odpověď (correctness, groundedness, policy_risk).

• Krok 4: Pravidlový modul vyhodnotí prahové hodnoty.

• Krok 5: Při překročení prahu se aktivuje upozornění a požadavek se přesměruje na záložní řešení nebo lidskou kontrolu.

• Krok 6: Selhání se přidá do fronty k posouzení a následně do backlogu benchmarku.

Skuteční uživatelé se málokdy chovají přesně podle očekávání návrhářů. Někteří nepochopí pokyny. Jiní budou slabá místa zkoumat záměrně. Tyto okrajové případy nejsou anomálie, ale neocenitelné signály. Správně implementovaný proces hodnocení je zachytí, analyzuje a zahrne do budoucích testů. Rychlé iterace bez slepých míst jsou možné pouze tehdy, když je hodnocení přirozenou součástí systému, nikoli dodatečným doplňkem po dokončení vývoje.

Ochranná opatření a monitorování doporučujeme zavést hned od prvního dne:

• Pomocí benchmarku specifického pro aplikaci pravidelně sledujte metriky modelu a regrese.

• Zachycujte a kontrolujte okrajové případy či adversariální vstupy a přidávejte je do datové sady benchmarku specifického pro aplikaci.

• Zajistěte, aby tyto hodnoticí metriky odpovídaly vašim hlavním KPI.

• Pravidelně prověřujte svou datovou sadu i benchmark, abyste nepřehlíželi nová rizika ani nepodléhali zkreslení.

• Zaveďte automatická upozornění na zhoršení metrik (například při poklesu přesnosti pod 85 % spusťte kontrolu).

• U rozhodnutí s vysokými riziky zachovejte proces lidské kontroly (právní poradenství, zdravotní doporučení, finanční transakce).

Každé spuštění benchmarku spotřebovává výpočetní výkon a energii. Každý nadbytečný experiment zvyšuje náklady. Zodpovědné hodnocení musí vyvažovat důslednost s efektivitou.

Následující praktické kroky pomohou zabránit nekontrolovanému růstu spotřeby energie a nákladů:

• Kdykoli je to možné, používejte menší modely. Počáteční experimenty provádějte na levnějších modelech a na větší přejděte až po ověření daného přístupu.

• Ukládejte prompty a volání API do mezipaměti.

• Plánujte úlohy s ohledem na spotřebu energie (dávkové zpracování, spotové instance, flexibilní priorita).

• Vedle výkonu sledujte také využití výpočetních prostředků.

Stejně důležité je sledovat vznikající předpisy pro AI. I když neexistuje zvláštní právní úprava, stále platí stávající rámce a nezbytná opatření, například:

Ochrana osobních údajů:

• Zajistěte, aby datové sady benchmarků neobsahovaly osobní údaje bez řádného souhlasu.

• Zaveďte zásady uchovávání dat pro zaznamenané dotazy.

• Zajistěte mechanismy pro vyřizování žádostí o výmaz dat.

Rovnost a zkreslení:

• Testujte výkon napříč demografickými skupinami.

• Při tvorbě benchmarku zajistěte rozmanité zastoupení.

Lidská práva a transparentnost:

• Uživatelům jasně popište omezení modelu.

• U rozhodnutí s vysokými riziky poskytujte vysvětlení.

• U kritických aplikací umožněte lidský dohled.

Hodnocení není jednorázová událost, ale neustále se vyvíjející systém. V rychle se měnícím oboru spočívá vaše výhoda ve schopnosti rychle testovat, učit se a přizpůsobovat, abyste mohli modely a nová řešení nasazovat účinněji.

Pokud týmy začlení hodnocení jako klíčovou součást vývoje a produktového řízení, mohou inovovat rychleji a bezpečněji. Nejprve definujte, jak v kontextu vaší aplikace AI vypadá dobrý výsledek, vytvořte platformu pro hodnocení a dále ji rozvíjejte. Získáte tak benchmark specifický pro vaši aplikaci, který vám při každé iteraci poskytne jistotu, že je řešení připraveno na produkční provoz.