Optimalizáld az Opus 5 kéréseidet. Tudd meg, hogyan kezeld a fallbacket és a routingot. 

              Három eltérő problémát kell szétválasztani

Röviden: az Opus 5 szerveroldali fallbackje kizárólag a biztonsági osztályozó miatti elutasításra szolgál. Nem kezeli a túlterhelést, a rate limitet vagy a szerverhibát, ezekhez külön infrastrukturális hibatűrés kell. A költség- és képességalapú routing pedig egy harmadik probléma.

A routing előre eldönti, hogy egy kérést melyik modell vagy végpont kezeljen. A fallback ezzel szemben egy elsődleges útvonal hibája, elutasítása vagy más előre rögzített feltétel után választ alternatívát.

1. Infrastrukturális fallback

Kiváltó ok lehet:

• szolgáltatáskiesés;
• timeout;
• rate limit;
• átmeneti szerverhiba;
• egy előre rögzített válaszidő-küszöb túllépése.

Ezt teljes egészében a saját kódban kell kezelni. A gyártói fallbacks paraméter ilyenkor nem lép működésbe: a rate limitet, a túlterhelést és a szerverhibát változatlanul visszaadja a hívónak.

Az alternatív útvonalnak nemcsak technikailag elérhetőnek kell lennie. Ugyanúgy meg kell felelnie az adatrezidencia-, biztonsági, minőségi és szerződéses követelményeknek.

Időtúllépés után nem biztos, hogy az eredeti művelet sikertelen volt. Ha a modell eszközhasználaton keresztül adatbázist módosított, megrendelést adott fel vagy más külső hívást indított, az automatikus újrapróbálkozás kettős végrehajtást okozhat. Ilyen folyamatban idempotenciakulcs, egyedi kérésazonosító és állapotellenőrzés szükséges.

2. Képesség- és költségalapú routing

Nem szükséges minden feladatot Opus 5-höz irányítani. Egyszerű, jól mérhető feldolgozást olcsóbb modell is teljesít, míg hosszú futású, több fájlt vagy több eszközt érintő feladatnál indokolt lehet az Opus 5 tesztelése. Ez utóbbi összhangban áll a gyártó által megjelölt képességprofillal, de a tényleges előnyt saját evalnak kell igazolnia.

Ebből azonban nem következik univerzális Haiku-Sonnet-Opus feladattérkép. A routing szabályait saját evalok alapján kell kialakítani és produkciós adatokkal rendszeresen felülvizsgálni. Kísérletek bizonyították, hogy ugyanarra a promptra a Haiku modell több reasoning kört igényelhet, amivel magasabb lesz a végleges válasz költsége, mint a drágább Opus, ha az utóbbi kevesebb belső párbeszédet folytat.

A jó routing döntési jelei:

• a feladat típusa és nehézsége;
• az elvárt válaszidő;
• a hibaköltség;
• az adatérzékenység;
• az előzetes eval eredménye;
• az adott workflow költségkerete.

Opus 5-nél a modellváltás mellett az effort-szint is routing-döntés. A low és a medium a magasabb szintek töredék tokenszámán is jó minőséget adhat, viszont az effort módosítása érvényteleníti a prompt-cache üzenetblokkjait, ezért a kérésenkénti állítgatás rontja a cache-hit arányt.

3. Safety fallback

Az Anthropic nyilvános dokumentációja szerint az Opus 5 biztonsági classifier miatt stop_reason: "refusal" értékkel utasíthat el egy kérést. Ez HTTP 200-as, sikeres válasz, üres content tömbbel: a kimenet előtti elutasítás nem kerül számlázásra, a rate limitbe viszont beleszámít. A béta fallbacks paraméter ilyenkor szerveroldalon újrapróbálhatja a kérést: vagy előre megadott, engedélyezett modelllistával, vagy az Opus 5-nél bevezetett default módban, az Anthropic által a refusal-kategóriához ajánlott modellel. Ehhez a server-side-fallback-2026-07-01 béta fejléc kell; a korábbi server-side-fallback-2026-06-01 csak explicit modelllistát fogad el.

Négy dolgot érdemes előre tudni róla:

• rate limit, túlterhelés vagy szerverhiba nem aktiválja;
• a paraméter a Claude API-n érhető el bétában; Amazon Bedrockon, Google Cloudon és Microsoft Foundryn nem, és a Message Batches API is elutasítja. Ezeken a platformokon az SDK-k refusal-fallback middleware-e a megoldás, amely minden Anthropic SDK-ban benne van, és kliensoldalon végzi ugyanezt az újrapróbálkozást;
• a fallbacks nem öröklődik át az eszközfuttatásból indított modellhívásokra, tehát az alügynököknek külön kell beállítani;
• a célmodellt a válasz felső szintű model mezője és a usage.iterations fallback_message bejegyzése azonosítja.

A stop_details.category mondja meg, melyik szabályterület lépett: cyber, bio, frontier_llm, reasoning_extraction vagy general_harms. A dokumentáció külön kiemeli, hogy a jóhiszemű biztonsági munka is beleeshet a cyber kategóriába – ez konkrét kockázat annál a magyar fejlesztőcégnél, amely sérülékenységvizsgálattal vagy biztonsági tooling fejlesztésével foglalkozik. Az elágazást a stop_reason értékére kell építeni, mert a stop_details lehet null.

Mivel a refusal HTTP 200, a hibaarányra vagy 5xx-ekre épülő monitorozás soha nem látja meg. Külön eseményt érdemes kibocsátani minden elutasításra és minden fallbackkel kiszolgált válaszra, majd a kettő különbségére riasztani.

Ez nem adatvédelmi kontroll, és nem helyettesíti a vállalati szabályrendszert. Egy safety fallback megváltoztathatja:

• a válasz minőségét;
• a modell biztonsági viselkedését;
• az eszközhívások eredményét;
• a tokenköltséget;
• a workflow reprodukálhatóságát.

Ha a rendszer személyes vagy bizalmas adatot észlel, a helyes reakció nem automatikusan egy másik modell használata. Szükség lehet blokkolásra, maszkolásra, pszeudonimizálásra, emberi jóváhagyásra vagy megfelelő szerződéses feltételekkel működő útvonalra.

Mit kell naplózni?

Éles környezetben célszerű rögzíteni:

• a kérés vagy tranzakció azonosítóját;
• a kért és a ténylegesen használt modellt;
• a routing- vagy fallbackesemény okát, refusal esetén a stop_details.category értékét;
• a workflow és a modell verzióját, valamint az effort-szintet;
• a válasz- és hibastátuszt;
• a tokenhasználatot és a becsült költséget;
• az emberi felülvizsgálat eredményét.

A teljes prompt és válasz válogatás nélküli naplózása nem automatikusan jó gyakorlat: a napló személyes adatot, forráskódot vagy üzleti titkot is tartalmazhat. A cél, a jogalap, a hozzáférés, a megőrzési idő és a törlés rendje ezért a naplózásra is vonatkozik.

A gyakorlati következtetés

Opus 5-nél a gyártói safety fallback csak a classifier-refusal kezelését egyszerűsíti. A rendszer egészének kockázatát csak akkor csökkenti, ha a célmodellek előre teszteltek, megfelelnek a szerződéses és adatkezelési követelményeknek, az ismételt műveletek biztonságosak, és a tényleges modellváltás naplózott.

Források

Anthropic: What’s new in Claude Opus 5.

Anthropic: Refusals and fallback.

NIST: Artificial Intelligence Risk Management Framework 1.0.

Ellenőrizve: 2026. július 26.