SELECTSELECT

SELECT

Snowflake Cortex Search: guía completa, precios y monitoreo de costos

By Jeff SkoldbergOct 9, 20257 min read

Esta página también está disponible en English, Deutsch, Français, Italiano, 日本語 y Português.

Cortex Search de Snowflake es un servicio de búsqueda híbrida totalmente administrado que combina búsqueda vectorial, por palabras clave y semántica. Está pensado para crear aplicaciones de RAG (Retrieval Augmented Generation) y soluciones de búsqueda empresarial: Snowflake se encarga de toda la infraestructura de embeddings, indexación y serving en segundo plano. A diferencia de la búsqueda tradicional por palabras clave, que solo busca coincidencias exactas, Cortex Search se apoya en el significado semántico del patrón de búsqueda frente al texto. Un usuario puede buscar "problemas de facturación" en una base de datos de atención al cliente y obtener todos los tickets relacionados con ese tema, aunque esa frase no aparezca literalmente en el texto.

Nuestros clientes vienen usando Cortex Search a fondo, y una de las preguntas más frecuentes que recibo es: "¿Cómo hago para saber cuánto me está costando realmente?"

El reto con Cortex Search es que su estructura de costos es más compleja que la de los servicios tradicionales de Snowflake. A diferencia de un warehouse que enciendes y apagas, Cortex Search tiene varios componentes de costo corriendo en paralelo. Sin un monitoreo adecuado, te puedes encontrar con una factura inesperadamente alta.

Veamos cómo funciona Cortex Search y luego repasemos los componentes de facturación y el monitoreo.

Por debajo, Cortex Search usa un enfoque híbrido que combina búsqueda vectorial (con los modelos Arctic Embed de Snowflake), búsqueda por palabras clave y reranking semántico para entregar resultados altamente relevantes. Cuando creas un servicio, Snowflake gestiona automáticamente la generación de embeddings, la indexación y la infraestructura de serving, transformando los datos de origen para servirlos con baja latencia.

Acá va un ejemplo práctico de cómo configurar y usar Cortex Search para tickets de soporte al 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 ves, nos apoyamos en la IA para interpretar "Problemas de facturación" y devolver las filas correctas.

La función SEARCH_PREVIEW devuelve resultados en JSON que incluyen una puntuación de relevancia por cada coincidencia. Con PARSE_JSON y FLATTEN obtienes una salida tabular limpia que muestra qué transcripciones son más relevantes para tu consulta, junto con sus metadatos y puntuaciones de confianza. Eso facilita integrar los resultados de búsqueda en aplicaciones o en análisis posteriores en SQL.

También puedes aplicar filtros por columnas de metadatos como región o periodos de tiempo, lo que resulta ideal para escenarios donde se necesita comprensión semántica y filtrado estructurado a la vez:

-- 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 tiene 5 componentes de Precios:

  1. Compute de serving: 6.3 créditos por GB/mes de datos indexados (se ejecuta de forma continua, hagas consultas o no)
  2. Tokens de embedding: costo por millón de tokens de texto en las columnas de búsqueda durante la indexación. Varía según el modelo. Consulta la tabla de consumo de créditos de Snowflake para conocer el costo de cada modelo. Ejemplo de Precios a septiembre de 2025:
  3. snowflake-arctic-embed-l-v2.0: 0.05 créditos por millón de tokens. ¡Es uno de los servicios de IA más económicos de Snowflake!
  4. Compute de warehouse: precios estándar de warehouse para materializar y refrescar los datos de búsqueda y ejecutar consultas
  5. Almacenamiento: los índices de búsqueda generan costos de almacenamiento al precio estándar (por ejemplo, $23/TB/mes)
  6. Servicios en la nube: normalmente gratis (solo se cobra si supera el 10% del uso diario de warehouse)

Ejemplo real: 10 millones de tickets de soporte al cliente, con un promedio de 500 tokens cada uno, usando un modelo de embedding que cuesta 0.32 créditos por millón de tokens:

  • Total de tokens: 10 millones de filas × 500 tokens = 5 mil millones de tokens
  • Costo de embedding: 5 mil millones de tokens ÷ 1 millón × 0.05 créditos = 250 créditos para la indexación inicial
    • A $3 por crédito, son $750
  • Más el serving continuo: si tu índice pesa 50 GB, son 50 × 6.3 = 315 créditos/mes solo por mantenerlo activo
    • $945 a $3 por crédito.

A diferencia de los warehouses, que se pueden suspender, los costos de serving de Cortex Search se acumulan de forma continua. Un índice de 100 GB cuesta 630 créditos al mes (alrededor de $1,890 a $3 por crédito), sin importar el volumen de consultas. Lo pagas aunque nadie busque nada.

Cómo monitorear los costos y el uso de Cortex Search

Snowflake ofrece dos vistas dedicadas en el esquema ACCOUNT_USAGE para hacer seguimiento de los costos de Cortex Search. La vista CORTEX_SEARCH_DAILY_USAGE_HISTORY desglosa los costos diarios por tipo de consumo (serving vs. embedding), mientras que CORTEX_SEARCH_SERVING_USAGE_HISTORY entrega el detalle por hora de los créditos de serving para detectar patrones de uso.

Ejemplo diario:

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

Como ves, una salida clave es consuption_type, que toma el valor embed_text_tokens o serving.

Ejemplo 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 puedes ver, es un agregado bastante básico de créditos por hora.

Tras acompañar a varios equipos en la implementación del monitoreo de costos de Cortex Search, estas son mis recomendaciones clave:

Configura alertas, no solo dashboards

Las consultas de monitoreo de arriba no sirven de nada si nadie las ejecuta. Para cualquier cosa que quieras monitorear en Snowflake, puedes envolver el SQL en una tarea programada con una Notification Integration y crear un monitor personalizado que envíe alertas a Slack o Teams. Si buscas un monitoreo realmente fácil de usar, échale un vistazo a los monitors de SELECT.

Suspende los servicios durante el desarrollo

A diferencia de los warehouses, que se pueden suspender automáticamente, los servicios de Cortex Search acumulan costos de serving las 24 horas, los 7 días de la semana. Durante el desarrollo y las pruebas, suspende tus servicios de búsqueda cuando no los estés usando activamente. Se reanudan en minutos, pero esos cargos continuos de serving se suman rápido.

Dimensiona tus índices con criterio

Cada columna que incluyas en tu servicio de búsqueda, ya sea buscable o solo un atributo, suma a tus costos de serving. No incluyas columnas "por si acaso". Empieza con lo mínimo y agrega columnas solo cuando las necesites. La diferencia de costo entre un índice de 10 GB y uno de 100 GB es enorme.

Monitorea por separado los costos del modelo de embedding

Revisa la columna CONSUMPTION_TYPE en la vista de uso diario para distinguir los costos de serving de los de embedding. Los picos de embedding suelen indicar patrones de refresco ineficientes o reconstrucciones completas innecesarias. Si ves costos de embedding altos de forma sostenida, revisa tus patrones de actualización de datos.

Optimiza tus servicios de Cortex Search

Los costos de búsqueda dependen mucho de cómo configures el servicio. Sigue estas pautas:

Define target lags adecuados. Si tus documentos no cambian con frecuencia, usa intervalos de refresco más largos:

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

Filtra el alcance de la búsqueda cuando sea posible. Si los agentes solo necesitan documentos recientes, agrega 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())
  ...

Usa claves primarias para actualizaciones incrementales

Si tus datos cambian con frecuencia, define claves primarias en tu servicio de búsqueda. Eso habilita rutas de refresco optimizadas que pueden reducir drásticamente tanto los costos de embedding como los tiempos de refresco. Sin claves primarias, cualquier cambio de esquema dispara un re-embedding completo de todo tu 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
    );

Para cerrar

Como en cualquier monitoreo de costos en Snowflake, nos apoyamos en el esquema ACCOUNT_USAGE para hacer seguimiento del gasto en Cortex Search. Toma las consultas de monitoreo de arriba como punto de partida para decidir qué necesitas vigilar y, a partir de ahí, programa alertas o reportes semanales. Mantente atento a los picos de créditos de serving (más volumen de consultas) y a los costos de embedding durante las actualizaciones de datos.

El objetivo no siempre es minimizar costos, sino sacarle valor a tu gasto. Entender estos patrones te ayuda a optimizar tanto el rendimiento como el presupuesto.

Si estás implementando Cortex Search, escríbeme. Me encantaría saber qué enfoques de monitoreo le funcionan a tu equipo.

Jeff es Consultor de Datos y Analítica con más de 15 años de experiencia automatizando insights y usando datos para controlar procesos de negocio. En lo tecnológico, se especializa en Snowflake + dbt + Tableau. En lo sectorial, tiene experiencia en Servicios Públicos, Ensayos Clínicos, Editorial, CPG y Manufactura. Escríbele cuando quieras a [email protected].