ktg-plugin-marketplace/plugins/ms-ai-architect/skills/ms-ai-security/references/cost-optimization/semantic-caching-patterns.md
Kjell Tore Guttormsen 6a7632146e feat(ms-ai-architect): add plugin to open marketplace (v1.5.0 baseline)
Initial addition of ms-ai-architect plugin to the open-source marketplace.
Private content excluded: orchestrator/ (Linear tooling), docs/utredning/
(client investigation), generated test reports and PDF export script.
skill-gen tooling moved from orchestrator/ to scripts/skill-gen/.

Security scan: WARNING (risk 20/100) — no secrets, no injection found.
False positive fixed: added gitleaks:allow to Python variable reference
in output-validation-grounding-verification.md line 109.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-04-07 17:17:17 +02:00

23 KiB

Semantic Caching for AI Workloads

Last updated: 2026-02 Status: GA Category: Cost Optimization & FinOps for AI


Introduksjon

Semantic caching er en teknikk som reduserer kostnader og latens for LLM-baserte applikasjoner ved å cache og gjenbruke svar basert på semantisk likhet mellom prompts — ikke kun eksakte tekstmatch. Dette er spesielt verdifullt i AI-workloads der samme eller lignende spørsmål stilles flere ganger.

Nøkkelverdi:

  • Kostnadsreduksjon: 40-70% reduksjon i token-forbruk for typiske applikasjoner (HIGH confidence)
  • Latensreduksjon: 80-95% raskere responstider for cached requests (HIGH confidence)
  • Skalerbarhet: Reduserer backend-belastning og muliggjør høyere throughput

Når bruke semantic caching:

  • Chatbots med repeterende spørsmål
  • RAG-applikasjoner med overlappende queries
  • Dokumentanalyse med lignende forespørsler
  • Customer support med standard svar

Når IKKE bruke semantic caching:

  • Real-time data som må være oppdatert (aksjekurser, vær)
  • Personaliserte svar basert på brukerhistorikk
  • Sikkerhetsavgjørelser som krever ny evaluering
  • Applikasjoner med ekstremt lave cache hit rates (<10%)

Kjernekomponenter

Semantic caching består av fire hovedkomponenter:

Komponent Rolle Azure-implementering
Embeddings Model Konverterer prompts til vektorer Azure OpenAI Embeddings API (text-embedding-3-large, text-embedding-ada-002)
Vector Database Lagrer embeddings og utfører similarity search Azure Managed Redis (RediSearch), Azure Cache for Redis Enterprise, Azure AI Search
Gateway/Proxy Orkestrerer cache lookup og LLM calls Azure API Management, custom application logic
LLM Backend Genererer completions ved cache miss Azure OpenAI, Azure AI Foundry models

Slik fungerer semantic caching

1. User prompt → Embedding Model → Vector [0.23, -0.45, 0.67, ...]
2. Vector → Vector Database → Similarity Search (cosine/euclidean)
3. IF similarity score > threshold:
     RETURN cached completion
   ELSE:
     Call LLM → Generate completion → Store in cache

Similarity metrics

Metric Når bruke Azure Redis støtte
Cosine similarity Standard for tekstlikhet, uavhengig av vektor-magnitude COSINE
Euclidean distance Når absolutt avstand mellom punkter er viktig L2
Inner product Rask beregning, forutsetter normaliserte vektorer IP

Score threshold best practices:

  • 0.95+ (cosine): Svært streng matching, nesten identiske prompts
  • 0.85-0.94: Balanced — standard anbefaling for de fleste use cases
  • 0.70-0.84: Liberal matching, høyere cache hit rate men lavere presisjon
  • Start med 0.85 og juster basert på cache hit rate og user feedback (MEDIUM confidence)

Arkitekturmønstre

Mønster 1: API Management + Managed Redis (anbefalt for enterprise)

Arkitektur:

Client → APIM (semantic cache policies) → Azure Managed Redis (RediSearch) → Azure OpenAI
                ↓ (on cache miss)
         Azure OpenAI Embeddings API

Komponenter:

  • Azure API Management (alle tiers støttet)
  • Azure Managed Redis med RediSearch-modul (REQUIRED)
  • Azure OpenAI med Chat Completion + Embeddings deployments

Implementering:

<!-- Inbound: Cache Lookup -->
<azure-openai-semantic-cache-lookup
    score-threshold="0.85"
    embeddings-backend-id="embeddings-backend"
    embeddings-backend-auth="system-assigned"
    ignore-system-messages="true"
    max-message-count="10">
    <vary-by>@(context.Subscription.Id)</vary-by>
</azure-openai-semantic-cache-lookup>
<rate-limit calls="10" renewal-period="60" />

<!-- Outbound: Cache Store -->
<azure-openai-semantic-cache-store duration="3600" />

Fordeler:

  • Zero-code løsning med APIM policies
  • Managed identity auth til Azure OpenAI
  • Built-in rate limiting og monitoring
  • Multi-tenant support via vary-by (subscription, header, claim)

Ulemper:

  • APIM koster ekstra (fra ~4 000 NOK/måned for Basic v2)
  • RediSearch må enablees ved opprettelse av Redis cache (kan ikke legges til senere)

Kostnadsestimat (SMB scenario, 100K requests/måned):

  • APIM Basic v2: ~4 000 NOK/måned
  • Azure Managed Redis (Memory Optimized 1GB): ~2 800 NOK/måned
  • Azure OpenAI Embeddings (text-embedding-3-small, 20M tokens): ~160 NOK
  • Total: ~7 000 NOK/måned (MEDIUM confidence)

Mønster 2: Application-level caching (Python/C#/.NET)

Arkitektur:

Application Code
  ↓
[Semantic Kernel / LangChain / Custom Logic]
  ↓
Azure Cache for Redis Enterprise (vector store)
  ↓ (on cache miss)
Azure OpenAI (Embeddings + Chat)

Implementering (Python med Redis OM):

from redis_om import get_redis_connection, EmbeddedJsonModel
from openai import AzureOpenAI
import numpy as np

# Redis connection med RediSearch
redis = get_redis_connection(
    host="your-redis.redis.cache.windows.net",
    port=6380,
    password="key",
    ssl=True
)

# Semantic cache lookup
def get_cached_completion(prompt: str, threshold: float = 0.85):
    # 1. Generate embedding for prompt
    embedding = client.embeddings.create(
        model="text-embedding-3-large",
        input=prompt
    ).data[0].embedding

    # 2. Vector similarity search in Redis
    results = redis.ft("cache_idx").search(
        Query(f"*=>[KNN 1 @embedding $vec AS score]")
        .return_fields("completion", "score")
        .sort_by("score")
        .paging(0, 1)
        .dialect(2),
        query_params={"vec": np.array(embedding, dtype=np.float32).tobytes()}
    )

    # 3. Return cached if similarity > threshold
    if results.docs and float(results.docs[0].score) >= threshold:
        return results.docs[0].completion

    # 4. Call LLM and cache result
    completion = call_llm(prompt)
    cache_completion(prompt, embedding, completion)
    return completion

Fordeler:

  • Full kontroll over caching-logikk
  • Kan bruke i eksisterende applikasjoner
  • Støtte for hybrid search (metadata filtering)
  • Framework-integrasjoner (Semantic Kernel, LangChain, LlamaIndex)

Ulemper:

  • Krever custom kode og testing
  • Må håndtere cache invalidation selv
  • Mindre out-of-the-box observability

Mønster 3: Azure AI Search som vector database

Arkitektur:

Application → Azure AI Search (vector index) → Azure OpenAI

Når bruke:

  • Hybrid search er kritisk (combining vector + keyword + filters)
  • Eksisterende Azure AI Search deployment
  • Behov for advanced query capabilities (facets, synonyms, scoring profiles)

Fordeler:

  • Kraftige hybrid search-kapabiliteter
  • Built-in semantic ranker
  • Integrert med Azure AI Studio

Ulemper:

  • Dyrere enn Redis for kun vector search (fra ~2 500 NOK/måned for Basic)
  • Høyere latens enn in-memory Redis (~50-100ms vs ~5-10ms)

Mønster 4: Multi-tier caching (advanced)

Arkitektur:

L1: In-memory cache (exact match) → 1-2ms latency
  ↓ (miss)
L2: Redis semantic cache → 5-10ms latency
  ↓ (miss)
L3: Azure OpenAI → 500-2000ms latency

Implementering:

  • L1: .NET IMemoryCache / Python functools.lru_cache (exact string match)
  • L2: Redis semantic cache (vector similarity)
  • L3: Azure OpenAI

Når bruke:

  • Ultra-high throughput scenarios (>10K RPS)
  • Microsecond-level latency requirements
  • Samme exakte prompts repeteres ofte

Beslutningsveiledning

Velge vector database

Krav Anbefaling Begrunnelse
Lavest mulig latens (<10ms) Azure Managed Redis In-memory, optimalisert for speed
Hybrid search (vector + keyword + filters) Azure AI Search Best-in-class hybrid search
Eksisterende Redis-infrastruktur Azure Cache for Redis Enterprise Leverage existing investment
Multi-purpose (cache + vector + session) Azure Managed Redis Consolidate på én tjeneste
Budget-constraints Azure Managed Redis Laveste kostnad for vector search

Velge embeddings model

Model Dimensioner Kostnad (per 1M tokens) Når bruke
text-embedding-3-small 1536 ~16 NOK Cost-optimized, god nok for de fleste use cases
text-embedding-3-large 3072 ~104 NOK Highest accuracy, kritiske applikasjoner
text-embedding-ada-002 1536 ~80 NOK Legacy, unngå for nye prosjekter

Anbefaling: Start med text-embedding-3-small. Oppgrader til large kun hvis A/B-testing viser signifikant forbedring i cache hit rate eller user satisfaction. (HIGH confidence)

Cache invalidation strategies

Strategi Implementering Når bruke
Time-based (TTL) duration="3600" (1 time) i APIM policy Standard for de fleste use cases
Event-driven Purge cache on data updates (webhook/Event Grid) Real-time data sources
Version-based Include data version in cache key Document versioning, A/B testing
Manual purge Admin endpoint for cache clear Incident response, data corrections

Best practice TTL values:

  • Chatbot FAQ: 24 timer (data endres sjelden)
  • RAG over documents: 1-6 timer (balanse mellom freshness og cache hits)
  • Product recommendations: 30 minutter (inventory changes)
  • Real-time analytics: IKKE bruk caching

Integrasjon med Microsoft-stakken

Azure API Management integrasjon

Setup-prosess:

  1. Opprett Azure Managed Redis med RediSearch:

    az redis create \
      --name myredis \
      --resource-group myrg \
      --location norwayeast \
      --sku Enterprise_E10 \
      --redis-module RediSearch
    

    ⚠️ KRITISK: RediSearch kan KUN enablees ved opprettelse. Kan ikke legges til senere.

  2. Konfigurer Redis som external cache i APIM:

    • Portal: APIM → External cache → Add
    • Connection string: Redis primary connection string
    • Test connection
  3. Opprett backend for embeddings API:

    <backend>
      <id>embeddings-backend</id>
      <url>https://myopenai.openai.azure.com/openai/deployments/embeddings/embeddings</url>
      <credentials>
        <authentication-managed-identity resource="https://cognitiveservices.azure.com/" />
      </credentials>
    </backend>
    
  4. Apply semantic cache policies (se XML eksempel i Mønster 1)

Policy parameters explained:

Parameter Verdi Forklaring
score-threshold 0.85 (anbefalt) Minimum similarity for cache hit (0-1)
embeddings-backend-id "embeddings-backend" Backend ID for embeddings deployment
embeddings-backend-auth "system-assigned" Bruker APIM managed identity
ignore-system-messages true Ignorer system messages i similarity-beregning
max-message-count 10 Max conversation history messages å inkludere
vary-by @(context.Subscription.Id) Partition cache per subscription (multi-tenancy)
duration 3600 (sekunder) Cache TTL

Semantic Kernel integrasjon

using Microsoft.SemanticKernel;
using Microsoft.SemanticKernel.Memory;
using StackExchange.Redis;

// Redis vector store
var redis = ConnectionMultiplexer.Connect("myredis.redis.cache.windows.net:6380,ssl=true");
var memoryStore = new RedisMemoryStore(redis, vectorSize: 1536);

// Semantic Kernel with memory
var kernel = Kernel.CreateBuilder()
    .AddAzureOpenAIChatCompletion("gpt-4", endpoint, apiKey)
    .AddAzureOpenAITextEmbeddingGeneration("text-embedding-3-small", endpoint, apiKey)
    .Build();

var memory = new SemanticTextMemory(memoryStore, kernel.GetService<ITextEmbeddingGeneration>());

// Semantic cache pattern
var query = "What is Azure Functions?";
var cachedResults = await memory.SearchAsync("cache", query, limit: 1, minRelevanceScore: 0.85);

if (cachedResults.Any())
{
    return cachedResults.First().Metadata.Text; // Cache hit
}
else
{
    var response = await kernel.InvokePromptAsync(query); // Cache miss
    await memory.SaveInformationAsync("cache", response.ToString(), query);
    return response.ToString();
}

LangChain integrasjon (Python)

from langchain.cache import RedisSemanticCache
from langchain.embeddings import AzureOpenAIEmbeddings
from langchain.chat_models import AzureChatOpenAI
from langchain.globals import set_llm_cache

# Setup semantic cache
embeddings = AzureOpenAIEmbeddings(
    model="text-embedding-3-small",
    azure_endpoint=os.getenv("AZURE_OPENAI_ENDPOINT"),
    api_key=os.getenv("AZURE_OPENAI_API_KEY")
)

set_llm_cache(
    RedisSemanticCache(
        redis_url="redis://myredis.redis.cache.windows.net:6380?ssl=true",
        embeddings=embeddings,
        score_threshold=0.85
    )
)

# Use LLM — caching happens automatically
llm = AzureChatOpenAI(model="gpt-4", temperature=0)
response = llm.predict("What is Azure Functions?")  # Cache miss → LLM call
response2 = llm.predict("Tell me about Azure Functions")  # Cache hit (semantic match)

Azure AI Foundry integrasjon

Azure AI Foundry models (via Model Inference API) støttes med generic LLM policies i APIM:

<!-- Use llm-semantic-cache-lookup instead of azure-openai-semantic-cache-lookup -->
<llm-semantic-cache-lookup
    score-threshold="0.85"
    embeddings-backend-id="embeddings-backend"
    embeddings-backend-auth="system-assigned">
    <vary-by>@(context.Subscription.Id)</vary-by>
</llm-semantic-cache-lookup>

<llm-semantic-cache-store duration="3600" />

Offentlig sektor (Norge)

Datahåndtering og personvern

Vurdering Anbefaling
PII i prompts Anonymiser/pseudonymiser FØR caching. Cache keys må ikke inneholde PII.
GDPR "right to be forgotten" Implementer purge-mekanisme for brukerdata. Tag cache entries med user ID for targeted deletion.
Data residency Bruk Norway East/West for Redis og OpenAI for å sikre data forblir i Norge/EU.
Audit logging Enable APIM diagnostics og Redis slow log for compliance.

Sikkerhetsoverveielser

Område Implementering
Encryption at rest Azure Managed Redis har default encryption
Encryption in transit Krev TLS 1.2+ (APIM policy + Redis SSL)
Access control APIM subscription keys + Azure RBAC på Redis
Network isolation ⚠️ Vurder Private Endpoints for Redis og OpenAI (klassifisert data)
Cache poisoning Validate LLM responses før caching (content safety checks)

Compliance checkliste

  • Schrems II: Azure OpenAI i EU-region (Norway East)
  • NIS2: Incident response plan for cache failures
  • eForvaltningsforskriften: Tilgjengelighetskrav (caching må ikke blokkere a11y)
  • Arkivloven: Cached data er IKKE arkivverdig kopi

Kostnad og lisensiering

Kostnadsmodell

Semantic caching påvirker disse kostnadene:

Kostnadselement Uten caching Med caching (70% hit rate) Besparelse
Azure OpenAI tokens (100M/måned) ~80 000 NOK ~24 000 NOK ~56 000 NOK/måned
Azure Managed Redis (Memory Optimized 10GB) 0 NOK ~14 000 NOK/måned -14 000 NOK
Embeddings API (20M tokens) 0 NOK ~160 NOK/måned -160 NOK
Netto besparelse - - ~41 840 NOK/måned

Estimater basert på GPT-4 ($30/1M tokens input) og text-embedding-3-small ($0.02/1M tokens). MEDIUM confidence.

ROI break-even analyse

Når lønner semantic caching seg?

Monthly LLM cost > (Redis cost + Embeddings cost) / Cache hit rate

Eksempel:
80 000 NOK > (14 000 + 160) / 0.70
80 000 NOK > 20 229 NOK ✅ Lønner seg

Tommelfingerregel:

  • Semantic caching lønner seg når LLM-kostnad > 25 000 NOK/måned OG forventet cache hit rate > 40% (MEDIUM confidence)

Azure Managed Redis pricing (Norway East, jan 2026)

Tier Memory Pris/måned (ca.) Når bruke
Memory Optimized 1GB 1 GB ~2 800 NOK POC, small apps (<50K cached prompts)
Memory Optimized 10GB 10 GB ~14 000 NOK Production, medium apps (<500K cached prompts)
Memory Optimized 50GB 50 GB ~56 000 NOK Enterprise, large apps (>1M cached prompts)
Compute Optimized (alternative) Varies ~20% billigere Mindre memory, mer CPU (hybrid search)

Priser er estimater og varierer. Sjekk Azure Pricing Calculator for nøyaktige priser. LOW confidence.

Lisensering

Komponent Lisensiering Merknad
Azure OpenAI Pay-per-token (PTU eller Consumption) Ingen ekstra lisenser for caching
Azure API Management Per tier (Basic v2+) Inkluderer semantic cache policies
Azure Managed Redis Pay-per-hour per tier RediSearch inkludert (Enterprise tier)
Semantic Kernel / LangChain Open source (MIT) Gratis å bruke

For arkitekten (Cosmo)

Når anbefale semantic caching

ANBEFAL når:

  • LLM-kostnader > 25 000 NOK/månd og forventet cache hit rate > 40%
  • Repeterende spørsmål (chatbot, FAQ, support)
  • Latenskrav < 200ms (semantic cache gir 5-10ms, LLM 500-2000ms)
  • RAG-applikasjoner med overlappende queries
  • Budget constraints kombinert med høyt volum

⚠️ ADVARER når:

  • Real-time data som endrer seg hyppig
  • PII-sensitive prompts uten anonymisering
  • Svært lave forventede cache hit rates (<20%)
  • Kritiske beslutninger som ALLTID må reevalueres (safety, security)

IKKE ANBEFAL når:

  • LLM-kostnader < 10 000 NOK/månd (overhead ikke verdt det)
  • Ekstremt personaliserte svar (hver prompt er unik)
  • Latens ikke er bekymring (batch processing)
  • Team mangler kompetanse på vector databases

Diskusjonsspørsmål til kunden

  1. "Hvor mange LLM-requests får dere per dag/uke? Hvor mange av disse er semantisk like?"

    • Estimerer cache hit rate og ROI
  2. "Hva er den typiske responsetiden fra LLM i dag? Hva er målsetningen?"

    • Kvantifiserer latensgevinst
  3. "Inneholder prompts personopplysninger? Hvordan håndteres disse i dag?"

    • Identifiserer GDPR-risiko
  4. "Har dere eksisterende Redis-infrastruktur? Hvilken tier?"

    • Vurderer om upgrade til Enterprise eller ny Managed Redis
  5. "Hvor kritisk er data freshness? Hvor gammel data er akseptabel?"

    • Definerer TTL-strategi
  6. "Bruker dere allerede APIM eller planlegger det?"

    • Velger mellom APIM-mønster vs application-level

Implementeringsrekkefølge (anbefalt)

Fase 1: POC (1-2 uker)

  1. Deploy Azure Managed Redis Memory Optimized 1GB med RediSearch
  2. Setup APIM semantic cache policies (eller Python/C# prototype)
  3. Test med representative prompts
  4. Måle cache hit rate og latens
  5. Go/No-go beslutning basert på metrics

Fase 2: Pilot (2-4 uker)

  1. Deploy production-size Redis (10GB+)
  2. Implementere logging og monitoring (Application Insights)
  3. Tune score threshold basert på user feedback
  4. Setup cache invalidation strategy
  5. Load testing

Fase 3: Production (2-3 uker)

  1. Enable for 10% av trafikk (canary)
  2. Monitor cost savings og latens
  3. Gradvis scale til 100%
  4. Document runbook for cache management

Monitoring og KPIer

Kritiske metrics å tracke:

Metric Target Verktøy
Cache hit rate >60% APIM Analytics / custom logging
P50 latency (cache hit) <10ms Application Insights
P50 latency (cache miss) <2000ms Application Insights
Cost savings >30% Azure Cost Management + custom calc
Redis memory usage <80% Azure Monitor
Embeddings API throttling 0 errors APIM / OpenAI metrics

Alert rules:

  • Cache hit rate drop >20% (indicates data drift or threshold misconfiguration)
  • Redis memory >90% (risk of eviction)
  • Embeddings API 429 errors (need rate limit increase)

Trade-offs og risiko

Trade-off Beskrivelse Mitigering
Staleness risk Cached svar kan være utdatert Tune TTL, event-driven invalidation
Cache poisoning Malicious/incorrect completions cached Validate responses, content safety checks
Cold start Første requests etter deploy er cache misses Pre-warm cache med common queries
Over-caching Caching too liberally (high threshold) → wrong answers Start conservative (0.85), A/B test
Complexity Ekstra moving parts (Redis, embeddings) Good monitoring, runbooks

Alternative approaches (når semantic caching ikke passer)

Scenario Alternativ Hvorfor
Lav repetisjon Prompt optimization + cheaper model Reduser token count, bruk GPT-3.5 vs GPT-4
Real-time data RAG med live data sources Cache documents, ikke LLM responses
Batch processing Async batch API (50% discount) Latens ikke kritisk
Personalisert User-specific fine-tuning Hver bruker har unique behavior

Kilder og verifisering

Microsoft dokumentasjon (HIGH confidence):

Code samples (HIGH confidence):

Pricing references (MEDIUM confidence):

Framework integrations:

Confidence levels:

  • HIGH: Direkte verifisert i Microsoft Learn (feb 2026)
  • MEDIUM: Estimater basert på gjeldende priser (kan endre seg)
  • LOW: Generelle anbefalinger basert på best practices (ikke Microsoft-spesifikke)

Generert av: Cosmo Skyberg, Microsoft AI Solution Architect MCP research dato: 2026-02-04 Neste review: 2026-05 (ved nye Redis-features eller OpenAI pricing changes)