對話式數據分析會使用 Gemini for Google Cloud 解讀自然語言問題，並以 Looker 語意模型 (LookML)、資料值和資料代理設定做為資料來源。回覆品質取決於您準備這些輸入內容的成效。
本指南提供策略和最佳做法，協助 LookML 開發人員和管理員設定及最佳化對話式數據分析。只要遵循這些 LookML 模型、探索和資料代理程式的建議，就能提高使用者採用率，並確保使用者獲得準確、相關且實用的問題解答。本指南將依循邏輯流程，說明與對話式分析相關的最佳做法，首先是開發模型 LookML 的穩固基礎，接著設定以這個模型為基礎的探索，然後建構以這些探索做為資料來源的資料代理程式。
對話式數據分析的 LookML 最佳做法
對話式數據分析會運用下列主要輸入內容解讀自然語言問題：
- LookML 模型：代理程式會擷取與其連結的「探索」結構定義。結構定義包含欄位 (維度、指標)、篩選器限定欄位 (篩選器、參數)，以及 Looker 探索基礎 LookML 模型中定義的對應標籤、說明和同義字。如要查看對話式數據分析分析的完整 LookML 參數清單，請參閱對話式數據分析總覽。
- 不重複的欄位值：代理程式可以對資料值進行取樣，並執行模糊搜尋，檢查基礎資料庫中的特定欄位值。這些方法可讓服務專員選擇正確的欄位、套用正確的篩選值，並找出使用者可能會詢問的可用類別和實體。
對話式數據分析的成效直接取決於這些輸入內容的品質和清晰度。下表列出 LookML 不清楚或模稜兩可時，對對話式數據分析造成的常見負面影響，以及減少延遲時間、改善輸出內容和使用者體驗的解決方案。
| LookML 品質問題 | 解決方案：更清楚的對話式數據分析 |
|---|---|
| 不夠清楚和命名衝突：如果欄位缺少明確的標籤、定義模糊不清，或在不同檢視畫面中名稱相似，可能會導致選取錯誤的欄位。 | 套用清楚的標籤並提供詳盡說明： |
| 欄位過多：公開過多欄位 (例如內部 ID、來自聯結的重複欄位或中繼計算) 會導致對話式數據分析可用的選項過於雜亂。 | 隱藏不相關的欄位：請確保所有主鍵、外鍵和技術欄位都隱藏。 (選用) 擴充探索：如果探索包含許多欄位，建議擴充現有探索，為對話式數據分析建立專屬版本。 |
| 取樣和搜尋的資料庫負載：從資料庫擷取樣本值和建議可能很慢，或會產生不必要的負載，尤其是使用者在查詢中參照特定資料值時。 | 在 LookML 中定義建議：避免即時資料庫查詢欄位建議，方法是硬式編碼值或指向更有效率的維度：
|
| 資料查詢的資料庫負載：大型或效率不彰的查詢可能會增加延遲和資料庫負載。 | 最佳化資料查詢：遵循查詢效能最佳化的一般最佳做法，例如使用匯總感知和有效率的聯結邏輯。 |
| LookML 定義不完整：如果依賴資訊主頁層級的自訂欄位或資料表計算，對話式數據分析就無法存取重要的商業邏輯。 | 納入自訂邏輯：將重要且常用的自訂欄位或資料表計算轉換為 LookML 維度和測量指標。 |
資料雜亂：下列類型的不一致或結構不良資料，會導致對話式分析難以準確解讀查詢。
|
解決地址資料品質問題：盡可能標記資料管理期間發現的資料品質問題 (值、類型、時區不一致)。與資料工程團隊合作清理來源資料，或在 ETL/資料建模層套用轉換。 |
LookML 重點摘要
定義要用做對話式數據分析資料來源的「探索」LookML 時，請留意以下重點：
- 使用清楚明確的標籤：為資料選擇標籤時，請反映貴商家使用者的實際用語。請避免使用
"amt_usd_curr"等技術簡寫，改用"Amount (USD)"。 - 啟用無縫對應：使用同義詞和說明，協助代理將使用者問題對應至正確的欄位。
- 集中計算：直接將常用計算定義為 LookML 維度或測量指標，確保單一資料來源的準確性，並減少延遲。
- 簡化背景資訊：在 LookML 中隱藏技術或僅供內部使用的欄位 (例如外部鍵或原始 ID)，確保對話式數據分析只會顯示回答業務問題所需的欄位。只專注於相關欄位可減少干擾，並提高欄位選取準確度。
- 最佳化範例資料和模糊搜尋查詢：在
suggestions參數中定義硬式編碼值，或使用suggest_dimension和suggest_explore提升資料庫查詢效率。 - 最佳化資料查詢：遵循最佳化查詢效能的 Looker 一般最佳做法，例如使用匯總感知和有效率的彙整邏輯。
如要進一步瞭解編寫簡潔有效率 LookML 的最佳做法，請參閱下列說明文件：
設定 Explore 以搭配對話式數據分析使用的最佳做法
為協助對話式數據分析提供最實用的答案，請在定義要用做對話式數據分析資料來源的探索時，考慮採用下列最佳做法：
- 在探索的基礎 LookML 中，只定義對終端使用者有用的分析欄位。
- 為每個欄位輸入清楚簡潔的名稱和說明。
- 視情況加入範例值。範例值對於字串類型欄位特別有幫助。
- 建議您策劃資料代理程式專用的探索，重複使用內容。
- 使用
extends根據現有 LookML 建立內容，並策劃 AI 代理所需的欄位。在「系統活動」中，使用者可以查看代理程式產生的查詢所使用的欄位，並決定要排除哪些欄位。 - 使用欄位層級的 LookML 修訂內容，為代理程式建立專屬說明，例如「使用者提及銷售時，請使用『訂單』欄位」。
- 使用
建構資料代理程式的最佳做法
運用 LookML 最佳做法和設定完善的探索功能，建立穩固的基礎後，您就能建構資料代理程式，為特定用途或使用者群組提供自訂對話體驗。資料代理程式最多可連結至五個探索，並使用自然語言指令提供背景資訊、定義術語及設定行為規範。
建構代理程式和撰寫指令時，請務必遵循最佳做法，根據特定使用者需求調整代理程式的回覆內容，並提升整體準確度。這些最佳做法包括為特定領域設計專用代理程式，以及撰寫清楚有效的指令。
建構專用代理
您可能會想建立一個全域資料代理，處理所有業務問題，但代理專門處理特定領域 (例如銷售、行銷或產品分析) 時，成效最佳。如果代理程式專注於一或多個密切相關的探索，就能獲得更精確的指令，減少模糊不清的情況，並提高回覆準確度。
設計代理程式時，請避免建構單一代理程式來處理所有不相關的資料模型。請改為針對不同業務領域建立專屬代理，並只連結密切相關的探索。舉例來說，您可以建立專門處理Orders和Transactions探索的「收益代理」，而不是讓一個代理處理所有公司資料。
撰寫有效的代理指令
代理程式指令是自訂資料代理程式行為的主要工具，可讓您將機構專屬的商業邏輯和術語融入其中。您可以將指令視為訓練代理程式的方式，讓代理程式瞭解如何解讀使用者問題、處理模稜兩可的內容，以及提供最實用的回覆。清楚詳盡的操作說明是生成準確、相關且可靠答案的關鍵。
建立資料代理時，請在「指令」欄位中輸入代理指令。如要進一步瞭解如何建立代理程式，請參閱「建立及管理探索資料代理程式」說明文件頁面。
如要撰寫有效的指令，請遵循下列最佳做法：
- 定義業務脈絡和預設行為：訓練代理瞭解貴機構的獨特邏輯和術語。使用指令定義縮寫 (例如「LY 代表去年」)、說明常見的篩選邏輯，或設定不明確情況下的預設行為 (例如「如果未提供
date_created，請篩選過去 6 個月的資料」)。 - 使用 LookML 和篩選器語法：在指令中參照欄位或套用篩選器時，請使用 LookML 語法 (例如
events.date_created) 和篩選器語法 (例如"last 6 months")。這樣一來，代理程式就能瞭解要套用哪些欄位或篩選器。例如：「當使用者詢問『地區』時，請使用account_holder.geo_region欄位。」 - 簡明扼要：清楚撰寫指示，避免使用不必要的字詞或重複內容。
- 避免重複：請勿重複提供應屬於 LookML 的資訊，例如欄位說明或同義字。如要進一步瞭解何時應在 LookML 中定義脈絡，而非代理程式指令，請參閱「何時應在 LookML 中新增脈絡，而非對話式數據分析」。此外，也請避免說明代理程式已瞭解的基本概念，例如維度和指標之間的差異，或是如何執行基本日期篩選。
代理指令的限制
撰寫代理程式指令時，請注意對話式數據分析的下列限制：
- 對話式數據分析不支援產生含有
pivots參數的查詢。雖然 Conversational Analytics 可以一次傳回多個維度的資料，但無法像 Looker 探索使用者介面一樣，將這些資料透視到不同的資料欄。而是以「長」或「扁平」格式傳回資料，因此資料是水平分組，而非垂直分組。 - 與受控的 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`.
# 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 中新增背景資訊，而非對話式數據分析
在 Conversational Analytics 中，您可以在 LookML 或代理程式指令中新增脈絡資訊。決定要在何處新增背景資訊時，請遵循下列指引：
- 應套用至探索所有使用者的內容，都應直接新增至 LookML 模型，因為 Looker 探索可能會在多個位置使用，包括資訊主頁和對話式數據分析。如果內容只應套用至特定使用者，請考慮使用 使用者屬性等 LookML 功能，打造個人化體驗。
- 優先處理欄位專屬中繼資料和硬性規定的 LookML。將同義詞和說明等欄位專屬中繼資料直接放在 LookML 中，而非代理程式指令。預設篩選器值或隱藏欄位等項目的需求，最好在 LookML 中處理，確保系統會遵守這些需求。
- 請勿重複提供代理程式已知的資訊，例如如何建立 Looker 查詢、維度或指標的說明、可存取的探索，或是如何進行基本日期篩選。同樣地，請勿在 LookML 和代理程式指令中定義相同字詞。
代理程式環境應為質性，並以使用者為中心，且可有多個代理程式從一個「探索」服務不同的使用者。LookML 適合定義欄位「是什麼」，但通常無法定義業務策略或預測計算。以下列舉應納入代理程式指令，但不應納入 LookML 的情境：
- 與代理互動的使用者是誰？What is their role? 是公司內部還是外部人員？他們先前的分析經驗為何？
- 使用者的目標是什麼？他們希望在對話結束時做出哪種決定？
- 使用者會提出哪些類型的問題？
- 哪些領域與這位使用者最相關？舉例來說，這個使用者應可存取哪些欄位？是否應一律套用特定篩選器？是否應優先顯示某些欄位？