Kako dizajnirati LLM upite s obzirom na predmemoriju na OpenAI, Anthropic i Gemini

Brzo predmemoriranje pomaže samo kada se isti tokeni ponovno koriste na pravom mjestu, dovoljno dugo i pod semantikom pružatelja koju zapravo pozivate. Timovi često propuštaju korist jer predmemoriranje tretiraju kao značajku modela umjesto kao problem arhitekture zahtjeva. Stavljaju vremenske oznake na vrh svakog odziva, isprepliću rezultate dohvaćanja specifičnih za zahtjeve sa shemama alata za višekratnu upotrebu ili optimiziraju za jednog pružatelja dok tiho povećavaju troškove za drugog.

Praktično rješenje je učiniti brzo predmemoriranje dijelom kompilatora zahtjeva pristupnika. Gateway bi trebao odvojiti stabilni brzi materijal od nepostojanog materijala zahtjeva, kompilirati upute za predmemoriju specifične za pružatelja usluga i mjeriti trošak i kašnjenje prema prefiksu koji se može predmemorirati. To je najvažnije u okruženju s više modela, gdje OpenAI, Anthropic i Gemini izlažu različito ponašanje predmemoriranja, računovodstvena polja, TTL-ove i troškove postavljanja.

Počnite s jedinicom koja se može predmemorirati, a ne s pružateljem

Jedinica za višekratnu upotrebu obično nije cijeli upit. To je prefiks ili objekt konteksta napravljen od brzog materijala koji dijele mnogi zahtjevi. U produkcijskom enterprise LLM API taj materijal često uključuje politiku platforme, politiku organizacije, upute za aplikacije, definicije alata, pravila formata odgovora, upute agenta za kodiranje ili statičke smjernice za korpus.

Promjenjivi dio je materijal koji se mijenja po zahtjevu: trenutni zadatak korisnika, ID-ovi zahtjeva, vremenske oznake, rep razgovora, svježe preuzeti RAG odlomci, podaci specifični za račun i rezultati jednokratnih alata. Ako se nestabilni sadržaj pojavi prije stabilnog sadržaja, može prekinuti ponovnu upotrebu prefiksa ili natjerati pružatelja da veliki upit tretira kao novi.

Činjenica: implementacije pružatelja usluga razlikuju se. OpenAI dokumenti zahtijevaju predmemoriranje kao ponovnu upotrebu zajedničkog prefiksa, s obračunom predmemoriranih tokena. Njegov članak o javnom brzom predmemoriranju kaže da automatsko predmemoriranje počinje od prefiksa od 1024 tokena i raste u koracima od 128 tokena, te da se unosi u predmemoriju obično brišu nakon 5 do 10 minuta neaktivnosti i unutar jednog sata od zadnje upotrebe. Anthropic dokumentira eksplicitne prijelomne točke predmemorije i preporučuje postavljanje cache_control na zadnji dijeljeni blok, kao što su upiti sustava ili definicije alata. Gemini dokumentira predmemoriranje konteksta kao značajku koja se plaća s brojevima predmemoriranih tokena koji se vraćaju u metapodacima upotrebe za operacije predmemorije i pozive generiranja koji koriste predmemoriju.

Preporuka: dizajnirajte svoj interni brzi prikaz oko stabilnih blokova i nepostojanih blokova prije mapiranja bilo čega na pružatelja API-ji.

Kompiliraj zahtjeve od najstabilnijih do najnestalnijih

Prevodilac zahtjeva koji je svjestan predmemorije trebao bi rasporediti materijal tako da se najveći odjeljak za višekratnu upotrebu pojavi prije odjeljka koji se odnosi na zahtjev. Praktični zadani redoslijed je:

1. Pravila o sigurnosti i usklađenosti platforme.
2. Pravila organizacije ili stanara.
3. Upute o ulozi aplikacije i zadacima.
4. Sheme alata i pravila za korištenje alata.
5. Statičko znanje ili dugotrajna referenca materijal.
6. Povijest razgovora koja se ponovno koristi u svim redovima.
7. Dohvaćeni odlomci ili drugi kontekst specifičan za zahtjev.
8. Trenutni korisnički zadatak.
9. Efemerni metapodaci potrebni samo za ovaj poziv.

Ovaj poredak nije univerzalna istina. Neki pružatelji usluga ili modeli mogu drugačije reagirati kada se upute pomaknu. Prioritet politike i kvaliteta ponašanja i dalje su važni.Tretirajte redoslijed koji je svjestan predmemorije kao kontroliranu promjenu: pokrenite brze regresijske testove prije i nakon promjene izgleda.

Primjer internih blokova upita

{
  "blocks": [
    {"id": "platform_policy:v7", "stability": "global", "kind": "system"},
    {"id": "org_policy:acme:v3", "stability": "tenant", "kind": "system"},
    {"id": "support_agent:v12", "stability": "app", "kind": "instructions"},
    {"id": "crm_tools:v5", "stability": "app", "kind": "tool_schema"},
    {"id": "kb_static:returns:v2", "stability": "workflow", "kind": "context"},
    {"id": "conversation_tail", "stability": "session", "kind": "history"},
    {"id": "retrieved_docs", "stability": "request", "kind": "rag"},
    {"id": "user_task", "stability": "request", "kind": "user"}
  ]
}

Prevodilac može hashirati stabilni prefiks nakon što ga prikaže. Taj hash postaje ključ pridruživanja za analitiku predmemorije: model, zakupac, aplikacija, hash prefiksa koji se može predmemorirati, brza verzija, TTL izbor, nekeširani ulazni tokeni, predmemorirani ulazni tokeni, tokeni za upisivanje u predmemoriju gdje su dostupni, izlazni tokeni, latencija i konačna cijena.

Koristite adaptere dobavljača umjesto jedne predmemorije Pretpostavka

Jedna oznaka "omogući predmemoriju" previše je nejasna za operacije s više pružatelja usluga. Gateway bi trebao izložiti jednu internu politiku predmemorije i kompilirati je u ponašanje specifično za pružatelja usluga.

OpenAI Adapter

Za OpenAI, optimizirajte za ponovljene dijeljene prefikse i obračun korištenja. Sastavljač zahtjeva treba držati stabilan materijal na početku i izbjegavati male razlike unutar prvog raspona koji se može predmemorirati. Pratite predmemorirane ulazne tokene iz polja upotrebe pružatelja usluga. Gdje je dostupno, također pratite tokene za pisanje u predmemoriju kako bi knjiga troškova mogla usporediti stvaranje i ponovnu upotrebu predmemorije.

Budući da je predmemorija orijentirana na prefiks, važan operativni zadatak je sprječavanje pomicanja prefiksa. Dva upita koja ljudima izgledaju isto mogu se razlikovati jer je vremenska oznaka, ID izrade, nasumični redoslijed alata ili personalizacija stanara prikazana pri vrhu.

Anthropic Adapter

Za Anthropic, kompajlirajte eksplicitne prijelomne točke predmemorije. Stavite cache_control na posljednji blok koji bi se trebao podijeliti s naknadnim zahtjevima. Dobri kandidati su velike sistemske upute, definicije alata ili stabilan referentni kontekst. Loši kandidati su jednokratne korisničke poruke, trenutno opterećenje zadataka ili RAG isječci specifični za zahtjev.

Činjenica: Anthropic dokumentira zadano trajanje predmemorije od 5 minuta i trajanje predmemorije od 1 sata dostupno uz dodatnu cijenu. To odabir TTL čini ekonomskom odlukom. Dugačka predmemorija može imati smisla za interaktivne agente kodiranja, pregled dokumenata u više koraka ili podršku kopilotima s pauzama između poteza. Može biti rasipan za jednokratni zadatak s malim brojem ponavljanja.

Gemini Adapter

Za Gemini, tretirajte predmemoriju konteksta kao odluku o resursu. Stvorite sadržaj iz predmemorije kada očekivana ponovna upotreba opravdava troškove postavljanja i pohrane, a zatim referencirajte tu predmemoriju iz poziva generiranja. Ovo se razlikuje od oslanjanja samo na automatsku predmemoriju prefiksa. Adapter bi trebao posjedovati životni ciklus predmemorije, TTL, metapodatke i politiku čišćenja.

Gemini kontekstne predmemorije u stilu često su najbolje za veliki, stabilni kontekst koji će mnogi zahtjevi ponovno koristiti: dugačak priručnik o pravilima, statični izvadak kataloga proizvoda, fiksno okruženje alata agenta za kodiranje ili tijek rada pregleda koji više puta postavlja pitanja preko istog dokumenta set.

Mjerenje ekonomije predmemorije, a ne samo stope pogodaka

Stopa pogodaka predmemorije korisna je, ali nije dovoljna. Visoka stopa pogodaka na malom prefiksu može malo uštedjeti. Niža stopa pogodaka na vrlo velikom prefiksu pravila i alata može biti važnija.Neki pružatelji izlažu troškove pisanja u predmemoriju ili postavljanja, a ti troškovi mogu poništiti uštede ako je ponovna upotreba niska.

Uhvatite ova polja za svaki zahtjev gdje ih pružatelj izlaže ili ih pristupnik može procijeniti:

• Pružatelj i model.
• Zakupac, aplikacija, okruženje i API ključ identitet.
• Verzija predloška upita i hash prefiksa koji se može predmemorirati.
• TTL pravilo ili trajanje predmemorije.
• Nekeširani ulazni tokeni.
• Keširani ulazni tokeni.
• Cache-write ili cache-creation tokeni gdje dostupno.
• Izlazni tokeni.
• Vrijeme do prvog tokena i ukupna latencija.
• Verzija s popisom cijena pružatelja koja se koristi za izračun troškova.
• Je li zahtjev bio dio interaktivne sesije, skupnog posla, petlje agenta ili jednokratnog poziva.

Zatim izračunati vrijednost predmemorije prema radnom opterećenju, a ne globalno. Kopilot za podršku, agent za kodiranje, preglednik dokumenata i jednokratni sažimač imaju različite obrasce ponovne upotrebe. Skupni podaci bi trebali prikazivati ​​ušteđene dolare, potrošene dolare za pisanje u predmemoriju, promjenu latencije i stopu pogodaka prema hash prefiksu.

Jednostavan ROI model je dovoljan za početak:

expected_savings =
  expected_reuses
  * cacheable_tokens
  * (uncached_input_price - cached_input_price)

net_value =
  expected_savings
  - cache_write_or_setup_cost
  - operational_overhead

Ovaj model je namjerno jednostavan. Trebalo bi se koristiti kao ulaz prije omogućavanja dugotrajnih ili eksplicitnih predmemorija, a ne kao zamjena za mjerenje proizvodnje.

Dodajte pravila za razbijanje predmemorije

Većina kvarova predmemorije dolazi zbog navika brze izrade, a ne zbog grešaka u pružatelju. Dodajte gateway lint pravila koja se pokreću prije nego što zahtjevi dođu do pružatelja usluga.

Označite vremenske oznake pri vrhu upita. Ako model treba trenutno vrijeme, postavite ga iza prefiksa koji se može višekratno koristiti ili ga proslijedite kao kasni blok zahtjeva.

Označite nasumične ID-ove u porukama sustava. ID-ovi korelacije pripadaju metapodacima ili zapisnicima, a ne stabilnom prefiksu upita.

Označite dinamički uređene sheme alata. Razvrstajte alate i svojstva sheme deterministički prije iscrtavanja. Popis alata koji mijenja redoslijed na svakom zahtjevu može uništiti ponovnu upotrebu čak i kada je skup alata logički identičan.

Označite RAG specifičan za zahtjev prije stabilnih alata. Pronađeni odlomci često su nepostojani. Prvo stavite stabilne upute i sheme alata, a zatim dohvaćene odlomke, osim ako brzi testovi ne dokažu da je potreban drugi redoslijed.

Označite personalizaciju specifičnu za korisnika u dijeljenim pravilima. Pravila zakupca mogu se predmemorirati preko zakupca, ali korisničke postavke i trenutno stanje računa obično nisu.

Označite odljev verzije predloška. Ako svaka implementacija promijeni razmake, komentare ili neiskorišteni tekst uputa, mijenja se hash prefiksa koji se može predmemorirati. Predloške upita za verziju namjerno i izbjegavajte nepotrebna uređivanja velikih stabilnih blokova.

Pažljivo postupajte s RAG radnim opterećenjima

RAG je mjesto gdje timovi često predmemoriraju previše. Stabilne upute za dohvaćanje, pravila citiranja, sheme alata i opisi korpusa mogu se ponovno koristiti. Sami preuzeti odlomci obično su specifični za zahtjev. Ako dohvaćene odlomke stavite ispred stabilnih uputa, smanjit ćete ponovnu upotrebu. Ako predmemorirate cijeli kontekst kada je malo vjerojatno da će se odlomci ponoviti, možete platiti troškove pisanja ili postavljanja bez dovoljno budućih pogodaka.

Postoje iznimke. Tijek pravnog pregleda, tijek rada za podršku ili pomoćnik za dokumente proizvoda mogu opetovano postavljati upite istom paketu dokumenata u jednoj sesiji. U tom slučaju dugotrajnija predmemorija za kontekst dokumenta može biti korisna.Odluka bi trebala ovisiti o očekivanom broju ponovne upotrebe, trajanju predmemorije, veličini konteksta dokumenta i tome hoće li korisnici postavljati više pitanja o istom materijalu.

Preporuka: klasificirajte RAG kontekst kao jednu od tri vrste: statično vođenje korpusa, kontekst sesije za višekratnu upotrebu ili jednokratno dohvaćeni isječci. Predmemorirajte samo prva dva prema zadanim postavkama.

Provjerite ponašanje prije optimizacije troškova

Kasnije premještanje sadržaja u odzivniku može poboljšati ponovnu upotrebu predmemorije, ali također može promijeniti ponašanje modela. Na primjer, premještanje pravila alata nakon povijesti razgovora može smanjiti njihov utjecaj. Premještanje pravila ispod dohvaćenog sadržaja može oslabiti prioritet uputa. Normaliziranje shema može utjecati na odabir alata ako se opisi promijene.

Upotrijebite regresijske testove prije uvođenja izgleda koji su svjesni predmemorije. Najmanje testirajte:

• Prioritet uputa za politiku sigurnosti i sukladnosti.
• Odabir alata za poznate zadatke.
• Valjanost strukturiranog izlaza gdje su uključene sheme.
• Kvaliteta odgovora na reprezentativnim primjerima RAG-a.
• Kašnjenje i trošak kod ponovljenih okreće se.
• Računovodstvo upotrebe specifično za pružatelja usluga.

Za visokorizične tijekove rada, pokrenite usporedbu u sjeni: izvorni raspored upita naspram rasporeda koji je svjestan predmemorije, isti model, isti ulazi, s ljudskim ili automatskim provjerama za neprihvatljive izlazne promjene. Ušteda troškova nije korisna ako kompajler zahtjeva mijenja poslovno ponašanje na načine koje timovi nisu odobrili.

Selektivno birajte radna opterećenja

Predmemoriranje upita najjače je kada su odgovori dugi i ponavljaju se. Dobre početne točke uključuju agente za kodiranje s velikim shemama alata, kopilote za podršku s uputama koje sadrže puno pravila, tokove pregleda dokumenata s ponovljenim pitanjima o istom materijalu, agente s velikim brojem alata i poslovne pomoćnike s velikim blokovima upravljanja.

Slabi kandidati uključuju kratke jednokratne upite, vrlo personalizirane upite gdje se vrh zahtjeva mijenja svaki put, rijetke zadatke administratora i tijekove rada u kojima izlaz tokeni dominiraju ukupnim troškom. U tim slučajevima druge optimizacije mogu biti važnije: kraće upute, bolje dohvaćanje, usmjeravanje modela, skupna obrada ili stroža ograničenja izlaza.

Predviđanje: semantika predmemoriranja pružatelja nastavit će se razlikovati. Automatsko predmemoriranje prefiksa, eksplicitne prijelomne točke, plaćeni kontekstni resursi, obračun pisanja u predmemoriju i TTL cijene vjerojatno će ostati neujednačene na svim platformama.Timovi koji centraliziraju kompilaciju zahtjeva i telemetriju na pristupniku moći će se prilagoditi brže od timova koji ugrađuju logiku predmemoriranja specifičnu za pružatelja usluga u kodu aplikacije.

Kontrolni popis implementacije

• Stvorite interni model blokova upita s oznakama stabilnosti: globalno, zakupac, aplikacija, tijek rada, sesija i zahtjev.
• Renderiranje blokova deterministički, uključujući redoslijed alata i redoslijed svojstava sheme.
• Premjestite nepostojana polja iz stabilnog prefiksa.
• Izračunajte hash prefiksa koji se može predmemorirati nakon iscrtavanja.
• Dodajte adaptere pružatelja za OpenAI ponovnu upotrebu prefiksa, Anthropic prijelomne točke predmemorije i Gemini kontekstnu predmemoriju resursi.
• Zabilježite tokene za unos bez predmemoriranja, tokene za unos u predmemoriju, tokene za pisanje u predmemoriju gdje su dostupni, izlazne tokene, latenciju, model, zakupca, aplikaciju, raspršivanje prefiksa i TTL.
• Izradite nadzorne ploče za neto ušteđene dolare, trošak pisanja/postavljanja, stopu pogodaka i latenciju prema radno opterećenje.
• Dodajte pravila za vremenske oznake, nasumične ID-ove, nestabilni RAG položaj, dinamički redoslijed alata i personalizaciju u dijeljenim blokovima.
• Pokrenite brze testove regresije ponašanja prije promjene proizvodnog izgleda.
• Prvo omogućite predmemoriju za radna opterećenja s velikim brojem ponavljanja, a zatim proširite na temelju izmjerenih ROI.

Zaključak

Dizajn obavijesti s obzirom na predmemoriju nije samo brzo oblikovanje. To je mogućnost pristupnika: determinističko prikazivanje, dizajn stabilnog prefiksa, kompilacija specifična za pružatelja usluga, linting i telemetrija troškova. Timovi koji će imati najviše koristi bit će oni koji mogu odgovoriti na tri pitanja za svako radno opterećenje: koji se dio zahtjeva doista može ponovno upotrijebiti, kako ovaj pružatelj naplaćuje ponovnu upotrebu i je li predmemorija poboljšala troškove od kraja do kraja ili latenciju bez promjene ponašanja?

Počnite s jednim radnim procesom koji se često ponavlja. Odvojite stabilne blokove od nepostojanih blokova, dodajte rukovanje predmemorijom specifično za pružatelja usluga, izmjerite ekonomičnost i tek onda generalizirajte. Taj put izbjegava uobičajeni način neuspjeha: uključivanje značajke predmemorije bez znanja štedi li novac, dodaje latenciju ili jednostavno prebacuje trošak u drugo računovodstveno polje.

Povezano čitanje

• provider-neutral LLM opažanje