OpenAI Batch API: 50 % lētāk, līdz 24 stundām

Saskaņā ar OpenAI Batch API dokumentāciju paketes pieprasījumi maksā par 50 % mazāk nekā sinhronie pieprasījumi, bet apstrādes logs ir līdz 24 stundām. Lai nosūtītu daudzus pieprasījumus, katru no tiem ieraksta atsevišķā JSONL faila rindā, augšupielādē failu un izveido paketi. Pabeigtās atbildes saņem izvades failā.

Šī izvēle der darbam, kura rezultāti var pienākt vēlāk, piemēram, datu kopas klasifikācijai vai iegulumu veidošanai. Interaktīvai funkcijai, kur lietotājs gaida tūlītēju vai pakāpeniski parādītu atbildi, jāizmanto sinhrons pieprasījums: OpenAI Batch API FAQ skaidro, ka straumēšana nav pieejama un noteikto apstrādes logu pašlaik nevar saīsināt.

Kuri pieprasījumi iederas paketē?

Labs kandidāts ir uzdevums, kurā pieprasījumi ir savstarpēji neatkarīgi un nākamo var sagatavot, negaidot iepriekšējā atbildi. OpenAI kā piemērus min modeļu novērtēšanu, lielu datu kopu klasifikāciju un satura krātuvju iegulumu veidošanu. Datu komanda var sagatavot ievadi iepriekš, palaist apstrādi fonā un pēc tam pievienot rezultātus sākotnējiem ierakstiem.

Lēmumu var pieņemt secīgi: vai rezultāts vajadzīgs, pirms lietotājs turpina darbu? Vai atbilde jāstraumē? Vai pieprasījumi ir neatkarīgi? Vai izvēlētais modelis un galapunkts atbalsta paketes? Ja uz pirmajiem jautājumiem atbilde ir „nē”, bet uz pārējiem — „jā”, pakete parasti ir piemērota. Čata atbilde uz tikko saņemtu ziņu šim kritērijam neatbilst; nakts laikā apstrādājama produktu aprakstu kopa atbilst.

Apstrādes logs ir robeža, pēc kuras nepabeigtie pieprasījumi var tikt atcelti, nevis paredzamais gaidīšanas ilgums katrai paketei. Rezultāti var būt gatavi agrāk, taču darbplūsmai jāspēj turpināties arī tad, ja tie pienāk tikai loga beigās. Ja rezultāts zaudē vērtību pēc dažām minūtēm, zemāka pieprasījuma cena šo termiņa prasību neatrisina.

JSONL ievade: pārbaude pirms augšupielādes

JSONL failā katra rinda ir patstāvīgs JSON objekts. Paketes pieprasījuma pamatlauki ir custom_id, method, url un body. Unikālais custom_id savieno atbildi ar sākotnējo ierakstu; body satur tā paša galapunkta parametrus, kurus lietotu parastā pieprasījumā. Vienā ievades failā drīkst iekļaut pieprasījumus tikai vienam modelim.

Pirms faila iesniegšanas automatizēti pārbaudi:

Katru rindu var nolasīt kā atsevišķu JSON objektu; fails nav viens JSON masīvs, un tajā nav tukšu vai bojātu rindu.
Visiem custom_id ir atbilstošs avota ieraksts, un identifikatori failā neatkārtojas.
method ir POST, bet katras rindas url atbilst galapunktam, ko norādīsi, veidojot paketi.
body satur izvēlētajam galapunktam derīgus parametrus un vienu atbalstītu modeli; pieprasījumos nav ieslēgta straumēšana.
Faila lielums, pieprasījumu skaits un rindā gaidošo ievades tokenu apjoms iekļaujas attiecīgajos paketes un projekta ierobežojumos.

Pieņemsim, ka jāklasificē produktu apraksti. Katram aprakstam var piešķirt stabilu avota sistēmas identifikatoru kā custom_id un saglabāt šo vērtību līdzās sākotnējam tekstam. Izvades rindu secība var atšķirties no ievades secības, tāpēc rindas numurs nav droša atbilžu sasaistes metode. Tas ir īpaši svarīgi, ja daļai pieprasījumu atbilde nonāk kļūdu failā.

No faila līdz paketes statusam

JSONL failu augšupielādē ar Files API, norādot mērķi batch. Pēc tam, veidojot paketi, nodod augšupielādētā faila ID laukā input_file_id, norādi endpoint un iestati completion_window vērtību 24h. Saglabā saņemto paketes ID: ar to var pieprasīt statusu un vēlāk atrast izvades failu.

Statuss validating nozīmē ievades pārbaudi, in_progress — apstrādi, finalizing — rezultātu sagatavošanu, bet completed — gatavu paketi. failed norāda uz neizturētu ievades validāciju; expired nozīmē, ka paketi neizdevās pabeigt noteiktajā logā. Statusi cancelling un cancelled attiecas uz manuālu atcelšanu. Šīs atšķirības ļauj automatizācijai lemt, vai gaidīt, labot ievadi vai apstrādāt jau pieejamos rezultātus.

Rezultātu sasaistīšana un daļēja izpilde

Paketes objektā output_file_id norāda uz pabeigto pieprasījumu atbilžu failu, bet error_file_id — uz kļūdaino pieprasījumu ierakstiem, ja tādi ir. Katru izvades rindu piesaisti sākotnējam ierakstam pēc custom_id un pārbaudi atbildes statusa kodu. Pēc tam salīdzini ievades identifikatoru kopu ar izvades un kļūdu ierakstiem, lai nepaliktu nepamanīts neviens pieprasījums.

Ja paketes termiņš beidzas pirms visa darba pabeigšanas, nepabeigtie pieprasījumi tiek atcelti, bet pabeigtās atbildes paliek pieejamas. Par pabeigtajos pieprasījumos patērētajiem tokeniem ir jāmaksā. Tāpēc atkārtotai iesniegšanai veido jaunu ievades kopu tikai no tiem ierakstiem, kuriem nav veiksmīgas atbildes; pretējā gadījumā jau paveiktais darbs var tikt apstrādāts un apmaksāts vēlreiz.

Arī manuāli atcelta pakete var atgriezt līdz atcelšanai pabeigtās atbildes. Kļūdu failā esošos ierakstus ir vērts atšķirt pēc iemesla: nederīgs pieprasījums vispirms jāizlabo, savukārt termiņā nepabeigtu darbu var iesniegt atkārtoti. Saglabāta saikne starp custom_id un avota datiem ļauj abas darbības veikt, nepārskatot rezultātus ar roku.

Kā novērtēt ietaupījumu

OpenAI API cenu tabula atdala standarta un paketes tarifus pēc modeļa un ievades, kešotās ievades un izvades tokeniem. Aprēķinam izmanto vienu un to pašu modeli un paredzamo tokenu sadalījumu abos apstrādes veidos. Salīdzinot tikai pieprasījumu skaitu, var palaist garām atšķirību, ko rada garākas atbildes vai cits kešotās ievades īpatsvars.

Atlaide attiecas uz API apstrādes cenu, nevis uz visu datu apstrādes sistēmas budžetu. Kopējā izvēlē jāņem vērā arī faila sagatavošana, statusa pārbaude, rezultātu sasaistīšana un kļūdaino pieprasījumu atkārtota iesniegšana. Ja šī darbplūsma jau ir automatizēta un rezultāti drīkst pienākt vēlāk, pakete var samazināt izmaksas, nezaudējot darbam vajadzīgo funkcionalitāti.

Lasiet arī: