Decisions API je obecně dostupné: rychlé třídění, strukturované vstupy a limity

Do zákaznické podpory přicházejí zprávy a aplikace potřebuje vybrat oddělení, zjistit chybějící údaj nebo určit pořadí zpracování. Dlouhá odpověď asistenta je pro takový krok často nepraktická. Decisions API od OpenAI, obecně dostupné od 22. října 2026, vrací předem určené typy odpovědí nad textem, obrázky a strukturovanými daty. Je určené pro vymezené posouzení, nikoli pro libovolné psaní nebo automatické převzetí odpovědnosti za další akci.

Vysvětlujeme změny proti veřejné betě a vlastní postup pro ověření třídění požadavků. Neprováděli jsme benchmark rychlosti ani přesnosti služby. Praktické příklady jsou modelové a jejich účelem je ukázat, jak odlišit použitelnou automatizaci od působivého, ale neověřeného skóre.

Co přináší obecná dostupnost

Dokumentace uvádí jediný aktuálně podporovaný model GPT‑6 Luna a rozhraní /v1/decisions. Proti betě přidává mimo jiné strukturovaný vstup JSON, další práci s obrázky, cache společného vstupu a zvýšení maxima z 200 na 400 otázek v požadavku. Popisuje také přehled využití organizace a návaznost na GPT‑Live.

Tyto možnosti se hodí pro aplikaci, která potřebuje krátký strojově zpracovatelný výsledek. Neznamenají, že jeden požadavek zvládne bez přípravy čtyři stovky libovolně navazujících obchodních rozhodnutí. Dokumentace rozlišuje nezávislé otázky nad společným vstupem od těch, které závisejí na předchozí odpovědi.

Obecná dostupnost je stav služby, ne potvrzení správnosti vašeho nastavení. Před nasazením je stále potřeba vytvořit kategorie, určit pravidla a vyhodnotit skutečné vstupy. Bez toho aplikace jen rychleji vrací rozhodnutí, jejichž význam tým neověřil.

Tři typy odpovědi mají různé použití

První typ hodnotí podmínku a vrací odhad pravděpodobnosti její platnosti. Může jít například o otázku, zda zpráva obsahuje požadovaný identifikátor. Druhý vybírá jednu z určených možností. Třetí hodnotí vstup podle seřazených úrovní a vrací skóre odvozené z jejich pravděpodobností.

Kategorie bez pořadí a stupnice nejsou totéž. Oddělení „servis“, „prodej“ a „ostatní“ nemají přirozený číselný průměr. Stupnice závažnosti naopak potřebuje srozumitelně rozlišené úrovně. Špatná volba typu může vytvořit číslo, které vypadá přesně, ale nemá použitelný význam.

Pokud chcete vypsat údaje ze zprávy do vlastního objektu nebo napsat vysvětlení, dokumentace odkazuje na jiné postupy, například strukturovaný výstup v Responses API. Decisions nepovažujte za univerzální náhradu všech způsobů práce s modelem.

Kategorie musí mít rozdílný význam

Vlastní model zákaznické podpory může mít kategorie servis, objednávka, fakturace a ostatní. Problém nastane u věty „Objednané zboží přišlo poškozené a chci opravit fakturu“. Bez pravidel může být několik voleb obhajitelných. Chyba potom nemusí být v modelu, ale v neúplném zadání.

Určete, zda se vybírá hlavní záměr, první potřebný krok nebo oddělení odpovědné za převzetí. Pokud má zpráva více samostatných požadavků, může být vhodné tuto skutečnost nejprve rozpoznat a předat ji člověku nebo rozdělit jiným postupem. Jedna kategorie nemá skrývat druhou důležitou část.

Ke každé kategorii připravte pozitivní příklad i hraniční případ. Příklady mají vysvětlovat pravidlo, nikoli nahrazovat jeho popis. Pokud si dva lidé stejné zadání vykládají odlišně, nejprve sjednoťte jejich rozhodnutí. Model nemůže napravit neexistující shodu týmu.

Začněte archivem skutečně posouzených vstupů

Pro ověření vyberte zprávy, u kterých odpovědný člověk určil správný výsledek podle současných pravidel. Zahrňte běžné krátké dotazy i nejasné formulace, chybějící údaje a smíšené požadavky. Sada složená pouze z jednoduchých ukázek bude výsledek nadhodnocovat.

Část dat použijte pro přípravu zadání a jinou pro kontrolu. Pokud po každé chybě přepíšete instrukce podle stejné kontrolní sady, postupně ji využíváte k ladění. Pro konečné posouzení pak potřebujete další dosud nepoužité příklady.

Při práci s reálnými zprávami ověřte povolené použití údajů. Pro zkoušku často stačí omezená nebo anonymizovaná kopie, pokud zachovává význam nutný pro posouzení. Do modelu nemusí automaticky vstupovat celý zákaznický účet jen proto, že je dostupný v interním systému.

Vysoká důvěra není důkaz správnosti

Vrácená pravděpodobnost a pole confidence jsou informace modelu. Nejsou nezávislým potvrzením, že závěr odpovídá realitě. Prahovou hodnotu pro automatické předání proto stanovujte podle vlastních označených příkladů a dopadu chyb.

Vlastní model: aplikace z tisíce zpráv označí sto jako servisní. Člověk potvrdí devadesát z těchto sta. To znamená, že deset označených zpráv patřilo jinam. Z tohoto údaje však ještě nevíte, kolik skutečných servisních zpráv zůstalo mezi zbývajícími devíti sty.

Pokud jich tam bylo dalších dvacet, celkem bylo servisních 110 a systém správně zachytil 90. Správnost mezi vybranými zprávami je 90 procent, ale zachycení všech servisních zpráv přibližně 81,8 procenta. Jde o ilustrační výpočet, nikoli výsledek Decisions API. Ukazuje, proč jedno souhrnné procento nestačí.

Chyby mají různé následky

Zpráva předaná nesprávnému oddělení může zpozdit odpověď. Přehlédnutý neúplný údaj může vyvolat další zbytečnou komunikaci. Tým má předem určit, které omyly jsou přijatelné a které vyžadují lidské posouzení. Univerzální práh bez znalosti úlohy tuto otázku neřeší.

Praktické nastavení může rozlišovat:

• Jasné případy, které aplikace automaticky zařadí.
• Nejasné nebo smíšené požadavky pro ruční převzetí.
• Odmítnuté nebo chybové odpovědi bez předstíraného výsledku.
• Případy s chybějícími podklady, které vyžadují doplnění.
• Kontrolní vzorek automaticky zařazených zpráv pro průběžné vyhodnocení.

Poslední bod pomáhá zachytit změnu jazyka zákazníků nebo nabídky firmy. Nastavení, které dobře fungovalo pro starý produkt, nemusí stejně rozlišovat dotazy k novému. Průběžná kontrola má odpovídat důsledkům chyb, nikoli pouze velikosti provozu.

Čtyři sta otázek není čtyři sta navazujících kroků

Více nezávislých otázek může využít stejný podklad: například určit kategorii zprávy, zjistit přítomnost čísla objednávky a označit žádost o zpětné zavolání. Každá má vlastní význam a pojmenování odpovědi. Aplikace potom potřebuje výsledky správně přiřadit.

Pokud další otázka závisí na předchozím výsledku, dokumentace doporučuje oddělené požadavky. Nejprve například zjistíte typ případu a teprve potom vyberete příslušnou podrobnější sadu otázek. Pokus vložit celý závislý postup do jednoho seznamu může zastřít logiku rozhodování.

Velký seznam má být také přehledný pro správce. Otázky pojmenujte podle účelu a evidujte jejich verze. Při změně jedné kategorie pak poznáte, které výsledky vznikly podle starých pravidel. Bez této vazby se dlouhodobé srovnání přesnosti stává obtížným.

JSON usnadní předání, neověří zdroj

Možnost vložit strukturovaná data přímo omezuje potřebu převádět je do volně napsaného odstavce. Význam položek ale stále musí být jasný. Pole označené „stav“ nemusí bez dalšího popisu říkat, zda jde o objednávku, platbu nebo doručení.

U kombinace zprávy a záznamu objednávky určete, který zdroj je závazný pro kterou informaci. Zákazník může psát o starší objednávce, zatímco připojený záznam patří jiné. Správně zpracovaný JSON neprokazuje správné spárování podkladů.

Stejný princip platí pro obrázky. Model posuzuje dostupný obraz, nikoli neviditelné části produktu nebo skutečnost mimo snímek. Pokud je podklad neostrý nebo neúplný, potřebuje postup možnost nepředat zdánlivě jistý závěr dál bez kontroly.

Další akci provádí aplikace

Decisions vrací posouzení. Odeslání zprávy, změnu záznamu nebo přidělení požadavku provádí navazující aplikace podle vlastních pravidel. Výsledek klasifikace není sám o sobě oprávněním k libovolné akci. Přístupy i schvalování musí odpovídat dopadu.

Na začátku může služba pouze navrhovat zařazení vedle běžného pracovního postupu. Tým porovná návrhy s lidským rozhodnutím a teprve potom povolí omezenou automatizaci. Tím získá skutečná data o vlastních případech místo odhadu podle obecné demonstrace.

Při chybě nebo nejistém výsledku musí být známá náhradní cesta. Zpráva nemá zmizet jen proto, že nevznikla očekávaná odpověď. Přehled přístupů vysvětluje návod k oprávněním agentů; širší automatizaci rozebírá průvodce Make a n8n.

Náklady sledujte na přijatý výsledek

Do rozhodnutí zahrňte počet požadavků, zpracovaný vstup, potřebné opakování a lidské kontroly. Krátká typovaná odpověď může být vhodná pro automatizaci, ale sama neprokazuje nejnižší cenu celého postupu. Před výpočtem ověřte aktuální sazby konkrétní služby.

Opakovaný společný vstup může využít cache podle dokumentovaných pravidel. Úsporu ale nelze předpokládat jen z existence stejné relace nebo podobných zpráv. Rozdíl mezi zápisem a čtením vysvětluje rozbor dvanáctihodinové cache.

Sledujte také případy, které systém předá člověku. Pokud automatizace ušetří část třídění, ale vytvoří stejně velkou frontu oprav, celkový přínos se zmenší. Správné hodnocení propojuje kvalitu, čas a účet, nikoli pouze rychlost jedné odpovědi.

Předání do provozu má obsahovat i výjimky

Vedle úspěšných příkladů sepište situace, které automatizace nesmí uzavřít sama. Může jít o chybějící vazbu na objednávku, zprávu s několika záměry nebo neshodu mezi připojenými podklady. Výjimka nemá být ukrytá jen ve vzorovém zadání; potřebuje také skutečnou cestu k pracovníkovi, který ji převezme.

Určete, jak se zaznamená oprava lidského rozhodnutí. Pokud pracovník zařazení změní, tato informace může posloužit při příštím hodnocení. Nemá se však automaticky a bez kontroly proměnit v nové obecné pravidlo. Jedna oprava může vycházet ze zvláštního kontextu, který u jiných zpráv neplatí.

Při změně nabídky nebo oddělení firmy zkontrolujte také seznam možností. Zastaralá kategorie může dál dostávat vysoké skóre, přestože už neexistuje tým, který by ji obsloužil. Technicky platná odpověď pak nevede k dokončení práce. Provozní přínos proto posuzujte až podle doručení požadavku správnému člověku a jeho skutečného převzetí.

Časté otázky

Mohu použít jiný model než GPT‑6 Luna?

Aktuálně ověřená dokumentace uvádí pouze GPT‑6 Luna. Podporu ostatních modelů nelze odvozovat z toho, že jsou dostupné v jiném API. Před nasazením ověřte konkrétní rozhraní a parametry.

Má skóre vždy znamenat vybranou kategorii?

Ne. U seřazených úrovní může být skóre průměrem váženým pravděpodobnostmi a ležet mezi úrovněmi. Pro výběr jedné nespořádané možnosti použijte odpovídající typ otázky a jasně definované kategorie.

Je obecná dostupnost důvodem vypnout lidskou kontrolu?

Ne. Říká něco o nabídce služby, nikoli o přesnosti vaší úlohy. Rozsah automatizace určujte podle vlastního ověření, dopadu omylů a funkční cesty pro nejasné nebo chybové případy.

Co si uchovat pro pozdější změnu pravidel?

Verzi otázek, popis kategorií, kontrolní příklady a výsledky vyhodnocení. Nové nastavení pak můžete porovnat se starým na stejné sadě a poznat, zda změna zlepšila požadovaný výsledek, nebo jen přesunula chyby do jiné skupiny.