引言
在上一篇文章《Apache Doris 4.0 AI 能力揭秘（一）：AI 函數之 LLM 函數介紹》中，我們介紹了 Apache Doris 4.0 如何通過原生集成 LLM 函數，將大語言模型的強大能力引入 SQL 分析場景，實現文本處理的智能化與內部分析的無縫化。這一能力不僅拓展了數據庫的邊界，也為數據密集型業務注入了全新的智能維度。
然而，技術能力的落地並不止於功能實現，真正的價值在於其在企業複雜場景中的穩定、高效與可管理的實踐。隨着 AI 函數在更多業務線中使用，如何將其從“可用”推進到“好用”、“可控”、“可規模化”，成為企業級應用的關鍵挑戰。 在本篇文章中，我們將深入探討在真實生產環境中應用 AI 函數的核心考量：Apache Doris LLM Function 的技術架構、核心功能特性、典型應用場景及性能優化策略，為相關技術實踐提供參考。
LLM Function 核心價值
在傳統的企業級數據分析架構中，文本數據的 AI 處理通常採用分離式模式：數據從數據庫導出，應用層調用外部 AI API 進行處理，然後將結果寫回數據庫。這種架構模式在實際生產環境中面臨數據一致性難以保障、性能瓶頸、運維複雜等挑戰。Apache Doris LLM Function 通過將大語言模型能力原生集成到 SQL 執行引擎中，從根本上解決了傳統架構的痛點，最顯著的優勢在於實現了事務一致性保障：AI 分析和數據操作在同一個 SQL 事務中完成，對於金融風控、訂單處理等對數據一致性要求極高的場景而言，帶來了至關重要的提升。
LLM Function 在性能上展現出顯著優勢：通過將 AI 處理內置於數據庫中，省去數據導出導入環節，大幅降低網絡與傳輸開銷，使處理時間從分鐘級縮短至毫秒級，顯著提升實時決策效率。此外，Apache Doris 查詢優化器可對包含 LLM 函數的 SQL 進行整體優化，支持並行執行、順序調度與緩存複用，結合 SQL 的批量處理能力，有效避免了逐條調用外部 API 的性能瓶頸，實現高效、可擴展的智能分析。
數據庫原生 AI 能力
01 技術架構設計思路深度解析
Apache Doris LLM Function 的設計理念體現了現代數據庫架構演進的重要趨勢：將 AI 能力深度集成到數據處理引擎的核心。這種設計思路與傳統的“數據導出 - 外部處理 - 結果迴流”模式形成鮮明對比，代表了一種更加高效、一體化的技術路徑。
從架構層面來看，LLM Function 採用了資源池化管理的設計模式。通過 CREATE RESOURCE 語句建立的 LLM 資源池，實現了對不同 AI 服務提供商（OpenAI、Anthropic、Gemini 等）的統一管理和動態調用。這種設計的技術優勢在於：首先是接口標準化，不同的 LLM 提供商通過統一的資源接口進行管理，避免了業務代碼與具體 AI 服務的強耦合；其次是負載均衡能力，可以根據不同的業務場景和性能要求，靈活選擇最適合的 LLM 資源；最後是故障隔離機制，單個 LLM 服務的異常不會影響到整個數據分析流程的穩定性。
在具體的技術實現上，LLM Function 的核心價值體現在其 SQL 原生集成能力。傳統的文本分析流程通常需要將數據從數據庫中導出，通過外部程序調用 AI 接口，然後將結果寫回數據庫。這個過程不僅涉及複雜的數據流轉，還存在數據一致性、事務管理、性能瓶頸等多個技術挑戰。而 LLM Function 通過將 AI 調用能力直接嵌入到 SQL 執行引擎中，實現了數據處理和 AI 分析的無縫融合。
從數據庫引擎的角度來看，LLM Function 的實現涉及了多個關鍵技術層面。在查詢優化器層面，需要對包含 LLM 函數的查詢進行特殊的優化處理，包括合理的執行順序安排、批量調用優化、緩存策略等。在執行引擎層面，需要處理異步 API 調用、超時管理、錯誤重試等複雜邏輯。在資源管理層面，需要實現對外部 API 調用的配額控制、併發限制、成本監控等功能。
02 AI 函數功能詳解
Apache Doris 提供的 10 個 LLM 函數覆蓋了文本處理的主要應用場景，每個函數都有其特定的技術特點和最佳適用場景。
-
AI_CLASSIFY 函數 是文本分類場景的核心工具：
在技術實現上，該函數接受文本內容和分類標籤作為參數，通過大語言模型的理解能力進行智能分類。與傳統的機器學習分類方法相比，AI_CLASSIFY 的最大優勢在於無需預訓練和特徵工程，可以通過自然語言描述的分類標準直接進行分類。在電商平台的用户評價分析中，傳統的方法可能需要預先定義大量的關鍵詞規則或訓練專門的分類模型，而 AI_CLASSIFY 可以通過語義理解，對複雜的用户反饋進行精準分類。
-- AI_CLASSIFY多維度分類示例 SELECT feedback_id, content, AI_CLASSIFY('primary_llm', content, '產品質量,物流服務,客户服務') as category, AI_CLASSIFY('primary_llm', content, '緊急,重要,普通') as priority FROM user_feedback WHERE create_time >= CURRENT_DATE - INTERVAL 1 DAY; -
AI_SENTIMENT 函數提供了比傳統情感分析更加細膩的情感識別能力：
傳統的情感分析主要基於詞彙情感詞典或簡單的機器學習模型，往往只能識別基本的正面、負面、中性情感，而且容易被表面的情感詞彙誤導。AI_SENTIMENT 通過深度的語義理解，能夠識別複雜的情感表達，包括諷刺、反語、多重情感等複雜情況。比如"雖然價格有點貴，但是確實物有所值"這樣的表述，傳統的情感分析可能會因為"貴"這個詞而判斷為負面，但 AI_SENTIMENT 能夠理解整體的正面傾向。
-- AI_SENTIMENT情感分析示例 SELECT review_id, review_text, AI_SENTIMENT('primary_llm', review_text) as sentiment, AI_EXTRACT('primary_llm', review_text, '提取關鍵問題點') as key_issues FROM product_reviews WHERE review_date >= CURRENT_DATE - INTERVAL 7 DAY; -
AI_EXTRACT 函數在信息提取場景中展現出了強大的結構化能力：
該函數能夠從非結構化的文本中提取特定的信息實體，其技術優勢在於能夠理解語義上下文，準確識別和提取關鍵信息。傳統的正則表達式提取在面對複雜的非結構化文本時往往力不從心，特別是當目標信息以不同的表達方式出現時。而 AI_EXTRACT 通過大語言模型的語義理解能力，可以識別同一概念的不同表達方式，大大提升了信息提取的準確性和覆蓋面。
- AI_GENERATE 函數是創意性文本生成的強大工具：
該函數可以基於給定的上下文和要求，生成符合特定風格和內容要求的文本。在實際應用中，這個功能可以用於自動生成產品描述、客服回覆模板、營銷文案等多種場景。與傳統的模板化生成不同，AI_GENERATE 能夠根據具體的上下文信息，生成更加個性化和相關性更強的內容。 - AI_TRANSLATE 函數提供了高質量的多語言翻譯能力：
與傳統的機器翻譯相比，基於大語言模型的翻譯能夠更好地理解上下文和語言的細微差別，產生更加自然和準確的翻譯結果。這對於跨國企業的多語言數據分析具有重要價值。 - AI_SUMMARIZE 函數可以對長文本進行智能摘要：
該函數能夠理解文本的主要內容和結構，提取關鍵信息並生成簡潔的摘要。在處理大量文檔、新聞文章、用户反饋等場景中，該功能可以大大提高信息處理的效率。 - AI_SIMILARITY 函數在文本相似度計算方面具有強大的語義理解能力：
傳統的相似度計算主要基於詞彙重疊（如餘弦相似度、Jaccard 相似度）或者簡單的向量距離，這些方法往往無法捕捉語義層面的相似性。AI_SIMILARITY 通過大語言模型的語義表示能力，能夠識別表達方式不同但語義相近的文本，在內容去重、相似問題匹配、推薦系統等場景中具有重要應用價值。 - AI_FIXGRAMMAR 函數專注於文本的語法糾錯和優化：
該函數不僅能夠識別和修正語法錯誤，還能夠改善文本的表達方式和可讀性。這在處理用户生成內容、文檔質量改進等場景中具有重要應用。 - AI_MASK 函數提供了智能化的敏感信息脱敏能力：
該函數能夠識別文本中的敏感信息（如個人身份信息、財務數據等），並進行適當的脱敏處理，這在數據安全和隱私保護方面具有重要價值。 - AI_FILTER 函數可以根據指定的條件對文本進行智能過濾：
該函數能夠理解複雜的過濾條件，並根據語義匹配進行文本篩選，在內容審核、質量控制等場景中具有重要應用。
03 資源管理和配置實踐深解
LLM Function 的資源管理機制是其技術架構的核心組成部分，理解和掌握資源配置的最佳實踐對於系統的穩定運行至關重要。
在生產環境中，LLM 資源的配置需要考慮多個關鍵因素。首先是 API 配額管理，不同的 LLM 服務提供商都有各自的調用頻率限制和計費模式。OpenAI 的 GPT 系列模型按照 token 數量計費，每分鐘有調用次數限制；Anthropic 的 Claude 系列有類似的限制機制；而 Google 的 Gemini 系列又有不同的配額策略。在配置資源時，需要根據業務的實際調用量和預算情況，合理選擇服務提供商和模型類型。
-- 創建生產環境的分層LLM資源配置
CREATE RESOURCE "high_performance_llm" PROPERTIES (
'type' = 'llm',
'llm.provider_type' = 'openai',
'llm.model_name' = 'gpt-4',
'llm.api_key' = '${OPENAI_API_KEY}',
'llm.max_tokens' = '2000',
'llm.temperature' = '0.3',
'llm.retry_times' = '3'
);
CREATE RESOURCE "cost_effective_llm" PROPERTIES (
'type' = 'llm',
'llm.provider_type' = 'openai',
'llm.model_name' = 'gpt-3.5-turbo',
'llm.api_key' = '${OPENAI_API_KEY}',
'llm.max_tokens' = '1000',
'llm.temperature' = '0.1'
);在資源選擇策略上，Apache Doris 提供了兩種方式：顯式指定和默認資源設置。在實際項目中，建議根據不同的業務場景採用不同的策略。對於批量處理場景，可以使用 SET default_AI_resource 設置默認資源，簡化 SQL 語句的編寫；對於實時查詢場景，建議在函數調用中顯式指定資源，確保調用的確定性和可控性。
-- 設置默認資源並進行智能資源選擇
SET default_AI_resource = 'cost_effective_llm';
-- 根據任務複雜度智能選擇資源
SELECT
customer_id,
feedback_text,
CASE
WHEN LENGTH(feedback_text) > 500 OR feedback_text LIKE '%複雜%'
THEN AI_SENTIMENT('high_performance_llm', feedback_text)
ELSE AI_SENTIMENT(feedback_text) -- 使用默認資源
END as sentiment_analysis
FROM customer_feedback
WHERE create_time >= CURRENT_DATE - INTERVAL 1 DAY;資源的性能調優也是生產環境部署的重要考慮因素。max_tokens 參數直接影響 API 調用的成本和響應時間，需要根據具體的文本處理需求進行調整。對於簡單的分類和情感分析任務，通常 500-1000 個 token 就足夠了；對於複雜的信息提取和文本生成任務，可能需要 2000 個或更多的 token。temperature 參數控制 AI 模型輸出的隨機性，對於需要確定性結果的分類和提取任務，建議設置較低的 temperature 值（0.1-0.3）；對於創意性的文本生成任務，可以適當提高 temperature 值（0.7-0.9）。
LLM Function 深度應用場景實踐
01 智能客户服務系統
在現代企業的客户服務體系中，海量的客户反饋、諮詢和投訴信息的處理一直是一個技術挑戰。傳統的人工處理方式效率低下，而簡單的關鍵詞匹配又難以準確理解客户的真實意圖。通過 Apache Doris LLM Function，我們可以構建一個高度智能化的客户服務分析系統。
系統的核心價值在於能夠在數據處理的同時完成 AI 分析，避免了傳統方案中數據在不同系統間流轉帶來的性能損耗和一致性問題。通過 SQL 原生的 AI 能力，客服團隊可以實時獲得智能化的分析結果，大大提升處理效率和服務質量。
-- 智能客户服務綜合分析系統
WITH customer_analysis AS (
SELECT
ticket_id,
customer_id,
content,
create_time,
-- 情感分析：識別客户情緒狀態
AI_SENTIMENT('primary_llm', content) as sentiment_score,
-- 問題分類：自動識別問題類型
AI_CLASSIFY('primary_llm', content,
'技術故障,賬務問題,物流查詢,產品諮詢,投訴建議') as issue_category,
-- 關鍵信息提取：自動提取結構化信息
AI_EXTRACT('primary_llm', content,
'提取訂單號、產品名稱、問題描述、期望解決方案') as key_info,
-- 緊急程度評估：確定處理優先級
AI_CLASSIFY('primary_llm', content, '緊急,重要,普通,低優先級') as priority_level
FROM customer_service_tickets
WHERE create_time >= CURRENT_DATE - INTERVAL 1 DAY
AND status IN ('new', 'in_progress')
)
SELECT
ca.*,
-- 生成處理建議
AI_GENERATE('primary_llm',
CONCAT('基於客户問題分析，生成專業的處理建議：',
'問題類型：', ca.issue_category,
'，客户情緒：', ca.sentiment_score,
'，關鍵信息：', ca.key_info),
300) as processing_suggestion
FROM customer_analysis ca
ORDER BY
CASE ca.priority_level
WHEN '緊急' THEN 1
WHEN '重要' THEN 2
WHEN '普通' THEN 3
ELSE 4
END,
ca.create_time DESC;在實際的生產環境部署中，這類分析查詢通常會被封裝成視圖或者存儲過程，供客服管理系統調用。系統可以實時展示智能分析結果，幫助客服代表快速理解客户問題、制定處理策略、提供個性化服務。
02 內容運營智能化分析平台
對於內容驅動的企業（如電商平台、媒體公司、在線教育等），內容質量和用户反饋的分析是業務優化的關鍵環節。傳統的內容分析往往依賴於簡單的統計指標（如點擊量、評論數等），難以深入理解內容的實際質量和用户的真實反饋。
通過 Apache Doris LLM Function，我們可以構建一個深度的內容智能分析平台。這個平台不僅能夠分析內容的基礎數據，還能理解內容的語義質量、用户反饋的情感傾向，甚至可以自動生成內容優化建議。
-- 內容運營智能分析平台
WITH content_analysis AS (
SELECT
c.content_id,
c.title,
c.author_id,
c.publish_time,
c.view_count,
c.comment_count,
-- 標題質量分析
AI_CLASSIFY('primary_llm', c.title,
'高吸引力,中等吸引力,低吸引力') as title_appeal,
-- 內容質量評估
AI_CLASSIFY('primary_llm', SUBSTRING(c.content, 1, 1000),
'優質內容,良好內容,普通內容,低質內容') as content_quality,
-- 可讀性評估
AI_CLASSIFY('primary_llm', SUBSTRING(c.content, 1, 1000),
'易讀,中等,困難') as readability_level
FROM content_posts c
WHERE c.publish_time >= CURRENT_DATE - INTERVAL 7 DAY
AND c.status = 'published'
),
user_feedback_analysis AS (
SELECT
uc.content_id,
COUNT(*) as total_comments,
-- 用户評論情感分佈統計
SUM(CASE WHEN AI_SENTIMENT('cost_effective_llm', uc.comment_text) LIKE '%正面%'
THEN 1 ELSE 0 END) as positive_comments,
SUM(CASE WHEN AI_SENTIMENT('cost_effective_llm', uc.comment_text) LIKE '%負面%'
THEN 1 ELSE 0 END) as negative_comments,
-- 用户建議彙總
AI_SUMMARIZE('primary_llm',
GROUP_CONCAT(CASE WHEN AI_CLASSIFY('cost_effective_llm', uc.comment_text, '建議,批評,讚揚') = '建議'
THEN uc.comment_text ELSE NULL END SEPARATOR ' | '),
200) as user_suggestions
FROM user_comments uc
WHERE uc.create_time >= CURRENT_DATE - INTERVAL 7 DAY
GROUP BY uc.content_id
)
SELECT
ca.*,
ufa.total_comments,
ufa.positive_comments,
ufa.negative_comments,
ROUND(ufa.positive_comments * 100.0 / NULLIF(ufa.total_comments, 0), 2) as positive_ratio,
ufa.user_suggestions,
-- 生成優化建議
AI_GENERATE('primary_llm',
CONCAT('基於內容分析數據，提供具體的優化建議：',
'標題吸引力：', ca.title_appeal,
'，內容質量：', ca.content_quality,
'，用户建議：', COALESCE(ufa.user_suggestions, '暫無')),
300) as optimization_suggestions
FROM content_analysis ca
LEFT JOIN user_feedback_analysis ufa ON ca.content_id = ufa.content_id
ORDER BY
CASE ca.content_quality
WHEN '優質內容' THEN 1
WHEN '良好內容' THEN 2
WHEN '普通內容' THEN 3
ELSE 4
END,
ca.view_count DESC;03 金融風控智能決策系統
金融行業的風險控制一直是數據分析技術應用的重要領域。傳統的風控模型主要基於結構化數據（如交易金額、頻次、地理位置等），而對於非結構化的文本數據（如客户描述、申請材料、通話記錄等）的利用相對有限。
LLM Function 的引入為金融風控提供了新的技術手段。通過自然語言處理能力，可以更好地理解和分析客户的行為模式、風險傾向和潛在欺詐信號，大大提升風控決策的準確性和效率。
-- 金融風控智能決策系統
WITH risk_assessment AS (
SELECT
application_id,
customer_id,
application_text,
declared_income,
requested_amount,
-- 申請意圖分析
AI_CLASSIFY('high_performance_llm', application_text,
'正常消費,正常投資,緊急資金,投機需求,可能虛假') as intention_analysis,
-- 風險關鍵詞提取
AI_EXTRACT('high_performance_llm', application_text,
'提取風險信號：債務情況、收入不穩定、投資損失、法律糾紛') as risk_indicators,
-- 財務一致性檢查
AI_CLASSIFY('high_performance_llm',
CONCAT('申請描述：', application_text, ' 聲明收入：', declared_income, ' 申請金額：', requested_amount),
'高度一致,基本一致,存在矛盾,嚴重不符') as financial_consistency,
-- 欺詐風險評估
AI_CLASSIFY('high_performance_llm', application_text,
'低風險,中等風險,高風險,極高風險') as fraud_risk_level
FROM loan_applications
WHERE application_date >= CURRENT_DATE - INTERVAL 1 DAY
AND status = 'pending_review'
),
risk_scoring AS (
SELECT
*,
-- 計算綜合風險評分
(CASE intention_analysis
WHEN '可能虛假' THEN 35
WHEN '投機需求' THEN 25
WHEN '緊急資金' THEN 15
ELSE 5
END +
CASE financial_consistency
WHEN '嚴重不符' THEN 25
WHEN '存在矛盾' THEN 15
ELSE 0
END +
CASE fraud_risk_level
WHEN '極高風險' THEN 30
WHEN '高風險' THEN 20
WHEN '中等風險' THEN 10
ELSE 0
END) as total_risk_score
FROM risk_assessment
)
SELECT
*,
-- 自動決策建議
CASE
WHEN total_risk_score >= 50 THEN '拒絕申請'
WHEN total_risk_score >= 30 THEN '人工審核'
WHEN total_risk_score >= 15 THEN '降低額度'
ELSE '可以批准'
END as decision_recommendation,
-- 生成詳細審批建議
AI_GENERATE('high_performance_llm',
CONCAT('基於風險分析，提供審批建議：',
'總風險評分：', total_risk_score,
'，主要風險：', intention_analysis,
'，風險指標：', risk_indicators),
250) as detailed_recommendation
FROM risk_scoring
ORDER BY total_risk_score DESC;性能優化與成本控制策略深度解析
01 API 調用成本優化的系統性方法
在 LLM Function 的實際應用中，API 調用成本往往是需要重點考慮的因素。不同的 LLM 服務提供商有着不同的計費模式，而且同一個提供商的不同模型在性能和成本之間也存在明顯的權衡關係。構建一個成本效益最優的 LLM 應用需要從多個維度進行系統性的優化。
分層資源策略是成本優化的核心思路。根據不同任務的複雜程度和準確性要求，選擇合適的模型資源。對於簡單的分類和情感分析任務，使用較小的模型（如 GPT-3.5-turbo）通常能夠獲得足夠好的效果，而成本顯著低於大模型；對於複雜的信息提取和生成任務，則需要使用更強大的模型來保證輸出質量。
-- 智能化的成本控制策略
WITH task_complexity_assessment AS (
SELECT
feedback_id,
feedback_text,
LENGTH(feedback_text) as text_length,
CASE
WHEN LENGTH(feedback_text) < 100 AND feedback_text NOT REGEXP '[複雜|詳細|具體]'
THEN '簡單任務'
WHEN LENGTH(feedback_text) BETWEEN 100 AND 500
THEN '中等任務'
ELSE '複雜任務'
END as task_complexity
FROM customer_feedback
WHERE create_time >= CURRENT_DATE - INTERVAL 1 HOUR
)
SELECT
feedback_id,
feedback_text,
task_complexity,
-- 根據任務複雜度選擇合適的資源
CASE task_complexity
WHEN '簡單任務' THEN
AI_SENTIMENT('cost_effective_llm', feedback_text)
WHEN '中等任務' THEN
AI_SENTIMENT('balanced_llm', feedback_text)
ELSE
AI_SENTIMENT('high_performance_llm', feedback_text)
END as sentiment_analysis,
-- 成本估算
CASE task_complexity
WHEN '簡單任務' THEN 0.01
WHEN '中等任務' THEN 0.03
ELSE 0.08
END as estimated_cost
FROM task_complexity_assessment;智能緩存策略是另一個重要的成本優化手段。對於相同或相似的文本輸入，可以通過建立緩存機制避免重複的 API 調用。在 Apache Doris 中，可以通過創建專門的緩存表來實現這一功能：
-- 智能緩存系統
CREATE TABLE AI_cache (
content_hash VARCHAR(64),
function_name VARCHAR(50),
original_text TEXT,
result_text TEXT,
confidence_score DECIMAL(3,2),
cache_time DATETIME,
hit_count INT DEFAULT 1,
INDEX idx_hash_function (content_hash, function_name)
) DISTRIBUTED BY HASH(content_hash);
-- 使用緩存的查詢邏輯
SELECT
cf.feedback_id,
cf.feedback_text,
COALESCE(
CASE WHEN lc.result_text IS NOT NULL AND
AI_SIMILARITY('cost_effective_llm', cf.feedback_text, lc.original_text) > 0.9
THEN lc.result_text
ELSE AI_SENTIMENT('primary_llm', cf.feedback_text)
END
) as sentiment_result,
CASE WHEN lc.result_text IS NOT NULL THEN 'cache_hit' ELSE 'api_call' END as source
FROM customer_feedback cf
LEFT JOIN AI_cache lc
ON MD5(cf.feedback_text) = lc.content_hash
AND lc.function_name = 'AI_SENTIMENT'
AND lc.cache_time >= CURRENT_DATE - INTERVAL 7 DAY
WHERE cf.create_time >= CURRENT_DATE - INTERVAL 1 HOUR;02 查詢性能調優的最佳實踐
LLM Function 的查詢性能優化涉及多個層面，從 SQL 查詢結構的優化到系統資源的合理配置，都需要進行系統性的考慮。
在查詢結構優化方面，合理的 JOIN 順序和 WHERE 條件的放置對於整體性能有重要影響。由於 LLM Function 的調用成本較高，應該儘可能地在早期階段過濾數據，減少需要進行 AI 分析的數據量：
-- 性能優化的查詢結構設計
WITH filtered_data AS (
-- 第一步：基礎數據過濾，減少後續AI分析的數據量
SELECT *
FROM customer_feedback
WHERE create_time >= CURRENT_DATE - INTERVAL 1 DAY
AND content IS NOT NULL
AND LENGTH(content) BETWEEN 20 AND 2000
AND customer_id IN (
SELECT customer_id
FROM active_customers
WHERE last_activity >= CURRENT_DATE - INTERVAL 30 DAY
)
),
priority_analysis AS (
-- 第二步：先進行簡單的優先級分類
SELECT
*,
AI_CLASSIFY('cost_effective_llm', content, '高優先級,普通優先級') as priority_class
FROM filtered_data
)
-- 第三步：只對高優先級內容進行詳細分析
SELECT
feedback_id,
customer_id,
content,
priority_class,
CASE
WHEN priority_class = '高優先級' THEN
AI_SENTIMENT('high_performance_llm', content)
ELSE
AI_SENTIMENT('cost_effective_llm', content)
END as sentiment_analysis
FROM priority_analysis
WHERE sentiment_analysis IS NOT NULL
ORDER BY
CASE priority_class WHEN '高優先級' THEN 1 ELSE 2 END;03 權限管理與安全控制
Apache Doris LLM Function 在 4.0 預覽版中已經提供了基礎的權限控制體系，確保 LLM 資源的安全使用。當前的權限管理主要基於 Apache Doris 的統一權限框架，對 LLM 資源實施訪問控制。
在當前版本中，權限控制主要通過 Usage_priv 權限實現，管理員可以控制哪些用户或角色能夠使用特定的 LLM 資源。這種權限控制機制確保了只有授權用户才能調用 LLM Function，避免了資源的濫用和安全風險。權限的分配可以基於角色進行管理，也可以直接分配給特定用户，提供了靈活的權限管理方式。
-- LLM資源權限管理示例
-- 創建專門的LLM用户角色
CREATE ROLE AI_analyst;
-- 為角色分配LLM資源使用權限
GRANT USAGE_PRIV ON RESOURCE 'primary_llm' TO ROLE 'AI_analyst';
GRANT USAGE_PRIV ON RESOURCE 'cost_effective_llm' TO ROLE 'AI_analyst';
-- 將角色分配給特定用户
GRANT 'AI_analyst' TO 'data_scientist@company.com';需要注意的是，當前版本的權限控制粒度相對較粗，主要針對資源級別的訪問控制。對於更細粒度的控制需求，如單用户的 LLM API 併發度限制、MaxTokens 參數控制、成本配額管理等功能，將在 Apache Doris 4.0 正式版中得到完善。同時，4.0 正式版還將加入完整的 LLM Function 調用監控和統計系統，包括調用頻次、成本分析、性能監控等關鍵指標的自動收集和分析功能，為企業級應用提供更加完善的運維支持。
技術發展趨勢和未來展望
01 AI 原生數據庫的演進方向
Apache Doris LLM Function 的推出標誌着數據庫技術向 AI 原生方向演進的重要里程碑。這種演進不僅僅是功能層面的簡單疊加，而是代表了數據處理架構的根本性變革。
從技術發展的歷史脈絡來看，數據庫系統經歷了從簡單的數據存儲到複雜的分析計算的演進過程。早期的數據庫主要關注數據的持久化和基本的查詢功能，隨後發展出了複雜的分析函數、存儲過程等高級特性。而 AI 能力的原生集成，代表了數據庫技術演進的下一個重要階段。
計算下推的深度擴展是這一演進的核心特徵。傳統的計算下推主要針對結構化數據的統計和聚合操作，目標是減少數據在網絡中的傳輸量，提高查詢性能。而 AI 計算的下推則擴展到了非結構化數據的語義理解和智能分析。這種擴展不僅提高了處理效率，更重要的是改變了數據分析的範式，使得複雜的 AI 分析可以與傳統的 SQL 查詢無縫融合。
在未來的發展中，多模態 AI 集成將是一個重要的發展方向。除了當前的文本處理功能外，圖像識別、語音分析、視頻理解等 AI 能力都有可能成為數據庫的原生功能。這將使得數據庫能夠處理更加豐富和複雜的數據類型，為企業提供更加全面的智能化數據分析能力。
邊緣 AI 計算將是另一個重要的發展趨勢。隨着 AI 模型的小型化和優化技術的發展，越來越多的 AI 計算可能會直接在數據庫引擎內部進行，而不是依賴外部 API 服務。這種變化將帶來顯著的性能提升和成本降低，同時也會增強數據的安全性和隱私保護。
02 企業級 AI 數據分析的發展趨勢
從企業應用的角度來看，AI 數據分析正在從輔助工具向核心基礎設施轉變。這種轉變對企業的數據架構、組織結構和業務流程都產生了深遠的影響。
數據治理的智能化是一個明顯的發展趨勢。傳統的數據治理主要依賴人工定義的規則和策略，這種方式在面對海量數據和複雜業務場景時往往力不從心。而 AI 能力的引入使得數據治理可以變得更加智能和自適應。通過 LLM Function，企業可以自動識別敏感數據、發現數據質量問題、推薦數據分類標準、生成數據字典等，大大提升數據治理的效率和準確性。
決策支持的實時化是另一個重要趨勢。在數字化轉型的浪潮中，企業對實時決策支持的需求越來越強烈。傳統的數據分析往往需要較長的處理時間，難以滿足實時決策的需求。通過 LLM Function，企業可以構建實時的智能決策系統，在業務事件發生的同時進行 AI 分析和決策支持，大大提升業務響應的速度和準確性。
成本效益的平衡優化將成為企業級 AI 應用的關鍵考量因素。隨着 AI 技術的普及，如何在保證分析效果的同時控制成本，將是企業面臨的重要挑戰。這需要在技術架構、資源配置、業務流程等多個層面進行系統性的優化，實現成本效益的最佳平衡。
總結
Apache Doris LLM Function 作為數據庫技術與人工智能深度融合的創新實踐，標誌着數據分析領域向智能化方向演進的重要里程碑。通過將大語言模型能力原生集成到 SQL 執行引擎中，有效解決了傳統數據分析架構中 AI 能力集成的技術挑戰。
- 從技術架構層面來看，LLM Function 採用資源池化管理和 SQL 原生集成的設計理念，實現了 AI 處理能力與數據查詢的無縫融合。十大核心函數覆蓋了文本分析、內容生成、數據處理等主要應用場景，為企業級智能化數據分析提供了完整的技術工具集。
- 在實踐應用方面，通過智能客服、內容運營、金融風控等典型場景的深度分析，驗證了 LLM Function 在提升業務效率、優化決策質量、降低運營成本方面的顯著價值。同時，通過系統化的性能優化和成本控制策略，為該技術在生產環境中的大規模部署提供了可靠保障。
本文系統闡述了 Apache Doris LLM Function 的技術價值和應用前景，期望為相關技術從業者在智能化數據分析領域的探索和實踐提供有益參考。展望未來，隨着 AI 原生數據庫、多模態智能分析、邊緣計算等技術的持續發展，Apache Doris LLM Function 所代表的技術路徑將在企業數字化轉型中發揮更加重要的作用。
