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'
EMBEDDING_MODEL = 'snowflake-arctic-embed-l-v2.0'
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 na 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.
Você também pode usar a função de tabela CORTEX_SEARCH_DATA_SCAN para inspecionar o conteúdo do serviço.
SELECT
*
FROM
TABLE (
CORTEX_SEARCH_DATA_SCAN (
SERVICE_NAME => 'transcript_search_service'
)
);
+ ---------------------------------------------------------- + --------------- + -------- + ------------------------------ +
| transcript_text | region | agent_id | _GENERATED_EMBEDDINGS_MY_MODEL |
| ---------------------------------------------------------- | --------------- | -------- | ------------------------------ |
| 'My internet has been down since yesterday, can you help?' | 'North America' | 'AG1001' | [0.1, 0.2, 0.3, 0.4] |
| 'I was overcharged for my last bill, need an explanation.' | 'Europe' | 'AG1002' | [0.1, 0.2, 0.3, 0.4] |
+ ---------------------------------------------------------- + --------------- + -------- + ------------------------------ +
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 faz a consulta deve ter privilégios USAGE no próprio serviço, bem como no banco de dados e 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.
Importante
O Cortex Search Services realiza buscas com os direitos do proprietário e seguem o mesmo modelo de segurança de outros objetos Snowflake executados com os direitos do proprietário. Para obter mais informações, consulte Requisitos de controle de acesso do Cortex Search
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.
Modelos de incorporação do Cortex Search¶
O Cortex Search permite que os usuários selecionem um modelo de incorporação hospedado para ser aproveitado no estágio de pesquisa vetorial da recuperação. Os seguintes modelos de incorporação estão disponíveis no Cortex Search.
Importante
O preço do modelo varia. O preço do modelo canônico está disponível na Snowflake Service Consumption Table. Se um preço mostrado abaixo diferir do preço mostrado para o modelo na Snowflake Service Consumption Table, o preço da tabela prevalecerá.
Nome do modelo |
Dimensões de saída |
Suporte a idiomas |
Custo de crédito por 1 milhão de tokens |
Descrição |
---|---|---|---|---|
|
768 |
Somente em inglês |
0,03 |
O modelo de incorporação mais prático do Snowflake, somente em inglês. Esse modelo de código aberto, com 110 milhões de parâmetros, produz os tempos de indexação mais rápidos dos modelos disponíveis no Cortex Search. Para obter mais informações, consulte a postagem no blog Arctic Embed 1.5 e o cartão do modelo Arctic Embed 1.5. |
|
1024 |
Multilíngue |
0,05 |
Modelo de incorporação multilíngue da Snowflake com excelente relação custo-desempenho. Esse modelo de código aberto e 568 milhões de parâmetros produz alta qualidade em conjuntos de dados em inglês e em outros idiomas. Para obter mais informações, consulte a postagem no blog Arctic Embed 2 e o cartão do modelo Arctic Embed 2. |
|
1024 |
Multilíngue |
0,07 |
Modelo de incorporação multilíngue do Voyage. Esse modelo produz alta qualidade em conjuntos de dados em inglês e em outros idiomas. Para obter mais informações, consulte a postagem do blog Voyage Multilingual 2 |
Alguns modelos de incorporação estão disponíveis apenas em determinadas regiões da nuvem para o Cortex Search. Para obter uma lista de disponibilidade por modelo e por região, consulte Disponibilidade regional do Cortex Search.
Cada modelo tem características diferentes de desempenho, custo e qualidade. Analise cuidadosamente as especificações do modelo para determinar o melhor modelo para sua carga de trabalho específica. Consulte a Snowflake Service Consumption Table para obter uma exibição mais precisa do custo de cada modelo em créditos por milhão de tokens.
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 de texto que pode ser processada por um modelo de linguagem grande. 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, é possível usar a função Cortex COUNT_TOKENS. Por exemplo, calcular os tokens de uma cadeia de caracteres a ser incorporada com o modelo snowflake-arctic-embed-m-v1.5
:
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 Compreensão da inicialização e atualização de tabelas dinâmicas 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 Consultas compatíveis para tabelas dinâmicas.
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 |
Descrição |
---|---|
Computação de warehouse virtual |
Um Cortex Search Service requer um warehouse virtual para atualizar o serviço: para executar consultas em objetos de base quando eles são inicializados e atualizados, incluindo a orquestração de trabalhos de incorporação de texto e a criação do índice de pesquisa. Essas operações usam recursos de computação, que consomem créditos. Se nenhuma alteração for identificada durante uma atualização, os créditos do warehouse virtual não serão consumidos, pois não há novos dados para atualizar. |
Computação de tokens EMBED_TEXT |
Um Cortex Search Service incorpora automaticamente cada linha de texto na coluna de pesquisa especificada no parâmetro |
Computação de serviços |
Um Cortex Search Service usa computação de serviço multilocatário, separada de um warehouse virtual fornecido pelo usuário, para estabelecer um serviço de baixa latência e alta taxa de transferência. O custo de computação para esse componente é incorrido por GB por mês (GB/mo) de dados indexados não compactados, em que os dados indexados são os dados fornecidos pelo usuário na consulta de origem do Cortex Search, além de incorporações de vetor computados em nome do usuário. Você incorre nesses custos enquanto o serviço estiver disponível para responder às consultas, mesmo que nenhuma consulta seja atendida durante um determinado período. Para obter a taxa de crédito de serviços do Cortex Search por GB/mo de dados indexados, consulte a Snowflake Service Consumption Table. |
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). |
Computação de serviços de nuvem |
Os Cortex Search Services usam a computação dos serviços de nuvem para identificar alterações nos objetos de base subjacentes e se o warehouse virtual precisa ser chamado. 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. |
Para obter as práticas recomendadas de gerenciamento de custos de um Cortex Search Service, consulte Entendendo o custo dos Cortex Search Services.
Para visualizar os custos de consumo relacionados ao serviços de AI para cada Cortex Search Service em sua conta, agregados diariamente, consulte a exibição CORTEX_SEARCH_DAILY_USAGE_HISTORY
Limitações conhecidas¶
O uso do Cortex Search está sujeito às seguintes limitações:
Tamanho da tabela base: o resultado da consulta materializada no serviço de pesquisa deve ter menos de 100 milhões de linhas para manter o desempenho ideal do serviço. Se o resultado materializado de sua consulta tiver mais de 100 milhões de linhas, a consulta de criação falhará com um erro.
Nota
Para aumentar os limites de escala de linha em um Cortex Search Service acima de 100 milhões, 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 da tabela dinâmica 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ê criar, duas entidades de tabela dinâmica aparecerão na UI de monitoramento 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. A seleção de uma dessas entidades no UI do Snowsight produz a 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 a esse recurso está disponível para contas nas seguintes regiões Snowflake. A disponibilidade de modelos de incorporação específicos em uma região é indicada por uma marca de seleção.
Provedor de nuvem
|
Região
|
snowflake-arctic-embed-m-v1.5 |
snowflake-arctic-embed-l-v2.0 |
voyage-multilingual-2 |
---|---|---|---|---|
AWS
|
US West 2 (Oregon)
|
✔ |
✔ |
✔ |
AWS
|
US East 2 (Ohio)
|
✔ |
✔ |
|
AWS
|
US East 1 (N. Virginia)
|
✔ |
✔ |
✔ |
AWS
|
Canada (Central)
|
✔ |
✔ |
|
AWS
|
South America (São Paulo)
|
✔ |
✔ |
|
AWS
|
Europe (Ireland)
|
✔ |
✔ |
|
AWS
|
Europe (London)
|
✔ |
✔ |
|
AWS
|
Europe Central 1 (Frankfurt)
|
✔ |
✔ |
✔ |
AWS
|
Europa (Estocolmo)
|
✔ |
✔ |
|
AWS
|
Asia Pacific (Tokyo)
|
✔ |
✔ |
✔ |
AWS
|
Asia Pacific (Mumbai)
|
✔ |
✔ |
|
AWS
|
Asia Pacific (Sydney)
|
✔ |
✔ |
|
AWS
|
Ásia Pacífico (Jakarta)
|
✔ |
✔ |
|
AWS
|
Asia Pacific (Seoul)
|
✔ |
✔ |
|
Azure
|
East US 2 (Virginia)
|
✔ |
✔ |
|
Azure
|
West US 2 (Washington)
|
✔ |
✔ |
|
Azure
|
South Central US (Texas)
|
✔ |
✔ |
|
Azure
|
UK Sul (Londres)
|
✔ |
✔ |
|
Azure
|
North Europe (Ireland)
|
✔ |
✔ |
|
Azure
|
West Europe (Netherlands)
|
✔ |
✔ |
✔ |
Azure
|
Switzerland North (Zürich)
|
✔ |
✔ |
|
Azure
|
Central India (Pune)
|
✔ |
✔ |
|
Azure
|
Japan East (Tokyo, Saitama)
|
✔ |
✔ |
|
Azure
|
Southeast Asia (Singapore)
|
✔ |
✔ |
|
Azure
|
Australia East (New South Wales)
|
✔ |
✔ |
|
GCP
|
Europe West 2 (London)
|
✔ |
✔ |
|
GCP
|
Europe West 3 (Frankfurt)
|
✔ |
✔ |
|
GCP
|
Europe West 4 (Netherlands)
|
✔ |
✔ |
|
GCP
|
Oriente Médio Central 2 (Dammam)
|
✔ |
✔ |
|
GCP
|
US Central 1 (Iowa)
|
✔ |
✔ |
|
GCP
|
US East 4 (N. Virginia)
|
✔ |
✔ |
Nota
Você pode especificar o parâmetro de inferência entre regiões em qualquer uma das regiões acima para acessar modelos que não são diretamente compatíveis com sua região padrão.
O Cortex Search está disponível nas seguintes regiões apenas usando a inferência entre regiões. Para usar o Cortex Search com inferência entre regiões, use o parâmetro de inferência entre regiões.
AWS Europe (Paris)
Europa AWS (Zurique)
AWS Asia Pacific (Singapore)
AWS Asia Pacific (Osaka)
Azure Canada Central (Toronto)
Azure Central US (Iowa)
Azure UAE North (Dubai)
Nota
Ao usar a inferência entre regiões, a latência da consulta entre regiões depende da infraestrutura do provedor de nuvem e do status da rede. A Snowflake recomenda que você teste seu caso de uso específico com a inferência entre regiões habilitada.
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 |
As funções disponíveis ao público em geral são recursos de AI cobertos. As funções em versão preliminar são recursos de AI em versão preliminar. [1] |
Para obter informações adicionais, consulte AI e ML Snowflake.