Szemantikus gyorsítótár LLM-alkalmazásokhoz: mikor biztonságos újrahasznosítani a válaszokat, és mikor nem

Az ügyfélszolgálati asszisztensek és a GYIK-botok újra és újra ugyanazokra a kérdésekre válaszolnak: hogyan állítom vissza a jelszavam, hol a számlám, mennyi a szállítási idő. Mindegyik kérdés egy modellhívásba kerül. A szemantikus cache az első alkalommal eltárolja a választ, és visszaadja, ha egy későbbi kérdés ugyanazt jelenti, még ha másképp is fogalmazták. Jól megcsinálva a hívások nagy része elmarad, és a válasz ezredmásodpercek alatt megérkezik. Hanyagul megcsinálva magabiztos válaszokat ad olyan kérdésekre, amelyeket senki sem tett fel.

A cikk szétválasztja a szemantikus cache-t a szolgáltatói prompt cachingtől, bemutatja az architektúrát, és idejének nagy részét azokra a részekre szánja, amelyeken a biztonság múlik: a küszöbre, a cache hatókörére, arra, mit ne cache-elj, és az érvénytelenítésre.

Miben különbözik a szemantikus cache a prompt cachingtől?

A Claude prompt caching dokumentációja egyértelmű: a találathoz 100%-ban azonos promptszakaszok kellenek, és a cache nincs hatással a kimenet generálására. Ez eleve biztonságos, és ezt érdemes először bekapcsolni; erről a prompt caching és modellirányítás cikkben írtam. A szemantikus cache a modell előtt ül, és más jellegű döntés, mert azt változtatja meg, mit kap a felhasználó.

Hogyan működik a szemantikus cache?

Az olyan könyvtárak, mint a GPTCache, ezt embedding-generátorra, a válaszok tárolójára, a kérdések vektortárára és egy hasonlóság-értékelőre bontják, amely eldönti, hogy egy jelölt egyezik-e. Könyvtár nem feltétlenül kell hozzá: egy embedding-tábla vektorindexszel Postgresben, például pgvector, és húsz sor kód elég.

# Illustrative semantic cache on Postgres + pgvector
def cached_answer(question: str, scope: dict) -> str:
    q = normalize(question)
    vec = embed(q)                                       # same model for writes and reads
    row = db.fetchone("""
        SELECT answer, 1 - (embedding <=> %(v)s) AS sim
        FROM answer_cache
        WHERE tenant = %(tenant)s AND lang = %(lang)s AND data_version = %(ver)s
          AND expires_at > now()
        ORDER BY embedding <=> %(v)s LIMIT 1""", {"v": vec, **scope})
    if row and row.sim >= THRESHOLD:
        metrics.hit(row.sim)
        return row.answer
    answer = call_model(question, scope)
    if cacheable(question, answer):
        db.execute("INSERT INTO answer_cache (...) VALUES (...)")   # with expires_at = now() + ttl
    return answer

Mennyit spórol a szemantikus cache?

A GPT Semantic Cache tanulmány Redisben tárolta a lekérdezések embeddingjeit, és ismétlődő, ügyfélszolgálati jellegű kérdéseken tesztelt. Akár 68,8%-kal kevesebb API-hívásról, kategóriától függően 61,6% és 68,8% közötti találati arányról és 97% feletti helyes találatról – azaz helyes választ adó találatról – számol be. Ezek a számok szándékosan ismétlődő forgalomból származnak. Egy termék-GYIK ilyen; egy nyílt végű asszisztens vagy egy kódolóeszköz nem, és a találatok töredékét fogja látni.

Mielőtt bármit építenél, mérd meg: naplózz egy hétnyi kérdést, embeddeld őket, és számold meg, hánynak van olyan közeli szomszédja, amelyet egy ember ugyanannak a kérdésnek fogadna el. Ez a szám a plafon.

Hogyan válaszd ki a hasonlósági küszöböt?

Az embedding-hasonlóság a témát méri, nem a szándékot. A Hogyan mondhatom le a rendelésemet? és a Hogyan mondhatom le az előfizetésemet? a vektortérben nagyon közel van, mégis más választ igényel. A Visszaküldhetem a kibontott terméket? és a Visszaküldhetem a bontatlan terméket? egyetlen szóelemben tér el, és ellentétes a válaszuk. Egy átlagos hasonlóságra hangolt küszöb boldogan kiszolgálja az egyiket a másik helyett.

1. Gyűjts néhány száz valódi kérdéspárt, és mindegyiket címkézd: azonos vagy eltérő válasz. A trükkös negatív példákat szándékosan vedd fel.
2. Számold ki minden pár hasonlóságát azzal az embedding-modellel, amelyet élesben használsz.
3. Válaszd azt a legalacsonyabb küszöböt, amelynél a téves találatok nullán vagy a közelében maradnak, és fogadd el az ebből adódó találati arányt.
4. Ismételd meg az ellenőrzést, valahányszor embedding-modellt váltasz, mert a hasonlósági skálák modellenként eltérnek.

A határsávban egy második ellenőrzés segít: a küszöb felett éppen csak átjutó találatoknál kérdezz meg egy kis, olcsó modellt, hogy a két kérdésre ugyanaz-e a válasz. Ez sokkal olcsóbb, mint a válasz generálása, és kiszűri a közeli tévedések többségét.

Hogyan akadályozd meg, hogy a szemantikus cache adatot szivárogtasson?

A cache a felhasználók közös memóriája. Ha a Mekkora a jelenlegi kedvezményem? kérdésre adott választ az ügyfélazonosító nélkül cache-eled, a következő kérdező ügyfél az első kedvezményét kapja. Minden keresést válassz szét mindazok szerint, amitől a válasz függ:

• Bérlő, személyes válaszoknál a felhasználó is. Vagy zárd ki teljesen a személyes válaszokat a cache-ből.
• Nyelv, hogy egy német kérdés ne kapjon tárolt angol választ.
• Szerepkör vagy jogosultsági szint, ha a belső munkatársak többet látnak, mint az ügyfelek.
• Adat- és promptverzió: egy új árlista, szabályzatszöveg vagy rendszerprompt új cache-névteret indítson.

A személyes adatot tartalmazó tárolt válaszok tárolt személyes adatok, a megfelelő megőrzési kötelezettségekkel; lásd a PII-kitakarás LLM-pipeline-okban cikket. A cache ráadásul írási útvonal is: ha a felhasználók tetszőleges modellkimenetet eltárolhatnak, amelyet aztán másoknak szolgálunk ki, egy prompt injectionnel manipulált válasz elterjedhet. Csak megbízható folyamatokból származó válaszokat tárolj, a guardrailek által megjelölt munkamenetekből soha.

Hogyan járjanak le és érvénytelenedjenek a tárolt válaszok?

Három mechanizmust használj együtt. Minden bejegyzésnek legyen TTL-je, inkább órákban vagy napokban, mint hónapokban mérve. A cache-kulcsban legyen verzió arra az adatra és promptra, amelyből a válasz született, így egy tartalomfrissítés új névtérre vált, ahelyett hogy egyenként törölnéd a sorokat. Végül kézi törlés dokumentumonként: ha valaki módosítja a visszaküldési szabályzatot, törölj minden bejegyzést, amelynek válasza ezt a dokumentumot idézte. Ehhez minden tárolt válasz mellé el kell menteni a forrásazonosítókat, ami a hivatkozások miatt amúgy is megéri, ahogy a grounding és hivatkozások cikkben.

Mit kell monitorozni?

A cache-találatokat ugyanúgy trace-eld, mint bármely más lépést, a hasonlósági értékkel és a tárolt bejegyzés azonosítójával, hogy egy rossz válasz visszakövethető legyen ahhoz a kérdéshez, amelyre eredetileg generálták; lásd az LLM-ágensek megfigyelhetősége cikket.

Források

1. Regmi and Pun: GPT Semantic Cache: Reducing LLM Costs and Latency via Semantic Embedding Caching (2024)
2. Zilliz: GPTCache README (modules, similarity evaluation, eviction)
3. Claude Platform Docs: Prompt caching
4. pgvector README: vector types and indexes