Hinihingi ng iyong mga user ang parehong tanong sa 40 iba’t ibang paraan, at binabayaran mo ang iyong LLM para sagutin ang bawat isa nang mula sa simula. “Paano ko i-reset ang aking password?” “Nakalimutan ko ang aking login, tulungan ako” “Hindi ako makapasok sa aking account” Parehong sagot. Tatlong buong model call. Ang karaniwang caching ay hindi makakatanggap nito. Nagtatrabaho lamang ito kapag tumutugma ang teksto nang eksaktong karakter sa karakter. Ang semantic caching ay tumutugma sa KAHULUGAN. Lumalabas ang isang tanong. Ibinabago ito sa isang embedding. Tinataya ng cache kung nakasagot na kayo ng isang bagay na sapat na malapit. Nakatagpo? Agad na ibinabalik ang naka-save na sagot. Walang LLM call. Hindi nakatagpo? Sumasagot ang model, at naka-save ang sagot para sa susunod na pagkakataon. Ang Redis ay nagpapatakbo na nito bilang isang managed service na tinatawag na LangCache. Walang karagdagang database na kailangang i-deploy, kinokontrol na para sa iyo ang TTL at eviction. Ayun ang kanilang pag-claim: 15x mas mabilis ang cache hits at malaking pagbawas sa iyong API bill. Ngunit dito ang bahagi na walang sinasabi ang iba. Ang similarity threshold ang lugar kung saan ito bumubulok. Masyadong maluwag ang pagtatakda at “paano ko i-rotate ang aking API key” ay babalikin ang sagot para sa “paano ko i-revoke ang aking API key.” Malapit sa kahulugan. Sang-ayon na iba’t ibang resulta. Kaya simulan mo nang mahigpit. I-log ang bawat hit sa loob ng isang linggo. Palawakin lamang kung napatunayan mong ang mga sagot ay tunay na palitan. Ang iyong savings ay nakadepende sa kung gaano karaming paulit-ulit ang iyong traffic. Ang mga support bot at internal docs assistants ay nananalo nang malaki. Ang mga likha o okasyonal na query ay malamig na hindi nagbabago. Tingnan ang iyong mga log bago tingnan ang pricing page. sumunod sa @cyrilXBT https://t.co/tQmQCsxVlo