80%-90% 的企业数据一直没法用，Snowflake AI 副总裁说推理模型刚把它们叫醒了

80% 到 90%。这是企业里非结构化数据占全部数据的比例。它们长期躺在 PDF、合同、扫描件、财报、邮件里，格式乱七八糟，人类看一眼都费劲，更别说让机器去查。Snowflake 的 AI 副总裁 Baris Gultekin 在播客里说，过去半年到一年，推理模型的进步让 text-to-SQL 的质量跨过了一个临界点，这批沉睡的数据第一次变得可查。

Baris 是跟着 Snowflake 现任 CEO Sridhar Ramaswamy 一起进来的。2023 年 5 月，Snowflake 收购了 AI 搜索引擎 Neeva，Baris 随之加入，现在负责 Snowflake 的 AI 产品线。他的日常，就是在“前沿模型能力”和“企业级安全、治理、可靠性”这两个世界的夹缝里做产品。这场对话信息量很大，从 text-to-SQL 到 RAG，从智能体设计到模型选型，再到“即插即用知识工作者”到底什么时候来，几乎把企业 AI 落地的关键问题都过了一遍。

先把 Snowflake 讲清楚：它是干什么的

Snowflake 是一个数据平台，现在管自己叫“AI 数据云”。企业把数据搬上来，做安全、治理、分析，跑 BI 看板，做大规模查询。过去主要处理结构化数据，比如交易记录、客户表、财务表。结构化数据的好处是规整，能直接用 SQL 查。

问题在于，结构化数据只是冰山一角。Baris 在对话里反复提到一个数字：企业数据中 80% 到 90% 是非结构化的。以前不是没人想用，是用了也白用。处理成本太高，提取精度太差，分析链条太长，做下来还不如让业务人员自己翻文档。

生成式 AI 改变的就是这件事。现在有两种用法。第一种是把非结构化数据“结构化”：从合同里抽出关键条款，从财报里抽出营收数字，从扫描件里抽出表单字段，抽完之后就能用 SQL 去查、去聚合、去跑分析。第二种是直接“跟数据对话”：把所有文档做向量化，建 RAG，让业务人员用自然语言提问，系统给出答案。Baris 举了个财富管理的例子：一个理财智能体，既要去查结构化的股价数据，又要读 PDF 里的股票研究报告，两种数据得能拼在一起用，这才是真实场景。

这也解释了他们为什么坚持“把 AI 带到数据旁边”，而不是把数据送到模型那边。企业的数据有重力，客户不愿意把数据复制到好几个地方，更不愿意把敏感数据送出安全边界。Snowflake 的做法是把推理跑在自己的安全边界内，模型提供商作为子处理方，不保留任何状态，数据不出门。对金融、医疗这类受监管行业，这条几乎是硬门槛。

Text-to-SQL：为什么过去不行，现在行了

主持人 Nathan Labenz 问得很直接：text-to-SQL 到底到哪一步了？Baris 的回答很坦诚，过去确实很难，难在几个地方。

第一，容错率极低。你问“我的营收是多少”，答案只有一个。错误空间几乎为零，而用户对质量的心理预期极高。第二，语义层太复杂。“营收”的定义可以变，“利润”的口径可以变，同一个词在不同部门有不同解释。第三，真实企业环境里，动辄几千张表、几十万列，模型要在里面找对数据源，难度远超 demo 场景。第四，还有大量“部落知识”：某个字段早就不用了，但没人删，新人不知道，模型更不知道。

转折点来自推理模型。Baris 说，过去半年到一年，推理模型的推理能力大幅提升，同时把语义模型搬上平台这件事变得相对容易，text-to-SQL 的质量有了“实质性提升”。他们的产品叫 Snowflake Intelligence，是一个智能体平台，面向业务用户，不要求会写 SQL，也不要求懂数据模型。这个产品现在是 Snowflake 增长最快的产品。

变化有多大？以前业务人员想问一个数据问题，得找熟悉数据的分析师，分析师排期、写查询、做分析，一周后给结果。现在业务人员直接问，几秒钟出答案。这就是“数据分析民主化”真正落地的样子，门槛从“会写 SQL”降到了“会提问”。

语义模型怎么建？Baris 说，推理模型现在能帮很大忙。输入包括系统里的元数据、表名、列名、底层数据本身，还包括 BI 看板里的语义信息、历史查询记录，这些都是线索。Snowflake 还拉上了 Tableau、Omni 等 BI 厂商，搞了一个叫 Open Semantic Interchange 的开放标准，目标是让语义模型在不同平台之间能互相复用。在一个平台建好的语义模型，换个平台也能用。这件事还在早期，但方向很清楚：语义层不应该被某一家锁死。

RAG 的现状：嵌入模型是核心，但复杂度在下降

RAG 这块，Snowflake 有个天然优势。他们收购的 Neeva 本来就是做网页级搜索引擎的，搜索和 RAG 的底层技术直接搬了过来。Baris 说，决定 RAG 质量的核心是嵌入模型的质量，其次是分块策略、混合搜索、重排序这些层。PDF 特别麻烦，里面有图片、表格、多栏排版，提取精度直接决定下游效果。多模态嵌入模型还是纯文本嵌入模型，也得看场景选。

但趋势是，很多以前需要专家手工调的东西，现在可以自动化了。复杂度在下降，质量在上升，新的用法开始出现。Baris 提到一个叫“分析型文档智能”的方向：假设你有过去十年的季度财报，几千份 PDF，你问“过去十年平均营收是多少”，系统能把分散在多个文档里的数字抽出来，做聚合，给答案。这个在以前几乎不可能，现在可行。

主持人追问了一个很多人关心的问题：是不是趋势在往“更大的模型直接搞定一切”走？他举了个例子，一年半前处理扫描表单，可能需要专门的嵌入模型、专门的表格提取模型，一堆小模型拼起来。现在 Claude Opus 或 Gemini 3 开箱就能处理，推理成本高，但 AI 工程时间省太多了。

Baris 的回答很务实：分场景。如果只处理一两份文档，前沿大模型确实直接上，省事。但如果要处理几亿份文档，不可能用 Claude 跑，成本和吞吐都扛不住。Snowflake 自己训了一个文档提取模型，比大语言模型小好几个数量级，专门做特定字段抽取，速度快、成本低。这就是帕累托前沿：最左边是前沿大模型，最贵最慢但最通用；中间是 Snowflake 这种平台级的专用小模型，摊薄到大量客户；最右边是单个企业自建的极专用模型，只在数据特殊、吞吐或成本要求极严时才划算。

微调没死，但起点应该是前沿模型

Nathan 问了一个很直接的问题：微调是不是已经死了？Baris 说不是，但用法变了。他举了 Cursor 的例子：Cursor 在自家规模上，用定制模型做代码自动补全，完全合理。判断标准是：先用前沿大模型起步，跑通了，再判断有没有必要专门化。如果有大量专有数据、模型没见过的任务、严格的吞吐或成本约束，才考虑训专用模型。大多数情况下，一个调好的 RAG 方案加 text-to-SQL 方案，配前沿模型，就是首选。

开源模型这块，Snowflake 平台上提供 OpenAI、Anthropic、Gemini、Meta、Mistral，也包括 DeepSeek。Baris 提到，有些客户愿意用中国开源模型的权重做定制，有些坚决不碰。这个分歧跟行业关系不大，更多是客户自己的内部政策和文化。Qwen 这类模型能力很强，不用确实会留一些东西在桌上，但替代品也很多，这个领域竞争足够充分，没有哪个模型能通吃。

模型会不会商品化？切换成本比想象中高

关于模型商品化，Baris 的判断是：模型之间的差距在缩小，但还没到完全商品化的地步。每家都在进步，竞争很健康，对平台和客户都是好事。Snowflake 的角色是提供选择，让客户根据数据驻留要求、质量评测、成本、延迟自己选。有些客户是 AWS 重度用户，模型如果只在 Azure 上可用，数据出境就成了问题，这是很现实的决策点。

主持人问：客户切换模型的频率有多高？Baris 的回答有点反直觉：大多数情况下切换并不多，因为提示词是针对特定模型优化过的，换模型意味着要重新优化，切换有成本。他拿 Google 和 Bing 做类比：Bing 质量追上来之后，很多人还是习惯用 Google，界面熟悉、肌肉记忆，切换的动力不足。模型还没到那个稳定状态，但一旦一个应用积累了几千行提示词和系统逻辑，切换的收益必须足够大才值得。

这也意味着，模型竞争有一个先发优势：在客户第一次做评测时表现最好的模型，更容易被选中，而且因为切换成本，这个位置有一定黏性。但 Baris 也强调，竞争在往应用层转移。ChatGPT 作为产品有黏性，Claude Code 作为工具有黏性，模型质量是基础，但差异化越来越体现在产品体验上。

智能体设计：选自己的冒险，还是结构化工作流

Nathan 用了一个很形象的比喻：智能体设计是一条光谱。一端是 Claude Code 那种“选自己的冒险”，给个目标，模型自己拆解、自己搜索、自己决定下一步。另一端是完全线性的结构化工作流，一串提示词按顺序跑。他自己的建议是，大多数企业场景，结构化工作流更靠谱，别一上来就搞“选自己的冒险”。

Baris 同意这个判断，但加了一个关键变量：用户是谁。面向开发者和构建者，Claude Code 这类工具非常强大，灵活度是优势。面向业务用户，比如一个产品经理问“上周这个产品的使用量是多少”，他要的是结构化、可预期、高质量的答案，不需要一个“选自己的冒险”界面。Snowflake 内部给 5000 名销售人员部署了一个销售助手，跑在 Snowflake Intelligence 上，界面像 ChatGPT，但底层是高度优化过的智能体，针对续约、销售管道这类问题做了专门调优。业务用户要的是信任，不是灵活。

多智能体协作这块，Baris 说现在客户的重点还是“先把一个智能体做好”，跨智能体的交接和协调刚开始变得重要。大企业里不同团队用不同平台建智能体，Salesforce 上建销售相关的，Snowflake 上建数据相关的，这些智能体之间要能对话。MCP 和 A2A 是客户期待支持的协议，A2A 目前 Snowflake 还没支持，但客户已经在问“智能体之间能不能通信”这件事。现在的变通做法是把别的智能体当成工具，通过 MCP 调，由编排器统一管理。

产品管理这个岗位正在被重写

Baris 做了 20 年产品管理，他说这件事对他冲击最大。以前做产品，先想 UI，再画原型，再排期开发。现在有了编码助手，如果用户本身就活在编码助手里，产品可能就是一个 skill，一天写完，直接推到客户面前用，拿到反馈，再决定要不要固化成正式产品。工作原型成了硬通货，验证跑在开发前面。

这也改变了他对“即插即用知识工作者”的判断。主持人提到，有人预测 2026 年 Q2 就会出现第一批“AI 同事”，有名字、有邮箱、有 Slack 账号、能参加会议，直接产生价值。Baris 说方向是对的，但时间点存疑。关键变量是“任务能被圈得多小”。如果任务边界清晰、范围可控，这种 autonomous agent 完全可能。但如果指望一个 AI 同事什么都能干，现在还不到时候。

他还补了一个数据平台的视角：不管智能体多强，最终拼的还是企业自己的数据，以及能不能把对的数据检索出来、把对的工具交给智能体去执行。所以“让数据为 AI 准备好”这件事，优先级只会越来越高。

价值会往哪走：中间层被挤压，两头扩张

主持人问了一个经典问题：基础设施、模型、应用层，价值怎么分配？Baris 的回答是：中间层会萎缩，两头会继续扩张。芯片层和模型层已经在捕获大量价值，应用层也在起来，Cursor 就是个例子。中间那层，也就是专门为某个场景写业务逻辑的公司，压力最大。因为很多业务逻辑，现在一个周末的 vibe coding 就能搞定，不需要专门买一个产品。

这也解释了他为什么更看好横向平台，而不是垂直 SaaS。大量 SaaS 的本质是把行业最佳实践编码成软件，当智能体能按需生成这些逻辑时，专门养一个团队去做这件事的价值就下降了。

那为什么不做一个“GE GPT”或者“Pfizer GPT”，把企业百年积累的数据全喂进模型权重里？Baris 用 ChatGPT 的演进打了比方：以前 ChatGPT 的知识有截止日期，后来加了联网搜索，模型不需要把全世界的信息都记在权重里，而是学会什么时候去检索、怎么理解检索结果。企业场景是同一个逻辑：检索加工具，比把知识烧进权重更便宜、更可更新、更能跟着底层模型一起升级。例外还是那个例外：任务特殊、数据特殊、吞吐或成本要求极严，才考虑训专用小模型。

主持人补了一个很生动的观察：你把我全部 Gmail 和 Google Docs 的访问权给一个模型，它搜得还是不如我自己搜得好。因为我在这个语料上“预训练”过，我知道什么时候找到了对的那封邮件，模型不知道。Baris 承认这个直觉有道理，但他认为这更像“直觉”这个东西本身还没被理解清楚。模型现在做的是检索和推理，人类做的是检索加直觉，后者怎么工程化，目前没有答案。

企业该做什么：明天就能用的几条

整场对话听完，Baris 给企业的建议其实很集中，可以拆成几条能直接动手的：

• 先盘点非结构化数据。合同、财报、扫描件、邮件，哪些是高价值、高查询频率的？从这批数据开始做提取和索引，不要一上来铺全网。
• 建语义层，别跳过。“营收”“活跃用户”这些词在企业内部有口径差异，先把定义和映射理清楚，text-to-SQL 的质量才有可能稳定。推理模型能帮忙建，但不能替你拍板业务定义。
• 从结构化工作流起步，再考虑放开。面向业务用户的智能体，先做范围窄、可评测、可监控的版本，跑通了再扩。别一上来就给业务用户一个“选自己的冒险”界面。
• 模型选型先跑评测，再谈切换。大多数团队切换模型的频率低于应该有的水平。如果有余力，定期拿新模型跑一遍自己的评测集，别让提示词优化成为不换模型的借口。
• 数据治理是智能体治理的地基。Snowflake 的做法是让智能体继承数据平台的细粒度访问控制，同一个智能体，不同用户问同一个问题，看到的答案范围不同。这件事应该在平台层做，别在每个智能体里重复造轮子。
• 让产品团队先学会用编码助手做原型。工作原型比 PRD 更有说服力。Baris 的原话是，产品构建的方式需要根本性改变，而这件事“发生得还不够快”。

回到开头那个数字。80% 到 90% 的企业数据一直没法用，这个比例不会一夜之间归零，但推理模型确实把门槛降下来了。Text-to-SQL 从“demo 能跑、生产不敢用”变成了“可以大规模部署”，RAG 从“专家手工调”变成了“大部分能自动化”，智能体从“选自己的冒险”变成了“针对场景高度优化”。企业 AI 的竞争，接下来拼的是数据准备得够不够好、语义层建得够不够扎实、产品迭代得够不够快。这三件事，没有一件是靠买一个模型就能解决的。