在 Looker 中設定對話式數據分析的最佳做法

對話式數據分析會使用 Gemini for Google Cloud 解讀自然語言問題，並以 Looker 語意模型 (LookML)、資料值和資料代理設定做為資料來源。回覆品質取決於您準備這些輸入內容的成效。

本指南提供策略和最佳做法，協助 LookML 開發人員和管理員設定及最佳化對話式數據分析。請根據這些建議調整 LookML 模型、探索和資料代理程式，提高使用者採用率，並確保使用者獲得準確、相關且實用的問題解答。本指南將依循邏輯流程，說明與對話式分析相關的最佳做法，從在模型 LookML 中建立穩固基礎開始，逐步說明如何設定以該模型為基礎的探索，以及如何建構以這些探索做為資料來源的資料代理程式。

對話式數據分析的 LookML 最佳做法

對話式數據分析會運用下列主要輸入內容解讀自然語言問題：

  • LookML 模型：代理程式會擷取與其連結的「探索」結構定義。結構定義包含欄位 (維度、測量指標)、篩選器限定欄位 (篩選器、參數)，以及 Looker 探索基礎 LookML 模型中定義的對應標籤、說明和同義字。如需 Conversational Analytics 分析的 LookML 參數完整清單，請參閱「Conversational Analytics 總覽」。
  • 不重複的欄位值：代理程式可以對資料值進行取樣，並執行模糊搜尋，檢查基礎資料庫中的特定欄位值。這些方法可讓服務專員選擇正確的欄位、套用正確的篩選值，並找出使用者可能會詢問的可用類別和實體。

對話式數據分析的成效與這些輸入內容的品質和清晰度直接相關。下表列出 LookML 不清楚或模稜兩可時，對對話式數據分析造成的負面影響，以及減少延遲時間、提升輸出內容和使用者體驗的解決方案。

LookML 品質問題 解決方案：更清楚的對話式數據分析
不夠清楚和命名衝突：如果欄位缺少明確的標籤、定義模糊不清，或在不同檢視畫面中名稱相似，可能會導致選取錯誤的欄位。 套用清楚的標籤並提供詳盡說明：
  • 使用 label 參數為欄位提供直覺易懂的商家名稱。
  • 使用說明參數提供重要背景資訊、自然語言定義和產業專用術語。對話式數據分析會使用說明，更準確地識別欄位意義並對應使用者用語。
欄位過多：如果公開太多欄位，例如內部 ID、來自聯結的重複欄位或中繼計算，對話式數據分析可用的選項就會變得雜亂。 隱藏不相關的欄位：請確保所有主鍵、外鍵和技術欄位都隱藏。

(選用) 擴充探索：如果探索包含許多欄位，建議擴充現有探索，為對話式數據分析建立專屬版本。
取樣和搜尋的資料庫負載：從資料庫擷取樣本值和建議可能很慢，或會產生不必要的負載，尤其是使用者在查詢中參照特定資料值時。 在 LookML 中定義建議：避免對欄位建議進行即時資料庫查詢，方法是硬式編碼值或指向更有效率的維度：
資料查詢的資料庫負載：大型或效率不彰的查詢可能會增加延遲和資料庫負載。 最佳化資料查詢：遵循查詢效能最佳化的一般最佳做法，例如使用匯總感知和有效率的聯結邏輯。
LookML 定義不完整：如果依賴資訊主頁層級的自訂欄位或資料表計算，對話式數據分析就無法存取重要的商業邏輯。 納入自訂邏輯：將重要且常用的自訂欄位或資料表計算轉換為 LookML 維度和測量指標。
資料雜亂：下列類型的不一致或結構不良資料，會導致對話式分析難以準確解讀查詢。
  • 值變化：大小寫或命名慣例不一致 (例如，值 complete、Complete 和 COMPLETE 混用)，可能會導致資料重複，或對話式數據分析中的資料關係不正確。
  • 資料類型不一致：如果資料欄應為數值，但偶爾包含字串值，系統會強制將欄位類型設為 string，導致無法進行數值運算。
  • 時區不明確：時間戳記欄位缺少標準化時區，可能會導致篩選或彙整結果不正確。
 解決資料品質問題：盡可能標記資料管理期間發現的資料品質問題 (值、類型、時區不一致)。與資料工程團隊合作，清理來源資料或在 ETL/資料模型層套用轉換。

LookML 重點

定義要用做對話式數據分析資料來源的「探索」LookML 時，請留意以下重點：

  • 使用清楚明確的標籤：為資料選擇標籤時，請反映貴商家使用者的實際用語。請避免使用 "amt_usd_curr" 等技術簡寫，改用 "Amount (USD)"。
  • 啟用無縫對應：使用同義詞和說明，協助代理將使用者問題對應至正確的欄位。
  • 集中計算：直接將常用計算定義為 LookML 維度或測量指標，確保單一資料來源的準確性，並減少延遲。
  • 簡化脈絡：在 LookML 中隱藏技術或僅供內部使用的欄位 (例如外部鍵或原始 ID)，確保只有回答業務問題所需的欄位會顯示在 Conversational Analytics 中。只專注於相關欄位可減少干擾，並提高欄位選取準確度。
  • 最佳化範例資料和模糊搜尋查詢：在 suggestions 參數中定義硬式編碼值，或使用 suggest_dimension 和 suggest_explore 提升資料庫查詢效率。
  • 最佳化資料查詢：遵循最佳化查詢效能的 Looker 一般最佳做法，例如使用匯總感知和有效率的彙整邏輯。

如要進一步瞭解編寫簡潔有效率 LookML 的最佳做法，請參閱下列說明文件：

設定 Explore 以搭配 Conversational Analytics 使用的最佳做法

為協助對話式數據分析提供最實用的答案，請在定義要用做對話式數據分析資料來源的探索時，考慮採用下列最佳做法：

  • 在探索的基礎 LookML 中，只定義對終端使用者有用的分析欄位。
    • 為每個欄位輸入清楚簡潔的名稱和說明。
    • 視情況加入範例值。範例值對於字串類型欄位特別有幫助。
  • 考慮匯總資料代理程式專屬的探索，重複使用內容。
    • 使用 extends 根據現有 LookML 建構，並策劃 AI 代理所需的欄位。在「系統活動」中，使用者可以查看代理程式產生的查詢所使用的欄位，並決定要排除哪些欄位。
    • 使用欄位層級的 LookML 修訂內容，為代理程式建立專屬說明，例如「使用者提及銷售時，請使用『訂單』欄位」。

建構資料代理程式的最佳做法

運用 LookML 最佳做法和設定完善的探索功能，建立穩固的基礎後，您就能建構資料代理程式，為特定用途或使用者群組提供個人化的對話體驗。資料代理程式最多可連結五個探索，並使用自然語言指令提供背景資訊、定義術語，以及設定行為規範。

建立代理程式和撰寫指令時，請務必遵循最佳做法，根據特定使用者需求調整代理程式的回覆內容，並提升整體準確率。這些最佳做法包括為特定領域設計專用代理程式，以及撰寫清楚有效的指令。

建構專用代理

雖然您可能會想建立一個全域資料代理，處理所有業務問題，但代理專門處理特定領域 (例如銷售、行銷或產品分析) 的問題時，成效最佳。如果代理專注於一或多個密切相關的探索，就能獲得更精確的指示，減少模糊不清的情況，並提高回覆準確度。

設計代理程式時，請避免建立單一代理程式來處理所有不相關的資料模型。請針對不同的業務領域建立專屬代理程式，並只連結密切相關的探索。舉例來說，請建立專門處理「收益代理程式」的代理程式，並只連結 Orders 和 Transactions 探索，而不是建立一個代理程式來處理所有公司資料。

撰寫有效的代理指令

代理程式指令是自訂資料代理程式行為的主要工具，可讓您將機構專屬的商業邏輯和術語融入其中。您可以將指令視為訓練代理程式的方式，教導代理程式如何解讀使用者問題、處理模稜兩可的情況，以及以最能幫助使用者的回覆方式回應。清楚詳盡的操作說明是生成準確、相關且可靠答案的關鍵。

建立資料代理時，請在「指令」欄位中輸入代理指令。如要進一步瞭解如何建立代理程式，請參閱「建立及管理探索資料代理程式」說明文件頁面。

如要撰寫有效的指令，請遵循下列最佳做法：

  • 定義業務脈絡和預設行為：訓練代理瞭解貴機構的獨特邏輯和術語。使用指令定義縮寫 (例如「LY 代表去年」)、說明常見的篩選邏輯，或設定不明確情況下的預設行為 (例如「如果未提供 date_created，請篩選過去 6 個月的資料」)。
  • 使用 LookML 和篩選器語法：在指令中參照欄位或套用篩選器時，請使用 LookML 語法 (例如 events.date_created) 和篩選器語法 (例如 "last 6 months")，確保代理程式瞭解要套用哪些欄位或篩選器。例如：「使用者詢問『區域』時，請使用 account_holder.geo_region 欄位。」
  • 針對複雜範例使用黃金查詢：針對常見問題或涉及複雜商業邏輯的查詢，請提供golden queries自然語言問題及其對應的已驗證 Looker 查詢。黃金查詢可協助代理程式學習特定模式。著重於釐清難懂的術語或常見的篩選條件組合。黃金查詢必須以特定 LookML 查詢表示法提供，而非原始 SQL 或標準「探索」網址。
  • 簡明扼要：清楚撰寫指示，避免使用不必要的字詞或重複內容。
  • 避免重複：請勿重複提供應屬於 LookML 的資訊，例如欄位說明或同義字。如要進一步瞭解何時應在 LookML 中定義脈絡，而非代理程式指令，請參閱「何時應在 LookML 中新增脈絡，而非對話式數據分析」。此外，請避免說明代理程式已瞭解的基本概念，例如維度和指標之間的差異，或是如何執行基本日期篩選。

代理指令的限制

撰寫代理程式指令時，請注意對話式數據分析的下列限制：

  • 對話式數據分析不支援產生含有 pivots 參數的查詢。雖然對話式數據分析可一次傳回多個維度的資料，但無法像 Looker 探索使用者介面一樣，將這些資料轉置到不同資料欄。對話式數據分析會以「長」或「扁平」格式傳回資料，因此資料是水平分組，而非垂直分組。

  • 對話式分析無法重複使用現有 Looker 內容中定義的自訂欄位 (例如，使用包含自訂欄位的「探索」產生的 LookML 建立精確查詢)，也無法在新查詢中產生全新的自訂欄位。而是使用現有的 LookML 欄位，或使用 Python 對資料結果建立自訂計算。

  • 與受控的 LookML 不同，指令通常是任意形式的文字，而且隨著基礎資料模型演進，指令可能會「過時」

代理程式指令範例

以下是資料代理程式的範例指令，該代理程式已連結至名為「Order Items」和「Products」的 Looker 探索：

# Define a persona and provide instructions on how to propose suggestions
You are a helpful data assistant. After answering the user's question, please provide 2-3 relevant follow-up questions they might be interested in exploring based on the data.
Anticipate the user's needs. Suggest potential next questions or related analyses after each response.
Always offer suggestions for deeper dives into the data.
Your tone should be professional and concise.

# Business Terms
# Define how business terms map to LookML fields or data values that can't be captured in LookML synonyms or descriptions.
Terms:
  EOP: End of Period. This is the last day of the period.
  LY: Last Year.
  Month-over-month: This is a measure of `type: period_over_period` with `period: month`.

# Default Behaviors
# Define how to handle ambiguous or underspecified queries.
When users mention Orders, you must apply a filter of `Status` like `COMPLETED`. Consider this a **hard-coded requirement**. Do not attempt to verify this filter by querying sample values; proceed directly to the calculation using this exact string.
Defaults:
  Date Filter: If no `created_date` is specified by the user, filter order_items.created_date to "last 12 months".
  Product Grouping: If "group by product" is requested without specifying name or category, use `products.category`.

# Golden Queries
# Provide examples of question/query pairs for common or complex questions.
Golden Queries:
  - Question: "How much revenue did we generate from successful orders in 2024?"
    Looker query:
      model: thelook_ecommerce
      explore: order_items
      fields: [order_items.total_sales]
      filters: [{field: order_items.status, value: "Complete"}, {field: order_items.created_year, value: "2024"}]

# Related Fields
# Provide instructions for what other related fields the agent should fetch information from
Include parent dimensions like Category when asking for "item level" data.

何時應在 LookML 中新增背景資訊，而非對話式數據分析

在對話式 Analytics 中，您可以將脈絡資訊新增至 LookML 或代理程式指令。決定要新增脈絡資訊的位置時，請套用下列指引：

  • 應套用至探索所有使用者的內容，都應直接新增至 LookML 模型，因為 Looker 探索可能會在多個位置使用，包括資訊主頁和對話式數據分析。如果內容只應套用至特定使用者，請考慮使用 LookML 功能 (例如使用者屬性) 建立自訂體驗。
  • 優先處理欄位專屬中繼資料和硬性規定的 LookML。將同義詞和說明等欄位專屬中繼資料直接放在 LookML 中，而不是代理程式指令。預設篩選器值或隱藏欄位等項目的需求，最好在 LookML 中處理，確保系統會遵守這些需求。
  • 請勿重複提供代理程式已知的資訊，例如如何建立 Looker 查詢、維度或測量指標的說明、可存取的探索，或是如何進行基本日期篩選。同樣地，請勿在 LookML 和代理程式指令中定義相同字詞。

代理程式環境應著重於使用者，並以質性為主，且一個「探索」可有多個代理程式為不同使用者提供服務。LookML 適合定義欄位「是什麼」，但通常無法定義商業策略或預測計算。以下列舉應納入代理程式指令，但不應納入 LookML 的情境：

  • 與代理程式互動的使用者是誰？他們的角色為何？是公司內部還是外部人員？他們先前的 Analytics 經驗為何？
  • 使用者的目標是什麼？他們希望在對話結束時做出哪種決定？
  • 使用者會提出哪些類型的問題？
  • 哪些領域與這位使用者最相關？舉例來說，這個使用者應可存取哪些欄位？是否應一律套用特定篩選器？是否應優先顯示某些欄位？