作为数据工程师，我们都遇到过业务利益相关者的那些重复性请求：“你能把这些文本总结成高管能快速阅读的内容吗？"，“我们能将客户评论翻译成英语以便大家分析吗？"，或者"我们能否在不构建新流水线的情况下大规模衡量客户情感？"。传统上，交付这些功能需要大量繁重工作。您必须将原始数据从数据仓库导出到Python笔记本中，清理和预处理数据，连接到外部NLP API或托管自己的机器学习模型，处理重试，管理成本，然后编写另一个作业将结果推回到Delta表中。这个过程很脆弱，需要多个移动部件，而且最重要的是，将分析带出了治理环境，造成了合规性和可重复性风险。

随着Databricks SQL中AI函数的引入，这种复杂性被抽象化了。摘要、翻译、情感检测、文档解析、脱敏甚至语义搜索现在都可以通过一行SQL函数来表达，直接对治理数据运行。不需要额外的基础设施，不需要维护外部服务，也不需要照管自定义的ML部署。只需SQL，在Lakehouse内部进行治理和扩展。

在本文中，我将使用熟悉的Bakehouse示例数据集带您了解五个这样的函数。我们将看到曾经需要自定义流水线和数周工程努力的任务如何被简化为简单查询，将AI从专业项目转变为数据工程师的日常工具。

1. 使用ai_summarize()进行摘要

如果您过去想要总结Bakehouse客户评论，工作流程绝不简单。评论通常很长、非结构化且以自由形式文本编写——这意味着它们包含从俚语和错别字到表情符号、混合语言和不完整句子的所有内容。从Delta表中提取原始评论只是开始。真正的挑战是使该文本可用于下游分析。

首先，您必须清理和规范化数据：删除非标准字符，修复大小写不一致，去除表情符号或特殊符号，有时甚至检测和过滤不同的语言。只有在预处理之后，您才能将清理后的文本输入到基于Python的摘要模型（如Pegasus、BART或T5）中。大规模运行这些模型引入了自己的操作开销：管理GPU、批处理请求、处理长输入序列以及将生成的摘要存储回Delta表。最后，您必须编写额外的逻辑来提取有用的信号——通常将冗长、杂乱的评论简化为简短的两句话要点。整个流水线脆弱、资源密集且需要持续维护。

借助Databricks SQL中新的ai_summarize()函数，这整个过程被压缩为一行代码。您只需将原始评论文本传递给函数，它就会直接作为查询结果返回简洁的摘要。无需单独的预处理，无需外部API，无需ML流水线维护——只需SQL。该函数足够智能，可以处理自由形式文本，消除噪音，并呈现客户反馈的主要观点。

在我们查看摘要本身之前，让我们首先通过一个简单查询探索Bakehouse数据集中review_text列的原始复杂性：

1
2
3

select franchiseID, review_date, review
FROM samples.bakehouse.media_customer_reviews
LIMIT 25;

现在，让我们使用ai_summarize函数来总结评论：

1
2
3
4
5

SELECT
      ai_summarize(CONCAT('Franchise: ', franchiseID,
                          ', Review: ',review))  franchise_review
FROM samples.bakehouse.media_customer_reviews
LIMIT 25;

2. 使用ai_translate()进行翻译

考虑这个场景：日本的Bakehouse管理团队想要分析客户评论，但大多数反馈是以英语存储的。对于日本团队来说，阅读英语评论造成了障碍；不仅减慢了分析速度，还引入了误解或错过文化细微差别的风险。作为数据工程师，我们都处理过这类请求：“你能让这个数据集以我们的本地语言可用吗？”

传统上，这意味着将评论从Delta表中导出，将它们连接到第三方翻译API，管理身份验证和配额，处理错误和重试，然后将翻译后的文本加载回数据仓库。这是一个多步骤过程，需要维护脆弱的ETL流水线，并且经常引发合规性问题，因为敏感的客户数据必须离开治理环境。

使用ai_translate()，这整个工作流程被压缩为单个SQL查询。该函数将原始评论文本作为输入，并以目标日语输出相同内容。对于Bakehouse数据集，这意味着日本团队可以立即以其本地语言访问评论，无需任何额外基础设施。

1
2
3
4

SELECT franchiseID, review_date, review, ai_translate(review,  'ja') AS review_japanese
FROM samples.bakehouse.media_customer_reviews
WHERE review like '%Tokyo%'
LIMIT 10;

3. 使用ai_analyze_sentiment()进行情感分析

传统上，数据工程师或数据科学家必须在Python中构建或微调情感分析模型，通常从TensorFlow、PyTorch或Hugging Face等框架开始。该过程涉及收集标记数据、训练或微调分类器、验证模型，然后将其打包成可部署的服务。一旦部署，该服务必须托管在GPU或CPU端点上，监视正常运行时间，并为生产负载维护扩展逻辑。除此之外，工程师还必须编写流水线作业将原始评论文本发送到端点，收集预测结果，并将结果存储回Delta表。所有这一切工作只是为了回答一个看似简单的问题：“我们的客户满意吗？”

借助Databricks的ai_analyze_sentiment()函数，这整个工作流程被减少到一行SQL。无需训练模型、部署端点或管理基础设施。您可以将原始评论文本直接输入函数，它会自动返回情感标签，如积极、消极或中性。

1
2
3

SELECT review, ai_analyze_sentiment(review) AS sentiment
FROM samples.bakehouse.media_customer_reviews
LIMIT 25;

4. 使用ai_mask()脱敏PII数据

保护个人可识别信息（PII）是数据工程师面临的最具挑战性的任务之一。我在DZone上写过一篇关于构建可扩展数据安全的详细文章。ai_mask()函数根据输入参数自动检测和脱敏PII数据。Bakehouse分析团队可以安全地分析评论，而不会暴露敏感的客户数据，所有这些都直接在SQL中完成，无需自定义正则表达式。

1
2
3

SELECT franchiseID,review_date,ai_mask(review, ARRAY('PERSON', 'EMAIL', 'PHONE_NUMBER')) as masked_review
FROM samples.bakehouse.media_customer_reviews
LIMIT 10;

结论

我们探索的示例包括ai_summarize、ai_translate、ai_analyze_sentiment、ai_parse_document和ai_mask，它们展示了AI的使用如何简化工程团队的工作负载，并允许他们进行快速分析。曾经需要复杂流水线、自定义Python脚本或外部API的任务现在被简化为简单的一行SQL函数。在撰写本文时，这些AI SQL函数处于公共预览阶段，并可能随着Databricks扩展其功能而发展。