Usaldusväärne LLM API marsruutimine: ajalõpud, korduskatsed ja mudeli tagasilöögid ilma semantiliste regressioonideta

Fakt: ebaõnnestunud piiranguga päringuid võidakse siiski teenusepakkuja piirangute hulka arvata. Agressiivsed kohesed korduskatsed võivad seetõttu süvendada pidurdamist selle lahendamise asemel. Korduskatsed tarbivad ka katkestuse ajal lisavõimsust ja mitme rakenduse kihi korduskatsete reeglid võivad sellest tulenevat koormust mitmekordistada.

Soovitus: lubage mudeli genereerimise korduskatsed ühel kihil. Tüüpilises arhitektuuris on AI API lüüs õige omanik, kuna see näeb marsruudi olekut, katsete ajalugu, latentsust ja kulusid. Võimaluse korral keelake automaatsed korduskatsed madalama taseme klientides või arvestage need selgelt samasse katseeelarvesse.

Kulutage üks täielik latentsusaja eelarve

Katse kohta on aegumisaeg ebapiisav. Kolm katset viiesekundilise ajalõpuga võivad muuta kavandatud viiesekundilise toimingu viieteistkümnesekundiliseks vastuseks, enne kui kaasatakse taganemine ja valideerimine.

Salvestage absoluutne tähtaeg, millal päring lüüsi siseneb. Enne iga katset arvutage järelejäänud aeg:

jäänud = tähtaeg – praegune_aeg
nõutav = ühendamise_luba + genereerimise_luba + valideerimise_luba
kui järele jääb < nõutav:
    stop_without_launching_ather_attempt

Kaheksasekundilise tähtaja puhul võib mõistlik esialgne jaotus reserveerida 300 ms lüüsi tööks ja lõplikuks kinnitamiseks, lubada kuni 4,5 sekundit peamise marsruudi jaoks ja säilitada umbes 3,2 sekundit ühe varu jaoks. Need väärtused on näide, mitte etalon. Need tuleb tuletada tegelike pakkujate, mudelite, piirkondade ja väljundi suuruste mõõdetud latentsusjaotusest.

Kasutage mööduvate korduskatsete jaoks piiratud eksponentsiaalset taganemist koos värinaga:

viivitus = juhuslik (0, min(cap, base * 2^retry_index))

Pakkuja uuesti proovimise vihjed (nt väärtus uuesti proovimine pärast) peaksid olema ülimuslikud, kui need mahuvad järelejäänud tähtaja sisse. Peatage pärast väikest arvu katseid. Levinud reeglid on üks esmane katse pluss üks tagavarakatse koos valikulise sama marsruudi uuesti proovimisega ainult varajase ühenduse tõrke korral, mis poleks saanud arveldatavat väljundit luua.

Muu: järjestikune varu parandab saadavust, kuid suurendab saba latentsust. Paralleelsed või maandatud päringud võivad aeglustumise ajal latentsusaega vähendada, kuid tarbivad rohkem võimsust ja võivad mitme eduka põlvkonna eest tasuda. Maandamine peaks piirduma latentsuskriitiliste, kõrvalmõjudeta töökoormustega koos tühistamise ja kulude kontrolliga.

Valige tagavarad võimete, mitte asetuse järgi

Varutabel peaks kodeerima ühilduvuse, mitte globaalse eelistuse järjekorra. Filtreerige kandidaatide marsruudid lepingu alusel, enne kui kaalute tervist, latentsust või hinda.

kandidaadid = marsruudid
  .filter(toetab_nõutud_modalities)
  .filter(konteksti_piir >= hinnanguline_sisendi_suurus)
  .filter(toetab_vajalikke_tööriistu)
  .filter(toetab_nõutud_skeemi_režiimi)
  .filter(mudeli_klass lubatud_mudeli_klassides)
  .filter(hinnanguline_kulu <= järelejäänud_kulu_eelarve)
  .filter(mitte_ajutiselt_suppressed)
valitud = auaste(kandidaadid, tervis, latentsusaeg, maksumus)

Struktureeritud väljundi tugi väärib selget testimist. Isegi kui kaks marsruuti reklaamivad skeemipiiranguga genereerimist, võivad need toetada erinevaid JSON-skeemi alamhulka või tõlgendada servajuhtumeid erinevalt. Tööriistaga varustatud mudelid võivad samuti erineda tööriista valiku, argumentide ülesehituse ja paralleelkõne käitumise poolest.

Fakt: mudeliperekondade vahetamine võib säilitada transpordi kättesaadavuse, muutes samal ajal stiili, põhjenduste kvaliteeti, ohutuskäitumist, märgistamist ja tööriistade valikut. HTTP edu ei tõenda semantilist samaväärsust.

Prognoos: mudelikataloogide laienedes kasutavad tootmise marsruutimise poliitikad staatiliste mudeliloendite asemel üha enam versioonistatud võimeprofiile ja töökoormusepõhiseid vastuvõtuteste. Käsitle seda disainisuunana, mitte teenusepakkuja käitumise garantiina.

Kinnitage vastus enne selle vastuvõtmist

Käitage iga vastus, sealhulgas esmane vastus, sama vastuvõtukonveieri kaudu. Valideerimine peaks toimuma enne, kui tulemus vahemällu salvestatakse, sisemiselt edukana esitatakse või tööriista täideviijale edastatakse.

1. Kinnitage transpordi lõpuleviimist ja vastuse ümbrikut saab sõeluda.
2. Kontrollige lõpetamise põhjust ja keelduge kärpimisest, kui on vaja täielikku väljundit.
3. Kinnitage struktureeritud väljund algse skeemi alusel.
4. Kontrollige kohustuslikke välju, loendiväärtusi ja rakenduse invariante.
5. Lubage ainult registreeritud tööriistanimed ja kinnitage argumendid iga tööriistaskeemi vastu.
6. Rakendage töökoormusepõhiseid semantilisi kontrolle, kui vale aktsepteerimine oleks kulukas.

Arvete väljavõtmiseks võivad semantilised kontrollid nõuda mittenegatiivset kogusummat, toetatud valuutakoodi ja reaüksuste kogusummasid selgelt määratletud tolerantsi piires. Klassifitseerimiseks nõuda lubatud komplekti kuuluvat etiketti. Koodi genereerimiseks võib sobida sõelumine või kompileerimine. Need kontrollid ei tõenda kvaliteeti, kuid takistavad prognoositavate lepingurikkumiste käsitlemist õnnestumistena.

Ärge parandage vaikselt iga valesti vormindatud vastust. Deterministlik normaliseerimine, nt kahjutu ümbritseva tühiku eemaldamine, võib olla vastuvõetav. Puuduvate finantsväljade arvamine või tööriista argumentide ümberkirjutamine muudab mudeli tähendust ja peaks käivitama tagasilükkamise või inimese ülevaatuse.

Eri genereerimise korduskatsed kõrvalmõjudest

LLM-i päringud kasutavad tavaliselt HTTP POST-i, mis ei ole oma olemuselt idempotentne. Veelgi olulisem on see, et mudeli vastus võib algatada välise toimingu, nagu makseviisi eest tasu võtmine, sõnumi saatmine, pileti loomine või infrastruktuuri muutmine. Loo uuesti proovimine ja selle toimingu taasesitamine on eraldi otsused.

Määrake igale mudelikutsele toimingu ID rakenduse piiril ja katse ID. Tööriista täitmisoleku säilitamine deterministliku võtme suhtes, näiteks:

execution_key = toimingu_id + tööriista_nimi + kanoonilised_argumendid_räsi

Enne tööriista käivitamist kontrollige, kas see võti on ootel, lõpetatud või nurjunud. Tagastada salvestatud tulemus lõpetatud täitmise jaoks, mitte seda uuesti käivitada. Toimingute jaoks, mille argumendid võivad õiguspäraselt muutuda, on vaja rakenduse tasemel kinnitust või uut toimingu ID-d.

Ebaselge ajalõpp nõuab erikäsitlust. Kui ühendus ebaõnnestub pärast päringu edastamist, ei pruugi lüüs teada, kas genereerimine toimus. Pakkuja toetatud idempotentsusvõti võib aidata, kui see on saadaval. Vastasel juhul logige tulemus tundmatuna ja rakendage töökoormusele vastavat korduspoliitikat, selle asemel et eeldada, et midagi ei juhtunud.

Tühjendage ebatervislikud marsruudid ja paljastage kõik katsed

Kaitsmekaitse või ajutine tervisehäire takistab igal uuel päringul sama ebaõnnestunud marsruuti uuesti avastamast. Avage ahel pärast määratletud veamäära või järjestikuse tõrke läve, seejärel lubage piiratud sondid pooleldi avatud olekus. Häälestage lävesid marsruudi ja tõrkeklassi järgi, et valesti vormindatud kliendipäring ei muudaks tervet mudelit kättesaamatuks.

Salvestage üks päringutaseme sündmus ja üks sündmus katse kohta. Kasulikud väljad hõlmavad toimingu ID-d, katse ID-d, valitud pakkujat ja mudelit, tõrkeklassi, olekukoodi, latentsust, lubade arvu, hinnangulist maksumust, varupõhjust, valideerimistulemust, vooluringi olekut ja lõpptulemust. Redigeerige või räsige viipasid, väljundeid ja tööriista argumente vastavalt nende tundlikkusele ja säilitusnõuetele.

Kasulikud töömõõdikud hõlmavad varumäära, katsete arvu lõpetatud päringu kohta, tähtaja ammendumise määra, valideerimise tagasilükkamise määra, ebaselgeid tulemusi, kulu aktsepteeritud vastuse kohta ja latentsust lõpliku marsruudi järgi. Suurenev HTTP edukuse määr koos suureneva valideerimise tagasilükkamise määraga on hoiatus, et transpordi saadavus varjab lepingu tõrkeid.

Tootmise levitamise kontroll-loend

• Määratlege iga töökoormuse klassi jaoks versioonistatud marsruutimisleping.
• Kaardista teenusepakkuja vead püsivateks, mööduvateks, ühildumatuteks, kehtetu vastusega ja mitmetähenduslikeks kategooriateks.
• Valige üks uuesti proovimise omanik ja piirake katsete arvu.
• Levitage absoluutne tähtaeg lüüsi, pakkuja kliendi, valideerimise ja tööriista täitmise kaudu.
• Ühe globaalse mudeliahela asemel looge võimalusega testitud varurühmad.
• Kinnitage skeeme, tööriistakutseid, lõpetamise põhjuseid ja domeeniinvariante.
• Kõrvalefektide dubleerimine toimingu- ja täitmisklahvide abil.
• Lisage marsruudi mahasurumine piiratud poolavatud sondidega.
• Logi katsetaseme latentsusaeg, märgid, kulu, tõrked ja aktsepteerimise tulemused.
• Sisestage ajalõpud, 429 sekundit, valitud 5xx vead, valesti vormindatud JSON, konteksti ületäitumine ja lavastamise aeglane õnnestumine.

Alustage ühe väikese riskiga töökoormuse jaoks esmase marsruudi ja ühe ühilduva varuvariandiga. Enne poliitika laiendamist võrrelge aktsepteeritud vastuse kvaliteeti, latentsust ja kulusid. Eesmärk ei ole kõrgeim võimalik varumäär. See on piiratud süsteem, mis kas tagastab vastuse, mis vastab algsele lepingule või ebaõnnestub selgelt enne, kui see põhjustab dubleerivat tööd või semantilist kahju.

Seotud lugemine

• varasem API testimise märkus
• eelmine ingliskeelne artikkel