Cache-ul semantic reduce apelurile LLM, cu risc de eroare

Cache-ul semantic poate evita un nou apel LLM atunci când o cerere seamănă cu una deja rezolvată. Economia este utilă dacă întrebările se repetă, iar răspunsul memorat rămâne corect pentru noul context; altfel, aceeași potrivire poate livra un răspuns greșit. Studiul Microsoft Research tratează împreună costul unei noi generări și costul nepotrivirii dintre cerere și răspunsul păstrat, în condițiile în care frecvența cererilor și costurile nu sunt cunoscute dinainte.

Pentru o echipă care urmărește factura și latența, alegerea pornește de la costul unui răspuns greșit, repetitivitatea cererilor și viteza cu care se schimbă informația. Potrivirea exactă și răspunsurile aprobate acoperă cazurile ușor de delimitat; reutilizarea semantică cere filtre de context, un prag evaluat pe exemple reale și reguli de invalidare. Întrebările despre variante diferite de produs pot avea formulări aproape identice și totuși răspunsuri incompatibile.

Ce anume poate fi reutilizat

Cache-ul exact folosește o cheie care identifică cererea și contextul relevant. Dacă răspunsul depinde de limbă, regiune, versiunea documentației sau drepturile utilizatorului, aceste atribute trebuie să participe la alegerea intrării. O cheie construită numai din textul întrebării poate reuni situații care cer rezultate diferite. În schimb, parafrazele care au același sens vor produce ratări, deoarece textul lor diferă.

Răspunsurile statice aprobate sunt redactate și validate înainte să fie servite din nou. Ele se potrivesc explicațiilor frecvente despre informații relativ stabile, dacă există și o regulă pentru retragerea lor la schimbarea conținutului. Un cache dinamic păstrează răspunsuri generate în timpul utilizării aplicației. Proveniența și gradul de aprobare al acestor două categorii diferă, deci nu ar trebui tratate ca echivalente doar pentru că sunt găsite prin aceeași căutare.

Vecinul semantic verificat este un răspuns candidat găsit prin apropierea dintre întrebări și acceptat numai după o verificare suplimentară. Scorul de similaritate ajută la găsirea candidatului, dar nu stabilește singur dacă răspunsul acoperă condițiile noii cereri. Verificarea poate compara produsul, perioada, sursa informației și răspunsul propriu-zis. Dacă aceste condiții nu pot fi stabilite, aplicația poate genera un răspuns nou.

O matrice pentru alegerea cazurilor potrivite

Repetitivitatea arată câte apeluri pot fi evitate; volatilitatea arată cât timp poate rămâne valabilă o intrare; costul erorii stabilește câtă incertitudine este acceptabilă. Combinația lor este mai utilă decât un prag unic aplicat întregii aplicații.

Cereri dese, informație stabilă, eroare cu impact redus: răspunsurile aprobate sunt prima opțiune. Potrivirea semantică poate extinde acoperirea la parafraze, după evaluarea exemplelor în care cuvintele diferă, dar răspunsul rămâne același.
Cereri dese, informație schimbătoare: economia este posibilă numai dacă intrările expiră repede sau sunt invalidate când se schimbă datele de bază. Într-un exemplu ipotetic, răspunsul despre disponibilitatea unei variante de produs devine inutil după actualizarea stocului, chiar dacă întrebarea se repetă identic.
Eroare cu impact mare sau răspuns personalizat: separă strict utilizatorii, conturile și documentele la care au acces. Pentru un sold, o condiție contractuală individuală ori o acțiune ce trebuie executată acum, reutilizarea unui răspuns final poate fi nepotrivită chiar la un scor mare de similaritate.
Cereri rare: compară apelurile economisite cu timpul și costul de indexare, căutare, stocare și verificare. Dacă aproape fiecare cerere este nouă, căutarea în cache adaugă o etapă înaintea apelului LLM fără un câștig corespunzător.

Matricea se aplică pe categorii de cereri, nu pe produs în ansamblu. Un asistent poate răspunde din conținut aprobat la întrebări generale despre utilizare și poate consulta date curente pentru prețuri sau situații individuale. Astfel, o categorie utilă pentru cache nu impune aceeași politică unor cereri cu altă miză.

Pragul se judecă după răspunsuri, nu doar după întrebări

Un prag mai permisiv oferă mai mulți candidați și poate crește reutilizarea, dar admite și mai multe asemănări înșelătoare. Setul de evaluare trebuie să conțină atât parafraze pentru care același răspuns este corect, cât și perechi apropiate care diferă prin negație, versiune, regiune, interval de timp sau identitatea produsului. Eticheta decisivă este dacă răspunsul memorat rămâne potrivit pentru cererea nouă.

Înaintea comparației vectoriale, filtrele pentru produs, regiune și drepturi de acces pot elimina candidați care nu ar trebui să concureze între ei. Pragul se alege apoi pentru cererile rămase eligibile. O schimbare a modelului de reprezentare, a documentației sau a tipurilor de întrebări poate modifica distribuția scorurilor; valoarea aleasă inițial trebuie reevaluată pe cereri recente.

Urmărește separat rata de reutilizare, adică partea cererilor servite din cache, și rata răspunsurilor nepotrivite dintre cele reutilizate. Adaugă costul total pe cerere și latența observată atât la potriviri, cât și la ratări: o ratare poate include căutarea în cache înaintea generării. Măsoară separat potrivirile exacte, răspunsurile statice aprobate și vecinii semantici verificați. O rată mare de accesări nu este un rezultat bun dacă vine din acceptarea unor răspunsuri greșite.

Unde ajută verificarea asincronă

Pentru un candidat aflat imediat sub prag, verificarea poate îmbunătăți cererile viitoare fără să întârzie răspunsul curent. Cercetarea Apple despre Krites descrie un cache cu răspunsuri statice validate anterior: un arbitru LLM evaluează asincron dacă unul dintre acestea se potrivește unei cereri aflate sub prag, iar potrivirile aprobate sunt promovate în cache-ul dinamic. Cererea curentă urmează politica obișnuită de servire. Rezultatele prezentate provin din simulări pe urme de cereri conversaționale și de căutare, astfel că nu oferă un prag sau o economie direct transferabilă altei aplicații.

Această politică schimbă momentul deciziei, nu elimină riscul unei aprobări greșite. Echipa poate revizui un eșantion din răspunsurile reutilizate și poate păstra separat cazurile respinse de verificator. Costul arbitrului trebuie inclus în economia netă, chiar dacă rulează în afara traseului cererii curente. Pentru categorii cu consecințe mari, verificarea automată nu înlocuiește delimitarea strictă a datelor și a accesului.

Expirarea urmează schimbarea informației

O durată fixă pentru toate intrările ignoră felul în care apar erorile. Recomandările Amazon ElastiCache disting răspunsurile stabile de datele în timp real, propun filtre după context și descriu atât expirarea, cât și invalidarea când datele de bază se schimbă. Intervalele sugerate într-o documentație de produs sunt exemple de configurare, nu dovezi că aceeași durată păstrează corect un răspuns în orice aplicație.

O intrare utilă pentru invalidare păstrează legătura cu sursa răspunsului, versiunea acesteia, momentul generării și domeniul de acces. Când se modifică o politică sau o pagină de documentație, intrările dependente pot fi retrase imediat; așteptarea expirării le-ar permite să circule deși sunt deja depășite. Dacă se schimbă modelul ori regulile după care este formulat răspunsul, intrările vechi trebuie evaluate în raport cu noile cerințe înainte de a fi servite din nou.

Politica poate fi activată treptat pe categorii stabile, după o perioadă în care candidații sunt înregistrați fără a fi serviți. Comparația cu răspunsuri generate din informația curentă arată atât apelurile ce ar fi fost evitate, cât și nepotrivirile care ar fi ajuns la utilizator. Extinderea are sens numai când economia netă și latența obținută justifică rata de eroare acceptată pentru categoria respectivă.

Citește și: