Snowflake Cortex Search: Visão Geral, Preços e Monitoramento de Custos

O Cortex Search da Snowflake é um serviço de busca híbrida totalmente gerenciado que combina busca vetorial, por palavra-chave e semântica. Foi criado para desenvolver aplicações de RAG (Retrieval Augmented Generation) e soluções de busca corporativa, com a Snowflake cuidando de toda a infraestrutura de embedding, indexação e entrega nos bastidores. Diferente da busca tradicional por palavra-chave, que procura correspondências exatas, o Cortex Search se baseia no significado semântico de um padrão de busca aplicado a dados textuais. Um usuário pode pesquisar "problemas de cobrança" em uma base de atendimento ao cliente e obter todos os tickets relacionados a questões de cobrança, mesmo que essa expressão não apareça no texto.

Nossos clientes têm usado bastante o Cortex Search, e uma das perguntas mais frequentes que recebo é: "Como faço para acompanhar quanto isso está realmente me custando?"

O desafio com o Cortex Search é que a estrutura de custos é mais complexa do que a dos serviços tradicionais do Snowflake. Diferente de um simples warehouse que você liga e desliga, o Cortex Search tem vários componentes de custo rodando ao mesmo tempo. Sem o monitoramento adequado, você pode acabar com uma fatura inesperadamente alta.

Vamos entender como o Cortex Search funciona e, em seguida, revisar os componentes de cobrança e o monitoramento.

Nos bastidores, o Cortex Search usa uma abordagem híbrida que combina busca vetorial (com os modelos Arctic Embed da Snowflake), busca por palavra-chave e reranking semântico para entregar resultados altamente relevantes. Quando você cria um serviço, a Snowflake cuida automaticamente da geração de embeddings, da indexação e da infraestrutura de entrega, transformando seus dados de origem para deixá-los prontos para entrega de baixa latência.

Veja um exemplo prático de como configurar e usar o Cortex Search para tickets de atendimento ao cliente:

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

Expandir código

Como você pode ver, estamos contando com a IA para entender "Problemas de cobrança" e retornar as linhas corretas.

A função SEARCH_PREVIEW retorna resultados em JSON que incluem uma pontuação de relevância para cada correspondência. Com PARSE_JSON e FLATTEN, você tem uma saída tabular limpa mostrando quais transcrições são mais relevantes para a sua consulta, junto com seus metadados e níveis de confiança. Isso facilita integrar os resultados de busca em aplicações ou em análises adicionais em SQL.

Você também pode aplicar filtros baseados em colunas de metadados, como região ou períodos de tempo, o que é perfeito para cenários em que você precisa tanto da compreensão semântica quanto da filtragem estruturada:

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

O Cortex Search tem 5 componentes de preço:

1. Compute de serving: 6,3 créditos por GB/mês de dados indexados (roda continuamente, esteja você consultando ou não).
2. Tokens de embedding: custo por milhão de tokens de texto nas colunas de busca durante a indexação. Varia conforme o modelo. Consulte a Tabela de Consumo de Créditos da Snowflake para ver o custo de cada modelo. Exemplo de preço em setembro de 2025:
3. snowflake-arctic-embed-l-v2.0: 0,05 créditos por milhão de tokens. Esse é um dos serviços de IA mais baratos da Snowflake!
4. Compute do warehouse: tarifas padrão de warehouse para materializar e atualizar dados de busca e executar consultas.
5. Armazenamento: os índices de busca geram cobranças de armazenamento à sua tarifa padrão (por exemplo, US$ 23/TB/mês).
6. Cloud services: geralmente gratuito (cobrado apenas se ultrapassar 10% do uso diário do warehouse).

Exemplo do mundo real: 10 milhões de tickets de atendimento ao cliente, com média de 500 tokens cada, usando um modelo de embedding que custa 0,32 créditos por milhão de tokens:

• Total de tokens: 10 milhões de linhas × 500 tokens = 5 bilhões de tokens
• Custo de embedding: 5 bilhões de tokens ÷ 1 milhão × 0,05 créditos = 250 créditos para a indexação inicial
  • A US$ 3/crédito, isso dá US$ 750.
• Mais o serving contínuo: se o seu índice tiver 50 GB, são 50 × 6,3 = 315 créditos/mês só para mantê-lo no ar
  • US$ 945 a US$ 3/crédito.

Diferente dos warehouses, que você pode suspender, os custos de serving do Cortex Search se acumulam continuamente. Um índice de 100 GB custa 630 créditos por mês (cerca de US$ 1.890 a US$ 3/crédito), independentemente do volume de consultas. Você paga isso mesmo que ninguém faça uma busca.

Como monitorar custos e uso do Cortex Search

A Snowflake oferece duas views dedicadas no schema ACCOUNT_USAGE para acompanhar os custos do Cortex Search. A view CORTEX_SEARCH_DAILY_USAGE_HISTORY detalha os custos diários por tipo de consumo (serving vs. embedding), enquanto a CORTEX_SEARCH_SERVING_USAGE_HISTORY traz os detalhes de créditos de serving por hora, ajudando a identificar padrões de uso.

Exemplo diário:

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

Note que uma saída importante é o consuption_type, que pode ser embed_text_tokens ou serving.

Exemplo por hora:

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

Como dá para ver, é uma consolidação bem simples de créditos por hora.

Depois de ajudar várias equipes a implementar o monitoramento de custos do Cortex Search, aqui vão minhas principais recomendações:

Configure alertas, e não só dashboards

Aquelas queries de monitoramento acima não servem para nada se ninguém as executar. Para qualquer coisa que você queira monitorar no Snowflake, dá para encapsular o SQL em uma tarefa agendada com uma Notification Integration e criar um monitor personalizado que envia alertas para o Slack ou o Teams. Se você quer uma funcionalidade de monitoramento extremamente fácil de usar, dê uma olhada nos monitors do SELECT.

Suspenda os serviços durante o desenvolvimento

Diferente dos warehouses, que podem se autossuspender, os serviços do Cortex Search acumulam custos de serving 24 horas por dia, 7 dias por semana. Durante o desenvolvimento e os testes, suspenda seus serviços de busca quando não estiver usando ativamente. Você consegue retomá-los em minutos, mas esses custos contínuos de serving somam rápido.

Dimensione seus índices com cuidado

Cada coluna que você inclui no seu serviço de busca, seja pesquisável ou apenas um atributo, aumenta seus custos de serving. Não inclua colunas "só por garantia". Comece com o mínimo e adicione colunas apenas quando precisar delas. A diferença de custo entre um índice de 10 GB e um de 100 GB é considerável.

Monitore os custos do modelo de embedding separadamente

Acompanhe a coluna CONSUMPTION_TYPE da view de uso diário para comparar os custos de serving e de embedding. Picos de embedding costumam indicar padrões de atualização ineficientes ou reconstruções completas desnecessárias. Se você notar custos de embedding consistentemente altos, investigue seus padrões de atualização de dados.

Otimize seus serviços do Cortex Search

Os custos de busca dependem muito de como você configura o serviço. Siga estas orientações:

Defina target lags adequados. Se seus documentos não mudam com frequência, use intervalos de atualização mais longos:

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

Filtre o escopo da busca sempre que possível. Se os agentes só precisam de documentos recentes, adicione filtros:

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

Use chaves primárias para atualizações incrementais

Se seus dados mudam com frequência, defina chaves primárias no seu serviço de busca. Isso habilita caminhos otimizados de atualização que podem reduzir drasticamente tanto os custos de embedding quanto os tempos de atualização. Sem chaves primárias, qualquer mudança de schema dispara um re-embedding completo de todo o conjunto de dados.

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

Como em qualquer monitoramento de custos no Snowflake, contamos com o schema ACCOUNT_USAGE para acompanhar os gastos com o Cortex Search. Use nossas queries de monitoramento acima como ponto de partida para decidir o que você precisa monitorar e, depois, agende alertas ou relatórios semanais. Fique de olho em picos de créditos de serving (aumento no volume de consultas) e nos custos de embedding durante as atualizações de dados.

O objetivo nem sempre é minimizar custos, e sim extrair valor do seu investimento. Entender esses padrões te ajuda a otimizar tanto a performance quanto o orçamento.

Se você está implementando o Cortex Search, entre em contato. Vou adorar saber quais abordagens de monitoramento funcionam para o seu time.

Jeff é Consultor de Dados e Analytics, com mais de 15 anos de experiência em automatizar insights e usar dados para controlar processos de negócio. Do ponto de vista de tecnologia, é especialista em Snowflake + dbt + Tableau. Do ponto de vista de negócio, tem experiência em Serviços Públicos, Ensaios Clínicos, Editorial, CPG e Manufatura. Fique à vontade para entrar em contato a qualquer momento: [email protected].