数据仓库中AI函数的高价值用例
DataHot 速览
Databricks 介绍在数据仓库中直接使用 AI 函数处理非结构化数据（如评论、工单、PDF）并与结构化数据结合。通过 SQL 调用模型，推理过程保留在现有管道和 Unity Catalog 治理范围内，支持默认安全治理、SQL 原生使用、统一计费及专用函数如 ai_classify、ai_extract 等。该方案可避免数据搬移带来的安全风险，并简化 AI 工作流。
为什么值得关注：展示数据仓库平台如何将 AI 能力内嵌到 SQL 分析流程，兼顾治理与易用性，对数据平台建设者具有直接参考价值。
本文目录 10 节
译文
AI 逐段翻译在大多数组织中，数据仓库存储结构化数据，而非结构化数据保存在数据湖中。这对于分析工作负载很有效，这些工作负载大规模消费结构化数据，日复一日地为已知的报告集合提供服务。
然而，AI工作负载需要不同的输入。AI模型通常需要解析非结构化数据（如评论、支持工单和PDF），并将它们与结构化数据结合，以训练、构建和服务模型。因此，分析师想要对支持工单进行情感分析，必须将数据行发送到外部服务，等待预测结果，然后手动将结果拼接回表中。这个过程缓慢，当模式变化时会中断，并引入不必要的安全和治理风险。
AI函数通过将AI直接带到数据所在之处，而不是将数据移动到单独的AI环境来解决这个问题。你可以在标准SQL查询中调用模型，将整个推理过程保留在现有管道和Unity Catalog治理之内。这种架构从根本上改变了你在数据仓库中使用AI的方式：
- 默认治理：因为AI函数遵循Unity Catalog权限，你的数据保持安全和私密。模型只能访问你明确允许的数据。
- SQL原生简单性：如果你能编写
SELECT语句，你就能使用AI构建。Databricks管理复杂性——规划、并行化和重试，因此你无需担心集群管理或外部编排。对一百万行运行推理与对一行运行一样容易，相同的查询无需重写即可扩展。 - 统一计费：消除协调不同仪表板的复杂性。AI使用情况出现在
system.billing.usage中，与标准Databricks SQL仓库成本并列。 - 专用函数：以更低成本获得更好结果。通过使用特定任务的函数——例如
ai_classify、ai_extract、ai_translate和ai_parse_document——你可以利用针对特定任务定制的模型，而不是为通用推理支付额外费用。
你可以在Databricks的任何地方使用这些AI函数，包括笔记本、Lakeflow Spark Declarative Pipelines和Workflow。但在本文中，我们特别关注从Databricks Lakehouse调用这些函数。以下用例将展示如何将这些AI函数集成到需要将数据仓库中的结构化数据与非结构化数据（来自数据仓库外部或通过GenAI支持的函数自行生成）结合的工作负载中。
用例1：文档智能，从原始文件到结构化行
ai_parse_document充当摄取桥梁，将原始二进制文件内容（如PDF或图像）转换为可读文本。解析后，ai_extract处理特定键和值的精细提取。这种组合方法消除了对脆弱的自定义OCR管道或第三方解析服务的需求，这些服务在模式变化时常常中断。
在此用例中，我们将ai_parse_document指向包含发票的Databricks卷。解析这些发票后，AI解析文档以JSON形式生成结果，然后传递给ai_extract函数，在函数中我们定义要从这些发票中提取的实体。结果是一个包含我们要从发票中提取的字段的结构化表。
现在，从原始PDF到提取行的数据沿袭在单个查询计划中运行。人们手工构建的桥梁——Python OCR服务、LLM调用和JSON展平步骤——全部并入查询中。
用例2：客户反馈的情感分析
该ai_classify函数执行零样本分类，将自由文本反馈映射到一组用户定义的标签，无需模型训练。此过程将混乱的非结构化文本转换为受治理的、可查询的列，使情感和主题数据立即可用于BI仪表板和行政报告。
在此示例中，我们希望将bronze.nps_responses表中的客户评论分类为正面、负面、中性和混合。
用例3：多语言数据的内联翻译
使用ai_translate，你可以直接在查询层将多语言数据规范化为单一目标语言。这防止了数据孤岛和碎片化，使所有下游分析（包括分类和提取）能够同时处理整个全球数据集，而不是仅处理纯英语切片。
在此示例中，我们从不同客户评论中提取情感，然后将它们翻译成英语。
用例4：大规模分类和路由
专注于操作效率，ai_classify将自由形式的输入（如支持工单或通话记录）转换为可操作的类别。通过在摄取点识别传入反馈的意图和紧急程度，它能够实现自动化的智能路由到相应团队或自动响应系统。
在下面的用例中，我们从表中摄取不同的支持工单，然后使用ai_classify来确定工单的用户意图和紧急程度。
用例5：使用ai_extract进行销售通话结构化提取
该ai_extract函数旨在从长文本内容（如销售通话记录）中挖掘半结构化信息，并将叙述文本转换为离散的结构化字段。这通过将定性信息直接放入BI工具中提供了重要价值，有效地将口头对话转化为可查询的指标，如交易阶段和风险标志。
在此用例中，我们挖掘冗长的记录，以确定下一步、交易阶段、风险标志和风险原因，以便销售人员能够对产生记录会议的结果采取行动。
用例6：使用ai_query进行生成性起草
ai_query是最通用的函数，也是其他函数的基础：它允许您向任何Databricks托管的Foundation Model服务端点发送提示，并针对每一行返回模型的答案。
在此用例中，我们可以使用ai_query为虚构的gold.renewal_signals表中的每个客户账户起草续订外联电子邮件，该表显示哪些账户已准备好续订。
由于您编写提示，它可以做模型能做的一切，这就是为什么它能处理更具体函数无法处理的情况。
生产环境专业提示
- 第一天就标记作业：这将使您能够将AI函数的成本归因于正确的作业
- 先尝试特定任务的函数：仅当ai_classify、ai_extract、ai_parse_document或ai_translate都不适用时，才使用ai_query
- 要求结构化输出：对于ai_query，使用responseFormat来获得结构化输出。如果您传递一个DDL STRUCT模式，您将获得类型化字段，而不是原始字符串；JSON-schema/json_object格式仍返回JSON字符串。
- 有意识地选择模型：每个基础模型都有成本、性能和受支持的输入格式等权衡。确保您有意识地决定为哪个用例选择哪个模型
- 在扩展前先采样：至少运行10,000行，阅读输出，然后运行其余部分。成本-准确性权衡因用例而异。
- 将提示视为代码：对它们进行版本控制，在拉取请求中审查，注释它们。在此工作流中，提示是包含业务逻辑的转换
这对您的数据仓库战略意味着什么
贯穿所有六个用例的主线是相同的。AI与仓库的其余部分运行在同一位置：一个平台、一个治理模型、一张账单、一组管道。您现有的SQL ETL的任何一行都可以加入AI步骤，而无需架设系统来托管它，并且每个以前在旁路翻译、评分或分类数据的Python脚本都可能成为一行替换的候选。
因此，从一个列开始。选择当前服务最脆弱的工作负载，将其重写为SELECT，在10,000行上运行，并阅读返回的内容。经过短暂的冲刺，您就会知道它是否适合——并且您将停止为导出数据而支付的额外开销。
演示笔记本
每个笔记本都附带内联示例数据、逐步SQL以及您应期望的输出。
继续阅读
这篇内容对你有用吗？
反馈只用于改善内容筛选，不等同于收藏