5毛钱标10万行，SQL开始吃掉大模型

一个SQL函数，40秒，10万行，0.5美元。

MotherDuck最近上线的prompt_jev()，把大模型塞进了SQL：调用TypeSafe的Jev，直接在查询里完成文本分类。这不是又一个Python库，而是一次界面层的宣战——大模型正在变成数据平台里的一种内置算子，AI for Data 第一次真正落到了一条SQL语句上。

💡 分析师的死穴：表格里那列没人敢碰的文本

每个数仓里都有一列文本，它叫“不方便”。

场景其实很日常。用户评论表里有一列自由文本，工单系统导出的描述字段，客服记录的摘要列——数据分析师看着这些列，第一反应不是分析，是绕开。因为传统路径太重了：先把数据导出，再写Python脚本调API，或者干脆立项给标注团队，等两周拿回一份CSV，再导回数仓。

文本在数据仓库里，长期是个“二等公民”。结构化字段能JOIN、能GROUP BY、能进看板，非结构化文本却只能躺平在表里占空间。prompt_jev()改的就是这件事：分类变成一个函数，写在SELECT里，结果直接参与聚合和关联。情感倾向、主题标签、意图分类，从此和SUM、COUNT是同一种东西。

产业逻辑很清晰：当一个能力被函数化，它才算真正进入了数据分析的主流程。 之前LLM做数据标注，是“旁边插一台机器”；现在是“长在引擎里”。位置变了，性质就变了。

📈 40秒与5毛钱：把账算给老板看

按行计费的时代，可能要翻篇了。

MotherDuck给的数字很直接：10万行文本标注，40秒，0.5美元，准确率口径为前沿大模型水平。需要强调，这组数字是官方口径（vendor-reported），来自MotherDuck的产品公告与定价说明，目前没有独立第三方复现数据，读者应把它当作用户案例下限而非基准测试。这个价格意味着什么？传统人工标注按条计价、随规模线性增长，还要叠加上标注规范、质检返工、项目管理的时间成本。而现在，边际成本约等于模型调用本身的成本，且几乎不随团队规模变化。

当然要说明：0.5美元针对的是分类这类轻量任务，复杂推理任务的成本会高得多。但账的核心不在绝对值，而在成本曲线的形状变了——从线性增长变成近似平坦。对数据团队来说，这意味着过去“不值得立项”的长尾标注需求，现在可以随手做了。

整条调用链长这样：

有意思的是，"Jev"这个名字难免让人联想到杰文斯悖论：效率提升十倍、百倍之后，用量往往不降反升。标注便宜到5毛钱，用的人只会更多，不是更少。

💰 把同类功能的账放在同一张桌上

只看一家的报价不叫比价，叫广告。

要判断0.5美元是噱头还是地板价，必须把它放进同类功能里横向看。目前三大主流云数仓平台都已提供SQL内调LLM的内置函数：MotherDuck的prompt_jev()、Snowflake的Cortex（COMPLETE()、SENTIMENT()等）、以及BigQuery ML的AI.CLASSIFY/ML.GENERATE_TEXT。

为了可比，这里做一次统一口径的交叉验证：假设典型分类场景每行输入约30 tokens、输出约5 tokens，10万行即约300万输入token＋50万输出token，按各家官方定价页价格折算（估算基于本文成稿时各平台公开定价，实际价格随模型版本和区域浮动，采购决策前请以官方定价页为准）：

三个交叉验证后值得注意的结论：

第一，0.5美元确实贴近当前地板价，但不是魔法价。BigQuery ML搭Gemini Flash档位在同等假设下算出的成本也在同一量级——这印证了一个判断：LLM标注的底价由底层模型token价格决定，平台溢价空间已经很小。真正的差异不在单价，而在摩擦成本：Snowflake按积分折算的口径让财务对账更顺，但换算后单价偏高；MotherDuck的报价最激进，但属于新平台的获客定价，长期走向待观察。

第二，延迟口径各家定义不同，不能直接比。"40秒"是指这个规模的分类任务完成时间；Snowflake和BigQuery的大批量场景官方推荐走batch模式，排队和调度时间不计入"推理延迟"。横向对比时要把口径拉平，否则就是拿冲刺成绩比马拉松配速。

第三，隐藏成本项不同。Snowflake可能叠加仓库运行积分；BigQuery的slot预留会影响批处理吞吐；MotherDuck则要计入月度compute credits的整体消耗。只比token单价会低估真实TCO。

来源说明：Snowflake数据来自其官方文档《Cortex LLM Functions Pricing》（按模型分档的每百万token积分换算表）；Google数据来自Google Cloud官方Vertex AI定价页与BigQuery ML文档（Gemini系列分档token价格）；MotherDuck数据来自其产品公告与定价页，为厂商自报口径。三处均于本文成稿时核对，模型版本迭代很快，引用时请二次确认。

🔧 为什么发生在SQL层，而不是又一个Python框架

SQL是数据团队的通用语，界面之争从来是生死之争。

过去两年，几乎每个数据平台都在喊“AI+数据”，但大部分落地形态是外挂式的：数据导出去，模型跑完再导回来。这种模式的问题在于割裂——权限、血缘、版本、调度全都断在中间。

prompt_jev()选择的是另一条路：把推理下沉到查询引擎内部。MotherDuck站在DuckDB的嵌入式架构上，计算可以跟着数据走，函数调用天然贴近存储层。数据不出平台、权限沿用数据库的既有体系、结果直接进血缘——这是Python脚本永远给不了的东西。

值得注意的是，这条路上MotherDuck并不孤单，Snowflake和Google已经先行：Cortex和BigQuery ML的AI函数都已是GA能力。MotherDuck的差异化打法是价格下限与嵌入式轻量场景——当巨头把功能铺到企业级定价，它用接近底价的报价去接长尾团队。数据圈里流传的一句半玩笑话是：能写SQL的就别写Python。听着像段子，背后是真实的技术分工逻辑——全球最大的数据从业者群体，主语言就是SQL。谁能把AI能力做成SQL方言的一部分，谁就抢到了这个群体的默认入口。据多位平台方向的工程师观察，内置LLM算子正在从加分项变成数据平台的竞争标配，这场仗会在未来两年内打完格局。

⚠️ 别急着all in：三个工程前提

便宜的东西，最怕被当成万能的。

作为架构师，必须泼三盆冷水。

第一，“前沿模型准确率”有适用边界。批量、简单、判别式的任务——情感分类、主题打标、垃圾识别——是LLM的舒适区；需要领域判断、多步推理、有强合规要求的场景，直接上量是给自己埋雷。第二，评估集仍然是人的活。模型换了、价格变了、任务定义改了，你需要一套自己的小规模人工校验集做回归，这笔隐形成本躲不掉。第三，数据治理不能因为函数一行就跳过。文本里带PII的表，出域给模型前要不要脱敏？哪些表允许调用推理？这些问题不会因为调用方式从“导数据”变成“写函数”而消失。

一个务实的决策路径：

一句话总结工程判断：LLM标注的合理定位是“够用就上、关键场景留人审抽样”，把它当免费的完美标注员，是概念泡沫；把它当成本下降两个数量级的新工具，是清醒。

🚀 竞争格局：数据库厂商的AI军备竞赛，正式开打

这一枪打的不是标注公司，是所有数据平台的定价表。

拉远看，AI与数据的关系是双向的：Data for AI解决“给模型喂数据”的问题，AI for Data解决“用AI处理数据”的问题。prompt_jev()属于后者，而且选择了最激进的表达方式——直接进付费计划（paid plans），而非实验特性。这是明确的商业化信号：平台方认为这个能力的付费意愿已经成立。

推演一下后续：当“在SQL里调大模型”成为数据平台的标配能力，竞争的焦点会从“有没有”转向“便宜多少、快多少、治理多好”。前文的横向对比已经说明，功能层面三家趋同，单价层面模型成本决定下限——那么真正的分水岭是计费透明度和治理能力：Snowflake的积分体系对账友好但换算复杂，Google背靠自家模型有价格主动权，MotherDuck则用激进定价换市场份额。模型价格的持续下行会不断压低这类函数的成本底价，而真正拉开差距的，是谁能把权限、血缘、审计这些治理件做得更顺。数据要素流通和合规的长期趋势，也会反过来要求AI处理过程本身可审计——函数化恰好给了这个抓手。

对从业者来说，值得关注的是三件事：自己平台的LLM算子路线图、内部长尾标注需求的释放节奏、以及评估与治理流程的补位速度。

小结

prompt_jev()单看是一个小功能，40秒、0.5美元、10万行——且这组数字目前只有官方口径背书，但横向放进来对比，它确实压到了同类功能的成本下限区间。它标记了一个节点：大模型第一次以SQL函数的形态，坐进了数据平台的正席。真正的看点不在这一次的价格，而在“函数化”打开的空间——分类只是第一个算子，抽取、摘要、生成都在路上。未来两年，判断一个数据平台的成色，可能要多加一条：它把AI做成了外挂，还是做成了内置。这场仗，才刚开打。