Výběr modelu AI: Jak vybírat, testovat, směrovat a řídit modely ve výrobě

Výběr modelu AI zněl jako jednorázová volba: vyberte nejschopnější model, vložte jeho ID do kódu aplikace a odešlete. Tento přístup se ve výrobě rychle rozpadá. Různé pracovní postupy vyžadují různé úrovně kvality, kontextová okna, modality, profily latence, podporu nástrojů, pravidla pro zpracování dat a kontroly nákladů. Model, který je vynikající pro kontrolu kódu, může být pro klasifikaci nehospodárný. Nízkonákladový model, který vypadá atraktivně za cenu tokenu, se může prodražit, pokud selže při ověření, napíše dlouhé odpovědi nebo spustí opakovanou kontrolu člověkem.

Praktickým cílem není najít jeden univerzální nejlepší model. Cílem je vytvořit opakovatelný provozní model pro výběr, testování, směrování, nahrazování a monitorování modelů napříč poskytovateli. Tento provozní model by měl týmům umožnit odpovědět na základní otázky s důkazy: který model je způsobilý pro tuto pracovní zátěž, kolik stojí úspěšný úkol, co se stane, když selže, kdo jej smí používat a jak provedeme migraci, když poskytovatel změní dostupnost nebo vyřadí starší model?

Pro týmy provozující produkční API systémy, zejména u více poskytovatelů, se výběr modelu stává rozhodnutím o části produktu, konstrukcí platformy součásti a řízením součásti. Brána, jako je Model Gate, může pomoci s částmi řídicí roviny: modelové aliasy, koncové body kompatibilní s OpenAI a Anthropic, viditelnost cen, pravidla přístupu ke klíčům API, analýzy využití, limity výdajů, týmové kontroly a automatizace Partner API. Neodstraňuje nutnost hodnotit kvalitu modelu, ale může usnadnit vystavení, omezení, pozorování a změny vybraných modelů, aniž by bylo nutné rozptýlit ID poskytovatelů v každé aplikaci.

Začněte pracovní zátěží, nikoli názvem modelu

Dobrý výběr modelu umělé inteligence začíná klasifikací práce. Podpůrný chatbot, asistent kódování, potrubí pro extrakci dokumentů, generátor odpovědí RAG, klasifikátor moderování, pracovní postup přepisu, generátor obrázků a hlasové rozhraní v reálném čase nemají stejné požadavky. Jejich porovnáním pomocí jediné tabulky hodnocení skryjete věci, na kterých ve výrobě záleží.

Pro každou pracovní zátěž definujte uživatelskou úlohu a provozní omezení. Interní sumarizační úloha může tolerovat několik sekund zpoždění, pokud je výsledek přesný a levný. Pracovní tok chatu zaměřeného na zákazníka může vyžadovat streamovaný výstup, předvídatelné chování při odmítnutí, nízkou latenci na konci a elegantní záložní řešení. Potrubí pro extrakci právních dokumentů může vyžadovat dlouhý kontext, přísné dodržování schématu JSON, nízkou toleranci halucinací a pečlivá pravidla protokolování. Kódovací agent může potřebovat volání nástroje, kontext úložiště, delší uvažování a zpětnou vazbu při provádění testu.

Tento přístup založený na pracovní zátěži mění výběr modelu ze srovnání značek na cvičení požadavků. Než budou kandidáti zařazeni do užšího výběru, sepište si smlouvu o způsobilosti: minimální soubor funkcí, které musí model nebo trasa splňovat, než je lze použít. Smlouva by měla zahrnovat velikost vstupu, velikost výstupu, podporované modality, potřeby strukturovaného výstupu, volání nástroje nebo funkce, streamování, dávkovou podporu, bezpečnostní požadavky, cíl latence, nákladový strop, omezení uchovávání dat a kompatibilitu koncových bodů.

Definujte smlouvu o způsobilosti

Smlouva o způsobilosti je praktickým mantinelem. Zabraňuje týmům vyměňovat modely pouze na základě ceny nebo srovnávacího skóre, když náhrada ve skutečnosti nemůže podporovat pracovní postup. Smlouva může být jednoduchá pro klasifikátor s nízkým rizikem a podrobná pro regulovaného asistenta orientovaného na zákazníka.

Základní požadavky na zachycení

Zdokumentujte minimálně očekávanou velikost výzvy, maximální velikost odezvy, výstupní formát, použití nástroje a rozpočet na latenci. U pracovních postupů RAG zahrňte požadavky na citace, kontroly uzemnění vyhledávání a toleranci pro nejisté odpovědi. Pro úlohy extrakce určete pravidla ověřování schématu, požadovaná pole a způsob, jakým by se mělo zacházet s částečnými výstupy. U multimodálních systémů zaznamenejte, zda pracovní postup potřebuje obrazový vstup, obrazový výstup, zvuk, přepis, interakci v reálném čase nebo vkládání.

Nepředpokládejte, že kompatibilita API znamená kompatibilitu funkcí. Dva poskytovatelé mohou přijímat podobné tvary požadavků, přičemž se liší ve strukturovaném výstupním chování, sémantice streamování, volání nástrojů, účtování tokenů, formátech chyb, limitech rychlosti a zásadách dat. Pokud vaše aplikace závisí na nativní funkci poskytovatele, zaznamenejte tuto závislost explicitně. Přenositelnost je užitečná, ale není zdarma.

Vhodnost před optimalizací

První otázkou výběru je, zda je model vhodný. Teprve po získání způsobilosti by měl tým optimalizovat kvalitu, cenu a rychlost. Model s atraktivní cenou není způsobilý, pokud nemůže zapadnout do kontextu, volat požadované nástroje, zvládnout modalitu, splnit požadavek na zpracování dat nebo spolehlivě vytvořit požadovaný výstupní tvar.

To je místo, kde modelová brána může operativně pomoci. V Model Gate mohou týmy odhalit povolené modely prostřednictvím klíčů API, kontrolovat metadata modelu prostřednictvím výpisu modelů a podrobných koncových bodů a směrovat požadavky aplikací přes stabilní názvy, nikoli pevně zakódovaná ID poskytovatelů. To podporuje řízené rozhraní API pro více modelů, kde jsou přístup k modelu, fakturace a využití viditelné na jednom místě.

Sestavte kandidátní matici

Jakmile je smlouva o pracovním vytížení jasná, vytvořte matici kandidátů. To nemusí být komplikované, ale mělo by to být dostatečně jasné, aby rozhodnutí přežila personální změny, oznámení poskytovatelů a kontroly rozpočtu.

Pro každého kandidáta zaznamenejte ID modelu, poskytovatele, typ koncového bodu, kontextové okno, maximální výstup, podporované modality, podporu nástrojů, podporu strukturovaného výstupu, podporu streamování, podporu dávek, uvažování nebo řízení úsilí, dimenze cen, limity sazeb, regionální omezení, stav životního cyklu, podmínky zpracování dat a známé nekompatibility. Zahrňte produkční alias nebo profil, který by ukazoval na model, pokud bude schválen.

Katalogy poskytovatelů se mění. Ceny, názvy modelů, kontextová okna, výstupní limity, stavy životního cyklu a omezení koncových bodů nejsou dostatečně stabilní, aby se daly pevně kódovat donekonečna. Matice kandidátů poskytuje platformám a aplikačním týmům sdílený pohled na to, co je schváleno, co se hodnotí, co je zastaralé a co musí být vyřazeno.

Používejte hodnocení konkrétních úkolů, nejen veřejné srovnávací testy

Veřejné srovnávací testy jsou užitečné pro objevování. Pomáhají identifikovat kandidáty, kteří budou pravděpodobně dostatečně silní pro určitou třídu úkolů. Neměly by být konečným akceptačním testem pro produkční pracovní postup. Skutečné výzvy jsou komplikovanější než výzvy srovnávací. Zahrnují nejednoznačné pokyny, zákaznický slovník, chybně tvarovaná data, vstupy protivníka, šum při vyhledávání, chybějící kontext a obchodní pravidla, která obecný výsledkový tabulka neměří.

Začněte se základní úrovní kvality. Základní linií může být aktuální produkční model, záměrně silný model nebo ručně zkontrolovaný soubor očekávaných výstupů. Poté vyhodnoťte levnější, rychlejší nebo novější kandidáty proti reprezentativním případům. Zahrňte běžné příklady, okrajové případy, selhání s vysokou hodnotou a příklady, které dříve způsobily incidenty nebo eskalace.

Pokud je to možné, preferujte deterministické kontroly

Mnoho výrobních úkolů lze částečně vyhodnotit pomocí deterministických kontrol. Pro strukturovanou extrakci ověřte schéma JSON, povinná pole, hodnoty výčtu, formáty data a obchodní omezení. Pro generování kódu spusťte testy jednotek, statickou analýzu nebo kompilaci. Pro generování SQL ověřte syntaxi a proveďte ji proti bezpečným testovacím přípravkům. U odpovědí RAG zkontrolujte přítomnost citace, podporu citovaného zdroje a chování při odmítnutí, když chybí důkazy.

Hodnocení člověkem a hodnocení modelem a soudcem jsou stále užitečné, ale měly by se používat tam, kde deterministické kontroly nemohou zachytit laťku kvality. Pokud je použit rozhodčí, kalibrujte rubriku podle známých dobrých a špatných příkladů. Bez kalibrace mohou skóre porotců modelu poskytnout falešný pocit přesnosti.

Vyhodnoťte režimy selhání, nejen průměrnou kvalitu

Průměrné skóre nestačí. Produkční riziko často sedí na chvostu: model, který tiše selže, vymýšlí citace, vrací neplatný JSON při zatížení, ignoruje výsledek nástroje nebo vytváří nebezpečnou odpověď pro malou, ale důležitou skupinu požadavků. Sledujte četnost selhání ověření, četnost opakování, četnost eskalace, kvalitu odmítnutí, vzorce halucinací, rozložení latence a cenu za přijatý výstup.

Měření nákladů na úspěšný úkol

Cena za token je pouze jednou součástí ceny API modelu AI. Model s levnějšími vstupními a výstupními tokeny může stále stát více, pokud potřebuje větší výzvy, produkuje delší odezvy, selže při ověřování schématu, vyžaduje vícenásobné opakování, zmešká příležitosti v mezipaměti nebo posílá více případů ke kontrole člověkem. Naopak dražší model může být celkově levnější, pokud úlohu vyřeší v jednom průchodu s kratšími výzvami a menším počtem oprav.

Jako hlavní finanční metriku použijte cenu za úspěšný úkol. Úspěšný úkol je takový, který splňuje kritéria přijatelnosti pracovního postupu: platný výstup, přijatelná kvalita, v rámci rozpočtu latence a žádná ruční oprava nad rámec očekávaného procesu. Zahrňte vstupní tokeny, výstupní tokeny, poplatky za uvažování nebo úsilí tam, kde je to možné, volání nástrojů, náklady na obrázky nebo zvuk, efekty mezipaměti, dávkové slevy, opakované pokusy, selhání ověření, eskalace podpory a náklady na kontrolu člověkem, pokud podstatně ovlivňují pracovní postup.

Týmy, které spravují více aplikací, by také měly poskytnout vývojářům údaje o cenách a využití. Model Gate publikuje informace o modelech a cenách prostřednictvím svých dokumentů a rozhraní API, včetně klíčových specifických cenových polí, kde je to relevantní. Pro podrobnou kontrolu cen mohou týmy porovnat schválené kandidáty s aktuálními ceny API modelu AI, než propagují model do produkčního profilu.

Řízení latence jako součást výběru

Latence není jen vlastnost poskytovatele. Je tvarován vybraným modelem, velikostí výzvy, délkou výstupu, režimem streamování, chováním opakování, stavem poskytovatele, limity rychlosti, regionem, voláním nástrojů a následným zpracováním. Pokyny poskytovatele běžně uvádějí, že výběr modelu a počet generovaných tokenů jsou hlavními přispěvateli k latenci dokončení, což znamená, že výběr modelu a výstupní kontrola jsou neoddělitelné.

Nastavte rozpočet latence pro každou pracovní zátěž. U interaktivního chatu rozhodněte, jaká latence prvního tokenu a latence plné odezvy jsou přijatelné. Pro zpracování na pozadí rozhodněte, zda je dávkové provedení důležitější než okamžitá doba odezvy. V případě agentních pracovních postupů zohledněte každé volání nástroje a otočení modelu spíše než načasování pouze prvního požadavku.

Při porovnávání kandidátů normalizujte testovací podmínky. Používejte srovnatelné výzvy, výstupní omezení, nastavení streamování, úrovně souběžnosti a zásady opakování. Test latence, který umožňuje jednomu modelu produkovat 100 tokenů a jinému 1000 tokenů, neměří rychlost modelu spravedlivě.

Používejte aliasy a profily namísto pevně zakódovaných ID modelů

Pevné kódování ID modelů poskytovatelů v celém kódu aplikace je jednou z nejčastějších chyb při výběru modelu. Zpomaluje odezvu na ukončení podpory, vytváří nekonzistentní využití napříč týmy a mění modelové změny v nasazení aplikací. Lepším vzorem je použití aliasů nebo profilů modelů pro aplikace.

Alias je stabilní název, například support-fast, support-quality, coding-default, extract-json nebo batch-summary. Za aliasem mohou vlastníci platformy připnout verzi modelu poskytovatele, testovat náhrady, propagovat nového kandidáta nebo se vrátit po regresi. Aplikace požaduje smlouvu o pracovní zátěži, nikoli marketingový název poskytovatele.

Připnuté verze modelu jsou užitečné, když záleží na reprodukovatelnosti. Aliasy spravované poskytovatelem mohou získat vylepšení, ale mohou také způsobit posun chování. Správná volba závisí na pracovním postupu. Kreativní asistent s nízkým rizikem může mít prospěch z vylepšení spravovaných poskytovatelem. Regulovaný extrakční kanál může před migrací vyžadovat připnuté ID, záznam změn a vyhodnocovací bránu.

Model Gate podporuje aliasy modelů jako mechanismus řídicí roviny, který týmům umožňuje udržovat názvy pro aplikace stabilní a zároveň měnit vyřešený model za nimi. Důležitou praxí správy a řízení je zacházet se změnami aliasů jako se změnami ve výrobě: zaznamenejte důvod, ovlivněné pracovní zatížení, výsledky hodnocení, plán zavádění a cíl vrácení.

Oddělte výběr modelu od záložního směrování

Záložní model není jen další nejlevnější nebo nejdostupnější možností. Musí splňovat stejnou smlouvu o způsobilosti nebo jednoznačně selhat. Nebezpečná záloha může narušit strukturované výstupy, chování nástrojů, kontextové předpoklady, bezpečnostní chování, datové zásady nebo uživatelský dojem.

Oddělte rozhodnutí o výběru od zásad směrování. Výběr modelu určuje, které modely jsou schváleny pro pracovní zátěž. Směrování určuje, kdy se má použít každá schválená trasa, na základě stavu poskytovatele, latence, limitů rychlosti, zásad nájemců, pravidel pro náklady nebo reakce na incidenty. Tento rozdíl brání logice dostupnosti v tiché změně sémantiky.

Například pracovní postup zákaznické podpory může mít primární alias, který ukazuje na vysoce kvalitní model, a záložní alias, který ukazuje na rychlejší model od jiného poskytovatele. Oba musí podporovat požadovanou délku kontextu, chování při streamování, volání nástrojů a bezpečnostní očekávání. Pokud žádná nouzová opatření nesplňují smlouvu, systém by měl vrátit jasný důvod selhání, spíše než se nepředvídatelně zhoršit.

Zavádění změn modelu po etapách

Změny modelů by se měly řídit stejnou disciplínou jako jiné změny produkce. Typické zavádění má pět fází: offline vyhodnocení, stínový provoz, kde je to vhodné, omezený kanár, monitorovaná expanze a rozhodnutí o vrácení. Přesný proces závisí na riziku, ale přeskakování přímo ze srovnání s benchmarkem do plného produkčního provozu je u důležitých pracovních postupů zřídka odůvodněné.

Offline hodnocení určí, zda je kandidát věrohodný. Stínový provoz může porovnávat výstupy bez ovlivnění uživatelů, i když zásady pro citlivá data mohou omezit, kdy je to povoleno. Zavedení Canary vystavuje novému modelu malý podíl skutečných uživatelů nebo interních nájemců. Monitorovaná expanze zvyšuje návštěvnost pouze v případě, že kvalita, latence, náklady a metriky chyb zůstanou v mezích.

Kritéria vrácení by měla být definována před zavedením. Mezi příklady patří četnost selhání ověření nad prahem, regrese latence p95, zvýšení nákladů na úspěšnou úlohu, zvýšení eskalace podpory, vzorce stížností uživatelů nebo specifické režimy velmi závažného selhání. Bez předem definovaných kritérií mají týmy tendenci diskutovat o regresích, zatímco uživatelé je již zažívají.

Plán pro ukončení podpory a vyřazení

Správa životního cyklu modelu je součástí řízení modelu AI. Poskytovatelé mohou označit modely jako aktivní, starší, zastaralé nebo vyřazené. Když vyřazený model přestane přijímat požadavky, aplikace, které na něm stále závisí, mohou okamžitě selhat. Riziko je vyšší, když jsou ID modelů rozptýlena mezi službami, úlohami, notebooky a konfigurací specifickou pro tenanta.

Vedejte si runbook ukončení podpory. Mělo by zahrnovat monitorování oznámení poskytovatele, inventář využití, ovlivněné aliasy, dotčené klíče API, vlastníky firem, kandidáty na výměnu, požadavky na hodnocení, termíny migrace, komunikaci s nájemci, kroky zavádění a přiřazení fakturace. Analýza využití je zde zásadní: před výměnou modelu musí týmy vědět, kdo jej používá, jak často, pomocí jakých klíčů, za jakou cenu a pro jaké pracovní postupy.

Brána pomáhá centralizací přístupu k modelu a záznamů o použití. Namísto hledání ID poskytovatele v každém úložišti mohou týmy zkontrolovat, které aliasy a klíče se vztahují k ovlivněnému modelu, a záměrně je migrovat.

Vládní přístup, rozpočty a vlastnictví

Jak roste využití modelu, rozhodnutí o výběru vyžadují řízení přístupu. Ne každý tým, tenant nebo prostředí by mělo mít povoleno používat každý model. Některé modely mohou být pro výchozí přístup příliš drahé. Některé mohou být schváleny pouze pro interní data. Některé mohou vyžadovat přísnější pravidla přihlašování nebo zákaznické přihlášení. Některé mohou být v určitých regionech nedostupné nebo nevhodné pro regulované pracovní zatížení.

Správa začíná vlastnictvím. Každý produkční alias nebo profil by měl mít vlastníka, popis pracovní zátěže, povolené nájemce nebo klíče, očekávání rozpočtu, schválené záložní chování a kadenci kontroly. Pravidla přístupu by měla být vynucována tam, kde je to možné, na úrovni klíče API nebo tenanta, nikoli pouze konvencí vývojářů. Pro citlivá nasazení propojte přístup k modelu s širšími postupy správy klíčů API, aby byly přihlašovací údaje, oprávnění, limity výdajů a auditní záznamy zpracovávány konzistentně.

Pro tvůrce SaaS, agentury nebo prodejce platí stejné zásady pro všechny zákaznické účty. Automatizace ve stylu partnerů může poskytovat klíče tenantů, přiřazovat povolené modely, vynucovat limity výdajů a přiřazovat použití, aniž by koncovým zákazníkům byly vystaveny přihlašovací údaje poskytovatele. To je zvláště důležité, když zákazníci mají různé rozpočty, potřeby shody nebo pravidla dostupnosti modelů.

Monitorujte skutečné využití po zavedení

Žádná sada eval plně nepředpovídá produkční chování. Po zavedení monitorujte skutečné využití podle tenanta, klíče, pracovního postupu, aliasu, vyřešeného modelu, trasy poskytovatele, využití tokenu, latence, chyb, nákladů a záložních událostí. Udržujte dostatek zdroje pro vysvětlení incidentů a otázek týkajících se zpětného zúčtování. Pokud je povoleno rychlé protokolování, pečlivě vzorujte a v případě potřeby citlivá data upravte. Pokud není povoleno rychlé protokolování, je stále cenná pozorovatelnost pouze metadat.

Užitečné produkční metriky zahrnují objem požadavků, míru přijatého výstupu, selhání ověření, opakování, četnost záložních řešení, chyby poskytovatele, chyby limitu četnosti, latenci prvního tokenu, latenci plné odezvy, vstupní tokeny, výstupní tokeny, náklady na úkol, výdaje podle klíče a rozdělení modelu podle pracovního postupu. U systémů pro uživatele zkombinujte technické metriky s produktovými signály, jako je hodnocení palce dolů, eskalace podpory, opuštění nebo čas ruční opravy.

Sledování by mělo vést k dalšímu cyklu výběru. Model, který vypadal nejlépe v offline hodnoceních, může být při reálném souběžném zpracování příliš pomalý. Levnější model může jednomu nájemci ušetřit peníze a jinému selhat, protože jejich datový tvar je odlišný. Záložní cesta může být používána zřídka, ale je drahá, když je spuštěna. Operační model by měl tato zjištění zviditelnit a uplatnit.

Časté chyby při výběru modelu AI

První chybou je výběr z marketingových benchmarků bez testování skutečných výzev. Srovnávací testy pomáhají vybrat modely do užšího výběru, ale přijetí do výroby by mělo záviset na reprezentativních datech a nákladech na selhání.

Druhou chybou je optimalizace na cenu tokenu a ignorování celkových nákladů na úkol. Opakované pokusy, dlouhé výstupy, volání nástrojů, selhání ověření, vynechání mezipaměti, dávkové chování a kontrola člověkem mohou zvrátit zdánlivé hodnocení.

Třetí chybou je zacházení s dlouhým kontextovým oknem jako s náhradou za vyhledávání, shrnutí a rychlý návrh. Dlouhý kontext může být cenný, ale může také zvýšit náklady a latenci a zároveň pohřbít relevantní důkazy.

Čtvrtou chybou je použití aliasů spravovaných poskytovatelem všude, aniž by došlo ke sledování posunu chování nebo zachování cílů vrácení. Aliasy poskytovatelů jsou pohodlné, ale kritické pracovní postupy často vyžadují připnuté verze a řízené migrace.

Pátou chybou je ponechání záložního řešení ignorovat smlouvu o způsobilosti. Záložní opatření, které nedokáže vytvořit požadovaný JSON, použít požadované nástroje, splnit datové zásady nebo zapadnout do kontextu, není bezpečné.

Šestá chyba spočívá v tom, že se nepodařilo zaznamenat požadovaný alias, vyřešený model, trasu poskytovatele, verzi ceny, využití tokenu, latenci a chybový stav. Bez tohoto přiřazení se incidenty a fakturační spory stanou jen dohady.

Praktický pracovní postup výběru

Trvalý pracovní postup může být jednoduchý. Inventujte aktuální využití podle aplikace, koncového bodu, tenanta, klíče API, pracovního postupu, skupiny výzev, nákladů, latence, chyb a vlastníka firmy. Definujte třídy pracovní zátěže a smlouvy o způsobilosti. Vytvořte matici kandidátů. Stanovte si základní linii kvality. Spusťte hodnocení specifické pro úlohu. Změřte náklady na úspěšný úkol. Záměrně vybírejte připnuté modely nebo aliasy poskytovatelů. Vystavte produkční aliasy aplikacím. Definujte záložní pravidla. Rozbalte po etapách. Sledujte skutečné využití. Zkontrolujte ukončení podpory a změny cen podle plánu.

Tento pracovní postup mění výběr modelu na opakovatelnou platformu namísto řady jednorázových rozhodnutí. Poskytuje aplikačním týmům stabilní smlouvy, poskytuje financím a operacím lepší přehled o nákladech, poskytuje zabezpečení jasnější hranice přístupu a poskytuje produktovým týmům bezpečnější způsob, jak v průběhu času zlepšovat kvalitu.

Závěr

Výběr modelu AI již není jen o výběru schopného LLM. V produkci ovlivňuje vybraný model spolehlivost, latenci, fakturaci, shodu, uživatelskou zkušenost a reakci na incidenty. Nejlepší rozhodnutí je specifické pro pracovní zátěž a založené na důkazech: definujte smlouvu o způsobilosti, testujte kandidáty na reprezentativních datech, měřte náklady na úspěšný úkol, řiďte zavedení a sledujte skutečné využití po nasazení.

U systémů s více poskytovateli je nejsilnějším vzorem udržet aplikace zaměřené na stabilní aliasy nebo profily, zatímco vlastníci platforem spravují schválené modely, záložní trasy, pravidla přístupu, kontroly výdajů a změny životního cyklu v zákulisí. Model Gate do tohoto provozního modelu zapadá jako brána a řídicí rovina pro vystavení modelů prostřednictvím kompatibilních rozhraní API, správu klíčů a týmů, zobrazení využití a cen a změnu přístupu k modelu, aniž by se každé rozhodnutí o modelu změnilo na přepis aplikace.