Orchestrace modelů: jak vybírat a skládat modely v AI systému | Knihovna

Zlaté pravidlo: Neorchestruj modely proto, že to zní chytře. Dělej to tehdy, když různé typy práce mají prokazatelně jiné nároky a umíš změřit, kdy levnější cesta stačí, kdy má předat úlohu silnější cestě a kdy se má systém zastavit.

Co to je a co to není

Orchestrace modelů je provozní vrstva, která pro každý krok vybírá model, konfiguraci a další postup. Rozhoduje například mezi malým rychlým modelem, dražším frontier modelem, lokálním modelem nebo čistě deterministickým kódem. Hlídá rozpočet, latenci, citlivost dat, kvalitu výstupu a chování při chybě.

Není to synonymum pro multi-agent systém. Pevný workflow může používat tři modely a pořád zůstává workflow. Není to ani univerzální proxy, která jen přepisuje názvy endpointů. Modely se liší v tool use, limitech kontextu, strukturovaném výstupu, bezpečnostním chování i typech chyb. A už vůbec to není důvod rozdělit jeden jednoduchý prompt mezi pět modelů.

Nejdřív postav baseline s jedním rozumně vybraným modelem. Orchestraci přidej až ve chvíli, kdy logy ukážou konkrétní problém: zbytečně drahé rutinní úlohy, slabý výkon v určité třídě požadavků, požadavek na lokální zpracování nebo potřebu nezávislého ověření.

Rozhodovací strom pro routing

Router nepotřebuje začínat jako další LLM. První verze bývá lépe čitelná jako několik pravidel:

Je úloha deterministická?
├─ ano  → kód, SQL, vyhledávání nebo validátor bez LLM
└─ ne
   Obsahuje data, která nesmí opustit region či zařízení?
   ├─ ano  → lokální nebo regionálně schválený model
   └─ ne
      Je výsledek nevratný nebo vysoce rizikový?
      ├─ ano  → silnější model + kontrola + případně člověk
      └─ ne
         Zvládá levnější model tuto třídu úloh v evalech?
         ├─ ano  → levnější model
         └─ ne   → silnější model

Po každém kroku:
- porušení schématu nebo chyba nástroje → oprava jednou, pak handoff
- nízká ověřitelná jistota → retrieval, silnější model nebo člověk
- timeout či výpadek providera → kompatibilní záložní cesta
- bezpečnostní problém → zastavit, ne improvizovat

Signály pro routing mají být dostupné před voláním drahého modelu: typ požadavku, jazyk, velikost vstupu, zdroj dat, požadované nástroje, tenant, SLA a riziková třída. Sebehodnocení modelu může být pomocný signál, ne jediný důkaz. Model umí sebevědomě schválit vlastní chybu.

Praktický blueprint

Užitečná architektura má malé množství explicitních vrstev:

Normalizace vstupu odstraní nepotřebná data, přiřadí tenant a vytvoří identifikátor běhu.
Policy gate určí povolené providery, region, datovou klasifikaci, maximální cenu a akce vyžadující schválení.
Router vybere cestu podle verzovaných pravidel nebo klasifikátoru. Vrátí také důvod rozhodnutí.
Model adapter převádí interní formát zpráv, nástrojů a strukturovaného výstupu do API konkrétního providera.
Executor spustí model a nástroje s timeoutem, limitem kroků a idempotency klíčem.
Verifier zkontroluje schéma, citace, business pravidla nebo strojově ověřitelný výsledek.
Handoff controller rozhodne o opravě, eskalaci, změně modelu, lidském review nebo zastavení.
Observability a eval store uloží verzi promptu, model, důvod routingu, latenci, cenu, výsledek kontroly a finální stav.

Doménová logika nemá znát názvy providerů. Interní kontrakt může být jednoduchý: task, risk, data_class, allowed_tools, output_schema a budget. Adaptéry pak řeší rozdíly providerů. Abstrakce však nesmí schovat vše do nejmenšího společného jmenovatele. Když jeden model nabízí vlastnost, která prokazatelně zlepšuje výsledek, použij ji přes explicitní capability flag a měj náhradní cestu.

Handoffs a fallbacky bez tichého chaosu

Handoff předává práci jiné cestě z věcného důvodu: vstup se ukázal jako složitější, verifikace selhala nebo je potřeba jiná schopnost. Předávej strukturovaný stav, ne celý neupravený transcript. Další model potřebuje původní cíl, ověřená fakta, výsledky nástrojů, co už selhalo a zbývající rozpočet.

Fallback řeší nedostupnost nebo známý typ selhání. Pořadí musí být předem dané. Například: stejný model znovu pouze při přechodné síťové chybě; oprava výstupu při porušení schématu; silnější model při neúspěšné věcné kontrole; jiný provider při výpadku; člověk u nevratné akce. Nekonečný retry řetězec není odolnost, jen skrytý účet.

Každý přechod musí zachovat bezpečnostní pravidla. Záložní model nesmí dostat data, která primární model kvůli lokalitě dostat nesměl. A fallback nesmí změnit „vyžaduje schválení“ na „zkus to automaticky“.

Evaly a cena za úspěch

Cena za milion tokenů je nákupní údaj, ne metrika systému. Rozhodující je cena za úspěšně dokončenou úlohu:

celkové náklady běhů + retrieval + nástroje + verifikace + lidské opravy
──────────────────────────────────────────────────────────────────────
počet úloh, které prošly definovaným kritériem úspěchu

Do eval sady dej skutečné třídy práce, hraniční případy, dlouhé vstupy, různé jazyky a bezpečnostní scénáře. Pro každou routingovou cestu sleduj úspěšnost, latenci, počet pokusů, četnost handoffů, lidské zásahy a typy chyb. Porovnávej s baseline jednoho modelu. Router optimalizovaný jen na cenu se naučí levně selhávat; router optimalizovaný jen na průměrnou kvalitu pošle všechno frontier modelu.

Měň jedno rozhodnutí najednou a přehrávej stejnou eval sadu. Produkční provoz sleduj odděleně, protože změna mixu požadavků může znehodnotit starý routing. Neopisuj veřejné benchmarky jako vlastní důkaz. Rozhoduje výkon na tvých úlohách a podle tvé definice úspěchu.

Bezpečnost a lokalita dat

Router je bezpečnostně citlivá součást. Vidí metadata, podle kterých se rozhoduje, kam data poputují. Klasifikace dat proto musí proběhnout před providerem a musí být vynucená policy vrstvou, ne jen napsaná v promptu.

Pro každý model eviduj povolené regiony, retenční podmínky, použití dat pro trénink, podporované šifrování, auditní možnosti a povolené nástroje. Osobní údaje a tajemství minimalizuj nebo rediguj ještě před voláním modelu. Logy nesmí znovu vytvořit únik tím, že uloží celý prompt. Tool credentials drž mimo kontext a autorizuj každý nástroj podle konkrétního běhu.

Lokální model není automaticky bezpečný a cloudový model není automaticky nebezpečný. Rozhoduje celý tok: kde běží inference, kam míří telemetrie, co zůstává v cache, kdo vidí logy a zda lze akci auditovat.

Časté poruchy

Routing podle dojmu: „těžké“ úlohy nemají definici. Oprava: taxonomie úloh, eval sada a verzované pravidlo.
Frontier model na všechno: vysoká kvalita se předpokládá i tam, kde nic nepřidává. Oprava: levný baseline a měření ceny za úspěch.
Nejlevnější model na všechno: úspora zmizí v retry a lidských opravách. Oprava: počítat celý běh, ne první API call.
Tichý fallback: incident se tváří jako úspěch. Oprava: logovat důvod, cestu a finální stav; upozornit na degradaci.
Ztracený stav při handoffu: druhý model opakuje práci nebo věří neověřenému tvrzení. Oprava: strukturovaný balíček předání.
Model hodnotí sám sebe: stejné slepé místo projde dvakrát. Oprava: deterministický check, nezávislý hodnotitel nebo člověk podle rizika.
Abstrakce vlastní workflow: produkt závisí na vizuálním Agent Builderu, jeho paměti a proprietárních tool definicích. Když služba skončí, skončí i cesta ven. Oprava: stav, prompty, schémata, evaly a pravidla držet ve vlastním verzovaném formátu.
Přepnutí providera bez evalů: kompatibilní JSON neznamená kompatibilní chování. Oprava: replay reprezentativních úloh před změnou.

Konkrétní příklad: třídění zákaznických požadavků

Firma přijímá e-maily v několika jazycích. Systém má určit kategorii, najít relevantní část dokumentace a připravit návrh odpovědi. Změna smlouvy nebo vrácení peněz vyžaduje člověka.

Kód odstraní podpisy, detekuje přílohy a označí osobní údaje.
Lokální malý model klasifikuje jazyk, téma a riziko do pevného JSON schématu.
Policy gate nepustí citlivé přílohy do externího API. Pro běžný dotaz povolí schváleného cloudového providera.
Levnější model dostane nalezené články a vytvoří návrh s citacemi.
Verifier zkontroluje, že citované dokumenty existují, odpověď neobsahuje zakázaný slib a všechny věty o produktu mají oporu ve zdroji.
Při porušení schématu proběhne jedna cílená oprava. Při věcné neshodě dostane silnější model původní cíl, zdroje a výsledek kontroly. Při vysokém riziku jde případ rovnou člověku.
Systém uloží zvolenou cestu, důvod, celkové náklady a to, zda návrh člověk přijal, upravil nebo odmítl.

Po několika eval cyklech může tým zjistit, že levnější model bezpečně zvládá rutinní dotazy, ale u nejasných reklamací často vyvolá opravu. Router proto neeskaluje podle délky e-mailu, ale podle kombinace tématu, rizika a výsledku retrieval. To je orchestrace založená na důkazu, ne na hierarchii značek.

Zdroje

Building effective agents (Anthropic) - praktické rozlišení jednoduchých workflow a agentních systémů; silný argument pro nejjednodušší funkční návrh.
RouteLLM (LMSYS) - výzkum routerů, které volí mezi silnější a levnější cestou podle typu dotazu.
FrugalGPT (Stanford University) - raná práce o kaskádách modelů, rozpočtu a optimalizaci kvality vůči nákladům.
NIST AI Risk Management Framework - rámec pro mapování, měření a řízení rizik AI systémů včetně provozní odpovědnosti.
OWASP Top 10 for LLM Applications - přehled útoků a provozních rizik, která musí respektovat router, nástroje i fallbacky.
OpenAI Evals - otevřený rámec a příklady, jak popsat eval úlohy a porovnávat chování modelů.

Co si pamatovat

Orchestrace není sbírka modelů. Je to kontrolní vrstva pro rozhodnutí, předání, ověření a zastavení. Začni jedním modelem a měřitelnou baseline. Routing stav na datech, ne na prestiži značky. Počítej cenu za úspěch včetně retry a lidské práce. Bezpečnostní pravidla vynucuj před modelem a přenášej je i do fallbacků. Stav, evaly a tool kontrakty drž ve vlastním formátu. Dobrá orchestrace je nudná, auditovatelná a vyměnitelná.