Multi-model stratégia má zmysel až po porovnávacom teste

Triedenie ticketov a príprava zmluvného textu majú odlišný dopad pri chybe. Pred výberom modelov určte, ktoré výsledky môžu ísť ďalej automaticky a ktoré musí schváliť človek.

Rozdelenie práce medzi modely pridáva aj routing a ďalšie miesto na chybu. Úsporu treba preukázať na celom procese.

Cena, rýchlosť a úspešnosť sa medzi kandidátmi líšia. Jeden model môže postačovať. Viac modelov má zmysel vtedy, keď porovnanie ukáže prínos aj po započítaní routingu a kontroly.

Rozdeľte úlohy podľa rizika, nie podľa mena modelu

Začnite zoznamom opakovaných úloh. Pri každej si zapíšte vstup, očakávaný výstup, škodu pri chybe a človeka, ktorý výsledok schváli. Triedenie ticketov, v ktorom má každý prípad jasnú cestu na manuálnu kontrolu, má iný rizikový profil ako zmluva, ktorá môže ovplyvniť záväzok firmy voči druhej strane.

Na menej rizikové úlohy skúste kandidáta s nízkou odozvou a nákladom. Kde ide o peniaze, o právny záväzok alebo o to, že by sa dáta dostali von, otestujte viac kandidátov na tých istých anonymizovaných vstupoch, nie na tých, ktoré sa práve hodia. Výsledok nech schváli človek. Pri kóde merajte, či prejdú relevantné testy a ako dlho trvá oprava toho, čo našlo review. Nie počet vygenerovaných riadkov.

Ako si vybrať model

Postup začína testovacími prípadmi a končí rozhodnutím podľa výsledkov.

Krok 1: Vytvorte reprezentatívny testovací súbor

Vyberte reálne prípady vrátane neúplných vstupov a hraničných stavov. Patria tam aj prípady, ktoré musia ísť na človeka. Kritériá kvality a minimálny počet správnych výsledkov určite pred testom, nie po ňom, inak si hranicu posuniete presne tam, kam ju dotlačí prvý dobre vyzerajúci výsledok.

Krok 2: Otestujte fallback a limity

Workflow musí mať cestu na odmietnutie alebo odovzdanie prípadu človeku. Nespoliehajte sa len na to, že model sám rozpozná vlastnú chybu. Merajte podiel eskalácií, chybné odpovede, p50 aj p95 odozvu a počet opakovaní, ktoré si každý kandidát vypýta, kým dá použiteľný výsledok. Celkový náklad počítajte až z toho. Ešte pred pilotom nastavte limit výdavkov, počet pokusov a stav, do ktorého sa má systém prepnúť vo chvíli, keď poskytovateľ prestane odpovedať, prípadne začne vracať chyby.

Krok 3: Štruktúrované výstupy a validácia

Multi-model pipeline funguje len vtedy, keď modely komunikujú v predvídateľnom formáte. To znamená:

• JSON schémy pre vstupy aj výstupy (nie voľný text)
• Validácia výstupov pred poslaním ďalšiemu modelu
• Logika opakovania s exponenciálnym backoffom (retry)
• Logging každého kroku pre debugging

Rozhrania poskytovateľov podporujú štruktúrované výstupy podľa svojej aktuálnej dokumentácie. JSON schému aj výsledok validujte vo vlastnej aplikácii pred ďalším krokom.

Overujte možnosti podľa aktuálnej dokumentácie

Pred výberom skontrolujte podporované funkcie a limity. Rovnako dôležité je, ako poskytovateľ nakladá s dátami. Podmienky konkrétneho účtu čítajte zvlášť. Dokumentácia sa mení pod rukami. Do návrhu preto zapíšte dátum, kedy ste ju čítali, a odkaz na OpenAI API, Anthropic API, Gemini API a GitHub Copilot.

Názov modelu sám o sebe nie je rozhodnutie. Vyberte kandidáta, ktorý na Vašom testovacom súbore splní dohodnutú kvalitu aj odozvu a zmestí sa do nákladového limitu, ktorý ste si dali ešte pred prvým testom. Prístupové požiadavky sú vstupenka, nie bonus.

Náklad porovnávajte na celom workflow

Náklad nie je iba cena jedného volania. Započítajte vstupy, výstupy, opakovania, cache, nástroje, ľudskú kontrolu a chyby, ktoré niekto musí opraviť skôr, než sa výsledok dostane k zákazníkovi.

Pri každom kandidátovi potom sledujte jedno číslo, a to celkový náklad na správne dokončenú úlohu.

Pilot ukončite až po dostatočnom počte reprezentatívnych prípadov. Rozhodnutie zapíšte aj s limitom rozpočtu, maximálnou odozvou a s tým, čo sa stane pri výpadku poskytovateľa.

Modelový návrh multi-model pipeline

Jednoduchý návrh používa úspornejší model na triedenie požiadaviek. Jednoduché dotazy dostanú odpoveď od rýchleho modelu, komplexné sa presmerujú na výkonnejší a celá úspora stojí a padá na tom, ako presne to triedenie rozlišuje jedno od druhého. Na reprezentatívnom testovacom súbore si porovnajte úsporu aj latenciu a k tomu to, či kvalita niekde nespadla. Bez neho je konkrétne percento len tvrdenie, nie dôkaz.

Confidence threshold začnite nastavovať konzervatívne. Upravujte ho podľa chýb a eskalácií, ktoré vidíte v meranom pilote, a nie podľa čísla, ktoré vyzeralo rozumne v deň, keď ste pipeline prvý raz spúšťali. Pipeline má na každom kroku používať štruktúrované výstupy s validáciou.

Limity oprávnení a schvaľovanie rozoberá aj governance checklist pre AI agenta. Číselný confidence threshold overte na označených prípadoch, nie iba na sebahodnotení modelu.

Záver

Začnite jedným modelom. Routing pridajte až vtedy, keď Vám test ukáže, že lacnejší model zvláda jasne ohraničenú časť úloh a že fallback naozaj zachytí prípady, pri ktorých si nie je istý.

Prineste reprezentatívne vstupy a limity pre kvalitu, cenu aj odozvu. Na konzultácii z toho vieme navrhnúť test routingu.