Megbízható LLM API-útválasztás: időtúllépések, újrapróbálkozások és modell-visszalépések szemantikus regressziók nélkül

Tény: a sikertelen, korlátozott sebességű kérelmek továbbra is beleszámítanak a szolgáltatói korlátokba. Az agresszív azonnali újrapróbálkozások ezért elmélyíthetik a szabályozást ahelyett, hogy megoldanák. Az újrapróbálkozások további kapacitást is igénybe vesznek a kimaradás során, és az újrapróbálkozási házirendek több alkalmazási rétegben megsokszorozhatják a keletkező terhelést.

Javaslat: hagyja, hogy egy réteg saját modellgenerációs újrapróbálkozásokat végezzen. Egy tipikus architektúrában az AI API átjáró a megfelelő tulajdonos, mert látja az útvonal állapotát, a kísérleti előzményeket, a késleltetést és a költségeket. Ha lehetséges, kapcsolja ki az automatikus újrapróbálkozásokat az alacsonyabb szintű klienseken, vagy számolja azokat kifejezetten ugyanabban a kísérleti költségkeretben.

Költsön el egy teljes késleltetési költségkeretet

A kísérletenkénti időtúllépések nem elegendőek. Három kísérlet öt másodperces időtúllépéssel egy tervezett öt másodperces műveletet tizenöt másodperces válaszlá változtathat, mielőtt a visszalépést és az érvényesítést belefoglalná.

Rögzítsen egy abszolút határidőt, amikor a kérés belép az átjáróba. Minden próbálkozás előtt számítsa ki a hátralévő időt:

fennmaradó = határidő – aktuális_idő
kötelező = csatlakozási_engedély + generálási_engedély + érvényesítési_engedély
ha marad < kötelező:
    stop_without_launching_anther_tempt

Nyolc másodperces határidőre az ésszerű kezdeti kiosztás 300 ms-ot tarthat fenn az átjárómunkára és a végső érvényesítésre, legfeljebb 4,5 másodpercet hagyhat az elsődleges útvonalra, és körülbelül 3,2 másodpercet tarthat meg egy tartalékhoz. Ezek az értékek példák, nem referenciaértékek. Ezeket a tényleges szolgáltatók, modellek, régiók és kimeneti méretek mért késleltetési eloszlásaiból kell származtatni.

Használjon korlátozott exponenciális visszalépést remegéssel átmeneti újrapróbálkozásokhoz:

késleltetés = véletlenszerű(0, min(cap, base * 2^retry_index))

A szolgáltatói újrapróbálkozási tippeknek, például az újrapróbálkozás utáni értéknek elsőbbséget kell élvezniük, ha beleférnek a hátralévő határidőbe. Néhány próbálkozás után hagyja abba. A közös házirend egy elsődleges próbálkozás és egy tartalék, opcionális ugyanazon az útvonalon történő újrapróbálkozással, csak egy olyan korai kapcsolati hiba esetén, amely nem generálhatott volna számlázható kimenetet.

Kiváltás: a szekvenciális tartalék javítja a rendelkezésre állást, de növeli a késleltetést. A párhuzamos vagy fedezett kérések csökkenthetik a késleltetést a lassulások során, de több kapacitást fogyasztanak, és több sikeres generáció esetén költségek merülhetnek fel. A fedezést a késleltetéskritikus, mellékhatásoktól mentes munkaterhelésekre kell korlátozni, törlési és költségszabályozással.

Válasszon tartalékokat képességek szerint, ne rang szerint

A tartaléktáblázatnak a kompatibilitást kell kódolnia, nem pedig globális preferenciasorrendet. Szűrje a jelölt útvonalakat a szerződés alapján, mielőtt figyelembe venné az állapotot, a késleltetést vagy az árat.

jelöltek = útvonalak
  .filter(supports_required_modalities)
  .filter(context_limit >= becsült_bemeneti_méret)
  .filter(supports_required_tools)
  .filter(supports_requested_schema_mode)
  .filter(model_class az engedélyezett_modell_osztályokban)
  .filter(becsült_költség <= fennmaradó_költség_költségvetés)
  .filter(not_temporarily_suppressed)
kiválasztott = rang(jelöltek, állapot, késleltetés, költség)

A strukturált kimenet támogatása explicit tesztelést érdemel. Még akkor is, ha két útvonal hirdet sémakorlátozott generálást, támogathatják a különböző JSON-séma részhalmazokat, vagy eltérően értelmezhetik az éles eseteket. Az eszközre alkalmas modellek hasonlóképpen különbözhetnek az eszközválasztásban, az argumentumfelépítésben és a párhuzamos hívás viselkedésében.

Tény: a modellcsaládok váltása megőrizheti a szállítás elérhetőségét, miközben megváltoztatja a stílust, az érvelés minőségét, a biztonsági viselkedést, a tokenizálást és az eszközválasztást. A HTTP sikere nem a szemantikai ekvivalencia bizonyítéka.

Előrejelzés: amint a modellkatalógusok bővülnek, a termelési útvonaltervezési irányelvek egyre gyakrabban használnak majd változatos képességprofilokat és munkaterhelés-specifikus elfogadási teszteket a statikus modelllisták helyett. Tekintse ezt tervezési iránynak, ne garanciaként a szolgáltatói viselkedésre.

Elfogadás előtt ellenőrizze a választ

Futtasson minden választ, beleértve az elsődleges választ is, ugyanazon az elfogadási folyamaton keresztül. Az érvényesítésnek meg kell történnie, mielőtt az eredményt gyorsítótárazzák, belsőleg sikeresnek számlázzák vagy átadják az eszköz végrehajtójának.

1. Győződjön meg arról, hogy az átvitel befejeződött, és a válaszboríték értelmezhető.
2. Ellenőrizze a befejezés okát, és utasítsa el a csonkolást, ha teljes kimenetre van szükség.
3. Érvényesítse a strukturált kimenetet az eredeti sémához képest.
4. Ellenőrizze a kötelező mezőket, a felsorolásértékeket és az alkalmazásinvariánsokat.
5. Csak a regisztrált szerszámneveket engedélyezze, és érvényesítse az argumentumokat az egyes szerszámsémákhoz.
6. Alkalmazzon munkaterhelés-specifikus szemantikai ellenőrzéseket, ahol a hamis elfogadás költséges lenne.

A számla kivonásához a szemantikai ellenőrzésekhez szükség lehet nemnegatív végösszegre, támogatott pénznemkódra és sorösszegekre egy kifejezetten meghatározott tűréshatáron belül. Az osztályozáshoz kérjen címkét az engedélyezett készletből. Kódgeneráláshoz az elemzés vagy a fordítás megfelelő lehet. Ezek az ellenőrzések nem igazolják a minőséget, de megakadályozzák, hogy a kiszámítható szerződésszegéseket sikerként kezeljék.

Ne javítson csendben minden hibás választ. Elfogadható lehet a determinisztikus normalizálás, mint például az ártalmatlan környező szóközök eltávolítása. A hiányzó pénzügyi mezők kitalálása vagy az eszközargumentumok átírása megváltoztatja a modell jelentését, és elutasítást vagy emberi felülvizsgálatot válthat ki.

A generációs újrapróbálkozás elkülönítése a mellékhatásoktól

Az LLM-kérések általában HTTP POST-ot használnak, amely nem eleve idempotens. Ennél is fontosabb, hogy a modellválasz külső műveletet indíthat el, például fizetési mód megterhelését, üzenet küldését, jegy létrehozását vagy infrastruktúra módosítását. A generálás újrapróbálása és a művelet újrajátszása külön döntés.

Minden modellhíváshoz rendeljen hozzá egy műveleti azonosítót az alkalmazás határához és egy kísérleti azonosítót. Az eszköz végrehajtási állapotának megőrzése determinisztikus kulccsal szemben, például:

végrehajtási_kulcs = műveletazonosító + eszköz_neve + canonical_arguments_hash

Egy eszköz végrehajtása előtt ellenőrizze, hogy a kulcs függőben van-e, befejeződött-e vagy meghiúsult. Az újrafuttatás helyett adja vissza a tárolt eredményt a befejezett végrehajtáshoz. Azokhoz a műveletekhez, amelyek argumentumai jogszerűen változhatnak, alkalmazásszintű jóváhagyást vagy új műveletazonosítót igényel.

Egy kétértelmű időtúllépés különleges kezelést igényel. Ha a kapcsolat a kérés elküldése után meghiúsul, előfordulhat, hogy az átjáró nem tudja, hogy történt-e generálás. A szolgáltató által támogatott idempotenciakulcs segíthet, ha rendelkezésre áll. Ellenkező esetben naplózza az eredményt ismeretlenként, és alkalmazzon egy munkaterhelés-specifikus újrajátszási szabályzatot ahelyett, hogy feltételezné, hogy semmi sem történt.

Távolítsa el az egészségtelen útvonalakat, és tegyen közzé minden próbálkozást

A megszakító vagy az ideiglenes állapotletiltás megakadályozza, hogy minden új kérés újra felfedezze ugyanazt a hibás útvonalat. Nyissa meg az áramkört egy meghatározott hibaarány vagy egymást követő meghibásodási küszöb után, majd engedje be a korlátozott szondákat félig nyitott állapotban. Hangolja be a küszöbértékeket útvonal és hibaosztály szerint, hogy egy hibásan formázott ügyfélkérelem ne tegye elérhetővé az egészséges modellt.

Kísérletenként egy kérésszintű eseményt és egy eseményt rögzítsen. A hasznos mezők közé tartozik a műveletazonosító, a kísérletazonosító, a kiválasztott szolgáltató és a modell, a hibaosztály, az állapotkód, a késleltetés, a jogkivonatok száma, a becsült költség, a tartalék ok, az érvényesítés eredménye, az áramkör állapota és a végeredmény. Módosítsa vagy kivonatolja a promptokat, a kimeneteket és az eszköz argumentumokat érzékenységüknek és megőrzési követelményeiknek megfelelően.

A hasznos működési mutatók közé tartozik a visszaesési arány, a teljesített kérésenkénti próbálkozások száma, a határidő kimerülési aránya, az érvényesítés elutasításának aránya, a kétértelmű eredmények, az elfogadott válaszonkénti költség és a végső útvonalonkénti várakozási idő. A növekvő HTTP-sikerességi arány és az érvényesítés elutasítási arányának növekedése arra figyelmeztet, hogy a szállítási elérhetőség elfedi a szerződéses hibákat.

A gyártási bevezetés ellenőrző listája

• Határozzon meg egy verziószámú útválasztási szerződést minden munkaterhelési osztályhoz.
• A szolgáltatói hibákat állandó, átmeneti, inkompatibilis, érvénytelen válaszú és kétértelmű kategóriákba sorolja.
• Válasszon egy újrapróbálkozási tulajdonost, és korlátozza a kísérletek számát.
• Abszolút határidő terjesztése az átjárón, a szolgáltatói kliensen, az érvényesítésen és az eszköz végrehajtásán keresztül.
• Egy globális modelllánc helyett a képességek szerint tesztelt tartalék csoportokat hozzon létre.
• Sémák, eszközhívások, befejezési okok és tartományinvariánsok érvényesítése.
• A mellékhatások duplikálása műveleti és végrehajtási kulcsokkal.
• Útvonal-elnyomás hozzáadása korlátos, félig nyitott szondákkal.
• A kísérleti szintű várakozási idő, a tokenek, a költségek, a hibák és az elfogadási eredmények naplózása.
• Időtúllépések, 429 másodpercek, kiválasztott 5xx hibák, rosszul formázott JSON, kontextus túlcsordulás és lassú ütemezési sikerek beszúrása.

Kezdje egy elsődleges útvonallal és egy kompatibilis tartalékkal egyetlen alacsony kockázatú munkaterheléshez. Hasonlítsa össze az elfogadott válasz minőségét, késleltetését és költségét, mielőtt kiterjeszti a házirendet. A cél nem a lehető legmagasabb visszaesési arány. Ez egy korlátozott rendszer, amely vagy az eredeti szerződésnek megfelelő választ küld vissza, vagy egyértelműen meghiúsul, mielőtt ismétlődő munkát vagy szemantikai kárt okozna.

Kapcsolódó olvasmány

• korábbi API-tesztelési megjegyzés
• korábbi angol nyelvű cikk