Stručná odpověď: Definujte, co znamená „dobrý“ přístup pro váš případ užití, a poté jej otestujte s reprezentativními, verzovanými výzvami a hraničními případy. Spárujte automatizované metriky s hodnocením lidských rubrik, spolu s kontrolami bezpečnosti protichůdných systémů a kontrolami vstřikováním výzev. Pokud se stanou závaznými omezení nákladů nebo latence, porovnejte modely podle úspěšnosti úkolu na vynaloženou libru a doby odezvy p95/p99.
Klíčové poznatky:
Odpovědnost : Jasně určete vlastníky, uchovávejte protokoly verzí a po jakékoli výzvě nebo změně modelu znovu spusťte vyhodnocení.
Transparentnost : Než začnete shromažďovat skóre, zapište si kritéria úspěchu, omezení a náklady na neúspěch.
Auditabilita : Udržujte opakovatelné testovací sady, označené datové sady a sledované metriky latence p95/p99.
Napaditelnost : Pro sporné výstupy používejte pravidla pro lidské posouzení a definovaný způsob odvolání.
Odolnost proti zneužití : Vkládání informací do systému Red team, citlivá témata a nadměrné odmítání ochrany uživatelů.
Pokud vybíráte model pro produkt, výzkumný projekt nebo dokonce interní nástroj, nemůžete jen tak říct „zní to chytře“ a odeslat ho (viz průvodce OpenAI evals a NIST AI RMF 1.0 ). Takhle skončíte s chatbotem, který sebevědomě vysvětluje, jak ohřát vidličku v mikrovlnné troubě. 😬
Články, které byste si mohli po tomto přečíst:
🔗 Budoucnost umělé inteligence: trendy formující příští desetiletí
Klíčové inovace, dopad na pracovní místa a etika, které je třeba sledovat.
🔗 Základní modely generativní umělé inteligence vysvětlené pro začátečníky
Zjistěte, co jsou začátečníky, jak se trénují a proč jsou důležité.
🔗 Jak umělá inteligence ovlivňuje životní prostředí a spotřebu energie
Prozkoumejte emise, poptávku po elektřině a způsoby, jak snížit ekologickou stopu.
🔗 Jak dnes funguje AI upscaling pro ostřejší snímky
Podívejte se, jak modely přidávají detaily, odstraňují šum a čistě zvětšují.
1) Definování „dobrého“ (záleží na situaci a to je v pořádku) 🎯
Než začnete s jakýmkoli hodnocením, rozhodněte se, jak vypadá úspěch. Jinak změříte všechno a nic se nenaučíte. Je to jako byste si přinesli krejčovský metr, abyste hodnotili soutěž v nejlepších dortích. Jasně, dostanete čísla, ale moc vám toho neřeknou 😅
Vyjasnit:
-
Cíl uživatele : shrnutí, vyhledávání, psaní, uvažování, extrakce faktů
-
Cena selhání : špatné doporučení filmu je vtipné; špatný lékařský pokyn… není vtipný (rámování rizik: NIST AI RMF 1.0 ).
-
Běhové prostředí : na zařízení, v cloudu, za firewallem, v regulovaném prostředí
-
Primární omezení : latence, cena za požadavek, soukromí, vysvětlitelnost, vícejazyčná podpora, ovládání tónu
Model, který je v jedné práci „nejlepší“, může být v jiné katastrofou. To není rozpor, to je realita. 🙂
2) Jak vypadá robustní rámec pro hodnocení modelu umělé inteligence 🧰
Ano, tohle je ta část, kterou lidé přeskakují. Vezmou si benchmark, jednou ho spustí a hotovo. Robustní evaluační framework má několik konzistentních vlastností (praktické příklady nástrojů: OpenAI Evals / OpenAI evals guide ):
-
Opakovatelné – můžete to spustit znovu příští týden a důvěřovat srovnání
-
Reprezentativní – odráží vaše skutečné uživatele a úkoly (nejen drobnosti)
-
Vícevrstvý – kombinuje automatizované metriky + lidskou kontrolu + kontradiktorní testy
-
Akční – výsledky vám řeknou, co máte opravit, ne jen „skóre se snížilo“
-
Odolné proti neoprávněné manipulaci – zabraňuje „učení se k testu“ nebo náhodnému úniku
-
Cenově uvědomělé – samotné hodnocení by vás nemělo přivést k bankrotu (pokud nemáte rádi bolest)
Pokud vaše hodnocení nepřežije skeptický názor kolegy z týmu: „Dobře, ale namapujte to na produkci,“ pak ještě není hotové. To je kontrola vibrací.
3) Jak vyhodnotit modely umělé inteligence počínaje analýzou případů užití 🍰
Zde je trik, který ušetří spoustu času: rozdělte případ užití na části .
Místo „vyhodnocení modelu“ proveďte:
-
Porozumění záměru (dostane uživatel to, co chce)
-
Vyhledávání nebo použití kontextu (používá poskytnuté informace správně)
-
Úvaha / vícekrokové úkoly (zůstává to koherentní napříč kroky)
-
Formátování a struktura (dodržuje pokyny)
-
Sladění bezpečnosti a zásad (zabraňuje nebezpečnému obsahu; viz NIST AI RMF 1.0 )
-
Tón a charakter značky (zní to tak, jak byste si přáli)
Díky tomu se „Jak vyhodnocovat modely umělé inteligence“ necítí jako jedna obrovská zkouška a spíše jako sada cílených kvízů. Kvízy jsou otravné, ale dají se zvládnout. 😄
4) Základy offline hodnocení – testovací sady, popisky a nenápadné detaily, na kterých záleží 📦
Offline eval je proces, kdy se provádějí kontrolované testy, než se uživatelé čehokoli dotknou (vzory pracovního postupu: OpenAI Evals ).
Sestavte si nebo si sežeňte testovací sadu, která je skutečně vaše
Dobrá sada testů obvykle obsahuje:
-
Zlaté příklady : ideální výstupy, které byste hrdě odeslali
-
Okrajové případy : nejednoznačné výzvy, neuspořádané vstupy, neočekávané formátování
-
Sondy v režimu selhání : podněty, které svádějí k halucinacím nebo nebezpečným odpovědím (rámování testování rizik: NIST AI RMF 1.0 )
-
Rozmanitost pokrytí : různé úrovně uživatelských dovedností, dialekty, jazyky, domény
Pokud testujete pouze „čisté“ výzvy, model bude vypadat úžasně. Pak se vaši uživatelé objeví s překlepy, polovičatými větami a energií zuřivého klikání. Vítejte v realitě.
Možnosti označování (neboli: úrovně přísnosti)
Výstupy můžete označit jako:
-
Binární : prošel/neprošel (rychlý, drsný)
-
Ordinální : skóre kvality 1–5 (nuansované, subjektivní)
-
Více atributů : přesnost, úplnost, tón, použití citací atd. (nejlepší, pomalejší)
Více atributů je pro mnoho týmů ideální volbou. Je to jako ochutnávat jídlo a posuzovat slanost odděleně od textury. Jinak jen řeknete „dobré“ a pokrčíte rameny.
5) Metriky, které nelžou – a metriky, které tak trochu lžou 📊😅
Metriky jsou cenné… ale mohou být také třpytivou bombou. Lesknou se všude a těžko se s nimi manipuluje.
Běžné metrické rodiny
-
Přesnost / exaktní shoda : skvělé pro extrakci, klasifikaci, strukturované úkoly
-
F1 / precision / recall : užitečné, když je chyba něčeho horší než nadbytečný šum (definice: scikit-learn precision/recall/F-score )
-
Překrývání stylů BLEU / ROUGE : vhodné pro shrnující úkoly, často zavádějící (původní metriky: BLEU a ROUGE )
-
Vkládání podobnosti : užitečné pro sémantickou shodu, může odměňovat nesprávné, ale podobné odpovědi
-
Míra úspěšnosti úkolu : „Dostal uživatel, co potřeboval?“ je zlatým standardem, pokud je dobře definován
-
Dodržování omezení : dodržuje formát, délku, platnost JSON, dodržování schématu
Klíčový bod
Pokud je váš úkol otevřený (psaní, uvažování, chat s podporou), metriky s jedním číslem mohou být… vratké. Ne zbytečné, jen vratké. Měření kreativity pravítkem je možné, ale budete se při tom cítit hloupě. (Taky si pravděpodobně vypíchnete oko.)
Takže: používejte metriky, ale ukotvěte je v lidské kontrole a skutečných výsledcích úkolů (jeden příklad diskuse o hodnocení založeném na LLM + upozornění: G-Eval ).
6) Srovnávací tabulka - nejlepší možnosti hodnocení (s zvláštnostmi, protože život má své zvláštnosti) 🧾✨
Zde je praktický seznam přístupů k hodnocení. Kombinujte je. Většina týmů to dělá.
| Nástroj / Metoda | Publikum | Cena | Proč to funguje |
|---|---|---|---|
| Ručně sestavená sada prompts testů | Produkt + inženýrství | $ | Velmi cílené, rychle zachycuje regrese - ale musíte to udržovat navždy 🙃 (startovací nástroje: OpenAI Evals ) |
| Panel hodnocení lidských rubrik | Týmy, které mohou ušetřit recenzenty | $$ | Nejlepší pro tón, nuance, „přijal by to člověk“, mírný chaos v závislosti na recenzentech |
| LLM jako soudce (s rubrikami) | Rychlé iterační smyčky | $-$$ | Rychlé a škálovatelné, ale může dědit zkreslení a někdy hodnotí pocity, nikoli fakta (výzkum + známé problémy s zkreslením: G-Eval ) |
| Sprint s protichůdným červeným týmem | Bezpečnost + shoda s předpisy | $$ | Nachází pikantní selhání, zejména rychlou injekci - působí jako zátěžový test v posilovně (přehled hrozeb: OWASP LLM01 Prompt Injection / OWASP Top 10 pro LLM aplikace ) |
| Generování syntetických testů | Týmy pro datové osvětlení | $ | Skvělé pokrytí, ale syntetické výzvy mohou být příliš úhledné, příliš zdvořilé… uživatelé nejsou zdvořilí |
| A/B testování se skutečnými uživateli | Produkty pro dospělé | $$$ | Nejjasnější signál – zároveň emocionálně nejvíce stresující, když se metriky mění (klasický praktický průvodce: Kohavi a kol., „Řízené experimenty na webu“ ) |
| Vyhodnocení založené na načtení (kontroly RAG) | Vyhledávání + aplikace pro kontrolu kvality | $$ | Měří „správně využívá kontext“, snižuje inflaci skóre halucinací (přehled hodnocení RAG: Hodnocení RAG: Průzkum ) |
| Monitorování + detekce driftu | Výrobní systémy | $$-$$$ | Postupem času podléhá degradaci - neokázalé až do dne, kdy vás zachrání 😬 (přehled driftu: Průzkum driftu konceptu (PMC) ) |
Všimněte si, že ceny jsou schválně nízké. Záleží na rozsahu, nástrojích a počtu schůzek, které omylem vyvoláte.
7) Lidské hodnocení – tajná zbraň, kterou lidé nedostatečně financují 👀🧑⚖️
Pokud provádíte pouze automatizované vyhodnocování, zmeškáte:
-
Nesoulad tónů („proč je to tak sarkastické“)
-
Jemné faktické chyby, které vypadají plynule
-
Škodlivé důsledky, stereotypy nebo nevhodné formulace (riziko + zkreslení: NIST AI RMF 1.0 )
-
Selhání při dodržování instrukcí, která stále zní „chytře“
Udělejte rubriky konkrétní (jinak recenzenti budou volně ladit)
Špatná rubrika: „Ochota“
Lepší rubrika:
-
Správnost : fakticky přesné vzhledem k zadání + kontextu
-
Úplnost : pokrývá požadované body bez zbytečných detailů
-
Srozumitelnost : čitelná, strukturovaná, minimální zmatek
-
Zásady / bezpečnost : vyhýbá se omezenému obsahu, dobře zvládá odmítnutí (bezpečnostní rámování: NIST AI RMF 1.0 )
-
Styl : odpovídá hlasu, tónu tónu a úrovni čtení
-
Věrnost : nevymýšlí si zdroje ani nepodložené tvrzení
Také občas provádějte kontroly mezi hodnotiteli. Pokud se dva recenzenti neustále neshodují, není to „problém lidí“, ale problém rubriky. Obvykle (základy spolehlivosti mezi hodnotiteli: McHugh o Cohenově kappa ).
8) Jak vyhodnotit modely umělé inteligence z hlediska bezpečnosti, robustnosti a „uf, uživatelé“ 🧯🧪
Tohle je ta část, kterou děláte před spuštěním – a pak v ní pokračujete, protože internet nikdy nespí.
Zahrnout testy robustnosti
-
Překlepy, slang, porušená gramatika
-
Velmi dlouhé a velmi krátké výzvy
-
Protichůdné pokyny („buďte struční, ale uveďte každý detail“)
-
Vícenásobné konverzace, kde si uživatelé mění cíle
-
Výzva k pokusům o vložení kódu („ignorovat předchozí pravidla…“) (podrobnosti o hrozbě: OWASP LLM01 Výzva k vložení kódu )
-
Citlivá témata, která vyžadují opatrné odmítnutí (rámování rizik/bezpečnosti: NIST AI RMF 1.0 )
Hodnocení bezpečnosti není jen o tom, „odmítá to“
Dobrý model by měl:
-
Jasně a klidně odmítněte nebezpečné požadavky (formulace pokynů: NIST AI RMF 1.0 )
-
V případě potřeby poskytněte bezpečnější alternativy
-
Vyhněte se nadměrnému odmítání neškodných dotazů (falešně pozitivní výsledky)
-
Zvládejte nejednoznačné požadavky objasňujícími otázkami (pokud je to povoleno)
Nadměrné odmítání je skutečný problém produktu. Uživatelé nemají rádi, když se s nimi zachází jako s podezřelými skřety. 🧌 (I když to podezřelí skřeti jsou.)
9) Náklady, latence a provozní realita – hodnocení, na které všichni zapomínají 💸⏱️
Model může být „úžasný“ a přesto pro vás nevhodný, pokud je pomalý, drahý nebo provozně nestabilní.
Vyhodnoťte:
-
Distribuce latence (nejen průměr - záleží na p95 a p99) (proč záleží na percentilech: Google SRE Workbook on Monitoring )
-
Cena za úspěšný úkol (ne cena za token samostatně)
-
Stabilita při zátěži (časové limity, limity rychlosti, anomální špičky)
-
Spolehlivost volání nástrojů (pokud používají funkce, jak se chovají)
-
Tendence délky výstupu (některé modely se liší a liší se tím, co stojí peníze)
V praxi může vyhrát o něco horší model, který je dvakrát rychlejší. Zní to očividně, ale lidé to ignorují. Jako byste si koupili sportovní auto na nákup a pak si stěžovali na prostor v kufru.
10) Jednoduchý komplexní pracovní postup, který můžete kopírovat (a upravovat) 🔁✅
Zde je praktický postup, jak vyhodnocovat modely umělé inteligence , aniž byste se museli uvrhnout do nekonečných experimentů:
-
Definujte úspěch : úkol, omezení, náklady na selhání
-
Vytvořte malou „základní“ testovací sadu : 50–200 příkladů, které odrážejí skutečné použití
-
Přidat okrajové a adversární sady : pokusy o vstřikování, nejednoznačné výzvy, bezpečnostní sondy (třída vstřikování výzev: OWASP LLM01 )
-
Spouštět automatické kontroly : formátování, platnost JSON, základní správnost, kde je to možné
-
Spuštění lidské kontroly : ukázkové výstupy napříč kategoriemi, hodnocení pomocí rubriky
-
Porovnejte kompromisy : kvalita vs. cena vs. latence vs. bezpečnost
-
Pilotní verze v omezeném vydání : A/B testy nebo postupné zavádění (průvodce A/B testováním: Kohavi a kol. )
-
Monitorování v produkčním prostředí : drift, regrese, smyčky zpětné vazby od uživatelů (přehled driftu: Průzkum driftu konceptů (PMC) )
-
Iterovat : aktualizace výzev, načtení, doladění, ochranné zábrany a poté opětovné spuštění eval (iterační vzory eval: Průvodce OpenAI evals )
Uchovávejte si verzované protokoly. Ne proto, že je to zábava, ale proto, že si v budoucnu budete děkovat s kávou v ruce a mumláním „co se změnilo…“ ☕🙂
11) Časté nástrahy (neboli: způsoby, jakými se lidé nechtěně oklamou) 🪤
-
Trénink pro testování : optimalizujete výzvy, dokud benchmark nevypadá skvěle, ale uživatelé trpí.
-
Netěsná vyhodnocovací data : výzvy k testování se zobrazují v trénovacích nebo dolaďovacích datech (jejda)
-
Uctívání jediné metriky : honba za jedním skóre, které neodráží hodnotu pro uživatele
-
Ignorování posunu v distribuci : chování uživatelů se mění a váš model se tiše degraduje (rámování produkčních rizik: Průzkum driftu konceptů (PMC) )
-
Nadměrné indexování na základě „chytrosti“ : chytré uvažování nevadí, ať už narušuje formátování nebo si vymýšlí fakta
-
Netestování kvality odmítnutí : „Ne“ může být správné, ale UX je stále hrozné.
Také si dejte pozor na dema. Dema jsou jako filmové trailery. Ukazují sestřihy, skrývají pomalé části a občas lžou s dramatickou hudbou. 🎬
12) Závěrečné shrnutí toho, jak vyhodnocovat modely umělé inteligence 🧠✨
Hodnocení modelů umělé inteligence není o jediném skóre, je to vyvážené jídlo. Potřebujete bílkoviny (správnost), zeleninu (bezpečnost), sacharidy (rychlost a cena) a ano, někdy i dezert (chuť a potěšení) 🍲🍰 (rámování rizik: NIST AI RMF 1.0 )
Pokud si na nic dalšího nevzpomenete:
-
Definujte, co znamená „dobrý“ pro váš případ použití
-
Používejte reprezentativní testovací sady, nejen známé benchmarky
-
Kombinujte automatizované metriky s kontrolou lidských rubrik
-
Robustnost a bezpečnost testů, jako by uživatelé byli nepřátelští (protože někdy… jsou) (třída promptne injection: OWASP LLM01 )
-
Zahrňte náklady a latenci do hodnocení, ne jako dodatečnou myšlenku (proč na percentilech záleží: Google SRE Workbook )
-
Monitorování po spuštění – modely se mění, aplikace se vyvíjejí, lidé se stávají kreativními (přehled driftů: Průzkum driftu konceptů (PMC) )
Takhle vyhodnotit modely umělé inteligence tak, aby obstály, i když je váš produkt spuštěný a lidé začnou dělat nepředvídatelné věci. Což je vždycky pravda. 🙂
Často kladené otázky
Jaký je první krok při vyhodnocení modelů umělé inteligence pro reálný produkt?
Začněte definováním toho, co znamená „dobrý“ pro váš konkrétní případ použití. Jasně uveďte cíl uživatele, kolik vás stojí selhání (nízké vs. vysoké rizikové situace) a kde bude model běžet (cloud, na zařízení, regulované prostředí). Poté uveďte přísná omezení, jako je latence, náklady, soukromí a kontrola tónů. Bez tohoto základu budete měřit hodně a stejně uděláte špatné rozhodnutí.
Jak vytvořím testovací sadu, která skutečně odráží mé uživatele?
Vytvořte si testovací sadu, která bude skutečně vaše, ne jen veřejný benchmark. Zahrňte zlaté příklady, které byste hrdě vydali, a také hlučné, nestandardní výzvy s překlepy, polovičatými větami a nejednoznačnými požadavky. Přidejte okrajové případy a testy selhání, které svádějí k halucinacím nebo nebezpečným odpovědím. Zohledněte rozmanitost v úrovni dovedností, dialektech, jazycích a doménách, aby se výsledky v produkčním prostředí nezhroutily.
Které metriky bych měl použít a které mohou být zavádějící?
Přiřaďte metriky typu úkolu. Přesná shoda a přesnost fungují dobře pro extrakci a strukturované výstupy, zatímco precision/recall a F1 pomáhají, když je přehlédnutí něčeho horší než nadbytečný šum. Metriky překrývání, jako je BLEU/ROUGE, mohou být u otevřených úkolů zavádějící a vkládání podobnosti může odměňovat „nesprávné, ale podobné“ odpovědi. Pro psaní, podporu nebo uvažování kombinujte metriky s lidskou kontrolou a mírou úspěšnosti úkolů.
Jak mám strukturovat hodnocení, aby byla opakovatelná a produkční?
Robustní rámec pro hodnocení je opakovatelný, reprezentativní, vícevrstvý a proveditelný. Kombinujte automatizované kontroly (formát, validita JSON, základní správnost) s hodnocením lidských rubrik a testy protichůdnosti. Zajistěte odolnost proti neoprávněným změnám tím, že se vyhnete únikům informací a budete se „zaškolovat v testování“. Udržujte hodnocení cenově dostupné, abyste ho mohli často opakovat, ne jen jednou před spuštěním.
Jaký je nejlepší způsob, jak provádět lidské hodnocení, aniž by se to změnilo v chaos?
Používejte konkrétní rubriku, aby recenzenti neexperimentovali. Hodnotěte atributy jako správnost, úplnost, srozumitelnost, bezpečnost/dodržování zásad, styl/soulad hlasu a věrnost (nevymýšlejte si tvrzení ani zdroje). Pravidelně kontrolujte shodu mezi hodnotiteli; pokud se recenzenti neustále neshodují, rubrika pravděpodobně potřebuje upřesnit. Lidská kontrola je obzvláště cenná z hlediska tónového nesouladu, drobných faktických chyb a nedodržování pokynů.
Jak mohu vyhodnotit bezpečnost, robustnost a rizika okamžité injekce?
Testujte s textem typu „ugh, uživatelé“: překlepy, slang, protichůdné instrukce, velmi dlouhé nebo velmi krátké výzvy a změny cílů s více kroky. Zahrňte pokusy o vložení výzev, jako je „ignorovat předchozí pravidla“, a citlivá témata, která vyžadují pečlivé odmítnutí. Dobrý bezpečnostní výkon neznamená jen odmítnutí – jde o jasné odmítnutí, nabízení bezpečnějších alternativ, když je to vhodné, a vyhýbání se nadměrnému odmítání neškodných dotazů, které poškozují UX.
Jak vyhodnotím náklady a latenci způsobem, který odpovídá realitě?
Neměřte pouze průměry – sledujte rozložení latence, zejména p95 a p99. Vyhodnoťte náklady na úspěšnou úlohu, nikoli náklady na token izolovaně, protože opakované pokusy a nepravidelné výstupy mohou smazat úspory. Otestujte stabilitu při zátěži (časové limity, limity rychlosti, špičky) a spolehlivost volání nástrojů/funkcí. O něco horší model, který je dvakrát rychlejší nebo stabilnější, může být lepší volbou produktu.
Jaký je jednoduchý komplexní pracovní postup pro vyhodnocování modelů umělé inteligence?
Definujte kritéria a omezení úspěchu a poté vytvořte malou základní testovací sadu (zhruba 50–200 příkladů), která odráží skutečné využití. Přidejte okrajové a adversarial sady pro bezpečnost a pokusy o vstřikování. Spusťte automatizované kontroly a poté vzorkujte výstupy pro hodnocení lidských rubrik. Porovnejte kvalitu vs. náklady vs. latenci vs. bezpečnost, pilotní projekt s omezeným nasazením nebo A/B testem a monitorujte v produkčním prostředí drift a regrese.
Jaké jsou nejčastější způsoby, jak se týmy při vyhodnocování modelů nechtěně oklamou?
Mezi běžné pasti patří optimalizace výzev k dosažení optimálního benchmarku, zatímco uživatelé trpí, únik výzev k hodnocení do trénování nebo doladění dat a uctívání jediné metriky, která neodráží hodnotu pro uživatele. Týmy také ignorují posun v distribuci, nadměrně indexují „chytrost“ namísto dodržování formátu a věrnosti a přeskakují testování kvality odmítnutí. Dema mohou tyto problémy skrýt, proto se spoléhejte na strukturovaná hodnocení, nikoli na zvýrazněné scény.
Reference
-
OpenAI - Průvodce hodnocením OpenAI - platform.openai.com
-
Národní institut pro standardy a technologie (NIST) - Rámec pro řízení rizik umělé inteligence (AI RMF 1.0) - nist.gov
-
OpenAI - openai/evals (repozitář GitHub) - github.com
-
scikit-learn - podpora_precision_recall_fscore - scikit-learn.org
-
Asociace pro počítačovou lingvistiku (ACL Anthology) - BLEU - aclanthology.org
-
Asociace pro počítačovou lingvistiku (ACL Anthology) - ROUGE - aclanthology.org
-
arXiv - G-Eval - arxiv.org
-
OWASP - LLM01: Prompt Injection - owasp.org
-
OWASP - OWASP Top 10 pro aplikace s velkými jazykovými modely - owasp.org
-
Stanfordská univerzita - Kohavi a kol., „Řízené experimenty na webu“ - stanford.edu
-
arXiv - Hodnocení RAG: Průzkum - arxiv.org
-
PubMed Central (PMC) - Průzkum driftu konceptů (PMC) - nih.gov
-
PubMed Central (PMC) - McHugh o Cohenově kappa - nih.gov
-
Google - Pracovní sešit SRE o monitorování - google.workbook