Snowflake Cortex Search : présentation, tarifs et suivi des coûts

Cortex Search de Snowflake est un service de recherche hybride entièrement managé qui combine recherche vectorielle, par mots-clés et sémantique. Il est conçu pour développer des applications RAG (Retrieval Augmented Generation) et des solutions de recherche d'entreprise, Snowflake prenant en charge en coulisses l'intégralité de l'infrastructure d'embedding, d'indexation et de serving. Contrairement à la recherche par mots-clés traditionnelle qui cherche des correspondances exactes, Cortex Search s'appuie sur le sens sémantique d'une requête appliquée à des données textuelles. Un utilisateur peut interroger une base de support client avec problèmes de facturation et obtenir tous les tickets liés à la facturation, même si cette expression n'apparaît pas littéralement dans le texte.

Nos clients utilisent Cortex Search de manière intensive, et l'une des questions qui revient le plus souvent est : comment savoir ce que cela me coûte réellement ?

La difficulté avec Cortex Search, c'est que sa structure de coûts est plus complexe que celle des services Snowflake classiques. Contrairement à un simple warehouse que l'on démarre et arrête à volonté, Cortex Search comporte plusieurs composantes de coût qui s'exécutent en parallèle. Sans suivi rigoureux, la facture peut vite s'envoler.

Voyons comment fonctionne Cortex Search, puis passons en revue les composantes de facturation et le suivi.

En interne, Cortex Search adopte une approche hybride combinant recherche vectorielle (alimentée par les modèles Arctic Embed de Snowflake), recherche par mots-clés et reranking sémantique pour livrer des résultats hautement pertinents. Lorsque vous créez un service, Snowflake gère automatiquement la génération des embeddings, l'indexation et l'infrastructure de serving, et transforme vos données sources pour les préparer à un serving à faible latence.

Voici un exemple concret de mise en place et d'utilisation de Cortex Search pour des tickets de support client :

-- 1. Create sample data table
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');

-- 2. Create the Cortex Search service
CREATE OR REPLACE CORTEX SEARCH SERVICE transcript_search_service

Déplier le code

Comme vous pouvez le constater, nous nous appuyons sur l'IA pour interpréter problèmes de facturation et renvoyer les lignes correspondantes.

La fonction SEARCH_PREVIEW renvoie des résultats JSON incluant un score de pertinence pour chaque correspondance. Avec PARSE_JSON et FLATTEN, vous obtenez une sortie tabulaire claire indiquant quelles transcriptions sont les plus pertinentes pour votre requête, accompagnées de leurs métadonnées et scores de confiance. L'intégration des résultats dans des applications ou dans des analyses SQL plus poussées s'en trouve grandement simplifiée.

Vous pouvez aussi appliquer des filtres sur les colonnes de métadonnées comme la région ou la période, ce qui en fait une solution idéale lorsque vous avez besoin à la fois de compréhension sémantique et de filtrage structuré :

-- Filter results by region
SELECT SNOWFLAKE.CORTEX.SEARCH_PREVIEW(
    'transcript_search_service',
    '{
        "query": "password reset problems",
        "columns": ["transcript_text", "region", "agent_id"],
        "filter": {"@eq": {"region": "Asia"}},
        "limit": 10
    }'
);

Cortex Search comporte 5 composantes tarifaires :

1. Compute de serving : 6,3 crédits par Go/mois de données indexées (s'exécute en continu, que vous interrogiez ou non le service)
2. Tokens d'embedding : coût par million de tokens de texte dans les colonnes de recherche au moment de l'indexation. Le tarif varie selon le modèle. Consultez la Snowflake Credit Consumption Table pour connaître le coût de chaque modèle. Exemple de tarification en septembre 2025 :
3. snowflake-arctic-embed-l-v2.0 : 0,05 crédit par million de tokens. C'est l'un des services IA les moins chers proposés par Snowflake !
4. Compute du warehouse : tarifs warehouse standard pour matérialiser et rafraîchir les données de recherche et exécuter les requêtes
5. Stockage : les index de recherche génèrent des frais de stockage au tarif standard (par exemple, 23 $/To/mois)
6. Cloud services : généralement gratuits (facturés uniquement au-delà de 10 % de l'utilisation quotidienne du warehouse)

Exemple concret : 10 millions de tickets de support client, avec une moyenne de 500 tokens chacun, et un modèle d'embedding facturé 0,32 crédit par million de tokens :

• Total des tokens : 10 millions de lignes × 500 tokens = 5 milliards de tokens
• Coût d'embedding : 5 milliards de tokens ÷ 1 million × 0,05 crédit = 250 crédits pour l'indexation initiale
  • À 3 $/crédit, soit 750 $
• Plus le serving en continu : si votre index pèse 50 Go, cela donne 50 × 6,3 = 315 crédits/mois rien que pour le maintenir actif
  • 945 $ à 3 $/crédit.

Contrairement aux warehouses que l'on peut suspendre, les coûts de serving de Cortex Search courent en permanence. Un index de 100 Go coûte 630 crédits par mois (environ 1 890 $ à 3 $/crédit), indépendamment du volume de requêtes. Vous payez même si personne n'effectue de recherche.

Comment suivre les coûts et l'utilisation de Cortex Search

Snowflake met à disposition deux vues dédiées dans le schéma ACCOUNT_USAGE pour suivre les coûts de Cortex Search. La vue CORTEX_SEARCH_DAILY_USAGE_HISTORY détaille les coûts quotidiens par type de consommation (serving vs embedding), tandis que CORTEX_SEARCH_SERVING_USAGE_HISTORY fournit le détail horaire des crédits de serving pour identifier les tendances d'utilisation.

Exemple quotidien :

-- Daily usage including serving and embedding costs
SELECT
    USAGE_DATE,
    DATABASE_NAME,
    SCHEMA_NAME,
    SERVICE_NAME,
    CONSUMPTION_TYPE,
    CREDITS,
    MODEL_NAME,
    TOKENS
FROM SNOWFLAKE.ACCOUNT_USAGE.CORTEX_SEARCH_DAILY_USAGE_HISTORY
WHERE USAGE_DATE >= CURRENT_DATE - 30
ORDER BY USAGE_DATE DESC, SERVICE_NAME, CONSUMPTION_TYPE;

L'une des sorties clés est consuption_type, qui prend la valeur embed_text_tokens ou serving.

Exemple horaire :

-- Hourly serving credit consumption
SELECT
    START_TIME,
    DATABASE_NAME,
    SCHEMA_NAME,
    SERVICE_NAME,
    CREDITS as hourly_serving_credits
FROM SNOWFLAKE.ACCOUNT_USAGE.CORTEX_SEARCH_SERVING_USAGE_HISTORY
WHERE START_TIME >= DATEADD('day', -7, CURRENT_TIMESTAMP())
ORDER BY START_TIME DESC, SERVICE_NAME;

Vous le constatez, il s'agit d'un regroupement très basique des crédits par heure.

Après avoir accompagné plusieurs équipes dans la mise en place du suivi des coûts de Cortex Search, voici mes principales recommandations :

Mettez en place des alertes, pas seulement des dashboards

Les requêtes de suivi présentées plus haut ne servent à rien si personne ne les exécute. Pour tout ce que vous souhaitez surveiller dans Snowflake, vous pouvez encapsuler le SQL dans une tâche planifiée couplée à une Notification Integration pour créer un moniteur personnalisé qui envoie des alertes vers Slack ou Teams. Si vous cherchez une fonctionnalité de monitoring particulièrement simple à utiliser, jetez un œil aux moniteurs dans SELECT.

Suspendez les services pendant le développement

Contrairement aux warehouses qui peuvent s'auto-suspendre, les services Cortex Search génèrent des coûts de serving 24h/24, 7j/7. En phase de développement et de test, suspendez vos services de recherche dès que vous ne les utilisez plus activement. Quelques minutes suffisent à les relancer, et ces frais de serving continus s'accumulent rapidement.

Dimensionnez vos index avec discernement

Chaque colonne incluse dans votre service de recherche, qu'elle soit interrogeable ou simple attribut, gonfle vos coûts de serving. N'ajoutez pas de colonnes par précaution. Démarrez au minimum et n'enrichissez le service qu'au fil des besoins réels. L'écart de coût entre un index de 10 Go et un index de 100 Go est considérable.

Suivez séparément les coûts des modèles d'embedding

Surveillez la colonne CONSUMPTION_TYPE de la vue d'utilisation quotidienne pour distinguer les coûts de serving de ceux d'embedding. Les pics d'embedding trahissent souvent des cycles de rafraîchissement inefficaces ou des reconstructions complètes inutiles. Si vous observez des coûts d'embedding élevés et persistants, examinez la logique de mise à jour de vos données.

Optimisez vos services Cortex Search

Les coûts de recherche dépendent fortement de la configuration du service. Suivez ces recommandations :

Définissez des target lags appropriés. Si vos documents évoluent peu, allongez les intervalles de rafraîchissement :

-- For static documentation
CREATE CORTEX SEARCH SERVICE product_docs_search
  ON document_text
  TARGET_LAG = '24 hours'  -- Instead of default 1 hour
  ...

Restreignez le périmètre de recherche dès que possible. Si les agents n'ont besoin que des documents récents, ajoutez des filtres :

CREATE CORTEX SEARCH SERVICE support_tickets_search
  ON ticket_text
  ATTRIBUTES customer_id, ticket_date, severity
  WHERE ticket_date >= DATEADD(year, -1, CURRENT_DATE())
  ...

Utilisez des clés primaires pour les mises à jour incrémentales

Si vos données changent souvent, définissez des clés primaires sur votre service de recherche. Vous activez ainsi des chemins de rafraîchissement optimisés qui réduisent drastiquement les coûts d'embedding comme les temps de rafraîchissement. Sans clé primaire, le moindre changement de schéma déclenche un ré-embedding complet de l'ensemble de votre jeu de données.

-- With primary key - only changed rows get re-embedded
CREATE OR REPLACE CORTEX SEARCH SERVICE support_tickets_search
    ON ticket_description
    PRIMARY KEY (ticket_id)  -- Must be TEXT data type
    ATTRIBUTES status, priority, created_date
    WAREHOUSE = search_wh
    TARGET_LAG = '1 hour'
    AS (
        SELECT ticket_id, ticket_description, status, priority, created_date
        FROM support_tickets
    );

Comme pour tout suivi de coûts dans Snowflake, on s'appuie sur le schéma ACCOUNT_USAGE pour surveiller les dépenses liées à Cortex Search. Utilisez les requêtes de monitoring ci-dessus comme point de départ pour cerner ce que vous devez suivre, puis planifiez des alertes ou des rapports hebdomadaires. Surveillez les pics de crédits de serving (hausse du volume de requêtes) ainsi que les coûts d'embedding lors des rafraîchissements de données.

L'objectif n'est pas toujours de minimiser les coûts, mais de tirer de la valeur de chaque dollar dépensé. Comprendre ces dynamiques permet d'optimiser à la fois la performance et le budget.

Si vous mettez Cortex Search en place, n'hésitez pas à me contacter. Je serai ravi d'échanger sur les approches de monitoring qui fonctionnent pour votre équipe.

Jeff est consultant Data et Analytics, fort de plus de 15 ans d'expérience dans l'automatisation des insights et l'exploitation des données pour piloter les processus métier. Côté technologies, il est spécialisé sur Snowflake + dbt + Tableau. Côté secteurs, il a travaillé dans les services publics, les essais cliniques, l'édition, les biens de grande consommation et l'industrie manufacturière. N'hésitez pas à le contacter : [email protected].