Cortex Search¶
概述¶
Cortex Search 支持对 Snowflake 数据进行低延迟、高质量的“模糊”搜索。Cortex Search 为 Snowflake 用户提供了广泛的搜索体验,包括利用大型语言模型 (LLMs) 的 检索增强生成 (RAG) (link removed) 应用程序。
使用 Cortex Search 只需几分钟即可在文本数据上运行混合(矢量和关键字)搜索引擎,而无需担心嵌入、基础设施维护、搜索质量参数调整或持续索引刷新等问题。这意味着可以将更少的时间用于基础设施和搜索质量调整,将更多的时间用于使用数据开发高质量的聊天和搜索体验。查看 Cortex Search 教程,了解使用 Cortex Search 为 AI 聊天和搜索应用程序提供支持的分步说明。
何时使用 Cortex Search¶
Cortex Search 的两个主要用例是检索增强生成 (RAG) 和企业搜索。
用于 LLM 聊天机器人的 RAG 引擎:通过利用语义搜索提供自定义的上下文响应,将 Cortex Search 用作文本数据聊天应用程序的 RAG 引擎。
企业搜索:使用 Cortex Search 作为后端,在应用程序中嵌入高质量的搜索栏。
用于 RAG 的 Cortex Search¶
检索增强生成 (RAG) 是一种从知识库中检索数据以增强大型语言模型的生成响应的技术。下面的架构图显示了如何将 Cortex Search 与 Cortex LLM 函数 结合起来,使用 Snowflake 数据作为知识库来创建采用 RAG 的企业聊天机器人。

Cortex Search 是一个检索引擎,可为大型语言模型提供所需的上下文,从而返回基于最新专有数据的答案。
示例¶
此示例将引导您完成创建 Cortex Search 服务并使用 REST API 对其进行查询的步骤。有关查询服务的更多详细信息,请参阅 查询 Cortex Search 服务 主题。
此示例使用一个示例客户支持文本记录数据集。
运行以下命令以设置示例数据库和架构。
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;
运行以下 SQL 命令以创建数据集。
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');
构建 Cortex Search 服务需要变更跟踪。如果要使用没有此表所有权的角色来创建搜索服务,请运行以下语句以启用对表的变更跟踪:
ALTER TABLE support_transcripts SET
CHANGE_TRACKING = TRUE;
有关启用变更跟踪的详细信息,请参阅 启用更改跟踪。
创建服务¶
可以使用单个 SQL 查询或通过 Snowflake AI & ML Studio 创建 Cortex Search 服务。创建 Cortex Search 服务时,Snowflake 会对源数据进行转换,以便为低延迟服务做好准备。以下各节介绍如何使用 SQL 以及在 Snowsight 中通过 Snowflake AI & ML Studio 创建服务。
备注
创建搜索服务时,搜索索引是创建过程的一部分。这意味着对于较大的数据集,CREATE CORTEX SEARCH SERVICE 语句可能需要更长的时间才能完成。
使用 SQL¶
下面的示例演示了如何使用 CREATE CORTEX SEARCH SERVICE 在上一节创建的示例客户支持文本记录数据集上创建 Cortex Search 服务。
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
);
此命令将触发为数据构建搜索服务。在此示例中:
对服务的查询将在
transcript_text
列中搜索匹配项。
TARGET_LAG
参数指示 Cortex Search 服务将大约每天检查一次基表support_transcripts
的更新。系统将对列
region
和agent_id
编制索引,以便与对transcript_text
列的查询结果一起返回。查询
transcript_text
列时,region
列将可用作筛选列。仓库
cortex_search_wh
将用于首次物化指定查询的结果,并且每次基础表发生更改时,都会重新物化查询结果
备注
根据查询中指定的仓库大小和表中的行数,此 CREATE 命令可能需要几个小时才能完成。
Snowflake 建议为每项服务使用大小不超过 MEDIUM 的专用仓库。
必须通过显式枚举或通配符 (
*
) 将 ATTRIBUTES 字段中的列包含在源查询中。
使用 Snowsight¶
按照以下步骤在 Snowsight 中创建 Cortex Search 服务:
登录 Snowsight。
选择被授予 SNOWFLAKE.CORTEX_USER 数据库角色的角色。
在导航菜单中,选择 AI & ML » Studio。
从 Create a Cortex Search Service 框中选择 + Create。
选择角色和仓库。该角色必须获授 SNOWFLAKE.CORTEX_USER 数据库角色。仓库用于在创建和刷新服务时物化源查询的结果。
选择在其中定义服务的数据库和架构。
输入服务名称,然后选择 Let's go。
选择包含要编入索引以进行搜索的文本数据的表或视图,然后选择 Next。对于本示例,请选择
support_transcripts
表。备注
如果要在定义服务时指定多个数据源或执行转换,请 使用 SQL。
选择要包含在搜索结果中的列(
transcript_text
、region
和agent_id
),然后选择 Next。选择要搜索的列(
transcript_text
),然后选择 Next。如果希望能够根据特定列筛选搜索结果,请选择这些列,然后选择 Next。如果不需要任何筛选器,请选择 Skip this option。对于本示例,您可以跳过此步骤。
设置您的目标滞后,即服务内容应滞后于基础数据更新的时间量,然后选择 Create search service。
最后一步确认服务已经创建,并显示服务名称及其数据源。
备注
从 Snowsight 创建服务时,服务的名称将用双引号引起来。有关在 SQL 中引用服务时这意味着什么的详细信息,请参阅 加双引号的标识符。
授予使用权限¶
创建服务和索引后,您可以将服务、其数据库和架构的使用权限授 予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;
预览服务¶
要确认服务已正确填充数据,您可以通过 SQL 环境中的 SEARCH_PREVIEW 函数 预览服务:
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;
成功查询响应示例:
[
{
"transcript_text" : "My internet has been down since yesterday, can you help?",
"region" : "North America"
}
]
该响应确认服务中填充了数据,并为给定查询提供了合理的结果。
从应用程序中查询服务¶
创建搜索服务、将其使用权限授予您的角色并预览之后,现在可以使用 Python API 从应用程序中对其进行查询。
下面的代码显示了使用 Python API 检索与 internet issues
查询最相关的支持票证,并进行筛选以返回 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())
成功查询响应示例:
{
"results": [
{
"transcript_text": "My internet has been down since yesterday, can you help?",
"region": "North America"
}
],
"request_id": "5d8eaa5a-800c-493c-a561-134c712945ba"
}
Cortex Search 服务会返回在查询的 columns
字段中指定的所有列。
所需权限¶
要创建 Cortex Search 服务,您的角色必须具有 Cortex LLM 函数所需的 CORTEX_USER 数据库角色。有关授予和撤消此角色的信息,请参阅 Cortex LLM 函数所需的权限。
要查询 Cortex Search 服务,查询用户的角色必须对服务本身以及服务所在的数据库和架构具有 USAGE 权限。请参阅 Cortex Search 访问控制要求。
要使用 ALTER 命令暂停或恢复 Cortex Search 服务,查询用户的角色必须对该服务具有 OPERATE 权限。请参阅 ALTER CORTEX SEARCH SERVICE。
了解 Cortex Search 质量¶
Cortex Search 利用检索和排名模型的集合提供高水平的搜索质量,几乎无需调整。在后台,Cortex Search 采用“混合”方法来检索和排名文档。每个搜索查询都会使用:
向量搜索,用于检索语义相似的文档。
关键字搜索,用于检索词汇相似的文档。
语义重排,用于对结果集中最相关的文档进行重排。
这种混合检索方法与语义重排步骤相结合,可在各种数据集和查询中实现较高的搜索质量。
词元限制和文本拆分¶
为了使用 Cortex Search 获得最佳搜索结果,Snowflake 建议将搜索列中的文本拆分为不超过 512 个词元(约 385 个英语单词)的块。当搜索列中的条目包含的词元超过 512 个时,Cortex Search 会对整个文本主体执行基于关键字的检索,但仅使用前 512 个词元进行语义(即向量)检索。
词元是一个字符序列,是大型语言模型可以处理的最小单元。作为近似值,一个词元约等于一个英语单词的 3/4,或约 4 个字符。要计算字符串中词元的确切数量,可以使用 TOKEN_COUNT Cortex 函数 以及如下所示的 snowflake-arctic-embed-m
模型参数:
SELECT SNOWFLAKE.CORTEX.COUNT_TOKENS('snowflake-arctic-embed-m', '<input_text>') as token_count
了解语义搜索词元限制¶
之所以建议使用 512 个或更小的块,是因为研究表明,较小的块大小通常会带来更高的检索和 LLM 下游响应质量。虽然目前有更长的上下文嵌入模型(例如 arctic-embed-m-long (link removed)),但 Cortex Search 还是选择了上下文窗口更小的嵌入模型,以提供更高的搜索质量,开箱即用。
这一概念背后的直觉是,使用较小的块,可以更精确地检索给定的查询。这是因为在为块和查询生成向量嵌入时,需要“平均”的词元更少。此外,对于较小的块,下游 LLM 可以只获得其需要的信息,因为在向模型提供的提示中,潜在的噪声文本较少。
您可以在 此处 (https://arxiv.org/pdf/2312.06648) 找到研究结果,这些结果表明,在公共问答式基准数据集上,较小的块通常表现更好。
刷新¶
Cortex Search 服务中提供的内容基于特定查询的结果。当 Cortex Search 服务的基础数据发生变化时,服务会更新以反映这些变化。这些更新称为刷新。此过程是自动化的,并且涉及到分析表的基础查询。
Cortex Search 服务具有与动态表相同的刷新属性。请参阅 了解动态表刷新 主题以了解 Cortex Search 服务的刷新特性。
Cortex Search 服务的源查询必须是动态表增量刷新的候选项。有关这些要求的详细信息,请参阅 对增量刷新的支持。这一限制旨在防止与向量嵌入计算相关的任何不必要的失控成本。有关动态表增量刷新不支持的构造的详细信息,请参阅 不支持的结构、运算符和函数。
暂停索引和服务¶
与动态表类似,Cortex Search 服务在遇到与源查询相关的连续五次刷新失败时,将自动暂停其索引状态。如果您的服务遇到此故障,可以使用 DESCRIBE CORTEX SEARCH SERVICE 或 CORTEX_SEARCH_SERVICES 视图 查看具体的 SQL 错误。两者的输出都包括以下列:
INDEXING_STATE 列的值为 SUSPENDED。
INDEXING_ERROR 列将包含源查询中遇到的具体 SQL 错误。
在解决根本问题之后,可以使用 ALTER CORTEX SEARCH SERVICE <name> RESUME INDEXING
恢复服务。有关详细语法,请参阅 ALTER CORTEX SEARCH SERVICE。
成本注意事项¶
Cortex Search 服务会产生以下成本:
成本类别 |
描述 |
---|---|
AI 服务 – 服务成本 |
Cortex Search 服务使用多租户服务计算,与用户提供的虚拟仓库分开,以实现低延迟搜索查询。计算成本是按每月每 GB(GB/月)的索引数据收取的,其中索引数据是 Cortex Search 源查询中用户提供的数据,加上代表用户计算的向量嵌入。在服务计费计算中,使用量在第二级计量,并假设一个月 30.5 天。 据估计,索引的数据大小(以字节为单位)大致等于 Cortex Search 服务的成本可在 CORTEX_SEARCH_SERVING_USAGE_HISTORY 视图 中查看,该视图提供了账户中每个 Cortex Search 服务的每小时服务词元消耗量。 Cortex Search 服务的成本也包含在 METERING_HISTORY 视图 的 AI_SERVICES 总计中。 有关每 GB/月索引数据的 Credit 费率,请参阅 Snowflake 服务使用量表。 |
AI 服务 – 嵌入成本 |
Cortex Search 服务使用 SNOWFLAKE.CORTEX.EMBED_TEXT_768 LLM 函数将搜索列中的每个文档嵌入向量空间,每个嵌入的词元都会产生 Credit 成本。嵌入是在源查询计算过程中递增处理的,因此只在添加或更改文档时才会产生嵌入成本。有关向量嵌入成本的更多详细信息,请参阅 向量嵌入。 |
虚拟仓库计算 |
Cortex Search 服务需要用户提供的虚拟仓库。当用户创建服务时以及每次刷新服务时,该仓库都会产生成本。 |
存储 |
Cortex Search 服务将源查询物化为存储在账户户中的表。此表将转换为针对低延迟服务进行优化的数据结构,也存储在账户中。表和中间数据结构的存储基于每 TB 的统一费率 (TB)。 |
云服务计算 |
当底层基础对象发生更改时,Cortex Search 服务使用云服务计算来触发刷新。云服务计算成本受到限制,Snowflake 仅在每日云服务成本大于账户每日仓库成本的 10% 时才计费。 |
小技巧
Snowflake 建议为每项 Cortex Search 服务使用大小不超过 MEDIUM 的仓库。由于产品更新在即,此建议将来可能不适用。
已知限制¶
Cortex Search 的使用受到以下限制:
支持的语言:该功能针对英文文档和查询进行了优化。
基表大小:搜索服务中的物化查询结果必须小于 5000 万行,以保持最佳的服务性能。如果查询的物化结果超过 5000 万行,则创建查询将出错。
备注
要将 Cortex Search 服务的行扩展限制提高到 5000 万以上,请联系 Snowflake 客户团队。
查询构造:Cortex Search 服务源查询必须遵守与动态表相同的查询限制。有关更多详细信息,请参阅 动态表的已知限制。
跨区域推理:Cortex Search 不支持 跨区域推理。
重要
对于您创建的每个 Cortex Search,都会有两个动态表实体出现在 动态表的 Snowsight 监控 UI 中。这两个实体的格式为 _CORTEX_SEARCH_SOURCE_*
和 _CORTEX_SEARCH_REFRESH_*
。这些实体也会出现在动态表 Information Schema 视图中,但不会出现在动态表 SHOW/DESC 命令中。在 Snowsight UI 中点击其中一个实体时,会显示一条 Dynamic Table not found
消息。这是符合预期的行为。在未来的产品版本中,与 Cortex Search 相关的实体将从 Snowsight 动态表监控 UI 中移除。
区域可用性¶
以下 Snowflake 区域的账户支持此功能:
AWS |
Azure |
GCP |
---|---|---|
US 西部 2(俄勒冈州) |
US 东部 2(弗吉尼亚州) |
欧洲西部 2(伦敦) |
US 东部 2(俄亥俄州) |
US 中南部(得克萨斯州) |
欧洲西部 3(法兰克福) |
US 东部 1(弗吉尼亚北部) |
UK 南部(伦敦) |
欧洲西部 4(荷兰) |
加拿大(中部) |
欧洲北部(爱尔兰) |
US 中部 1(爱荷华州) |
南美洲(圣保罗) |
欧洲西部(荷兰) |
US 东部 4(弗吉尼亚北部) |
欧洲(爱尔兰) |
瑞士北部(苏黎世) |
|
欧洲(伦敦) |
印度中部(浦那) |
|
欧洲中部 1(法兰克福) |
日本东部(东京、埼玉) |
|
欧洲(斯德哥尔摩) |
东南亚(新加坡) |
|
亚太地区(东京) |
澳大利亚东部(新南威尔士州) |
|
亚太地区(孟买) |
||
亚太地区(悉尼) |
||
亚太地区(雅加达) |
||
亚太地区(首尔) |
法律声明¶
输入和输出的 Data Classification 如下表所示。
输入 Data Classification |
输出 Data Classification |
名称 |
---|---|---|
Usage Data |
Customer Data |
Covered AI Features [1] |
有关更多信息,请参阅 Snowflake AI 和 ML。