שיטות מומלצות להגדרת ניתוח נתונים בשיחה ב-Looker

ניתוח נתונים שיחה משתמש ב-Gemini for Google Cloud כדי לפרש שאלות בשפה טבעית, תוך שימוש במודל הסמנטי (LookML) של Looker, בערכי הנתונים ובהגדרות של סוכן הנתונים כמקור האמת שלו. איכות התשובות תלויה ביעילות ההכנה של הקלט.

המדריך הזה מציע אסטרטגיות ושיטות מומלצות למפתחים ולאדמינים של LookML להגדרה ולאופטימיזציה של ניתוח נתונים שיחותי. ההמלצות האלה יעזרו לכם להגדיל את מספר המשתמשים במודל LookML, ב-Explores ובסוכני הנתונים, ולוודא שהמשתמשים יקבלו תשובות מדויקות, רלוונטיות ומועילות לשאלות שלהם. המדריך הזה כולל שיטות מומלצות שקשורות לניתוח שיחות. הוא בנוי לפי רצף הגיוני שמתחיל בפיתוח בסיס חזק ב-LookML של מודל, ממשיך בהגדרת ניתוחים שמבוססים על המודל הזה ומסתיים ביצירת סוכני נתונים שמשתמשים בניתוחים האלה כמקורות נתונים.

שיטות מומלצות לשימוש ב-LookML בניתוח נתוני השיחות

הניתוח השיחתי מפרש שאלות בשפה טבעית על סמך הקלטים העיקריים הבאים:

  • מודל LookML: הסוכן מאחזר את הסכימה של ה-Explores שמקושרים אליו. הסכימה כוללת שדות (מאפיינים, מדדים), שדות סינון בלבד (מסננים, פרמטרים) ותוויות, תיאורים ומילים נרדפות תואמים שמוגדרים במודל LookML שעליו מבוסס הכלי Explore של Looker. רשימה מלאה של פרמטרים של LookML שמערכת Conversational Analytics מנתחת זמינה במאמר סקירה כללית של Conversational Analytics.
  • ערכי שדות ייחודיים: הסוכן יכול לדגום ערכי נתונים ולבצע חיפושים משוערים כדי לבדוק אם יש ערכים ספציפיים בשדה במסד הנתונים הבסיסי. השיטות האלה מאפשרות לסוכן לבחור את השדות הנכונים, להחיל את ערכי הסינון הנכונים ולזהות את הקטגוריות והישויות הזמינות שמשתמשים עשויים לשאול עליהן.

רמת האפקטיביות של ניתוח שיחות קשורה ישירות לאיכות ולבהירות של נתוני הקלט האלה. בטבלה הבאה מפורטות דרכים נפוצות שבהן LookML לא ברור או דו-משמעי יכול להשפיע לרעה על ניתוח נתונים שיחתי, וגם פתרונות לצמצום זמן האחזור ולשיפור הפלט וחוויית המשתמש.

בעיה באיכות של LookML פתרון לניתוח נתונים בשיחה בצורה ברורה יותר
חוסר בהירות וסכסוכי שמות: שדות שחסרות להם תוויות ברורות, שההגדרות שלהם לא חד-משמעיות או שיש להם שמות דומים בתצוגות שונות עלולים להוביל לבחירה שגויה של שדות. הוספת תוויות ברורות ותיאורים מפורטים:
  • משתמשים בפרמטר label כדי לתת לשדות שמות אינטואיטיביים שמתאימים לעסק.
  • משתמשים בפרמטר description כדי לספק הקשר חשוב, הגדרות בשפה טבעית וטרמינולוגיה ספציפית לתחום. התכונה 'ניתוח נתונים שיחתי' משתמשת בתיאורים כדי לזהות טוב יותר את המשמעויות של השדות ולמפות את המונחים של המשתמשים.
ניפוח של שדות: חשיפה של יותר מדי שדות, כמו מזהים פנימיים, שדות כפולים מחיבורים או חישובים ביניים, יוצרת עומס באפשרויות שזמינות ב-Conversational Analytics. הסתרת שדות לא רלוונטיים: חשוב לוודא שכל המפתחות הראשיים, המפתחות החיצוניים והשדות הטכניים מוסתרים.

(אופציונלי) הרחבת ניתוחים: אם יש לכם ניתוחים עם הרבה שדות, כדאי ליצור גרסה ייעודית לניתוח נתוני שיחות על ידי הרחבת ניתוח קיים.
טעינת מסד הנתונים לדגימה ולחיפוש: אחזור ערכי דגימה והצעות ממסד הנתונים עלול להיות איטי או לגרום לטעינה מיותרת, במיוחד כשמשתמשים מתייחסים לערכי נתונים ספציפיים בשאילתות. הגדרת הצעות ב-LookML: כדי להימנע משאילתות בזמן אמת במסד הנתונים להצעות לשדות, אפשר להגדיר ערכים קשיחים או להפנות למאפיינים יעילים יותר:
  • משתמשים בפרמטר suggestions כדי להגדיר רשימה של ערכים אפשריים.
  • משתמשים בפרמטרים suggest_explore ו-suggest_dimension כדי לשלוח שאילתה למאפיין חלופי ויעיל יותר להצעות למסננים.
עומס על מסד הנתונים בשאילתות נתונים: שאילתות גדולות או לא יעילות יכולות להגדיל את זמן האחזור ואת העומס על מסד הנתונים. אופטימיזציה של שאילתות נתונים: כדאי לפעול לפי השיטות המומלצות הכלליות לשיפור הביצועים של שאילתות, כמו שימוש במודעות מצטברת ובלוגיקה יעילה של איחוד (join).
הגדרות LookML לא מלאות: אם אתם מסתמכים על שדות בהתאמה אישית או על חישובים של טבלאות ברמת לוח הבקרה, ל-Conversational Analytics לא תהיה גישה ללוגיקה עסקית קריטית. שילוב לוגיקה מותאמת אישית: המרת שדות מותאמים אישית או חישובים בטבלה שחשובים ושימושיים למאפיינים ולמדדים של LookML.
נתונים מבולגנים: סוגי הנתונים הבאים לא עקביים או לא מובנים בצורה טובה, ולכן קשה לנתח את השאילתות בצורה מדויקת באמצעות ניתוח שיחות.
  • וריאציות של ערכים: שימוש לא עקבי באותיות רישיות או במוסכמות שמות (לדוגמה, שילוב של הערכים complete, Complete ו-COMPLETE) עלול להוביל לשכפול נתונים או ליצירת קשרים שגויים בין נתונים ב-Conversational Analytics.
  • סוגי נתונים לא עקביים: אם עמודות שאמורות להיות מספריות מכילות ערכי מחרוזת מדי פעם, סוג השדה יהיה string, ולא ניתן יהיה לבצע פעולות מספריות.
  • אי בהירות לגבי אזור הזמן: היעדר אזורי זמן סטנדרטיים בשדות של חותמות זמן עלול להוביל לסינון או לצבירה שגויים.
 איכות נתוני הכתובות: אם אפשר, כדאי לסמן בעיות באיכות הנתונים (ערכים, סוגים ואזורי זמן לא עקביים) שזיהיתם במהלך אוסף הנתונים. עובדים עם צוותי הנדסת נתונים כדי לנקות את נתוני המקור או להחיל טרנספורמציות בשכבת ה-ETL או בשכבת המודלים של הנתונים.

מסקנות חשובות לגבי LookML

חשוב לזכור את הנקודות העיקריות האלה כשמגדירים LookML לניתוחים שייעשה בהם שימוש כמקורות נתונים לניתוח שיחות:

  • שימוש בתוויות ברורות ומדויקות: בחרו תוויות לנתונים שמשקפות את השפה שבה משתמשים העסקיים שלכם מדברים בפועל. עדיף להימנע מקיצורים טכניים כמו "amt_usd_curr" ולהשתמש ב-"Amount (USD)".
  • הפעלת מיפוי חלק: אפשר להשתמש במילים נרדפות ובתיאורים כדי לעזור לסוכן למפות את שאלות המשתמשים לשדות הנכונים.
  • ריכוז החישובים: כדי להבטיח מקור יחיד של אמת ולצמצם את זמן האחזור, כדאי להגדיר חישובים שנעשה בהם שימוש לעיתים קרובות ישירות כמאפיינים או כמדדים של LookML.
  • מייעלים את ההקשר: מסתירים שדות טכניים או שדות לשימוש פנימי בלבד ב-LookML (כמו מפתחות זרים או מזהים גולמיים) כדי להבטיח שרק שדות שנדרשים למענה על שאלות עסקיות יוצגו ב-Conversational Analytics. התמקדות רק בשדות רלוונטיים מפחיתה את הרעש ומשפרת את הדיוק של בחירת השדות.
  • אופטימיזציה של נתוני מדגם ושאילתות חיפוש משוער: אפשר להגדיר ערכים שמוצפנים בקידוד קשיח בפרמטר suggestions, או להשתמש בפרמטרים suggest_dimension ו-suggest_explore כדי לבצע שאילתות במסד הנתונים בצורה יעילה יותר.
  • אופטימיזציה של שאילתות נתונים: כדאי לפעול לפי השיטות המומלצות הכלליות של Looker לאופטימיזציה של ביצועי שאילתות, כמו שימוש במודעות מצטברות ובלוגיקה יעילה של איחוד (join).

שיטות מומלצות נוספות לכתיבת קוד LookML נקי ויעיל זמינות במאמרים הבאים:

שיטות מומלצות להגדרת ניתוח נתונים ב-Explore לשימוש בניתוח נתוני שיחות

כדי לקבל את התשובות הכי מועילות מניתוח נתונים שימושי, מומלץ לפעול לפי השיטות המומלצות הבאות כשמגדירים את הניתוחים לשימוש כמקור נתונים לניתוח נתונים שימושי:

  • ב-LookML הבסיסי של הניתוח, מגדירים רק את השדות ששימושיים לניתוח על ידי משתמשי הקצה.
    • נותנים לכל שדה שם ותיאור ברורים ותמציתיים.
    • במקומות הרלוונטיים, כדאי לכלול ערכים לדוגמה. ערכים לדוגמה שימושיים במיוחד בשדות מסוג מחרוזת.
  • מומלץ ליצור ניתוחים ספציפיים לסוכני נתונים שמשתמשים מחדש בתוכן.
    • אפשר להשתמש ב-extends כדי להסתמך על LookML קיים ולבחור את השדות שהסוכן צריך. ב'פעילות המערכת', המשתמשים יכולים לראות באילו שדות נעשה שימוש בשאילתות שנוצרו על ידי סוכנים, ולהחליט אילו שדות להחריג.
    • אפשר להשתמש בשיפורים ב-LookML ברמת השדה כדי ליצור תיאורים שמותאמים לסוכנים – "השתמש בשדה Orders כשמשתמשים מתייחסים למכירות".

שיטות מומלצות ליצירת סוכני נתונים

אחרי שתבססו את היסודות בעזרת שיטות מומלצות לשימוש ב-LookML וניתוחים מוגדרים היטב, תוכלו ליצור סוכני נתונים כדי לספק חוויות שיחה מותאמות אישית לתרחישי שימוש ספציפיים או לקבוצות משתמשים ספציפיות. סוכני נתונים מתחברים לחמישה אובייקטים של Explore לכל היותר, ומשתמשים בהוראות בשפה טבעית כדי לספק הקשר, להגדיר טרמינולוגיה ולקבוע הנחיות התנהגותיות.

חשוב לפעול לפי שיטות מומלצות כשיוצרים סוכנים וכותבים הוראות, כדי להתאים את התשובות של הסוכן לצרכים ספציפיים של המשתמשים ולשפר את הדיוק הכולל. השיטות המומלצות האלה כוללות עיצוב סוכנים ייעודיים לתחומים ספציפיים וכתיבת הוראות ברורות ויעילות.

יצירת נציגים מומחים

למרות שזה יכול להיות מפתה ליצור סוכן נתונים גלובלי אחד שיטפל בכל השאלות העסקיות, הסוכנים פועלים בצורה הכי טובה כשהם מתמחים בתחום ספציפי, כמו מכירות, שיווק או ניתוח מוצרים. אם הסוכן מתמקד בחיפוש אחד או בכמה חיפושים שקשורים זה לזה, אפשר לתת לו הוראות מדויקות יותר, וכך לצמצם את אי הבהירות ולשפר את דיוק התשובות.

כשמעצבים סוכנים, כדאי להימנע מבניית סוכן יחיד לטיפול בכל מודלי הנתונים הלא קשורים. במקום זאת, כדאי ליצור סוכנים ממוקדים לתחומי עסקים שונים, ולקשר אותם רק לחיפושים שקשורים אליהם באופן הדוק. לדוגמה, במקום סוכן אחד לכל נתוני החברה, אפשר ליצור סוכן הכנסות שמתמקד באופן ספציפי בOrders ובTransactions.

כתיבת הוראות אפקטיביות לסוכן

ההוראות לסוכן הן הכלי העיקרי להתאמה אישית של התנהגות סוכן הנתונים, ולהחדרת הלוגיקה העסקית והטרמינולוגיה הייחודיות של הארגון. ההוראות הן דרך לאמן את הסוכן איך לפרש את השאלות של המשתמשים, איך להתמודד עם דו-משמעות ואיך להגיב בצורה הכי מועילה למשתמשים. הוראות כתובות היטב הן המפתח ליצירת תשובות מדויקות, רלוונטיות ואמינות.

כשיוצרים סוכן נתונים, מזינים את ההוראות לסוכן בשדה הוראות. מידע נוסף על יצירת סוכנים זמין במאמר יצירה וניהול של סוכני נתונים ב-Explore.

כדי לכתוב הוראות יעילות, כדאי לפעול לפי השיטות המומלצות הבאות:

  • הגדרת הקשר העסקי והתנהגות ברירת המחדל: צריך להסביר לסוכן את הלוגיקה והטרמינולוגיה הייחודיות של הארגון. אפשר להשתמש בהוראות כדי להגדיר ראשי תיבות (לדוגמה, 'LY פירושו בשנה שעברה'), להסביר לוגיקת סינון נפוצה או להגדיר התנהגויות ברירת מחדל למקרים של עמימות (לדוגמה, 'אם לא צוין date_created, הסינון יתבצע לפי 6 החודשים האחרונים').
  • שימוש ב-LookML ובסינטקס של מסננים: כשמתייחסים לשדות או מחילים מסננים בהוראות, צריך להשתמש בסינטקס של LookML (לדוגמה, events.date_created) ובסינטקס של מסננים (לדוגמה, "last 6 months"). כך מבטיחים שהסוכן יבין אילו שדות או מסננים להחיל. לדוגמה: "כשמשתמש שואל על 'אזור', צריך להשתמש בשדה account_holder.geo_region".
  • שימוש בדוגמאות לשאילתות מומלצות עבור דוגמאות מורכבות: לשאלות או לשאילתות נפוצות שכוללות לוגיקה עסקית מורכבת, כדאי לספק golden queries – צמדים של שאלות בשפה טבעית והשאילתות התואמות להן ב-Looker שעברו אימות. שאילתות לדוגמה יכולות לעזור לסוכן ללמוד דפוסים ספציפיים. כדאי להתמקד בשאילתות שמבהירות טרמינולוגיה מסובכת או שילובים נפוצים של מסננים. צריך לספק את השאילתות המוזהבות בייצוג ספציפי של שאילתת LookML, ולא ב-SQL גולמי או בכתובות URL רגילות של Explore.
  • היו תמציתיים: כתבו בצורה ברורה והימנעו ממילים מיותרות או מחזרות על עצמן בהוראות.
  • הימנעות מכפילות: אל תכפילו מידע ששייך ל-LookML, כמו תיאורי שדות או מילים נרדפות. מידע נוסף על מקרים שבהם כדאי להגדיר הקשר ב-LookML לעומת הוראות לסוכן זמין במאמר מתי כדאי להוסיף הקשר ל-LookML לעומת ניתוח נתונים בשיחה. בנוסף, אל תסבירו מושגים בסיסיים שהסוכן כבר מבין, כמו ההבדל בין מאפיין למדד או איך לבצע סינון בסיסי של תאריכים.

המגבלות של הוראות לסוכן

כשכותבים את ההוראות לסוכן, חשוב לשים לב למגבלות הבאות של ניתוח שיחות:

  • התכונה 'ניתוח נתונים שיחתי' לא תומכת ביצירת שאילתות שמכילות את הפרמטר pivots. אמנם ניתוח שיחות יכול להחזיר נתונים של כמה מאפיינים בבת אחת, אבל הוא לא יכול להפוך אותם לעמודות נפרדות כמו בממשק המשתמש של Looker Explore. במקום זאת, היא מחזירה את הנתונים בפורמט 'ארוך' או 'שטוח', כך שהנתונים מקובצים אופקית ולא אנכית.

  • אי אפשר להשתמש מחדש בשדות מותאמים אישית שמוגדרים בתוכן קיים של Looker (לדוגמה, כשמשתמשים ב-LookML שנוצר מניתוח שמכיל שדה מותאם אישית כדי ליצור שאילתה מושלמת) או ליצור שדות מותאמים אישית חדשים לגמרי בתוך שאילתה חדשה. במקום זאת, המערכת משתמשת בשדות LookML קיימים או ב-Python כדי ליצור חישובים בהתאמה אישית על תוצאות הנתונים.

  • בניגוד ל-LookML, שמוגדר מראש, ההוראות הן לרוב טקסט חופשי, והן יכולות להיות לא רלוונטיות אם מודל הנתונים הבסיסי משתנה עם הזמן.

דוגמה להוראות לסוכן

הנה כמה הוראות לדוגמה לסוכן נתונים שמחובר ל-Looker Explores שנקראים Order Items ו-Products:

# 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 ומתי לניתוח נתונים בשיחה

בניתוח שיחות, אפשר להוסיף הקשר ל-LookML או בתוך הוראות לסוכן. כשמחליטים איפה להוסיף הקשר, כדאי לפעול לפי ההנחיות הבאות:

  • אם יש הקשר שצריך לחול על כל המשתמשים ב'ניתוח נתונים', צריך להוסיף אותו ישירות למודל LookML, כי יכול להיות שמשתמשים ב'ניתוח נתונים' של Looker בכמה מקומות, כולל במרכזי בקרה ובניתוח נתונים שיחתי. אם ההקשר צריך לחול רק על משתמשים מסוימים, כדאי להשתמש בתכונות של LookML כמו מאפייני משתמשים כדי ליצור חוויות מותאמות אישית.
  • כדאי לתת עדיפות ל-LookML כשמדובר במטא-נתונים ספציפיים לשדות ובדרישות מחמירות. מזינים מטא-נתונים ספציפיים לשדה, כולל מילים נרדפות ותיאורים, ישירות ב-LookML ולא בהוראות לסוכן. מומלץ לטפל בדרישות כמו ערכי ברירת מחדל של מסננים או שדות מוסתרים ב-LookML, כדי לוודא שהן יכובדו.
  • אל תחזרו על מידע שהסוכן כבר יודע, כמו איך ליצור שאילתה ב-Looker, הסבר על מאפיינים או מדדים, ניתוחים נגישים או איך לבצע סינון בסיסי של תאריכים. באופן דומה, אל תגדירו את אותו מונח גם ב-LookML וגם בהוראות לסוכן.

ההקשר של הנציג צריך להיות איכותי וממוקד במשתמש, ויכולים להיות הרבה נציגים שמשרתים משתמשים שונים מתוך Explore אחד. ‫LookML מתאים להגדרת מה השדה, אבל בדרך כלל אי אפשר להגדיר איתו אסטרטגיה עסקית או חישובים של ניתוחים חזויים. הנה כמה דוגמאות להקשר שצריך לכלול בהוראות לסוכן, אבל לא ב-LookML:

  • מי המשתמש שמקיים אינטראקציה עם הנציג? מה התפקיד שלהם? האם הם עובדים בחברה או מחוצה לה? מה הניסיון הקודם שלהם עם Analytics?
  • מה המטרה של המשתמש? איזו החלטה הם רוצים לקבל בסוף השיחה?
  • אילו סוגי שאלות המשתמש הזה ישאל?
  • אילו שדות הכי רלוונטיים למשתמש הזה? לדוגמה, אילו שדות צריכים להיות נגישים למשתמש הזה, האם צריך להחיל תמיד מסננים מסוימים, או האם צריך לתת עדיפות לשדות מסוימים עבור המשתמש הזה?