Šis raksts ir daļa no VentureBeat īpašā numura “AI reālās izmaksas: veiktspēja, efektivitāte un ROI mērogā”. Lasiet vairāk no šī īpašā numura.
Modeļu pakalpojumu sniedzēji turpina ieviest aizvien sarežģītākus lielo valodu modeļus (LLMS) ar garākiem konteksta logiem un uzlabotām spriešanas iespējām.
Tas ļauj modeļiem apstrādāt un “domāt” vairāk, bet tas arī palielina aprēķināšanu: jo vairāk modelis uzņem un izliek, jo vairāk enerģijas tas tērē un jo augstākas ir izmaksas.
Savienojiet to ar visu piesaistīšanos, kas saistīta ar pamudinājumu – var būt nepieciešami daži mēģinājumi, lai nokļūtu paredzētajā rezultātā, un dažreiz šim jautājumam vienkārši nav nepieciešams modelis, kas var domāt kā doktora grāds – un aprēķināt tēriņus var izkļūt no kontroles.
Tas rada tūlītēju OPS, pilnīgi jaunu disciplīnu AI Dawning laikmetā.
“Ātra inženierija ir tāda veida kā rakstīšana, faktiskā radīšana, turpretī uzvedumi ir kā publicēšana, kur jūs attīstāt saturu,” Crawford Del Prete, IDC Prezidents, pastāstīja VentureBeat. “Saturs ir dzīvs, saturs mainās, un jūs vēlaties pārliecināties, ka laika gaitā to uzlabojat.”
Aprēķināšanas izmantošanas un izmaksu izaicinājums
Aprēķina lietošana un izmaksas ir divi “saistīti, bet atsevišķi jēdzieni” LLMS kontekstā, skaidroja Deivids Emersons, lietišķais zinātnieks Vektora institūtsApvidū Parasti cenas lietotāji maksā skalas, pamatojoties gan uz ievades žetonu skaitu (ko uzaicina lietotājs), gan uz izvades žetonu skaitu (ko modelis piegādā). Tomēr tie netiek mainīti uz aizkulišu darbībām, piemēram, meta-reklamēm, stūrēšanas instrukcijām vai paaudzes paaudzei (RAG).
Kaut arī garāks konteksts ļauj modeļiem vienlaikus apstrādāt daudz vairāk teksta, tas tieši nozīmē ievērojami vairāk flopu (aprēķināšanas jaudas mērījums), viņš paskaidroja. Daži transformatoru modeļu aspekti pat kvadrātiski mērogā ar ieejas garumu, ja tie nav labi pārvaldīti. Nevajadzīgi ilgas atbildes var arī palēnināt apstrādes laiku un prasīt papildu aprēķināšanu un izmaksas, lai izveidotu un uzturētu algoritmus, lai pēcapstrādes atbildes uz atbildi, uz kuru lietotāji cerēja.
Parasti ilgāka konteksta vide stimulē pakalpojumu sniedzējus apzināti sniegt izteiksmīgas atbildes, sacīja Emersons. Piemēram, daudzi smagāki spriešanas modeļi (piemēram, O3 vai O1 no Openai) bieži sniedz ilgas atbildes uz pat vienkāršiem jautājumiem, radot lielas skaitļošanas izmaksas.
Šeit ir piemērs:
Ieguldījums: Atbildiet uz šo matemātikas problēmu. Ja man ir 2 āboli un es pērku vēl 4 Uzglabāt pēc ēšanas 1, cik man ir ābolu?
Izvade: Ja es ēdu 1, man ir palicis tikai 1. Man būtu 5 āboli, ja es nopirktu vēl 4.
Modelis ne tikai ģenerēja vairāk žetonu, nekā tas bija nepieciešams, bet arī apglabāja savu atbildi. Pēc tam inženierim var būt jāizstrādā programmatisks veids, kā iegūt galīgo atbildi vai uzdot sekojošos jautājumus, piemēram, “Kāda ir jūsu galīgā atbilde?” Tas rodas vēl vairāk API izmaksu.
Alternatīvi, uzvedni var pārveidot, lai modelim palīdzētu radīt tūlītēju atbildi. Piemēram:
Ieguldījums: Atbildiet uz šo matemātikas problēmu. Ja man ir 2 āboli un es pērku vēl 4E Uzglabāt pēc ēšanas 1, cik man ir ābolu? Sāciet savu atbildi ar “Atbilde ir”…
Vai:
Ieguldījums: Atbildiet uz šo matemātikas problēmu. Ja man ir 2 āboli un pēc 1 ēšanas es iegādājos vēl 4 veikalā, cik man ir ābolu? Aptiniet savu galīgo atbildi treknrakstā tagos Apvidū
“Jautājuma veids var samazināt centienus vai izmaksas, lai nonāktu vēlamajā atbildē,” sacīja Emersons. Viņš arī norādīja, ka tādi paņēmieni kā daži kadru pamudinājumi (daži piemēri, ko lietotājs meklē) var palīdzēt radīt ātrāku izeju.
Viena no briesmām ir nezināt, kad izmantot sarežģītas metodes, piemēram, pārdomu ķēdes (COT), pamudinot (atbildes ģenerējot pakāpienus) vai pašrefināciju, kas tieši mudina modeļus ražot daudzus žetonus vai iziet vairākas iterācijas, radot atbildes, Emersons norādīja.
Ne katram vaicājumam ir nepieciešams modelis, lai analizētu un atkārtoti analizētu pirms atbildes sniegšanas, viņš uzsvēra; Viņi varētu būt pilnīgi spējīgi pareizi atbildēt, kad viņiem ir norādīts tieši reaģēt. Turklāt, ja pietiks ar zemāku piepūli, pietiktu nepareizai API konfigurācijām (piemēram, Openai O3, kurai nepieciešami augstas spriešanas pūles) būs augstākas izmaksas.
“Izmantojot ilgāku kontekstu, lietotājiem var rasties arī kārdinājums izmantot“ visu, izņemot virtuves izlietni ”pieeju, kurā jūs pēc iespējas vairāk teksta iemetiet modeļa kontekstā, cerot, ka, to darot, palīdzēs modelim precīzāk veikt uzdevumu,” sacīja Emersons. “Lai gan vairāk konteksta var palīdzēt modeļiem veikt uzdevumus, tā ne vienmēr ir labākā vai efektīvākā pieeja.”
Evolūcija, lai pamudinātu OPS
Nav liels noslēpums, ka šajās dienās var būt grūti iegūt ai-optimizētu infrastruktūru; IDC Del Prete norādīja, ka uzņēmumiem jāspēj samazināt GPU dīkstāves laika daudzumu un aizpildīt vairāk vaicājumu dīkstāves ciklos starp GPU pieprasījumiem.
“Kā es varu vairāk izspiest no šīm ļoti, ļoti vērtīgajām precēm?”, Viņš atzīmēja. “Tā kā man ir jāveic mana sistēmas izmantošana, jo man vienkārši nav priekšrocības, vienkārši metot lielāku jaudu pie problēmas.”
Ātri OPS var būt tālu, lai risinātu šo izaicinājumu, jo tas galu galā pārvalda uzvednes dzīves ciklu. Kamēr ātrā inženierija ir saistīta ar uzvednes kvalitāti, uzvedne OPS ir vieta, kur jūs atkārtojat, paskaidroja Del Prete.
“Tā ir vairāk orķestrēšana,” viņš teica. “Es to domāju par jautājumu veidošanu un to, kā jūs mijiedarbojaties ar AI, lai pārliecinātos, ka jūs no tā gūstat maksimālu labumu.”
Viņš sacīja, ka modeļiem ir tendence kļūt “nogurušiem”, cik riteņbraukšana cilpās, kur izejas kvalitāte pasliktinās. Ātri OPS palīdz pārvaldīt, izmērīt, uzraudzīt un noregulēt uzvednes. “Es domāju, ka tad, kad mēs atskatāmies trīs vai četrus gadus pēc šī brīža, tā būs vesela disciplīna. Tā būs prasme.”
Lai gan tas joprojām ir ļoti jauns lauks, agrīnie pakalpojumu sniedzēji ietver querypal, mudināmus, atspēkojumus un Truelens. Attīstoties uzvedumiem, šīs platformas turpinās atkārtot, uzlabot un sniegt reāllaika atsauksmes, lai lietotājiem vairāk spētu laika gaitā noregulēt uzvednes, atzīmēja Dep Prete.
Galu galā, pēc viņa domām, aģenti pats varēs noregulēt, rakstīt un strukturēt pamudinājumus. “Automatizācijas līmenis palielināsies, samazināsies cilvēku mijiedarbības līmenis, jūs varēsit, lai aģenti darbotos autonomāk, ņemot vērā viņu radītās uzvednes.”
Parastās pamudināšanas kļūdas
Kamēr uzvedne nav pilnībā realizēta, galu galā nav perfekta uzvedne. Pēc Emersona teiktā, dažas no lielākajām kļūdām, ko cilvēki pieļauj:
- Nav pietiekami specifisks par problēmu, kas jāatrisina. Tas ietver to, kā lietotājs vēlas, lai modelis sniegtu atbildi, kas jāņem vērā reaģēšanas laikā, ierobežojumi ņemt vērā un citi faktori. “Daudzos iestatījumos modeļiem ir nepieciešams labs konteksta daudzums, lai sniegtu atbildi, kas lietotājiem atbilst cerībām,” sacīja Emersons.
- Neņemot vērā veidu, kā problēmu var vienkāršot, lai sašaurinātu reakcijas jomu. Vai atbildei vajadzētu būt noteiktā diapazonā (no 0 līdz 100)? Vai atbilde būtu jāizveido kā atbilžu variante, nevis kaut kas beztermiņa? Vai lietotājs var sniegt labus piemērus vaicājuma kontekstualizēšanai? Vai problēmu var sadalīt atsevišķos un vienkāršākos jautājumos?
- Neizmantojot struktūras priekšrocības. LLM ir ļoti labs modeļa atpazīšanā, un daudzi var saprast kodu. Izmantojot ložu punktus, detalizēti saraksti vai treknrakstā indikatori (****) Cilvēka acīm var šķist “mazliet pārblīvēti”, Emersons atzīmēja, ka šīs izsaukšanas var būt noderīgas LLM. Lūgšana pēc strukturētas izejas (piemēram, JSON vai Markdown) var palīdzēt arī tad, ja lietotāji vēlas automātiski apstrādāt atbildes.
Ir daudz citu faktoru, kas jāņem vērā ražošanas cauruļvada uzturēšanā, pamatojoties uz labāko inženiertehnisko praksi, atzīmēja Emersons. Tie ietver:
- Pārliecinoties, ka cauruļvada caurlaide paliek konsekventa;
- Uzvednes veiktspējas uzraudzība laika gaitā (potenciāli pret validācijas kopu);
- Pārbaužu iestatīšana un agrīna brīdinājuma noteikšana, lai identificētu cauruļvada problēmas.
Lietotāji var arī izmantot rīkus, kas izstrādāti, lai atbalstītu pamudināšanas procesu. Piemēram, atvērtā koda Dspy var automātiski konfigurēt un optimizēt pakārtotos uzdevumus, pamatojoties uz dažiem marķētiem piemēriem. Lai gan tas var būt diezgan izsmalcināts piemērs, ir daudz citu piedāvājumu (ieskaitot dažus iebūvētus tādos rīkos, piemēram, Chatgpt, Google un citi), kas var palīdzēt nekavējoties noformēt.
Un galu galā Emersons sacīja: “Es domāju, ka viena no vienkāršākajām lietām, ko lietotāji var darīt, ir mēģināt saglabāt mūsdienīgu efektīvu pamudinājumu pieeju, modeļa attīstību un jaunus veidus, kā konfigurēt un mijiedarboties ar modeļiem.”
