Cortex Search¶

Vue d’ensemble¶

Cortex Search permet une recherche « floue » à faible latence et de haute qualité sur vos données Snowflake. Cortex Search propose un large éventail d’expériences de recherche pour les utilisateurs de Snowflake, notamment les applications de génération augmentée par récupération (RAG) exploitant des Large Language Models (LLMs).

Cortex Search vous permet de démarrer avec un moteur de recherche hybride (vecteur et mot-clé) sur vos données textuelles en quelques minutes, sans avoir à vous soucier de l’intégration, de la maintenance de l’infrastructure, du réglage des paramètres de qualité de recherche ou des actualisations continues de l’index. Cela signifie que vous pouvez consacrer moins de temps au réglage de l’infrastructure et de la qualité de la recherche, et plus de temps au développement d’expériences de chat et de recherche de haute qualité en utilisant vos données. Découvrez les Tutoriels Cortex Search pour des instructions étape par étape sur l’utilisation de Cortex Search pour alimenter des applications de chat et de recherche AI.

Quand utiliser Cortex Search¶

Les deux principaux cas d’utilisation de Cortex Search sont la génération augmentée par récupération (RAG) et la recherche en entreprise.

• Moteur RAG pour les chatbots LLM : utilisez Cortex Search comme moteur RAG pour applications de chat avec vos données textuelles en exploitant la recherche sémantique pour des réponses personnalisées et contextualisées.

• Recherche en entreprise : utilisez Cortex Search comme backend pour une barre de recherche de haute qualité intégrée à votre application.

Cortex Search pour RAG¶

La génération augmentée par récupération (RAG) est une technique permettant de récupérer des données à partir d’une base de connaissances afin d’améliorer la réponse générée par un grand modèle linguistique. Le diagramme d’architecture suivant montre comment vous pouvez combiner Cortex Search avec les Fonctions LLM Cortex pour créer des chatbots d’entreprise avec RAG en utilisant vos données Snowflake comme base de connaissances.

Cortex Search est le moteur de recherche qui fournit au modèle de langage étendu le contexte dont il a besoin pour renvoyer des réponses basées sur vos données propriétaires les plus récentes.

Exemple¶

Cet exemple vous guide à travers les étapes de création d’un Cortex Search Service et de son interrogation à l’aide de la REST API. Consultez la rubrique Interrogation d’un Cortex Search Service pour plus de détails sur l’interrogation du service.

Cet exemple utilise un exemple d’ensemble de données de transcription de support client.

Exécutez les commandes suivantes pour configurer l’exemple de base de données et le schéma.

CREATE DATABASE IF NOT EXISTS cortex_search_db;

CREATE OR REPLACE WAREHOUSE cortex_search_wh WITH
   WAREHOUSE_SIZE='X-SMALL';

CREATE OR REPLACE SCHEMA cortex_search_db.services;

Exécutez les commandes SQL suivantes pour créer la base de données.

CREATE OR REPLACE TABLE support_transcripts (
    transcript_text VARCHAR,
    region VARCHAR,
    agent_id VARCHAR
);

INSERT INTO support_transcripts VALUES
    ('My internet has been down since yesterday, can you help?', 'North America', 'AG1001'),
    ('I was overcharged for my last bill, need an explanation.', 'Europe', 'AG1002'),
    ('How do I reset my password? The email link is not working.', 'Asia', 'AG1003'),
    ('I received a faulty router, can I get it replaced?', 'North America', 'AG1004');

Le suivi des modifications est nécessaire pour créer le service de recherche cortex. Si vous envisagez d’utiliser un rôle qui n’est pas propriétaire de cette table pour créer le service de recherche, exécutez l’instruction suivante pour activer le suivi des modifications sur la table :

ALTER TABLE support_transcripts SET
  CHANGE_TRACKING = TRUE;

Pour plus de détails sur l’activation du suivi des modifications, consultez Activer le suivi des modifications.

CREATE OR REPLACE CORTEX SEARCH SERVICE transcript_search_service
  ON transcript_text
  ATTRIBUTES region
  WAREHOUSE = cortex_search_wh
  TARGET_LAG = '1 day'
  EMBEDDING_MODEL = 'snowflake-arctic-embed-l-v2.0'
  AS (
    SELECT
        transcript_text,
        region,
        agent_id
    FROM support_transcripts
);

GRANT USAGE ON DATABASE cortex_search_db TO ROLE customer_support;
GRANT USAGE ON SCHEMA services TO ROLE customer_support;

GRANT USAGE ON CORTEX SEARCH SERVICE transcript_search_service TO ROLE customer_support;

SELECT PARSE_JSON(
  SNOWFLAKE.CORTEX.SEARCH_PREVIEW(
      'cortex_search_db.services.transcript_search_service',
      '{
        "query": "internet issues",
        "columns":[
            "transcript_text",
            "region"
        ],
        "filter": {"@eq": {"region": "North America"} },
        "limit":1
      }'
  )
)['results'] as results;

[
  {
  "transcript_text" : "My internet has been down since yesterday, can you help?",
  "region" : "North America"
  }
]

SELECT
  *
FROM
  TABLE (
    CORTEX_SEARCH_DATA_SCAN (
      SERVICE_NAME => 'transcript_search_service'
    )
  );

+ ---------------------------------------------------------- + --------------- + -------- + ------------------------------ +
|                      transcript_text                       |     region      | agent_id | _GENERATED_EMBEDDINGS_MY_MODEL |
| ---------------------------------------------------------- | --------------- | -------- | ------------------------------ |
| 'My internet has been down since yesterday, can you help?' | 'North America' | 'AG1001' | [0.1, 0.2, 0.3, 0.4]           |
| 'I was overcharged for my last bill, need an explanation.' | 'Europe'        | 'AG1002' | [0.1, 0.2, 0.3, 0.4]           |
+ ---------------------------------------------------------- + --------------- + -------- + ------------------------------ +

from snowflake.core import Root
from snowflake.snowpark import Session

CONNECTION_PARAMETERS = {"..."}

session = Session.builder.configs(CONNECTION_PARAMETERS).create()
root = Root(session)

transcript_search_service = (root
  .databases["cortex_search_db"]
  .schemas["services"]
  .cortex_search_services["transcript_search_service"]
)

resp = transcript_search_service.search(
  query="internet issues",
  columns=["transcript_text", "region"],
  filter={"@eq": {"region": "North America"} },
  limit=1
)
print(resp.to_json())

{
  "results": [
    {
      "transcript_text": "My internet has been down since yesterday, can you help?",
      "region": "North America"
    }
  ],
  "request_id": "5d8eaa5a-800c-493c-a561-134c712945ba"
}

Privilèges requis¶

• Pour créer un Cortex Search Service, votre rôle doit avoir le rôle de base de données CORTEX_USER pour les fonctions LLM Cortex. Pour plus d’informations sur l’octroi et la révocation de ce rôle, consultez Privilèges requis pour les fonctions Cortex LLM.

• Pour interroger un Cortex Search Service, le rôle de l’utilisateur effectuant la requête doit disposer des privilèges USAGE sur le service lui-même, ainsi que sur la base de données et le schéma dans lesquels le service réside. Consultez Exigences en matière de contrôle d’accès à Cortex Search.

• Pour suspendre ou reprendre un Cortex Search Service à l’aide de la commande ALTER, le rôle de l’utilisateur qui interroge doit avoir le privilège OPERATE sur le service. Voir ALTER CORTEX SEARCH SERVICE.

Comprendre la qualité de Cortex Search¶

Cortex Search s’appuie sur un ensemble de modèles de récupération et de classement pour vous offrir un niveau élevé de qualité de recherche avec peu ou pas de réglage requis. Sous le capot, Cortex Search adopte une approche « hybride » pour récupérer et classer les documents. Chaque requête de recherche utilise :

• Recherche vectorielle pour récupérer des documents sémantiquement similaires.

• Recherche par mot-clé pour récupérer des documents lexicalement similaires.

• Reclassement sémantique pour reclasser les documents les plus pertinents dans le jeu de résultats.

Cette approche de recherche hybride, couplée à une étape de reclassement sémantique, permet d’obtenir une qualité de recherche élevée sur une large gamme d’ensembles de données et de requêtes.

Limites de jetons et division de texte¶

Pour des résultats de recherche optimaux avec Cortex Search, Snowflake recommande de diviser le texte de votre colonne de recherche en morceaux ne dépassant pas 512 jetons (environ 385 mots anglais). Lorsqu’une entrée dans la colonne de recherche contient plus de 512 jetons, Cortex Search effectue une récupération basée sur des mots-clés sur l’ensemble du corps du texte, mais utilise uniquement les 512 premiers jetons pour la récupération sémantique (c’est-à-dire basée sur des vecteurs).

Un jeton est une séquence de caractères et constitue la plus petite unité de texte pouvant être traitée par un modèle de langage de grande taille. À titre approximatif, un jeton équivaut à environ 3/4 d’un mot anglais, soit environ 4 caractères. Pour calculer le nombre exact de jetons dans une chaîne, vous pouvez utiliser la fonction Cortex COUNT_TOKENS. Par exemple, le calcul des jetons d’une chaîne à intégrer avec le modèle snowflake-arctic-embed-m-v1.5 :

SELECT SNOWFLAKE.CORTEX.COUNT_TOKENS('snowflake-arctic-embed-m', '<input_text>') as token_count

Actualise¶

Le contenu diffusé dans un Cortex Search Service est basé sur les résultats d’une requête spécifique. Lorsque les données sous-jacentes à un Cortex Search Service changent, le service est mis à jour pour refléter ces modifications. Ces mises à jour sont appelées actualisations. Ce processus est automatisé et consiste à analyser la requête qui sous-tend la table.

Les Cortex Search Services ont les mêmes propriétés d’actualisation que les tables dynamiques. Consultez la rubrique Comprendre l’initialisation et l’actualisation des tables dynamiques pour comprendre les caractéristiques d’actualisation d’un Cortex Search Service.

La requête source d’un Cortex Search Service doit être candidate à l’actualisation incrémentielle de la table dynamique. Pour plus de détails sur ces exigences, consultez Prise en charge de l’actualisation incrémentielle. Cette restriction est conçue pour empêcher tout coût incontrôlable indésirable associé au calcul d’intégration vectorielle. Pour plus d’informations sur les constructions qui ne sont pas prises en charge pour l’actualisation incrémentielle de la table dynamique, consultez Requêtes prises en charge pour les tables dynamiques.

Suspension de l’indexation et de la mise à disposition¶

De la même manière que les tables dynamiques, les Cortex Search Services suspendent automatiquement leur état d’indexation lorsqu’ils rencontrent cinq échecs d’actualisation consécutifs liés à la requête source. Si vous rencontrez cette défaillance pour votre service, vous pouvez voir l’erreur SQL lors de l’utilisation du DESCRIBE CORTEX SEARCH SERVICE ou du Vue CORTEX_SEARCH_SERVICES. La sortie des deux inclut les colonnes suivantes :

• La colonne INDEXING_STATE aura la valeur de SUSPENDED.

• La colonne INDEXING_ERROR contiendra l’erreur SQL spécifique rencontrée dans la requête source.

Une fois le problème racine résolu, vous pouvez reprendre le service avec ALTER CORTEX SEARCH SERVICE <name> RESUME INDEXING. Pour une syntaxe détaillée, voir ALTER CORTEX SEARCH SERVICE.

Considérations relatives aux clients¶

Un Cortex Search Service entraîne des coûts de la manière suivante :

Pour connaître les meilleures pratiques en matière de gestion des coûts d’un Cortex Search Service, voir Comprendre les coûts de Cortex Search Services.

Pour visualiser les coûts de consommation liés aux services AI pour chaque service Cortex Search Service de votre compte, agrégés quotidiennement, consultez la vue CORTEX_SEARCH_DAILY_USAGE_HISTORY

Limitations connues¶

L’utilisation de Cortex Search est soumise aux limitations suivantes :

• Taille de la table de base : Le résultat de la requête matérialisée dans le service de recherche doit avoir une taille inférieure à 100 millions de lignes pour maintenir une performance de service optimale. Si le résultat matérialisé de votre requête comporte plus de 100 millions de lignes, la requête de création échoue avec une erreur.

  Note

  Pour augmenter les limites de mise à l’échelle des lignes sur un Cortex Search Service au-dessus de 100 millions, veuillez contacter votre équipe de compte Snowflake.

• Constructions de requête : les requêtes sources du Cortex Search Service doivent respecter les mêmes restrictions de requête que les tables dynamiques. Veuillez consulter le Limites des tables dynamiques pour plus de détails.

• Réplication et clonage : les Cortex Search Services ne prennent pas en charge la réplication ou le clonage. La prise en charge de ces fonctionnalités sera disponible dans une future version.

Disponibilité régionale¶

La prise en charge de cette fonctionnalité est disponible pour les comptes dans les régions Snowflake suivantes. La disponibilité de modèles de représentation vectorielle spécifiques dans une région est indiquée par une coche.

Cortex Search est disponible dans les régions suivantes uniquement en utilisant l’inférence interrégionale. Pour utiliser Cortex Search avec l’inférence interrégionale, utilisez le paramètre d’inférence interrégionale.

• AWS Europe (Paris)

• AWS Europe (Zurich)

• AWS Asie-Pacifique (Singapour)

• AWS Asie-Pacifique (Osaka)

• Azure Canada Central (Toronto)

• Azure Central US (Iowa)

• Azure UAE Nord (Dubaï)

Avis juridiques¶

La classification des données d’entrées et de sorties est présentée dans la table suivante.

Pour plus d’informations, reportez-vous à Snowflake AI et ML.