Snowflake Cortex

Snowflake Cortex 是由 Snowflake Inc. 开发、内置于 Snowflake Data Cloud 的原生 AI 和机器学习套件。它使数据团队能够直接对已存储在 Snowflake 中的数据运行大型语言模型推理、构建 AI 代理并部署语义搜索，而无需将数据路由到外部 AI 服务或管理独立的 GPU 基础设施。其核心主张是架构级安全：让 LLM 走向您受管控的数据，而不是让数据离开去寻找 LLM。每一项 Cortex 操作都会继承 Snowflake 现有的访问控制、审计日志、VPC 边界和合规认证。

Cortex 套件拥有四大核心服务支柱。Cortex LLM Functions（也称为 Cortex AI SQL）允许分析师使用 AI_COMPLETE、AI_CLASSIFY、AI_SUMMARIZE、SENTIMENT、TRANSLATE、EXTRACT_ANSWER 和 AI_TRANSCRIBE 等函数，直接从 SQL 调用 Anthropic Claude、Meta Llama 4 和 Mistral 等模型。Cortex Search 提供完全托管的混合搜索服务，结合了语义向量检索与关键字匹配，可跨存储在 Snowflake 中的非结构化文档进行搜索。Cortex Analyst 将纯英文问题转换为 SQL 并返回文字答案，让不会编写查询的业务用户也能轻松访问结构化数据。Cortex Agents 将上述所有功能编排成一个多步推理循环，并通过 REST API 暴露出来，允许团队构建跨越结构化表格和文档存储的聊天机器人与自动化工作流。第五个组件 Cortex Code 是 Snowflake 原生的 AI 编程助手，全面掌握账户的模式（schemas）和列名，自 2025 年 11 月推出以来，已被超过 50% 的 Snowflake 客户采用。

截至 2026 年 5 月，Snowflake Cortex 的实际功能

Cortex 于 2025 年 11 月 4 日达到生产就绪状态，当时 Snowflake 在 Snowflake BUILD 2025 开发者大会上同步宣布 Cortex Agents 和 Cortex AI Functions 全面可用（GA）。在此之前，这两项服务均处于预览阶段，仅限抢先体验客户使用。GA 版本的发布向所有 Snowflake 账户开放了这些服务，并为企业提供了在之上构建生产工作负载所需的合同级 SLA。

当前的功能集涵盖了完整的“数据上运行 AI”工作流：摄取、转换、分析和呈现。处理 1000 万条客户评论的数据工程师可以在现有的 dbt 模型中添加一个引用 AI_SENTIMENT 的 SQL 列，并在下一次管道运行时获取情感得分，无需管理新凭据，也无需启动额外的数据仓库。构建内部数据分析聊天机器人的团队可以使用 Cortex Agents REST API 接收自然语言问题，将结构化查询路由到 Cortex Analyst 生成 SQL，将文档问题路由到 Cortex Search 进行检索，综合结果后返回一个连贯的答案。多模态处理将相同的 SQL 可调用模式扩展到了图像和音频：AI_TRANSCRIBE 可将存储在 Snowflake 暂存区（stages）中的音频或视频文件直接转换为文本，以供下游分析。

微调同样是无服务器的。团队可以使用专有的 Snowflake 数据对 Llama 模型进行微调，而无需配置 GPU 计算资源或离开 Snowflake 环境。训练后的模型权重保留在账户内，并且通过与所有其他 Cortex 函数相同的基于积分（credit）的计量方式进行服务。

“Cortex Code 正在改变我们在 Braze 处理代理式分析的方式。它对我们的数据集、模式和列的原生理解意味着我们的工程师可以花更少的时间在上下文上纠缠，而将更多的时间用于获取精确、可操作的输出。” - Spencer Burke，Braze 增长高级副总裁，Snowflake 新闻稿，2026 年 2 月

Snowflake Cortex 与 Databricks Mosaic AI 和 AWS Bedrock 的定位对比

Databricks Mosaic AI 是架构上最接近的竞争对手，因为它解决了相同的问题：将 AI 嵌入现有的数据平台中，使团队无需构建独立的 ML 技术栈。机制上的区别在于抽象级别。Databricks 通过 Mosaic AI Training 和 Serving 层显式暴露 GPU 集群；工程师可以检查节点配置、选择硬件层级，并运行自定义的 PyTorch 训练任务，对计算资源拥有完全的可见性。Mosaic AI 的 Agent Framework 支持自定义模型训练、基于人类反馈的强化学习（RLHF），以及通过带有速率限制的 AI Gateway 进行多提供商 LLM 路由。Snowflake Cortex 则将所有这些抽象化：您只需编写 SQL，Snowflake 会在后台无形地分配无服务器计算资源，且没有 GPU 配置选项。对于需要训练专有模型、运行带有 MLflow 集成的严格评估套件，或构建需要自定义内存和工具注册表的复杂代理架构的组织来说，Databricks 更胜一筹。而对于希望在不搭建 ML 平台的情况下快速将 AI 投入生产的 Snowflake 用户来说，Cortex 则是赢家。完整对比请见 Databricks Mosaic AI。

AWS Bedrock 具有云中立性和模型多样性，通过统一的 REST API 提供对来自 Anthropic、Meta、Mistral、Cohere、Amazon Nova 等 30 多种基础模型的访问。Bedrock 与 Cortex 在架构上的对比归结为数据移动。Bedrock 在您的数据仓库之外运行：要将其用于 Snowflake 数据，您需要提取数据集，将其跨越网络边界发送到 Bedrock 端点，然后接收返回的结果。这种跨边界操作需要额外的 IAM 策略、网络安全控制，以及受监管行业的合规文档。Cortex 通过在 Snowflake 已获认证的安全边界内运行推理，完全消除了这一边界，使用的是您的治理团队已经管理的相同 IAM 角色和审计日志。Bedrock 的优势在于广度：它支持尚未出现在 Cortex 目录中的模型和代理模式，并且能与 AWS Step Functions 和 Lambda 自然集成，以实现复杂的工作流编排。对于数据跨越多个云的团队来说，Bedrock 的云中立定位在架构上比 Cortex 更清晰。对比选项请见 AWS Bedrock、Google Vertex AI 和 Azure OpenAI。

Cortex 工作流的实际体验

对于已经熟练掌握 Snowflake SQL 的数据工程师来说，Cortex 的上手体验确实是低阻力的。没有需要学习的新平台，基本功能无需安装 SDK，也没有需要管理的凭据。一个常见的首个项目是对现有的客户记录表运行 AI_SENTIMENT 或 AI_SUMMARIZE。查询成功运行，结果随之呈现，从想法到工作原型的迭代周期只需数小时，而不是数周。

阻力出现在成本监控层。Snowflake Cortex 现在有九个不同的服务类别，并带有独立的计费视图：AI SQL Functions、Cortex Code、Cortex Copilot、Cortex Analyst、Cortex Search、Cortex Agents、Fine-Tuning、Document Processing 和 Legacy Functions。这些视图使用不一致的用户标识符字段，使得构建统一的成本仪表板变得并不容易。一位审计生产环境 Snowflake 账户的从业者发现，超过 60% 的 Cortex 支出对监控团队来说是不可见的，因为他们只关注了主要的 AI Functions 使用视图。

“在我最近审计的一个账户中，超过 60% 的 Cortex 支出对监控团队来说是不可见的。” - Vedprakash，数据工程师，Medium 上的 DataAIChronicles，2026 年 3 月

Cortex Search 加剧了这一问题，因为它使用的是始终在线（always-on）的计费模式。与按调用次数收费的 SQL 函数不同，Cortex Search 服务是持续运行的后台进程，按每月索引数据的 GB 数计费，无论在该计费周期内是否运行了任何搜索查询。习惯了 Snowflake 按计算付费模式的团队，有时会对他们为概念验证（POC）启动的 Cortex Search 服务累积了一个月的索引费用感到惊讶。

Snowflake 于 2026 年 3 月发布了针对 Cortex AI Functions 的原生支出控制功能，增加了每用户滚动的 24 小时限制和团队级预算上限。但要实现稳健的监控，仍然需要将多个计量视图拼接成一个统一的成本仪表板，而大多数团队都是在收到意外账单后才被动构建，而不是在发布前主动进行。

构建搜索驱动应用程序的团队通常会将 Cortex Search 与企业知识管理工具结合使用。像 Glean 这样的产品也解决了针对非结构化内容的类似企业搜索问题，尽管采用的是不同的架构方法。

Snowflake Cortex 为谁而建

主要用户是其组织已经承诺将 Snowflake 作为数据仓库的数据工程师或分析工程师。Cortex 不是一个独立的产品：没有单独的 Cortex 订阅，没有免费层，也没有在没有 Snowflake 账户的情况下访问 Cortex 的方法。如果这符合您的情况，那么 Cortex 是将 AI 嵌入您已有的数据工作流的最快途径。

在这一限制下，Cortex 在受监管行业中表现尤为强劲。在 HIPAA、SOC 2 或 GDPR 要求下运营的医疗保健、金融服务和保险组织，通常对数据处理地点有合同义务。在现有业务伙伴协议（BAA）覆盖的 Snowflake 账户内运行 LLM 推理，在架构上比为 Bedrock 目录中的每个模型供应商与独立的 AI 提供商协商新的 BAA 要简单得多。

为非技术业务用户构建自助服务工具的分析团队将从 Cortex Analyst 中受益。他们无需构建自定义的自然语言转 SQL（NL-to-SQL）层，只需在 Streamlit 或内部聊天机器人界面后暴露 Cortex Analyst API，即可让业务用户使用纯英文查询数据。

Snowflake Cortex 不是什么

Cortex 不是切换数据平台的理由。如果您的数据存储在 Databricks、BigQuery 或 Redshift 中，那么您无法使用 Cortex。数据驻留的优势仅适用于已在 Snowflake 账户内的数据；没有任何代理或连接器能够在保持 Cortex 治理属性完好无损的情况下深入其他系统。Cortex Code 在 2026 年 2 月进行了扩展，以引用 AWS Glue 和 Postgres 等外部系统，但 LLM 推理函数本身仍然仅对暂存在 Snowflake 中的数据进行操作。

Cortex 不是一个完整的 ML 平台。微调支持仅限于 Llama 模型变体。没有自定义模型架构训练，没有基于人类反馈的强化学习，也没有相当于 Databricks 的 MLflow 实验跟踪功能来进行系统的模型评估。如果团队的 AI 路线图涉及在自己的数据上大规模训练专有模型，他们将超出 Cortex 托管产品的能力范围，需要考虑 Databricks Mosaic AI 或专用的 MLOps 平台。

Cortex 也不适合缺乏成本监控纪律的团队。跨九个服务类别的基于 Token 的计费、始终在线的 Cortex Search 基础设施费用，以及直到 2026 年 3 月才推出原生资源监控器，这些因素的结合让团队收到了意外的账单。一个广为流传的案例是，一个数据团队为处理 11.8 亿条客户记录的单个 Cortex Functions 查询支付了约 5,000 美元。查询完成了，积分耗尽了，却没有配置任何警报来捕捉它。这种计费动态现在已通过 2026 年 3 月的成本控制得到部分缓解，但团队在共享账户中广泛启用 Cortex 之前，仍应构建监控仪表板。