Uzticama LLM API maršrutēšana: noildze, atkārtoti mēģinājumi un modeļa atkāpšanās bez semantiskās regresijas

Fakts: neveiksmīgi pieprasījumi ar ierobežotu ātrumu joprojām var tikt ieskaitīti pakalpojumu sniedzēja ierobežojumiem. Tāpēc agresīvi tūlītēji mēģinājumi var padziļināt bremzēšanu, nevis to atrisināt. Atkārtoti mēģinājumi arī patērē papildu ietilpību pārtraukuma laikā, un atkārtota mēģinājuma politikas vairākos lietojumprogrammu slāņos var palielināt iegūto slodzi.

Ieteikums: ļaujiet vienam slānim atkārtot modeļa ģenerēšanas mēģinājumus. Tipiskā arhitektūrā AI API vārteja ir īstais īpašnieks, jo tā redz maršruta stāvokli, mēģinājumu vēsturi, latentumu un izmaksas. Ja iespējams, atspējojiet automātiskos atkārtojumus zemāka līmeņa klientiem vai iekļaujiet tos tajā pašā mēģinājuma budžetā.

Iztērējiet vienu latentuma budžetu no gala līdz galam

Katra mēģinājuma taimautu skaits ir nepietiekams. Trīs mēģinājumi ar piecu sekunžu taimautu var pārvērst paredzēto piecu sekunžu darbību par piecpadsmit sekunžu atbildi, pirms tiek iekļauta atkāpšanās un validācija.

Ierakstiet absolūto termiņu, kad pieprasījums tiek ievadīts vārtejā. Pirms katra mēģinājuma aprēķiniet atlikušo laiku:

atlicis = termiņš — pašreizējais_laiks
nepieciešams = savienojuma_atlaide + paaudzes_atlaide + validācijas_atlaide
ja paliek < nepieciešams:
    stop_without_launching_another_attempt

Astoņu sekunžu termiņā saprātīgs sākotnējais piešķīrums var rezervēt 300 ms vārtejas darbam un galīgajai validācijai, atvēlēt līdz 4,5 sekundēm primārajam maršrutam un saglabāt aptuveni 3,2 sekundes vienam atkāpšanās laikam. Šīs vērtības ir piemērs, nevis etalons. Tie ir jāatvasina no izmērītā latentuma sadalījuma faktiskajiem nodrošinātājiem, modeļiem, reģioniem un izvades izmēriem.

Izmantojiet ierobežotu eksponenciālo atkāpšanos ar nervozitāti īslaicīgiem atkārtojumiem:

aizkave = nejaušs(0, min(cap, base * 2^retry_index))

Pakalpojumu sniedzēja ieteikumiem par atkārtotu mēģinājumu, piemēram, vērtībai “atkārtoti pēc mēģinājuma”, ir jābūt prioritāriem, ja tie iekļaujas atlikušajā termiņā. Pēc neliela mēģinājumu skaita apstājieties. Kopējā politika ir viens primārais mēģinājums plus viens atkāpšanās mēģinājums ar neobligātu tā paša maršruta atkārtotu mēģinājumu tikai agrīnas savienojuma kļūmes gadījumā, kas nevarēja radīt apmaksājamu izvadi.

Kompozīcija: secīga atkāpšanās uzlabo pieejamību, bet palielina aizture latentumu. Paralēli vai apdrošināti pieprasījumi var samazināt latentumu palēninājuma laikā, taču tie patērē vairāk jaudas un var iekasēt maksu par vairākām veiksmīgām paaudzēm. Riska ierobežošana ir jāierobežo ar latentuma kritiskām darba slodzēm bez blakusparādībām ar atcelšanu un izmaksu kontroli.

Atlasiet atkāpšanās variantus pēc iespējām, nevis pēc ranga

Atkāpšanās tabulai ir jākodē saderība, nevis globālā preferenču secība. Pirms veselības stāvokļa, latentuma vai cenas apsvēršanas filtrējiet kandidātu maršrutus atbilstoši līgumam.

kandidāti = maršruti
  .filter(atbalsta_nepieciešamās_modalitātes)
  .filter(context_limit >= aptuvenais_ievades_izmērs)
  .filter(atbalsta_nepieciešamie_rīki)
  .filter(atbalsta_pieprasīto_shēmas_režīmu)
  .filter(model_class in enabled_model_classes)
  .filter(aptuvenā_maksa <= atlikušās_izmaksas_budžets)
  .filter(nav_īslaicīgi_apspiests)
atlasīts = rangs(kandidāti, veselība, latentums, izmaksas)

Strukturētās izvades atbalsts ir pelnījis precīzu pārbaudi. Pat tad, ja divi maršruti reklamē shēmas ierobežotu ģenerēšanu, tie var atbalstīt dažādas JSON shēmas apakškopas vai atšķirīgi interpretēt malas gadījumus. Modeļi, kas darbojas ar rīkiem, var atšķirties arī pēc rīku izvēles, argumentu uzbūves un paralēlās izsaukuma darbības.

Fakts: modeļu saimes maiņa var saglabāt transporta pieejamību, vienlaikus mainot stilu, argumentācijas kvalitāti, drošības uzvedību, marķieri un rīku izvēli. HTTP panākumi nav semantiskās ekvivalences pierādījums.

Paredzēšana: modeļu katalogiem paplašinoties, ražošanas maršrutēšanas politikās statisku modeļu sarakstu vietā arvien vairāk tiks izmantoti versiju iespēju profili un darba slodzei raksturīgi pieņemšanas testi. Uztveriet to kā dizaina virzienu, nevis garantiju par pakalpojumu sniedzēja rīcību.

Apstipriniet atbildi pirms tās pieņemšanas

Palaidiet katru atbildi, tostarp primāro atbildi, izmantojot to pašu pieņemšanas cauruļvadu. Validācijai jānotiek, pirms rezultāts tiek saglabāts kešatmiņā, iekšēji tiek izrakstīts kā veiksmīgs vai nodots rīka izpildītājam.

1. Apstipriniet, ka transportēšana ir pabeigta, un atbildes aploksni var parsēt.
2. Pārbaudiet pabeigšanas iemeslu un noraidiet saīsināšanu, kad ir nepieciešama pilnīga izvade.
3. Apstipriniet strukturēto izvadi, salīdzinot ar sākotnējo shēmu.
4. Pārbaudiet obligātos laukus, uzskaites vērtības un lietojumprogrammu invariantus.
5. Atļaut tikai reģistrētus rīku nosaukumus un pārbaudīt argumentus pret katru rīku shēmu.
6. Izmantojiet darba slodzei specifiskas semantiskās pārbaudes, ja viltus pieņemšana izmaksātu dārgi.

Rēķinu izgūšanai semantiskajām pārbaudēm var būt nepieciešama nenegatīva kopsumma, atbalstīts valūtas kods un rindas vienību kopsummas skaidri noteiktas pielaides robežās. Klasifikācijai pieprasiet etiķeti no atļautā komplekta. Kodu ģenerēšanai var būt piemērota parsēšana vai kompilācija. Šīs pārbaudes neliecina par kvalitāti, taču tās novērš paredzamus līguma pārkāpumus uzskatīt par veiksmīgiem.

Nelabojiet klusībā katru nepareizi veidotu atbildi. Var būt pieņemama deterministiska normalizācija, piemēram, nekaitīgu apkārtējo atstarpju noņemšana. Trūkstošu finanšu lauku uzminēšana vai rīka argumentu pārrakstīšana maina modeļa nozīmi, un tas izraisa noraidīšanu vai cilvēka pārskatīšanu.

Atsevišķi ģenerēšanas mēģinājumi no blakusparādībām

LLM pieprasījumos parasti tiek izmantots HTTP POST, kas pēc savas būtības nav idempotens. Vēl svarīgāk ir tas, ka modeļa atbilde var ierosināt ārēju darbību, piemēram, iekasēt maksu par maksājuma veidu, nosūtīt ziņojumu, izveidot biļeti vai mainīt infrastruktūru. Atkārtota ģenerēšanas mēģinājums un šīs darbības atkārtošana ir atsevišķi lēmumi.

Katram modeļa izsaukumam piešķiriet darbības ID pie lietojumprogrammas robežas un mēģinājuma ID. Saglabājiet rīka izpildes stāvokli pret deterministisku atslēgu, piemēram:

execution_key = operation_id + tool_name + canonical_arguments_hash

Pirms rīka izpildes pārbaudiet, vai šī atslēga ir gaidoša, pabeigta vai neizdevusies. Atgrieziet saglabāto rezultātu pabeigtai izpildei, nevis palaidiet to vēlreiz. Operācijām, kuru argumenti var likumīgi mainīties, ir nepieciešams lietojumprogrammas līmeņa apstiprinājums vai jauns darbības ID.

Neskaidras noildzes gadījumā ir nepieciešama īpaša apstrāde. Ja savienojums neizdodas pēc pieprasījuma pārsūtīšanas, vārteja var nezināt, vai ir notikusi ģenerēšana. Pakalpojumu sniedzēja atbalstīta idempotences atslēga var palīdzēt, ja tāda ir pieejama. Pretējā gadījumā reģistrējiet rezultātu kā nezināmu un izmantojiet darba slodzei atbilstošu atkārtošanas politiku, nevis pieņemot, ka nekas nav noticis.

Izslēdziet neveselīgus maršrutus un atklājiet katru mēģinājumu

Automātiskais slēdzis vai īslaicīga stāvokļa apspiešana neļauj katram jaunam pieprasījumam no jauna atklāt to pašu neveiksmīgo maršrutu. Atveriet ķēdi pēc noteikta kļūdu līmeņa vai secīgas atteices sliekšņa, pēc tam ielaidiet ierobežotas zondes pusatvērtā stāvoklī. Pielāgojiet sliekšņus pēc maršruta un atteices klases, lai nepareizi veidots klienta pieprasījums nevarētu padarīt veselīgu modeli nepieejamu.

Katrā mēģinājumā ierakstiet vienu pieprasījuma līmeņa notikumu un vienu notikumu. Noderīgi lauki ietver darbības ID, mēģinājuma ID, atlasīto nodrošinātāju un modeli, kļūmes klasi, statusa kodu, latentumu, pilnvaru skaitu, aptuvenās izmaksas, atkāpšanās iemeslu, validācijas rezultātu, ķēdes stāvokli un gala rezultātu. Rediģējiet vai sajauciet uzvednes, izvades un rīku argumentus atbilstoši to jutīguma un saglabāšanas prasībām.

Noderīga darbības metrika ietver atkāpšanās biežumu, mēģinājumus uz vienu izpildītu pieprasījumu, termiņa izsmelšanas līmeni, validācijas noraidīšanas līmeni, neskaidrus rezultātus, maksu par pieņemto atbildi un latentumu pēc galīgā maršruta. Pieaugošais HTTP veiksmes rādītājs un augošs validācijas noraidīšanas līmenis ir brīdinājums, ka transporta pieejamība maskē līguma kļūmes.

Ražošanas izlaišanas kontrolsaraksts

• Definējiet versijas maršrutēšanas līgumu katrai darba slodzes klasei.
• Kartē nodrošinātāja kļūdas pastāvīgās, pārejošās, nesaderīgās, nederīgās un neskaidrās kategorijās.
• Izvēlieties vienu atkārtotā mēģinājuma īpašnieku un ierobežojiet kopējo mēģinājumu skaitu.
• Izplatiet absolūtu termiņu, izmantojot vārteju, nodrošinātāja klientu, validāciju un rīka izpildi.
• Izveidojiet pēc iespējas pārbaudītas rezerves grupas, nevis vienu globālu modeļu ķēdi.
• Apstipriniet shēmas, rīku izsaukumus, pabeigšanas iemeslus un domēna invariantus.
• Atceliet blakusefektu dublikātus, izmantojot darbības un izpildes atslēgas.
• Pievienojiet maršruta nomākšanu ar ierobežotām pusatvērtām zondēm.
• Reģistrējiet mēģinājumu līmeņa latentumu, pilnvaras, izmaksas, kļūmes un pieņemšanas rezultātus.
• Ievadiet noildzes, 429 s, atlasītas 5xx kļūdas, nepareizi veidots JSON, konteksta pārpilde un lēni iestudēšanas panākumi.

Sāciet ar primāro maršrutu un vienu saderīgu rezerves daļu vienai zema riska darba slodzei. Pirms politikas paplašināšanas salīdziniet pieņemtās atbildes kvalitāti, latentumu un izmaksas. Mērķis nav augstākais iespējamais atkāpšanās līmenis. Tā ir ierobežota sistēma, kas vai nu atgriež atbildi, kas atbilst sākotnējam līgumam, vai nepārprotami neizdodas, pirms tā rada dubultu darbu vai semantiskus bojājumus.

Saistīta informācija

• agrāka API testēšanas piezīme
• iepriekšējais raksts angļu valodā