Viac otázok v jednej požiadavke na Jev: vzor fan-out v praxi

V dokumentácii TypeSafe je vzor nazvaný špekulatívny fan-out. Namiesto reťaze volaní, v ktorej druhá otázka čaká na výsledok prvej, dostane Jev všetky otázky v jednej požiadavke, a to aj tie, ktorých odpoveď sa napokon nemusí použiť. O tom, čo je pre daný prípad dôležité, rozhodne až váš kód. S74 Pre e-shop, ktorý denne triedi stovky správ, to znamená menej čakania na sieť a jednoduchší kód. Vzor má však hranice, o ktorých stránka mlčí.

Ako vyzerá príklad z dokumentácie

Ukážka triedi tikety zákazníckej podpory. Jedna požiadavka obsahuje text tiketu a päť otázok: Choice category (v kóde sa objavujú hodnoty bug_report, billing a feature_request), Score bug_severity, Noul has_reproducible_steps, Noul refund_requested a Score frustration. Závažnosť chyby a opísaný postup na jej zopakovanie majú zmysel len pri hlásení chyby, otázka na vrátenie peňazí len pri fakturácii a frustráciu kód sleduje pri každom tikete. S74

Kód potom rozvetví ďalší postup. Hlásenie chyby so skóre závažnosti nad 1,5 a s pravdepodobnosťou opísaného postupu nad 0,6 pôjde vývojárom, ostatné hlásenia skončia v zozname chýb. Fakturačný tiket s pravdepodobnosťou žiadosti o vrátenie peňazí nad 0,7 dostane príznak, návrh novej funkcie sa iba zapíše a frustrácia nad 1,5 znamená prednostnú odpoveď bez ohľadu na kategóriu. S74

Dokumentácia vzor stavia proti postupu, pri ktorom sa najprv zistí kategória a závažnosť sa doplní ďalším volaním. Keď sa špekulatívna odpoveď zíde, druhé volanie odpadne; keď sa nezíde, kód ju jednoducho nepoužije. S74

Čo vzor sľubuje a čo neuvádza

Podľa dokumentácie sa otázky vyhodnocujú paralelne, takže pridanie ďalších zvyčajne odozvu výrazne nepredĺži. S74 Ide o tvrdenie výrobcu, stránka k nemu neuvádza žiadne namerané hodnoty. S74 Opis API dopĺňa, že všetky otázky v požiadavke sa vzťahujú na jeden spoločný state a typy otázok sa v jednej požiadavke môžu miešať. Najvyšší počet otázok v jednej požiadavke opis API neuvádza. S75

Pri cene treba byť opatrný. TypeSafe účtuje vstupné tokeny, pri Jeve 1.14 aj 1.13 za 0,042 USD za milión, a výstupné tokeny sú zatiaľ zadarmo. S01 Spotrebu vracia odpoveď v jednom objekte usage za celú požiadavku, nie po otázkach. S75 Ani stránka o vzore, ani opis API však nevysvetľujú, o koľko vstupných tokenov požiadavku predĺži každá ďalšia otázka. S74 S75 Z logiky vzoru vyplýva, že spoločný text posielate raz namiesto niekoľkých samostatných volaní, no skutočnú úsporu si overte podľa hodnoty input_tokens na vlastných dátach. Odhad nákladov vám pomôže spraviť kalkulačka.

Platia aj limity veľkosti. Predvolene je to 64k tokenov na požiadavku a 32k na jednu otázku; s hlavičkou TypeSafe-Danger-Zone-Long-Context: true sa obe hranice zvýšia na 262k. S01 Ďalšie podrobnosti opisuje sprievodca cena a limity.

Prahy z príkladu nie sú odporúčanie

Hodnoty 1,5, 0,6 a 0,7 sú v ukážke len na ilustráciu. Pri otázke Score je výsledok váženým priemerom čísel úrovní, ktoré sa číslujú od nuly, takže pri troch úrovniach vychádza skóre od 0 do 2. S04 Stránka o fan-oute neuvádza, koľko úrovní majú bug_severity a frustration. S74 Význam prahu 1,5 preto z príkladu nevyčítate: pri troch úrovniach leží blízko vrchu škály, pri piatich (0 až 4) pod jej stredom. To je náš prepočet, nie údaj výrobcu.

Pri otázkach Noul dokumentácia navrhuje začať s prahom 0,7 pre áno a 0,3 pre nie a hodnoty potom upraviť podľa vlastných výsledkov. S06 Ako prahy nastavovať a overovať, rozoberá sprievodca confidence a kalibrácia.

V ukážke chýba aj vetva pre tiket, ktorý nespadá do žiadnej z troch kategórií v kóde. S74 V ostrej prevádzke odporúčame takú vetvu doplniť a posielať tieto prípady človeku.

Pasca: jeden spoločný stav pre všetky otázky

Fan-out zvádza vložiť do jedného state všetko, čo potrebuje ktorákoľvek otázka. Stránka o slabinách Jevu 1.13, naposledy revidovaná 2. 10. 2026, pritom upozorňuje, že presnosť klesá, keď stav narastá o obsah nesúvisiaci s rozhodnutím. Odporúča vopred v kóde vybrať len polia, ktoré otázka potrebuje. S07 Stránka sa týka verzie 1.13; samostatný prehľad slabín pre 1.14 sme v dokumentácii nenašli.

Náš návrh: do jednej požiadavky dávajte otázky, ktoré pracujú s tým istým vstupom, napríklad s textom jednej správy. Keď otázka potrebuje iné údaje, napríklad históriu objednávok, pošlite ju samostatne a s vlastným, kratším stavom.

Čo to znamená pre slovenský e-shop

Vezmime správu „Balík neprišiel, chcem peniaze späť.“ Podľa vzoru môže jedna požiadavka obsahovať otázku Choice na zámer správy, otázku Noul na žiadosť o vrátenie peňazí a otázku Score na mieru nespokojnosti. Kód z odpovedí zostaví postup: zámer určí frontu, pravdepodobnosť vrátenia rozhodne o príznaku pre účtovníka a vysoká nespokojnosť posunie správu dopredu. Rozdelenie práce medzi model a kód zodpovedá ukážke z dokumentácie. S74 Podrobnejšie sme smerovanie správ podľa zámeru opísali v článku triedenie správ od zákazníkov.

Dve veci si však overte sami. Dokumentácia vzoru nehovorí nič o slovenčine, preto prahy nastavte až na vzorke vlastných správ; postup opisuje sprievodca testovanie slovenčiny. A keďže kód skladá výsledok z viacerých samostatných odpovedí, pripravte sa aj na prípad, keď si navzájom odporujú. Ako sa môžu rozchádzať odpovede na príbuzné otázky, sme rozoberali v článku o súlade medzi Choice a Noul.