Dela via

Hämta cachelagrade svar från API-begäranden för stora språkmodeller

GÄLLER FÖR: Alla API Management-nivåer

llm-semantic-cache-lookup Använd principen för att utföra cacheuppslagning av svar på LLM-API-begäranden (large language model) från en konfigurerad extern cache, baserat på vektornärheten för uppmaningen till tidigare begäranden och ett angivet poängtröskelvärde. Cachelagring av svar minskar bandbredds- och bearbetningskrav som ställs på LLM-API:et för serverdelen och minskar svarstiden som uppfattas av API-konsumenter.

Kommentar

Kommentar

Ange principens element och underordnade element i den ordning som anges i principbeskrivningen. Läs mer om hur du anger eller redigerar API Management-principer.

Modeller som stöds

Använd principen med LLM-API:er som lagts till i Azure API Management som är tillgängliga via Azure AI Model Inference API eller med OpenAI-kompatibla modeller som hanteras via tredjeparts slutsatsdragningsproviders.

Principuttryck

<llm-semantic-cache-lookup
    score-threshold="score threshold to return cached response"
    embeddings-backend-id ="backend entity ID for embeddings API"
    embeddings-backend-auth ="system-assigned"             
    ignore-system-messages="true | false"      
    max-message-count="count" >
    <vary-by>"expression to partition caching"</vary-by>
</llm-semantic-cache-lookup>

Attribut

Attribut beskrivning Obligatoriskt Standardvärde
score-threshold Tröskelvärde för poäng definierar hur nära en inkommande fråga måste matcha en cachelagrad uppmaning för att returnera dess lagrade svar. Värdet varierar från 0,0 till 1,0. Lägre värden kräver högre semantisk likhet för en matchning. Läs mer. Ja Ej tillämpligt
embeddings-backend-id Serverdel ID för API-anrop för inbäddning. Ja Ej tillämpligt
embeddings-backend-auth Autentisering som används för inbäddning av API-serverdelen. Ja. Måste anges till system-assigned. Ej tillämpligt
ignore-system-messages Boolesk. När det är inställt på true (rekommenderas) tar du bort systemmeddelanden från en chattavslutningsprompt innan du utvärderar cachelikhet. Nej falskt
max-message-count Om det anges hoppas antalet återstående dialogmeddelanden efter vilka cachelagring hoppas över. Nej Ej tillämpligt

Element

Namn beskrivning Obligatoriskt
vary-by Ett anpassat uttryck som bestäms vid körning vars värde partitioner cachelagring. Om flera vary-by element läggs till sammanfogas värden för att skapa en unik kombination. Nej

Förbrukning

Användningsanteckningar

  • Den här principen kan bara användas en gång i ett principavsnitt.
  • Finjustera värdet score-threshold för baserat på ditt program för att säkerställa att rätt känslighet används för att avgöra när cachelagrade svar ska returneras för frågor. Börja med ett lågt värde, till exempel 0,05, och justera för att optimera förhållandet mellan cacheträffar och missar.
  • Tröskelvärdet för poäng över 0,2 kan leda till cachematchningsfel. Överväg att använda lägre värde för känsliga användningsfall.
  • Kontrollera åtkomst mellan användare till cacheposter genom att vary-by ange med specifika användar- eller användargruppsidentifierare.
  • Inbäddningsmodellen bör ha tillräckligt med kapacitet och tillräcklig kontextstorlek för att hantera promptvolymen och prompterna.
  • Överväg att lägga till llm-content-safety-policy med prompt shield för att skydda mot snabba attacker.
  • Vi rekommenderar att du konfigurerar en princip för hastighetsbegränsning (eller princip för hastighetsgräns per nyckel ) omedelbart efter alla cachesökningar. Detta hjälper till att hindra serverdelstjänsten från att överbelastas om cacheminnet inte är tillgängligt.

Exempel

Exempel med motsvarande llm-semantic-cache-store-princip

I följande exempel visas hur du använder llm-semantic-cache-lookup principen tillsammans med llm-semantic-cache-store principen för att hämta semantiskt liknande cachelagrade svar med ett tröskelvärde för likhetspoäng på 0,05. Cachelagrade värden partitioneras av anroparens prenumerations-ID.

Kommentar

Den hastighetsbegränsningsprincip som lagts till efter cachesökningen hjälper till att begränsa antalet anrop för att förhindra överlagring på serverdelstjänsten om cachen inte är tillgänglig.

<policies>
    <inbound>
        <base />
        <llm-semantic-cache-lookup
            score-threshold="0.05"
            embeddings-backend-id ="llm-backend"
            embeddings-backend-auth ="system-assigned" >
            <vary-by>@(context.Subscription.Id)</vary-by>
        </llm-semantic-cache-lookup>
        <rate-limit calls="10" renewal-period="60" />
    </inbound>
    <outbound>
        <llm-semantic-cache-store duration="60" />
        <base />
    </outbound>
</policies>

Relaterat innehåll

Mer information om hur du arbetar med principer finns i: