Dela via

Hämta cachelagrade svar på Azure OpenAI API-begäranden

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

azure-openai-semantic-cache-lookup Använd principen för att utföra cachesökning av svar på API-begäranden om slutförande av Azure OpenAI-chatt från en konfigurerad extern cache, baserat på vektornärheten mellan uppmaningen och tidigare begäranden och ett angivet tröskelvärde för likhetspoäng. Cachelagring av svar minskar bandbredds- och bearbetningskrav som ställs på serverdelens Azure OpenAI API 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.

Azure OpenAI stöds i Azure AI Foundry-modeller

Principen används med API:er som lagts till i API Management från Azure OpenAI i AI Foundry-modeller av följande typer:

API-typ Modeller som stöds
Chatten har slutförts gpt-3.5

gpt-4

gpt-4o

gpt-4o-mini

o1

o3
Inbäddningar text-embedding-3-large

text-embedding-3-small

text-embedding-ada-002
Svar (förhandsversion) gpt-4o (Versioner: 2024-11-20, 2024-08-06, 2024-05-13)

gpt-4o-mini (Version: 2024-07-18)

gpt-4.1 (Version: 2025-04-14)

gpt-4.1-nano (Version: 2025-04-14)

gpt-4.1-mini (Version: 2025-04-14)

gpt-image-1 (Version: 2025-04-15)

o3 (Version: 2025-04-16)

o4-mini (Version: '2025-04-16)

Kommentar

API:er för traditionell slutförande är endast tillgängliga med äldre modellversioner och stödet är begränsat.

Aktuell information om modellerna och deras funktioner finns i Azure OpenAI i Foundry Models.

Principuttryck

<azure-openai-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>
</azure-openai-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 princip för azure-openai-semantic-cache-store

I följande exempel visas hur du använder azure-openai-semantic-cache-lookup principen tillsammans med azure-openai-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 />
        <azure-openai-semantic-cache-lookup
            score-threshold="0.05"
            embeddings-backend-id ="azure-openai-backend"
            embeddings-backend-auth ="system-assigned" >
            <vary-by>@(context.Subscription.Id)</vary-by>
        </azure-openai-semantic-cache-lookup>
        <rate-limit calls="10" renewal-period="60" />
    </inbound>
    <outbound>
        <azure-openai-semantic-cache-store duration="60" />
        <base />
    </outbound>
</policies>

Relaterat innehåll

Mer information om hur du arbetar med principer finns i: