Snowflake Cortex Search: panoramica, prezzi e monitoraggio dei costi

Cortex Search di Snowflake è un servizio di ricerca ibrida completamente gestito che unisce ricerca vettoriale, per parole chiave e semantica. È pensato per realizzare applicazioni RAG (Retrieval Augmented Generation) e soluzioni di enterprise search: dietro le quinte, Snowflake si occupa di tutta l'infrastruttura di embedding, indicizzazione e serving. A differenza della ricerca tradizionale per parole chiave, che si limita a individuare corrispondenze testuali, Cortex Search interpreta il significato semantico della query rispetto ai dati testuali. Si può, ad esempio, interrogare un database di customer service con "problemi di fatturazione" e ottenere tutti i ticket riconducibili al tema, anche se quella frase non compare letteralmente nel testo.

I nostri clienti usano Cortex Search in modo intensivo e una delle domande che mi viene posta più di frequente è: "Come faccio a tenere sotto controllo quanto mi sta costando davvero?"

Il punto è che la struttura dei costi di Cortex Search è più articolata rispetto ai servizi tradizionali di Snowflake. A differenza di un semplice warehouse che si accende e si spegne, Cortex Search ha più voci di costo che corrono in parallelo. Senza un monitoraggio adeguato, ci si può ritrovare con una bolletta inaspettatamente salata.

Vediamo come funziona Cortex Search e analizziamo poi le voci di fatturazione e il monitoraggio.

Sotto il cofano, Cortex Search adotta un approccio ibrido che combina ricerca vettoriale (basata sui modelli Arctic Embed di Snowflake), ricerca per parole chiave e reranking semantico per restituire risultati altamente pertinenti. Quando si crea un servizio, Snowflake gestisce automaticamente la generazione degli embedding, l'indicizzazione e l'infrastruttura di serving, preparando i dati di origine per un serving a bassa latenza.

Ecco un esempio pratico di configurazione e utilizzo di Cortex Search per i ticket di customer support:

-- 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

Espandi codice

Come si può notare, ci affidiamo all'AI per interpretare "Problemi di fatturazione" e restituire le righe corrette.

La funzione SEARCH_PREVIEW restituisce risultati in formato JSON che includono un punteggio di pertinenza per ogni corrispondenza. Combinando PARSE_JSON e FLATTEN si ottiene un output tabellare ordinato, che evidenzia le trascrizioni più pertinenti alla query insieme ai relativi metadati e punteggi di confidenza. In questo modo è semplice integrare i risultati di ricerca in applicazioni o in successive analisi SQL.

È inoltre possibile applicare filtri sulle colonne di metadati come la regione o gli intervalli temporali: una soluzione ideale negli scenari in cui servono sia comprensione semantica sia filtri strutturati.

-- 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
    }'
);

Il pricing di Cortex Search si articola in 5 voci:

1. Compute di serving: 6,3 crediti per GB/mese di dati indicizzati (è sempre attivo, indipendentemente dal fatto che si stiano eseguendo query)
2. Token di embedding: costo per milione di token di testo nelle colonne di ricerca durante l'indicizzazione. Varia in base al modello. Consulti la Snowflake Credit Consumption Table per conoscere il costo di ciascun modello. Esempio di prezzo a settembre 2025:
3. snowflake-arctic-embed-l-v2.0: 0,05 crediti per milione di token. È uno dei servizi AI più economici di Snowflake!
4. Compute del warehouse: tariffe standard del warehouse per la materializzazione e l'aggiornamento dei dati di ricerca e per l'esecuzione delle query
5. Storage: gli indici di ricerca sono soggetti alle tariffe di archiviazione standard (ad esempio, 23 $/TB/mese)
6. Servizi cloud: di norma gratuiti (addebitati solo se superano il 10% dell'utilizzo giornaliero del warehouse)

Esempio concreto: 10 milioni di ticket di customer support, con una media di 500 token ciascuno, utilizzando un modello di embedding che costa 0,32 crediti per milione di token:

• Token totali: 10 milioni di righe × 500 token = 5 miliardi di token
• Costo di embedding: 5 miliardi di token ÷ 1 milione × 0,05 crediti = 250 crediti per l'indicizzazione iniziale
  • A 3 $/credito, fanno 750 $
• A cui si aggiunge il serving continuativo: con un indice da 50 GB, sono 50 × 6,3 = 315 crediti/mese solo per tenerlo attivo
  • 945 $ a 3 $/credito.

A differenza dei warehouse, che è possibile sospendere, i costi di serving di Cortex Search maturano senza sosta. Un indice da 100 GB costa 630 crediti al mese (circa 1.890 $ a 3 $/credito) indipendentemente dal volume di query. Si paga anche se nessuno effettua ricerche.

Come monitorare costi e utilizzo di Cortex Search

Snowflake mette a disposizione due viste dedicate nello schema ACCOUNT_USAGE per tracciare i costi di Cortex Search. La vista CORTEX_SEARCH_DAILY_USAGE_HISTORY ripartisce i costi giornalieri per tipo di consumo (serving vs embedding), mentre CORTEX_SEARCH_SERVING_USAGE_HISTORY offre il dettaglio orario dei crediti di serving, utile per individuare i pattern di utilizzo.

Esempio giornaliero:

-- 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;

Come si nota, l'output chiave è consuption_type, che assume valore embed_text_tokens oppure serving.

Esempio orario:

-- 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;

Come si vede, si tratta di un'aggregazione molto basilare dei crediti per ora.

Dopo aver supportato diversi team nell'implementare il monitoraggio dei costi di Cortex Search, ecco i miei principali consigli:

Imposti alert, non solo dashboard

Le query di monitoraggio viste sopra non servono a nulla se nessuno le esegue. Per qualunque elemento si voglia monitorare in Snowflake, è possibile incapsulare l'SQL in un task pianificato con una Notification Integration, così da creare un monitor personalizzato che invii alert a Slack o Teams. Se cerca una funzionalità di monitoraggio davvero immediata, dia un'occhiata ai monitor di SELECT.

Sospenda i servizi durante lo sviluppo

A differenza dei warehouse, che si auto-sospendono, i servizi Cortex Search accumulano costi di serving 24 ore su 24, 7 giorni su 7. Durante le fasi di sviluppo e test, sospenda i servizi di ricerca quando non li sta usando attivamente. Riattivarli richiede pochi minuti, ma quegli addebiti continui di serving si sommano in fretta.

Dimensioni gli indici con attenzione

Ogni colonna inserita nel servizio di ricerca, sia essa ricercabile o solo un attributo, incide sui costi di serving. Eviti di includere colonne "per sicurezza". Parta dall'essenziale e aggiunga colonne solo quando servono davvero. La differenza di costo tra un indice da 10 GB e uno da 100 GB è notevole.

Monitori separatamente i costi dei modelli di embedding

Tenga d'occhio la colonna CONSUMPTION_TYPE della vista di utilizzo giornaliero per distinguere i costi di serving da quelli di embedding. Picchi di embedding spesso segnalano pattern di refresh inefficienti o ricostruzioni complete superflue. Se rileva costi di embedding costantemente elevati, analizzi i pattern di aggiornamento dei dati.

Ottimizzi i servizi Cortex Search

I costi di ricerca dipendono in larga misura da come configura il servizio. Segua queste linee guida:

Imposti target lag adeguati. Se i documenti non cambiano spesso, opti per intervalli di refresh più lunghi:

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

Restringa l'ambito della ricerca quando possibile. Se agli operatori bastano i documenti recenti, aggiunga dei filtri:

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

Usi le primary key per gli aggiornamenti incrementali

Se i dati cambiano spesso, definisca le primary key sul servizio di ricerca. In questo modo si abilitano percorsi di refresh ottimizzati, in grado di ridurre drasticamente sia i costi di embedding sia i tempi di aggiornamento. Senza primary key, qualunque modifica allo schema innesca un re-embedding completo dell'intero dataset.

-- 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
    );

Come per qualsiasi attività di cost monitoring in Snowflake, ci affidiamo allo schema ACCOUNT_USAGE per tenere sotto controllo la spesa di Cortex Search. Utilizzi le query di monitoraggio viste sopra come punto di partenza per definire cosa controllare, poi pianifichi alert o report settimanali. Faccia attenzione ai picchi di crediti di serving (legati all'aumento del volume di query) e ai costi di embedding durante i refresh dei dati.

L'obiettivo non è sempre minimizzare i costi, ma ricavare valore dalla spesa. Capire questi pattern aiuta a ottimizzare prestazioni e budget allo stesso tempo.

Se sta implementando Cortex Search, mi contatti pure. Sarei felice di conoscere gli approcci di monitoraggio che funzionano per il suo team.

Jeff è un consulente Data and Analytics con oltre 15 anni di esperienza nell'automazione degli insight e nell'uso dei dati per governare i processi di business. Sul fronte tecnologico è specializzato in Snowflake + dbt + Tableau. Sul piano dei domini di business, ha maturato esperienza in Public Utility, sperimentazioni cliniche, editoria, CPG e manifatturiero. Lo contatti pure in qualsiasi momento: [email protected].