在数据仓库中使用 AI Functions：热门用例

在大多数企业中，数据仓库里存放的是结构化数据，非结构化数据则留在数据湖中。这种模式对传统分析十分有效：报告模型固定，消费的是大规模结构化数据。但 AI 工作负载需要不同的输入。模型往往要解析评论、支持工单、PDF 等非结构化内容，再将其与结构化数据结合，才能完成训练、构建和推理。过去，分析师若想分析支持工单的情感，必须把数据行导出到外部服务，等待预测结果，再手工拼回表里。这个过程不仅慢，遇到 schema 变更还会中断，同时带来不必要的安全和治理风险。

AI Functions 改变了这一架构。它把 AI 带到数据所在处，而不是把数据搬到独立的 AI 环境。你可以直接在标准 SQL 查询中调用模型，整个推理流程都留在现有管道和 Unity Catalog 治理范围之内。凭借这一设计，数据安全成为默认属性：模型只能访问你明确允许的数据；使用方式也极为简单，能写 SELECT 就能构建 AI 应用；计费统一在 system.billing.usage 中呈现；任务专用函数（如 ai_classify、ai_extract、ai_translate、ai_parse_document）能针对特定工作提供更优效果，且成本更低。

文章随后介绍了六个典型用例。第一个是文档智能：ai_parse_document 将 PDF、图片等原始二进制内容转换为文本，再由 ai_extract 抽取具体键值，最终得到结构化表格。整条数据血缘从原始 PDF 延伸到抽取行，原本需要手工搭建的 OCR、LLM 调用和 JSON 展开步骤全部合并到一个查询计划中。第二个是客户反馈情感分析：ai_classify 执行零样本分类，将自由文本映射到用户定义的标签，无需训练模型，结果可直接用于 BI 仪表盘。

第三个用例是翻译：ai_translate 在查询层将多语言数据标准化为单一目标语言，避免数据孤岛，使下游分析能同时处理全球数据集。第四个是分类与路由：ai_classify 在数据接入时识别支持工单的意图和紧急程度，自动分发给相应团队或自动应答系统。第五个是销售通话结构化提取：ai_extract 从通话记录中抽取下一步行动、交易阶段、风险标记和原因等字段，让定性信息可被 BI 工具查询。第六个是生成式起草：ai_query 允许你向 Databricks 托管的模型发送任意提示，逐行返回结果，例如为每个续约信号账户草拟续约邮件，因此它能处理专用函数覆盖不了的需求。

文章还给出生产环境建议：第一天就为任务打上标签，以便归因成本；优先尝试任务专用函数，只有都不合适时才用 ai_query；让 ai_query 返回结构化输出；慎重选择模型；先跑 1 万行样本再批量运行；把提示词当作代码管理。这些建议强调成本、准确性和可维护性的平衡。

最后，所有这些用例背后是同一个思路：AI 与数据仓库的其他部分运行在同一平台，使用同一套治理、计费和管道。现有 SQL ETL 的任何一行都可以加入 AI 步骤，而无需额外搭建系统。你只需从某一列开始，把最脆弱的现有服务改写成一个 SELECT，跑 1 万行看看结果，就能快速判断是否合适，并省去把数据搬出去产生的额外开销。