Cortex Search¶
Visão geral¶
O Cortex Search permite uma pesquisa “difusa” de baixa latência e alta qualidade em seus dados Snowflake. O Cortex Search oferece uma ampla matriz de experiências de pesquisa para usuários do Snowflake, incluindo aplicativos Retrieval Augmented Generation (RAG) que aproveitam os Grandes modelos de linguagem (LLMs).
O Cortex Search permite que você comece a usar um mecanismo de busca híbrido (vetor e palavra-chave) em seus dados de texto em minutos, sem precisar se preocupar com incorporação, manutenção de infraestrutura, ajuste de parâmetro de qualidade de pesquisa ou atualizações contínuas de índice. Isso significa que você pode gastar menos tempo em infraestrutura e ajuste de qualidade de pesquisa e mais tempo desenvolvendo experiências de bate-papo e pesquisa de alta qualidade usando seus dados. Confira os tutoriais do Cortex Search para obter instruções passo a passo sobre como usar o Cortex Search para potencializar aplicativos de bate-papo de AI e pesquisa.
Quando usar o Cortex Search¶
Os dois principais casos de uso do Cortex Search são geração aumentada de recuperação (RAG) e pesquisa empresarial.
Mecanismo RAG para chatbotsLLM: use o Cortex Search como um mecanismo RAG para aplicativos de bate-papo com seus dados de texto, aproveitando a pesquisa semântica para obter respostas personalizadas e contextualizadas.
Pesquisa corporativa: use o Cortex Search como um backend para uma barra de pesquisa de alta qualidade incorporada ao seu aplicativo.
Cortex Search para RAG¶
A geração aumentada de recuperação (RAG) é uma técnica para recuperar dados de uma base de conhecimento para aprimorar a resposta gerada de um grande modelo de linguagem. O diagrama de arquitetura a seguir mostra como você pode combinar o Cortex Search com o Cortex LLM Functions para criar chatbots corporativos com RAG usando seus dados do Snowflake como base de conhecimento.

O Cortex Search é o mecanismo de recuperação que fornece ao Grande modelo de linguagem o contexto necessário para retornar respostas baseadas em seus dados proprietários mais atualizados.
Exemplo¶
Este exemplo mostra as etapas de criação de um Cortex Search Service e sua consulta usando a RESTAPI. Consulte o tópico Como consultar o Cortex Search Service para obter mais detalhes sobre consultas ao serviço.
Este exemplo usa um amostra de conjunto de dados de transcrição de suporte ao cliente.
Execute os seguintes comandos para configurar o banco de dados de exemplo e o esquema.
CREATE DATABASE IF NOT EXISTS cortex_search_db;
CREATE OR REPLACE WAREHOUSE cortex_search_wh WITH
WAREHOUSE_SIZE='X-SMALL';
CREATE OR REPLACE SCHEMA cortex_search_db.services;
Execute os seguintes comandos SQL para criar o conjunto de dados.
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');
O rastreamento de alterações é necessário para criar o Cortex Search Service. Se você for usar uma função que não tenha propriedade desta tabela para criar o serviço de pesquisa, execute a seguinte instrução para habilitar o rastreamento de alterações na tabela:
ALTER TABLE support_transcripts SET
CHANGE_TRACKING = TRUE;
Para obter detalhes sobre como habilitar o rastreamento de alterações, consulte Habilitar o rastreamento de alterações.
Criação do serviço¶
Você pode criar um Cortex Search Service com uma única consulta SQL ou do Snowflake AI & ML Studio. Quando você cria um Cortex Search Service, o Snowflake realiza transformações em seus dados de origem para prepará-los para distribuição de baixa latência. As seções a seguir mostram como criar um serviço usando ambos SQL e no Snowflake AI & ML Studio em Snowsight.
Nota
Quando você cria um serviço de pesquisa, o índice de pesquisa é criado como parte do processo de criação. Isso significa que a instrução CREATECORTEXSEARCHSERVICE pode levar mais tempo para ser concluída para conjuntos de dados maiores.
Uso de SQL¶
O exemplo a seguir demonstra como criar um Cortex Search Service com CREATE CORTEX SEARCH SERVICE o conjunto de dados de transcrição de suporte ao cliente de amostra criado na seção anterior.
CREATE OR REPLACE CORTEX SEARCH SERVICE transcript_search_service
ON transcript_text
ATTRIBUTES region
WAREHOUSE = cortex_search_wh
TARGET_LAG = '1 day'
AS (
SELECT
transcript_text,
region,
agent_id
FROM support_transcripts
);
Este comando aciona a construção do serviço de pesquisa para seus dados. Neste exemplo:
Consultas ao serviço procurarão correspondências na coluna
transcript_text
.O parâmetro
TARGET_LAG
determina que o Cortex Search Service verificará atualizações na tabela basesupport_transcripts
aproximadamente uma vez por dia.As colunas
region
eagent_id
serão indexadas para que possam ser retornadas junto com os resultados das consultas na colunatranscript_text
.A coluna
region
estará disponível como uma coluna de filtro ao consultar a colunatranscript_text
.O warehouse
cortex_search_wh
será usado para materializar os resultados da consulta especificada inicialmente e sempre que a tabela base for alterada.
Nota
Dependendo do tamanho do warehouse especificado na consulta e do número de linhas na sua tabela, esse comando CREATE pode levar várias horas para ser concluído.
A Snowflake recomenda usar um warehouse dedicado de tamanho não maior que MEDIUM para cada serviço.
As colunas no campo ATTRIBUTES devem ser incluídas na consulta de origem, por meio de enumeração explícita ou curinga, (
*
).
Uso de Snowsight¶
Siga estas etapas para criar um Cortex Search Service em Snowsight:
Faça login no Snowsight.
Escolha uma função que tenha a função de banco de dados SNOWFLAKE.CORTEX_USER concedida.
No menu de navegação, selecione AI & ML » Studio.
Selecione + Create da caixa Create a Cortex Search Service.
Selecione uma função e um warehouse. A função deve receber a função de banco de dados SNOWFLAKE.CORTEX_USER. O warehouse é usado para materializar os resultados da consulta de origem quando o serviço é criado e atualizado.
Selecione um banco de dados e um esquema no qual o serviço é definido.
Insira um nome para o seu serviço e selecione Let’s go.
Selecione a tabela ou exibição que contém os dados de texto a serem indexados para pesquisa e selecione Next. Para este exemplo, selecione a tabela
support_transcripts
.Nota
Se você quiser especificar várias fontes de dados ou executar transformações ao definir seu serviço, use SQL.
Selecione as colunas que você deseja incluir nos resultados de pesquisa,
transcript_text
,region
eagent_id
, e depois selecione Next.Selecione a coluna que será pesquisada,
transcript_text
, depois selecione Next.Se você quiser filtro os resultados da sua pesquisa com base em uma ou mais colunas específicas, selecione essas colunas e depois selecione Next. Se você não precisar de nenhum filtro, selecione Skip this option. Neste exemplo, você pode pular esta etapa.
Defina seu atraso de destino, que é a quantidade de tempo que o conteúdo do seu serviço deve ficar atrás das atualizações dos dados base, e então selecione Create search service.
A etapa final confirma que seu serviço foi criado e exibe o nome do serviço e sua fonte de dados.
Nota
Quando você cria o serviço a partir de Snowsight, o nome do serviço fica entre aspas duplas. Para obter detalhes sobre o que isso significa ao fazer referência ao serviço em SQL, consulte Identificadores entre aspas duplas.
Concessão de permissões de uso¶
Depois que o serviço e o índice forem criados, você pode conceder uso no serviço, seu banco de dados e esquema para outras funções, como customer_support.
GRANT USAGE ON DATABASE cortex_search_db TO ROLE customer_support;
GRANT USAGE ON SCHEMA services TO ROLE customer_support;
GRANT USAGE ON CORTEX SEARCH SERVICE transcript_search_service TO ROLE customer_support;
Pré-visualização do serviço¶
Para confirmar se o serviço está preenchido com dados corretamente, você pode visualizar o serviço por meio da função SEARCH_PREVIEW de um ambiente SQL:
SELECT PARSE_JSON(
SNOWFLAKE.CORTEX.SEARCH_PREVIEW(
'cortex_search_db.services.transcript_search_service',
'{
"query": "internet issues",
"columns":[
"transcript_text",
"region"
],
"filter": {"@eq": {"region": "North America"} },
"limit":1
}'
)
)['results'] as results;
Exemplo de resposta de consulta bem-sucedida:
[
{
"transcript_text" : "My internet has been down since yesterday, can you help?",
"region" : "North America"
}
]
Esta resposta confirma que o serviço está preenchido com dados e fornece resultados razoáveis para a consulta fornecida.
Consulta do serviço do seu aplicativo¶
Depois de criar o serviço de pesquisa, conceder uso a ele para sua função e visualizá-lo, agora você pode consulta -lo em seu aplicativo usando o API Python.
O código a seguir mostra o uso da API Python para recuperar o tíquete de suporte mais relevante para uma consulta sobre internet issues
, filtrado para retornar resultados na região North America
:
from snowflake.core import Root
from snowflake.snowpark import Session
CONNECTION_PARAMETERS = {"..."}
session = Session.builder.configs(CONNECTION_PARAMETERS).create()
root = Root(session)
transcript_search_service = (root
.databases["cortex_search_db"]
.schemas["services"]
.cortex_search_services["transcript_search_service"]
)
resp = transcript_search_service.search(
query="internet issues",
columns=["transcript_text", "region"],
filter={"@eq": {"region": "North America"} },
limit=1
)
print(resp.to_json())
Exemplo de resposta de consulta bem-sucedida:
{
"results": [
{
"transcript_text": "My internet has been down since yesterday, can you help?",
"region": "North America"
}
],
"request_id": "5d8eaa5a-800c-493c-a561-134c712945ba"
}
O Cortex Search Services retorna todas as colunas especificadas no campo columns
da sua consulta.
Privilégios obrigatórios¶
Para criar um Cortex Search Service, sua função deve ter a função de banco de dados CORTEX_USER necessária para o Cortex LLM Functions. Para obter informações sobre como conceder e revogar essa função, consulte Privilégios obrigatórios para Cortex LLM Functions.
Para consultar um Cortex Search Service, a função do usuário que efetua a consulta deve ter privilégios USAGE no próprio serviço, bem como no banco de dados e no esquema em que o serviço reside. Consulte os Requisitos de controle de acesso do Cortex Search Access.
Para suspender ou retomar um Cortex Search Service usando o comando ALTER, a função do usuário que faz a consulta deve ter o privilégio OPERATE no serviço. Consulte ALTER CORTEX SEARCH SERVICE.
Como entender a qualidade do Cortex Search¶
O Cortex Search utiliza um conjunto de modelos de recuperação e classificação para fornecer um alto nível de qualidade de pesquisa com pouca ou nenhuma necessidade de ajuste. Internamente, o Cortex Search adota uma abordagem “híbrida” para recuperar e classificar documentos. Cada consulta de pesquisa utiliza:
Pesquisa vetorial para recuperar documentos semanticamente semelhantes.
Pesquisa por palavra-chave para recuperar documentos lexicamente semelhantes.
Reclassificação semântica para reclassificar os documentos mais relevantes no conjunto de resultados.
Essa abordagem de recuperação híbrida, juntamente com uma etapa de reclassificação semântica, alcança alta qualidade de pesquisa em uma ampla gama de conjuntos de dados e consultas.
Limites de token e divisão de texto¶
Para obter resultados de pesquisa ideais com o Cortex Search, a Snowflake recomenda dividir o texto na sua coluna de pesquisa em partes de, no máximo, 512 tokens (cerca de 385 palavras em inglês). Quando uma entrada na coluna de pesquisa contém mais de 512 tokens, o Cortex Search executa a recuperação baseada em palavras-chave em todo o corpo do texto, mas usa apenas os primeiros 512 tokens para recuperação semântica (ou seja, baseada em vetores).
Um token é uma sequência de caracteres e é a menor unidade que pode ser processada por um grande modelo de linguagem. Como aproximação, um token é equivalente a cerca de 3/4 de uma palavra em inglês, ou cerca de 4 caracteres. Para calcular o número exato de tokens em uma cadeia de caracteres, você pode usar a TOKEN_COUNT Cortex Function com o parâmetro modelo snowflake-arctic-embed-m
da seguinte maneira:
SELECT SNOWFLAKE.CORTEX.COUNT_TOKENS('snowflake-arctic-embed-m', '<input_text>') as token_count
Como entender os limites do token de pesquisa semântica¶
A recomendação para blocos de tamanho 512 tokens ou menos é motivada por pesquisas que mostram que uma parte de tamanho menor normalmente resulta em maior recuperação e qualidade de resposta de LLM downstream. Embora existam modelos de incorporação de contexto mais longo disponíveis hoje, como arctic-embed-m-long, o Cortex Search opta por um modelo de incorporação com uma janela de contexto menor para fornecer maior qualidade de pesquisa imediatamente.
A intuição por trás desse conceito é que, com partes menores, a recuperação pode ser mais precisa para uma determinada consulta. Isso ocorre porque há menos tokens para “calcular a média” ao gerar incorporações vetoriais para a parte e a consulta. Além disso, com partes menores, o LLM downstream pode receber apenas as informações necessárias, pois há menos texto potencialmente ruidoso fornecido no prompt para o modelo.
Você pode encontrar pesquisas aqui mostrando que partes menores geralmente têm melhor desempenho em conjuntos de dados de referência públicos no estilo perguntas e respostas.
Atualizações¶
O conteúdo exibido em um Cortex Search Service é baseado nos resultados de uma consulta específica. Quando os dados subjacentes a um Cortex Search Service mudam, o serviço é atualizado para refletir essas alterações. Essas atualizações são chamadas de atualização. Este processo é automatizado e envolve a análise da consulta que está subjacente à tabela.
Os Cortex Search Services têm as mesmas propriedades de atualização das tabelas dinâmicas. Consulte o tópico Como é feita a atualização de tabela dinâmica para entender as características de atualização de um Cortex Search Service.
A consulta de origem para um Cortex Search Service deve ser candidata à atualização incremental de tabela dinâmica. Para obter detalhes sobre esses requisitos, consulte Suporte para atualizações incrementais. Essa restrição foi criada para evitar quaisquer custos indesejados associados à computação de incorporação de vetores. Para obter mais informações sobre as construções que não são suportadas para atualização incremental de tabela dinâmica, consulte Construções, operadores e funções não suportados.
Suspensão de indexação e serviço¶
Semelhante às tabelas dinâmicas, o Cortex Search Services suspenderá automaticamente seu estado de indexação quando encontrar cinco falhas de atualização consecutivas relacionadas à consulta de origem. Se você encontrar essa falha no seu serviço, poderá exibição o erro SQL específico usando DESCRIBE CORTEX SEARCH SERVICE ou Exibição CORTEX_SEARCH_SERVICES. A saída de ambos inclui as seguintes colunas:
A coluna INDEXING_STATE terá o valor de SUSPENDED.
A coluna INDEXING_ERROR conterá o erro SQL específico encontrado na consulta de origem.
Depois que o problema raiz for resolvido, você poderá retomar o serviço com o ALTER CORTEX SEARCH SERVICE <nome> RESUME INDEXING
. Para sintaxe detalhada, consulte ALTER CORTEX SEARCH SERVICE.
Considerações sobre custo¶
Um Cortex Search Service incorre em custo das seguintes maneiras:
Categoria de custo |
Descrição |
---|---|
Serviços de AI - Custos de serviço |
O Cortex Search Services usa computação de serviço multilocatário, separada de um warehouse virtual fornecido pelo usuário, para permitir consultas de pesquisa de baixa latência. O custo de computação é incorrido por GB por mês (GB/mês) de dados indexados, onde dados indexados são os dados fornecidos pelo usuário na consulta de origem do Cortex Search, mais incorporações de vetores computadas em nome do usuário. Nos cálculos de faturamento de serviços, o uso é medido no segundo nível, com uma suposição de 30,5 dias em um mês. Como estimativa, o tamanho dos dados indexados em bytes é aproximadamente igual a Os custos de atendimento do Cortex Search podem ser observados na exibição CORTEX_SEARCH_SERVING_USAGE_HISTORY, que fornece o consumo de token de atendimento por hora para cada Cortex Search Service em sua conta. Os custos de atendimento do Cortex Search também estão incluídos no total de AI_SERVICES da exibição METERING_HISTORY. Para a taxa de crédito por GB/mês de dados indexados, consulte a Tabela de consumo de serviço Snowflake. |
Serviços AI - Custos de incorporação |
O Cortex Search Services incorpora cada documento na coluna de pesquisa no espaço vetorial usando a função SNOWFLAKE.CORTEX.EMBED_TEXT_768 LLM, que incorre em um custo de crédito por token incorporado. As incorporações são processadas incrementalmente na avaliação da consulta de origem, de modo que o custo de incorporação é incorrido apenas para documentos adicionados ou alterados. Para mais detalhes sobre os custos de incorporação de vetores, consulte Incorporações de vetor. |
Computação de warehouse virtual |
Os Cortex Search Services exigem um warehouse virtual fornecido pelo usuário. Este warehouse incorre em custo quando o usuário cria o serviço e cada vez que o serviço é atualizado. |
Armazenamento |
O Cortex Search Services materializa a consulta de origem em uma tabela armazenada em sua conta. Esta tabela é transformada em estruturas de dados otimizadas para serviços de baixa latência, também armazenadas em sua conta. O armazenamento da tabela e das estruturas de dados intermediárias é baseado em uma taxa fixa por terabyte (TB). |
Serviços de computação em nuvem |
O Cortex Search Services usa serviços de nuvem para acionar atualizações quando um objeto base subjacente é alterado. O custo de computação dos serviços de nuvem está sujeito à restrição de que a Snowflake cobra apenas se o custo diário dos serviços de nuvem for superior a 10% do custo diário do warehouse da conta. |
Dica
A Snowflake recomenda usar um tamanho de warehouse não maior do que MEDIUM para o Cortex Search Service. Esta recomendação pode não se aplicar no futuro devido a futuras atualizações do produto.
Limitações conhecidas¶
O uso do Cortex Search está sujeito às seguintes limitações:
Linguagem com suporte: o recurso é otimizado para documentos e consultas em inglês.
Tamanho da tabela base: o resultado da consulta materializada no serviço de pesquisa deve ter menos de 50 milhões de linhas para manter o desempenho de serviço ideal. Se o resultado materializado da sua consulta tiver mais de 50 milhões de linhas, a consulta de criação apresentará erro.
Nota
Para aumentar os limites de escala de linha em um Cortex Search Service acima de 50 m, entre em contato com sua equipe de conta Snowflake.
Construções de consulta: as consultas de origem do Cortex Search Service devem obedecer às mesmas restrições de consulta que as tabelas dinâmicas. Consulte Limitações conhecidas para tabelas dinâmicas para obter mais detalhes.
Replicação e clonagem: o Cortex Search Services não oferece suporte para replicação ou clonagem. O suporte para esses recursos estará disponível em uma lançamento futuro.
Importante
Para cada Cortex Search que você cria, há duas entidades de tabela dinâmica que aparecem na UI de monitoramento do Snowsight para tabelas dinâmicas. Essas duas entidades têm o formato _CORTEX_SEARCH_SOURCE_*
e _CORTEX_SEARCH_REFRESH_*
. Essas entidades também aparecem em exibições de esquema de informações de tabela dinâmica, mas não aparecem em comandos SHOW/DESC em tabelas dinâmicas. Ao clicar em uma dessas entidades na UI Snowsight, há uma mensagem Dynamic Table not found
. Este é um comportamento esperado. As entidades relacionadas ao Cortex Search serão removidas do UI de monitoramento das tabelas dinâmicas do Snowsight em versões futuras do produto.
Disponibilidade regional¶
O suporte para esse recurso está disponível para contas nas seguintes regiões do Snowflake:
AWS |
Azure |
GCP |
---|---|---|
US West 2 (Oregon) |
East US 2 (Virginia) |
Europe West 2 (London) |
US East 2 (Ohio) |
South Central US (Texas) |
Europe West 3 (Frankfurt) |
US East 1 (N. Virginia) |
UK Sul (Londres) |
Europe West 4 (Netherlands) |
Canada (Central) |
North Europe (Ireland) |
US Central 1 (Iowa) |
South America (São Paulo) |
West Europe (Netherlands) |
US East 4 (N. Virginia) |
Europe (Ireland) |
Switzerland North (Zürich) |
|
Europe (London) |
Central India (Pune) |
|
Europe Central 1 (Frankfurt) |
Japan East (Tokyo, Saitama) |
|
Europa (Estocolmo) |
Southeast Asia (Singapore) |
|
Asia Pacific (Tokyo) |
Australia East (New South Wales) |
|
Asia Pacific (Mumbai) |
||
Asia Pacific (Sydney) |
||
Ásia Pacífico (Jakarta) |
||
Asia Pacific (Seoul) |
Avisos legais¶
A classificação dos dados de entradas e saídas é definido na tabela a seguir.
Classificação de dados de entrada |
Classificação de dados de saída |
Designação |
---|---|---|
Usage Data |
Customer Data |
Covered AI Features [1] |
Para obter informações adicionais, consulte AI e ML Snowflake.