一年前在Snowflake上配OpenAI做聊天机器人，如今我会改用原生AI栈

回顾[我2025年5月写的一篇文章](https://medium.com/@sanket.prabhu34/building-a-chatbot-in-snowflake-using-streamlit-and-openai-gpt-3-5-cfb9e1da1b52)，内容是在Snowflake中使用Streamlit和OpenAI的GPT-3.5构建聊天机器人，以及同样的用例在Snowflake当前自己的AI栈上看起来是什么样的。

大约一年前，我发表了一篇教程，介绍如何使用Streamlit和OpenAI的GPT-3.5 API在Snowflake内部构建聊天机器人。它确实能运行，也有人使用，而且在当时，这是为Snowflake原生受众提供对话式AI的一种合理方式。

我当时遵循的一个误区（虽然我没有这么称呼它）是：如果你想要一个真正智能的聊天机器人，你必须离开Snowflake去获取智能，然后把答案带回来。一个API密钥，一个供应商账户，以及为出站调用配置的网络白名单条目。这就是准入成本。

从那时起发生的变化是：并不是说Snowflake获得了更智能的模型，而是模型和数据之间的距离消失了。

聊天机器人并没有变得更聪明，而是数据所在位置和模型运行位置之间的差距缩小了。

1. 我2025年5月实际构建了什么

旧架构很简单：在Snowflake内运行Streamlit作为UI，使用`snowflake.snowpark.context`与仓库通信获取数据，而OpenAI的GPT-3.5 API通过开放互联网处理对话层。

这意味我当时提到了三个实际前提：支持Streamlit的Snowflake账户，OpenAI API密钥（独立的供应商关系和独立的账单），以及配置好的网络访问，以便应用能够真正访问OpenAI的端点。对于个人项目或演示，这只是星期二下午就能搞定的事。但对于出口控制严格的企业团队来说，仅第三项就可能变成为期数周的安全审查。

2. 即使在当时也困扰我的差距

即使在我发布时，我也并不喜欢那个架构。聊天机器人回答的每个问题都意味着Snowflake数据（或至少是数据摘要）要跨出Snowflake的边界，到达OpenAI的API，然后答案再返回。对许多用例来说，这是一个可以接受的权衡。但对于涉及受监管或敏感数据的任何用例，这就成了更难讨论的问题，而我已经多次与安全团队进行过这种对话，他们的质疑并没有错。

值得对任何聊天机器人设计提出的反问是：在获得答案之前，数据到底去了哪里？在2025年的版本中，诚实的回答是“暂时离开Snowflake”。现在情况不同了。

3. Snowflake AI栈目前的样子

我现在会使用的函数是AI_COMPLETE，这是Snowflake目前普遍可用的LLM补全函数（旧的`SNOWFLAKE.CORTEX.COMPLETE`函数将在2026年底弃用，所以如果你是从头开始，AI_COMPLETE是值得学习的）。

当我再次为这篇文章深入研究时，有一个部分确实让我惊讶：AI_COMPLETE让你可以使用来自OpenAI、Anthropic、Meta、Mistral AI和DeepSeek的模型，包括OpenAI自己的模型系列，也就是我在2025年直接调用的同一家供应商。区别不在于哪个公司构建了模型，而在于这些模型现在在Snowflake服务边界内运行，作为SQL函数被调用，而不是你的应用程序使用自己的API密钥向第三方端点发出出站调用。

SELECT AI_COMPLETE('llama3.1-70b', 'Summarize the last 5 support tickets for this account.');

无需配置或轮换API密钥，无需向安全审查证明出站网络规则的合理性。模型调用与它所推理的数据处于同一治理边界内。

4. 现在也不仅仅是换了个函数

2025年的聊天机器人是一个单一循环：提出问题，发送给GPT-3.5，返回答案。这适用于一般对话，但除非你手动将数据填入提示中，否则它不实际了解你的Snowflake数据。

现在可用的功能更进一步：

1. Cortex Search（正式发布）处理非结构化内容的检索，例如支持工单、文档，或聊天机器人需要搜索而有不能猜测的内容。
2. Cortex Analyst（正式发布）将自然语言转化为基于语义视图的受管控SQL，使得聊天机器人能回答关于结构化数据的真实问题，而不是凭空捏造数字。
3. Cortex Agents（正式发布）位于两者之上，决定给定问题实际需要哪种工具并编排调用，而不是用单一平坦的提示-响应循环试图同时处理所有事情。

如今构建的聊天机器人实际上不再是2025年意义上的“聊天机器人”。它更像是一个恰好拥有聊天界面的智能体，能够搜索、查询和推理受管控数据，而不是仅在抽象层面谈论它。

5. 我仍然会考虑旧方法的地方

我认为2025年的架构并没有错，我想诚实地说明这一点，而不是假装旧帖子是错误。仍然有现实的理由去直接调用外部LLM API：你需要Snowflake未托管的特定模型，你需要Cortex函数目前未公开的功能，或者你的数据确实没有带来使边界问题变得重要的敏感度。

但是，对于我写的特定用例——Snowflake原生聊天机器人回答基于Snowflake数据的问题——相比一年前，将模型调用保持在与数据相同的边界内是一个显著更好的默认选择。在2025年5月，这不是真正的选项。现在它是了。

概要

1. 我2025年5月的聊天机器人使用Snowflake中的Streamlit作为UI，使用OpenAI的GPT-3.5 API作为智能，这意味着每次提问都需要API密钥、供应商账单，并且Snowflake数据要离开环境。
2. AI_COMPLETE，Snowflake当前正式发布的补全函数，现在提供对OpenAI、Anthropic、Meta、Mistral AI和DeepSeek模型的访问，这些模型在Snowflake服务边界内部署，而不是通过开放互联网调用。
3. 更大的转变不是功能交换，而是Cortex Search、Cortex Analyst和Cortex Agents（均为GA）让你能够构建更接近于受治理的智能体的东西，而不是单循环聊天机器人。
4. 直接调用外部LLM API在某些情况下仍然有意义。它不再是仅仅为了让聊天机器人真正了解你的数据而采用的默认方式。
5. `SNOWFLAKE.CORTEX.COMPLETE` 将在2026年底被弃用：如果你今天正在构建，请从AI_COMPLETE开始。

我很高兴写了第一篇帖子。这也是我所拥有的关于这个类别发展速度的最清晰证据，并提醒我，今天值得捍卫的架构很少是十二个月后值得捍卫的架构。

我用OpenAI在2025年构建的聊天机器人，以及为什么今天我不会那样构建它最初发表在Snowflake Builders Blog: Data Engineers, App Developers, AI, & Data Science在Medium上，人们通过突出和回应这个故事来继续对话。