在數據倉庫中使用 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 萬行看看結果，就能快速判斷是否合適，並省去把數據搬出去產生的額外開銷。