在當今數據驅動的商業環境中，數據分析人員和營銷人員經常需要與復雜的數據庫交互以獲取洞察。然而，并非所有人都精通SQL等結構化查詢語言，這就催生了對自然語言接口的需求。本文將深入探討一種創新的意圖驅動自然語言接口，該接口結合了大型語言模型（LLM）和意圖分類技術，為數據潔凈室（Data Clean Rooms, DCRs）等隱私敏感環境提供了安全、高效的解決方案。

自然語言接口的挑戰與機遇

當數據分析師輸入“我們應該重新定位哪些隊列？”這樣的查詢時，他們實際上是在表達一種意圖，而非直接發出SQL命令。這種簡單的句子可能隱含著不同的操作，如細分排名、相似匹配或隊列比較。將這些模糊的提示轉化為結構化、符合政策的分析，需要的不僅僅是語言建模，更需要基于業務上下文和技術約束的語義理解。

傳統的文本到SQL模型在處理這類問題時往往力不從心，尤其是在隱私優先的環境中，如數據潔凈室，其中只能查詢經過批準的模型和自定義估計函數，無法訪問客戶可識別數據。在這種情況下，意圖分類成為關鍵技術，它將模糊的人類語言映射到結構化、可預測的類別，使下游系統能夠采取行動。

本文介紹的混合自然語言接口旨在將用戶意圖轉化為安全的SQL查詢，并將其應用于數據潔凈室等實際場景。在這些場景中，分析師和營銷人員跨品牌協作，他們擁有不同的技能組合，但通常不精通SQL，而是最了解自己的品牌業務，并且可能跨地區使用母語表達品牌意圖。

系統架構概述

我們的系統架構借鑒了現代搜索引擎的語義搜索原理，將用戶意圖和SQL提示模板嵌入到同一向量空間中，使用FAISS（Facebook AI Similarity Search）等技術將用戶查詢高效匹配到最合適的SQL模板。這種混合架構結合了以下關鍵組件：

1. 基于嵌入的意圖分類：使用OpenAI的text-embedding-3-small等模型將文本轉換為高維向量。
2. 基于FAISS的語義檢索：快速查找最近鄰意圖。
3. 模板驅動的SQL生成：考慮商店/品牌和隊列元數據。
4. 嚴格的模式引導LLM補全（作為備用）：當模板無法安全解析查詢時使用。

這種架構確保了系統的準確性、快速性和合規性，特別適合數據潔凈室中跨企業邊界的隱私保護數據協作。生成的查詢自動遵守分析師的訪問規則，例如：

• 無行級訪問（如無原始客戶ID）
• 僅應用所需的預批準轉換（如HyperLogLog草圖、標準化聚合）
• 只讀SQL（僅SELECT查詢）
• 由策略強制執行的模式和函數約束

意圖分類：系統的核心

意圖分類是該系統的基礎，它將非結構化的自然語言映射到結構化類別，從而驅動下游邏輯，如SQL模板選擇。一個單一的提示，例如“ComfyWearCo和SportStyleShop之間哪些隊列有重疊？”，可以被提煉為核心意圖：兩個品牌之間的隊列重疊。

意圖分類的重要性體現在以下幾個方面：

1. 消歧：幫助區分比較、查找、排名和探索性任務。
2. 安全：在任意文本到SQL生成之上強制執行基于模板的SQL路徑。
3. 速度：實現提示的快速路由，避免調用大型模型和產生幻覺輸出。

這些意圖使用每類5-10+個提示示例進行訓練、嵌入和索引。例如，隊列推薦、相似請求、隊列重疊、隊列比較和自然語言到SQL查詢等不同意圖都有相應的示例集。

基于嵌入的意圖分類數學原理

基于嵌入的意圖分類的核心是將自然語言提示轉換為高維向量空間中的點，使得語義相似的提示在空間中距離較近。我們使用OpenAI的text-embedding-3-small模型來生成這些嵌入，該模型能夠將文本轉換為1024維的向量。

在數學上，嵌入過程可以看作是一個函數f: T→V，其中T是文本提示的集合，V是d維向量空間（d=1024）。該函數保留了文本的語義相似性，即如果兩個提示在語義上相似，它們的嵌入向量在V中的歐幾里得距離或余弦相似度就會很近。

一旦生成了嵌入，我們就使用FAISS來構建索引，以便快速查找與新輸入提示最相似的示例。FAISS使用局部敏感哈希（LSH）等技術來加速高維空間中的最近鄰搜索，使得在大規模數據集上的實時檢索成為可能。

意圖分類器：嵌入+引導標注

在實現方面，我們使用OpenAI的text-embedding-3-small來嵌入每個意圖類別的精選標注提示示例，并使用FAISS對這些嵌入進行索引。以下是一個示例提示集：

• 隊列推薦：

建議我們可以在ComfyWearCo嘗試的未測試高價值隊列。

SportStyleShop中有哪些尚未使用的有前途的細分市場？

列出ComfyWearCo中尚未定位的高價值隊列。

• 相似請求：

SportStyleShop中哪些隊列與ComfyWearCo的隊列4相似？

在SportStyleShop中為ComfyWearCo的隊列2查找相似細分市場。

顯示ComfyWearCo隊列4與其他商店的最佳匹配。

• 隊列重疊：

跨品牌的哪些隊列有重疊用戶？

ComfyWearCo的隊列3和SportStyleShop的隊列4是否重疊？

• 隊列比較：

比較ComfyWearCo的隊列1和SportStyleShop的隊列2的指標。

顯示每個品牌的隊列1及其KPI。

• 自然語言到SQL查詢：

列出ComfyWearCo中客戶生命周期超過2.0的隊列。

按總訂單數顯示ComfyWearCo的頂級隊列。

索引代碼的大致流程如下：

1. 準備意圖示例，包括文本、預期意圖和語言。
2. 使用OpenAI API生成嵌入。
3. 將嵌入轉換為適合FAISS的格式。
4. 創建FAISS索引并添加嵌入。
5. 保存索引和元數據（意圖標簽和原始提示）用于運行時預測。

選擇FAISS而非基于SentenceTransformer的分類器，主要是因為FAISS具有以下優勢：

1. 零樣本泛化：通過添加更多標注示例即可輕松擴展，無需重新訓練。
2. 可解釋性：意圖由其最近鄰支持，可以進行檢查。
3. 無需模型訓練或托管：部署更快，維護更簡單。
4. 靈活性：支持開放世界分類和備用行為。

模式感知解析和商店映射

在數據潔凈室環境中，我們假設有多個品牌，如ComfyWearCo和SportStyleShop。基于隊列的數據模型的關鍵組件包括：

• hll_cohort_sketches_store_x1/hll_cohort_sketches_store_y1：存儲每個商店的隊列級指標的表，每個表由（store_id, cohort_id）鍵控，包含隱私保護的HLL草圖和標準化指標。
• Cohort_Similarity：表示跨商店隊列之間的相似性分數，引用草圖表中的（store_a, cohort_a）和（store_b, cohort_b）。

所有查詢生成，無論是通過模板還是LLM，都遵循這個實體關系模型，只使用可用字段和安全操作進行估計，如hll_estimate或hll_merge_agg。

由于自然語言中的品牌名稱（如“ComfyWearCo”）與內部表名和商店ID不同，我們使用brand_registry.json來捕獲映射關系，例如：

{
  "ComfyWearCo": {
    "store_id": "comfy_wear_store_view",
    "table": "hll_cohort_sketches_store_x1"
  },
  "SportStyleShop": {
    "store_id": "sporty_style_store_view",
    "table": "hll_cohort_sketches_store_y1"
  }
}

實體提取使用正則表達式和字符串匹配來檢測提示中的商店和隊列提及，這也使得該系統可以擴展到支持N個商店而無需更改實現。

基于模板的SQL生成

給定預測的意圖和提取的實體，我們使用特定于意圖的SQL模板。以下是隊列比較的示例：

SELECT 'ComfyWearCo' AS store_name, cohort_id,
       hll_estimate(cohort_hll_sketch) AS estimated_users,
       avg_standardized_avg_order_value,
       avg_standardized_total_orders,
       avg_standardized_customer_lifetime,
       avg_standardized_days_since_last_purchase
FROM hll_cohort_sketches_store_x1
WHERE cohort_id = 2 AND store_id = 'comfy_wear_store_view'
UNION ALL
SELECT 'SportStyleShop' AS store_name, cohort_id,
       hll_estimate(cohort_hll_sketch) AS estimated_users,
       avg_standardized_avg_order_value,
       avg_standardized_total_orders,
       avg_standardized_customer_lifetime,
       avg_standardized_days_since_last_purchase
FROM hll_cohort_sketches_store_y1
WHERE cohort_id = 4 AND store_id = 'sporty_style_store_view';

這種方法通過完全基于可用模式來避免生成幻覺SQL。

具有模式感知提示的LLM備用機制

如果沒有匹配的模板，我們會回退到LLM（在我們的示例中使用GPT-4），使用以下提示：

你是一名在安全數據潔凈室工作的數據分析師。僅使用SELECT語句。
僅使用提供的模式和函數。不要發明任何列或函數。
選擇單個隊列時使用hll_estimate(cohort_hll_sketch)。
除非跨行聚合，否則不要使用hll_merge_agg。
模式：
<SCHEMA TEXT>
用戶問題：
ComfyWearCo中哪些隊列的總訂單數最高？

這種受模式約束的提示大大減少了生成SQL中的錯誤。

示例查詢

意圖：相似請求

問題：SportStyleShop中哪些隊列與ComfyWearCo的隊列5最相似？

SELECT cohort_b, similarity_score_proxy
FROM cohort_similarity
WHERE store_a = 'comfy_wear_store_view'
  AND cohort_a = 5
  AND store_b = 'sporty_style_store_view'
ORDER BY similarity_score_proxy DESC
LIMIT 5;

意圖：隊列推薦

問題：建議ComfyWearCo中尚未使用的高價值隊列。

SELECT cohort_id, avg_standardized_avg_order_value, 
       avg_standardized_total_orders,
       avg_standardized_customer_lifetime, 
       avg_standardized_days_since_last_purchase
FROM hll_cohort_sketches_store_x1
WHERE store_id = 'comfy_wear_store_view' AND cohort_hll_sketch IS NULL
ORDER BY avg_standardized_avg_order_value DESC
LIMIT 5;

對高級數據潔凈室功能的可擴展性

我們的方法的一個關鍵優勢是它支持高級隱私保護功能，如HyperLogLog（HLL）草圖，這在數據潔凈室中常用于近似用戶計數而不暴露原始標識符。

HLL在數據潔凈室中的重要性

• 禁止行級數據，因此基數估計（如用戶計數）必須通過草圖計算。
• 允許使用hll_estimate和hll_merge_agg等函數，而不允許直接使用COUNT(DISTINCT user_id)。
• 跨品牌隊列之間的安全重疊和相似性依賴于HLL草圖的相似性。

我們的系統如何支持HLL

• 模板編碼為在選擇單個隊列時使用hll_estimate。
• 系統防止濫用，例如避免在非聚合查詢中使用hll_merge_agg。
• LLM備用機制使用有效的HLL函數用法和約束進行模式初始化。

評估：覆蓋范圍和準確性

為了驗證我們的方法，我們對30多個自然語言輸入運行了提示測試套件，每個輸入映射到我們支持的五個意圖之一。結果顯示，在各種意圖類型上都具有很高的準確性和語義覆蓋范圍。以下是一些代表性示例：

1. 提示：SportStyleShop中哪些隊列與ComfyWearCo的隊列3最相似？ 預測：lookalike_request | 預期：lookalike_request
2. 提示：比較ComfyWearCo的隊列4和SportStyleShop的隊列1。 預測：cohort_comparison | 預期：cohort_comparison
3. 提示：建議ComfyWearCo中我們尚未使用的新高價值隊列。 預測：cohort_recommendation | 預期：cohort_recommendation

評估證實，我們的基于FAISS的分類器與特定于意圖的模板相結合，為數據潔凈室中的各種探索性和診斷性查詢提供了準確、可解釋和安全的SQL。

擴展到其他LLM

盡管此實現使用OpenAI的GPT-4作為備用SQL生成，但該架構設計為與LLM無關。可以輕松替換為其他模型，如Anthropic的Claude、Google的Gemini或本地LLM如LLaMA 3。

如何替換LLM

重要的是，無論使用哪種LLM，基于FAISS的意圖分類器都保持不變。但是，如果選擇的LLM（如Claude或開源模型）不提供嵌入API，則需要在本地生成嵌入。

用SentenceTransformers替換OpenAI嵌入

可以通過sentence-transformers庫切換到本地嵌入模型，如all-MiniLM-L6-v2：

from sentence_transformers import SentenceTransformer
import numpy as np
model = SentenceTransformer("all-MiniLM-L6-v2")
def get_embedding(text):
    return model.encode([text])[0].astype("float32").reshape(1, -1)

這保持了基于FAISS的分類邏輯，同時與OpenAI的嵌入API解耦，還支持在氣隙或受監管環境中進行本地推理。

我們展示了一種混合系統，該系統將語義搜索（通過嵌入+FAISS）與為數據潔凈室環境量身定制的安全SQL生成相結合。通過將SQL生成基于模式和意圖模板，并僅在必要時回退到LLM，該架構在表達能力和安全性之間取得了實際平衡。

這種方法為在隱私受限的分析環境中構建智能接口提供了藍圖。未來的工作可以包括使用置信度分數對FAISS結果進行排名，進一步提高系統的準確性和可靠性。隨著數據隱私要求的不斷發展，這種意圖驅動的自然語言接口將在促進跨品牌數據協作方面發揮越來越重要的作用。