Partager via

Obtenir les réponses mises en cache des demandes d’API de modèle de langage volumineux

S’APPLIQUE À : Tous les niveaux de Gestion des API

Utilisez la stratégie pour effectuer la recherche de cache des réponses aux requêtes d’API de modèle de langage volumineux (LLM) à partir d’un cache externe configuré, en fonction de la llm-semantic-cache-lookup proximité vectorielle de l’invite aux requêtes précédentes et d’un seuil de score spécifié. La mise en cache de la réponse réduit les besoins en bande passante et en calcul imposés par l’API LLM principal et limite la latence perçue par les consommateurs de l’API.

Remarque

Remarque

Définissez les éléments enfants et de stratégie dans l’ordre fourni dans l’instruction de stratégie. En savoir plus sur comment définir ou modifier des stratégies du service Gestion des API.

Modèles pris en charge

Utilisez la stratégie avec les API LLM ajoutées à Gestion des API Azure qui sont disponibles via l’API d’inférence du modèle Azure AI ou avec des modèles compatibles OpenAI pris en charge par le biais de fournisseurs d’inférence tiers.

Instruction de la stratégie

<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>

Attributs

Attribut Descriptif Obligatoire Par défaut
seuil de score Le seuil de score définit la manière dont une invite entrante doit correspondre à une invite mise en cache pour retourner sa réponse stockée. La valeur est comprise entre 0,0 et 1,0. Les valeurs inférieures nécessitent une similarité sémantique plus élevée pour une correspondance. Plus d’informations Oui S/O
embeddings-backend-id Back-end ID pour l’appel d’API d’incorporation. Oui S/O
embeddings-backend-auth Authentification utilisée pour l’incorporation du serveur principal de l’API. Oui. Cette propriété doit être définie sur system-assigned. S/O
ignore-system-messages Booléenne. Lorsqu’il est défini true sur (recommandé), supprime les messages système d’une invite de saisie semi-automatique de conversation avant d’évaluer la similarité du cache. Non faux
max-message-count Si spécifié, nombre de messages de dialogue restants une fois la mise en cache ignorée. Non S/O

Éléments

Nom Descriptif Obligatoire
varient par Expression personnalisée déterminée au moment du runtime dont la valeur partitionne la mise en cache. Si plusieurs éléments vary-by sont ajoutés, les valeurs sont concaténées pour créer une combinaison unique. Non

Utilisation

Notes d’utilisation

  • Cette stratégie ne peut être employée qu’une seule fois dans une section stratégie.
  • Ajustez la valeur de score-threshold votre application pour vous assurer que la sensibilité appropriée est utilisée pour déterminer quand retourner des réponses mises en cache pour les requêtes. Commencez par une valeur faible telle que 0,05 et ajustez pour optimiser le ratio d’accès au cache aux absences.
  • Le seuil de score supérieur à 0,2 peut entraîner une incompatibilité de cache. Envisagez d’utiliser une valeur inférieure pour les cas d’usage sensibles.
  • Contrôlez l’accès inter-utilisateurs aux entrées du cache en spécifiant vary-by avec des identificateurs d’utilisateur ou de groupe d’utilisateurs spécifiques.
  • Le modèle d’incorporation doit avoir suffisamment de capacité et une taille de contexte suffisante pour prendre en charge le volume et les invites d’invite.
  • Envisagez d’ajouter la stratégie llm-content-safety avec un bouclier d’invite pour protéger contre les attaques d’invite.
  • Nous vous recommandons de configurer une stratégie de limite de débit (ou une stratégie de limite de débit par clé ) immédiatement après toute recherche de cache. Cela permet à votre service principal d’être surchargé si le cache n’est pas disponible.

Exemples

Exemple avec une stratégie llm-semantic-cache-store correspondante

L’exemple suivant montre comment utiliser la llm-semantic-cache-lookup stratégie avec la llm-semantic-cache-store stratégie pour récupérer des réponses mises en cache sémantiquement similaires avec un seuil de score de similarité de 0,05. Les valeurs mises en cache sont partitionnée par l’ID d’abonnement de l’appelant.

Remarque

Ajoutez une stratégie de limite de débit (ou une stratégie de limite de débit par clé ) après la recherche du cache pour limiter le nombre d’appels et empêcher la surcharge sur le service principal si le cache n’est pas disponible.

<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>

Contenu connexe

Pour plus d’informations sur l’utilisation des stratégies, consultez :

  • Last updated on