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.
Créer le service¶
Vous pouvez créer un Cortex Search Service avec une seule requête SQL ou depuis le Studio AI & ML de Snowflake. Lorsque vous créez un Cortex Search Service, Snowflake effectue des transformations sur vos données sources pour les préparer à une diffusion à faible latence. Les sections suivantes montrent comment créer un service en utilisant à la fois SQL et dans le Studio AI & ML de Snowflake dans Snowsight.
Note
Lorsque vous créez un service de recherche, l’index de recherche est créé dans le cadre du processus de création. Cela signifie que l’instruction CREATE CORTEX SEARCH SERVICE peut prendre plus de temps à compléter pour des ensembles de données plus volumineux.
Utiliser SQL¶
L’exemple suivant montre comment créer un Cortex Search Service avec CREATE CORTEX SEARCH SERVICE sur l’exemple d’ensemble de données de transcription du support client créé dans la section précédente.
CREATE OR REPLACE CORTEX SEARCH SERVICE transcript_search_service
ON transcript_text
ATTRIBUTES region
WAREHOUSE = cortex_search_wh
TARGET_LAG = '1 day'
AS (
SELECT
transcript_text,
region,
agent_id
FROM support_transcripts
);
Cette commande déclenche la création du service de recherche pour vos données. Dans cet exemple :
Les requêtes adressées au service rechercheront des correspondances dans la colonne
transcript_text
.Le paramètre
TARGET_LAG
indique que le Cortex Search Service vérifiera les mises à jour de la table de basesupport_transcripts
environ une fois par jour.Les colonnes
region
etagent_id
seront indexées afin qu’elles puissent être renvoyées avec les résultats des requêtes sur la colonnetranscript_text
.La colonne
region
sera disponible en tant que colonne de filtre lors de l’interrogation de la colonnetranscript_text
.L’entrepôt
cortex_search_wh
sera utilisé pour matérialiser les résultats de la requête spécifiée initialement et à chaque fois que la table de base est modifiée.
Note
En fonction de la taille de l’entrepôt spécifié dans la requête et du nombre de lignes de votre table, l’exécution de cette commande CREATE peut prendre plusieurs heures.
Snowflake recommande d’utiliser un entrepôt dédié dont la taille ne dépasse pas la taille MEDIUM pour chaque service.
Les colonnes du champ ATTRIBUTES doivent être incluses dans la requête source, soit via une énumération explicite, soit via un caractère générique, (
*
) .
Utiliser Snowsight¶
Suivez ces étapes pour créer un Cortex Search Service dans Snowsight :
Connectez-vous à Snowsight.
Choisissez un rôle auquel est accordé le rôle SNOWFLAKE.CORTEX_USER de base de données.
Dans le menu de navigation, sélectionnez AI & ML » Studio.
Sélectionnez + Create dans la boîte Create a Cortex Search Service.
Sélectionnez un rôle et un entrepôt. Le rôle doit se voir attribué le rôle de base de données SNOWFLAKE.CORTEX_USER. L’entrepôt est utilisé pour matérialiser les résultats de la requête source lorsque le service est créé et actualisé.
Sélectionnez une base de données et un schéma dans lesquels le service est défini.
Saisissez un nom pour votre service, puis sélectionnez Let’s go.
Sélectionnez la table ou la vue contenant les données textuelles à indexer pour la recherche, puis sélectionnez Next. Pour cet exemple, sélectionnez la table
support_transcripts
.Note
Si vous souhaitez spécifier plusieurs sources de données ou effectuer des transformations lors de la définition de votre service, utilisez SQL.
Sélectionnez les colonnes que vous souhaitez inclure dans les résultats de la recherche,
transcript_text
,region
, etagent_id
, puis sélectionnez Next.Sélectionnez la colonne qui sera recherchée,
transcript_text
, puis sélectionnez Next.Si vous souhaitez pouvoir filtrer vos résultats de recherche en fonction d’une ou plusieurs colonnes particulières, sélectionnez ces colonnes, puis sélectionnez Next. Si vous n’avez besoin d’aucun filtre, sélectionnez Skip this option. Pour cet exemple, vous pouvez ignorer cette étape.
Définissez votre latence cible, qui correspond au temps pendant lequel le contenu de votre service doit être en retard par rapport aux mises à jour des données de base, puis sélectionnez Create search service.
L’étape finale confirme que votre service a été créé et affiche le nom du service et sa source de données.
Note
Lorsque vous créez le service à partir de Snowsight, le nom du service est entre guillemets. Pour plus de détails sur ce que cela signifie lors du référencement du service dans SQL, consultez Identificateurs entre guillemets doubles.
Accorder des autorisations d’utilisation¶
Une fois le service et l’index créés, vous pouvez accorder l’utilisation du service, de sa base de données et de son schéma à d’autres rôles tels que customer_support.
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;
Prévisualiser le service¶
Pour confirmer que le service est correctement renseigné avec les données, vous pouvez prévisualiser le service via la fonction SEARCH_PREVIEW depuis un environnement SQL :
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;
Exemple de réponse de requête réussie :
[
{
"transcript_text" : "My internet has been down since yesterday, can you help?",
"region" : "North America"
}
]
Cette réponse confirme que le service est rempli de données et fournit des résultats raisonnables pour la requête donnée.
Interrogez le service depuis votre application¶
Une fois que vous avez créé le service de recherche, accordé son utilisation à votre rôle et l’avez prévisualisé, vous pouvez désormais l’interroger à partir de votre application à l’aide de l”API Python.
Le code suivant montre l’utilisation de l’API Python pour récupérer le ticket d’assistance le plus pertinent pour une requête concernant internet issues
, filtré pour renvoyer des résultats dans la région North America
:
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())
Exemple de réponse de requête réussie :
{
"results": [
{
"transcript_text": "My internet has been down since yesterday, can you help?",
"region": "North America"
}
],
"request_id": "5d8eaa5a-800c-493c-a561-134c712945ba"
}
Les Cortex Search Services renvoient toutes les colonnes spécifiées dans le champ columns
de votre requête.
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 qui interroge doit avoir des privilèges USAGE sur le service lui-même, ainsi que sur la base de données et le schéma dans lesquels réside le service. 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é pouvant être traitée par un grand modèle de langage. À 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 TOKEN_COUNT du Cortex avec le paramètre du modèle snowflake-arctic-embed-m
comme suit :
SELECT SNOWFLAKE.CORTEX.COUNT_TOKENS('snowflake-arctic-embed-m', '<input_text>') as token_count
Comprendre les limites des jetons de recherche sémantique¶
La recommandation de morceaux de taille 512 jetons ou moins est motivée par des recherches qui montrent qu”une taille de morceau plus petite entraîne généralement une meilleure qualité de récupération et de réponse du modèle LLM en aval. Bien qu’il existe aujourd’hui des modèles d’intégration à contexte plus long, tels que arctique-intégrer-m-long, Cortex Search opte pour un modèle d’intégration avec une fenêtre de contexte plus petite pour offrir une meilleure qualité de recherche dès le départ.
L’intuition derrière ce concept est qu’avec des morceaux plus petits, la récupération peut être plus précise pour une requête donnée. Cela est dû au fait qu’il y a moins de jetons sur lesquels « faire la moyenne » lors de la génération des intégrations vectorielles pour le morceau et la requête. De plus, avec des morceaux plus petits, le LLM en aval peut recevoir uniquement les informations dont il a besoin, car il y a moins de texte potentiellement bruyant fourni dans l’invite au modèle.
Vous pouvez trouver des recherches ici montrant que les petits morceaux fonctionnent généralement mieux sur des ensembles de données de type questions-réponses publics.
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 Présentation de 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 Constructions, opérateurs et fonctions non pris en charge.
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 :
Catégorie de coût |
Description |
---|---|
Services AI - Coûts de service |
Les Cortex Search Services utilisent un calcul de service multi-locataire, distinct d’un entrepôt virtuel fourni par l’utilisateur, pour permettre des requêtes de recherche à faible latence. Le coût de calcul est engagé par GB par mois (GB/mo) de données indexées, où les données indexées sont les données fournies par l’utilisateur dans la requête source de Cortex Search, plus les intégrations vectorielles calculées pour le compte de l’utilisateur. Dans les calculs de facturation du service, l’utilisation est mesurée au deuxième niveau, avec une hypothèse de 30,5 jours par mois. À titre d’estimation, la taille des données indexées en octets est à peu près égale à Les coûts de service de Cortex Search peuvent être observés dans la vue CORTEX_SEARCH_SERVING_USAGE_HISTORY, qui fournit la consommation horaire de jetons de service pour chaque Cortex Search Service de votre compte. Les coûts de service de Cortex Search sont également inclus dans le total AI_SERVICES dans la vue METERING_HISTORY. Pour le taux de crédit par GB/mo de données indexées, consultez la Table de consommation du service Snowflake. |
AI Services - Coûts d’intégration |
Les Cortex Search Services intègrent chaque document de la colonne de recherche dans l’espace vectoriel à l’aide de la fonction SNOWFLAKE.CORTEX.EMBED_TEXT_768 LLM, qui entraîne un coût de crédit par jeton intégré. Les intégrations sont traitées de manière incrémentielle lors de l’évaluation de la requête source, de sorte que le coût d’intégration n’est engagé que pour les documents ajoutés ou modifiés. Pour plus de détails sur les coûts d’intégration vectorielle, consultez le Intégrations vectorielles. |
Calcul de l’entrepôt virtuel |
Les Cortex Search Services nécessitent un entrepôt virtuel fourni par l’utilisateur. Cet entrepôt génère des coûts lorsque l’utilisateur crée le service et chaque fois que le service est actualisé. |
Stockage |
Les Cortex Search Services matérialisent la requête source dans une table stockée dans votre compte. Cette table est transformée en structures de données optimisées pour un service à faible latence, également stockées dans votre compte. Le stockage pour la table et les structures de données intermédiaires est basé sur un tarif forfaitaire par téraoctet (TB). |
Calcul des services cloud |
Les Cortex Search Services utilisent le calcul des services Cloud pour déclencher des actualisations lorsqu’un objet de base sous-jacent a changé. Le coût de calcul des services Cloud est soumis à la contrainte selon laquelle Snowflake ne facture que si le coût quotidien des services Cloud est supérieur à 10 % du coût quotidien de l’entrepôt pour le compte. |
Astuce
Snowflake recommande d’utiliser une taille d’entrepôt ne dépassant pas la taille MEDIUM pour un Cortex Search Service. Cette recommandation pourrait ne plus s’appliquer à l’avenir en raison des prochaines mises à jour du produit.
Limitations connues¶
L’utilisation de Cortex Search est soumise aux limitations suivantes :
Langue prise en charge : La fonctionnalité est optimisée pour les documents et les requêtes en anglais.
Taille de la table de base : le résultat de la requête matérialisée dans le service de recherche doit comporter moins de 50 millions de lignes pour maintenir des performances de diffusion optimales. Si le résultat matérialisé de votre requête comporte plus de 50 millions de lignes, la requête de création générera une erreur.
Note
Pour augmenter les limites de mise à l’échelle des lignes sur un Cortex Search Service au-dessus de 50 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 Limitations connues relatives aux 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.
Important
Pour chaque Cortex Search que vous créez, deux entités de table dynamique apparaissent dans l”UI de Surveillance de Snowsight pour les tables dynamiques. Ces deux entités sont au format _CORTEX_SEARCH_SOURCE_*
et _CORTEX_SEARCH_REFRESH_*
. Ces entités apparaissent également dans les vues du schéma d’informations des tables dynamiques, mais n’apparaissent pas dans les commandes SHOW/DESC des tables dynamiques. En cliquant sur l’une de ces entités dans l’UI de Snowsight , il y a un message Dynamic Table not found
. Il s’agit d’un comportement attendu. Les entités liées à Cortex Search seront supprimées de la surveillance de l’UI des tables dynamiques de Snowsight dans les futures versions du produit.
Disponibilité régionale¶
La prise en charge de cette fonctionnalité est disponible pour les comptes dans les régions Snowflake suivantes :
AWS |
Azure |
GCP |
---|---|---|
US Ouest 2 (Oregon) |
Est US 2 (Virginie) |
Europe Ouest 2 (Londres) |
US Est 2 (Ohio) |
Sud-Central US (Texas) |
Europe Ouest 3 (Francfort) |
US East 1 (N. du Nord) |
UK Sud (Londres) |
Europe Ouest 4 (Pays-Bas) |
Canada (Centre) |
Europe du Nord (Irlande) |
US Central 1 (Iowa) |
Amérique du Sud (São Paulo) |
Europe de l’Ouest (Pays-Bas) |
US East 4 (Virginie du Nord) |
Europe (Irlande) |
Suisse Nord (Zurich) |
|
Europe (Londres) |
Inde centrale (Pune) |
|
Europe Central 1 (Francfort) |
Japon Est (Tokyo, Saitama) |
|
Europe (Stockholm) |
Asie du Sud-Est (Singapour) |
|
Asie-Pacifique (Tokyo) |
Australie Est (Nouvelle-Galles du Sud) |
|
Asie Pacifique (Mumbai) |
||
Asie-Pacifique (Sydney) |
||
Asie-Pacifique (Jakarta) |
||
Asie-Pacifique (Seoul) |
Avis juridiques¶
La classification des données d’entrées et de sorties est présentée dans la table suivante.
Classification des données d’entrée |
Classification des données de sortie |
Désignation |
---|---|---|
Usage Data |
Customer Data |
Covered AI Features [1] |
Pour plus d’informations, reportez-vous à Snowflake AI et ML.