Améliorer les invites en utilisant le contexte des bases de données

8 minutes

La récupération vous donne accès aux données. Mais un blob JSON à lui seul ne répond à la question de personne. Si un client vous demande la compatibilité des pédales de vélo, vous disposez des informations sur le produit de votre base de données, mais vous devez maintenant indiquer au modèle de langage ce qu’il faut faire avec elle. Cette étape représente le « A » dans RAG : augmentation.

Comprendre la structure des messages de conversation

Différents modèles ont des API différentes, mais la plupart des modèles basés sur la conversation suivent un modèle similaire. Nous utilisons Azure OpenAI comme exemple, mais les concepts s’appliquent largement.

Les modèles de conversation Azure OpenAI attendent des messages avec des rôles. Le rôle système définit le comportement de l’Assistant. Le rôle d’utilisateur contient la question d’origine et le contexte de base de données dans lequel le modèle doit baser sa réponse. Si vous le souhaitez, un rôle Assistant peut stocker des réponses précédentes dans une conversation à plusieurs tours. Voici un exemple simplifié de structure d’invite :

{
  "messages": [
    {
      "role": "system",
      "content": "You are a helpful assistant that answers questions about products. Use only the provided context to answer. If the context doesn't contain enough information, say so."
    },
    {
      "role": "user", 
      "content": "Context: {retrieved_data}\n\nQuestion: {user_question}"
    }
  ]
}

Dans cet exemple, {retrieved_data} serait le JSON que vous avez créé à partir de votre requête de produit et {user_question} serait quelque chose comme « Quelles pédales sont compatibles avec mountain-500 ? »

Le message système définit les règles de base. Le message utilisateur combine votre contexte de base de données avec la question réelle.

Construire des invites en T-SQL

Vous pouvez générer ce JSON dans votre code d’application, mais il est souvent pratique de le conserver dans la base de données. Votre requête de récupération, votre mise en forme de contexte et votre construction d’invite se combinent, et les fonctions T-SQL JSON_OBJECT et JSON_ARRAY gèrent la mise en forme JSON.

DECLARE @userQuestion NVARCHAR(1000) = 'Which pedals are compatible with the Mountain-500?';

-- @context contains retrieved product data as JSON from the retrieval step

DECLARE @systemMessage NVARCHAR(MAX) = 'You are a customer service assistant for Adventure Works. Answer questions using only the provided product information. Be concise and helpful.';

DECLARE @userMessage NVARCHAR(MAX) = 'Product information: ' + @context + CHAR(10) + CHAR(10) + 'Customer question: ' + @userQuestion;

DECLARE @payload NVARCHAR(MAX) = JSON_OBJECT(
    'messages': JSON_ARRAY(
        JSON_OBJECT('role': 'system', 'content': @systemMessage),
        JSON_OBJECT('role': 'user', 'content': @userMessage)
    ),
    'max_tokens': 500,
    'temperature': 0.7
);

La @payload variable contient maintenant un corps de requête complet prêt pour l’API Azure OpenAI.

Baser le modèle dans vos données

Grounding indique au modèle d’utiliser vos données comme source de vérité. Sans cela, le modèle peut s’appuyer sur ses données d’apprentissage, qui peuvent être obsolètes ou incorrectes pour votre domaine. Un client qui demande des garanties de vélo Adventure Works ne doit pas obtenir d’informations de garantie générique à partir d’Internet.

De bonnes instructions de base définissent l’étendue (« utiliser uniquement les données de produit fournies »), encouragez l’honnêteté (« si vous n’avez pas suffisamment d’informations, dites-le »), et pouvez spécifier le format (« conserver les réponses sous 100 mots »). Voici un exemple pour le rôle système :

DECLARE @systemMessage NVARCHAR(MAX) = 
'You are an Adventure Works product expert. Follow these rules:
1. Answer only using the product information provided
2. Do not invent features or specifications
3. If information is missing, tell the customer you''ll need to check
4. Keep responses under 100 words
5. Suggest related products when relevant';

Ces instructions aident le modèle à rester concentré et à fournir des réponses utiles et précises.

Comportement du modèle de contrôle

La charge utile de la requête comprend quelques paramètres qui affectent la façon dont le modèle génère des réponses :

max_tokens limite la longueur de réponse. Pour obtenir des réponses détaillées sur les produits, 500 à 1 000 fonctionnent bien.
temperature contrôle la créativité sur une échelle comprise entre 0 et 2. Les valeurs inférieures (0,3 à 0,5) produisent des réponses plus cohérentes et factuelles. Les valeurs plus élevées permettent au modèle d’être plus créatif, ce que vous ne souhaitez généralement pas pour RAG.

Le contrôle des jetons et de la température permet de s’assurer que le modèle se comporte de façon prévisible lorsqu’il est ancré dans vos données.

Construire la charge utile complète

Voici comment créer une invite RAG pour une question de produit à l’aide de tables Adventure Works :

DECLARE @userQuestion NVARCHAR(1000) = 'Which pedals are compatible with the Mountain-500?';
DECLARE @questionVector VECTOR(1536);
DECLARE @context NVARCHAR(MAX);
DECLARE @payload NVARCHAR(MAX);

-- Generate embedding for the question
SELECT @questionVector = AI_GENERATE_EMBEDDINGS(@userQuestion USE MODEL my_embedding_model);

-- Get product context using vector search
SET @context = (
    SELECT TOP 3
        p.Name AS ProductName,
        p.Color,
        p.Size,
        pc.Name AS Category,
        pm.Name AS Model
    FROM Production.Product p
    INNER JOIN Production.ProductSubcategory ps ON p.ProductSubcategoryID = ps.ProductSubcategoryID
    INNER JOIN Production.ProductCategory pc ON ps.ProductCategoryID = pc.ProductCategoryID
    INNER JOIN Production.ProductModel pm ON p.ProductModelID = pm.ProductModelID
    ORDER BY VECTOR_DISTANCE('cosine', p.DescriptionVector, @questionVector)
    FOR JSON PATH
);

-- Build the prompt
SET @payload = JSON_OBJECT(
    'messages': JSON_ARRAY(
        JSON_OBJECT(
            'role': 'system', 
            'content': 'You are an Adventure Works product assistant. Use only the provided product data to answer questions.'
        ),
        JSON_OBJECT(
            'role': 'user', 
            'content': 'Product data: ' + @context + CHAR(10) + 'Question: ' + @userQuestion
        )
    ),
    'max_tokens': 500,
    'temperature': 0.5
);

La @payload variable contient désormais tout ce dont le modèle a besoin : vos instructions de base, les données de produit récupérées et la question du client. Il vous suffit de l’envoyer au point de terminaison du modèle et de gérer la réponse.

Points clés à prendre

C’est au niveau de la requête que la récupération prend toute son utilité. Votre contexte JSON ne signifie rien, sauf si vous indiquez au modèle comment l’utiliser. Définissez des règles de base claires dans le message système afin que le modèle reste fidèle à vos données. Maintenez la température basse pour les réponses factuelles. Utilisez JSON_OBJECT et JSON_ARRAY pour créer des charges utiles JSON valides directement dans T-SQL.

Commentaires

Cette page a-t-elle été utile ?