אופטימיזציה של עלויות השימוש בפונקציית AI באמצעות זיקוק מודלים

תצוגה מקדימה

השימוש במוצר או בתכונה כפוף לתנאי השימוש במוצרים בגרסת טרום-GA, בחלק "תנאים כלליים לשירות" של התנאים הספציפיים לשירות. השימוש בתכונות ובמוצרים בגרסת טרום-GA הוא "כפי שהם" (As is), ויכול להיות שהתמיכה בהם תהיה מוגבלת. מידע נוסף זמין בקטע תיאור שלבי ההשקה.

הערה: כדי לקבל תמיכה במהלך תקופת התצוגה המקדימה, אפשר לפנות לכתובת [e-mail].

במאמר הזה מוסבר איך להשתמש במצב האופטימלי של פונקציות AI מנוהלות ב-BigQuery. אתם יכולים להשתמש במצב אופטימלי כדי לעבד מערכי נתונים גדולים שמכילים אלפים, או אפילו מיליארדים, של שורות עם צריכת טוקנים של מודל שפה גדול (LLM) וזמן אחזור של שאילתות שקטנים משמעותית בהשוואה להסקת מסקנות רגילה של LLM לכל שורה. האופטימיזציה הזו חלה רק על הפונקציות AI.IF ו-AI.CLASSIFY.

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

כדי להבין טוב יותר את צריכת האסימונים שלך, תוכלהצג את מספר האסימונים שבהם השתמשה שאילתה ב-Google Cloud לְנַחֵם. כדי להעריך את השימוש הזה לפני שמריצים שאילתה, משתמשים בפונקציה AI.COUNT_TOKENS.

הדוגמה הבאה מדגימה כיצד להשתמש בפונקציה AI.IF עם מצב אופטימלי כדי לזהות כתבות חדשותיות על אסונות טבע, תוך שימוש ב-text-embedding-005 כמודל ההטמעה:

SELECT
  title,
  body,
  AI.IF(
    ('The following news story is about a natural disaster: ', body),
    embeddings => AI.EMBED(body, endpoint => 'text-embedding-005', task_type => 'CLASSIFICATION').result,
    -- Optional, 'MINIMIZE_COST' is the default when embeddings are provided.
    optimization_mode => 'MINIMIZE_COST'
   ) AS is_natural_disaster
FROM
  `bigquery-public-data.bbc_news.fulltext`;

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

בדוגמה הזו, ההטמעות נוצרות תוך כדי תנועה. בפועל, מומלץ ליצור הטמעה כדי שאפשר יהיה להשתמש בה שוב.

איך פועל מצב אופטימלי

הפונקציות המנוהלות של AI‏, AI.IF ו-AI.CLASSIFY, קוראות בדרך כלל למודל שפה גדול (LLM) מרוחק עבור כל שורה במערך הנתונים. כשמשתמשים במצב אופטימלי, מערכת BigQuery מאמנת באופן אוטומטי מודל קל משקל ומזוקק במהלך ביצוע השאילתה.

כך מתבצע התהליך:

• דגימה ותיוג: BigQuery בוחר דגימה מייצגת קטנה של הנתונים שלכם ומפעיל את Gemini כדי לספק תוויות.
• אימון מודל מזוקק: מודל מזוקק מקומי מאומן בדיוק בזמן באמצעות התוויות והטמעות הנתונים של ה-LLM כמאפיינים.
• בדיקת איכות: מערכת BigQuery מעריכה את רמת הדיוק של המודל המזוקק בהשוואה לתוצאות של ה-LLM. כברירת מחדל, אם המודל המזוקק לא עומד בסף האיכות הנדרש, השאילתה נכשלת ומוצגת שגיאה שמסבירה למה המודל נפסל. אם איכות המודל מקובלת, יכול להיות ש-BigQuery עדיין יחזור ל-LLM המרוחק בשורות ספציפיות כדי לשמור על איכות עקבית, או בשורות שחסרים בהן הטבעות תקפות.
• הסקת מסקנות: המודל המזוקק מעבד את רוב השורות, ומצמצם באופן משמעותי את מספר הקריאות ל-Gemini.

מגבלות

המגבלות של מצב אופטימלי:

• מספר השורות המינימלי: כדי לוודא שיש מספיק נתונים לאימון המודל, הקלט לפונקציית ה-AI צריך לכלול כ-3,000 שורות.
• סוגי נתונים: עבור הנחיות המתייחסות למספר עמודות, רק עמודות מחרוזת נתמכות לאופטימיזציה.
• סיווג עם כמה תוויות: AI.CLASSIFY עם output_mode => 'multi' לא נתמך במצב אופטימלי.
• תמיכה בפונקציות: רק הפונקציות AI.IF ו-AI.CLASSIFY תומכות במצב אופטימלי. עם זאת, כשמשתמשים במצב אופטימלי עם AI.CLASSIFY, יכול להיות שהשאילתות ייכשלו אם איכות המודל המזוקק לא מספיקה.
• יחס השגיאות: הארגומנט max_error_ratio לא נתמך במצב אופטימלי.

לפני שמתחילים

כדי לקבל את ההרשאות שנדרשות להרצת פונקציות AI מנוהלות ב-BigQuery, אפשר לעיין במאמר בנושא הגדרת הרשאות לפונקציות של AI גנרטיבי שקוראות למודלים גדולים של שפה (LLM) בפלטפורמת הסוכנים של Gemini Enterprise.

בחירת מודל הטמעה

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

כדי לקבל את האיזון הטוב ביותר בין עלות, איכות ויכולת התאמה, מומלץ לחשב את ההטמעות של הנתונים באמצעות מודל הטמעה, כמו text-embedding-005 או הטמעות Gemini למשימות באנגלית או בכמה שפות. לנתונים מרובי-אופנים (טקסט ותמונות), מומלץ להשתמש במודל הטמעה מרובה-אופנים, כמו Gemini Embedding 2‏ (gemini-embedding-2).

יצירת הטמעות

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

יצירה אוטונומית של הטמעת נתונים

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

בדוגמה הבאה נוצרת טבלה עם עמודה של הטמעה שנוצרה באופן אוטונומי, באמצעות text-embedding-005 כמודל ההטמעה, ולאחר מכן נעשה שימוש בפונקציה AI.CLASSIFY כדי לסווג את הנתונים:

-- Create a table with an autonomously generated embedding column
CREATE TABLE my_dataset.bbc_news (
  title STRING,
  body STRING,
  body_embedding STRUCT<result ARRAY<FLOAT64>, status STRING>
    GENERATED ALWAYS AS (
      AI.EMBED(
        body,
        connection_id => '<my_connection_id>',
        task_type => 'CLASSIFICATION',
        endpoint => 'text-embedding-005')
    ) STORED
    OPTIONS(asynchronous = TRUE)
);

-- Insert data into the table
INSERT INTO my_dataset.bbc_news (title, body)
SELECT title, body FROM `bigquery-public-data.bbc_news.fulltext`;

-- Run the optimized query.
-- Wait for the background job to finish generating embeddings before running.
SELECT
  title,
  body,
  AI.CLASSIFY(
    body,
    categories => ['tech', 'sport', 'business', 'other']
  ) AS category
FROM
  my_dataset.bbc_news;

הגדרה ידנית של עמודות

אם יש לך עמודת הטמעה קיימת, ציין אותה בארגומנט embeddings של AI.IF או AI.CLASSIFY. אפשר ליצור את זה באמצעות הפונקציה AI.EMBED.

הדוגמה הבאה מדגימה כיצד ליצור טבלה עם עמודת הטמעה, תוך שימוש ב-text-embedding-005 כמודל ההטמעה, ולאחר מכן להשתמש בעמודה זו בשאילתת AI.CLASSIFY:

-- Create a table with an embedding column
CREATE TABLE my_dataset.bbc_news AS
SELECT
  title,
  body,
  AI.EMBED(
    body,
    endpoint => 'text-embedding-005',
    task_type => 'CLASSIFICATION'
  ).result AS body_embedding
FROM
  `bigquery-public-data.bbc_news.fulltext`;

-- Run the optimized query
SELECT
  title,
  body,
  AI.CLASSIFY(
    body,
    categories => ['tech', 'sport', 'business', 'other'],
    embeddings => body_embedding,
  ) AS category
FROM
  my_dataset.bbc_news;

אם ההנחיה שלך מפנה למספר עמודות, ספק רשימה של שמות העמודות וההטמעות המתאימות להן בארגומנט embeddings. לדוגמה: embeddings => [('body', body_embedding), ('title', title_embedding)].

אופטימיזציה של שאילתות ניטור

כדי לוודא כמה שורות עברו אופטימיזציה במהלך ביצוע השאילתה, ניתן לצפות בסטטיסטיקות הביצוע ב Google Cloud קונסולה או דרך ה-API:

המסוף

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

1. במסוף Google Cloud , עוברים לדף BigQuery.

   כניסה ל-BigQuery

2. בתפריט הניווט, לוחצים על Jobs explorer (סייר המשרות).

3. לוחצים על מזהה המשימה כדי להציג את החלונית פרטי המשימה.

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

   

API

בדוק את ה-FunctionGenAiCostOptimizationStats באובייקט GenAIFunctionStats של המטא-דאטה של ​​המשימה. אובייקט זה כולל את מספר השורות שהוסבו באמצעות זרימת העבודה הממוטבת והודעות שנוצרו על ידי המערכת המספקות תובנות לגבי מצב האופטימיזציה.

פתרון בעיות

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

גודל הנתונים קטן מדי

בעיה: נתונים לא מספיקים לאימון מודלים. יכול להיות שתופיע הודעת השגיאה הבאה: Fail to apply cost optimization because the data size is too small.

פתרון: מגדילים את גודל הקלט לכ-3,000 שורות ומוודאים שנוצרו הטמעות תקינות לכל השורות.

יש מעט דוגמאות בכמה כיתות או שאין דוגמאות בכלל

בעיה: מספר הדוגמאות לא מספיק לקטגוריות מסוימות במהלך שלב הדגימה, ולכן אי אפשר לאמן את המודל. יכול להיות שתופיע הודעת השגיאה הבאה: Fail to apply cost optimization because some classes have few or no samples.

פתרון:

• הסר קטגוריות נדירות או ריקות מקריאה לפונקציה AI.CLASSIFY.
• כדאי לקבץ קטגוריות נדירות לקטגוריה רחבה יותר כדי להגדיל את גודל המדגם. אפשר להשתמש בקטגוריה OTHER כדי לקבץ פריטים שלא נכללים בקטגוריות ספציפיות יותר. עם זאת, אל תוסיפו את OTHER אם רשימת הקטגוריות שלכם כבר מלאה, כי המונח הזה לא חד-משמעי ועלול לגרום לבלבול.

ההטמעות הן בעלות מידות לא עקביות

בעיה: חוסר עקביות בין הטמעת מאפיינים בשורות שונות. יכול להיות שתופיע הודעת השגיאה הבאה: Fail to apply cost optimization because the embeddings have inconsistent dimensions.

פתרון: מוודאים שההטמעות נוצרו על ידי אותו מודל ושיש להן את אותו אורך של וקטור ההטמעה. אפשר להשתמש בשאילתת SQL דומה לזו שבהמשך כדי לבדוק שלערכי ההטמעה בעמודה יש את אותו אורך:

SELECT ARRAY_LENGTH(body_embedding.result), COUNT(*)
FROM `PROJECT_ID.DATASET.TABLE_NAME`
GROUP BY 1;

מורכבות ההנחיה גבוהה מדי

הבעיה: המודל המזוקק לא יכול להגיע לסף דיוק גבוה. יכול להיות שתופיע הודעת השגיאה הבאה: Fail to apply cost optimization because the prompt complexity is too high.

פתרון:

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

  • הימנעו מקטגוריות חופפות שבהן קלט עשוי להשתייך למספר קטגוריות בו זמנית. לדוגמה, הימנעו מקטגוריות כמו ['terrible', 'bad', 'okay', 'good', 'excellent'].
  • חשוב להימנע ממצבים שבהם לא חלות קטגוריות. לדוגמה, הרשימה של הקטגוריות ['bad', 'average'] לא כוללת ביקורת שמביעה שבח.

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

    AI.CLASSIFY(
      review,
      categories => [
        ('terrible', 'Review where customer was not happy and the message indicates they will never try this product again'),
        ('bad', 'Review where customer was not happy but suggested improvements to the product'),
        ('okay', 'Review where customer was neutral about the product. Short reviews qualify for this category'),
        ('good', 'Review where customers were happy using this product but had minor critiques'),
        ('excellent', 'Review where customers were very happy using this product and will recommend others to try it too')],
      embeddings => review_embeddings)
    

• אפשר לנסות מודלים מתקדמים יותר להטמעה כמו text-embedding-005 או gemini-embedding-2.

• לקבלת סיוע נוסף בניפוי שגיאות, צרו קשר עם [e-mail].

מספר לא צפוי של שורות שעובדו על ידי ה-LLM

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

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

פתרון: מוודאים שההטמעות נוצרות בצורה תקינה ותקפות לכל השורות בנתונים. אם הבעיה נמשכת, אפשר לפנות אל [e-mail] כדי לקבל עזרה בניפוי באגים.

לא זוהתה עמודה של הטמעה אוטונומית

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

פתרון: השתמשו בפרמטר embeddings כדי להעביר במפורש עמודת הטמעה אוטונומית - לדוגמה, embeddings => content_embedding.result - אשר מפעילה אופטימיזציה של עלויות.

המאמרים הבאים

• מידע נוסף על AI גנרטיבי ב-BigQuery
• מידע נוסף על שליטה בעלויות של AI גנרטיבי באמצעות מכסות יומיות ב-BigQuery
• אפשר לעיין במאמרי העזרה בנושא הפונקציה AI.IF.
• אפשר לעיין במאמרי העזרה בנושא הפונקציה AI.CLASSIFY.