מגבלות ידועות ב-Conversational Analytics API

ל-Conversational Analytics API יש מגבלות ידועות על מספר מקורות הנתונים, סגנון ההמחשות וגודל מערכי הנתונים.

מגבלות על מקורות נתונים

בקטע הזה מתוארים האילוצים וההתנהגויות של Conversational Analytics API כשמתחברים למקורות של Looker ומסדי נתונים ושולחים אליהם שאילתות – AlloyDB ל-PostgreSQL,‏ Cloud SQL ל-MySQL,‏ Cloud SQL ל-PostgreSQL ו-Spanner.

מגבלות של מקורות נתונים ב-Looker

כשמתחברים למקור נתונים של Looker, חשוב לשים לב לנקודות הבאות:

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

  • סוכן יכול לשלוח שאילתות לכמה ניתוחים בשיחה שכוללת שאלות עם כמה חלקים, או בשיחות שכוללות שאלות המשך.

    לדוגמה: משתמש מחבר שני דוחות Explore, אחד בשם cat-explore ואחד בשם dog-explore. המשתמש מזין את השאלה 'מה גדול יותר: מספר החתולים או מספר הכלבים?' כך יישאלו שתי שאילתות: אחת לספירת מספר החתולים ב-cat-explore ואחת לספירת מספר הכלבים ב-dog-explore. הנציג משווה את המספר משתי השאילתות אחרי השלמתן.

  • השיטה QueryData לא תומכת במקורות נתונים של BigQuery או Looker.

מגבלות של מקורות נתונים של מסדי נתונים

כשמתחברים למקורות נתונים של AlloyDB,‏ Cloud SQL ל-MySQL,‏ Cloud SQL ל-PostgreSQL או Spanner, כדאי לשים לב לנקודות הבאות:

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

  • הטבלה שנבחרה לסוכן הנתונים מכוונת את הסוכן לגבי הטבלאות שבהן כדאי להתמקד. בחירת טבלה היא לא הגדרת אבטחה. גם אם מציינים שמקור הנתונים יכול לשלוף מידע רק מטבלאות מסוימות – כמו table1 ו-table2 – המערכת עדיין עשויה להחזיר נתונים מטבלה לא רצויה (table3) אם למשתמש שמריץ את השאילתה יש הרשאות כלליות לצפייה בתוכן של table3 באותו מסד נתונים.

מגבלות של ויזואליזציות

אלה סוגי ההדמיות שנתמכים:

  • אזור
  • עמודה
  • Geoshape
  • מפת חום
  • קו (פעולות על ציר הזמן)
  • עוגה
  • פיזור

מגבלות על עיבוד נתונים

  • במקורות נתונים של Looker, ממשק Conversational Analytics API יכול להחזיר עד 5,000 שורות לכל שאילתה.
  • במקורות נתונים של BigQuery, מגבלת השאילתות של Conversational Analytics API היא 500GB של נתונים מעובדים.
  • במקורות נתונים של AlloyDB,‏ Cloud SQL ל-MySQL,‏ Cloud SQL ל-PostgreSQL ו-Spanner,‏ Conversational Analytics API יכול להחזיר עד 1,000 שורות לכל שאילתה.
  • יכולות ההסקה ואחזור התוכן של Conversational Analytics API, שמבוססות על Python, יכולות להתמודד עם מורכבויות זמן של עד O(100k) שורות.
  • שאילתות על כמויות גדולות של נתונים עלולות לגרום לירידה ברמת הדיוק של החשיבה הרציונלית אצל סוכני נתונים.
  • האורך המקסימלי של פלט הטוקנים ב-Conversational Analytics API הוא 8,192 טוקנים. הפעלת שאילתות על כמויות גדולות של נתונים עלולה להחזיר שגיאה MAX_TOKENS.
  • הנתונים שמוחזרים בשדה DataResult של הודעת מערכת כפופים למגבלת גודל. התוצאות של הנתונים מקוצרות למקסימום של 3,000,000 בייט. במהלך התהליך הזה, המערכת משאירה כמה שיותר שורות מלאות במסגרת מגבלת הגודל הזו.

מגבלות על שאילתות

  • התכונה של BigQuery שמאפשרת להשתמש בשמות עמודות גמישים לא אפשרית.
  • יש תמיכה במבני נתונים ב-BigQuery, אבל לפעמים הם עלולים להיכשל.
  • במקורות נתונים של Looker, ה-API לא יכול להגדיר את הערך של שדה סינון בלבד שמוגדר באמצעות הפרמטר parameter LookML.
  • שימוש ב-Conversational Analytics API כדי להתחבר למופע פרטי של Looker (Google Cloud core) באמצעות Data Studio Pro, כשהמופע הזה של Looker (Google Cloud core) נמצא בתוך גבולות גזרה של VPC Service Controls, הוא לא תצורה נתמכת ולא עומד בדרישות התאימות של VPC Service Controls.
  • בחיבורים למופעים של Looker (Google Cloud core) עם הגדרות של כתובות IP פרטיות, ‏ Conversational Analytics API לא תומך במופעים של Looker (Google Cloud core) שמוגדרים לשימוש ב-CMEK או ב-VPC Service Controls.
  • במשאבי Conversational Analytics API, ‏ CMEK נתמך רק במקורות נתונים של Looker.
  • ממשק ה-API של ניתוח נתוני שיחות לא פועל טוב עם מקורות נתונים של Data Studio שבהם השבתת עריכת שדות בדוחות מושבתת, כי ההגדרה הזו מונעת מניתוח נתוני שיחות ליצור שדות מחושבים.

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

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

מגבלות המכסה

  • ל-Conversational Analytics API יש את המגבלות הבאות על בקשות כוללות (כולל בקשות לצ'אט ובקשות שלא לצ'אט):
    • קצב מקסימלי של 10 שאילתות לשנייה (QPS), כלומר 600 שאילתות לדקה (QPM) לכל פרויקט.
    • שיעור מקסימלי של 10 שאילתות לשנייה (QPS), כלומר 600 שאילתות לדקה (QPM) לכל משתמש בכל פרויקט.
  • כחריג, יש מגבלות מחמירות יותר על בקשות לצ'אט:
    • קצב מקסימלי של 30 שאילתות לדקה לכל פרויקט.
    • קצב מקסימלי של 30 שאילתות לדקה לכל משתמש בכל פרויקט.
    • כל בקשה לצ'אט נחשבת ל-8 יחידות מכסה, במקום ליחידה אחת כמו בדרך כלל. כתוצאה מכך, בדף Quotas במסוף Google Cloud מוצגות מגבלות שהן פי 8 מהמגבלות בפועל על הבקשות. לדוגמה, מגבלה של 240 יחידות מייצגת 30 בקשות לצ'אט.
  • הקצב המקסימלי של בקשות Agent-to-Agent ‏ (A2A) הוא 10 QPS, כלומר 600 QPM לכל פרויקט לכל סוכן.
  • ל-API של ניתוח נתונים שיחתי ל-AlloyDB, ל-Cloud SQL ל-MySQL, ל-Cloud SQL ל-PostgreSQL ול-Spanner יש מגבלה של 50 שאילתות לדקה לכל פרויקט. כדי להגדיל את המגבלות האלה, צריך לפנות אל Google Cloud שירות הלקוחות.

מגבלות על סוגי שאלות

  • ה-API של ניתוח נתונים בממשק שיחה תומך בשאלות שאפשר לענות עליהן באמצעות תרשים להמחשה אחד, למשל:

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

  • ה-API של Analytics בממשק שיחה עדיין לא תומך בשאלות שאפשר לענות עליהן רק באמצעות סוגי ההמחשות המורכבות הבאים:

    • תחזיות
    • ניתוח סטטיסטי מתקדם, כולל זיהוי מתאם ואנומליות