Versioonitud hinnakataloogid AI API lüüside jaoks: peatage hinnakõikumine pakkumiste ja tagasimaksete tõttu

AI API arveldamine nurjub, kui lüüs käsitleb pakkuja hindu staatilise otsingutabelina. Raske osa ei ole žetoonide korrutamine määraga. Raske osa on teada, milline hind kehtis päringu ajal, milline SKU vastas tegelikule kasutusalale, kas hind kinnitati ja miks kliendi pakkumine erineb teenusepakkuja arvest.

Lüüs, mis toetab mitut mudelit, kontot, piirkonda, vahemälurežiime, paketttöid, hostitud tööriistu ja etteantud juurutusi, vajab hinnakujunduse juhtimistasandit. See juhttasand peaks sisestama pakkuja hinnakaardid, muutma iga heakskiidetud tariifi, kaardistama pakkuja kasutuse arveldatavateks SKU-deks, testima hinnapakkumisi enne levitamist ja võrdlema arveldatud pearaamatu ridu arvetega.

Lugeja probleem: hinna triiv puruneb rohkem kui hinnakujunduse lehekülgi

Pakkuja hinnad võivad varieeruda dimensioonide lõikes, mida rakendustiimid harva näevad: mudeli versioon, sisendmärgid, vahemällu salvestatud sisendmärgid, väljundmärgid, arutlusmärgid, vahemällu kirjutus, hostitud tööriistad, partii allahindlused, juurutamise tüüp, piirkond, valuuta ja mahukavad. Kui need dimensioonid jaotatakse üheks väljaks „hind loa kohta”, teeb lüüs lõpuks valesti tsiteerimise, ülereserveerib eelarved, esitab üürnike alamaks või suunab kulutused valesse kulukohta.

Tõrketeade ilmneb tavaliselt ühes viiest kohast:

• Eellennu hinnapakkumised: taotlus võetakse vastu, kuna lüüs hindab vana või mittetäieliku määra.
• Eelarvebroneeringud: üürniku saldo reserveeritakse ühe kataloogi abil, kuid arveldatakse teise kataloogi abil.
• Kasutusraamatud: vahemällu salvestatud märgid, arutlusmärgid, tööriistakutsed või partiiühikud salvestatakse üldiste kogusummadena ja neid ei saa õigesti ümber hinnata.
• Tagasimaksete eksport: rahandus saab üürniku kogusummad ilma teenusepakkuja arve dimensioonideta, mis on vajalikud erinevuse selgitamiseks.
• Partner API-d: järgnevad tooted näitavad hindu, teadmata, kas need hinnad on kehtivad, hinnangulised, aegunud või blokeeritud.

Faktid, mida hinnakujunduses säilitada

Fakt: pakkuja avalikus dokumentatsioonis eraldatakse hinnakujundus tavaliselt mudeli ja märgikategooria järgi. Sisend-, vahemällu salvestatud sisend- ja väljundmärkidel võivad olla erinevad kiirused. Mõned kasutusaruanded näitavad vahemällu salvestatud sisendite või arutlusmärkide arvu, mis tähendab, et lüüs peaks säilitama kasutuse alamkategooriad, selle asemel, et salvestada ainult žetoone.

Fakt: hinnakujundus ei ole alati puhtad jaotusmärgid. Mõned pakkujad müüvad määratud võimsust, ette nähtud läbilaskevõimet või märgiühikuid, mis on seotud konkreetse mudeli võimsusega. Nendes režiimides võivad kulu põhineda ajal, võimsusühikutel või mudelipõhistel sisend- ja väljundsuhetel, mitte lihtsal päringupõhisel märgiarvel.

Fakt: hostitud tööriistad ja otsingufunktsioonid võivad luua täiendavaid arveldatavaid sündmusi väljaspool tavapärast mudelit. Otsingu maandus, failiotsing, URL-i kontekst, koodi täitmine, vahemällu kirjutamine ja agendi vahetoimingud võivad vajada eraldi SKU vastendamist.

Soovitus: käsitlege neid fakte skeeminõuetena, mitte eranditena. Kui kasutussündmus sisaldab arveldatavat dimensiooni, mida kataloog ei saa kaardistada, peaks lüüs panema tehingu arveldamise ootele, selle asemel et määrata selle vaikselt nulli.

Koostage versioonipõhine hinnakataloog

Hinnakataloog peaks olema esmaklassiline tabel või teenus, mitte pakkuja adapteritesse manustatud konstandid. Kataloog on olemas selleks, et vastata ühele küsimusele: millist kinnitatud tariifi tuleks selle kasutussündmuse puhul praegu selle rentniku ja teenusepakkuja konto kontekstis kasutada?

Kataloogi põhiväljad

Praktiline kataloogirida peaks sisaldama vähemalt järgmisi välju:

• catalog_version_id: muutumatu versioon, mida kasutatakse hinnapakkumiseks, reserveerimiseks, arveldamiseks ja vastavusse viimiseks.
• pakkuja: ülesvoolu pakkuja või sisemine pakkuja adapter.
• provider_account_scope: globaalne, organisatsioon, projekt, tööruum, BYOK rentnik, edasimüüja konto või ettevõtteleping.
• model_id_or_alias: teenusepakkuja poolt nähtav mudeli ID või sisemudeli pseudonüüm, mille hind määratakse.
• pricing_sku: kanooniline SKU, mida värav arvelduseks kasutab.
• provider_meter_id: valikuline ülesvoolu arvemõõtur, kui see on saadaval.
• arveldusühik: sisendtunnus, vahemällu salvestatud sisendtunnus, väljundmärk, arutlusluba, vahemällu kirjutamine, otsingupäring, kujutise tunnus, helisekund, kogumisühik, PTU tund või muu selgesõnaline ühik.
• region_scope: globaalne, piirkond, elukoha tsoon, turg või andmeresidentsuse klass.
• deployment_type: serverita, pakett-, ette nähtud, spetsiaalne, peenhäälestatud või sisemine liivakast.
• teenuse_tasand: standardne, prioriteetne, pakett-, kiire, ette nähtud või muu lüüsi tasand.
• valuuta: kursi valuuta enne juurdehindlust, makse, krediite või konverteerimist.
• määr: täpne komamäär, mitte kunagi binaarne ujukoma.
• minimaalne_ühik: väikseim arveldatav ühik.
• ümardamise_reegel: päringu, arve rea, rentniku perioodi või teenusepakkuja määratud.
• source_url: dokumentatsioon, hinnakaart, lepinguviide või sisemise kinnituse pilet.
• observed_at: kui hind tuvastati või imporditi.
• effective_from ja effective_to: kehtivusaken.
• approval_state: mustand, üle vaadatud, heaks kiidetud, aegunud, blokeeritud või asendatud.

Oluline rakendamise üksikasi on see, et kataloogiversioon on liikluses kasutusel muutumatu. Parandused peaksid looma uue versiooni või korrigeerimiskirje, mitte muteerima ajaloolist versiooni, millele olemasolevad pearaamatu read viitavad.

Eraldage mudeli aliased hinnakujunduse SKU-dest

Sisemised aliased, nagu chat-default, support-fast või reasoning-premium, on kasutusmugavused. Need ei tohiks asendada pearaamatus pakkujale nähtavat mudeli ID-d ega hinnakujunduse SKU-d.

Kasutussündmus peaks salvestama kõik kolm identiteeti:

• requested_model_alias: mida rakendus küsis.
• upstream_model_id: mida lüüs tegelikult nimetas.
• pricing_sku: mida arveldusmootor kasutas arveldamiseks.

See takistab pseudonüümi pakkumiste ajalugu ümber kirjutamast. Kui chat-default osutab augustis ühele mudelile ja septembris uuemale mudelile, peaks augusti kasutus jääma seotuks augusti ülesvoolu mudeli ja augusti kataloogiversiooniga.

tsitaat muutumatu kataloogiversiooni vastu

Tsitaadid on kasulikud ainult siis, kui neid saab hiljem selgitada. Lüüs peaks enne saatmist valima kataloogiversiooni, kasutama seda eelkontrolli hinnapakkumiseks, säilitama selle eelarvereservatsioonis ja viima selle läbi lõpliku arvelduse.

Taotluse minimaalne elutsükkel näeb välja selline:

1. Normaliseerige taotlus eeldatavateks arveldatavateks dimensioonideks: mudel, teenusetasand, piirkond, loa prognoos, vahemälu sobivus, tööriistad, pakettrežiim ja juurutuse tüüp.
2. Valige rentniku ja pakkuja konto ulatuse jaoks aktiivne kinnitatud kataloogiversioon.
3. Lahendage eeldatavad SKU-d iga võimaliku arveldatava dimensiooni jaoks.
4. Arvutage lennueelne prognoos ja reserveerige rentniku eelarve.
5. Saada ülesvoolu päring ainult siis, kui kõik nõutavad SKU vastendused on olemas.
6. Püüdke teenusepakkuja vastusest lõpliku kasutuse metaandmed, sealhulgas alamkategooriad.
7. Tegeliku kasutuse määramiseks kasutage sama kataloogiversiooni, välja arvatud juhul, kui on vaja selgesõnalist parandustöövoogu.
8. Salvestage kõik reserveeritud ja arveldatud summade erinevused.

Soovitus: hinnapakkumine ja reserveerimine konservatiivsete eeldustega, seejärel arveldage vastusejärgse kasutamisega. Täpne saatmiseelne hinnakujundus on keeruline voogesituse, korduskatsete, hostitud tööriistade, kauakestvate agentide ja vahemälu tabamuste käitumise puhul. Eesmärk ei ole täiuslik ennustus. Eesmärk on kontrollitud kokkupuude ja seletatav lahendus.

Enne suleti tundmatute arveldatavate mõõtmete korral

Kõige ohtlikum hinnaviga on puuduv SKU, mis muutub tasuta kasutamiseks. Lüüsi ei tohi sulgeda, kui pakkuja vastus sisaldab kasutussalvet, millel pole kinnitatud vastendust.

Näited, mis peaksid käivitama arvelduse kinnipidamise:

• Mudelite vastus sisaldab cached_input_tokens, kuid kataloogis on ainult üldised sisend- ja väljundlubade määrad.
• Arutlusmudel tagastab reasoning_tokens, kuid põhjenduse SKU-d pole konfigureeritud.
• Majutatud otsingutööriist arveldab päringu kohta, kuid lüüs salvestab ainult mudelimärgid.
• Pakitöö saab allahindlust, kuid kataloog seostab selle standardse serverita SKU-ga.
• Ettevalmistatud juurutus maksab võimsustasusid tunnitasusid, kuid rentniku pearaamat eeldab arveldust märgi kohta.
• Piirkondlik juurutus kasutab asukohamuutjat, mida aktiivses kataloogis pole.

Arvelduse ootel ei tohiks sündmust kaotada. See peaks säilitama pakkuja töötlemata kasutuse, normaliseeritud kasutuse, päringu identifikaatorid, rentniku identifikaatorid, pakkuja konto ulatuse, proovitud kataloogiversiooni, puuduvad SKU väljad ja arvelduse blokeerimise põhjuse. Kui kataloog on värskendatud ja kinnitatud, saab ootejärjekorda deterministlikult uuesti esitada.

Kasutage enne kinnitamist hinnakaardi erinevuste kontrolli

Pakkuja hinnakujunduslehed ja API-d ei ole alati masinstabiilsed ning lepingud võivad alistada avalikud hinnad. Sellegipoolest on automaatsed erinevuste kontrollid hoiatustena kasulikud. Nad peaksid tuvastama muudatused enne, kui need mõjutavad klientidele nähtavaid hinnapakkumisi.

Hinnakujunduse imporditoru peaks võrdlema hiljuti vaadeldud hinnakaarte viimase kinnitatud kataloogi ja lipuga:

• uued mudelid või vananenud mudelid;
• muutud sisendit, vahemällu salvestatud sisendit, väljundit või arutluskiirust;
• uued märgikategooriad või tööriistamõõturid;
• vahemällu kirjutamise või vahemälu tabamuse kordajaid muudetud;
• uued piirkondlikud, elukoha- või turumuutused;
• muudetud partiide allahindluse reegleid;
• muudetud ette nähtud või eraldatud võimsuse reegleid;
• valuutamuutused;
• ümardamine või miinimumühiku muutmine;
• konfliktid avalike hinnakaartide ja kontopõhiste lepinguhindade vahel.

Soovitus: käsitlege kriimustusi ja importe mustanditena. Nõua inimeste heakskiitu kõigi muudatuste jaoks, mis mõjutavad arveldatavat liiklust, partneritele nähtavat hinnakujundust või rahalist eksporti. Sisemised katsetused võivad kasutada liivakastikataloogi, kuid sellel peaks olema selge kululimiit ja seda ei tohiks kunagi segi ajada kinnitatud kliendiarveldusega.

Lisage hinnapakkumise testid hinnakujunduse CI-ks

Hinnamuudatused vajavad testimist samal põhjusel, miks koodimuudatused teevad: väike muudatus võib mõjutada paljusid päringu kujundeid. Hinnapakkumiste testid peaksid käima alati, kui kataloogiridad, SKU vastendused, pakkuja adapterid või märgistusreeglid muutuvad.

Kasutage sünteetilisi päringu kujundeid, mis katavad hinnakujunduspinna:

• standardne tekstipäring sisend- ja väljundmärkidega;
• taotlus vahemällu salvestatud sisendtunnustega;
• põhjendusrikas taotlus koos eraldi põhjenduste kasutamisega;
• tööriistakasutustaotlus koos otsingu-, faili- või koodikäitustasudega;
• multimodaalne taotlus pildi-, heli-, video- või loodud meediaüksustega;
• pakktöö soodushindade ja hilinenud arveldusega;
• varustatud juurutus koos tunnivõimsuse ja ülekandumise käitumisega;
• piirkondlik või elukohapõhine taotlus;
• üürnik teenusepakkujapõhiste lepinguhindadega;
• partnerrentnik, kellel on juurdehindlus- või allahindluspoliitika.

Iga test peaks andma rohkem kui lõplik kogusumma. See peaks sisaldama valitud kataloogiversiooni, SKU-de loendit, arveldusühikuid, hindu, ümardamiskäitumist, valuutat, hinnangulist kogusummat, broneeringu summat ja eeldatavaid arveldusread.

Tsitaadi näidistesti