Batch Cortex Search¶

Syntaxe¶

Utilisez la syntaxe suivante pour interroger un Cortex Search Service en mode lot à l’aide de la fonction de table CORTEX_SEARCH_BATCH :

SELECT
    q.query,
    r.*
FROM query_table AS q,
LATERAL CORTEX_SEARCH_BATCH(
    service_name => '<database>.<schema>.<cortex_search_service>',
    query => q.query,                   -- optional STRING
    multi_index_query => q.miq,         -- optional VARIANT
    filter => q.filter,                 -- optional VARIANT
    limit => 10,                        -- optional INT
    options => q.options                -- optional VARIANT
) AS r;

Paramètres¶

La fonction CORTEX_SEARCH_BATCH prend en charge les paramètres suivants.

service_name (chaîne, obligatoire)

Nom complet du Cortex Search Service à interroger.

query (chaîne, facultatif)

Colonne contenant la chaîne de requête pour la recherche du service.

multi_index_query (variante, facultative)

Un objet qui spécifie une ou plusieurs entrées de requête vectorielles ou de mots-clés à rechercher dans l’index du service. Voir:ref:multi_index_query <label-cortex_multi_index_search> pour plus de détails sur la façon de construire ce paramètre.

Note

Pour des raisons de performance, multi_index_query prend actuellement en charge au maximum une entrée d’index vectoriel dans le tableau de requête.

filter (variante, facultative)

Colonne contenant des objets de filtre à appliquer aux résultats de la recherche.

limit (entier, facultatif)

Nombre maximum de résultats à renvoyer par requête. Par défaut : 10.

options (variante, facultative)

Colonne contenant un objet VARIANT avec des paramètres par requête facultatifs. Les clés de niveau supérieur prises en charge sont les suivantes :

• scoring_config (objet, facultatif) : Même structure que le paramètre scoring_config pour les requêtes interactives Cortex Search (Python, REST, ou SEARCH_PREVIEW). Utilisez-le pour personnaliser le classement de la requête par lots de cette ligne. Voir Personnalisation de la notation des résultats de Cortex Search.

• replicas (entier, facultatif) : Combien de copies de l’index de recherche sont utilisées pour traiter la requête par lots de cette ligne. Par défaut : 2. Des valeurs plus élevées peuvent améliorer le débit. Le coût de service augmente en fonction du nombre de répliques.

• experimental (objet, facultatif) : Objet réservé au comportement de recherche expérimentale ou en avant-première. Les champs et la sémantique peuvent être modifiés sans préavis. À utiliser uniquement lorsque la documentation ou l’assistance de Snowflake vous indique de définir des clés spécifiques.

Notes sur l’utilisation¶

• Le débit de la fonction de recherche par lots peut varier en fonction de la quantité de données indexées dans le Cortex Search Service interrogé et de la complexité des requêtes de recherche. Exécutez la fonction sur un petit nombre de requêtes afin de mesurer le débit de votre charge de travail spécifique. En général, les requêtes vers des services plus importants avec plus de conditions de filtrage voient un débit inférieur.

• Le débit de la fonction de recherche par lots, c’est-à-dire le nombre de requêtes de recherche traitées par seconde, n’est pas influencé par la taille de l’entrepôt utilisé pour l’interroger.

• Étant donné que la recherche par lots génère des ressources dédiées pour servir chaque tâche, elle entraîne une latence de démarrage supplémentaire. Si vous devez exécuter moins de 2 000 requêtes, vous obtiendrez généralement des résultats plus rapides en utilisant l’API Cortex Search interactive (Python ou API REST) plutôt que la recherche par lots.

• Contrairement à l’API Cortex Search interactive, la fonction de recherche par lots peut interroger des services dont la diffusion est actuellement suspendue.

• Un seul Cortex Search Service peut être interrogé en mode interactif et par lot simultanément sans aucune dégradation des performances ou du débit de la requête interactive. Des ressources de calcul séparées sont utilisées pour les requêtes interactives et les requêtes par lots.

Considérations relatives aux clients¶

La recherche par lots a trois composantes de coûts :

Coût de service

Des frais basés sur la taille des données de l’index de recherche et la durée de la tâche de recherche par lots, à l’exclusion du temps de démarrage. Reflète également la valeur replicas dans``options`` (par défaut 2) ; voir l’option replicas ci-dessus.

Coût d’intégration des requêtes

Frais pour le nombre de jetons intégrés à la suite des requêtes d’entrée. Contrairement à Cortex Search interactif, l’intégration des requêtes n’est pas gratuite pour la recherche par lots.

Coût de l’entrepôt virtuel

Frais pour le calcul de l’entrepôt virtuel utilisé pour exécuter la tâche en lot.

Pour le suivi de l’utilisation, voir la vue d’utilisation du compte CORTEX_SEARCH_BATCH_QUERY_USAGE_HISTORY. Pour plus d’informations sur les coûts de Cortex Search, voir:ref:label_cortex_search_cost_considerations.

Disponibilité régionale¶

La recherche par lots est disponible dans toutes les régions où Cortex Search est disponible. Voir:ref:label-cortex_search_overview_regional_availability pour une liste complète des régions prises en charge.

Exemple d’utilisation :¶

Dans cet exemple, associez des produits d’un formulaire de commande soumis par l’utilisateur à un catalogue de produits « or ». L’appel CORTEX_SEARCH_BATCH utilise options afin que les intégrations soient calculées sans le préfixe de requête de recherche par défaut ; voir Désactivation du préfixe de requête pour les intégrations vectorielles. N’utilisez ce paramètre que lorsque vous avez évalué l’impact sur la qualité des résultats.

-- Create the golden product catalog with canonical product names
CREATE OR REPLACE TABLE golden_catalog (product_name TEXT);
INSERT INTO golden_catalog VALUES
  ('Wireless Bluetooth Headphones'),
  ('Wireless Noise-Canceling Earbuds'),
  ('USB-C Charging Cable 6ft'),
  ('Portable Power Bank 10000mAh');

-- Create Cortex Search Service on the golden catalog
CREATE CORTEX SEARCH SERVICE golden_product_service
ON product_name
WAREHOUSE = <warehouse_name>
TARGET_LAG = '1 day'
AS
SELECT product_name FROM golden_catalog;

-- Create a table of user-submitted products (may contain variations or typos)
CREATE OR REPLACE TABLE submitted_products (product TEXT);
INSERT INTO submitted_products VALUES
  ('bluetooth headphones wireless'),
  ('usb c cable');

-- For each user-submitted product, query the service for the two closest golden results
SELECT
  q.product, s.*
FROM submitted_products AS q,
LATERAL CORTEX_SEARCH_BATCH(
    service_name => 'golden_product_service',
    query => q.product,
    limit => 2,
    options => OBJECT_CONSTRUCT(
        'scoring_config', OBJECT_CONSTRUCT(
            'disable_vector_embedding_query_prefix', true
        )
    )
) AS s;

L’exemple suivant utilise multi_index_query pour soumettre des intégrations précalculées comme entrée de requête au lieu de texte brut. Ici, la table source my_db.my_schema.product_embeddings contient une colonne embedding avec des vecteurs précalculés, et le Cortex Search Service``my_db.my_schema.golden_product_service`` a été créé avec une configuration de type (BYOV, « bring-your-own-vector »). Pour plus de détails sur la construction de multi_index_query, voir multi_index_query.

SELECT
    q.product_name,
    s.*
FROM (
    SELECT
        product_name,
        embedding::ARRAY AS emb_arr
    FROM my_db.my_schema.product_embeddings
    LIMIT 100000
) q,
LATERAL CORTEX_SEARCH_BATCH(
    service_name => 'my_db.my_schema.golden_product_service',
    multi_index_query => OBJECT_CONSTRUCT(
        'EMBEDDING', ARRAY_CONSTRUCT(
            OBJECT_CONSTRUCT('vector', q.emb_arr)
        )
    ),
    limit => 5
) s;